Scalable service level agreement (SLA) verification and action using a data plane

An ingress node inserts into a header of a packet service level agreement information and forwards the packet. At an egress node of the network, the packet is received and the service level agreement information is obtained from the header of the packet. The egress node verifies whether there is conformance to a service level agreement based on at least one parameter associated with reception of one or more packets at the egress node and the service level agreement information.

The present disclosure relates to inband service level agreement (SLA) verification.

BACKGROUND

Network service providers are expected to provide differentiated levels of service according to service level agreements (SLAs). Currently, SLA verification measures latency, including jitter and delay, by using an out-of-band mechanism and sending synthetic probe packets that are independent of production data flows. While an effort is made to resemble production traffic, such as voice or video, an actual path that the production traffic takes, based on hashing, could differ from a path of out-of-band traffic. Latency could be related to a characteristic of a specific flow, a specific path, a specific size, etc., which may not be detected by an out-of-band probe packet. Consequently, during SLA verification, an exact service level achieved by a specific user may not be determined.

Network analytics is a key area for monetization of a network. For example, the NetFlow™ technology is used for collecting network and flow related information, which is periodically uploaded to a network management server for analytics. The analytics may be used for real-time service assurance. Federating such distributed data in order to perform real-time and predictive service assurance is difficult to achieve on a per-flow basis. For ease and scalability, real-time and predictive service assurance checks for any resource constraints, and if a predefined threshold is breached, a link/path will be excluded. However, per-flow visibility is not possible.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

An ingress node inserts into a header of a packet service level agreement information and forwards the packet. At an egress node of the network, the packet is received and the service level agreement information is obtained from the header of the packet. The egress node verifies whether there is conformance to a service level agreement based on at least one parameter associated with reception of one or more packets at the egress node and the service level agreement information.

EXAMPLE EMBODIMENTS

FIG. 1illustrates an example of an environment100in which the various embodiments presented herein may be deployed. The environment includes a network102of which there is an ingress node104and egress node106. There are numerous other nodes in the network102that are not shown for simplicity. According to embodiments presented herein, the ingress node104generates packets according to flow information and inserts expected or agreed-upon SLA information into headers of one or more packets of a packet flow. The expected SLA information may include agreed-upon delay (latency), jitter, packet loss, etc. Delay (latency) is measured in terms of end-to-end (ingress-to-egress) time taken for a packet to travel. Jitter is a variation on delay and measures the delay over various packets, and compares the delay differences. Packet loss is a measure of drops of packets, and is commonly reflected as a percentage (packet loss percentage). In accordance with the techniques presented herein, the egress node will measure delay/latency for packets. The egress node can additionally compute jitter (over a plurality of packets) as well as packet loss by comparing an in-packet carried sequence number value to an expected sequence number of a received packet. In any case, the expected SLA information (whether it is delay, jitter, packet loss, etc.) is inserted into at least one packet that is sent from the ingress node into the network and for reception by the egress node.

The flow information may be 5-tuple-based (e.g., source IP address/port number, destination IP address/port number and the protocol of a Transmission Control Protocol/Internet Protocol (TCP/IP) connection), Quality of Service (QoS)-based (precedence/Differentiated Services Code Point (DSCP)), ingress interface-based, or Virtual Routing and Forwarding (VRF)-based, etc.

The ingress node104may receive a packet that is part of a flow that matches a SLA requirement policy (i.e., a packet that is part of a flow to be monitored for SLA compliance) and may append to the packet, as part of a packet header, the expected SLA information. In embodiments that operate in an IP version 6 environment, the packet header may be an extension header. In other embodiments, the packet header may be a network service header. The ingress node104may then forward the packet into network102where it eventually reaches the egress node106.

The above-described actions of the ingress node104could be considered as a Service Function Chaining paradigm where the egress node106serves as a Service Function Forwarder hosting a Service Function that is responsible for performing network analytics such as, for example, SLA verification.

