Network Working Group Peng He Internet Draft Gregor v. Bochmann Expires: March 2007 University of Ottawa September 21, 2006 A Novel Framework for Inter-area MPLS Optimal Routing draft-he-ccamp-optimal-routing-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on March 21, 2007. Abstract We propose a novel framework for inter-area MPLS optimal routing. The key to our proposal lies in deploying an overlaid star optical network in the OSPF backbone area and introducing the concept of "virtual area border routers" (v-ABRs). Compared with other proposals, our framework can provide globally optimized inter-area routing and has very good compatibility to existing traditional IP/MPLS routers. He and Bochmann Expires March 21, 2007 [Page 1] Internet-Draft Inter-area Optimal Routing Framework September 2006 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Terminology....................................................2 2. Introduction...................................................3 2.1. What's The Problem........................................3 2.2. Current Approaches........................................4 3. The Novel Framework for Inter-area MPLS Optimal Routing........5 3.1. The Basic Idea............................................5 3.1.1. Overview of Agile All-Photonic Network (AAPN)........5 3.1.2. Deploying AAPN in the OSPF Backbone Area.............6 3.2. The Routing-Info Component................................7 3.3. The Path Computation Component............................8 3.4. The Signalling Component..................................8 3.4.1. Path Message in the Head-End Area....................9 3.4.2. Path Message in the Backbone Area....................9 3.4.3. Path Message in the Tail-end Area...................10 3.4.4. Resv Message........................................10 4. Further Considerations........................................11 5. Generalization of the Proposed Routing Framework..............12 6. Security Considerations.......................................13 7. IANA Considerations...........................................13 8. Conclusions...................................................13 9. Acknowledgments...............................................13 10. References...................................................14 Author's Addresses...............................................15 Intellectual Property Statement..................................15 Disclaimer of Validity...........................................16 Copyright Statement..............................................16 Acknowledgment...................................................16 1. Terminology OSPF: Open Shortest Path First CSPF: Constraint-based Shortest Path First LSP: Label Switched Path LSR: Label Switched Router He and Bochmann Expires March 21, 2007 [Page 2] Internet-Draft Inter-area Optimal Routing Framework September 2006 LSDB: Link State Database RSVP: Resource Reservation Protocol AAPN: Agile All-Photonic Network 2. Introduction Currently, several carriers have multi-area networks, and many other carriers that are still using a single IGP area may have to migrate to a multi-area environment as their network grows and approaches the single area scalability limits [RFC4105]. Hence, it would be useful and meaningful to extend current MPLS TE (Traffic Engineering) capabilities across IGP areas to support inter-area resources optimization. That is why RFC4105 [RFC4105] was recently published to define detailed requirements for inter-area MPLS traffic engineering and ask for solutions. In this draft, we consider the Open Shortest Path First (OSPF) [RFC2328, RFC3630] IP routing protocol, which is commonly used for routing within a single administrative domain and adopted by MPLS and GMPLS (Generalized MPLS) (with extensions). 2.1. What's The Problem OSPF supports large networks through multiple OSPF areas: one backbone area (Area0) surrounded by non-backbone areas. Area border routers (ABR) are located at the border between the backbone and the non-backbone areas. An inter-area connection normally starts in a non-backbone area, traverses a backbone area, and terminates in another non-backbone area. MPLS TE mechanisms that have been deployed today by many carriers are limited to a single IGP area and can not be expanded to multi-areas directly. The limitation comes more from the routing and path computation components than from the signalling component. This is basically because the OSPF/OSPF-TE hierarchy limits topology visibility of head-end LSRs (Label Switch Routers) to their area, and consequently head-end LSRs can no longer run a CSPF algorithm to compute the shortest constrained path to the tail-end, as CSPF requires the whole topology information in order to compute an end- to-end shortest constrained path. For an example, Figure 1 shows a common multi-area network and we suppose RT1 in Area1 is the source node while RT6 in Area2 is the destination. Generally speaking, a non-backbone area (e.g., Area1 in Figure 1) often has multiple ABRs (existing points). One ABR might be He and Bochmann Expires March 21, 2007 [Page 3] Internet-Draft Inter-area Optimal Routing Framework September 2006 much closer to the destination of a requested MPLS connection than another. Because the head-end node does not have the entire topology, it does not know which ABR is the best choice. In Figure 1, how could R1 choose an optimum ABR in Area1 to the destination RT6? Through local optimization, R1 may select ABR2 to be on the path, but how does ABR2 know what the best path is to go to RT6? Although local optimization can be done in each of the respective areas along the inter-area path (RT1 to RT6), the simple summation of the three local optimizations does not necessarily lead to a global optimization. What many carriers want is to optimize their resources as a whole. Therefore, the question of how to implement inter-area routing with global optimization guarantee is a key issue in inter-area traffic engineering. 2.2. Current Approaches Most current approaches for inter-area routing center on the "how-to" issue, that is, how to find out an inter-area route (not optimal and not dynamic) and how to build up this path through the inter-area signalling process. The per-area approach uses a two-step method to compute an inter-area route: find out a "loose inter-area route" first through topology aggregation/abstraction, then resolve the loose route into a strict path, area by area. Actually, this per area approach would always lead to sub-optimal resource utilization. Another segment approach divides an inter-area path into two segments, one in Area1 and one in Area0 & Area2 (see Figure 1 for a rough look). Optimal routing of the 1st segment is done first by the head-end LSR; then based on the 1st segment, a far-end ABR (e.g., ABR5) computes the 2nd segment. Obviously, this approach can not achieve global route optimization either. PCE (Path Computation Element)-based approaches [PCE-ARC] are the only category of approaches that can provide global optimization. But this needs building up an independent overlay external PCE network that covers all the areas, and defining and implementing many associated new protocols. He and Bochmann Expires March 21, 2007 [Page 4] Internet-Draft Inter-area Optimal Routing Framework September 2006 <---------Area1---------><------Area0-------><-------Area2-----> --- ---- ---- --- |RT2|--|ABR1|-----...------|ABR4|---|RT6| / --- ---- ---- / --- \ / / \ --- --- ---- ---- / \ --- |RT1|---|RT3|---------|ABR2| ... |ABR5|-----------|RT8| --- --- ---- ---- \ / --- \ / \ / \ --- --- / ---- ---- \ --- / |RT4|----|RT5|--|ABR3|-----...------|ABR6|---|RT7| --- --- ---- ---- --- - ABR1, ABR2, ABR3: Area0-Area1 ABRs - ABR4, ABR5, ABR6: Area0-Area2 ABRs Figure 1 : A common network with multiple OSPF areas. 3. The Novel Framework for Inter-area MPLS Optimal Routing 3.1. The Basic Idea In this draft, we propose a novel framework that deploys an overlaid star optical network in the backbone area so as to implement global resource optimization in an efficient and distributed manner. The star topology can help to achieve globally-optimized routing (as explained later), and the overlaid star can provide high reliability. AAPN (Agile All-Photonic Networks) is a representative example of overlaid star optical networks. Hence we use AAPN to represent overlaid star networks in the following context of this draft. 3.1.1. Overview of Agile All-Photonic Network (AAPN) As shown in Figure 2, an AAPN [AAPN-ARC] consists of a number of hybrid photonic/electronic edge nodes connected together via several (not less than two) load-balancing core nodes and optical fibers to form an overlaid star topology. Note that there are no direct physical links among these cores. By introducing concentrating devices, AAPN can support up to 1024 edge nodes [AAPN-TOP]. Each core node contains a stack of bufferless transparent photonic space switches (one for each wavelength). A scheduler at each core node is used to dynamically allocate timeslots over the various wavelengths to each edge node. An edge node contains a separate buffer for the traffic destined to each of the other edge nodes. Traffic aggregation is performed in these buffers, where packets are collected together He and Bochmann Expires March 21, 2007 [Page 5] Internet-Draft Inter-area Optimal Routing Framework September 2006 in fixed-size slots (sometimes called bursts) that are then transmitted as single units across the AAPN via optical links. At the destination edge node the slots are partitioned, with reassembly as necessary, into the original packets that are sent to the outside routers. The term "agility" in AAPN describes its ability to deploy bandwidth on demand at fine granularity, which radically increases network efficiency and brings to the user much higher performance at reduced cost. --- --- |EN3|---|RT8| --- --- | | --- | v --- |RT1| | to CN2 /|RT4| --- \ --- ----- --- / --- \|EN1|------| CN1 |------|EN4|/ / --- \ /| |\ / --- \ --- / \ / ----- \ / \ --- |RT2|/ \/ \/ \|RT5| --- /\ /\ / --- / \ ----- / \ / --- / \| CN2 |/ \ --- / |EN2|------| |------|EN5| --- / --- ----- --- \ |RT3|/ | | to CN1 \ --- --- | | ^ |RT6| --- | | --- |RT7| --- --- |EN6| --- - CN: Core Node - EN: Edge Node - RT: Router Figure 2 : Agile All-Photonic Network (AAPN) Overlaid Star Topology. 3.1.2. Deploying AAPN in the OSPF Backbone Area AAPN is more suitable to be used in multi-area network environment due to its agility at the core and large capacity. The direct and natural way to deploy an AAPN in the OSPF backbone area is like this: the core nodes are located in the middle of Area0 and the edge nodes act as ABRs at the border between Area0 and other non-backbone areas. However, in this scheme, inter-area routing with global optimization still can not be guaranteed. Therefore, we adopt a novel way of deploying OSPF over an AAPN that interconnects several OSPF areas to He and Bochmann Expires March 21, 2007 [Page 6] Internet-Draft Inter-area Optimal Routing Framework September 2006 provide such guarantee, as shown in Figure 3. This "overlapped" OSPF architecture is fundamental for our inter-area MPLS optimal routing framework. In details, our proposed framework consists of three main components, namely the routing-info, path computation and signalling components, as described in the following sections. Note: due to the symmetric architecture of AAPN (see Fig. 2), we use the "bundle" [RFC4201] concept to further reduce the overhead traffic to the outside. That is, all the links from one edge node to the core nodes are exported as one TE link. Similarly, the overlaid core nodes in AAPN are, if necessary, exported as one core node, named as "the core" (see Figure 3). <--------------Area1-----------------><-----------Area2----------> <---------Area0--------> --- ---- ---- --- |RT2|--|EN1 | |EN4 |---|RT6| / --- ---- \ / ---- / --- \ / \ ------ / / \ --- --- / ---- \| THE |/ ---- / \ --- |RT1|----|RT3|----------|EN2 |---| CORE |---|EN5 |-----------|RT8| --- \ --- / ---- /| |\ ---- \ / --- \ / / ------ \ \ / \ --- --- / ---- / \ ---- \ --- / |RT4|---|RT5|---|EN3 | |EN6 |---|RT7| --- --- ---- ---- --- <-------------sub-path1-------------><--------sub-path2----------> Figure 3 : Our framework deploys AAPN as backbone area (Area0). 3.2. The Routing-Info Component This component is responsible for the discovery of the TE topology, which can be ensured through OSPF [RFC2328] and OSPF-TE [rfc3630]. As shown in Figure 3, after deploying AAPN as backbone area, we further expand the OSPF non-backbone areas a little step so that there is an overlap between Area0 and each expanded non-backbone area. Then the AAPN edge nodes located in the overlap (see the top of Figure for the overlap), together with their direct TE links to the core, and the associated part of the core, belong to both the Area0 and a non- backbone area. In such a scenario, legacy routers in a non-backbone area see related AAPN edge nodes as normal internal IP/MPLS routers, see the AAPN TE links as normal internal links and see the associated part of the core as the (only) ABR of their non-backbone area. In other words, a legacy router sees what it can see in its area about He and Bochmann Expires March 21, 2007 [Page 7] Internet-Draft Inter-area Optimal Routing Framework September 2006 the core as an ABR, which we call a virtual-ABR (v-ABR). For each legacy router in an expanded non-backbone area, the exchange and distribution of routing/TE information is just like in any other standard OSPF/OSPF-TE area. While within the Area0 (within the AAPN), the AAPN edge nodes that belong to the same non-backbone area can be organized as a big virtual router and one edge node in each virtual router is selected as the head of this virtual router. Then the area-specific reachability information is exchanged among these heads and distributed to each edge node per area and then outside routers. Therefore, it is the head edge node that actually performs the functions of the virtual-ABR, that is, distributing area-specified reachability information. Note that only the reachability (not TE) information, which is enough for our framework, is exchanged among virtual routers, and hence among non-backbone areas. 3.3. The Path Computation Component In our framework, an inter-area LSP can be considered consisting of two segments as shown in the bottom Figure 3: one in the head-end (expanded) area (sub-path1) and one in the tail-end (expanded) area (sub-path2). The core connects these two segments/sub-LSPs to form a complete inter-area LSP. The most interesting thing is that local routing optimization (through CSPF) with both of these two sub-LSPs can lead naturally to a globally-optimized inter-area LSP. As seen in Figure 3, this is due to the particular star topology of the AAPN architecture and the load-sharing core nodes that can be viewed as one single virtual router (v-ABR) from the outside. The local routing optimization in the head-end area can be performed by the source LSR, which takes the TE topology and LSP constraints as input. While in the tailend area, local routing optimization is done by one of the edge nodes in the area (see next section for details). Obviously, dynamic inter-area routing can be implemented in our proposed framework. 3.4. The Signalling Component This component is responsible for the establishment of the LSP along the computed path. In Figure 3, consider the case that a source LSR (RT1) in Area1 wants to set up a LSP to a destination LSR (RT8) in Area2. RT1 must first compute an optimized path to the virtual-ABR of Area1 (v-ABR1) through CSPF, and then signal this establishment He and Bochmann Expires March 21, 2007 [Page 8] Internet-Draft Inter-area Optimal Routing Framework September 2006 request to the network. RSVP with TE extension (RSVP-TE) [RFC2205, RFC3209] can be used as the signalling protocol. 3.4.1. Path Message in the Head-End Area As shown in Figure 4, RT1 starts the signalling process by creating a RSVP Path message with two objects inserted, namely LABEL_REQUEST Object (LRO) to request a label binding for the path, and EXPLICIT_ROUTE object(ERO) to indicate the computed explicit path (with one sub-object per hop). However, RT1 has to use the loose ERO sub-objects for the hops outside Area1. In Figure 3, the ERO specifies the explicit path as RT1->RT3->EN2->v-ABR1->RT8, where RT8 is a loose ERO sub-object. Then, RT1 sends the Path message to the next hop defined in the ERO, which is RT3. RT3 (a non AAPN node) receives the Path message and processes it as defined by RSVP-TE: 1. Checks the message format to make sure everything is OK, 2. Performs admission control to check the required bandwidth, 3. Stores the "path state" from the Path message in its local Path State Block (PSB) to be used by the reverse-routing function, and 4. If successful, deletes the 1st sub-object (itself) in the ERO and forwards the Path message according to the new 1st sub-object (next hop) in the ERO, in our case, EN2. 3.4.2. Path Message in the Backbone Area EN2, an AAPN edge node, receives the Path message from RT3 and checks the contained ERO. If EN2 finds that the IP address of the 2nd sub- object in the ERO is a v-ABR and the 3rd sub-object (with the loose attribute) is beyond Area1, then EN2 has the task of resolving the loose sub-object into strict ones. In our case, there is one loose sub-object, RT8, which represents the destination of the requested LSP. Although EN2 can not find a strict path from v-ABR1 to RT8 by itself, it knows who can. First, by checking the inter-area reachability information and internal parameters, EN2 finds out which group of edge nodes (also which associated v-ABR) locates in the same non-backbone area as RT8. In Figure 4, these are EN4, EN5 and EN6 (v- ABR2). Second, it selects an edge node among them randomly, e.g., EN4. In the third step, EN2 removes the first two sub-objects (itself and v-ABR #1) from the ERO of the original received Path message, and inserts v-ABR2 at the top, then forwards the modified Path message to EN4. He and Bochmann Expires March 21, 2007 [Page 9] Internet-Draft Inter-area Optimal Routing Framework September 2006 When EN4 receives the Path message and finds that the 1st sub-object in the received ERO is v-ABR2, together with a loose second sub- object, RT8, it knows that it should find an explicit path between these two sub-objects. As shown in Figure 3, EN4 is capable to do the resolving work because EN4 and RT8 reside in the same expanded area, Area2. EN4 finds the optimized explicit path v-ABR2->EN5->RT8. EN4 then replaces the ERO object in the received Path message with a new ERO object that stores the resolved explicit route (EN5->RT8). Finally, EN4 forwards the new modified Path message to EN5 as if it were forwarded from EN2 by using EN2's data (IP address, etc.). We call this process a Path message handoff. At the same time, EN5 also sends an acknowledge message (containing the resolved path) to EN2 (Figure 5). From the above handoff process, we can see that only the area-specific reachability (not TE) information needs to be exchanged among areas. In our proposal, TE information is organized within each area. 3.4.3. Path Message in the Tail-end Area The edge node EN5 receives the Path message and believes it is from EN2. Since all the sub-objects in the received ERO are strict, EN5 processes this Path message in a standard way, just as RT3 did in Area1, and then forwards the processed Path message to RT8. 3.4.4. Resv Message When the destination, RT8, gets the Path message, it responds to this establishment request by sending a RSVP Resv message. The purpose of this response is to have all routers along the path perform the Call Admission Control (CAC), make the necessary bandwidth reservations and distribute the label binding to the upstream router. As defined in standard ESVP-TE [RFC3209], the label is distributed using the Label Object in the Resv message. The labels sent upstream become the output labels for the routers receiving the label object. The label that a router issues upstream become the inbound label used as the lookup into the hardware output tag table. The reservation- specific information is stored in the local reservation state block (RSB) of each router. When the AAPN edge node EN5 receives the Resv message from downstream (RT8), it starts internal AAPN signalling to ask the core to set-up a connection from EN2 to EN5 (omit v-ABR1&2). If bandwidth is available for this connection, the core informs both EN2 and EN5. EN5 then sends a Resv message to EN1. Note that it is an internal choice of the AAPN to select a label, for instance, a timeslot number, a wavelength, or a normal MPLS label. He and Bochmann Expires March 21, 2007 [Page 10] Internet-Draft Inter-area Optimal Routing Framework September 2006 The Resv message makes its way upstream (see Figure 4), hop by hop, and when it reaches the source LSR, RT1, the inter-area path is set- up as: RT1->RT3->EN2->v-ABR1->v-ABR2->EN5->RT8. Now, a globally optimized inter-area LSP is set-up. It can be maintained and torn- down just as any normal intra-area LSP tunnel. <-------------Area1---------------><------------Area2----------> <--------Area0--------> ---- |EN4 | ------ / ---- --- --- ---- | THE |/ . ---- --- |RT1|----|RT3|----------|EN2 |---| CORE |--------|EN5 |------|RT8| --- --- ---- | | . ---- --- . . ------ . . . . . . . . . . .PATH======341=========>. . . . t . .PATH===342=======>. . . i . .<=================.=Hand=>. . m . . . off . . e . . . .PATH=343=>. . . . . . . . . . .<=344=RESV. v . .<=========344=========RESV. . .<=========344======RESV. . . Figure 4 : Inter-area LSP Signaling Process.(34x means Section 3.4.x) 4. Further Considerations Contrary to other inter-area proposals, our proposal can provide globally-optimized inter-area routing and does not require any changes on existing traditional IP/MPLS routers, hardware or software, to implement (good backward compatibility). Furthermore, there is no node that has global TE information. Instead, the TE information is distributed on a per-area basis and only area-specific reachability (not TE) information is exchanged among areas. Global optimization is achieved through cooperation and interaction between AAPN edge nodes in different areas (Path message handoff). In addition, for the 2nd half of an inter-area LSP (in the tail-end area), the optimized routing computation is done by an AAPN edge node randomly chosen in the tail-end area. Hence, load-sharing among these edge nodes is achieved. Under our proposed framework, inter-area routing can be dynamic. In addition, re-optimization of an inter-area TE LSP can also be implemented, either locally within an area (by the head-end LSR for He and Bochmann Expires March 21, 2007 [Page 11] Internet-Draft Inter-area Optimal Routing Framework September 2006 the 1st half or by an edge node for the 2nd half of LSP) or globally by the head-end LSR (end-to-end re-optimization). Regarding inter-area QoS, there is not much work left. Current single area QoS mechanisms [RFC2475, RFC 3270] can be expanded directly to multiple areas and to AAPN. As seen in Figure 3, our proposal keeps OSPF's hierarchical structure and just expands non-backbone areas a little. Hence the scalability of our proposal is as good as OSPF/OSPF-TE [RFC2328, RFC3630]. Our proposed framework also supports diversely-Routing of inter-area TE LSPs, as required in RFC4105 [RFC4105]. As shown in Figure 3, diversely routing can be deployed in Area 1 and 2 independently and optimally, and then the AAPN residing in the backbone area connects them together. 5. Generalization of the Proposed Routing Framework The routing concepts discussed in this draft are based on the assumption that there are a number of edge nodes (that are connected with other routers - through traditional Internet technology - and belonging to the same OSPF area) and these edge nodes can establish optical connections between one another in an agile manner and can adjust the bandwidth of each connection in an agile manner according to the varying bandwidth that is required by the IP traffic. We think any agile optical switching technology (burst switching, TDM (Time- Division-Multiplexing), or routed wavelength (with less bandwidth flexibility)) may be used. Our proposal is not limited to AAPNs, it is actually applicable in a much larger context. The fundamental ideas abstracted from our proposal are: (1) a "load-symmetrical" network (optical mostly) as backbone, (2) overlap between backbone and non-backbone areas, and (3) virtual-ABR. A load-symmetrical optical network is a network that can provide one or several optical connections for each edge node pair (source-destination pair) and the load among the several optical connections of each edge node pair is balanced. Hence the "bundle" concept [5] can be used and a single core can represent the optical network topology. Note that "load-symmetrical" does not mean the loads among any distinct edge node pairs are balanced; it only refers to the load- balancing within the connections of one edge node pair. Load symmetrical networks do not need to have a symmetrical physical network topology, although a symmetrical physical network topology He and Bochmann Expires March 21, 2007 [Page 12] Internet-Draft Inter-area Optimal Routing Framework September 2006 (such as AAPN] and PON (Passive Optical Networks)) can be made load- symmetrical easily. 6. Security Considerations This document does not introduce new security issues beyond those inherent in MPLS TE [RFC3209, rfc3630]. 7. IANA Considerations This informational document makes no requests for IANA action. 8. Conclusions Based on deploying a load-symmetrical network (such as an overlaid star optical network (AAPN)) in multi-area networks, we propose a novel framework that aims to implement optimal inter-area MPLS routing. Compared with other inter-area routing proposals, our proposal has two distinguishing characteristics: 1. Our proposal can provide globally-optimized inter-area routing; 2. There will be no change, hardware or software, on existing traditional IP/MPLS routers in the peripheral OSPF areas to implement our proposal. Furthermore, our proposal is not limited to AAPNs; it is actually applicable to any load-symmetrical (optical) network with arbitrary physical network topology. Indeed, our proposal can be considered as a highly competitive candidate that has the potential to become a total solution to Inter-area MPLS Traffic Engineering [RFC4105]. 9. Acknowledgments This work was supported by the Natural Sciences and Engineering Research Council (NSERC) of Canada and industrial and government partners, through the Agile All-Photonic Networks (AAPN) Research Network. This work is part of an AAPN Partnered Research Project sponsored by TELUS. The authors thank Rainer Iraschko for useful discussions. He and Bochmann Expires March 21, 2007 [Page 13] Internet-Draft Inter-area Optimal Routing Framework September 2006 10. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, April, 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC3209] Awduche, D., et al. "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December, 2001. [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September, 2003. [RFC4105] Le Roux, et al., "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4201] K. Kompella et al. "Link Bundling in MPLS Traffic Engineering (TE)" RFC 4201, October, 2005. [PCE-ARC] Farrel, A., "A Path Computation Element (PCE) Based Architecture", draft-ietf-pce-architecture-04 (work in progress), January 2006. [AAPN-ARC]G. v. Bochmann, M.J. Coates, T. Hall, L. Mason, R. Vickers and O. Yang, "The Agile All-Photonic Network: An architectural outline", Proc. Queen's University, Biennial Symposium on Communications, 2004, pp.217-218. [AAPN-TOP]L.G. Mason, A. Vinokurov, N. Zhao and D. Plant, "Topological Design and Dimensioning of Agile All Photonic Networks", Computer Networks: The International Journal of Computer and Telecommunications Networking, Volume 50, Issue 2(February 2006), Pages: 268 - 287, 2006. He and Bochmann Expires March 21, 2007 [Page 14] Internet-Draft Inter-area Optimal Routing Framework September 2006 Author's Addresses Peng He School of Information Technology and Engineering (SITE) University of Ottawa 800 King Edward Avenue Ottawa, Ontario K1N 6N5 Canada Phone: 1-613-5625800 ext. 2191 Email: penghe@site.uottawa.ca Gregor v. Bochmann School of Information Technology and Engineering (SITE) University of Ottawa 800 King Edward Avenue Ottawa, Ontario K1N 6N5 Canada Phone: 1-613-5625800 ext. 6205 Email: bochmann@site.uOttawa.ca Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. He and Bochmann Expires March 21, 2007 [Page 15] Internet-Draft Inter-area Optimal Routing Framework September 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. He and Bochmann Expires March 21, 2007 [Page 16]