Policy control using software defined network (SDN) protocol

A network device includes an internal policy engine that makes local policy decisions for packet flows and controls policies applied by service modules and forwarding components of the network device. The policy engine interacts with an external policy server to receive policies using software defined networking (SDN) protocol as if the data plane of the network device were directly exposed to the external policy server by the SDN protocol.

TECHNICAL FIELD

The invention relates to computer networks and, more specifically, network devices that route packets within computer networks.

BACKGROUND

Various types of devices connect to service provider networks to access services provided by packet-based data networks, such as the Internet, enterprise intranets, and virtual private networks (VPNs). For example, many computers utilize fixed subscriber connections, such as digital subscriber line- or cable-based connections, of service provider networks to access the packet-based services. Similarly, wireless devices, such as cellular or mobile smart phones and feature phones, tablet computers, and laptop computers, utilize mobile connections such as cellular radio access networks of the service provider networks to access the packet-based services.

In this way, the service provider network typically provide an extensive access network infrastructure to provide packet-based data services to service provider network access gateways to provide access to the offered services. Access gateways, for example, are positioned near the edge of the service provider network upstream from the subscribers and typically provide an anchor for managing subscriber sessions. The access gateways typically provide mechanisms for identifying subscriber traffic and apply subscriber policies to manage subscriber traffic on a per-subscriber basis as such traffic traverses the service provider core network boundary.

The increased demand for data services has led to significant increase in size and complexity of fixed and wired access networks. Policy distribution and control within large-scale access networks is often a challenge given the sheer volume of subscribers and the wide variety of networking equipment that may be deployed within the access network.

SUMMARY

In general, techniques are described for leveraging software defined networks (SDNs) and protocols related thereto to provide a policy control framework that leverages existing network infrastructure to scale to the demand from increasing numbers of subscribers. The techniques may provide an automated solution that can provide network-level policy decisions yet provide granular per-flow policy control.

In one embodiment, a method comprises detecting, with a flow control unit of a data plane of a router, a new packet flow and accessing, with a policy engine of a control plane of the router, a plurality of policies stored within a policy database of the control plane of the router to identify one or more of the policies that specify criteria that match attributes of the new packet flow. The method further comprises outputting, in response to failing to identify the one or more policies, a message to request a policy from a policy server. The message is constructed to conform to a software defined networking (SDN) protocol as if the data plane of the router were directly exposed to an external device by the SDN protocol. The method further comprises receiving a response message that conforms to the SDN protocol and specifies at least one new policy and installing the policy within the policy database of the control plane of the router.

In another embodiment, a network device comprises a plurality of interfaces configured to send and receive packets. The network device comprises a control plane and a data plane to forward packets between the interfaces, wherein the data plane includes a flow control unit to detect a new packet flow associated with the packets. The control plane comprises a routing engine to maintain routing information specifying routes through a network. The routing engine processes the routing information to select routes through the networks and install forwarding information within the data plane in accordance with the selected routes to control forwarding of the packets. The control plane also includes a policy engine that stores a plurality of policies stored within a policy database. In response to detection of the new packet flow, the policy engine outputs a message to request a policy from a policy server, the message constructed to conform to a software defined networking (SDN) protocol. The policy engine receives a response message from the policy server that specifies at least one new policy and installs the policy within the policy database of the control plane of the router. The data plane may continue to forwarding packets in accordance with the forwarding information generated by the internal routing engine of the router and in accordance with local policy decisions made by the policy engine, yet apply policies received from the policy server by the SDN protocol.

In another embodiment, a computer-readable medium contains instructions. The instructions cause a programmable processor to access, with a policy engine of a control plane of the router, a plurality of policies stored within a policy database of the control plane of the router to identify one or more of the policies that specify criteria that match attributes of a new packet flow. The instructions further cause the processor to output a message to request a policy from a policy server, wherein the message is constructed to conform to a software defined networking (SDN) protocol as if the data plane of the router were directly exposed to an external device by the SDN protocol. The instructions further cause the processor to receive a response message from the policy server, wherein the response message conforms to the SDN protocol and specifies at least one new policy, install the policy within the policy database of the control plane of the router, and, after receiving the response message and installing the policy within the policy database of the router, execute a local policy decision with the policy engine of the router to select one of the policies from the policy database for application to packets forwarded by the router.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating an example network system2that distributes and applies subscriber policies in accordance with techniques described herein. As shown in the example ofFIG. 1, network system10includes a service provider network20coupled to a public network22. Service provider network20operates as a private network that provides packet-based network services to subscriber devices18A,18B (herein, “subscriber devices8”). Subscriber devices18A may be, for example, personal computers, laptop computers or other types of computing device associated with subscribers. Subscriber devices18B may comprise, for example, 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 devices18may 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.

