Technique for dispatching data packets to service control engines

A dispatching technique dispatches packets to a plurality of service control engines (SCEs) which in aggregate may be configured to handle traffic produced by a high-speed high-capacity data link. Upstream and downstream packets that are associated with a data flow between a subscriber and a destination node in a communication network are received from by a dispatcher which is located in a path used by the data flow. For each packet, the dispatcher identifies an SCE from among a plurality of SCEs that is to receive the packet based upon an address contained in the packet. The packet is then dispatched by the dispatcher to the identified SCE which processes the packet accordingly. After processing the packet, the SCE returns the packet to the dispatcher which further processes the packet including transferring the packet onto the communication network towards its destination.

FIELD OF THE INVENTION

This invention relates to communication networks and in particular to dispatching data packets to service control engines (SCEs) in a communication network.

BACKGROUND OF THE INVENTION

A communication network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting communications (e.g., data, voice, video) between communication units (end nodes), such as personal computers, certain telephones, personal digital assistants (PDAs), video units and the like. Many types of communication networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect nodes over dedicated private communications links located in the same general geographical location, such as a building or campus. WANs, on the other hand, typically connect large numbers of geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines. The Internet is an example of a WAN that connects networks throughout the world, providing global communication between nodes on various networks. The nodes typically communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol is a set of rules defining how the nodes interact with each other.

In some communication networks, such as the Internet, users (subscribers) gain access to a communication network via a service provider (SP). An SP is an entity, such as a business or organization, that offers access to various services provided by the entity, such as access to the communication network. SPs that provide access to the Internet and related services are commonly called Internet SPs (ISPs).

Some SPs, such as ISPs, charge their subscribers a fixed monthly fee for unlimited access to certain services provided by the SP, such as Internet access. The rationale here is that most users will make light usage of the service and thus not place great demands on the SP's network hardware and software resources. However, as certain high-bandwidth applications, such as peer-to-peer (P2P) applications and streaming video, gain popularity among subscribers, SPs are finding that more and more demand is being placed on their networks.

Service providers must find ways to deal with the challenges posed by the aggressive nature of P2P applications. Simply adding additional network capacity to the network may be costly and cumbersome to manage. Moreover, some networks are expensive to maintain and competition for subscribers is often fierce. Thus, some SPs find it difficult to maintain a solid margin and profit from their subscribers. Moreover, because certain subscribers may have unlimited access to the SPs' services, additional capacity added to the network in order to allocate additional bandwidth to these subscribers to accommodate their demands may be quickly consumed leaving strained SPs in the same situation.

One way SPs are addressing these issues is to monitor the usage of their networks to determine if certain applications are causing network congestion or increased expenditures and proactively act to restrain the effect of these applications. Moreover, SPs may seek to identify subscribers that are consuming an unacceptably large amount of network resources and either charge them for the excessive usage or potentially enforce various policies to limit their usage. For example, SPs may wish to provide tiered pricing plans whereby users who consume a great deal of resources are charged a different rate than users who consume fewer resources.

An SP may employ a service control engine (SCE) to control or monitor subscriber access to its network's resources. An SCE is a network device that is configured to, inter alia, monitor network traffic (data packets) transferred between a subscriber and an SP's network and enforce certain policies with regards to the monitored traffic. These policies may include filtering certain traffic e.g., limit usage of the SP's network by the subscribers. Traffic not filtered by the SCE is passed through the device. In a typical configuration, the SCE is positioned in a path taken by the traffic and acts as a “bump in the wire.” That is, it behaves in a manner that is “transparent” to the traffic carried on the path.

SCEs typically enforce policies by identifying the nature of network traffic, determining if a policy applies and enforcing the policy if necessary. The nature of the traffic is typically identified using a process known as a “deep packet inspection and analysis.” Deep packet inspection and analysis involves inspecting a packet at layers not normally inspected by other network devices (e.g., routers, bridges), such as the application layer which is layer-7 (L7) of the Open Systems Interconnection Reference Model (OSI-RM), and analyzing the inspected layers to identify the nature of the traffic (e.g., an application associated with the traffic). After identifying the nature of the traffic, the SCE can then decide how to act on (handle) the traffic.

