Dynamic service chain provisioning

In general, techniques for dynamically provisioning service chains are described. In one example a network device comprises a control unit having at least one processor coupled to a memory, wherein the control unit is configured to receive a services list comprising an ordered list of services, the ordered list of services specifying at least a first service and a second service. The network device also comprises a forwarding unit coupled to the control unit and configured to receive a packet of a packet flow from a first service node that has applied the first service to the packet, wherein the forwarding unit is configured to send, based at least on the ordered list of services, the packet to a second service node that applies the second service.

TECHNICAL FIELD

The invention relates to computer networks and, more specifically, to applying network services to network traffic traversing computer networks.

BACKGROUND

A computer network is composed of a set of nodes and a set of links that connect one node to another. For instance, a computer network may be composed of a set of routers while the set of links may be cables between the routers. When a first node in the network sends a message to a second node in the network, the message may pass through many links and many nodes. The set of links and nodes that the message passes through while traveling from the first node to the second node is referred to as a path through the network.

A network operator may deploy one or more network devices to implement service points that apply network services such as firewall, carrier grade network address translation (CG-NAT), performance enhancement proxies for video, transport control protocol (TCP) optimization and header enrichment, caching, and load balancing. In addition, the network operator may configure service chains that each identifies a set of the network services to be applied to packet flows mapped to the respective service chains. A service chain, in other words, defines one or more network services to be applied in a particular order to provide a composite service for application to packet flows bound to the service chain.

SUMMARY

In general, techniques for dynamically provisioning service chains are described. For example, a service control gateway may be provisioned by a policy server with an ordered list of services to be applied to packet flows. Based on the list of services, the service control gateway may orchestrate traversal of the ordered list of services by the packets flows and, in this way, dynamically stitch together a service chain made up of the ordered list of services for application to the packet flows.

In one example implementation, the ordered list of services is bifurcated into an uplink ordered list (“uplink services list”) of virtual private network (VPN) routing and forwarding instances/tables (VRFs) of the service control gateway and a downlink ordered list (“downlink services list”) of VRFs of the service control gateway. Each VRF of the uplink services list may specify a matching route for the packet flows to the corresponding service, and each VRF of the downlink services list may specify a matching route for the packet flows to a VRF of the uplink services list or a matching route for the packet flows to the default routing table. The service control gateway may stitch together VRFs of the uplink services list and downlink services list to implement respective service chains for uplink packets destined for a packet data network (or “PDN,” e.g., the Internet) and for downlink packets destined for a subscriber (for instance) and received from the PDN. By enabling the service control gateway to orchestrate and stitch together different combinations of services dynamically from an ordered list of services, the techniques may facilitate dynamic service chaining by a services gateways.

In one example, a method comprises receiving, by a service control gateway, a services list comprising an ordered list of services, the ordered list of services specifying at least a first service and a second service. The method also comprises receiving, by the service control gateway, a packet of a packet flow from a first service node that has applied the first service to the packet. The method also comprises sending, by the service control gateway based at least on the ordered list of services, the packet to a second service node that applies the second service.

In another example, network device comprises a control unit having at least one processor coupled to a memory, wherein the control unit is configured to receive a services list comprising an ordered list of services, the ordered list of services specifying at least a first service and a second service. The network device also comprises a forwarding unit coupled to the control unit and configured to receive a packet of a packet flow from a first service node that has applied the first service to the packet, wherein the forwarding unit is configured to send, based at least on the ordered list of services, the packet to a second service node that applies the second service.

In another example, a non-transitory computer-readable storage medium comprising instructions for causing one or more programmable processors of a network device to configure, by a gateway coupled to a plurality of service nodes by respective virtual private networks (VPNs), a separate input virtual routing and forwarding table (VRF) and output VRF for each of the VPNs; receive, by the gateway, an ordered list specifying a service chain for processing packets of a packet flow through an ordered set of the service nodes, wherein the ordered list specifies the service chain as sequences of the input VRFs and the output VRFs for the VPNs associated with the service nodes; and send and receive, by the gateway, packets of the packet flow in accordance with the specified sequences of the input VRFs and the output VRFs to forward packets along the service chain.

In another example, a system comprises a first service node configured to apply a first service; a second service node configured to apply a second service; and a network device comprising at least one processor coupled to a memory, wherein the network device is configured to receive a services list comprising an ordered list of services, the ordered list of services specifying at least a first service and a second service, wherein the network device is configured to receive a packet of a packet flow from the first service node that has applied the first service to the packet, wherein the network device is configured to send, based at least on the ordered list of services, the packet to the second service node configured to apply the second service.

Like reference characters denote like elements throughout the figures and text.

DETAILED DESCRIPTION

FIG. 1illustrates an example network system in accordance with techniques described herein. The example network system ofFIG. 1includes a service provider network2that operates as a private network to provide packet-based network services to subscriber devices16A-16N (collectively, “subscriber devices16”). That is, service provider network2provides authentication and establishment of network access for subscriber devices16such that the subscriber device may begin exchanging data packets with PDN12, which may represent an internal packet-based network of the service provider or an external packet-based network such as the Internet.

In the example ofFIG. 1, service provider network2includes access network6(“access network6”) that provides connectivity to packet data network (PDN)12via service provider core network7including gateway8. Service provider core network7and PDN12provide packet-based services that are available for request and use by subscriber devices16. As examples, core network7and/or PDN12may provide, for example, bulk data delivery, voice over Internet protocol (VoIP), Internet Protocol television (IPTV), Short Messaging Service (SMS), Wireless Application Protocol (WAP) service, or customer-specific application services. Packet data network12may comprise, for instance, a local area network (LAN), a wide area network (WAN), the Internet, a virtual LAN (VLAN), an enterprise LAN, a layer 3 virtual private network (L3VPN), an Internet Protocol (IP) intranet operated by the service provider that operates access network6, an enterprise IP network, or some combination thereof. In various embodiments, PDN12is connected to a public WAN, the Internet, or to other networks. Packet data network12executes one or more packet data protocols (PDPs), such as IP (IPv4 and/or IPv6), X.25 or Point-to-Point Protocol (PPP), to enable packet-based transport of PDN12services.

Subscriber devices16connect to gateway8via access network6to receive connectivity to subscriber services for applications hosted by subscriber devices16. A subscriber may represent, for instance, an enterprise, a residential subscriber, or a mobile subscriber. Subscriber devices16may be, for example, personal computers, laptop computers or other types of computing device associated with subscribers. In addition, subscriber devices16may comprise mobile devices that access the data services of service provider network2via radio access network (RAN)4. Example mobile subscriber devices include mobile telephones, laptop or desktop computers having, e.g., a 3G wireless card, wireless-capable netbooks, video game devices, pagers, smart phones, personal data assistants (PDAs) or the like. Each of subscriber devices16may run a variety of software applications, such as word processing and other office support software, web browsing software, software to support voice calls, video games, videoconferencing, and email, among others. Subscriber devices16connect to access network6via access links that comprise wired and/or wireless communication links. The term “communication link,” as used herein, comprises any form of transport medium, wired or wireless, and can include intermediate nodes such as network devices. Each of access links may comprise, for instance, aspects of an asymmetric DSL network, WiMAX, a T-1 line, an Integrated Service Digital Network (ISDN), wired Ethernet, or a cellular radio link.

