BRIEF DESCRIPTION OF THE DRAWINGS
The foregoing will be apparent from the following more particular description of preferred embodiments of the methods and apparatus for providing optimal identification and processing of L3 control channels, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the methods and apparatus for providing optimal identification and processing of L3 control channels.
FIG. 1 depicts a block diagram of a network environment performing processing token identifiers for L3 control channels when encapsulated in a tunneling protocol.
FIGS. 2A and 2B illustrate L3 control channel packets as used in conventional tunneling protocols.
FIGS. 3A and 3B illustrates L3 control channel packets having a token identifier for processing token identifiers for L3 control channels when encapsulated in a tunneling protocol.
FIGS. 4A and 4B depict a flow diagram of a particular method of performing processing token identifiers for L3 control channels when encapsulated in a tunneling protocol.
FIG. 5 illustrates an example network device architecture for a computer system that performs processing token identifiers for L3 control channels when encapsulated in a tunneling protocol.
DETAILED DESCRIPTION
Referring to FIG. 1, a particular embodiment of a core network 10 having a plurality of forwarding entities P1, P2. . . Pn, operable to transmit message traffic from a particular forwarding entity to another forwarding entity via a tunneling protocol, whereby each forwarding entity P1, P2. . . Pn, has an Internet Protocol (IP) address is shown. In the example embodiment depicted in FIG. 1, forwarding entity P1 operates as an ingress provider edge router while forwarding entity Pn operates as an egress provider edge router. In turn, forwarding entities P2, P3. . . Pn-1 operate as typical forwarding entities in network 10 between ingress router P1 and egress router Pn and, consequently, form at least one label switching path (LSP) therebetween. Ingress router P1 interfaces with client edge router C1 to provide interconnectivity between core network 10 and private network 11. Likewise, egress router Pn interfaces with client edge router C2 to provide interconnectivity between core network 10 and private network 12. Conceptually, the GRE protocol creates a virtual tunnel 13 between P1 and Pn (typically enabled by VRF tables at the forwarding entities). In this example embodiment, forwarding entities P1, P2. . . Pn, use the generic routing encapsulation (GRE) tunneling protocol to route and propagate packets between provider edge routers (e.g., ingress and egress routers) via the tunnel 13. It should be noted that although GRE is used as the tunneling protocol in this example configuration, other embodiments disclosed herein may use any tunneling protocol suitable for encapsulating and transmitting data in a network through a virtual tunnel.
Referring now to FIG. 2A in conjunction with FIG. 1, a typical tunneling protocol packet 14 is shown having a payload section 15, tunnel header section 16 and L3 header _1 section 17. In this example, payload section 15 includes an L3 control channel section 18 (containing L3 control channel data such as BFD data) and L3/L4 header _219. The payload section 15 is typically the organic information received by ingress router P1 in network 10 from client edge router C1 in private network 11. Alternatively, the payload section may contain network management or maintenance control data (e.g., BFD) that is generated at various core network endpoints (e.g., P1 and Pn). Upon receiving the payload 15 from client edge router C1 (or at some point shortly thereafter), ingress router P1 encapsulates the payload 15 with tunnel header 16 and L3 header_117. In effect, L3 header_117 operates as the destination address, or egress router Pn's address from FIG. 1, to properly route packet 14 through network 10.
FIG. 2B depicts an example tunneling protocol packet 20 for transmitting a BFD control message encapsulated in the GRE tunneling protocol. BFD packet 20 includes a payload section 21, GRE header section 22 and IP header_1 section 23. Payload section 21 further includes BFD echo data section 24, UDP header section 25 and IP header_2 section 26. In this example, ingress router P1 sends a BFD echo request to egress router Pn via a typical IP control channel message. The BFD echo request will cause egress router Pn to transmit an acknowledgement message back to ingress router P1. Furthermore, IP header_123 and IP header_226 both include a source IP address 27 for ingress router P1 and destination IP address 28 for egress router Pn. The UDP header section 25 contains a port number that triggers specific BFD processing when received by Pn. It should be noted that although BFD is used as the exemplary control protocol in this example, the scope of the methods and apparatus disclosed herein contemplate the implementation of any similar control channel protocol (e.g., MPLS LSP ping)
Still referring to FIG. 2B, in processing the BFD packet 20, egress router Pn performs an IP address lookup for IP header_123 to determine if the destination IP address 28 is its own address (e.g., Pn's IP address) and thus requires further processing. Since the IP header_1 section 23 is coupled with GRE header section 22, GRE tunnel decapsulation processing is triggered and egress router Pn strips GRE header section 22 and IP header_1 section 23 from BFD packet 20 leaving payload section 21. Next, egress router Pn processes IP header_226 and performs a second IP lookup operation and determines that the destination address is its own address (e.g., Pn's IP address) and requires further processing (e.g., processing the BFD echo packet 24 and UDP header section 25). Thus, in order to locally process an L3 control channel packet (e.g., BFD echo request in this example), egress router Pn must perform a second, or recursive, IP lookup operation for IP header_226 in the payload 21 of packet 20. This second/recursive IP lookup is superfluous since the destination address identity (e.g., Pn's IP address) has already been ascertained from the initial IP lookup operation. Thus, the routing lookup processing that handles the control channel data is unnecessarily doubled and prevents the router from performing at an optimal level of efficiency.
FIG. 3A depicts an example embodiment of an L3 control channel packet 30 encapsulated in a tunneling protocol. L3 control channel packet 30 includes a payload section 31, generic token identifier 32, tunnel header section 33 and L3 Header_135. Payload section 31 further includes L3 control channel section 34 (e.g., MPLS LSP ping) for implementing a control channel operation. To obviate the need for a redundant secondary L3 lookup (such as an IP lookup), generic token identifier 32 is substituted for the L3/L4 Header_219 as shown in FIG. 2A. Generic token identifier 32 is a non-IP (does not contain address data), type-length-value (TLV) bit pattern that is used in demultiplexing the control channel at the destination router. Thus, instead of performing a costly primary L3 lookup (similar to the processing of IP header section 23 previously discussed), the generic token identifier 32 simply alerts the forwarding entity (e.g., tunnel end point) that local processing of the packet payload 31 is required (e.g., that the packet contains control channel data). Furthermore, when the generic token identifier 32 is maintained separately from the tunneling header as in FIG. 3A, the generic token identifier 32 may indicate a specific control channel protocol (e.g., BFD) while remaining generic with respect to the tunneling protocol (e.g., MPLS). For example, in using the configuration shown in FIG. 3A, the same generic BFD token identifier may be used for any tunneling protocol that routes a BFD control channel packet.
Alternatively, as depicted in the example embodiment of FIG. 3B, the tunnel header 42 of control channel packet 40 may include the token identifier 45 such that processing of only the tunnel header 42 is required for determining the need for local processing of the payload. In this embodiment, fewer clock cycles are needed to process the single tunnel header 42 as compared to processing both the generic token identifier 32 and tunnel header 33 in packet 30. However, unlike the generic token identifier 32 of packet 30, token header 42 is specific to a particular tunneling protocol and cannot port to other tunneling technologies. As such, this approach typically extends the tunneling protocol such that the particular tunneling headers/labels must be modified accordingly in order to account for the additional token header data. For instance, in reference the configuration in FIG. 3B, assume that token identifier 45 is specific to a BFD control channel packet 40 an MPLS tunneling protocol. In this example, the BFD token identifier 45 cannot be used to tunnel BFD control channel data through an L2TP enabled network since the token identifier 45 is specific to MPLS. Despite this, as shown in FIG. 3A, generic token identifier 32 may be standardized across any number of tunneling protocols for specific L3 control channels since the generic token identifier 32 is separate from the tunnel header 33 (and thus processed separately). Nonetheless, more clock cycles are expended in such a configuration (as shown in FIG. 3A) since both the generic token identifier 32 and tunnel header 33 are processed separately.
Referring now to FIG. 3A in conjunction with FIG. 1, when packet 30 is propagated through network 10 via forwarding entities P2, P3. . . Pn−1 , each forwarding entity performs an address lookup operation for L3 Header_135 (e.g., an IP lookup operation). Once a forwarding entity P2, P3. . . Pn−1 determines that the L3 Header_135 address is not the forwarding entity address, the packet 30 is forwarded/propagated to the next hop in the tunnel 13. Thus, each forwarding entity performs one, and only one, address lookup for packet 30.
Similarly, egress router Pn (or any L3 control channel destination router) performs only one address lookup for control channel packet 30 upon its receipt. Since egress router Pnhas already ascertained that the destination address is the egress router address (via the address lookup operation for L3 Header—1 35, 44), the generic token identifier 33 in FIG. 3A (or token identifier 45 in FIG. 3B) merely instructs egress router Pn that local processing of the packet is necessary. Thus, significantly fewer clock cycles are required in processing token identifier 33, 45 vis-à-vis performing an address lookup operation (e.g., an IP lookup).
Flow charts of the presently disclosed methods are depicted in FIGS. 4A and 4B. The rectangular elements are herein denoted “processing blocks ” and represent computer software instructions or groups of instructions. Alternatively, the processing blocks represent steps performed by functionally equivalent circuits such as a digital signal processor circuit or an application specific integrated circuit (ASIC). The flow diagrams do not depict the syntax of any particular programming language. Rather, the flow diagrams illustrate the functional information one of ordinary skill in the art requires to fabricate circuits or to generate computer software to perform the processing required in accordance with the present invention. It should be noted that many routine program elements, such as initialization of loops and variables and the use of temporary variables are not shown. It will be appreciated by those of ordinary skill in the art that unless otherwise indicated herein, the particular sequence of steps described is illustrative only and can be varied without departing from the spirit of the invention. Thus, unless otherwise stated the steps described below are unordered meaning that, when possible, the steps can be performed in any convenient or desirable order.
Referring now to FIGS. 4A and 4B, a method 150 for transmitting IP control packets in a network having a plurality of forwarding entities operable to transmit message traffic from a particular forwarding entity to another forwarding entity via a tunneling protocol, wherein each forwarding entity has an Internet Protocol (IP) address is shown. The method begins with processing block 200 which discloses receiving, at a source forwarding entity in the network, a request for an L3 control packet, wherein the L3 control packet includes control channel data for implementing a control channel operation. Processing block 201 then states adding a token identifier to the L3 control packet, the token identifier indicating that local processing of the L3 control packet is required. Processing block 202 recites adding a token identifier that is specific to a particular L3 control channel protocol (e.g., a token identifier specific to the BFD control channel protocol).
In addition, processing block 203 states adding a destination address to the L3 control packet in accordance with the tunneling protocol. Typically, a destination address and a tunneling header, or label, are added to the L3 control packet in accordance with the tunneling protocol in order to route the packet through the network. For example, a GRE header and a destination IP address (and often a source IP address) are added to an IP control channel packet that is tunneled through a network using a GRE tunneling protocol.
The method continues with processing block 204 which discloses transmitting, from the source forwarding entity in the network, the L3 control packet with the token identifier to a second forwarding entity in accordance with the tunneling protocol.
Processing 205 states receiving, at the second forwarding entity, the L3 control packet with the token identifier. Processing block 206 then discloses processing, at the second forwarding entity, the L3 control packet with the token identifier.
Processing block 207 recites identifying the destination address in the L3 control packet. Processing block 208 states performing an address lookup operation to determine if the second forwarding entity address is the same as the destination address. The method still continues with processing block 209 which discloses, upon determining that the second forwarding entity address is the destination address, processing the token identifier to determine if local processing of the L3 control packet is required. Processing block 210 then recites that, in response to processing the token identifier, processing the control channel data of the L3 control packet
Processing block 211 states, upon determining that second forwarding entity address is not the destination address, transmitting the L3 control packet with the token identifier to another forwarding entity in accordance with the tunneling protocol.
FIG. 5 illustrates example architectures of a network device that is configured as a host computer system 340. The network device 340 may be any type of computerized system such as a personal computer, workstation, portable computing device, mainframe, server or the like. In this example, the system includes an interconnection mechanism 311 that couples a memory system 312, a processor 313, a communications interface 314, and an I/O interface 315. The communications interface 314 and I/O interface 315 allow the computer system 340 to communicate with external devices or systems.
The memory system 312 may be any type of computer readable medium that is encoded with an application 355-A that represents software code such as data and/or logic instructions (e.g., stored in the memory or on another computer readable medium such as a disk) that embody the processing functionality of embodiments of the invention for the agent 355 as explained above. The processor 313 can access the memory system 312 via the interconnection mechanism 311 in order to launch, run, execute, interpret or otherwise perform the logic instructions of the applications 355-A for the host in order to produce a corresponding agent process 355-B. In other words, the agent process 355-B represents one or more portions of the agent application 355-A performing within or upon the processor 313 in the computer system.
It is to be understood that embodiments of the invention include the applications (i.e., the un-executed or non-performing logic instructions and/or data) encoded within a computer readable medium such as a floppy disk, hard disk or in an optical medium, or in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the memory system 312 (e.g., within random access memory or RAM). It is also to be understood that other embodiments of the invention can provide the applications operating within the processor 313 as the processes. While not shown in this example, those skilled in the art will understand that the computer system may include other processes and/or software and hardware components, such as an operating system, which have been left out of this illustration for ease of description of the invention.
Having described preferred embodiments of the invention it will now become apparent to those of ordinary skill in the art that other embodiments incorporating these concepts may be used. Additionally, the software included as part of the invention may be embodied in a computer program product that includes a computer useable medium. For example, such a computer usable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having computer readable program code segments stored thereon. The computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals. Accordingly, it is submitted that that the invention should not be limited to the described embodiments but rather should be limited only by the spirit and scope of the appended claims.
Patent Application
20080008168
