Not applicable.
Not applicable.
The delivery of end-to-end services often requires various service functions to be performed on data packets. Data packets are forwarded through a network along service function paths to be processed by one or more service functions. Multiprotocol label switching (MPLS) allows network nodes in a network to direct data packets from one network node to the next network node based on short path labels rather than long network addresses. The labels identify paths (e.g., virtual links) between adjacent network nodes rather than end points (e.g., a source network node and a destination network node). In MPLS, data packets from a path computation engine (PCE) do not come back once they leave a forwarding network node. Using existing systems, routing loop problems occur when a data packet returns to the forwarding network node once it has been sent by the network node. Routing loops can negatively impact a network's performance by consuming network resources such as processing power and bandwidth. Typically, routing loops are undesirable and are avoided using existing systems.
In one embodiment, the disclosure includes a data packet forwarding method comprising receiving at a first port a data packet that comprises at least one packet header that is associated with a service chain identifier (ID), forwarding the data packet to at least one second port to be processed by at least one service function, receiving the data packet from the at least one second port in response to forwarding the data packet to the at least one second port, and forwarding the data packet to a third port to a network node.
In another embodiment, the disclosure includes a data packet routing method comprising receiving service function path information that identifies a service function path, generating a path reservation message that comprises at least a portion of the service function path information, sending the path reservation message to a network node along the service function path, and receiving a confirmation message in response to the path reservation message.
In yet another embodiment, the disclosure includes an apparatus comprising an ingress port, an egress port, a port associated with a service function, a memory, and a processor coupled to the ingress port, the egress port, the port, and the memory, and configured to receive from the ingress port a data packet that comprises a packet header that is associated with a service ID, forward the data packet to the port for processing by the service function, receive the data packet from the port in response to forwarding the data packet to the port, and forward the data packet to the egress port to a network node.
These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.
For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.
It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
Disclosed herein are various embodiments for routing and implementing service functions along service function chains and service function paths. Network nodes are configured to route and forward data packets along different service function paths and forwarding paths based on service function path information. Network nodes are configured to generate service function path entries based on the service function path information, to generate steering policies based on the service function path information, and to generate local or internal forwarding policies. Service function path entries, steering policies, and local steering policies can be employed to route data packets using based on both the network nodes and the service function along a service function chain. This provides two layers of routing ability for data packets. Further, network nodes are configured to send a data packet from a port to a service function and then to receive the processed data packet from the same port after the service function processes the data packet without causing looping problems. As such, routing loops can be implemented in a network for routing data packets along service function chains or service function paths.
SC-PCE 104 is configured to compute and provide service function chains and service function paths for network 102. A service function chain is an ordered set of service functions and ordering constraints that is applied to data packets, data frames, and/or data flows. A service function chain may comprise one or more service function paths along the service function chain. A service function path may also be referred to as an explicit path. A service function is a function that specifies a specific treatment for a data packet. Service functions are functions that can act at various layers of a protocol stack, for example, at the network layer or other open system interconnection (OSI) layers. A service function can be realized as a virtual element, a physical network element, or embedded in a physical network element. One or more service functions can be embedded in the same network element. Multiple occurrences or instances of the service function can exist in the same domain. A service function may also be referred to as a service function instance when multiple instances exist. As such, the terms “service function” and “service function instance” may be used interchangeably. Examples of service functions include, but are not limited to, firewalls, wide area network (WAN) and application acceleration, deep packet inspection (DPI), lawful interception (LI), server load balancing, network address translation (NAT)-44, NAT-64, Internet Protocol version 6 network prefix translation (NPTv6), HOST_ID injection, hypertext transfer protocol (HTTP) header enrichment functions, and transmission control protocol (TCP) optimization.
Network node 106 is configured as a service function chain or service function path ingress node. A service function path ingress node may also be referred to as a head-end of the service function path. Network nodes 108 are service function forwarder (SFF) network nodes that comprise a plurality of ports and one or more service functions attached to each of the ports. A port that is attached to a service function refers to a port of an SFF network node that is physically coupled to a service function, configured to be couple to a service function, associated with a service function, or configured to interact with a service function. SFF network nodes are configured to forward data packets to the attached service functions and to other network nodes. An SFF network node is configured to discover which port each service function is connected to. For example, an SFF network node may employ an address resolution protocol (ARP)/neighbor discovery (ND) protocol where the Internet Protocol (IP) address of the service function is attached by an explicit route (ERO) to discover which port each service function is connected to. Network nodes 110 are configured to communicate data packets through network 102. Network nodes 112 are configured as service function chain or service function path egress nodes. A service function path egress node may also be referred to as a tail-end of the service function path. SC-PCE 104 and network nodes 106-112 may be coupled to one another via one or more tunnels and/or links. Examples of tunnels include, but are not limited to, multiprotocol label switching (MPLS) tunnels and virtual extensible local area network (VxLAN) tunnels. Links may include physical links, such as electrical and/or optical links, and/or logical links (e.g., virtual links).
SC-PCE 104 is configured to compute service function chains and service function paths for the service function chain and to send the service function path information 150 to the service function path ingress node (e.g., network node 106). Service function path information 150 can be sent as an individual message or can be carried within a data packet. The service function path information 150 may comprise a service chain identifier (ID), a list of SFF network nodes or SFF network node identifiers along a service function path, a list of service functions attached to each of the SFF network nodes, and an ingress node for the service function path. In an embodiment, SC-PCE 104 sends the service function path information 150 using a PCE communication protocol and path request message or path request message objects as described in Internet Engineering Task Force (IETF) request for comments (RFC) 5440 titled, “Path Computation Element (PCE) Communication Protocol (PCEP),” by Vassuer et al., published in March 2009, which is hereby incorporated by reference as if reproduced in its entirety, or other versions thereof. Alternatively, the service function path information 150 is sent using an explicit signaling method (e.g., head-end dynamic signaling and software-defined networking (SDN) controller dynamic signaling) or an out-of-band provisioning method.
The service function path ingress node, network node 106, is configured to inspect the service function path information 150 and to send a path message 152 that comprises at least a portion of the service function path information 150 to a next hop along the service function path towards the egress node of the service function path. Path message 152 may also be referred to as a path reservation message. The path message 152 is shown as a dashed arrow line. A path message may be configured similarly to path messages described in IETF RFC 4875 titled, “Extensions to Resource Reservation Protocol—Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs),” by Aggarwal et al., published in May 2007, which is hereby incorporated by reference as if reproduced in its entirety, or other versions thereof. For legacy IP networks, network node 106 is configured to encapsulate the RSVP in VxLAN. For example, network node 106 maps the service chain ID to a VxLAN header. The RSVP sub-TLV carries the list of service function network nodes attached to each service function forwarder network node. Table 1 is an embodiment of encapsulating RSVP in VxLAN.
Network nodes 108 and 110 are configured to receive the path message 152, to configure itself based on the service function path information 150, and to forward the path message 152 to a next hop along the service function path towards the egress node of the service function path. The service function path information 150 comprises instructions for network nodes 108 and/or 110 to associate or to map a tunnel, a port, and/or one or more data packet attributes to a service chain ID for routing data packets. Data packet attributes may include, but are not limited to, a packet header, a tunnel header, a media access control address, an IP address, a virtual local area network (VLAN) ID, a multiprotocol label switching (MPLS) tag or label, a virtual private network (VPN) header, and a global label. Alternatively, network nodes 108 and 110 may receive instructions for associating or to mapping a tunnel, a port, and/or one or more data packet attributes to a service chain ID for routing data packets in a separate message (not shown) from SC-PCE 104.
The service function egress nodes, network nodes 112, are configured to inspect the service function path information 150 from path message 152 and to send a confirmation message 154 to a previous hop along the service function path towards the ingress node of the service function path. The confirmation message 154 is shown as a solid arrow line. In an embodiment, the confirmation message may be configured similarly to reservation (RESV) messages described in IETF RFC 4875.
Data packets 156 may then be communicated from the service function ingress node along the service function paths to the service function egress nodes when the confirmation message is received by the service function ingress node. Data packets 156 are shown as a starred arrow line.
Additional details about service functions and service function chaining architectures are described in IETF RFC draft titled, “Service Function Chaining (SFC) Architecture,” by J. Halpern, et al., published on Mar. 6, 2015, IETF RFC draft titled, “Service Function Chaining (SFC) Control Plane Achitecture,” by H. Li, et al., published on Mar. 8, 2015, IETF RFC draft titled, “Framework for Service Function Path Control,” by L. Dunbar, et al., published on Mar. 6, 2015, and IETF RFC draft titled, “MPLS-Based Hierarchical SDN for hyper-Scale DC/Cloud,” by L. Fang, et al., published on Mar. 27, 2015, which are all hereby incorporated by reference as if reproduced in their entirety, or other versions thereof.
The processor 330 may be implemented by hardware and software. The processor 330 may be implemented as one or more central processing unit (CPU) chips, logic units, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 330 is in communication with the ports 310, Tx/Rx 320, and memory 340.
The memory 340 comprises one or more of disks, tape drives, and solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution. The memory 340 may be volatile and non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), and static random-access memory (SRAM). Service function module 350 is implemented by processor 330 to execute the instructions for implementing various embodiments for routing and forwarding data packets along different service function paths and forwarding paths based on service function path information, generating service function path entries based on the service function path information, generating steering policies based on the service function path information, and generating local or internal forwarding policies. The inclusion of service function module 350 provides an improvement to the functionality of network element 300. The service function module 350 also effects a transformation of network element 300 to a different state. Alternatively, service function module 300 is implemented as instructions stored in the processor 330.
Network nodes 402, 406, and 408 may be configured similarly to network nodes 106-112 in
Network node 404 is configured to receive service function path information (e.g., service function path information 150 in
As an example, network node 404 receives service function path information for a first service path 450 between network node 402 and network node 406 and service function path information for a second service function path 452 between network node 402 and network node 408. The first service function path 450 comprises a path from network node 402 via port 410A to service function 412A via port 410B, to service function 412C via port 410D, and to network node 406 via port 410G. The second service function path 452 comprises a path from network node 402 via port 410A to service function 412B via port 410C, to service function 412D via port 410E, and to network node 408 via port 410G. Accordingly, network node 404 is configured to generate service function path entries and steering policies for the first service path 450 and the second service path 452.
Data packets can be forwarded along the first service function path 450 and the second function path 452. Data packets may comprise one or more data packet attributes that are associated with a service chain ID and can be forwarded based on the service chain ID, the tunnel and/or port where they are received, and/or based on one or more data packet attributes. For example, a data packet for the first service function path 450 is received at port 410A. The data packet is forwarded to service function 412A via port 410B. The processed data packet is received from service function 412A at port 410B and is forwarded to service function 412C via port 410D. The processed data packet is received from service function 412C at port 410D and is forwarded to network node 406 via port 410G. The data packet is forwarded to network node 406 using packet headers or tunnel headers from the service function path entries. As such, data packets are transmitted from and received at the same port to be processed by a service function.
Network nodes 702, 704, 708, and 710 may be configured similarly to network nodes 106-112 in
Network node 706 is configured to receive service function path information (e.g., service function path information 150 in
As an example, network node 706 receives service function path information for a first service function path 750 between network node 702 and network node 708 and service function path information for a second service function path 752 between network node 704 and network node 710. The first service function path 750 uses layer 2 routing and comprises a path from network node 702 via port 712B to service function 714A via port 712C, to service function 714C via port 712E, and to network node 708 via port 712H. The second service function path 752 uses layer 3 routing and comprises a path from network node 704 via port 712A to service function 714A via port 712C, to service function 714D via port 712F, and to network node 710 via port 712I. Accordingly, network node 706 is configured to generate service function path entries and steering policies for the first service path 750 and the second service path 752.
Data packets may comprise one or more data packet attributes that are associated with a service chain ID and can be forwarded based on the service chain ID, the tunnel and/or port where they are received, and/or the one or more data packet attributes. When a data packet is received for the first service function path at port 712B, the data packet is forwarded to service function 714A via port 712C. The processed data packet is received from service function 714A at port 712C and is forwarded to service function 714C via port 712E. The processed data packet is received from service function 714C at port 712F and is forwarded to network node 708 via port 712H. The data packet is forwarded to network node 708 using tunnel headers from the service function path entries.
When a data packet is received for the second service function at port 712A, the packet header or tunnel header is removed from the data packet and a local label is added to the data packet. The data packet is forwarded to service function 714A via port 712C. The processed data packet is received from service function 714A at port 712C and is forwarded to service function 714D via port 712F. In an embodiment, a second local label is attached to the processed data packet before sending the data packet to service function 714D. The processed data packet is received from service function 714D at port 712F and is forwarded to network node 710 via port 712I. The data packet is forwarded to network node 710 using a packet header or a tunnel header from the service function path entries. In an embodiment, the data packet is forwarded to network node 710 with local labels. Alternatively, the local labels are removed and the packet header or tunnel header is added to the data packet before sending the data packet to network node 710.
The flag bit field 1102 is a one bit field. The type field 1104 is a seven bit field and indicates that the IP address in the service function ERO sub-TLV 1100 are associated with one or more service functions in a network node. The length field 1106 is an eight bit field and indicates the length of the service function ERO sub-TLV 1100, for example, in bytes. The prefix length field 1108 is an eight bit field and indicates the length of the IP prefix of the service function ERO sub-TLV 1100, for example, in bytes. The IP prefix field 1110 may have a variable length and comprises the IP prefix for network nodes that are attached to one or more service functions.
While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the spirit or scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.
In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the spirit and scope disclosed herein.
The present application claims priority to U.S. Provisional Application No. 61/991,002 filed May 9, 2014 by Linda Dunbar, et al., and entitled “Service Chain Instance Path Route Reservations,” which is incorporated herein by reference as if reproduced in its entirety.
Number | Date | Country | |
---|---|---|---|
61991002 | May 2014 | US |