For example, an SP may have a policy that limits the number of streaming video connections a particular subscriber may have active at any given time. The SP may employ an SCE to enforce this policy. Packets generated by subscribers are examined by the SCE using deep packet inspection and analysis to determine if they conform to the policy. If so, the SCE allows the packets to be transferred to their destination. If the packets do not conform to the policy, the SCE may filter the packets, respond to them or perform other steps as set forth by the policy. Thus, if a particular subscriber already has the limited number of video streams active and generates a packet to request an additional video stream, the SCE may filter the request and not let it proceed to its destination, respond to the request with an error message or take other action.

In addition to enforcing certain subscriber policies, SCEs may be configured to generally collect statistics of network usage. Thus, an SP may use an SCE to gather statistics regarding the type of applications that are being utilized on the SP's network. The SP may then use these statistics to better understand how subscribers use the SP's network and tailor services for those subscribers accordingly.

DETAILED DESCRIPTION OF THE INVENTION

Service control engines (SCEs) are limited with regards to the rate at which they can process data packets. This is primarily due to the compute intensive nature of deep packet inspection coupled with the other duties typically performed by the SCE, such as matching packets to data flows, enforcing policies against the packets and keeping various statistics. This may pose a problem in certain service provider (SP) networks that may wish to employ an SCE to monitor and police network traffic on a high-speed high-capacity link. Here, the link may carry packets at a rate that is faster than an SCE can process. Thus, the SCE may not be able to properly process the traffic carried on the link.

The present invention overcomes these shortcomings by incorporating a technique for dispatching packets to a plurality of SCEs which in aggregate may be configured to handle traffic produced by a high-speed high-capacity data link. In accordance with an aspect of the present invention, traffic associated with data flows are forwarded on a high-speed high-capacity link to a dispatcher. The dispatcher is configured to dispatch the traffic among a plurality of SCEs such that traffic associated with the same data flow is dispatched to the same SCE. The SCEs in aggregate contain sufficient capacity to handle processing the traffic carried on the high-speed high-capacity link.

Advantageously, the present invention is an improvement over the prior art in that it enables deep packet inspection of traffic on high-speed high-capacity data links where it may not otherwise be practical or possible.

FIG. 1is a block diagram of an exemplary communication network that may be used with the present invention. Network100comprises a plurality of nodes including subscriber nodes110, a service provider edge node120, dispatcher node200, server node170and SCEs600a-ccoupled via various data links to form an internetwork of nodes. These internetworked nodes communicate by exchanging data packets according to a pre-defined set of protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP) over Asynchronous Transfer Mode (ATM) or Ethernet.

The subscriber nodes110are conventional nodes, such as personal computers, work stations, personal digital assistants (PDA) and the like. The service provider (SP) edge node120is a conventional edge node, such as a router, that is configured to interface the subscriber nodes110with the SP's network which includes the SP edge node120, dispatcher node200and the SCEs600a-c. The server node170is a conventional server node that is configured to exchange information (e.g., data packets) with the subscriber nodes110. The dispatcher node200and the server node170are coupled via a wide-area network (WAN)150. The WAN150is a conventional WAN, such as the Internet, comprising various nodes (not shown) configured to implement the WAN.

The dispatcher node200is illustratively an intermediate node (e.g., a router) that is configured to, inter alia, dispatch packets received from the network100to the SCEs600on physical links130. The links130couple network interfaces on the dispatcher200to the SCEs600and enable data to be transferred between the SCEs600and the dispatcher200. Each SCE600acts as a “bump on the wire” in the path taken by data traveling from the dispatcher200to the SCE600and back to the dispatcher200meaning that the SCE600appears to be “transparent” to data carried on the path.

FIG. 2is a high-level block diagram of a dispatcher node200that may be used with the present invention. Node200comprises one or more network interface cards300, one or more SCE network interface cards210and a supervisor engine card500interconnected by a backplane220. Node200is configured to perform various conventional layer-2 (L2) and layer-3 (L3) switching and routing functions. As used herein, L2 and L3 refer to the data link and network layers, respectively, of the Open Systems Interconnection Reference Model (OSI-RM). In addition, as will be described further below, node200is configured to dispatch data packets received by the network interfaces300to SCEs600in accordance with an aspect of the present invention. A suitable network device that may be used with the present invention to implement dispatcher node200is the Cisco 7600 series router available from Cisco Systems Incorporated, San Jose, Calif.