In the example ofFIG. 1, service provider network20includes broadband network gateway (GW)36and network switch38that provide subscriber devices18A with access to core network31. In some embodiments, GW36may comprise a router that maintains routing information between subscriber devices18A and core network31. Broadband network gateway36, for example, typically includes Broadband Remote Access Server (BRAS) functionality to aggregate output from one or more switches38into a higher-speed uplink to core network31. Moreover, GW36provides an anchor point active sessions for subscriber devices18A. In this sense, GW36may maintain session data and operate as a termination point for communication sessions established with subscriber devices18A that are currently accessing packet-based services of public network via core network31. That is, core network31provides data service access to public network22and may comprise, for instance, a general packet radio service (GPRS) core packet-switched network, a GPRS core circuit-switched network, an IP-based mobile multimedia core network, or another type of transport network. Core network31typically includes one or more packet processing nodes (“PPN”)19, such as internal routers and switches, and appliances to provide security services, load balancing, billing, deep-packet inspection (DPI), and other services for mobile traffic traversing the core network.

Network switch38may communicate with broadband network gateway36over a physical interface supporting various protocols, e.g., ATM interface supporting ATM protocols. In one example, network switch38may comprise a digital subscriber line access multiplexer (DSLAM) or other switching device. Each of subscriber devices18A may utilize a Point-to-Point Protocol (PPP), such as PPP over ATM or PPP over Ethernet (PPPoE), to communicate with network switch38. For example, using PPP, one of subscriber devices18may request access to core network31core network31and provide login information, such as a username and password, for authentication by policy server37. PPP may be supported on lines such as digital subscriber lines (DSLs) that connect endpoint computing devices18with network switch38. In other embodiments, endpoint computing devices18may utilize a non-PPP protocol to communicate with network switch38. Other embodiments may use other lines besides DSL lines, such as cable, Ethernet over a T1, T3 or other access links Examples details of a Broadband Remote Access Server coupled to a DSLAM or other network switch to provide manage network connections are described in U.S. Pat. No. 7,813,376, entitled “TERMINATION OF NETWORK CONNECTIONS IN ABSENCE OF A DYNAMIC NETWORK INTERFACE,” the entire content of which is incorporated herein by reference.

As shown inFIG. 1, service provider network20may include radio access network25in which one or more base stations communicate via radio signals with subscriber devices18B. Radio access network25is a transport network that enables base stations to exchange packetized data with core network31of the service provider, ultimately for communication with packet data network22. Radio access network25typically comprises communication nodes interconnected by communication links, such as leased land-lines or point-to-point microwave connection. The communication nodes comprise network, aggregation, and switching elements that execute one or more protocols to route packets between base stations and gateway router (“GW”)28. Core network31provides session management, mobility management, and transport services to support access, by subscriber devices18A, to public network22. GW28provides an anchor point active sessions for subscriber devices18B. Similar to GW36, GW28may maintain session data and operate as a termination point for communication sessions established with subscriber devices18B that are currently accessing packet-based services of public network via core network31. Examples details of a high-end mobile gateway device that manages subscriber sessions for mobile devices are described in U.S. patent application Ser. No. 13/248,834, entitled MOBILE GATEWAY HAVING REDUCED FORWARDING STATE FOR ANCHORING MOBILE SUBSCRIBERS,” the entire content of which is incorporated herein by reference.

Policy server37provides a central point for policy distribution and control for managing subscriber session associated with subscriber devices18. For example, policy server37may be Policy Control and Charging Rules Function (PCRF) device that maintains a central database of policies33for deployment within service provider network20to be applied to packet flows for subscriber devices18. In some examples, policy server37may also provide authentication, authorization and accounting (AAA) functions to authenticate the credentials of a subscriber requesting a network connection. Example details of a regarding policy and charging control are found in “3GPP TS 23.203—Policy and Charging Control Architecture (Release 10),” Version 10.1.0, 3rd Generation Partnership Project, Technical Specification Group Services and System Aspects, September 2010, which is incorporated herein by reference in its entirety. Although shown as a standalone device, policy server37may be integrated within a router or gateway of broadband network or on a separate network device and may be, for example, a Remote Authentication Dial-In User Service (RADIUS) server.