When the egress node106receives the packet and determines, based on the expected SLA information in the header, that the packet failed SLA verification, the egress node106may send a notification to the ingress node104and/or to a network controller108indicating that the packet failing the SLA verification. The notification signaling may be accomplished by using either an out-of-band mechanism or an inband Operation, Administration and Maintenance (OAM) mechanism.

Upon receiving the notification, the ingress node104or the network controller108could take a number of different actions, some of which may include, but not be limited to, triggering a Fast Retransmit and Recovery (FRR) or increasing a metric on a Provider Edge (PE) to Customer Edge (CE) link to redirect traffic.

In some embodiments, the notification may be sent to network controller108, or to a centralized management server (not shown) for accounting purposes.

Integration with application endpoints is also possible. For example, the egress node106or the network controller108, upon knowing an application within a flow, may signal an originating endpoint or a controller of the originating endpoint (for a voice or video call) to throttle transmission, change codecs, or perform another action. Further details and use cases will become more apparent in connection with the following description.

FIG. 2illustrates a block diagram of an ingress node, shown at reference numeral200. The ingress node200includes input ports210and output ports220. In one embodiment, the ingress node200includes a network processor Application Specific Integrated Circuit (ASIC)230, or multiple such ASICs. Network processor ASIC230may include fixed digital logic, programmable logic, or a combination thereof. For example, network processor ASIC230may include fixed or programmable digital logic integrated circuits, in which digital logic gates are configured to perform instructions of SLA information insertion logic240. Network processor ASIC230may further include memory (not shown) and fixed or programmable digital logic for networking functions, such as switching, routing, etc.

The ingress node200may include network processor ASIC230or memory250or both network processor ASIC230and memory250. The ingress node200may further include one or more processors270. Memory250may include SLA information insertion logic260.

The one or more processors270may be one or more microprocessors or microcontrollers configured to execute program logic instructions, such as SLA information insertion logic260, for carrying out various operations and tasks described herein. For example, the one or more processors270may execute SLA information insertion logic260stored in memory250(as e.g., software) in order to perform SLA information insertion techniques described herein. Memory250may include read only memory (ROM), random access memory (RAM), magnetic storage media, optical storage media, flash memory, electrical, or other physical/tangible (non-transitory) memory.

The functions of one or more processors270may be implemented by logic encoded in one or more non-transitory tangible computer readable media, wherein memory250may store data used for operations described herein and may store software or processor executable instructions that are executed to carry out the operations described herein.

SLA information insertion logic260may take any of a variety of forms, so as to be encoded in one or more non-transitory tangible computer readable memory media or storage device (e.g., memory250) for execution, such as fixed logic or programmable logic (e.g., software/computer instructions executed by a processor).

FIG. 3illustrates a block diagram of an egress node shown at reference numeral300. The egress node300may include input ports310and output ports320. In one embodiment, the egress node300includes a network processor ASIC330, or multiple such ASICs. Network processor ASIC330may include fixed digital logic, programmable logic, or a combination thereof. For example, network processor ASIC330may include fixed or programmable digital logic integrated circuits, in which digital logic gates are configured to perform instructions of SLA verification logic340. Network processor ASIC330may further include memory (not shown) and fixed or programmable digital logic for networking functions, such as switching, routing, etc.

The egress node300may include network processor ASIC330or memory350or both network processor ASIC330and memory350. The egress node300may further include one or more processors370. Memory350may include SLA verification logic360.

The one or more processors370may be one or more microprocessors or microcontrollers configured to execute program logic instructions such as SLA verification logic360for carrying out various operations and tasks described herein. For example, one or more processors370can execute SLA verification logic360stored in memory350(as e.g., software) in order to perform SLA verification techniques described herein. Memory350may include ROM, RAM, magnetic storage media, optical storage media, flash memory, electrical, or other physical/tangible (non-transitory) memory.

The functions of one or more processors370may be implemented by logic encoded in one or more non-transitory tangible computer readable media, wherein memory350may store data used for operations described herein and may store software or processor executable instructions that are executed to carry out the operations described herein.