The backplane220comprises point-to-point interconnections that interconnect the various cards and allow data and signals to be transferred between the cards. The SCE network interfaces210are conventional network interfaces that couple the dispatcher200with the SCEs600and enable data to be transferred between the dispatcher200and the SCEs600. Network interfaces300couple the dispatcher200with other nodes in the network100(e.g., the SP edge node120and nodes contained in the WAN150) and allow data packets to be transferred between the intermediate node200and these nodes using various protocols such as ATM, Frame Relay (FR), Ethernet and the like.

FIG. 3is a high-level partial block diagram of a network interface300that may be used with the present invention. Interface300comprises input interface logic310, input queuing logic320, a packet processing engine (PPE)330, backplane interface logic340, output queuing logic350and output interface logic360. The input310and output360interfaces comprise circuitry configured to enable packets to be transferred between the network interface300and the network100using various protocols, such as ATM, FR, Ethernet and the like. To that end, the interfaces310,360comprise conventional circuitry that incorporates signal, electrical, and mechanical characteristics and interchange circuits, needed to interface with the physical media of the network100and protocols running over that media.

The input320and output350queuing logic contain conventional packet queues (not shown) configured to buffer and queue packets transferred between the network interface300and the network100. The backplane interface340comprises conventional circuitry configured to interface the network interface300with the backplane220and enable data to be transferred between the network interface300and other cards attached to the backplane200.

The PPE330comprises forwarding logic configured to dispatch packets received by the network interface300to an SCE600in accordance an aspect of the present invention. Illustratively, PPE330is implemented as a series of one or more Application Specific Integrated Circuits (ASICs) which contains the forwarding logic portions of which may be configured by the supervisor engine400. Note that this forwarding logic may contain a processor and memory that is configured to dispatch the packets in accordance with aspects of the present invention.

Operationally, data packets received from the network100by a network interface300are received at the input interface310and transferred to the input queuing logic320where the packets are placed on a queue for transfer to the PPE330. The PPE330removes the packets from the queue, determines destinations for the packets and configures the backplane interface340to transfer the packets to the destinations which may be one or more cards in dispatcher200(e.g., another network interface300, SCE network interface210, supervisor engine500) and/or the output queuing logic350. Packets destined for another card are transferred to the card via the backplane220. Packets destined for the output queuing logic350are transferred to the output queuing logic350which schedules the packets for transfer onto the network100and places the packets on a queue contained in the output queuing logic350. A packet ready for transfer onto the network100is removed from its queue by the output queuing logic350and transferred to the output interface360which transfers the packet onto the network100.

Packets processed by the PPE330are dispatched to SCEs600via physical links associated with logical channels called port channels. Each SCE network interface210is configured with one or more port channels wherein each port channel is associated with one or more physical links130. A technology that may be used with the present invention to implement the port channels is the EtherChannel technology available from Cisco Systems Incorporated.

The PPE330dispatches a packet to an SCE600by using an address contained in the packet (e.g., destination address) to identify a port channel associated with the packet, hashing an address contained in the packet to generate a hash value that is used to select a physical link associated with the port channel and forwarding the packet and hash value to the identified port channel.

FIG. 4is a block diagram of a dispatch database (DB)400that may be used with the present invention to identify a port channel for a packet that is to be dispatched to an SCE600. Dispatch DB400is a data structure illustratively configured as a table comprising one or more entries410wherein each entry410contains a port channel field440. The port channel field440holds a value that represents a port channel that is associated with the packet. A port channel for a particular packet is identified using the DB by hashing an address contained in the packet to generate an index and using the index to select an entry410in the DB400. The contents of the port channel field440of the selected entry410is then use to identify a port channel associated with the packet. Illustratively, the address contained in the packet that is used to generate the index is a destination address associated with the destination for the packet.

FIG. 5is a high-level partial block diagram of a supervisor engine500that may be used with the present invention. The supervisor engine500comprises a backplane interface logic520, a controller530, a forwarding logic540, a processor550and a memory560. The backplane interface logic520comprises logic configured to buffer and transfer data between the supervisor engine500and the backplane220. The controller530comprises logic that is used to steer data between the backplane interface logic520, the forwarding logic540and the processor550. The forwarding logic540comprises one or more ASICs configured to process packets acquired by the supervisor engine500including making forwarding decisions for the packets and directing the backplane interface logic to forward the packets to a destination based on the forwarding decisions.

