Inter-domain Optimization Trigger in a PCE-based Environment

Figure 1 is a schematic block diagram of an exemplary computer network 100 comprising areas 104-110 interconnected by area 102 (a “backbone” area). area 102 shares area border routers (ABRs) with each area 104-110, namely, ABR1-2 with 104, ABR3-4 with area 106, ABR5 with area 108, and ABR6 with area 110. In addition, areas 104-110 share their area border routers ABR1-6 with backbone area 102. Areas 104-110 have exemplary intradomain routers A-D, respectively, while area 110 also has intradomain router E. Also, withinarea 106 are exemplary nodes (e.g., routers) n1-n4. Those skilled in the art will understand that any number of routers and nodes may be used in the areas, and that the viewshown herein is for simplicity. As used herein, an area is a collection of routers that share full network topology information with each other but not necessarily with routers outside the area. A collection of areas may be contained within a single autonomous system (AS). The term area as used herein also encompasses the term “level” which has a similar meaning for networks that employ IS-IS as their interior gateway protocol (IGP), in which case the area border routers ABR1-6 are embodied as level 1/level2 (L1L2) routers. These examples are merely representative. Areas and levels are generally referred to herein as “domains.” Also, the terms ABR, L1L2 router, and more generally, border routers, are used interchangeably herein. 

Data packets may be exchanged among the areas 102-110 using predefined network communication protocols such as the Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP), Asynchronous Transfer Mode (ATM) protocol, Frame Relay protocol, Internet Packet Exchange (IPX) protocol, etc. Routing information may be distributed among the routers of the areasusingpredetermined IGPs, such as conventional distance-vector protocols or, illustratively, link-state protocols, through the use of IGP Advertisements. 

Figure 2 is a schematic block diagram of an exemplary router 200 that may be advantageously used with the present invention as an intradomain router or a border router. The router comprises a plurality of network interfaces 202, a processor 204, and a memory 208 interconnected by a system bus 206. The network interfaces 202 contain the mechanical, electrical and signaling circuitry for communicating data over physical links coupled to the network 100. The network interfaces may be configured to transmit and/or receive datausing a variety of different communication protocols, including, inter alia, TCP/IP, UDP, ATM, synchronous optical networks (SONET), wireless protocols, Frame Relay, ethernet, Fiber Distributed Data Interface (FDDI), etc. 

The memory 208 comprises a plurality of storage locations that are addressable by the processor 204 and the network interfaces 202 for storing software programs and data structures associated with the present invention. The processor 204 may comprise necessary elements or logic adapted to execute the software programs and manipulate the data structures, such as routing table 218. A router operating system 220, portions of which are typically resident in memory 208 and executed by the processor, functionally organizes the router by, inter alia, invoking network operations in support of software processes and/or services executing on the router. These software processes and/or services include PCC/PCE process 210, routing services 212, routing information Base (RIB 216), TE services 222, and RSVP services 214. It will be apparent to those skilled in the art that other processor and memory means, including various computer-readable media, may be used to store and execute program instructions pertaining to the inventive technique described herein. 

Routing services 212 contain computer executable instructions executed by processor 204 to perform functions provided by one or more routing protocols, such as IGP, e.g. OSPF and IS-IS. These functions may be configured to manage a forwarding information database (not shown) containing, e.g., data used to make forwarding decisions. TE services 222 contain computer executable instructions for operating TE functions in accordance with the present invention. Examples of Traffic Engineering are described in RFC 3209, RFC 3784, and RFC 3630 as incorporated above, and in RFC 3473, entitled, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) extensions dated january 2003, which is hereby incorporated by reference in its entirety. RSVP services 214 contain computer executable instructions for implementing RSVP and processing RSVP messages in accordance with the present invention. RSVP is described in RFC 2205, entitled Resource ReSerVation Protocol (RSVP), and in RFC 3209, entitled RSVP-TE: extensions to RSVP for LSP Tunnels, both as incorporated above. 

Routing table 218 is illustratively resident in memory 208 and used to store routing information, including reachable destination address prefixes and associated attributes. These attributes include next-hop information used by exemplary router 200 to reach the destination prefixes and an associated metric (e.g., cost) of reaching the destination prefixes. The routing table 218 is illustratively maintained and managed by RIB 216. To that end, the RIB 216 maintains copies of routes (paths) provided by the routing protocols, such as IGP, in order to compute best paths/routes for installation into the routing table 218. 

Changes in the network topology may be communicated among routers 200 using a link-state protocol, such as the conventional OSPF and IS-IS protocols. Suppose, for example, that a communication link fails within an AS or a cost value associated with a network node changes. Once the change in the network’sstate is detected by one of the routers, that router may flood an IGP Advertisement communicating the change to the other routers in the AS. In this manner, each of the routers eventually “converges” to an identical view of the network topology. 

Figure 3 is a flowchart illustrating a sequence of steps for triggering optimization in accordance with the present invention. Sequence 300 starts at step 302 and continues to step 304 where the event PCE (e.g., ABR3) detects the event, such as, e.g., through an IGP Advertisement (e.g., for the appearance of link n1-n2). In step 306, the event PCE sends the event notification to the other PCEs (ABR1-6, except ABR3) through the use of IGP Extension Object 400. Notably, the event PCE may first decide whether it is beneficial to send the request. 

At step 308, the other PCEs receive the event notification. If configured to do so, in step 310 the receiving PCE may determine whether any LSRs in its domain have requested a TE-LSP that would benefit from the event. If not, the sequence ends at step 328. Otherwise, the sequence continues to step 312, where the PCE (a source PCE) sends the event notification to the LSRs in its domain. An LSR receives the notification in step 314, and if it is not a head-end node at step 316, the LSR ignores the notification (aside from perhaps forwarding it on to other LSRs in its domain), and the sequence ends at step 328. If the LSR is a head end node, it sends an optimization request (optionally jittered) to its local source PCE in step 318. Notably, the head-end node may first determine for which TE-LSPs, if any, to send an optimization request, as described above. 

The source PCE receives the optimization request in step 320, and in step 322 it checks if the TE-LSP in the request would benefit from optimization based on the event domain. If there would be no benefit in step 324, the source PCE rejects the request, sends an error message to the requesting head-end node, and the sequence ends in step 328. However, if at step 326 it is determined that the TE-LSP could benefit from optimization, the source PCE processes the received optimization request. Once the request is processed, the sequence ends in step 328.