SLA verification logic360may take any of a variety of forms, so as to be encoded in one or more non-transitory tangible computer readable memory media or storage device (e.g., memory350) for execution, such as fixed logic or programmable logic (e.g., software/computer instructions executed by a processor).

FIGS. 4 and 5illustrate example topologies for various embodiments of the inband SLA verification techniques.FIG. 4illustrates a topology in an IP version 6 environment.FIG. 5illustrates a topology in an environment that uses a network service header.FIGS. 4 and 5depict an example in which the SLA expectation information is related to latency/delay. This is only by way of example and is not meant to be limiting.

InFIG. 4, a network400is shown that includes an ingress node402. The ingress node402receives a packet404that is part of a flow for which SLA verification is to be made. The packet404includes source address information, destination address information and a payload. Upon determining that the received packet404matches the SLA requirement policy, the ingress node402may append an IP version 6 extension header406to the packet404. The extension header may include SLA expectation information and a first local timestamp indicating a time of departure of the packet from the ingress node. For example, the SLA expectation information is a latency of 80 msec and the first local timestamp is T1. After appending the IP version 6 extension header406to the packet404, the ingress node402may forward the packet404into network400where it ultimately will reach an egress node. As explained above, appending the IP version 6 extension header and forwarding the packet404to an egress node408may be considered to be Service Function Chaining (SFC) with the egress node408as a Service Function Forwarder (SFF) hosting a Service Function (SF) that is responsible for performing network analytics such as, for example, SLA verification.

Upon receiving the packet404with the appended extension header406, the egress node408obtains a second local timestamp, T2, the time at which the packet404arrives at the egress node, and verifies whether the packet conforms to SLA expectation information based on a difference between the second local timestamp and the first local timestamp and the SLA expectation. In other words, the egress node uses T2as a local processing timestamp and determines the difference between T1and T2for the packet to determine if the end-to-end (ingress-to-egress) delay/latency is within the SLA expectation, e.g., 80 msec, that was inserted into the packet.

When the egress node408determines that the packet having the appended extension header is not verified as conforming to the SLA, the egress node408may send a notification indicating a failed SLA verification to the ingress node402or to a network controller. The notification may be sent via an out-of-band mechanism or an inband OAM mechanism.

Upon receiving the notification, the ingress node402or the network controller could take a number of different actions including, but not limited to, triggering a Fast Retransmit and Recovery or increasing a metric on a PE to CE link to redirect traffic.

Reference is now made toFIG. 5.FIG. 5shows a network500having an ingress node502. The ingress node502receives a packet504that is part of a flow for which SLA verification is to be made. The packet504includes source address information, destination address information and a payload. Upon determining that the received packet504matches an SLA requirement policy, the ingress node502may append a network service header (NSH)506to the packet504. The network service header may include SLA expectation information and a first local timestamp. Again, in this example, the SLA expectation information is a latency of 80 msec and the first local timestamp is T1. After appending the network service header506to the packet504, the ingress node502may forward the packet504into the network50where it ultimately reaches egress node508.

Upon receiving the packet504with the appended network service header506, the egress node508obtains a second local timestamp (T2) and verifies whether the packet conforms to the SLA based on a difference between the second local timestamp and the first local timestamp and the SLA expectation information, as described above in connection withFIG. 4.

As described above in connection withFIG. 4, when the egress node508determines that the packet having the appended network service header is not verified as conforming to the SLA, the egress node508may send a notification indicating a failed SLA verification to the ingress node502or to a network controller. The notification may be sent via an out-of-band mechanism or an inband OAM mechanism.

Upon receiving the notification, the ingress node502or the network controller could take a number of different actions including, but not limited to, triggering a Fast Retransmit and Recovery or increasing a metric on a PE to CE link to redirect traffic.