The processor550is a conventional central processing unit (CPU) configured to execute computer-executable instructions and manipulate data in the memory560. The memory560is a conventional random-access memory (RAM) comprising e.g., Dynamic RAM (DRAM) devices. The memory560includes an operating system562and configuration services564. The operating system562is a conventional operating system that comprises computer-executable instructions and data configured to support the execution of processes, such as configuration services564, on processor550. Specifically, operating system562is configured to perform various conventional operating system functions that, e.g., enable the processes to be scheduled for execution on the processor550as well as provide controlled access to various resources, such as memory560. The configuration services564is illustratively a process comprising computer-executable instructions configured to enable processor550to (1) generate configuration information that is illustratively used by the processor550to configure forwarding logic540and the PPEs330(including the dispatch DB400) and (2) configure the forwarding logic540and the PPEs330with the configuration information. In addition, configuration services564may contain code that is configured to maintain the port channels associated with the SCE network interfaces210.

FIG. 6is a high-level block diagram of an exemplary SCE600that may be used with the present invention. An example of an SCE that may be used with the present invention is the Cisco SCE2000available from Cisco Systems Incorporated. SCE600comprises one or more network interfaces610, a processor630and a memory650. The network interfaces610connect (interface) the SCE600with the network100and enable data packets to be transferred between the SCE600and the network100using various protocols, such as Ethernet. To that end, the network interfaces610comprise conventional interface circuitry that incorporates signal, electrical, and mechanical characteristics and interchange circuits needed to interface with the physical media of the network100and protocols running over that media.

The processor630is a conventional CPU configured to execute instructions and manipulate data contained in the memory650. The memory650is a conventional RAM comprising e.g., DRAM devices. The memory650contains an operating system652, policy DB654, an information DB656, packet process658and a Virtual Local Area Network (VLAN) identifier (ID) translation DB700.

The operating system652is a conventional operating system that comprises computer-executable instructions and data configured to support the execution of processes, such as packet process658, on processor630. Specifically, operating system652is configured to perform various conventional operating system functions that, e.g., enable the processes to be scheduled for execution on the processor630as well as provide controlled access to various resources on the SCE600, such as memory650. The policy DB654is a database comprising policy information that is applied to packets processed by the SCE600and the information DB656is a database comprising information about the packets. This information may include statistical information that is maintained by the SCE600for the processed packets. Packet process658is a software process comprising computer-executable instructions and data structures configured to process packets received by the SCE600in accordance with an aspect of the present invention.

The VLAN ID translation DB700holds information that is used by the SCE600to translate a VLANs associated with packets processed by the SCE600.FIG. 7is a block diagram of a VLAN ID translation DB700that may be used with the present invention. Translation DB700is a data structure that is illustratively organized as a table comprising one or more entries710wherein each entry contains an ingress VLAN ID field720and an egress VLAN ID field740. The ingress VLAN ID field720holds a value that represents a VLAN ID of a VLAN associated with a packet that is received by the SCE600from the dispatcher200. The egress VLAN ID field740holds a value that represents a VLAN ID of a VLAN that is associated with the packet before it is transferred from the SCE600back to the dispatcher200. A packet's VLAN is translated by comparing a VLAN ID associated with the packet with the ingress VLAN ID720of entries710in the database700to locate an entry710whose VLAN ID720matches the VLAN ID in the packet. The VLAN ID associated with the packet is then replaced with the VLAN ID contained in the egress VLAN ID740field of the matching entry710.

As will be described further below, packets are transferred from the dispatcher200via a physical link130to the SCE600where they are received at the network interfaces610. Each packet is associated with a particular VLAN. The processor630processes the packets which may include maintaining various statistics associated with the packets in information DB656as well as applying various policies maintained in policy DB654to the packets to determine if e.g., the packets are forwarded or dropped. For packets that are forwarded, the processor630translates a VLAN ID associated with the packets to “switch” the packets from one VLAN to another, as described above.