A network service provider operates, or in some cases leases, elements of access network6to provide packet transport between subscriber devices16and gateway8. Access network6represents a network that aggregates data traffic from one or more subscribers for transport to/from service provider core network7of the service provider. Access network6includes network nodes that execute communication protocols to transport control and user data to facilitate communication between subscriber devices16and gateway8. Access network6may include a broadband access network, network, a wireless LAN, a public switched telephone network (PSTN), or other type of access network, and may include or otherwise provide connectivity for cellular access networks, such as radio access network (RAN)4ofFIG. 1. Examples of access network6may also include networks conforming to a Universal Mobile Telecommunications System (UMTS) architecture, an evolution of UMTS referred to as Long Term Evolution (LTE), mobile IP standardized by the Internet Engineering Task Force (IETF), as well as other standards proposed by the 3rdGeneration Partnership Project (3GPP), 3rdGeneration Partnership Project 2 (3GGP/2) and the Worldwide Interoperability for Microwave Access (WiMAX) forum.

Service provider core network7(hereinafter, “core network7”) offers packet-based connectivity to subscriber devices16attached to access network6for accessing PDN12. Core network7may represent a public network that is owned and operated by a service provider to interconnect a plurality of networks, which may include access network6. Core network7may implement Multi-Protocol Label Switching (MPLS) forwarding and in such instances may be referred to as an MPLS network or MPLS backbone. In some instances, core network7represents a plurality of interconnected autonomous systems, such as the Internet, that offers services from one or more service providers. PDN12may represent an edge network coupled to core network7, e.g., by a customer edge device such as customer edge switch or router. PDN12may include a data center.

In examples of network2that include a wireline/broadband access network, gateway8may represent a Broadband Network Gateway (BNG), a Broadband Remote Access Server (BRAS), MPLS Provider Edge (PE) router, core router or gateway, or a Cable Modem Termination System (CMTS), for instance. In examples of network2that include a cellular access network as access network6, gateway8may represent a mobile gateway, for example, a Gateway General Packet Radio Service (GPRS) Serving Node (GGSN), an Access Gateway (aGW), or a Packet Data Network (PDN) Gateway (PGW). In other examples, the functionality described with respect to gateway8may be implemented in a switch, service card or other network element or component. Core network7may provide access to multiple different access networks6conforming to different access types both wireline and wireless, e.g., cellular/GPRS/UMTS, broadband or other wireline, and so forth.

A network service provider that administers at least parts of network2typically offers services to subscribers associated with devices, e.g., subscriber devices16, which access the service provider network. Services offered may include, for example, traditional Internet access, Voice-over-Internet Protocol (VoIP), video and multimedia services, and security services. As described above with respect to access network6, core network7may support multiple types of access network infrastructures that connect to service provider network access gateways to provide access to the offered services. In some instances, network system2may include subscriber devices16that attach to multiple different access networks6having varying architectures.

In general, any one or more of subscriber devices16may request authorization and data services by sending a session request to gateway8. In turn, gateway8typically accesses Authentication, Authorization and Accounting (AAA) server11to authenticate the subscriber device requesting network access. Once authenticated, any of subscriber devices16may send subscriber data traffic toward service provider core network7in order to access and receive services provided by PDN12, and such packets traverse gateway8as part of at least one packet flow. Flows27illustrated inFIG. 1represent one or more upstream or “uplink” packet flows from any one or more subscriber devices16and directed to PDN12via gateway8, which is a next hop for PDN12for traffic from subscribers. Downstream or “downlink” flows originated by PDN12are directed to subscriber devices16(not shown inFIG. 1).

The term “packet flow,” “traffic flow,” or simply “flow” refers to a set of packets originating from a particular source device and sent to a particular destination device. Service traffic may include multiple different flows. A single flow of packets, in either the upstream (sourced by one of subscriber devices16) or downstream (destined for one of subscriber devices16) direction, may be identified by the 5-tuple: <source network address, destination network address, source port, destination port, protocol>, for example. This 5-tuple generally identifies a packet flow to which a received packet corresponds. An n-tuple refers to any n items drawn from the 5-tuple. For example, a 2-tuple for a packet may refer to the combination of <source network address, destination network address> or <source network address, source port> for the packet. Moreover, a subscriber device may originate multiple packet flows upon authenticating to service provider network2and establishing a communication session for receiving data services.

As described herein, service provider network2includes a services complex9having a cluster of service nodes10A-10B (collectively, “service nodes10”) that provide an execution environment for corresponding network services. That is, each of service nodes10apply one or more services. As examples, service nodes10may apply firewall and security services, carrier grade network address translation (CG-NAT), media optimization (voice/video), IPSec/VPN services, deep packet inspection (DPI), HTTP filtering, parental control, caching and content delivery services, web awareness/applications, counting, accounting, charging, and load balancing of packet flows or other types of services applied to network traffic. Each of service nodes10in this way represents a service instance. Although illustrated with only two service nodes10, services complex9may include many thousands of such service nodes10each providing one or more services to data traffic.

Each of service nodes10may alternatively be referred to as a “service point,” “value-added service (VAS) point” or node, or “network function virtualization (NFV) node.” Network function virtualization involves orchestration and management of networking functions such as a Firewalls, Intrusion Detection or Preventions Systems (IDS/IPS), Deep Packet Inspection (DPI), caching, Wide Area Network (WAN) optimization, etc. in virtual machines instead of on physical hardware appliances. Network function virtualization in the service provider network may provide Value Added Services (VAS) for edge networks such as business edge networks, broadband subscriber management edge networks, and mobile edge networks. Access network6ofFIG. 1is an example of an edge network for service provider network2ofFIG. 1.

Service control gateway20operates as a gateway for the services complex9to anchor the delivery of dynamic service selection and application to packet flows. Service control gateway20may perform traffic detection, policy enforcement, and service steering according to techniques described herein. Service control gateway20may provide subscriber-aware, device-aware, and/or application-aware traffic detection and granular traffic steering functionality with policy interfaces. Service control gateway20may include integrated L4-L7 deep packet inspection (DPI), for instance. Service control gateway20may in some cases be combined with other embedded networking functions (such as carrier-grade NAT and firewall/load balancer) to consolidate components of the services complex9into a single network element.

Service control gateway20may represent is a physical gateway router or switch that connects virtual networks of the services complex9to physical networks such core network9, the Internet, a customer VPN (e.g., L3VPN), another data center, or to non-virtualized servers. In such examples, services complex9may include layer two (L2) and layer three (L3) switching and routing components that provide point-to-point connectivity between servers (not shown) that execute one or more of service nodes10within a virtual environment. That is, one or more of service nodes10may run as virtual machines in a virtual compute environment. Moreover, the compute environment may comprise a scalable cluster of general computing devices, such as x86 processor-based servers. As another example, service nodes10may comprise a combination of general purpose computing devices and special purpose appliances. In some examples, service control gateway20represents a server, process, virtual machine, or controller executing within services complex9.