After authentication and establishment of network access, any one of subscriber devices18may begin exchanging data packets with public network22, and such packets traverse GWs28,36and PPNs19. When forwarding packets, GWs28,36and PPNs19may apply one or more policies to the packets. Upon receiving detecting a session request from one of subscriber devices18A, GW36utilizes a communication session17A with policy server37to authenticate the individual subscriber. At this time, GW36typically receives profile information for a subscriber and/or subscriber service identified in the request, where the profile information may specify particular policies to be applied to the packet flow(s) for the subscriber. As further described below, a local policy engine within a control plane of GW36installs the policies within a data plane of the BGW for application to the packet flows. Further, GW36controls application of policies to individual packet flows from subscriber devices18A and may, on a per flow basis, interact with policy server37to retrieve policy information.

Similarly, GW28establishes a communication session17B with policy server37to authenticate requests for new sessions from subscriber devices18B and install policies within a data plane of GW28for application to the packet flows for the subscriber session. BGW28controls application of policies to individual packet flows from subscriber devices18A and may, on a per flow basis, interact with policy server37to retrieve policy information.

Policies33may, for example, provide fine-grain control by way of service data flow (SDF) detection, QoS, gating and packet flow-based charging. Policies related to service data flow detection may contain information for identifying individual packet flows for a service session. In some examples, policies33specify one or more conditions and a set of actions to be performed on packets that match parameters that characterize packet flows according to, for example, the IP5-tuple consisting of the source address, destination address, source port, destination port, and transport protocol specified in IP packet headers, other packet header information, and/or information obtained from Deep-Packet Inspection (DPI). The actions may include one or more of appending a label to the packet, removing or swapping a label on the packet, inspecting the packet for viruses, performing deep packet inspection on the packet, performing quality of service.

In this way, GWs28,36provide an infrastructure for automated deployment of a rich set of policies that provide fine-grain, flow-level control over packet flows associated with subscribers18. However, instead of a using conventional protocol when interacting with policy server37, GWs28,36may instead use a software defined networking (SDN) protocol. For example, instead of utilizing a conventional AAA protocol for authenticating subscribers with policy server37, local policy engine within GWs28,36uses an SDN protocol that is conventionally used to expose a forwarding plane of a network device to direct access by an external controller for creating and controlling a software defined network. In other words, rather than directly exposing the data planes of GWs28,36, the gateways utilize the SDN protocol in limited fashion for communication sessions17A,17B in place of conventional AAA protocols, such as Radius or Diameter. Moreover, GWs28,26continue to maintain full control plane operation over packet forwarding function yet utilize an SDN protocol that has been extended so as to be used as a fine-grain policy distribution mechanism on a per flow basis.

More specifically, a software defined network (SDN) is a network in which control plane functionality is completely and entirely decoupled from data plane operation performed by switches and routers within the network. That is, control plane functionality within each of the devices is set aside and, instead, each device executes an SDN protocol to directly expose the data plane components of the device. Separate network equipment, such as a centralized SDN controller, performs all network control, including topology learning and forwarding decisions, and directly manipulates the data plane forwarding components of the network devices using the SDN protocol. One primary example of an SDN protocol is “OpenFlow,” which is a layer two (L2) communication protocol that provides direct access to the data plane of a network switch or router. Further example details of the OpenFlow protocol is described in “OpenFlow Switch Specification,” Open Networking Foundation, Version 1.2, Dec. 5, 2011, incorporated herein by reference.

In contrast, as further described below, GWs28,36maintain full control plane operation over forwarding packet flows associated with subscribers18. GWs28,36and policy server37each include modified communication software that embeds functionality for an SDN protocol. That is, AAA communication software executing on GWs28,36and policy server37utilizes an underlying SDN protocol that has been extended so as to be used as a fine-grain policy distribution mechanism capable of deploying and installing policies33on a per flow basis via communication sessions17.

As a result, the techniques leverage internal policy control mechanisms of the existing network infrastructure, e.g., GWs28,36, to provide a policy distribution architecture able to scale to the demand from increasing numbers of subscribers18. That is, as high-end network gateways, GWs28,36may include tightly-coupled control-plane and data-plane policy enforcement mechanism suitable for high-volume networks. Conventional use of an SDN protocol to bypass control-plane functionality of GWs28,36by directly exposing data plane components of the devices would likewise bypass these existing internal policy enforcement mechanisms of GWs28,36or otherwise be unable to leverage such mechanisms. However, as further described, GWs28,36maintain full control-plane functionality and control over their respective data planes yet nevertheless present an SDN protocol for receipt of policies to be deployed by the gateways as if their forwarding planes were exposed. This may be advantageous in that policy server37may conform to and otherwise communicate in accordance with technologies for software defined networks, which has ever increasing interest from industry and academia, yet allow service provider network20to utilize powerful policy enforcement mechanism within control planes of GWs28,36. In this way, the techniques described herein may provide an automated solution that can provide network-level policy control from one or more central devices, such as Policy server37using SDN protocols, yet provide granular per-flow policy control within each of GWs28,36. Although described by way of example with respect to GWs,28,36, PPNs19operate in accordance with the techniques described herein with respect to distribution of policies33from policy server37.