It should be noted that functions performed by dispatcher node200and the SCEs600, including functions that implement aspects of the present invention, may be implemented in whole or in part using some combination of hardware and/or software. It should be further noted that computer-executable instructions and/or computer data that implement aspects of the present invention may be stored in various computer-readable mediums, such as volatile memories, non-volatile memories, flash memories, removable disks, non-removable disks and so on. In addition, it should be noted that various electromagnetic signals, such as wireless signals, electrical signals carried over a wire, optical signals carried over optical fiber and the like, may be encoded to carry computer-executable instructions and/or computer data that implement aspects of the present invention on e.g., a communication network.

In network100, packets are transferred between the subscriber nodes110and the server node170via bi-directional data flows. For a particular data flow, packets traveling from a subscriber node110to the server node170travel in an upstream direction and are considered upstream packets. Likewise, packets traveling from the server node170to the subscriber node110travel in a downstream direction and are considered downstream packets.

At the dispatcher200, the PPEs330and the supervisor engine's forwarding logic540are configured such that packets for a particular data flow that are received in either direction are dispatched to the same SCE600. Dispatching packets associated with a particular data flow to the same SCE600acts to reduce complexity with regards to maintaining state for the data flow.

FIGS. 8A-Billustrate the dispatching and processing of upstream and downstream data packets, respectively, at dispatcher200in accordance with an aspect of the present invention. Referring toFIG. 8A, path830illustrates the path taken by upstream packets traveling through the dispatcher200in the upstream direction from a subscriber110to the server170. Specifically, an upstream packet is received at network interface300aon a VLAN used to communicate with the subscriber110(i.e., VLAN100). Network interface300aprocesses the packet including identifying a port channel on the SCE network interface210athat is to receive the packet. Network interface300athen hashes an address contained in the packet to select a physical link130associated with the identified port channel and transfers the packet, identified port channel and hash value to SCE network interface210a. Illustratively, the address contained in the packet used to generate the hash value is a source address of the packet.

Note that, as will be described further below, the hash value is used to select a physical data link130that is used to carry the packet to an SCE600. By virtue of selecting a physical data link130, the hash value selects an SCE600that is to receive and process the packet. Thus, the address that was used to derive the hash value acts to identify the SCE600that is to receive and process the packet.

Interface210areceives the packet, identified port channel and hash value, uses the identified port channel and the hash value to identify a physical data link130associated with the port channel and transfers the packet on the identified physical link130to an SCE600. The SCE600receives the packet and processes it including switching the packet from the subscriber's VLAN to the server's VLAN, as described above. The SCE600then transfers the packet back to the dispatcher200via a physical link130where it is received at SCE network interface210b. The SCE network interface210bprocesses the packet and forwards it to the supervisor engine400. The supervisor engine400determines that the server170can be reached through network interface300band forwards the packet to interface300b. Network interface300breceives the packet from the supervisor engine400and forwards it via the network to the server170on the server's VLAN (i.e., VLAN101).

Referring now toFIG. 8B, path850illustrates the path taken by downstream packets traveling from the server170to a subscriber110. Specifically, a downstream packet issued by the server170and destined for a subscriber110is received on the server's VLAN (e.g., VLAN101) by the dispatcher200at network interface300b. Network interface300bprocesses the packet including identifying a port channel and hashing an address contained in the packet to generate a hash value that is used to identify a physical link associated with the identified port channel. Illustratively, the address used to generate the hash value is a destination address contained in the packet. The network interface300bthen dispatches the packet to the identified port channel on interface210bby forwarding the packet, the identified port channel and the identified physical link to network interface210b. Interface210breceives the packet, identified port channel and physical link information, uses the port channel and physical link information to identify a physical link130that couples the SCE network interface210bwith an SCE600and transfers the packet on the identified physical link130. The SCE600receives the packet and processes it including switching the packet from the server's VLAN to the subscriber's VLAN. The SCE600then transfers the packet back on a physical link130to the dispatcher200where it is received at SCE network interface210a. SCE network interface210aprocesses the packet and forwards it to the supervisor engine400. The supervisor engine400determines that the subscriber110can be reached through network interface300aand forwards the packet to interface300a. Network interface300areceives the packet from the supervisor engine400and forwards it via the network to the subscriber110on the subscriber's VLAN (e.g., VLAN100).

Illustratively, packets processed by dispatcher200are IP packets that contain an IP header that conforms to the well-known IP protocol. A version of the IP protocol that may be used with the present invention is described in Request For Comments (RFC)791which is available from the Internet Engineering Task Force (IETF) and which is hereby incorporated by reference in its entirety as though fully set forth herein. It should be noted, however, that the inventive technique may be adapted to process packets that contain header information which conforms to other protocols.