SLA verification, using either IP version 6 extension headers or network service headers, may be integrated with application endpoints. In such embodiments, upon receiving the signal, the ingress node402,502or the network controller may throttle transmission, change codecs, or may perform another action.

FIG. 6is a flowchart that illustrates example processing in various embodiments of an ingress node. At602, the process may begin with the ingress node receiving or obtaining a packet via one of its input ports. The ingress node may then determine, at604, whether the packet matches an SLA requirement policy. If the ingress node determines that the packet does not match the SLA requirement policy, then the packet may be forwarded into the network at614.

At604, if the ingress node determines that the packet matches the SLA requirement policy, then a header may be appended to the packet. The header may be an IP version 6 extension header in some embodiments and in other embodiments, the header may be a network service header.

At608, the ingress node may copy/insert SLA information into the header appended to the packet. The SLA information may include an SLA expectation, such as latency, jitter or packet loss, for example.

When the SLA information pertains to delay or jitter, operations610and612are performed. At610, the ingress node obtains a first local timestamp and, at612, the ingress node may include the first local timestamp in the header. The first local timestamp represents the time that the packet is sent into the network by the ingress node.

The ingress node may then forward the packet with the appended header into the network, at614. If the SLA information pertains to a parameter other than delay or jitter, such as packet loss, then operations610and612are not necessary, but sequence numbers are included in packets so that the egress node can determine when packets that are expected to be received (based on sequence number), are not received. This is useful for determine conformance with a SLA-based packet loss.

FIG. 7is a flowchart illustrating example processing in the egress node. At702, the egress node receives the packet (which originated at the ingress node) in the network. At704, the egress node determines whether the packet includes a header (an IP version 6 extension header or a network service header) having stored therein SLA expectation information (and perhaps a local timestamp). If the egress node determines that the packet does not include the header having stored therein the SLA expectation information then, at706, the packet is forwarded to a destination and the process is completed.

If the egress node determines that the packet includes the header having stored therein SLA expectation information and a local timestamp, then the following operations are performed. When the header further a local timestamp inserted by the ingress node, then at708, the egress node may obtain a second local timestamp associated with receipt of the packet at the egress node. At710, the egress node obtains the SLA information contained in the packet and the first local timestamp, if one is included. At712, the packet may be forwarded to the destination.

At714, the egress node may submit the SLA information to a local process (running at the egress node) to determine whether there is conformance to the SLA based on the SLA information obtained from the header of the packet.

The determination made at714depends on the type of SLA information contained in the header of the received packet. When the header of the received packet includes a first local timestamp inserted by the ingress node and the SLA information contained in the header is expected latency/delay, then the egress node uses the second timestamp (obtained at708) associated with reception of the packet at the egress node, and determines a difference between the first local timestamp and the second local timestamp. Thus, in this example, verification of conformance to the SLA involves comparing the difference with the expected latency value contained in the header of the packet. If the difference is determined to be outside the expected latency, then the conformance of the packet to the SLA fails.

When the SLA information in the header of the packet is expected jitter, then the egress node determines differences, for a plurality of packets received at the egress node, between a first local timestamp associated with a packet sent by the ingress node and a second local timestamp associated with a packet received at the egress node. The egress computes a jitter value based on the differences, and compares the jitter value with the expected jitter. If the jitter value is outside the expected jitter, then conformance to the SLA fails.

Further still, when the SLA Information in the header of the packet is expected packet loss, the egress node determines whether and how many packets sent by the ingress node do not reach the egress node based on sequence number information contained in the packets, and the egress node computes a packet loss value, accordingly. Then egress node then compares the packet loss value with the expected packet loss, and when the packet loss value is outside the expected packet loss, conformance to the SLA fails.

When conformance to the SLA fails, a packet counter may be incremented, at718. If, at720, the packet counter is determined not to be greater than or equal to a predefined maximum count, then the process is completed. Otherwise, the packet counter may be reset, at722, and a signal may be sent, at724.