As virtualized, individual network services provided by service nodes10can scale just as in a modern data center, through the allocation of virtualized memory, processor utilization, storage and network policies, as well as horizontally by adding additional load-balanced virtual machines. In one example, services complex9comprises a set of interconnected, high-performance yet off-the-shelf packet-based routers and switches that implement industry standard protocols. In one example, services complex9may comprise off-the-shelf components that provide Internet Protocol (IP) over an Ethernet (IPoE) point-to-point connectivity.

In the illustrated example, a software-defined networking (SDN) controller19may provide a high-level controller for configuring and managing routing and switching infrastructure of service provider network2(e.g., gateway8, service control gateway20, core network7and service nodes10). The SDN controller19provides a logically and in some cases physically centralized controller for facilitating operation of one or more virtual networks within services complex. In some instances, the SDN controller19manages deployment of virtual machines within the operating environment of value-added services complex9. The SDN controller19communicates with service control gateway20to specify information for implementing service chain25, such as virtual routing and forwarding instances configuration. Service chain information provided by an SDN controller19may specify any combination and ordering of value-added services provided by service nodes10, traffic engineering information (e.g., labels or next hops) for tunneling or otherwise transporting (e.g., MPLS or IP tunnels) packet flows along service paths, rate limits, Type Of Service (TOS) markings or packet classifiers that specify criteria for matching packet flows to a service chain. Additional information regarding a SDN controller operating as a virtual network controller in conjunction with other devices of services complex9or other software-defined network is found in International Application Number PCT/US2013/044378, filed Jun. 5, 2013, and entitled PHYSICAL PATH DETERMINATION FOR VIRTUAL NETWORK PACKET FLOWS, which is incorporated by reference as if fully set forth herein.

In accordance with techniques described herein and as shown inFIG. 1, service control gateway20receives flows27from gateway8via link21(which may represent one or more physical links or networks) and steers individual subscriber packet flows27through dynamically provisioned and ordered lists of services provided by service nodes10. That is, each subscriber packet flow may be forwarded through a particular ordered combination of services provided by service nodes10, each ordered set being referred to herein as a “service chain.” Gateway8may direct flows27to service control gateway20via an access virtual private network (VPN) routing and forwarding table (VRF) configured in gateway8and service control gateway20.

In the example ofFIG. 1, one or more uplink subscriber packet flows27are directed along a service chain25from service control gateway20, to service node10A, to service control gateway20, to service node10B, to service control gateway20. Service chain25having been applied to flows27, service control gateway20forwards the flows27according to the default routing table, e.g., to return flows27to gateway8(in the illustrated example) or to bypass gateway8to forward the flows27directly to PDN12. In this way, subscriber flows27may be processed by service control gateway20and service nodes10as the packets flow between access network6and PDN12according to service chains configured by the service provider. A particular node10may support multiple service chains.

Whereas a “service chain” defines one or more services to be applied in a particular order to provide a composite service for application to packet flows bound to the service chain, a “service tunnel” or “service path” refers to a logical and/or physical path taken by packet flows processed by a service chain along with the forwarding state for forwarding packet flows according to the service chain ordering. Each service chain may be associated with a respective service tunnel, and packet flows associated with each subscriber device16flow along service tunnels in accordance with a service profile associated with the respective subscriber. The arrows denoted as service chain25illustrate the path taken by packet flows mapped to the service chain25by service control gateway. For example, a given subscriber may be associated with a particular service profile, which in turn is mapped to service chain25. Similarly, another subscriber may be associated with a different service profile, which in turn is mapped to a service tunnel associated with service chain. Service control gateway20, in some instances after authenticating and establishing access sessions for the subscribers, may direct packet flows for the subscribers along the appropriate service tunnels, thereby causing service complex9to apply the requisite ordered services for the given subscriber. In various examples, service control gateway20may apply steer traffic to, e.g., service chain25, based on DPI-based traffic detection, subscriber or device policies, or other basis.

Service nodes10may cooperate with service control gateway20to implement service chain25using internally configured forwarding state that directs packets of the packet flow along the service chain25for processing according to the identified set of service nodes10. Such forwarding state may specify tunnel interfaces for tunneling between service nodes10and service control gateway20using network tunnels such as Internet Protocol (IP) or Generic Route Encapsulation (GRE) tunnels, or by using Virtual Local Area Networks (VLANs), Multiprotocol Label Switching (MPLS) techniques, and so forth. In some instances, real or virtual switches, routers or other network elements that interconnect connect service nodes10may be configured to direct packet flows to the service nodes10and service control gateway20according to service chain25. One or more tunnel endpoints for a service chain25may each be associated with a different virtual private network overlaying a physical underlay network. Such a tunnel endpoint may be logically located and implemented by a network element that has a routing instance (e.g. a VRF) for the virtual private network for the tunnel endpoint. Such a network element, whether physical or virtual, may be considered and alternatively referred to as a provider edge (PE) router for the virtual private network for the tunnel endpoint. A network element may be a PE router for multiple virtual private networks. In some examples, network system2implements VPNs using techniques described in Rosen & Rekhter, Request for Comments 4364, February 2006, Internet Engineering Task Force (IETF) Network Working Group, the entire contents of which is incorporated by reference herein.

Service provider network2may include an Authentication, Authorization and Accounting server11(“AAA server11). For example, upon detecting a new traffic flow, service control gateway20may authenticate new subscribers to AAA server11, e.g., by way of the Radius or Diameter protocols, and, at this time, receive a service profile or other information that defines the services to be applied to the subscriber or maps the various traffic expected for the subscriber to one or more service flows. Upon detecting a new flow, the service control gateway20selects the service chain for the flow based on the service profile and traffic type. For example, service control gateway20selects one of the service chains for the packet based on the service profile received for the subscriber and/or based on the type of traffic, e.g., HTTP traffic or VoIP traffic.

In accordance with techniques described herein, SDN controller19provisions components of service provider network2with forwarding information to enable service control gateway20and services nodes20to direct the components to forward traffic along service chain25. In the illustrated example, SDN controller19provisions service control gateway20with at least four VRFs: VRF1_IN26A, VRF1_OUT26B, VRF2_IN28A, and VRF2_OUT28B. Service control gateway20includes VRFs26,28having respective routing instances that include interfaces for service nodes10A and10B. Service control gateway20may also include at least one access routing and forwarding instance for exchanging traffic with gateway8. SDN controller19may communicate with service control gateway20to manipulate route targets and provision service node10servers and/or advertise routes within the virtual and/or physical networks. In some examples, an operator may configure IP-VPNs within service control gateway20to establish VRFs26,28.

Each of service nodes10is associated with two VRFs at service control gateway20, an in-VRF for service traffic toward the service node, and an out-VRF for service traffic from the service node. In the example ofFIG. 1, service node10A is associated with in-VRF VRF1_IN26A and with out-VRF VRF_OUT26B (collectively, “VRFs26”). Service node10A is configured to apply a service to service traffic received from service control gateway20via VRF_IN26A and to return the service traffic to the service control gateway20via VRF_OUT26B. Each of VRFs26,28configured in service control gateway20may include at least one virtual interface, such as an attachment circuit, by which service control gateway20may identify VRFs26,28with which to process incoming service traffic. Service node10B is associated with in-VRF VRF2_IN28A and with out-VRF VRF_OUT28B (collectively, “VRFs28”). Service node10B is configured to apply a service to service traffic received from service control gateway20via VRF_IN28A and to return the service traffic to the service control gateway20via VRF_OUT28B.