FIG. 9is a block diagram of an IP header900that may be used with the present invention. IP header900comprises a version field920, an Internet header length (IHL) field925, a type of service (TOS) field930, a total length field935, an identification field940, a flags field945, a fragment offset field950, a time-to-live (TTL) field955, a protocol field960, a header checksum field965, a source IP address field970, a destination IP address field975and an options and padding field980.

The version field920specifies a value that represents a format of the IP packet header. Illustratively, this value is set to a value of 4 to indicate that the packet header is an IP version 4 (IPv4) type packet or to a value of 6 to indicate that the packet header is an IP version 6 (IPv6) type packet. The IHL field925holds a value that represents a length of the IP packet header900. The TOS field930holds a value that specifies various parameters associated with a type of service requested for the packet. The total length field935holds a value that represents the total length of the header plus a payload (not shown). The identification field940holds a value that is used to identify fragments of an IP packet associated with the header900. The flags field945holds a value that represents various flags associated with the packet containing the header900. The fragment offset field950holds a value that represents an offset value associated with a fragment of the packet associated with the header900. The TTL field950holds a value that represents a timer used to track the lifetime of the packet. The protocol field960holds a value that represents a protocol related to the packet. The header checksum field965holds a value that represents a checksum of the IP header900. The source IP address field970holds a value that represents a source IP address associated with the packet. The destination IP address field975holds a value that represents a destination address associated with the packet. The options and padding field980holds a value that represents various options associated with the packet. The padding field is used as a filler to guarantee that the payload which follows the header900starts on a 32-bit boundary.

As noted above, packets traveling between the dispatcher and the SCEs600travel on physical links130associated with port channels. Illustratively, the packets are transferred on Institute of Electrical and Electronic Engineers (IEEE) 802.1Q trunks that are carried by the physical links130. IEEE 802.1Q trunks are described in “802.1Q IEEE Standards for Local and metropolitan area networks Virtual Bridged Local Area Networks,” IEEE Std. 802.1Q, 2003 Edition, pp. 1-312, which is available from the IEEE and which is hereby incorporated by reference in its entirety as though fully set forth herein.

Packets traveling on the trunks are encapsulated in 802.1Q frames.FIG. 10is a block diagram of an 802.1Q frame1000that may be used with the present invention. Frame1000comprises a preamble field1020, a start frame delimiter (SFD) field1035, a destination address (DA) field1040, a source address (SA) field1045, a tag protocol identifier (TPID) field1050, a tag control information (TCI) field1060, a type/length field1065, a data field1070and a cyclic redundancy check (CRC) field1075.

The preamble field1020holds a value that represents a preamble that may be used to synchronize a receiver to receive the frame1000. The SFD field1035holds a value that indicates a start of the frame1000. The DA field1040holds a value that represents an address of a destination for the frame1000. The SA field1045holds a value that represents an address of the station that sourced the frame1000. The TPID field1050holds a value that identifies the frame as an IEEE 802.1Q frame. The type/length field1065holds a value that represents a length of the frame1000. The data field1070holds payload data carried by the frame1000. Illustratively, this payload data contains the packet carried by the frame1000. The CRC field1075holds a value that represents a cyclic redundancy check of the frame1000.

The TCI field1060holds VLAN tag information associated with the frame1000. Specifically, this field holds a user priority value1052, a canonical format indicator (CFI)1054and a VLAN ID1056. The user priority field1052holds a value that represents a priority level associated with the frame1000that may be used to prioritize handling of the frame1000. The CFI field1054holds a value that is used for compatibility purposes between Ethernet and token ring type networks. This value is typically set to zero. The VLAN ID field1056holds an identifier that identifies a VLAN associated with the packet contained in the data field1070.

FIG. 11is a flowchart of a sequence of steps that may be used to configure dispatcher200to identify an SCE600that is to receive a packet received by the dispatcher200and dispatch the packet to the SCE600, to perform deep packet inspection on the packet, in accordance with an aspect of the present invention. The sequence begins at step1105and proceeds to step1110where the dispatcher200receives the packet from the network100on a first VLAN at a first network interface300. Next, at step1120, the first network interface300processes the packet including generating a hash value and identifying a port channel on a first SCE network interface210, as described above. As will be described further below, the combination of port channel and the generated hash value is illustratively used to select a physical link130on which to transfer the packet to an SCE600. Thus, this combination illustratively acts to identify an SCE600that is to receive the packet. The sequence then proceeds to step1130where the packet, the port channel and the hash value are forwarded to the first SCE network interface210.