Further, in some examples, GWs28,36and/or PPNs19may utilize existing mechanisms to control other devices in accordance with the policies received from policy server37. For example, GW36may utilize an access node control protocol (ANCP), also referred to as a layer two (L2) control protocol (L2CP), to establish communication session21with switch38and communicate control information to the switch in accordance with the policies received from policy server37. Example details of an ANCP are described in “Protocol for Access Node Control Mechanism in Broadband Networks,” Internet Engineering Task Force (IETF), Apr. 26, 2011, the entire contents of which are incorporated herein by reference.

FIG. 2is a block diagram illustrating an example router40that is configured in accordance with one or more techniques of this disclosure. For purposes of illustration, router40may be described below within the context of system10shown in the example ofFIG. 1and may represent any one of gateways28,36, or any of PPNs19. In this example embodiment, router40includes control unit42, interface cards (IFCs)62A-62N (collectively, “IFCs62”), and service cards71.

Router40typically include a chassis (not shown in the example ofFIG. 2for ease of illustration purposes) having a number of slots for receiving a set of cards, including IFCs62and service cards71. Each card may be inserted into a corresponding slot of a chassis for communicably coupling the card to a control unit42via a bus, backplane, or other electrical communication mechanism. IFCs62send and receive packet flows or network traffic via inbound network links64A-64N (collectively, “inbound links64”) and outbound network links66A-66N (collectively, “outbound links66”). Inbound links64and outbound links66in some examples for common IFCs form common, physical communication media for the IFCs, which operate in full duplex mode. That is, in some examples, each of IFCs62is coupled to respective communication media that can send and receive data substantially simultaneously. In other examples, inbound links64and outbound links66form separate physical media for respective IFCs62.