As mentioned previously, the signal may be sent to the ingress node or a network controller. In some embodiments, in which the egress node or the network controller has knowledge of an application within the flow, the egress node or the network controller may signal an originating endpoint of the application, or a network controller of the originating endpoint, to perform an action including, but not limited to, throttling transmission or changing a codec.

In some embodiments, in addition to the packet counter being reset when the packet counter becomes greater than or equal to the predefined maximum count, the packet counter may also be reset after each predefined time interval. The predefined time interval may be 10 seconds, 60 seconds, or some other time interval. In such embodiments, a signal indicating failed SLA verification will be sent every time the packet counter reaches the predefined maximum count during a predefined time interval.

Embodiments which use inband SLA verification provide a clear picture regarding whether actual data traffic is flowing according to the expected SLA. Further, SLA verification is very granular such that it could be used as: always on; selective packet based verification; or on-demand verification. As explained above, SLA verification may be based on delay (latency) measured in terms of end-to-end (ingress-to-egress) time difference of a packet, as well as jitter and packet loss. The egress node will measure delay/latency for packets. The egress node can additionally compute jitter (over a plurality of packets) as well as packet loss by comparing an in-packet carried sequence number value to an expected sequence number of a received packet. Thus, the SLA information inserted into a header of a packet at an ingress node may include expected/maximum delay/latency, expected/maximum jitter and expected/maximum packet loss.

Thus, in summary, in one form, a method is provided comprising: receiving, at an egress node of a network, a packet that includes in a header thereof service level agreement information inserted by an ingress node of the network; obtaining, by the egress node, the service level agreement information; and verifying, by the egress node, whether there is conformance to a service level agreement based on at least one parameter associated with reception of one or more packets and the service level agreement information.

In another form, an apparatus is provided comprising: a plurality of network ports of an egress node configured to receive and send packets over a network; a network processor unit coupled to the plurality of network ports and configured to determine how to direct packets with respect to the plurality of network ports; and a processor configured to: obtain, at an egress node of a network, from a header of a packet received at one of the plurality of network ports, service level agreement information inserted by an ingress node of the network, and verify whether the packet conforms to a service level agreement based on at least one parameter associated with reception of one or more packets and the service level agreement information.

In still another form, one or more non-transitory computer readable storage media are provided that are encoded with instructions, which when executed by a processor, cause the processor to perform operations comprising: receiving, at an egress node of a network, a packet that includes in a header thereof service level agreement information inserted by an ingress node of the network; obtaining, by the egress node, the service level agreement information; verifying, by the egress node, whether there is conformance to a service level agreement based on at least one parameter associated with reception of one or more packets and the service level agreement information.

In yet another form, a method is provided comprising: obtaining, at an ingress node of a network, a packet to be sent into the network; inserting into a header of the packet service level agreement information for use by an egress node of the network in verifying conformance to a service level agreement; and forwarding the packet into the network.

In still another form, an apparatus is provided comprising: a plurality of network ports of an ingress node configured to receive and send packets over a network; a network processor unit coupled to the plurality of network ports and configured to determine how to direct packets with respect to the plurality of network ports; and a processor configured to: obtain, at an ingress node of a network, a packet to be sent into the network; insert into a header of the packet service level agreement information for use by an egress node of the network in verifying conformance to a service level agreement; and forward the packet into the network.

In still another form, one or more non-transitory computer readable storage media are provided that are encoded with instructions, which when executed by a processor, cause the processor to perform operations comprising: obtaining, at an ingress node of a network, a packet to be sent into the network; inserting into a header of the packet service level agreement information for use by an egress node of the network in verifying conformance to a service level agreement; and forwarding the packet into the network.

In yet another form, a method is provided comprising: obtaining, at an ingress node of a network, a packet to be sent into the network; inserting into a header of the packet service level agreement information for use by an egress node of the network in verifying conformance to a service level agreement; forwarding the packet into the network; receiving, at the egress node the packet that includes in the header thereof service level agreement information inserted by the ingress node; obtaining, by the egress node, the service level agreement information; and verifying, by the egress node, whether there is conformance to a service level agreement based on at least one parameter associated with reception of one or more packets and the service level agreement information.