Next, at step1140, the first SCE network interface210receives the packet, port channel and hash value and uses the port channel and hash value to select a first physical data link130on which to transfer the packet to an SCE600. The packet is then forwarded on the selected physical data link130to the SCE600. Note that steps1120-1140illustratively act to dispatch the packet to the SCE600. At step1150, the SCE600receives the packet, processes it, translates the packet's VLAN from a first VLAN to a second VLAN, as described above, and returns the packet on a physical link130to the dispatcher200.

The second SCE interface210, at step1160, receives the packet on the second VLAN and forwards the packet to the supervisor engine400. At step1170, the supervisor engine400identifies a second network interface300through which the destination for the packet may be reached and forwards the packet to the identified network interface300. The network interface300receives the packet and forwards it on the second VLAN to the destination. The sequence ends at step1195.

As noted above, packets transferred to an SCE600from the dispatcher200are illustratively encapsulated in frames1000by the dispatcher200and transferred to the SCE600via trunks carried by the physical links130. The packets are placed in the payload1070portion of the frames1000. A VLAN ID of a VLAN that is associated with the packet is placed in the VLAN ID field1056of the frame. The SCE600receives the frames1000and processes them including translating the VLAN IDs1056contained in the frames1000to switch the packets contained in the frames900from a first VLAN to a second VLAN, as described above. The packets are then returned to the dispatcher200and received on the second VLAN.

FIG. 12is a flow chart of a sequence of steps that may be used to process a frame1000at an SCE600in accordance with an aspect of the present invention. The sequence begins at step1205and proceeds to step1210where the frame1000is received from the dispatcher200. Next, at step1220, the SCE600processes the received frame1000. This processing may include performing deep packet inspection of the packet contained in the frame's payload to update various statistics maintained in information DB656and enforce various policies contained in the policy DB654against the packet contained in the frame1000, as described above. At step1230, the VLAN associated with the packet is translated from a first VLAN ID to a second VLAN ID, as described above. At step1240, the SCE600transfers the frame1000back to the dispatcher200. The sequence ends at step1295.

FIG. 13is a flowchart of a sequence of steps that may be used to process an upstream packet and a downstream packet of a data flow in accordance with an aspect of the present invention. The sequence begins at step1305and proceeds to step1310where a subscriber110generates and forwards an upstream packet to a destination (e.g., server170). Next, at step1320, the dispatcher200receives the packet and processes it including dispatching the packet to an SCE600, receiving the packet from the SCE600and forwarding the received packet to the destination, as described above. At step1330, the destination receives the upstream packet. The destination then, at step1340, generates a downstream packet and forwards the generated downstream packet to the subscriber110. The packet travels downstream where it is eventually received by the dispatcher200which, at step1350, processes the downstream packet including transferring it to the same SCE600, receiving the packet from the SCE600and forwarding the received packet to the subscriber110, as described above. At step1360, the subscriber110receives the downstream packet. The sequence ends at step1395.

For example, referring to FIGS.1and11-13, assume that packets transferred between the dispatcher200and the subscriber node110are transferred on VLAN100and packets transferred between the dispatcher200and the server170are transferred on VLAN101. Further, assume that the forwarding logic540and the PPEs330have been configured by the supervisor engine500to forward packets associated with the same data flow to the same SCE600.

Now suppose the subscriber node110generates an IP packet containing an IP header900(FIG. 9) that is destined for server node170. The subscriber node110forwards the packet upstream to the server170(step1310). Specifically, the subscriber node110forwards the packet onto the network100where it is received by the service provider edge node120. The service provider edge node120forwards the packet to the dispatcher node200where it is received by the dispatcher200at network interface300a(step1110).