Control unit42may include one or more master microprocessors52that execute software instructions, such as those used to define a software or computer program, stored to a computer-readable storage medium (again, 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, control unit42may 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, for performing the techniques described herein.

Control unit42may also be divided into logical or physical “planes” to include a control plane44and a forwarding plane52. In some examples, control unit42may be further divided into a third logical or physical “plane,” a service plane, as shown inFIG. 3. That is, control unit42may implement three separate functionalities, e.g., the routing, forwarding and service functionalities, either logically, e.g., as separate software instances executing on the same set of hardware components, physically, e.g., as separate physical dedicated hardware components that either statically implement the functionality in hardware or dynamically execute software or a computer program to implement the functionality, or some combination of logical and physical implementations.

Control plane44of control unit42provides the routing functionality of router40. In this respect, control plane44may represent hardware or a combination of hardware and software of control unit42that implements routing protocols46. Routing protocols46may include, for example, intermediate system to intermediate system (IS-IS), open shortest path first (OSPF), routing information protocol (RIP), border gateway protocol (BGP), or other routing protocols. By executing routing protocols46, control plane44learns network topology and performs route selection for forwarding packets through the network and determines new routes through the network. That is routing protocols46may be part of a routing engine within control plane44and locally perform topology learning and forwarding decisions. Control plane44stores learned routing information within routing information base (RIB)50. The routing information may include information defining a topology of a network, such as network14ofFIG. 1. Control plane44generates forwarding information for data plane52by resolving the topology defined by the routing information to select or determine one or more routes through network14. Control plane44may then update data plane52in accordance with these routes to program data plane52with forwarding information as a software forwarding information base (FIB)54A.

In this example, data plane52includes a packet forwarding engine58that further includes slave microprocessor53, content addressable memory (CAM)72, and forwarding application-specific integrated circuits (ASICs)70. Forwarding ASICs70may be microcode-controlled chipsets that are programmably configured by slave microprocessor53. Specifically, one or more of ASICs70may be operable by internal microcode-based control logic56programmed by slave microprocessor53. Further, slave microprocessor53programs a hardware FIB54B into internal memory of ASICs70within the data plane50A based on software FIB54A. When forwarding packets, control logic56traverses HW FIB54B and, upon reaching a FIB entry for the packet (e.g., a leaf node), microcode-implemented control logic56selects a forwarding next hop (FNH) for forwarding the packet. In this way, after the ASICs70are programmed with HW FIB54B, data planes52of router40may receive and forward packet flows associated with subscribers8. One example of a router including a packet processing engine having multiple microcode instruction memories is described in U.S. Pat. No. 6,976,154, the entire contents of which are incorporated herein by reference.

Service cards71may each represent a card capable of applying one or more services. Service card71may include a control unit, which may represent one or more general processors that execute software instructions, such as those used to define a software or computer program, stored to a non-transitory computer-readable medium, 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 the one or more processors to perform the techniques described herein. Alternatively, the control unit may represent 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, for performing the techniques described herein. In some instances, control unit50may be referred to as a processor.

When forwarding packets via, data plane52may apply one or more policies to the packets. For example, local policy engine47processes session requests received from subscriber devices18and interacts with policy server37to authenticate each subscriber. As shown inFIG. 2, policy engine includes SDN interface68to receive policies to be applied to particular packet flows for subscribers18. Instead of utilizing a conventional AAA protocol for authenticating subscribers with policy server37, SDN interface68uses an SDN protocol that is typically used for creating and controlling a software defined network by exposing data plane52and forwarding ASICs70to an external SDN controller.

In the example router40ofFIG. 2, local policy engine47stores policies received via SDN interface68to an internal database or other repository as policies48A and dynamically communicates with directs master processor52to install copies of policies48B within data plane52for particular packet flows detected by forwarding ASICs70. As further explained with respect toFIG. 3, flow control unit57of forwarding ASICs may detect new packet flow of new or existing sessions and may signal policy engine47of control plane44, causing the policy engine to deploy policies, including potentially interacting with policy server37, on a per flow basis.

Policies48A,48B may, for example, provide fine-grain control by way of service data flow (SDF) detection, QoS, gating and packet flow-based charging. Policies related to service data flow detection may contain information for identifying individual packet flows for a service session. In some examples, policies48A,48B specify one or more conditions and a set of actions to be performed on packets that match parameters that characterize packet flows according to, for example, the IP5-tuple consisting of the source address, destination address, source port, destination port, and transport protocol specified in IP packet headers, other packet header information, and/or information obtained from Deep-Packet Inspection (DPI). The actions may include one or more of appending a label to the packet, removing or swapping a label on the packet, inspecting the packet for viruses, performing deep packet inspection on the packet, performing quality of service processing on the packet, blocking or dropping the packet or other services.

When installed within data plane52, slave microprocessor53may store policies48B within a policy store74. Policy store74may be any suitable data structure to store policies48A such as a database, lookup table, array, linked list, and the like, within a computer-readable medium. In this example, CAM72is used to store pointers that identify policies48B, although any other type of readable memory structure may be used. CAM72comprises semiconductor memory and comparison circuitry that enables a search operation of contents in memory to complete in a single clock cycle. In one example, CAM72may store one or more entries comprising encoded values associated with one or more policies. To select one or more one or more policies48B, CAM72compares a query value against the one or more encoded values of CAM72and returns pointers to policies48B associated with encoded values that match the query value. For instance, slave microprocessor53of PFE58may select one or more policies48B from policy store74and may program forwarding ASICs70with the selected policies and process the packets according to the policies. Further details are of deployment of policies within a high-end router are described within U.S. patent application Ser. No. 12/947,463, entitled “POLICY AND CHARGING CONTROL RULE PRECEDENCE MAPPING IN WIRELESS CONTENT ACCESS NETWORKS,” filed Nov. 16, 2010, and U.S. patent application Ser. No. 13/174,437, entitled “HYBRID PORT RANGE ENCODING,” filed Jun. 30, 2011, the entire contents of both being hereby incorporated herein by reference.

In this way, components of control plane44and data plane52of router20provide mechanisms for automated deployment of a rich set of policies that provide fine-grain, flow-level control over packet flows associated with subscribers8.

FIG. 3is a block diagram illustrating example operation of the components of router40. In the example ofFIG. 3, the components of router40are arranged as operating within three different structural planes. In this example, the components of router40may be viewed as architecturally operating within data plane52, service plane72and routing plane75, where the routing plane and the service plane form a distributed version of control plane44shown inFIG. 2.

In the example ofFIG. 3, flow control unit57receives an inbound packet78and selectively directs the packet along fast path91to forwarding ASICs70for immediate forwarding or along slow path93for additional analysis by service cards71. That is, flow control unit57receives an incoming packet78for a packet flow (e.g., IP traffic or VPN-encapsulated traffic) and determines whether to send the packet to deep packet inspection (DPI) module73for processing within one or more of service cards71, or whether to bypass DPI module73. In one example, flow control unit57may maintain a flow table to track current packet flows. Upon receiving a packet that does not match a current packet flow, flow control unit57may direct the packet to service cards71for processing. In some cases, upon determining that a particular packet flow does not require additional processing, such as determining that the packet flow does not pose a threat, DPI module73may issue commands65to dynamically configure flow control unit57of data plane52to direct subsequent packets of the packet flow along fast path91, thereby bypassing DPI module73.

The term “packet flow” refers to a set of data packets originating from a particular source device and sent to a particular destination device as part of an application communication session between the source and destination device. More specifically, the terms “data stream”, “data flow”, and “packet flow” may be understood to indicate the same or similar concepts of a flow of packetized data, in accordance with a packet protocol such as IPv4, IPv6, X.25, or some other packet protocol. A flow of packets, in either the upstream direction (i.e. sourced by one of subscriber devices18) or downstream direction (destined for one of subscriber devices18), may be identified by the five-tuple: <source network address, destination network address, source port, destination port, protocol>. This five-tuple generally identifies a packet flow to which a received packet corresponds and, depending on the flow direction, one of subscriber devices18may be associated with either the source network address or the destination network address of the packet flow. For example, one of subscriber devices18may establish a subscriber session with one of GWs28,36such that the subscriber session supports multiple application flows for corresponding applications. Each of the application flows has distinct quality of service (QoS) parameters that correspond with the service or application being carried over each of the bearer channels, such as VoIP or bulk data transfer, and with the subscriber information, e.g. levels of service in the SLA. Packet flows may therefore also be characterized and identified according to other characteristics, including VLAN tags, PPPoE session, and GTP tunnel identifiers of network layer or data link layer protocol headers/tags that encapsulate the packets.

In general, service cards71may be installed along a backplane or other interconnect of router40and, in one example, include DPI module73to perform a variety of services on the packets received from data plane52, such as filtering, logging, Intrusion Detection and Prevention (IDP) analysis, virus scanning, deep packet inspection. That is, in general, DPI module73of service cards71receive packets from flow control unit57, selectively provide security and other services to the packets in accordance policies installed by local policy engine47, and relay packets or any response packets to data plane52for forwarding by forwarding ASICs70in accordance with HW FIB54B.

In general, DPI module73identifies packet flows in the monitored traffic, and transparently reassembles application-layer communications from the packet flows. A set of protocol-specific decoders within the DPI module73analyzes the application-layer communications and identifies application-layer transactions. During this process, DPI module73discovers new packet flows associated with subscriber sessions and determines subscriber information for the data packets by, for example, determining an IP address or subscriber identifier from the packets. In some cases, DPI module73may determine that incoming packet78represents a request for a new subscriber session. In addition, DPI module73may apply DPI to the data packets to identify a type of software application, i.e., an application identity, for the subscriber packet flow. The application identity information may include an application identifier (“application ID”) that DPI module73assigns to the application based on its inspection of the packets in the application flow. For example, DPI module73may determine that a packet flow is associated with a particular layer seven (L7) communication protocol including HyperText Transfer Protocol (HTTP), the File Transfer Protocol (FTP), the Network News Transfer Protocol (NNTP), the Simple Mail Transfer Protocol (SMTP), Telnet, Domain Name System (DNS), Gopher, Finger, the Post Office Protocol (POP), the Secure Socket Layer (SSL) protocol, the Lightweight Directory Access Protocol (LDAP), Secure Shell (SSH), Server Message Block (SMB) and other protocols. In some examples, DPI module73may detect and identify applications that use various means for transporting communications, e.g., either using layer four (L4), or the transport layer, as a transport means, or using another software application at layer seven (L7), or the application layer, as a transport means. That is, DPI module73may detect layered or stacked applications at L7 of a network. For example, DPI module73may detect and identify packet flows for Kazaa and Yahoo! Messenger (YMSG) protocols that use another L7 application, such as the HyperText Transfer Protocol (HTTP) or Microsoft's implementation of the Server Message Block (SMB) protocol, also known as the Common Internet File System (CIFS), as a transport layer-like application for transporting application data. Further example details of application identification that may be performed by DPI module73are described in U.S. Pat. No. 8,112,800, the entire contents of which are incorporated herein by reference.

DPI module73forwards this subscriber information and application identity information, collectively referred to as DPI output data94, to policy control engine85. In response, policy control engine85attempts to make local decision with respect to the new packet flow based on policies48A. That is, policy control engine85searches policies48A for a matching session policy to apply to the session for the subscriber packet flow based at least in part on the subscriber information and the application identity information received as DPI output data94. The session policy may, for example, control configurable packet processing operations to be applied by forwarding ASICs70, such as packet forwarding, bandwidth, quality of service, filtering, rate limiting, marking, accounting, dynamic-request change of authorization (CoA), policy-based routing and redirection, advertisement insertion, lawful intercept, class of service, and traffic shaping, for instance. As another example, a policy may specify a filter, classifier, class of service queue, counter, policer, lawful intercept component, traffic flow template, routing table, or mobility tunnel endpoint identifier handler, for example. The policy may also be associated with a PDP address allocated by the service provider network20for the subscriber device18for use in sending and receiving subscriber session data packets; routing information used by services cards71in directing the forwarding of session data packets, such as tunnel endpoint identifiers (TEIDs) and identifiers or addresses for downstream nodes; and session policy characteristics such as bandwidth, priority, quality of service (QoS) profiles, dynamic IGMP, firewall filter, and class of service (CoS) configuration, for each of the individual packet flows in the subscriber session, for example. Upon selecting one of local policies48A for the particular packet flow, local policy engine47programs a copy of the policy within policies48B within forwarding ASICs to be applied to subsequent packets of the packet flow for the particular subscriber18.

In the event local policy engine47is unable to resolve the newly discovered packet flow to a particular one of policies48A, the local policy engine communicates with policy server37to request a policy for the particular packet flow. However, instead of using a conventional protocol, such as Radius or Diameter, local policy engine47invokes SDN interface68to construct and output message101in accordance with a software defined networking (SDN) protocol as if data plane52were directly exposed to an external SDN controller or device. Moreover, upon receiving response message103in accordance with the SDN protocol, local policy engine47extracts the specified policy for the new packet flow and stores the policy within routing plane75along with other local policies48A. Local policy engine47deploys the policy to policy store74for installation within forwarding ASICs70. Moreover, local policy engine47may also output a response96that provides any packet flow-specific instructions for DPI module73, including specification of any policies48C to be applied in service plane72based on analysis of the packets. For example, DPI module73may subject subsequent packets of the packet flow to certain types of deep packet inspection and analysis operations, as specified by policies48C, based on the instructions received from local policy engine47. Alternatively, DPI module73may issue command65to direct flow control unit57to install a dynamic filter within the flow table, such as an exact match filter that indicates particular actions to be performed when a packet is received that matches the filter. In the case local policy engine47indicates by way of message96that no further DPI services need be applied to the packet flow (e.g., after determining that the packet flow is trusted or benign), DPI module73may install a filter within flow control unit57to specify that subsequent packets of this packet flow session may be processed on fast path91that bypasses DPI module73.

In this way, routing plane75presents an SDN interface68as if data plane52were directly exposed for software defined networking, yet policy control decisions are nevertheless maintained by local policy engine47of routing plane75and packet flow detection and analysis functionality provided by flow control unit57and DPI module73are still utilized within router40.

FIGS. 4A,4B depict a flowchart illustrating example operation of router40ofFIGS. 2-3in accordance with aspects of this disclosure. Initially, as shown inFIG. 4B, routing engine49executes protocols46to learn and maintain routing information within RIB50representative of topology information (108). Routing engine49processes the routing information to select routes through the networks and generate forwarding information in accordance with the selected routes. In addition, routing engine49installs the forwarding information into forwarding integrated circuits70(108).

Subsequently, as shown inFIG. 4A, router40receives a packet, such as IP traffic or VPN traffic from a VPN tunnel (110). In one optional example, a flow control unit57of the data plane52analyzes the received packet to identify a packet flow associated with the packet (112), e.g., using a flow-based provisioning logic to identify a five-tuple based on information carried in the header or body of the packet. Upon identifying the packet flow, flow control unit57references an internal flow table to determine whether the packet belongs to a new packet flow or a packet flow already recognized by the router (114).

If flow control unit57finds a match in the flow table (YES branch of114) for the received packet and the matching entry directs the packet onto fast path91for processing (YES branch of94), flow control module20does not forward the packet to IDP68but signals forwarding ASICs70that the packet can immediately be forwarded in accordance with FIB (74).

If flow control unit57does not find a match in the flow table (NO branch of114), which indicates that the packet belongs to a new packet flow, the flow control unit directs the packet to service cards71for deep packet inspection (116).

When the packet is directed to one of service cards71, DPI module73of that service card applies deep packet inspection of the packet or series of packets for the packet flow (122). For example, DPI module73may extract and assemble application layer data from the packet to produce data indicative of an application identity associated with the new packet flow. DPI module73may also identify a subscriber for the packet flow, such as when the packet represents a session request. For new packet flows, DPI module73communicates the data to policy engine47of the control plane44(124). DPI module73may also perform Intrusion Detection and Prevention (IDP) analysis and/or virus scanning to filter out certain packets. As a further example, the DPI module73may perform ciphering, NAT or authentication services.

Upon receiving DPI data from DPI module73for new packet flows, policy engine47accessing policies48A stored within the policy database of control plane44to attempt to identify one or more of the policies that specify criteria that match attributes of the new packet flow, as specified by the DPI data (126). In other words, policy engine47attempts to perform a local policy decision to select one of the policies from the policy database.

In the event the local policy decision operation identifies one or more policies specifying criteria, e.g., rules, that match data from DPI module73for the new packet flow (YES branch of128), policy engine47may communicate the selected policies to DPI module73and/or may install the selected policies directly into forwarding integrated circuits70of the data plane of the router (138).

However, in the event the local policy decision operation fails to identify one or more policies specifying criteria, e.g., rules, that match data from DPI module73(NO branch of128), policy engine47outputs a message to request a policy from policy server37, where the message is constructed to conform to a software defined networking (SDN) protocol as if the data plane of the router were directly exposed to an external device by the SDN protocol (130).

Upon receiving a response message from policy server37, where the response message conforms to the SDN protocol and specifies at least one new policy, policy engine47installs the new policy within the policy database of control plane44(134). Policy engine47then perform a local policy decision to select one of the policies from the policy database for application to the new flow (136). Policy engine37may communicate the selected policies to DPI module73and/or may install the selected policies directly into forwarding integrated circuits70of the data plane of the router (138).

DPI module73receives the selected policies and may apply the policies to the packet and possibly subsequent packets of the packet flow (140) and inject the packet into data plane52for forwarding by forwarding ASICs70in accordance with HW FIB54B (142,120). In some instances, DPI module73may signal flow control unit57and direct the flow control unit to install criteria in its internal flow table designating whether subsequent packets of the packet flow should be forwarded directly to forwarding integrated circuits70along fast path91or whether the subsequent packets should continue to be directed to DPI module73along slow path93. At this time, DPI module73may determine whether to install the policies selected for the packet flow directly into forwarding integrated circuits70of the data plane of the router in the event subsequent packets for the flow need not be directed to DPI module73.

Techniques described above leverage protocols for software defined networks (SDNs) yet utilize local policy control and to scale to the demand from increasing numbers of subscribers. As described, in various examples, a network device includes an internal policy engine that makes local policy decisions on a per-packet flow basis and controls policies applied by service modules and forwarding components of the network device to those flows. The policy engine interacts with external devices, such as an external policy server, to receive policies using software defined networking (SDN) protocol as if the data plane of the network device were directly exposed to the external policy server by the SDN protocol. In this way, the techniques provide a flexible, granular per-flow policy control framework.

The techniques may be applied in a variety of applications. For example, with the growing transition towards VoIP-based services and video calls, being able to identify VoIP or video flows (out of multiple flows belonging to same subscriber session) may be helpful in treating or prioritizing the flows efficiently from a network perspective. This techniques described herein may allow for dynamic service activation and policy application, thus removing any need to statically dedicate bandwidth for each subscriber/service. Moreover, a router or other network device can identify and report when a flow cannot be set up due to bandwidth constraints. In network congestion scenarios, premium flows can be offloaded or redirected onto less congested paths on the network by applying proactive policy control. This enables network operators to control the bandwidth usage in the network even at peak times.

As another example, the techniques may be applied in the context of an intelligent VPN service, which a service provider may offer to enterprise customers. In order to scale, provide quality of experience levels and meet service level agreements, the service provider can implement the VPN using policy delegation and intelligent local policy decisions with an SDN protocol as described herein. The deep packet inspection (DPI) function on the local device may discover and the local policy engine may report new customer flows via the SDN protocol, as described herein. An external policy controller for the VPN makes a decision to add the customer as a new VPN member based on interaction with the VPN service application within the network. This decision is communicated to the local policy engine using SDN, and the local policy engine within the network device now makes intelligent policy decisions with respect to resources, bandwidth management and prioritization of the flows currently being handled by the device. The local policy engine may determine not to honor the decision of the external policy controller due to a number of factors, such as lack of local resources within the network device. In such a case, the local policy engine may communicate this decision back to the external policy server again using the SDN protocol. When the flows stop, the local device can deallocate and recover the resources that were associated with the VPN member and inform the external controller of this set of events. Similarly, any change in flows belonging to the VPN member can be dealt with intelligently at the local device level and then communicated to the external controller via the SDN protocol.

Further, as described herein, a network device, such as a BRAS, may utilize the techniques described herein and delegate part of the policy enforcement to a downstream DSLAM, e.g., instructing the DSLAM to use certain parameter values for interleaving delay to manage subscriber flows. The interleaving delay may be different for the subscribers based on the various services that they access; interleaving delay directly affects the quality of experience (QoE).