VRF1_IN26A sends and VRF1_OUT26B receives packets exchanged between service control gateway20and service node10A. VRF2_IN28A sends and VRF2_OUT28B receives packets exchanged between service control gateway20and service node10B.

In some examples, SDN controller19automatically configures virtual private networks to establish a virtual network topology for service nodes10to direct service traffic received from service control gateway20back to service control gateway20. In some examples, service nodes10and service control gateway20may be configured with IP-VPNs to establish respective point-to-point service topologies for the service nodes10and service control gateway20.

In accordance with techniques described in this disclosure, policy control server14dynamically provisions service control gateway20with an ordered list of services for flows27to cause the service control gateway20to steer flows27along a service chain defined by the ordered list of services and the service nodes10corresponding to the services. In other words, service control gateway20orchestrates traversal of the ordered list of services (applied and represented by service nodes10), specified by services list17, by flows27and, in this way, dynamically stitches together service chain25made up of the ordered list of services for application of services to matching traffic.

In one example, policy control server14implements a policy interface (e.g., Diameter or Remote Authentication Dial-In User Service (RADIUS) to send services list17to service control gateway20. Services list17includes an ordered list of services for service chain25for flows27.

For instance, policy control server14may represent a Policy Control and Charging Rules Function (PCRF) device for mobile (e.g., 3GPP) subscriber devices16or, alternatively or in addition, a Broadband Policy Control Framework (BPCF) device for broadband/wireline subscriber devices16. Accordingly, service control gateway20may in some cases implement a Policy Charging and Enforcement Function (PCEF) for any or both of the above functions, or for another function. Policy control server14and service control gateway20may communicate according to a Gx reference point that defines a protocol for signaling of policy and charging control (PCC) rules that determine treatment of matching service data flows in a Policy and Charging Enforcement Function. A PCC rule includes a rule identifier that uniquely identifies the rule within a subscriber session, service data flow detection information, charging information, and/or policy control information.

Policy control server14may install the new (and/or modified) PCC rules for service sessions to service control gateway using PCC rule installation messages sent over the Gx reference point between policy control server14(operating at least in part as a PCRF/BPCF) and service control gateway (operating at least in part as a PCEF). The Gx interface may include a protocol stack that includes, for example, Remote Authentication Dial-In User Service (RADIUS) or Diameter. Accordingly, PCC rule installation messages may include a Charging-Rule-Install attribute-value pair (AVP) that specifies a Charging-Rule-Definition AVP. A PCC rule installation message for a PCC rule may further include services list17for dynamically defining a service chain for service data flows that match the PCC rule (flows27inFIG. 1). PCC rules installed to service control gateway20by policy control server14may be static or dynamic (e.g., static Gx or dynamic Gx). The PCC rule installation message may represent a Diameter Credit Control Answer (CCA) that includes services list17as, e.g., one or more AVPs. The Diameter CCA may be responsive to an earlier Diameter Credit Control Request (CCR) (initial or update) issued by service control gateway, e.g., in response to detecting a new application or a new subscriber, or receiving a RADIUS Accounting Request message from gateway8for a new application or a new subscriber.

Upon receiving a new or modified PCC rule and associated services list17included in a PCC rule installation message, service control gateway20applies the ADC rule to traffic received from gateway8to identify packet flows that match the ADC rule. The service control gateway20steers matching packet flows along a service chain that includes the service of service nodes10defined by the services list17associated with the PCC rule.

In some cases, service control gateway20implements a traffic detection function (TDF) to perform application traffic detection and dynamic steering of matching application traffic along a service chain according to techniques described herein. In such cases, service control gateway20receives rules from policy control server14(operating as a PCRF/BPCF) that are known as Application Detection and Control (ADC) rules, which policy control server14may provide and activate by an Sd reference point. Service control gateway20may in some examples apply, to detected application traffic, enforcement actions such as gating, redirection, and bandwidth limiting.

Policy control server14may generate ADC rules in association with an ordered list of services, in accordance with techniques described herein. For instance, policy control server14may generate an ADC rule for a Traffic Detection Function (TDF) session for a subscriber session for one of subscriber devices16. The generated ADC rule may include a rule identifier, TDF application identifier, monitoring key, gateway status, uplink/downlink maximum bit rates (MBRs), and redirection information. Policy control server14additionally generates the services list17that specifies the ordered list of services to be applied to application traffic that match the generated ADC rule (flows27inFIG. 1).

Policy control server14installs the ADC rule to service control gateway20, via an Sd interface, using an ADC installation message instance. The Sd interface may include a protocol stack that includes, for example, RADIUS or Diameter. The ADC rule installation message may thus include an ADC-Rule-Install AVP, for instance. The ADC rule installation message may further include the services list17in association with the ADC rule. ADC rules installed to service control gateway20by policy control server14may be static or dynamic (e.g., static Sd or dynamic Sd).

Upon receiving an ADC rule and associated services list17included in an ADC rule installation message, service control gateway20applies the ADC rule to traffic received from gateway8to identify flows27that match the ADC rule. The service control gateway20steers matching flows27along a service chain25that includes the service nodes10defined by the services list17associated with the ADC rule.

The ordered list of services may be bifurcated into an uplink ordered list (“uplink service list) of virtual routing and forwarding table (VRFs) of the service control gateway and a downlink ordered list (“downlink service list) of VRFs of the service control gateway. Each VRF of the uplink ordered list may represent a start point of a corresponding service in a service chain, and each VRF of the downlink ordered list may represent an end point of the corresponding service in the service chain. The service control gateway20stitches together VRFs of the uplink ordered list and downlink ordered list to implement respective service chains for uplink packets issued by a subscriber and destined for PDN12and for downlink packets destined for the subscriber and received from PDN12.

In this example ofFIG. 1, services list17may include an uplink ordered list specifying, in order, VRF1_IN26A and VRF2_IN28A; services list17also includes a downlink ordered list specifying, in order, VRF1_OUT26B and VRF2_OUT28B. Service control gateway20stitches together the combination of service nodes10based on services list17including the uplink ordered list and downlink ordered list, as described in example detail below. In this way, the techniques may facilitate dynamic service chaining by service provider network2. The techniques may thus provide the service control gateway20, and the administrator/operator thereof, with the capability to dynamically orchestrate any combination of services, provided by service nodes10, from a list of services and create service chains by stitching together the combinations. This may provide advantages over statically provisioned service chains by, e.g., enabling dynamic modification of the service chain for a packet flow27by the policy control server14and thus modify the ordering, type, and/or number of services applied to packets of the packet flow27.

FIG. 2is block diagram illustrating, in further detail, an example network device according to techniques described in this disclosure. Network device40may represent an example instance of service control gateway20ofFIG. 1. Network device40includes a control unit50coupled to one or more network interface card(s)52(“NICs52”), which transmit and receive packet data via one or more communication links. Control unit50includes at least one processor53that executes software instructions, such as those used to define a software or computer program, stored to a tangible computer-readable medium (not shown inFIG. 2), such as a storage device (e.g., a disk drive, or an optical drive), or memory (such as Flash memory, random access memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause a programmable processor to perform the techniques described herein. Alternatively, or in addition, control unit50may comprise dedicated hardware, such as one or more integrated circuits, one or more Application Specific Integrated Circuits (ASICs), one or more Application Specific Special Processors (ASSPs), one or more Field Programmable Gate Arrays (FPGAs), or any combination of one or more of the foregoing examples of dedicated hardware.

Control unit50configures forwarding unit54with VRFs by which network device40exchanges service traffic with a plurality of service nodes10. Forwarding unit54includes two separate VRFs for communicating with each service node of service nodes10, an “in” VRF having an outgoing interface (OIF) for sending service traffic to the service node, and an “out” VRF having an incoming interface (IIF) for receiving service traffic from the service node. Forwarding unit54may represent a module executed by processor53or a separate forwarding unit, such as one or more line cards having packet processors for high-speed packet processing a coupled to control unit50. Reference herein to incoming and outgoing interfaces may refer to virtual or software interfaces configured in the device.

In the illustrated example, forwarding unit54is configured with SVC-VRF-1-IN64A having OIF66A and SVC-VRF-1-OUT64B having IIF66B. OIF66A is an interface to an attachment circuit68A for SVC-VRF-1-IN64A and by which forwarding unit54can send service traffic to service node10A. IIF66B is an interface to an attachment circuit68B for SVC-VRF-1-OUT64B and by which forwarding unit54can receive service traffic from service node10A. Forwarding unit54is also configured with SVC-VRF-2-IN70A having OIF72A and SVC-VRF-2-OUT70B having IIF72B. OIF72A is an interface to an attachment circuit74A for SVC-VRF-2-IN70A and by which forwarding unit54can send service traffic to service node10B. IIF72B is an interface to an attachment circuit74B for SVC-VRF-2-OUT70B and by which forwarding unit54can receive service traffic from service node10B. VRFs64,70may alternatively be referred to as “service VRFs” in that they are usable by network device40for exchanging traffic with service nodes10. Attachment circuits68,74may alternatively be referred to as “VRF attachment circuits.”

Each of attachment circuits68,74may represent a physical and/or virtual circuit attaching a service node10to one of VRFs64,70and may be, for example, a Frame Relay data link connection identifier, an asynchronous transfer mode (ATM) Virtual Path Identifier (VPI)/Virtual Channel Identifier (VCI), an Ethernet port, a VLAN, a Point-to-Point Protocol (PPP) connection on a physical interface, a PPP session from an L2 Tunneling Protocol (L2TP) tunnel, or a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP), a Generic Route Encapsulation (GRE) tunnel, or another interface with bridged encapsulation. Attachment circuits68,74may each comprise a direct link or an access network. In at least some examples, packets transported via attachment circuit68,74include respective MPLS labels identifying the attachment circuit and the associated VRF, in accordance with RFC 4364.

Forwarding unit54is further configured with services list60specifying an ordered list of services62A-62B that defines a set of service nodes10as a service chain for application to at least one packet flow received by network device40. Services list60specifies the services as a list of respective VRF names that identify VRFs64,70with which network device40exchanges services traffic with the corresponding service nodes10. Service62A specifies “SVC-VRF-1” identifying VRFs64for exchanging service traffic with service node10A, and service62B specifies “SVC-VRF-2” identifying VRFs70for exchanging service traffic with service node10B. In this way, forwarding unit54is configured to stitch together a service chain made from service node10A to service node10B. Services62may identify VRFs using strings, as in the example ofFIG. 2, or by another means.

Network device40receives packets for packet flow80and directs the packets along the service chain defined by services list60. Forwarding unit54includes lookup module56, which is configured to determine a next service62in the ordered services list60for application to service traffic based on the VRF with which the network device40receives the traffic.

In the illustrated example, after directing packets of packet flow80toward service node10A via OIF66A for attachment circuit68A for application of at least one service by service node10A, forwarding unit54receives the packets from service node10A via IIF66B for attachment circuit68B. IIF66B is associated with SVC-VRF-1-OUT. Based on an identifier for IIF66B, such as an index value or string, lookup module56determines service62B is the next service for the packets of packet flow80according to the ordering of the services list60. In other words, because IIF66B is associated with SVC-VRF-1-OUT64B for “SVC-VRF-1” of service62A and associated packets received with IIF66B (and attachment circuit68A) with SVC-VRF-1-OUT64B, lookup module56is configured to determine, based on IIF66B, the next service to applied after service62A, i.e., service62B.

Accordingly and because attachment circuits68B,74A are both located on network device40and associated with respective VRFs SVC-VRF-1-OUT64B, SVC-VRF-2-IN70A, forwarding unit54forwards packets of packet flow80received on IIF66B using SVC-VRF-2-IN70A, which is configured to forwards the packets of packet flow80via OIF72A for attachment circuit74A to service node10B. The forwarding unit54thus identifies the VRF name from the IIF (associated with received packets as a packet property and in some cases included in the switch fabric header) on which the packet arrives and steers to the next VRF name index of the service chain list defined by services list60. In this way, network device40is configured to steer service traffic to service nodes10according to a service chain defined by services list60.

FIG. 3is a block diagram illustrating, in detail, components of an example network device that dynamically stitches a service chain defined by an ordered list of services according to techniques described herein. Network device100illustrated inFIG. 3may represent an example instance of service control gateway20ofFIG. 1or network device40ofFIG. 2.

In this example, control unit140includes a combination of hardware and software that provides a control plane108operating environment for execution of various user-level host processes166A-166L (collectively, “host processes166”) executing in user space141. By way of example, host processes166may include a command-line interface and/or graphical user interface process166L to receive and respond to administrative directives in accordance with one or more of protocols153, a routing process166A to execute one or more routing protocols of protocols153including Multiprotocol Border Gateway Protocol (MP-BGP)153A, a policy process to execute one or more policy interface protocols of protocols153such as RADIUS153K, and so forth. Control unit140may provide routing plane, service plane, and management plane functionality for network device100.

Host processes166execute on and interact with kernel143, which provides a run-time operating environment for user-level processes. Kernel143may represent, for example, a UNIX operating system derivative such as Linux or Berkeley Software Distribution (BSD). Kernel143offers libraries and drivers by which host processes166may interact with the underlying system. Hardware environment150of control unit140includes microprocessor152that executes program instructions loaded into a main memory (not shown inFIG. 3) from a storage device (also not shown inFIG. 3) in order to execute the software stack, including both kernel143and user space141, of control unit140. Microprocessor152may represent one or more general- or special-purpose processors such as a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or any other equivalent logic device. Accordingly, the terms “processor” or “controller,” as used herein, may refer to any one or more of the foregoing structures or any other structure operable to perform techniques described herein.

In this example, routing process166A executes one or more interior and/or exterior routing protocols, including MP-BGP153A, to exchange routing information with other network devices and store received routing information in routing information base145(“RIB145”). RIB145may include information defining a topology of a network, including one or more routing tables, link-state databases, and/or traffic engineering databases. RIB145includes multiple VPN tables180A-180M for corresponding VRFs configured for network device100. The VRFs may define service topologies for multiple different service nodes, as described above with respect toFIGS. 1-2.

Routing process166A resolves the topology defined by routing information in RIB145to select or determine one or more active routes through the network and then installs these routes to forwarding information base142(“FIB142”), which is stored by kernel143that is responsible for synchronizing the FIB142(the master copy of the network device100FIB) with FIBs148A-148N on respective forwarding units125A-125N. In some cases, FIB142includes a separate FIB copy corresponding to each of FIBs148A-18N. FIB142may alternatively be referred to as a “software FIB” or “kernel FIB,” for the FIB142is managed by software components of the control plane, including kernel143. Each of FIBs148A-148N may alternatively referred to as a “hardware FIB,” in that it is stored to memory accessible to a hardware-based packet processor159A.

In some cases, FIB142may be generated and managed by user space processes, e.g., routing process166A and policy process166L, which may communicate forwarding structures to kernel143by a socket or other communication channel. Typically, processes66generates forwarding structures of FIB142to include radix or other lookup trees to map packet information (e.g., header information having destination information and/or a label stack) to other forwarding structures or to next hop devices and ultimately to interface ports of interface cards associated with respective forwarding units125A-125N. In addition to generating and providing lookup data structures such as the aforementioned radix or lookup tree, processes66may generate and provide next hop instructions for installation to FIB142and eventual provisioning to FIBs148A-148N.

Network device100also includes a plurality of forwarding units125A-125N (collectively, “forwarding units125”) and a switch fabric (not shown) that together provide the data (or “forwarding”) plane110for forwarding network traffic. Forwarding units125connect to control unit140in this example by communication links151, which may represent an Ethernet network.

Each of forwarding units125may include substantially similar components performing substantially similar functionality, said components and functionality being described hereinafter primarily with respect to forwarding unit125A illustrated in detail inFIG. 3. Forwarding unit125A receives and sends network packets via interfaces of interface cards (IFCs)126A,126B of forwarding unit125A. Forwarding unit125A also includes hardware-based packet processor159A and memory157A, which together represent hardware or a combination of hardware and software that provide high-speed forwarding of network traffic, as described in further detail below. Likewise, forwarding unit125B includes packet processor159B and memory157B, and so on. Each of forwarding units215includes an instance of forwarding unit processor162and interface163. Forwarding unit125A may include multiple packet processors159A that provide a distributed data plane110in cooperation with other packet processors159on other forwarding units125. In some examples, one or more of forwarding units125may each include at least one packet processor substantially similar to packet processor159. Example instances of forwarding unit125A may include flexible programmable integrated circuit (PIC) concentrators (FPCs), dense port concentrators (DPCs), and modular port concentrators (MPCs). In some instances, forwarding units125may or include represent line cards.

Each of IFCs126A,126B may include interfaces for various combinations of layer two (L2) technologies, including Ethernet, Gigabit Ethernet (GigE), and Synchronous Optical Networking (SONET) interfaces located on a PIC (not shown) of forwarding unit125A, for instance. In various aspects, each of forwarding units125may include more or fewer IFCs. In some examples, each of packet processors159is associated with different IFCs of the forwarding unit on which the forwarding component is located. The switch fabric (again, not shown) connecting forwarding units125provides a high-speed interconnect for forwarding incoming transit network packets to the selected one of forwarding units125for output over a network interface of an IFC126of the selected forwarding unit.

Network device100may in some instances represent a multi-chassis router, and the switch fabric may include a multi-stage switch fabric, such as a 3- or 5-stage Clos switch fabric, that relays packet-switched communications and circuit-switched communications between the routing nodes of the multi-chassis router via optical interconnects using multiplexed communications. An example multi-chassis router that employs optical interconnects using multiplexed communications is described in U.S. Pat. No. 8,050,559, entitled MULTI-CHASSIS ROUTER WITH MULTIPLEXED OPTICAL INTERCONNECTS, issued Nov. 1, 2011, the entire contents of which being incorporated by reference herein.

Forwarding units125A-125N of network device100demarcate control plane8and data plane10of network device100. That is, forwarding unit125A performs functions of both control plane108and data plane110. In general, packet processor159A and IFCs126A,126B implement data plane110for forwarding unit125A, while forwarding unit processor162(illustrated as “fwdg. unit processor162”) executes software that implements portions of control plane108within forwarding unit125A. Control unit140also implements portions of control plane108of network device100. Forwarding unit processor162of forwarding unit125A manages packet processor159A and executes instructions to provide an interface163to control unit140receive process inter-plane communications and handle host-bound or other local/exception network packets. Interface163may further provide an interface by which forwarding unit125A receives at least part of FIB142for installation to memory157A as FIB148A and maintains FIB148A. Forwarding unit processor162may represent a general- or special-purpose processor, microprocessor, or controller capable of executing instructions. Forwarding unit processor162may execute a microkernel for forwarding unit125A.

Memory157A of forwarding unit125A represents one or more computer-readable storage media, such as one or more instances of Random Access Memory (RAM), e.g., Static RAM (SRAM), Dynamic RAM (DRAM), and/or Reduced Latency DRAM (RLDRAM). In some examples, packet processor159A and memory157A may represent or include a Content Addressable Memory (CAM) such as Tertiary CAM (TCAM). Although illustrated as separate from packet processor159A, at least a portion of memory157A may in some cases be internal memory for the packet processor159A.

Memory157A stores FIB148A including VPN tables180′ and rules176′ received by interface163from control plane108. In the illustrated example, kernel143installs to memory157A at least a part of FIB142to FIB148A including VPN tables180′ and rules176′.

Packet processor159A may represent a packet-forwarding integrated circuit (IC), e.g., one or more programmable ASICs or ASIC-based packet processors, that processes network packets by performing a series of operations on each packet over respective internal packet forwarding paths as the packets traverse the internal architecture of network device100. Packet processor159A processes packets in accordance with next hop instructions. A next hop is a data structure stored to FIB148A that either contains the final result of packet processing for a packet or acts as a link to another lookup for the same packet.

Packet processor59A accesses next hops stored to FIB148A that, when executed, cause packet processor159A to examine the contents of each packet (or another packet property, e.g., incoming interface (IIF) on which the network device received the packet) and on that basis make forwarding decisions, apply filters, and/or perform accounting, management, traffic analysis, and load balancing, for example. In one example, packet processor159A stores next hops as next hop data chained together (or otherwise arranged) as a series of next hops along an internal packet forwarding path for the network device100. The result of packet processing determines the manner in which a packet is forwarded or otherwise processed by packet processors159from its input interface on one of forwarding units125to its output interface on one of forwarding units125(the same forwarding unit125may have both the input and output interface for a given packet). Additional details regarding next hops and an example forwarding architecture are described in U.S. Pat. No. 7,215,637, “Systems and methods for processing packets,” issued May 8, 2007; in PLATFORM-INDEPENDENT CONTROL PLANE AND LOWER-LEVEL DERIVATION OF FORWARDING STRUCTURES, U.S. application Ser. No. 12/266,298, filed Nov. 6, 2008; and in U.S. Pat. No. 8,806,058, issued Aug. 12, 2014, and entitled “PACKET FORWARDING PATH PROGRAMMING USING A HIGH-LEVEL DESCRIPTION LANGUAGE,” each of which being incorporated herein by reference in its entirety.

In accordance with techniques described herein, policy process166L receives a policy rule message167conforming to a policy protocol such as RADIUS153K or Diameter. Policy rule message167includes a policy rule that specifies packet flow definition data for identifying one or more packet flows and further includes a services list that specifies an ordered list of services to apply to the one or more packet flows that match the packet flow definition data. Packet flow definition data may include, e.g., a service data flow (SDF) filter or traffic flow template (TFT) filter. Packet flow definition data may identify flows according to subscriber, according to application, or by other criteria. Policy process166L stores the policy rule as one of policy rules176, which may include PCC/ADC rules, for instance, in association with the services list stored as service lists178. For instance, rule176A includes services list178A as the ordered list of services to apply to packet flow(s) matching the packet flow definition data for rule176A.

Processes166install representations of rules176including services lists178and VPN tables180to FIB142. Kernel143downloads the FIB142to the hardware FIBs148of forwarding units125. VPN tables180A′ may in some cases represent lookup trees (e.g. Radix trees) or lookup tables. Packet processors159of distributed forwarding units125process packets received on incoming interfaces and process the packets by determining, based on an incoming interface (e.g., an attachment circuit for a VRF/VPN table180), a next service in services list178′ for application to the packets. In response to determining the next service, the packet processors159forward the packets using the VPN table180A′ that is an “in” VRF for the next service. In this way, network device100is configured to steer service traffic to services according to service chains defined by services lists178dynamically provided by, e.g., a policy control server to network device100.

FIGS. 4A-4Bare block diagrams illustrating example services lists for defining a service chain according to techniques described herein. In these examples, lists of services are bifurcated into corresponding uplink service lists and a downlink service lists.FIG. 4Aillustrates uplink services list90and downlink services list92. Uplink services list90includes an ordered list of VRF names90A-90K that correspond to respective start points of services in a service chain. Downlink services list92includes an ordered list of VRF names92A-92K that correspond to respective end points of services in the service chain. For example, VRF name90A (“SVC-VRF-1-IN”) identifies a service VRF-in that includes an attachment circuit for sending service traffic to a service, and VRF name92A (“SVC-VRF-1-OUT”) identifies a service VRF-out that includes an attachment circuit for receiving service traffic from the same service (e.g., “service1”).

K is a variable for the number of services in the service chain. If K>4, uplink services list90and downlink services92will include additional services between90C,92C and90K,92K. The number of services may be any non-negative integer.

Uplink services list90may be a value portion of a Service-List-UpLink attribute-value pair (AVP) (or Vendor-Specific Attribute (VSA)) for communication via a policy protocol (e.g., RADIUS) on a policy interface (e.g., Sd or Gx). In such instances, the Service-List-Uplink AVP may be provisioned with an ordered list of VRF names configured on a service control gateway (or other network device) and representing the start point of each service in a service chain. This Service-List-Uplink AVP may be provisioned per rule in the service control gateway or other network device operating according to techniques described herein, via PCRF dynamic Gx or Static Gx policy type, or using another policy protocol and interface (e.g., ADC and Sd).

Downlink services list92may be a value portion of a Service-List-DownLink AVP or VSA for communication via a policy protocol on a policy interface. In such instances, the Service-List-Downlink AVP may be provisioned with an ordered list of VRF names configured on a service control gateway (or other network device) and representing the end point of each service in a service chain. This Service-List-DownLink AVP may be provisioned per rule in a service control gateway or other network device operating according to techniques described herein, via PCRF dynamic Gx or Static Gx policy type, or using another policy protocol and interface (e.g., ADC and Sd).

A subscriber created on a service control gateway will associate the uplink services list90and downlink services list92in the action for the rule (e.g. PCC-action for a PCC rule) to steer the traffic towards the VRF names in the order received. The data traffic will be steered into the first VRF provisioned in the Service-List and upon return from the first service into the second VRF in the service-list and so on till all the service in the service-list are exhausted in the uplink and downlink directions corresponding to the uplink services list90and downlink services list92, respectively. The service control gateway may identify the VRF name from the ingress iif on which the packet arrives and steer to next VRF name index of the service chain list. The iif is a packet property may be included in a fabric header for a packet/cell received by the service control gateway.

In the example ofFIG. 4A, in the uplink direction (e.g., from subscriber devices or toward a PDN), uplink packets ingressing from SVC-VRF-1-OUT (92A) at the service control gateway will be steered to SVC-VRF-2-IN (90B) and uplink packets ingressing at SVC-VRF-2-OUT (92B) will be steered to SVC-VRF-2-IN (90C), and so on until service control gateway forwards uplink packets ingressing at SVC-VRF-K-OUT (92K) using the default routing table.

In the downlink direction (e.g., toward subscriber devices or away from a PDN), downlink packets ingressing at SVC-VRF-K-OUT (92K) will be steered to SVC-VRF-3-IN (90C) and downlink packets ingressing at SVC-VRF-3-OUT (92C) will be steered to SVC-VRF-2-IN (90B), and so on until service control gateway forwards downlink packets ingressing at SVC-VRF-1-OUT (92A) using the default routing table (or “default VRF”).

A service control gateway may determine whether a packet is an uplink packet or a downlink packet based on a destination network address of the packet and routes installed to the VRFs that specify different actions for packets having different destination network addresses.

Subsequent to the service control gateway (or other network device) being provisioned with a rule that is associated with uplink services list90and downlink services list92, a policy control server may dynamically modify the rule to provision the service control gateway with a modified uplink services list90′ and a modified downlink services list92′ for a modified services list, as illustrated inFIG. 4B. The modified services list is pared to include two services in this example. In other examples, services lists may be dynamically modified by the policy control server to modify the services applied, modify the order of the services, add or remove services, and so forth.

Service control gateway receives and installs the modified rule including the modified uplink services list90′ and a modified downlink services list92′ and steers traffic that matches the rule according to the modified service chain defined by the modified uplink services list90′ and a modified downlink services list92′. Using these techniques, a policy control server or other administrative entity or device may dynamically control the services applied to subscriber and/or application traffic, including by modifying the services applied while a subscriber session or application is in progress.

FIGS. 5A-5Bare block diagrams illustrating example internal packet processing paths executable by a packet processor for dynamic service chaining according to techniques described herein. Internal packet processing path204includes forwarding lookup structures and next hop instructions and may be defined within one or more hardware FIBs of one or more forwarding units of a network device, such as FIBs148of forwarding units125ofFIG. 3.

As illustrated inFIG. 5A, a packet processor executes packet processing path204to match packets of a packet flow210to rule176A of rules176, and to steer the matching packets along a service chain that is (1) dynamically provisioned within the network device with uplink services list90and downlink services list92, and (2) implemented in a hardware FIB by a combination of lookup data structures and next hop instructions. Specifically, path204includes lookup table220that keys to IIFs of received packets (the IIFs associated with various VRFs configured on the network device) and resolves to a forwarding table. Lookup table220includes entries220A-220F (collectively, “entries220”) each having an IIF key value and resolving to different forwarding table that is dependent on whether the received packets having the IIF key value are uplink packets or downlink packets.

For instance, packets received on an IIF identified by value ‘168’ are received with an access VRF (e.g., an access VRF connecting gateway8to service control gateway20) and key to entry220A. For uplink packets222, entry220A resolves to the “SVC-VRF-1-IN” VRF, which is an entry point for a service and causes the packet processor to forward the matching uplink packets222to a service node providing the service and having a destination route installed in the “SVC-VRF-1-IN” VRF in the network device. For downlink packets224, entry220A resolves to the “SVC-VRF-K-IN” VRF, which is an entry point for a service and causes the packet processor to forward the matching downlink packets224to a service node providing the service and having a destination route installed in the “SVC-VRF-K-IN” VRF in the network device.

To take another example, packets received on an IIF identified by value ‘53’ are received with a “SVC-VRF-2-OUT” VRF and key to entry220c. For uplink packets222, entry222resolves to the “SVC-VRF-3-IN” VRF, which is an entry point for a service and causes the packet processor to forward the matching uplink packets222to a service node providing the service and having a destination route installed in the “SVC-VRF-3-IN” VRF configured in the network device. For downlink packets224, entry220C resolves to the “SVC-VRF-1-IN” VRF, which is an entry point for a service and causes the packet processor to forward the matching uplink packets222to a service node providing the service and having a destination route installed in the “SVC-VRF-1-IN” VRF configured in the network device. Each of the VRFs and interfaces illustrated inFIGS. 5A-5Bmay include a forwarding table having routes that key to destination network addresses of packets and specify one or more actions for matching packets, e.g., forwarding the matching packets via an OIF for an attachment circuit to a service node.

By processing uplink packets222and downlink packets224based on respective IIFs on which the network device receives the packets and resolving to next hops according to lookup table220, the packet processor is able to determine the next service in the uplink services list and downlink services list (respectively), and so dynamically stitch together an uplink service chain for uplink packets222and a downlink service chain for downlink packets224. In some examples, the network device implements at least one of an uplink service chain and a downlink service chain.

FIG. 5Billustrates packet processing path204′ dynamically modified from packet processing path204to implement the modified uplink services list90′ and modified downlink services list92′ ofFIG. 4B, and received by the network device. The packet processor executes packet processing path204′ to match packets of a packet flow210to modified rule176A′ of rules176, and to steer the matching packets along a modified service chain that is (1) dynamically provisioned within the network device with uplink services list90′ and downlink services list92′, and (2) implemented in a hardware FIB by a combination of lookup data structures and next hop instructions. In this way, the network device may be dynamically provisioned with a list of services to apply to packets flows.

FIGS. 6A-6Cdepict a flowchart illustrating an example mode of operation for a network device according to techniques described herein. The mode of operation is described with respect to service control gateway30ofFIG. 1and uplink services list90and downlink services list92ofFIG. 4A.

Service control gateway30receives configuration information from a policy control server. Specifically, service control gateway30receives a policy rule (302) as well as an uplink services list90for the rule (304) and a downlink services list92for the rule (306). Uplink services list90specifies a first ordered list of VRFs, and downlink services list92specifies a second ordered list of VRFs. Service control gateway30may install the rule and the services lists to a forwarding plane.

Service control gateway30subsequently receives a packet (308). If the packet is a downlink packet (YES branch of310), service control gateway30forwards the packet to a service node using the last VRF in the first ordered list of VRFs specified by the uplink services list90(312). Service control gateway30receives a packet at an incoming interface (314) and maps the incoming interface to an associated VRF at an index in the second ordered list of VRFs (316). Packets received at step314may differ from the packets sent from the service control gateway30due to the application of services at the service nodes. If the associated VRF is the first VRF in the second ordered list of VRFs (YES branch of318), service control gateway30forwards the packet using the default routing table (322). Otherwise (NO branch of318), service control gateway20decrements the index and forwards the packet to the next service node in the chain using the VRF at the decremented index in the first ordered list of VRFs (320).

If the packet is an uplink packet (NO branch of310), service control gateway20forwards the packet to a service node using the first VRF in the first ordered list of VRFs specified by the uplink services list90(332). Service control gateway20receives a packet at an incoming interface (334) and maps the incoming interface to an associated VRF at an index in the second ordered list of VRFs (336). Packets received at step334may differ from the packets sent from the service control gateway20due to the application of services at the service nodes. If the associated VRF is the last VRF in the second ordered list of VRFs (YES branch of338), service control gateway20forwards the packet using the default routing table (342). Otherwise (NO branch of338), service control gateway20increments the index and forwards the packet to the next service node in the chain using the VRF at the incremented index in the first ordered list of VRFs (340).

FIG. 7is a conceptual diagram illustrating a control flow and packet flow among network elements of a service provider network according to a dynamically provisioned service chain, in accordance with techniques described herein. With regard to the control flow in this example, gateway8issues a RADIUS or Diameter Accounting Request to service control gateway20to initiate policy provisioning for a subscriber device16. Service control gateway20responds with a corresponding Accounting Response.

In addition, service control gateway20issues, to policy control server14, a policy request for policies to be applied to traffic for the new subscriber or application (e.g., flows27). The policy request in this example is a Diameter CCRI. Policy control server14sends a policy response, in this example a Diameter CCRA, to service control gateway20.

The policy response includes an uplink services list specifying one or more “in” VRFs, as well as a downlink services list specifying one or more “out” VRFs. In this way, service control gateway20may be dynamically provisioned with a service chain25. Service control gateway20stitches together the in VRFs and out VRFs in order to direct flows27along service chain25. InFIG. 7, “service-list-uplink AVP” indicates the uplink service list, and “service-list-downlink AVP” indicates the downlink service list, both included as separate AVPs in the CCRA.

Service control gateway20receives uplink packets from gateway8via an access VRF. Service control gateway20steers the packets to VRF1_IN26A (“first VRF in service-list-uplink AVP”), which forwards the traffic to service node10A, which applies a first service. Service control gateway20receives the traffic back on an incoming interface for VRF1_OUT26B (“first VRF in service-list-downlink AVP”). Service control gateway20maps the incoming interface for VRF2_OUT26B to the next VRF, VRF1_IN28A, and forwards the traffic accordingly to service node10B, which applies a second service. Service control gateway20receives the traffic back on an incoming interface for VRF2_OUT28B. Service control gateway20maps the incoming interface for VRF2_OUT26B to the next VRF, which may be the default routing table. Service control gateway20outputs the packets according to the next VRF and a route lookup toward PDN12.

For downlink packets received by service control gateway20via, e.g., an access VRF, service control gateway20may apply the uplink service list and downlink service list in a reverse ordering to apply a service chain that is a reverse of service chain25.