Internet Draft S. Van den Bosch Document: draft-vdbosch-tewg-multiarea-branch- Alcatel te-00.txt Expires: May 2002 November 2001 Multi-area traffic engineering using branched LSP setup Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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. Abstract This document proposes an alternative approach to inter-area traffic engineering and path setup. It recognizes the potential issues with current proposals and presents a different approach based on concurrently sending path setup messages. The approach allows for fast, efficient path setup across multiple areas without crankback or flooding. It does so without introducing a new protocol or changing the IGP and requires only minimal extensions of the current signaling protocols. 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 [2]. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................1 Van den Bosch Informational - Expires May 2002 1 Inter-area traffic engineering November 2001 using branched LSP setup 1. Introduction....................................................2 2. Basic building blocks of the proposed solution..................3 3. Inter-area traffic engineering scenarios........................4 4. RSVP extensions.................................................5 5. Application of the proposed functionality......................10 6. Relation to other approaches...................................12 7. Conclusion.....................................................12 Security Considerations...........................................12 References........................................................13 Acknowledgments...................................................14 Author's Addresses................................................14 Full Copyright Statement..........................................14 1. Introduction Internet traffic engineering is defined as that aspect of Internet network engineering dealing with the issue of performance evaluation and performance optimization of operational IP networks. Traffic Engineering encompasses the application of technology and scientific principles to the measurement, characterization, modeling, and control of Internet traffic [3]. Traffic engineering typically consists of information exchange, path computation and path signaling. Path computation can be performed online or offline depending on the available information and desired efficiency and responsiveness. In both cases, once an explicit route (ER) is calculated, the path can be setup using RSVP-TE [4] or CR- LDP [5] signaling. Information exchange is done using IGP extensions such as [6] or [7]. The IGP can be organized in a hierarchical way, e.g. multiple leaf areas connected via a backbone area in OSPF or multiple islands of L1 routers connected over a L2 router network in IS-IS. In both cases, some routers may belong to both hierarchy levels. These routers are called Area Border Routers (ABR) in OSPF and L1L2 routers (L1L2) in IS-IS. The fact that the remainder of this document will use OSPF terminology by no means indicates a preference or restriction. The information exchange in a hierarchical network is restricted by the flooding scope of the link state advertisements (LSA). Therefore, a node computing a path for an inter-area LSP typically does not have a full view on all available resources. Over the last year, several proposals for inter-area traffic engineering were made and structured by means of a requirement document. The proposals are enabled through the introduction of new functionality including route server (RS) capability [8], query capability [9], summary TE- LSA flooding capability [10] and constraint passing. This functionality is further supported by means of fall-back scenarios such as crankback [11] and TE feedback [12]. The additional functionality needs to be introduced by means of IGP Van den Bosch Informational - Expires May 2002 2 Inter-area traffic engineering November 2001 using branched LSP setup extensions and signaling extensions. These requirements are now merged with (hierarchical) restoration requirements [13]. In this document we propose a solution to inter-area path set-up and traffic engineering based on concurrently sending Path/Label Request messages. The approach is inline with the requirements in [14] and offers fast and efficient path computation while not requiring route servers, crankback or flooding. The remainder of this document is organised as follows. Section 2 discusses the basic building blocks needed for the proposed solution and section 3 provides examples for inter-area traffic engineering. Section 4 proposes signaling extensions introducing this functionality into RSVP-TE. Extensions for CR-LDP are deferred to a later document. Section 5 described the detailed use of the proposed functionality. Section 6 briefly describes the relation to other approaches and section 7 contains the conclusion. 2. Basic building blocks of the proposed solution For a description of the basic building blocks we will use the generic Path/Label Request and Resv/Label Mapping terms for the path setup messages. In later section we will revert to the RSVP-TE terminology. 2.1. Branching of multiple Path/Label Request messages The basic building block of the proposed solution is the ability of a sender to concurrently send multiple Path/Label Request messages. messages. The amount of messages that are sent and their destination can be tailored in order to achieve specific behavior. 2.2. Selective forwarding of path set-up messages The proposed solution is further based on the ability of an intermediate node to selectively forward Path/Label Request messages. Each intermediate node - be it on the original ERO or not - should be able to select between the incoming messages and concurrently forward at least one of them to the next abstract node in its area or to a number of candidate intermediate nodes. The node should be notified of the maximum number of messages it should consider and of the maximum time it should wait before deciding. The Path/Label Request messages should contain a quality measure. This enables the intermediate node to select between them. Comparison of the available paths may be based on any of the currently proposed metrics or others. Upon receiving a Path/Label Request message, the node checks if more messages can be expected and initiates the hold-off timer. When all messages are received or when the timer expires, the node selects the Path/Label Request messages to forward and their respective destinations. The default behavior would be to select the best current path up to his position and forward the corresponding path Van den Bosch Informational - Expires May 2002 3 Inter-area traffic engineering November 2001 using branched LSP setup set-up messages to a number of destinations. Furthermore, a node may elect to forward only the first Path/Label Request message it receives. For the Path/Label Request messages that were not forwarded, the intermediate node sends PathErr/ResvTear messages in order to free reserved resources. Note that nodes that are neither abstract node nor candidate for intermediate node are not required to support broadcast and selective forwarding. In the interest of migration, it may be interesting to restrict the intermediate nodes to ABRs and L1L2 routers [15]. 2.3. Selective response with Resv/Label Mapping messages. Upon receiving a Path/Label Request message, the egress starts the hold-off timer and collects other incoming messages. It selects the appropriate paths based on the recorded metrics. The appropriate path may be the shortest path from source to destination under the assumed metric or for instance a pair of diversely routed paths. The receiver then responds with a single Resv/Label Mapping message that establishes the path in the conventional way. Note that we do not propose to change the refresh procedure for RSVP-TE soft state. Ultimately, the ingress LSR could occasionally revert to concurrent sending in order to allow dynamic adaptation of the established path. 3. Inter-area traffic engineering scenarios In this section, we provide three scenarios explaining how the proposed functionality can be used for inter-area traffic engineering and LSP set-up. These scenarios are based on the diagram below. --------------- --------------- --------------- | +----+ +----+ | | |ABR1| |ABR3| | +----+ +----+ +----+ +----+ |LSR1| | | | | |LSR2| +----+ +----+ +----+ +----+ | |ABR2| |ABR4| | | area 1 +----+ area 0 +----+ area 2 | --------------- --------------- --------------- The ingress and egress LSR are denoted as LSR1 and LSR2 respectively. The area border routers of area1 and area2 are denoted ABR1,2 and ABR3,4 respectively. Scenario 1 LSR1 computes the optimal path segment in area 1 to either ABR1 or ABR2 based on the appropriate metric (IGP or TE metric) and sends a PATH message. Suppose the optimal path segment goes through ABR1. Van den Bosch Informational - Expires May 2002 4 Inter-area traffic engineering November 2001 using branched LSP setup Then, ABR1 computes the optimal path segment to both ABR3 and ABR4. It forwards the PATH message to both ABR3 and ABR4, each with the appropriate ERO. Both ABRs in area 2 forward the message to the LSR2. LSR2 selects the best path and establishes connection by returning a RESV message. This scenario is based on the assumption that resources are far scarcer in the leaf areas than in the backbone area. It has the advantage of requiring only a single decision point, LSR2. The established path, however, may be sub-optimal. Scenario 2 LSR1 concurrently sends a Path/Label Request message to both ABR1 and ABR2. ABR1 and ABR2 send the message further to both ABR3 and ABR4. ABR3 and ABR4 will therefore receive a maximum of two PATH messages. Based on the recorded metric, each one selects the best one and forwards it to LSR2. LSR2 selects the best overall path and establishes connection. This scenario has the advantage of finding the optimal end-to-end path for the specified metric. Scenario 3 Scenario 3 can extend any of the above scenarios by concurrently sending PATH messages on parallel paths towards the same intermediate node (ABR1, 2, 3 or 4). This functionality may be interesting for survivability reasons. ABR1, for instance, can upon receiving multiple path set-up messages for parallel paths, select one of them for the primary path and one of them for the protection path. 4. RSVP extensions 4.1. RECORD_METRIC object RECORD_METRIC object Class = xxx C-Type = x 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (subobjects // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.1. HOP_COUNT subobject 0 1 2 3 Van den Bosch Informational - Expires May 2002 5 Inter-area traffic engineering November 2001 using branched LSP setup 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | C-type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of the HOP_COUNT subobject | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x hop count C-Type The C-Type of the included HOP_COUNT object. Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. Flags Flags is an 8 bit field. The first bit is the No Update (NU) Flag. The other seven are reserved for further use. Contents of the HOP_COUNT subobject The HOP_COUNT subobject contains the hop count of the path segment from the first branch point to the last strict hop of the ERO. Support of the HOP_COUNT subobject is MANDATORY for compliant nodes. 4.1.2. DELAY subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | C-Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of the DELAY subobject | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x accumulated delay C-Type The C-Type of the included DELAY object. Length Van den Bosch Informational - Expires May 2002 6 Inter-area traffic engineering November 2001 using branched LSP setup The Length contains the total length of the subobject in bytes, including the Type and Length fields. Flags Flags is an 8 bit field. The first bit is the No Update (NU) Flag. The other seven are reserved for further use. Contents of the DELAY subobject The DELAY subobject contains the accumulated delay of the path segment from the first branch point to the last strict hop of the ERO. Support of the DELAY subobject is OPTIONAL for compliant nodes. However, nodes not supporting the subobject MUST be able to set the NU Flag. 4.1.3. MIN_BW subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | C-Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of the MIN_BW subobject | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x minimum available bandwidth C-Type The C-Type of the included MIN_BW object. Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. Flags Flags is an 8 bit field. The first bit is the No Update (NU) Flag. The other seven are reserved for further use. Contents of the MIN_BW subobject The MIN_BW subobject contains the minimum available bandwidth of the path segment from the first branch point to the last strict hop of the ERO. Van den Bosch Informational - Expires May 2002 7 Inter-area traffic engineering November 2001 using branched LSP setup Support of the MIN_BW subobject is OPTIONAL for compliant nodes. However, nodes not supporting the subobject MUST be able to set the NU Flag. 4.1.4. IGP_METRIC subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | C-Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of the IGP_METRIC subobject | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x IGP path metric C-Type The C-Type of the included IGP_METRIC object. Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. Flags Flags is an 8 bit field. The first bit is the No Update (NU) Flag. The other seven are reserved for further use. Contents of the IGP_METRIC subobject The IGP_METRIC subobject contains the accumulated path metric computed from the IGP link metrics of the path segment from the first branch point to the last strict hop of the ERO. Support of the IGP_METRIC subobject is OPTIONAL for compliant nodes. However, nodes not supporting the subobject MUST be able to set the NU Flag. 4.1.5. TE_METRIC subobject 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | C-Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Contents of the TE_METRIC subobject | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Van den Bosch Informational - Expires May 2002 8 Inter-area traffic engineering November 2001 using branched LSP setup 0x TE path metric C-Type The C-Type of the included TE_METRIC object. Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. Flags Flags is an 8 bit field. The first bit is the No Update (NU) Flag. The other seven are reserved for further use. Contents of the TE_METRIC subobject The TE_METRIC subobject contains the accumulated path metric computed from the TE link metrics of the path segment from the first branch point to the last strict hop of the ERO. Support of the TE_METRIC subobject is OPTIONAL for compliant nodes. However, nodes not supporting the subobject MUST be able to set the NU Flag. Support of the RECORD_METRIC object is MANDATORY for compliant nodes. Non-compliant nodes MUST forward it transparently. 4.2. BRANCH object BRANCH object Class = xxx C-Type = x 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # Branches | Flags | Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP ID Range | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original LSP ID | Previous LSP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # Branches This field is set to the number of branches for the LSP that is being set up. If a node decides to branch and or drop, it MUST correctly update this field. Van den Bosch Informational - Expires May 2002 9 Inter-area traffic engineering November 2001 using branched LSP setup Flags Flags is an 8 bit field. The first bit is the DonĘt Select (DS) Flag which forces intermediate nodes to forward all branches. The other seven are reserved for further use. Timer This field contains a Timer value which is used by intermediate nodes or by the egress to initialise a hold off timer when collecting incoming PATH messages from different branches. LSP_ID Range LSP_ID Range contains a range of acceptable values for the LSP_IDs used for branches of the current PATH message. A branching node MUST divide the LSP_ID Range over the branches so that each (downstream) branch is guaranteed to have a unique LSP_ID. Original LSP_ID This field contains the original LSP_ID selected by the ingress for the desired LSP. Previous LSP_ID This field contains the LSP_ID used by a previous branching node. A compliant node MUST fully support the BRANCH object. Non-compliant nodes MUST forward the BRANCH object transparently. 5. Application of the proposed functionality 5.1. Originating a branch request Branching MAY originate at the ingress of the LSP or at any intermediate node. An ingress node MAY elect to send multiple branched PATH messages towards the first abstract node in the ER_Object (ERO) in its area or to a number of candidate intermediate nodes towards the first abstract node in its ERO. For each branch, it computes the path segment towards the candidate intermediate node. It then creates a PATH message for each branch containing the BRANCH and the RECORD_METRIC object. It selects an LSP_ID for the desired LSP and places it in the Original LSP_ID field. For each branch, it selects a different LSP_ID which it places in the Previous LSP_ID field of the BRANCH object. One of these MAY be equal to the Original LSP_ID. For each of the branches it provides a range of acceptable LSP_IDs to be used by downstream nodes when branching. These ranges MUST be disjoint for all branches. It sets the Timer value to the desired Van den Bosch Informational - Expires May 2002 10 Inter-area traffic engineering November 2001 using branched LSP setup hold off timer value at an intermediate node or at the ingress. The RECORD_METRIC object MUST contain the HOP_COUNT subobject and MAY contain any of the optional subobjects. Their values MUST be initialised with the corresponding metric value for the computed path segment. An intermediate node receiving a regular PATH message without BRANCH object MAY elect to branch this PATH message if it is not adjacent to the next hop in the ERO. It then proceeds as described above for an ingress node. The Original LSP_ID MUST equal the LSP_ID of the incoming PATH message. An intermediate node receiving a PATH message with BRANCH object may elect to branch this PATH message if it is not adjacent to the next hop in the ERO. If the DonĘt Select (DS) Flag is set, it computes the path segment towards the candidate intermediate nodes. For each branch, it selects an LSP_ID from the LSP_ID range specified in the BRANCH object. It subdivides the LSP_ID range over the new PATH messages and updates the subobject values in the RECORD_METRIC object and the # Branch field. It MAY update the Timer field with a smaller value. It MUST correctly update the HOP_COUNT subobject. It SHOULD update the optional subobjects for which the No Update (NU) Flag is not set. For each optional subobject that it canĘt update correctly, it MUST set the No Update (NU) Flag in the concerned subobject. If the DS Flag is not set, the intermediate node MAY elect to initiate a hold off timer with the Timer value. It MAY then collect incoming PATH messages with the same Original LSP_ID as the first message until the timer expires or until # Branch messages are received. It MAY then elect to forward only some PATH messages, for instance by forwarding the PATH message with the best metrics only. For each of the forwarded PATH messages it copies the LSP_ID of the PATH message in the Previous LSP_ID field and chooses new LSP_IDs from the specified LSP_ID range. It then procedes in the same way as described for the case where the DS is set. A node originating branched PATH messages MUST be prepared to accept regular RESV messages for all the LSP_IDs it sent out. 5.2. Egress reaction to a branched PATH message Upon receiving a PATH message containing a BRANCH object, the egress initiates a hold off timer with the Timer value. Until the hold off timer expires, it then collects any incoming PATH messages with the same Original LSP ID as the first PATH message up to a maximum of # Branches. Based on the RECORD METRIC object, it select the appropriate (best) path and constructs a RESV message containing a copy of the BRANCH object from the selected branch. A non-compliant egress node will ignore the BRANCH and RECORD_METRIC objects and react to all branches as individual LSP_ID in the same session. The corresponding RESV messages will NOT contain the BRANCH object. If this is the case, then the node originating the BRANCH Van den Bosch Informational - Expires May 2002 11 Inter-area traffic engineering November 2001 using branched LSP setup message MUST construct a new RESV message with the BRANCH object for only one received RESV message. The egress node can detect a non-compliant intermediate node by checking the difference between the length of the RRO and the value of the HOP_COUNT subobject. If these values donĘt match, the egress MAY base its decision on the incomplete information or send a PathErr message. It MUST set the NU Flag in the BRANCH object of the RESV message. 5.3. Reaction to a RESV message of a branched PATH message Upon receiving a RESV message containing a BRANCH object, a node copies the Previous LSP_ID into the LSP_ID field and forwards the message upstream unless it is the ingress. It also starts refreshing the selected PATH with the Original LSP_ID. Finally, it sends PathTear messages for all other LSP_IDs. A non-compliant intermediate node transparently passes the RESV message. 6. Relation to other approaches The proposed approach does not preclude any of the other approaches or scenarios. It suffices to restrict the number of Path/Label Request messages that are sent to one. The proposed approach then reverts to any of the other approaches mentioned. Distributed and route server SDR methods as listed in [14] can then operate as described, depending on which scenario is reverted to. The best inter-working scenario would be to use the concurrent Path/Label Request messages whenever possible and else revert to a method which does not impose continuous overhead. Such a method can use crankback or query capability. 7. Conclusion We presented the basic outline of a new approach for inter-area traffic engineering and path set-up based on broadcasting path set- up messages. The approach is fast, efficient and potential optimal and does not require crankback, flooding or modifications to the IGP. We also proposed to extend RSVP with two objects, BRANCH and RECORD_METRIC. Security Considerations The approach outlined in this document poses no new security problems. Van den Bosch Informational - Expires May 2002 12 Inter-area traffic engineering November 2001 using branched LSP setup References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC2119. 3 D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, " Requirements for Traffic Engineering Over MPLS," RFC2702, September 1999. 4 D. O. Awduche, L. Berger, D.-H. Gan, T. Li, V. Srinivasan, G. Swallow, " RSVP-TE: Extensions to RSVP for LSP Tunnels," work in progress, draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001. 5 B. Jamoussi, Editor, O. Aboul-Magd, L. Andersson, P. Ashwood- Smith, F. Hellstrand, K. Sundell, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Halpern, J. Heinanen, T. Kilty, A. Malis, P. Vaananen, " Constraint-Based LSP Setup using LDP," work in progress, draft- ietf-mpls-cr-ldp-05.txt, February 2001. 6 D. Katz, D. Yeung, "Traffic Engineering Extensions to OSPF," work in progress, draft-katz-yeung-ospf-traffic-06.txt, September 2001. 7 H. Smit, and T. Li, "IS-IS Extensions for Traffic Engineering," work in progress, draft-ietf-isis-traffic-04.txt, August 2001. 8 K. Kompella, Y. Rekhter, "Multi-area MPLS Traffic Engineering," work in progress, draft-kompella-mpls-multiarea-te-00.txt, July 2001. 9 C.-Y. Lee, S. Ganti, "Path Request and Path Reply Message," work in progress, draft-lee-mpls-path-request-01.txt, July 2001. 10 N. Fujita, A. Iwata, "Traffic Engineering Extensions to OSPF Summary LSA," work in progress, draft-fujita-ospf-te-summary- 00.txt 11 A. Iwata, N. Fujita, G. R. Ash,A. Farrel, " Crankback Routing Extensions for MPLS Signaling," work in progress, draft-iwata- mpls-crankback-01.txt, July 2001. 12 P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, " Improving Topology Data Base Accuracy with LSP Feedback," work in progress, draft-ietf-mpls-te-feed-02.txt, July 2001. 13 W. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, T. Griffin, E. Kern, T. Reddington, " Network Hierarchy and Multilayer Van den Bosch Informational - Expires May 2002 13 Inter-area traffic engineering November 2001 using branched LSP setup Survivability," work in progress, draft-ietf-tewg-restore- hierarchy-00.txt, October 2001. 14 J. Ash, J. Strand, C.-Y. Lee, A. Celer, N. Gammage, S. Ganti, A. Iwata, A. Farrel, S. Dharanikota, S. Venkatachalam, D. Papadimitriou, " Requirements for Multi-Area TE," work in progress, draft-ash-multi-area-te-reqmts-00.txt, September 2001. 15 T. Li, T. Przygienda, H. Smit, " Domain-wide Prefix Distribution with Two-Level IS-IS," RFC 2966, October 2000. Acknowledgments Stefaan De Cnodder, Omar Elloumi and Dimitri Papadimitriou, are greatly appreciated for their comments and help with the draft. Author's Addresses Sven Van den Bosch Alcatel Francis Wellesplein 1 Phone: 32-3-240-8103 B-2018 Antwerpen Email: sven.van_den_bosch@alcatel.be Belgium Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Van den Bosch Informational - Expires May 2002 14