Network Working Group Jerry Ash Internet Draft John Strand AT&T Expiration Date: March 2002 Cheng-Yin Lee Paragon Networks Alicja Celer Nortel Networks Neil Gammage Motorola Sudhakar Ganti Tropic Networks Atsushi Iwata Norihito Fujita NEC Corporation Adrian Farrel Movaz Networks, Inc. Sudheer Dharanikota Nayna Networks Senthil Venkatachalam Dimitri Papadimitriou Alcatel September, 2001 Requirements for Multi-Area TE Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 1] Internet Draft September 2001 Abstract This draft describes requirements for multi-area TE. Based on the requirements, the goal is to eventually protocol extensions needed for multi-area TE. Various approaches to multi-area TE are considered, based on the intra-area TE approaches discussed in the [te_framework] and [te_qos_routing]. These TE approaches include time dependent routing (TDR) LSP selection, state dependent routing (SDR) LSP selection, and event dependent routing (EDR) LSP selection. We propose that the needed protocol capability extensions (information exchange, etc.) should support the various types of multi-area TE identified in the draft. The focus initially is on multi-area TE, and not multi-AS TE. IP over optical (IPO) requirements are considered [mp-lambda-s, gmpls], including the unique routing requirements of the optical plane [stand1, stand2, unique]. Initial requirements are given for protocol support of the various multi-area TE methods, which include needs to support route-server (RS) functionality, query functionality, crankback functionality, TE feedback functionality, and summary-LSA functionality. Table of Contents Page 1. Introduction 3 2. Requirements for Multi-Area TE 3 3. Multi-Area TE Routing Methods and Requirements 5 3.1 Time-Dependent Routing (TDR) LSP Selection 6 3.2 State-Dependent Routing (SDR) LSP Selection 6 3.3 Event-Dependent Routing (EDR) LSP Selection 8 3.4 Inter-AS LSP Selection 8 4. Requirements for Information Exchange & Topology Data Base Update 9 5. Comparison of Multi-Area TE Methods 10 5.1 TDR Methods 10 5.2 SDR Methods 10 5.2.1 Distributed SDR (D-SDR) Methods 10 5.2.2 Route Server SDR (RS-SDR) Methods 11 5.3 EDR Methods 12 6. Requirements for Multi-Area TE Protocol Extensions 12 7. Security Considerations 12 8. Acknowledgments 12 9. References 12 10.Authors' Addresses 14 Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 2] Internet Draft September 2001 1. Introduction This draft describes requirements for multi-area TE. Based on the requirements, the goal is to eventually protocol extensions needed for multi-area TE. Various approaches to multi-area TE are considered, based on the intra-area TE approaches discussed in the [te_framework] and [te_qos_routing]. These multi-area TE approaches are outlined, and include time dependent routing (TDR) LSP selection, state dependent routing (SDR) LSP selection, and event dependent routing (EDR) LSP selection. We propose that the needed protocol capability extensions (information exchange, etc.) should support the various types of multi-area TE identified in the draft. The focus initially is on multi-area TE, and not multi-AS TE. The focus initially is on multi-area TE, and not multi-AS TE. IP over optical (IPO) requirements are considered [mp-lambda-s, gmpls], including the unique routing requirements of the optical plane [stand1, stand2, unique]. Initial requirements are given for protocol support of the various multi-area TE methods, which include needs to support route-server (RS) functionality, query functionality, crankback functionality, TE feedback functionality, and summary-LSA functionality. Several drafts were presented at the IETF-49 TEWG meeting on multi-area TE, among them [sudheer1], [sudheer2], [abarbanel], [kompella], [lee]. Several of these methods propose the use of a route server (RS) capability [lee, kompella], query capability [query], crankback capability [crankback], and others suggest the use of summary LSAs [summary_lsa]. These drafts propose different approaches to multi-area TE, but are related by a common set of requirements and protocol needs discussed in this draft. Many potential users are requesting multi-area TE capability [Swallow, IETF49 TEWG Meeting Minutes]. Presentation slides from an IETF-50/TEWG presentation can be found at 2. Requirements for Multi-Area TE There are various requirements to be considered in adopting a multi-area TE method, which include the following: a) maximize network utilization, considering QoS objectives b) minimize network cost, considering QoS objectives c) minimize routing overhead (includes LSAs, crankbacks, queries, etc.) d) minimize routing overhead across areas (LSA flooding) e) maximize scalability f) allow various multi-area TE routing methods, including TDR, SDR, and EDR LSP selection [te_framework, te-qos-routing] g) allow various information exchange methods to be used, including support for RS functionality, query functionality, crankback functionality, TE feedback functionality, and summary-LSA functionality h) support bi-directional LSPs and asymmetrical bi-directional LSPs i) provide signaling interworking with other technologies, including BICC, PNNI, and other signaling protocols j) ensure that multi-area TE supports IP over optical (IPO) control plane needs, including both overlay models and peer models [mp-lambda-s, gmpls] Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 3] Internet Draft September 2001 k) ensure that all routing constraints and unique IPO requirements can be incorporated in multi-area path selection [strand1, strand2, unique] l) allow routing protocols across areas to be resident on multiple network elements [strand2] m) allow LSP restoration to occur separately within each area [strand2] n) provide metrics capable of modeling transport costs, cross-connect costs, regeneration/amplification costs [strand2] o) allow multiple paths which satisfy path diversity needs [strand2] p) allow topological overlap between areas [strand2] q) allow partial connectivity in the optical domain [strand2] r) allow multi-area information exchange of link/switch capabilities in networks that support mixed switching types s) allow multi-area information exchange of link protection types in networks that support mixed link protection types t) allow multi-area gmpls explicit label control, so that routing protocols are capable of distributing label availability information with respect to lambdas and time slots both within and between areas For IPO needs, support for both an overlay model and peer model are required. An overlay model provides more separation between optical and network domains, which affords more routing domain independence, and requires less routing information exchange across the domain boundaries (e.g., no LSAs are flooded across the UNI). Further, it is envisioned that within the optical domain there may be an O-E-O sub-domain layer and an all-optical sub-domain layer [strand2]. Within the all-optical subdomain, full connectivity may not be possible. For example, if the all-optical sub-domain is limited by optical impairment to support only routes of 3 or less links, it may not be possible to provide more than 3-link connectivity between all nodes [strand2]. GMPLS [gmpls] extends MPLS to allow signaling of labels for other switching technologies beyond the packet switching. When a new LSP is set up it must be specified to the LSRs in the path what the transmission commodity being switched is -- the current choices include packet, Ethernet, PDH, SDH, SONET, digital wrapper, Lambda, and fiber. In order to perform traffic engineering correctly, it is not enough to know the IP topology, but we also need to know the link capabilities. Similarly, GMPLS allows the LSP requester to specify the link protection properties required. These are the protection properties of the underlying link not those of the LSP itself. Link protection possibilities are none, 1:n, 1:1, 1+1, better than 1+1. Again, TE can only do this correctly if the link protection properties are passed around, and this needs to be supported for multi-area TE. GMPLS allows labels to encode sub-resources within a link (e.g., time slots or lambdas). GMPLS also extends the signaled explicit route to allow it to encode the labels that should be used for each hop of the route with Explicit Label Control. Combining these gives the ingress control of the sub-resources to use through the network. This is only any use if the TE is centralized or if the IGP is extended to report sub-resource availability. Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 4] Internet Draft September 2001 3. Multi-Area TE Routing Methods and Requirements Internet Traffic Engineering is concerned with the performance optimization of operational networks. It encompasses the measurement, modeling, characterization, and control of Internet traffic, and the application of techniques to achieve specific performance objectives, including the reliable and expeditious movement of traffic through the network, the efficient utilization of network resources, and the planning of network capacity. Hierarchical multi-area or multi-AS topologies are normally used with IP routing protocols (e.g., OSPF, BGP). Traffic trunks can be defined by LSPs between LSRs, and are used to allocate the bandwidth of the logical links to various LSR pairs. TE LSP routing is characterized by the LSP choices used in the method and rules to select one LSP for a given connection or bandwidth-allocation request. When an LSP bandwidth-allocation request is initiated by an LER, the LER implementing the routing method executes the LSP selection rules to find an admissible LSP from among the LSPs that satisfy the request. In a network with source routing, the LER maintains control of the LSP request. With source routing, the LER identifies the entire selected LSP including all intermediate or via LSRs (VLSRs) and egress LSR (ELSR) in the LSP in an explicit-route (ER) parameter. Some VLSRs may lie on the boundary of areas and are area border routers (ABRs). If the QoS or traffic parameters cannot be realized at any one of the VLSRs in the LSP setup request, then the VLSR generates a crankback parameter which allows a VLSR to return control of the bandwidth-allocation request to the LER or ABR for further alternate routing. LSPs are determined by (normally proprietary) algorithms based on the network topology and reachable address information. LSPs can cross multiple areas within an AS, and also cross multiple ASs. An LER may select an LSP based on the routing rules and the QoS resource management criteria, which must be satisfied on each link in the LSP. In addition to controlling bandwidth allocation, the QoS resource management procedures can check other QoS parameters, such as end-to-end transfer delay, delay variation, and transmission quality considerations such as loss, echo, and noise. LSP selection methods are categorized into the following three types: * time-dependent routing (TDR) LSP selection, * state-dependent routing (SDR) LSP selection, and * event-dependent routing (EDR) LSP selection. LSP choices can be changed dynamically, either in an off-line, preplanned, time-varying manner, as in TDR, or on-line, in real time, as in SDR or EDR. With off-line, pre-planned TDR LSP selection, LSP choices might change every hour or at least several times a day to respond to measured hourly shifts in traffic loads, and are periodically recalculated, perhaps each week. Real-time LSP selection does not depend on precalculated LSP choices. Rather, the LSR or route server (RS) senses the immediate traffic load and if necessary searches out new LSPs through the network. On-line, real-time LSP selection methods include EDR and SDR. Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 5] Internet Draft September 2001 An LER can fully calculate an ER at the source based on TDR, SDR, or EDR LSP selection, or the ER can include loose hops which are used at ABRs. In the latter case, the ER processing rules allow the ABRs to insert a series of hops to navigate to the next ABR, thus the LSP choice is not constrained to the LER. This distinction is made in [crankback], but only after the initial signaling attempt (with the LER-signaled ER) has failed. 3.1 Time-Dependent Routing (TDR) LSP Selection With TDR methods the LSP choices are altered at a fixed point in time during the day or week. TDR LSP choices are determined on an off-line, preplanned basis and are implemented consistently over a time period. The TDR LSP choices are determined considering the time variation of traffic load in the network, for example based on measured hourly load patterns. Several TDR time periods are used to divide up the hours into contiguous routing intervals. Typically, the TDR LSP choices used in the network are coordinated to take advantage of noncoincidence of busy hours among the traffic loads. In TDR, the LSP choices are preplanned and designed off-line using a centralized system, which employs a TDR network design model. The off-line computation determines the optimal routes from a potentially very large number of possible alternatives, in order to maximize network throughput and/or minimize the network cost. The designed LSP choices are loaded and stored in the various LSRs in the TDR network, and periodically recomputed and updated (e.g., every week) by the central system. In this way an LER does not require additional network information to construct TDR LSP choices, once the LSP choices have been loaded. This is in contrast to the design of LSP choices on-line in real time, such as in the SDR and EDR methods described below. LSPs in the TDR routing table may consist of time varying routing choices and use a subset of the available LSPs. That is, we can distinguish between LSP calculation/choice and LSP establishment. In TDR, the LSP choices are made off line and are changed by a change in time period. In SDR and EDR, the LSP choices are determined on line and changed by a change in the network state and/or an event such as a blocked LSP request (a variant of SDR and EDR could be to have the LSP choices made off line). LSPs in the TDR routing table may consist of several (possibly multiple-link) LSPs through multiple VLSRs. If a connection on one link in a LSP is blocked (e.g., because of insufficient bandwidth), the bandwidth-allocation request then attempts another complete LSP. Implementation of such a routing method can be done through control from the LER or ABR, plus a crankback capability that allows a bandwidth-allocation request blocked on a link in an LSP to return to the LER or ABR for further alternate routing on other LSPs. 3.2 State-Dependent Routing (SDR) LSP Selection In SDR, the LSP choices are altered automatically according to the state of the network. For a given SDR method, the LSP selection rules are implemented to determine the LSP choices in response to changing network status, and are used over a relatively short time period. Information on network status may be collected at a central route server (RS) processor or distributed to multiple RSs or the LSRs in the network. Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 6] Internet Draft September 2001 The information exchange may be performed by * flooding the information to all the RSs and/or LSRs in the network * querying RSs or LSRs on an on-demand basis for needed information, * feeding the information back on LSP signaling messages * a combination of any of the above SDR methods route LSP bandwidth-allocation requests on the best available LSP on the basis of network state information. For example, in the least loaded routing (LLR) method, the residual capacity of candidate LSPs is calculated, and the LSP having the largest residual capacity is selected for the bandwidth-allocation request. Various relative levels of link occupancy can be used to define link load states, such as lightly-loaded, heavily-loaded, or bandwidth-not-available states. In general, SDR methods calculate a LSP cost for each bandwidth-allocation request based on various factors such as the load-state or congestion state of the links in the network. In SDR, the LSP choices are designed on-line by the LER or an RS through the use of network status and topology information obtained through information exchange with other LSRs and/or other RSs. There are various implementations of SDR distinguished by whether the computation of the LSP choices is a) distributed among all the LSRs in an AS, or b) done in a centralized RS per AS, or perhaps several RSs (e.g., 1 or more per AS area). This leads to two different implementations of SDR: a) distributed SDR (D-SDR) -- here each LSR in the AS obtains topology and status information from all the other LSRs. Normally the topology status information is flooded throughout each area in the AS, and between areas with summary-LSAs. In another form of D-SDR, rather than flooding information an LER queries the other LSRs in the candidate LSPs to obtain topology and status information. To determine an LSP explicit route, the LER executes a particular routing optimization procedure such as LLR. a) route server SDR (RS-SDR) -- here the centralized RS or several RSs obtain topology and status information from the various LSRs within an AS or within an AS-area. The topology/status information can be sent on a periodic basis (e.g., every few seconds) or based on topology/status changes. The RS performs a computation of the candidate LSPs on a periodic basis (e.g., every few seconds) or on-demand (e.g., initiated by a query from an LER). To determine the LSP explicit route, the RS computes the constrained route by executing a particular routing optimization procedure such as LLR. The LSPs are either transmitted to the LSRs on a periodic basis (e.g., every few seconds) or provided on demand from an LER. The essential distinction between D-SDR and RS-SDR LSP selection is where the TE routing database is kept and the LSP choices are made. In the D-SDR case, the database and LSP choices are made at the LSRs themselves. In the RS-SDR case, the database and LSP choices are made at the RS(s). Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 7] Internet Draft September 2001 In either instance, LSP explicit routes may be determined based on the constraints specified and analysis of the status data. For example, an LSP selection method might provide that the primary (shortest) LSP choice is used if the bandwidth is available. If the bandwidth is unavailable on one or more links, a second LSP is selected from the list of feasible LSPs on the basis of having the greatest level of idle bandwidth at the time. This second LSP may be used to provide bandwidth capacity in addition to that already provided by the primary LSP between the LER and egress LSR. The second LSP may be selected from among a pre-stored list of candidate LSPs or computed on line based on the constraints and network status information in the TE routing database. Dynamically activated bandwidth reservation can be used to protect against inefficient LSP usage, and other controls used to automatically modify LSP choices during network overloads and failures [te_qos_routing]. 3.3 Event-Dependent Routing (EDR) LSP Selection In EDR, the LSP choices are updated locally on the basis of whether connections succeed or fail on a given LSP choice. In the EDR learning approaches, the LSP last tried, which is also successful, is tried again until blocked, at which time another LSP is selected at random and tried on the next bandwidth-allocation request. Success-to-the-top (STT) EDR LSP selection is a decentralized, on-line LSP selection method with update based on random routing. STT-EDR uses a simplified decentralized learning method: The primary LSP LSP-p is used first if available, and a currently successful alternate LSP LSP-s is used until it is blocked. In the case that LSP-s is blocked (e.g., bandwidth is not available on one or more links), a new alternate LSP LSP-n is selected at random as the alternate LSP choice for the next bandwidth-allocation request overflow from the primary LSP. Dynamically activated bandwidth reservation is used under congestion conditions to protect traffic on the primary LSP. STT-EDR uses crankback when an alternate LSP is blocked at a VLSR, and the bandwidth-allocation request advances to a new random LSP choice. In STT-EDR, many LSP choices can be tried by a given bandwidth-allocation request before the request is blocked. The main point of EDR is that is does not require a centralized database of FIDB information, such as is provided in D-SDR at each LSR through flooding or query, or in RS-SDR at each RS. In the case of EDR, the FIDB information is accessed locally at each LSR as the LSP is set up or modified. Hence in EDR, the FIDB information is decentralized, however with SDR the FIDB information is kept in one database, either in the LSRs or centralized in an RS. In the EDR learning approaches, the current alternate LSP choice can be updated randomly, cyclically, or by some other means, and may be maintained as long as a connection can be established successfully on the LSP. Hence the LSP selection is constructed with the information determined during connection setup, and no additional information is required by the LER. 3.4 Inter-AS LSP Selection In selecting LSPs between autonomous systems (ASs), which themselves may consist of multiple areas, inter-AS routing capabilities such as BGP [abarbanel] need to be considered. Though not specifically addressed in this draft, some of the multi-area TE methods described herein can very well be used to address the needs of multi-AS LSP selection as well. Details of inter-AS LSP selection are TBD. Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 8] Internet Draft September 2001 2. Requirements for Information Exchange & Topology Data Base Update Various means of information exchange, such as with LSAs, query, and crankback, are required to build the topology database, to construct the LSP choices, and to determine and establish a LSP from the choices. LSAs [ospf, isis] are flooded within areas to build the topology database at each LSR by advertising link status, node status, reachable addresses, and other information. LSAs could also be advertised between areas; however this could raise scalability issues since areas are established in the first place to limit LSA flooding to a reasonable level within the designated areas (more on this later). Summarized LSAs [summary_lsa] can be flooded between areas to give useful but reduced information, and also to be scalable. Query [query] messages are required in some multi-area TE methods, for example, between an LER and a route server (RS) [lee, kompella], or between an LER and ABR, to determine topology database information needed to calculate a path for an LSP. A query could also be used to request that an RS or ABR compute an LSP path from its topology database, and return it to the requesting LSR, ABR, or other RS. Various other means of using query-response may be proposed. Using the topology database, the LSR or RS generates the LSP choices according to a number of different LSP selection methods, such as those described in Section 3. Crankback [crankback] can be used in LSP setup, or modification, to backtrack to an ABR or LER, if a bottleneck is found in a candidate LSP (e.g., if there is insufficient bandwidth on a particular link in the LSP). One way to view the topology database at each LSR or RS is to consider a decomposition into the slow information database (SIDB) and the fast information database (FIDB). Information in the SIDB changes slowly, for example) * max link bandwidth * color * metric (weight, delay, etc.) * reachable addresses * slow available link bandwidth update (e.g., based on >= 5-minute updates) Information in the FIDB changes rapidly, for example * available link bandwidth (e.g., real-time updates) The LSA overhead to flood information in the SIDB is relatively much less than the LSA overhead to flood information in the FIDB, because of the relative rates of change of the database, not because of their relative sizes. It might well be feasible, for example, to flood the full SIDB information between areas, whereas it may not be feasible to flood the full FIDB information (vs. summarized LSA information) between areas. The use of SIDB and FIDB information by each inter-area TE method is detailed in the next section. Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 9] Internet Draft September 2001 Note that the SIDB and FIDB information needs to be identified for each class type. TE methods are currently being defined for multiple class types [class] wherein the amount of SIDB/FIDB information will greatly increase (multiplicative by the number of classes). This will increase the emphasis on information exchange methods that decrease the routing overhead in terms of LSAs, crankbacks, queries, etc. In general, SLAs, PHBs, and class types may not be consistent across domains or areas, and could be policy specific. In that case, a consistent meaning for class type needs to be defined. 3. Comparison of Multi-Area TE Methods In the previous Section we gave routing requirements for multi-area TE, which included TDR, SDR, and EDR methods. Here is a summary of the classification of the various methods, use of SIDB/FIDB, and some similarities, differences, and relative advantages among the methods. See [te_qos_routing] for more detailed comparisons of these methods on the basis of performance, network design impacts, and operational impacts. Multiservice network models are used to evaluate performance, design, and operation. 3.1 TDR Methods [te_framework, te_qos_routing] - LSP selection performed by off-line centralized system - candidate LSPs are pre-planned based on previously measured traffic and downloaded periodically to LSRs - LSP selection patterns change periodically (e.g., each hour) to respond to measured hourly shifts in traffic loads and are periodically recalculated (e.g., each week) - advantage: intra-area and inter-area LSA flooding reduction - disadvantage: LSP choices not adaptive to network status 3.2 SDR Methods 3.2.1 Distributed SDR (D-SDR) Methods a. [kompella]/scenario 1 approach: - per area path set up - SIDB/FIDB flooded intra-area - normal summary-LSAs inter-area - use crankback to ABR or LER if LSP setup request fails - feedback can be used to help build LSR TE routing database - advantage: reduced LSA flooding between areas - disadvantage: LSP choices not based on whole topology database b. [kompella]/scenario 3 approach: - LER gets TE information from backbone-area and computes path to tail-end ABR; tail-end ABR computes rest of path - LER stores both backbone and intra-area SIDB/FIDB - use crankback if LSP setup request fails - feedback can be used to help build LSR TE routing database - advantage: whole topology database used for LSP determination - disadvantage: large amount of downloaded backbone TE information Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 10] Internet Draft September 2001 c. [sudheer1] approach: - ABRs flood TE-summary-LSA's to other areas - LER sets up LSP based on topology database, including summary-LSA information - transit LSRs use crankback if LSP setup request fails, ABR or LER may try another LSP - SIDB/FIDB flooded intra-area - summarized SIDB/FIDB flooded inter-area (in TE-summary-LSAs) - feedback can be used to help build LSR TE routing database - advantage: reduces flooded information between areas - disadvantage: LSP choices not based on whole topology database d. D-SDR query approach [te_qos_routing]: - ABRs flood SIDB-LSA's to other areas - LER queries LSRs along candidate LSPs for FIDB information (at time of LSP setup or modification) - LER sets up LSP based on SIDB topology database and FIDB query-information - transit LSRs use crankback if LSP setup request fails, ABR or LER may try another LSP - SIDB flooded intra-area & inter-area - feedback can be used to build LSR TE routing database - advantage: reduces flooded information within areas and between areas - disadvantage: requires extensive use of query capability 3.2.2 Route Server SDR (RS-SDR) Methods a. [lee] approach: - this is a distributed RS approach wherein RSs could be separate or combined ABR/RS - RS(s) within area gather intra-area link-state information (reduces intra-area flooding) - LER queries a RS in backbone area for path - LER does not download TE information from backbone area (reduces flooding across areas) - uses crankback if LSP setup request fails - RS may try path query to another RS within area to determine another LSP - intra-area SIDB/FIDB flooded only to RSs - uses LER-RS query - advantage: requires no TE-summary-LSA flooding between areas; possible intra-area LSA flooding reduction; whole topology database used for LSP determination - disadvantage: requires RS implementation with RS backup b. [kompella]/scenario 2 approach: - LER queries ABR/RS for path (this is similar to [lee] approach) - SIDB/FIDB flooded intra-area - uses LER-ABR/RS query - use crankback to ABR/RS or LER if LSP setup request fails - advantage: requires no TE-summary-LSA flooding between areas; whole topology database used for LSP determination - disadvantage: requires RS implementation with RS backup Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 11] Internet Draft September 2001 c. [kompella]/scenario 4 approach: - LER queries central RS for path - SIDB/FIDB flooded intra-area and to central RS - uses LER-RS query - use crankback if LSP setup request fails - advantage: requires no TE-summary-LSA flooding between areas; possible intra-area LSA flooding reduction; whole topology database used for LSP determination - disadvantage: requires RS implementation with RS backup 3.3 EDR Methods Success-to-the-top EDR (STT-EDR) approach [te_qos_routing]: - LER determines CRLSP based on SIDB - uses crankback if LSP setup request fails - SIDB information flooded intra-area and inter-area - no FIDB flooding required - feedback used to build LSR TE routing database - advantage: intra-area and inter-area LSA flooding reduction - disadvantage: LSP choices not based on whole topology database 4. Requirements for Multi-Area TE Protocol Extensions Initial requirements are given here for protocol support of the multi-area TE methods, which include needs to support * route-server (RS) functionality [lee, kompella], * query functionality [query], * crankback functionality [crankback], * TE feedback functionality [feedback], and * summary-LSA functionality [summary_lsa]. Details of the proposed protocol upgrades necessitated by the various multi-area TE solution approaches are already available in the various drafts referenced. 7. Security Considerations The multi-area routing extensions for RSVP-TE and CRLDP inherit the same security mechanisms described in [rsvp_te, crldp] to protect against spoofing attacks of a session, the privacy of signaling messages, and the denial of service (DoS) attacks. Different areas may apply distinct security models and may have different means of signaling security (especially if one area does not use MPLS). Joining security domains would introduce security issues that need to be addressed. 8. Acknowledgments 9. References [sudheer1] Senthil K. Venkatachalam, Sudheer Dharanikota, "A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering,", work in progress. Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 12] Internet Draft September 2001 [sudheer2] Senthil K. Venkatachalam, Sudheer Dharanikota, Thomas D. Nadeau, "OSPF, IS-IS, RSVP, CR-LDP extensions to support inter-area traffic engineering using MPLS TE," work in progress. [abarbanel] Ben Abarbanel, Senthil K. Venkatachalam, "BGP-4 support for Traffic Engineering," work in progress. [kompella] Kireeti Kompella, Yakov Rekhter, "Multi-area MPLS Traffic Engineering," work in progress. [lee] Cheng-Yin Lee, Alicja Celer, Neil Gammage, Sudhakar Ganti, Gerald Ash, "Distributed Route Exchangers," work in progress. [query] Cheng-Yin Lee, Sudhakar Ganti, "Path Request and Path Reply Message,", work in progress. [crankback] Atsushi Iwata, Norihito Fujita, Gerald R. Ash, Adrian Farrel, "Crankback Routing Extensions for MPLS Signaling,", work in progress. [feedback] Peter Ashwood-Smith, Bilel Jamoussi, Don Fedyk, Darek Skalecki "Improving Topology Data Base Accuracy with LSP Feedback," work in progress. [summary_lsa] Atsushi Iwata, Norihito Fujita, "Traffic Engineering Extensions to OSPF Summary LSA," IETF draft. [te_qos_routing] G. Ash, "Traffic Engineering & QoS methods for IP-, ATM-, & TDM-Based Multiservice Networks," work in progress. [te_framework] D. Awduche, et. al., "Overview & Principles of Internet Traffic Engineering" work in progress. [te_requirements] D. Awduche, et al., "Requirements for Traffic Engineering Over MPLS," RFC2702, September 1999. [unique] Angela Chiu, John Strand, Robert Tkach, "Unique Features and Requirements for The Optical Layer Control Plane," work in progress. [strand1] John Strand, Angela Chiu, Robert Tkach, "Issues for Routing in the Optical Layer," IEEE Communications Magazine, February 2001. [strand2] John Strand, Yong Xue, "Routing for Optical Networks With Multiple Routing Domains," oif2001.046 (for a copy send an email request to jls@research.att.com). Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 13] Internet Draft September 2001 [mp-lambda-s] D. Awduche, et al., "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects", work in progress. [gmpls] P. Ashwood-Smith and L. Berger, et al., "Generalized MPLS-Signaling Functional Description,", work in progress. [ldp] L. Andersson, et. al., "LDP Specification," RFC 3036, January 2001. [crldp] B. Jamoussi, et al., "Constraint-Based LSP Setup using LDP," work in progress. [rsvp] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)--Version 1 Functional Specification, RFC2205, September 1997. [rsvp_te] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels," work in progress. [ospf] J. Moy, "OSPF Version 2," RFC2328, April 1998. [isis] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments," RFC1195, December 1990. [recovery] S. Makam, et. al., "Framework for MPLS-based Recovery," work in progress. [class] Francois Le Faucheur, et. al., "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering," work in progress. 10. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-4578 Fax: +1-(732)-368-8659 Email: gash@att.com John Strand AT&T Room MT A5-1D06 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1-(732)-420-9036 Fax: +1-(732)-368-9433 Email: jstrand@att.com Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 14] Internet Draft September 2001 Cheng-Yin Lee Paragon Networks Email: : leecy@paragon-networks.com Alicja Celer Nortel Networks Email: aceler@nortelnetworks.com Neil Gammage Motorola Email: neil.gammage@motorola.com Sudhakar Ganti Tropic Networks Inc. 135 Michael Cowpland Drive Kanata, Ontario, Canada, K2M 2E9 Email: sganti@tropicnetworks.com Atsushi Iwata NEC Corporation Networking Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81-(44)-856-2123 Fax: +81-(44)-856-2230 Email: a-iwata@ah.jp.nec.com Atsushi Iwata Norihito Fujita NEC Corporation Networking Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81-(44)-856-2123 Fax: +81-(44)-856-2230 Email: n-fujita@bk.jp.nec.com Adrian Farrel Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Phone: +1-(703)-847-9847 Email: afarrel@movaz.com Sudheer Dharanikota Nayna Networks 157 Topaz Drive Milpitas, CA 95035 Phone: (408)-956-8000 x357 Email: sudheer@nayna.com Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 15] Internet Draft September 2001 Senthil K. Venkatachalam Alcatel USA 45195 Business Court, Suite 400 Dulles, VA 20166 Phone: (703)654-8635 Email: Senthil.Venkatachalam@usa.alcatel.com Dimitri Papadimitriou Optical Networking Alcatel NSG-NA Corporate Research Center - Network Strategy Group Francis Wellesplein, 1 B-2018, Antwerpen - Belgium Phone: +323-2408491 Email: Dimitri.Papadimitriou@alcatel.be Ash, et. al. draft-ash-multi-area-te-reqmts-00.txt [Page 16]