In still another form, a system is provided comprising an ingress node, an egress node, both of which are part of a network, wherein the ingress node is configured to: obtain a packet to be sent into the network; insert into a header of the packet service level agreement information for use by the egress node of the network in verifying conformance to a service level agreement; and forward the packet into the network; and wherein the egress node is configured to: receive the packet that includes in the header thereof service level agreement information inserted by the ingress node; obtain the service level agreement information; and verify whether there is conformance to a service level agreement based on at least one parameter associated with reception of one or more packets and the service level agreement information.

Label-Based Source-Triggered NetFlow and Resource Data Collection

Typically, network devices such as, for example, routers, are configured to collect and export network information. However, per-flow visibility is not generally provided. To solve this problem, control is placed on a source instead of an intermediate router. For example, an instruction may be included in a packet instead of in a router command line interface (CLI). This can be achieved by tagging a packet with a specific marking. In one embodiment, this can be accomplished by using a Multiprotocol Label Switching (MPLS) label value (“NetFlow Label” or NFL). The NFL is applicable to traditional MPLS networks and segment routing. In another embodiment, this can be achieved by using an IP version 6 Flow Label value or an IP version 6 extension header signal.

Reference is now made toFIGS. 8 and 9.FIG. 8shows an embodiment using MPLS labels in this manner. A label table800of a label switch router (LSR) or transit router is shown. A value,1010in this example, is associated with a “NetFlow Query” behavior. Therefore, when a label having the value1010arrives at a transit router, in addition to forwarding a packet as usual, a network resource report is triggered and sent to a server902, as shown inFIG. 9. The network resource report may include information such as local resource utilization of an ingress buffer queue, ingress card CPU utilization, ingress memory utilization, etc.

AlthoughFIG. 8depicts an embodiment using MPLS labels, the same concept may be used with respect to another embodiment that uses, for example, IP version 6 extension headers. In other words, the concept may be used with any way of tagging a packet.

FIG. 10shows an example similar to that ofFIG. 9, but using an IP version 6 extension header with NFL1014instead of an MPLS label.

FIG. 11illustrates an example process in which packets in a flow may be tagged with a NFL to trigger a network resource report. The process may begin, at1102, with an ingress node tagging a packet with a NFL and forwarding the packet. At1104, a node receives the packet. The node may determine whether the packet is tagged with the NFL, at1106. If the node is not tagged with the NFL, then the packet is forwarded, at1112, and the process may be completed. Otherwise, the node forwards the packet, at1108, and at1110, triggers creation of a network resource report, which then may be sent to a central server. The process may then be completed.

The sending of network reports is scalable because every packet may not include a NFL. For example, the NFL may be included in every Nthpacket, where N may be 100, 50, 200, or another number.

The central server may use network resource information to perform analytics and may perform an action if the SLA is breached or predicted to be breached based on the collected network resource information.

In some embodiments, by default, information captured by NetFlow and uploaded for real-time analytics may include: flow information such as, for example, a header tuple, protocol, etc.; packet context, which may include path information such as incoming interface, outgoing interface, stack details (e.g., MPLS or segment routing (SR) stack); and network context, which may include resource information such as CPU utilization, backplane utilization, etc.

In its most fundamental form, a static generic tag may be used including, but not limited to an MPLS label, an IP version 6 flow label, an extension header, and a Type-Length Value (TLV) within inband OAM within IP version 6 (iOAM6).

Positioning a well-defined and unique tag anywhere in a stack to trigger collection of NetFlow information introduces a new paradigm in diagnostics collection. The paradigm shifts from a device/configuration-based paradigm to a more scalable packet-based paradigm and moves control from transit devices to a source, where there is flexibility to perform a full rate/bulk collection to selective packet marking for custom or in-depth flow analysis.