At network interface300a, the packet is received by the network interface's input interface logic310(FIG. 3) and transferred to a queue contained in the input queuing logic320. The packet is then dispatched to an SCE600based on an address in the packet (steps1120-1140). Specifically, the PPE330removes the packet from the queue, uses a destination address975contained in the packet along with the dispatch DB400to identify a port channel on SCE interface200athat is to receive the packet, as described above. The PPE330then generates a hash value by hashing a source address970contained in the packet to identify a physical link130within the identified port channel that is to carry the packet (step1120). Illustratively, the hash value is a number from 0-7 and the hash algorithm used to hash the source address970to produce the hash value is defined to optimally distribute traffic across the links130associated (bundled) with the identified port channel. The PPE330then forwards the packet, identified port channel and generated hash value to network interface210a. Specifically, the PPE330directs the backplane interface logic340to transfer the packet, the identified port channel and the hash value via the backplane220to network interface210a(step1130).

Network interface210areceives the packet, the identified port channel and hash value, uses the hash value to select a physical link130associated with the identified port channel and transfers the packet to an SCE600via the selected physical link130(step1140). Specifically, the network interface210areceives the packet, identified port channel and hash value from the backplane220. The network interface210athen uses the identified port channel and the hash value to identify a physical link130associated with the identified port channel that is to carry the packet. Assume the identified physical link is physical link130a. The network interface210athen encapsulates the packet in a frame1000and forwards the frame1000on a trunk carried by physical link130a.

The packet travels on the trunk via link130ato SCE600a. SCE600areceives the frame900, processes it, translates the packet's VLAN and returns the frame900to the dispatcher200(step1150). Specifically, SCE600areceives the frame1000at a network interface610and transfers the frame1000to the processor630(step1210). The processor630processes the packet contained in the payload portion of the frame1000including performing deep packet inspection of the packet to e.g., maintain various statistics and apply various policies to the packet to determine if the frame1000should be forwarded or dropped and so on. In addition, the processor630translates the VLAN associated with the packet from VLAN100to VLAN101, as described above. The processor then forwards the frame1000out a network interface610coupled to physical link130dto the dispatcher200.

The upstream packet is received by the dispatcher200at SCE interface210bwhich forwards the packet to the supervisor engine400(step1160). Specifically, the frame1000travels on link130dback to the dispatcher where it is received on VLAN101at SCE interface210b. SCE210bremoves the packet from the payload portion of the frame1000and forwards the packet and the VLAN ID of the VLAN on which the packet was received (i.e., VLAN101) to the supervisor engine400via the backplane220.

The supervisor engine400receives the packet and forwards the packet to its destination via network interface300b(step1170). Specifically, the backplane interface logic520receives the packet and its VLAN ID. The forwarding logic540examines the destination address975contained in the packet and determines that the destination (i.e., the server170) can be reached via network interface300b. The supervisor engine400then forwards the packet and its VLAN ID to network interface300bvia the backplane220. Network interface300breceives the packet and its VLAN ID and forwards the packet to the server170on VLAN101.

Now assume that the server170generates a downstream IP packet containing a header900and forwards the packet the subscriber110(step1340). Specifically, the packet is forwarded downstream from the server170through the WAN150to the dispatcher200which receives the downstream packet at network interface300b(step1110), as described above.

The network interface300bidentifies a port channel to receive the packet and generates a hash value that is used to select a physical link130associated with the identified port channel (step1120). Specifically, the PPE330at network interface300buses a destination address975contained in the packet to identify a port channel on SCE network interface210bthat is to receive the packet. The PPE330then hashes the destination address975to generate a hash value, as described above.

The network interface then forwards the packet, the identified port channel and hash value to SCE network interface210b, as described above (step1130). Network interface210breceives the packet, port channel and hash value, uses the hash value and port channel to identify a physical link130that is to be used to transfer the packet to an SCE600. Assume the identified physical link is130d. The network interface210bthen encapsulates the packet in a frame1000forwards the frame1000to SCE600avia physical link130d, as described above.

SCE600areceives the frame1000, processes the packet contained in the frame1000including translating the packet's VLAN (from VLAN101to VLAN100) and forwards the frame1000on link130aback to the dispatcher200, as described above (step1150). The frame1000is received at SCE network interface210awhich removes the packet from the frame1000and forwards the packet and its VLAN ID (i.e., VLAN100) to the supervisor engine400, as described above (step1160). The supervisor engine400processes the packet including determining that the subscriber110may be reached through network interface300aand forwards the packet and its VLAN ID to network interface300a. Network interface300athen forwards the packet to the subscriber110on VLAN100.