idnits 2.17.1 draft-ash-multi-area-te-reqmts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 877 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 226 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 38 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 265 has weird spacing: '...uss the relat...' == Line 495 has weird spacing: '...support inter...' == Line 623 has weird spacing: '...cedures for c...' == Line 804 has weird spacing: '...ore the reque...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Kompella' on line 767 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jerry Ash, Editor 2 Internet Draft John Strand 3 AT&T 4 Expiration Date: May 2002 5 Cheng-Yin Lee 6 King Associates 8 Alicja Celer 9 Nortel Networks 11 Neil Gammage 12 Motorola 14 Sudhakar Ganti 15 Tropic Networks 17 Atsushi Iwata 18 Norihito Fujita 19 NEC Corporation 21 Adrian Farrel 22 Movaz Networks, Inc. 24 Sudheer Dharanikota 25 Nayna Networks 27 Senthil Venkatachalam 28 Dimitri Papadimitriou 29 Alcatel 31 Jean Philippe Vasseur 32 Cisco Systems 34 November, 2001 36 Requirements for Multi-Area TE 38 40 Status of this Memo 42 This document is an Internet-Draft and is in full conformance with 43 all provisions of Section 10 of RFC2026. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that other 47 groups may also distribute working documents as Internet-Drafts. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 Abstract 62 This draft describes requirements for multi-area TE within the context of 63 GMPLS. Based on the requirements, the goal is to eventually provide 64 protocol extensions needed for multi-area TE. Various approaches to 65 multi-area TE are considered, and these approaches are evaluated against the 66 requirements. These approaches include state dependent routing (SDR) LSP 67 selection, event dependent routing (EDR) LSP selection, and time dependent 68 routing (TDR) LSP selection. These approaches include needs to support 69 path-computation server (PCS) functionality, query functionality, crankback 70 functionality, TE feedback functionality, and summary-LSA functionality. 71 The target in future releases of this document will be to converge on a 72 reduced subset of the required multi-area TE methods and protocol 73 extensions. 75 Table of Contents 77 1. Introduction 78 2. Requirements for Multi-Area TE 79 3. Requirements for Information Exchange & Topology Data 80 Base Update 81 4. Comparison of Multi-Area TE Methods 82 4.1 SDR Methods 83 4.2.1 Distributed SDR (D-SDR) Methods 84 4.2.2 Path Computation Server SDR (PCS-SDR) Methods 85 4.2 EDR Methods 86 4.3 TDR Methods 87 5. Requirements for Multi-Area TE Protocol Extensions 88 6. Security Considerations 89 7. Acknowledgments 90 8. References 91 9. Authors' Addresses 92 10. Copyright Statement 93 Appendix A. Multi-Area TE Routing Methods 94 A.1 State-Dependent Routing (SDR) LSP Selection 95 A.2 Event-Dependent Routing (EDR) LSP Selection 96 A.3 Time-Dependent Routing (TDR) LSP Selection 97 A.4 Inter-AS LSP Selection 99 1. Introduction 101 This draft describes requirements for multi-area TE within the context of 102 GMPLS. Based on the requirements, the goal is to eventually provide protocol 103 extensions needed for multi-area TE. Multi-area TE has been recommended to 104 be supported in the requirements from the Traffic Engineering Working Group 105 [hierarchy_restoration_requirements]. Various approaches to multi-area TE 106 are considered, based on the intra-area TE approaches discussed in the 107 [te_framework] and [te_qos_routing], and are evaluated against the 108 requirements. These multi-area TE approaches are outlined in Appendix A, 109 and include state dependent routing (SDR) LSP selection, event dependent 110 routing (EDR) LSP selection, and time dependent routing (TDR) LSP selection. 111 The focus initially is on multi-area TE, and not multi-AS TE. IP over 112 optical (IPO) requirements are considered [mp-lambda-s, gmpls], including 113 the unique routing requirements of the optical plane [stand1, stand2, 114 unique]. 116 Several drafts were presented at the IETF-49 TEWG meeting on multi-area TE, 117 among them [abarbanel], [kompella], [lee], [sudheer1], [sudheer2]. Several 118 of these methods propose the use of a path-computation-server (PCS) 119 capability [kompella, lee, vasseur], query capability [query], crankback 120 capability [crankback], and others suggest the use of summary LSAs 121 [summary_lsa]. These drafts propose different approaches to multi-area TE, 122 but are related by a common set of requirements and protocol needs discussed 123 in this draft. These multi-area TE methods are evaluated against the 124 requirements, and include various protocol extension needs (PCS, query, 125 crankback, etc.). The target in future releases of this document will be to 126 converge on a reduced subset of the required multi-area TE methods and 127 protocol extensions. 129 Many potential users are requesting multi-area TE capability [Swallow, 130 IETF49 TEWG Meeting Minutes]. Presentation slides from an IETF-50/TEWG 131 presentation can be found at 132 134 2. Requirements for Multi-Area TE 136 There are various requirements to be considered in adopting a multi-area TE 137 method, which include the following: 139 a) maximize network utilization and minimize cost, considering QoS 140 objectives 141 b) minimize routing overhead (includes LSAs, crankbacks, queries, 142 etc.), i.e., maximize scalability 143 c) allow various multi-area TE routing methods, including SDR, EDR, and 144 TDR LSP selection (SDR required today, optionally EDR and TDR should be 145 supported) 146 d) allow multiple paths which satisfy path diversity needs (may not be 147 possible depending on the approach) 148 e) allow LSP restoration/protection to occur separately within each 149 area 150 f) allow multi-area information exchange of link protection types in 151 networks that support mixed link protection types 152 g) support bi-directional LSPs and asymmetrical bi-directional LSPs 153 h) ensure that routing constraints and unique IPO requirements can be 154 incorporated in multi-area path selection (may or may not be possible 155 depending on the approach) 156 i) allow multi-area information exchange of link/switch capabilities in 157 networks that support mixed switching types 158 j) allow multi-area GMPLS explicit label control, so that routing 159 protocols are capable of distributing label availability information with 160 respect to lambdas and time slots both within and between areas 161 k) ensure cross-area security/authorization at the same level 162 supported within a single area 164 Hence, multi-area TE protocols need to provide good cross-area path 165 selection and, most importantly, be scalable. As to scalability, concerns 166 have been raised as to the current scalability of IGPs [igp-scale], and 167 there is a need to minimize any further extensions in the complexity of IGP 168 protocols. Multi-area TE protocols need to satisfy restoration/protection 169 requirements, and also support several GMPLS-related path selection needs. 170 GMPLS [gmpls] allows the LSP request to specify the link protection 171 properties required. These are the protection properties of the underlying 172 link not those of the LSP itself. Link protection possibilities are none, 173 1:n, 1:1, 1+1, better than 1+1. Again, TE can only do this correctly if the 174 link protection properties are passed around, and this needs to be supported 175 for multi-area TE. 177 Note that these requirements may or may not be fully satisfied depending on 178 the multi-area TE method being used. Even though various approaches will 179 not meet all requirements, they could still be valuable. Therefore each 180 method is evaluated in Section 4, taking into account the trade-off between 181 optimization and scalability as well as the other requirements listed above. 183 3. Requirements for Information Exchange & Topology Data Base Update 185 As discussed in the Introduction, several multi-area TE methods [kompella, 186 lee, sudheer1, sudheer2, vasseur] are evaluated in the next Section against 187 the requirements, and include various protocol extension needs (PCS, query, 188 crankback, etc.). The target in future releases of this document will be to 189 converge on a reduced subset of the required multi-area TE methods and 190 protocol extensions. Various means of information exchange, including 191 support for PCS functionality, query functionality, crankback functionality, 192 TE feedback functionality, and summary-LSA functionality, are required to 193 build the topology database, to construct the LSP choices, and to determine 194 and establish a LSP from the choices. 196 LSAs [ospf, isis] are flooded within areas to build the topology database at 197 each LSR by advertising link status, node status, reachable addresses, and 198 other information. LSAs could also be advertised between areas; however 199 this could raise scalability issues since areas are established in the first 200 place to limit LSA flooding to a reasonable level within the designated 201 areas (more on this later). Summarized LSAs [summary_lsa] can be flooded 202 between areas to give useful but reduced information, and may also to be 203 scalable. 205 Query [query] messages are required in some multi-area TE methods, for 206 example, between an LER and a path computation server (PCS) [kompella, lee, 207 vasseur], or between an LER and ABR (in this case the ABR plays the role of 208 an PCS), to determine topology database information needed to calculate a 209 path for an LSP. A query could also be used to request that an PCS or ABR 210 compute an LSP path from its topology database, and return it to the 211 requesting LSR, ABR, or other PCS. Various other means of using 212 query-response may be proposed, as described in [kompella]. 214 Using the topology database, the LSR or PCS generates the LSP choices 215 according to a number of different LSP selection methods, such as those 216 described in Section 3 and Appendix A. Crankback [crankback] can be used in 217 LSP setup, or modification, to backtrack to an ABR or LER, if a bottleneck 218 is found in a candidate LSP (e.g., if there is insufficient bandwidth on a 219 particular link in the LSP). Use of crankback to an ABR may or may not be 220 more efficient than rerouting from the head-end LSR, and would depend on the 221 resource requirements and network topology. 223 One way to view the topology database at each LSR or PCS is to consider a 224 decomposition into the slow information database (SIDB) and the fast 225 information database (FIDB). 227 Information in the SIDB changes slowly, for example 229 * max link bandwidth 230 * color 231 * metric (weight, delay, etc.) 232 * reachable addresses 233 * slow available link bandwidth update (e.g., based on >= 5-minute 234 updates) 236 Information in the FIDB changes rapidly, for example 238 * available link bandwidth (e.g., real-time updates) 240 The LSA overhead to flood information in the SIDB is relatively much less 241 than the LSA overhead to flood information in the FIDB, because of the 242 relative rates of change of the database, not because of their relative 243 sizes. It might well be feasible, for example, to flood the full SIDB 244 information between areas, whereas it may not be feasible to flood the 245 full FIDB information (vs. summarized LSA information) between areas. 246 However, flooding of the full SIDB information may also pose some 247 scalability issues. The use of SIDB and FIDB information by each 248 multi-area TE method is detailed in the next section. 250 Note that the SIDB and FIDB information needs to be identified for each 251 class type. TE methods are currently being defined for multiple class types 252 [class] wherein the amount of SIDB/FIDB information will greatly increase 253 (multiplicative by the number of classes). This will increase the emphasis 254 on information exchange methods that decrease the routing overhead in terms 255 of LSAs, crankbacks, queries, etc. In general, SLAs, PHBs, and class types 256 may not be consistent across domains or areas, and could be policy specific. 257 In that case, a consistent meaning for class type needs to be defined. 259 4. Comparison of Multi-Area TE Methods 261 In the previous Sections we gave requirements and needed information 262 exchange for multi-area TE, which included SDR, EDR, and TDR methods 263 described in Appendix A. In this Section we evaluate several multi-area TE 264 methods against the requirements, identify protocol extension needs (PCS, 265 query, crankback, etc.), classify the methods, and discuss the relative 266 advantages and disadvantages of the methods. The target in future releases 267 of this document will be to converge on a reduced subset of the required 268 multi-area TE methods and protocol extensions. 270 See [te_qos_routing] for more detailed comparisons of these methods on the 271 basis of performance, network design impacts, and operational impacts. 272 Multiservice network models are used to evaluate performance, design, and 273 operation. 275 4.1 SDR Methods 277 4.1.1 Distributed SDR (D-SDR) Methods 279 a. [kompella]/scenario 1 approach: 280 - per area path set up 281 - SIDB/FIDB flooded intra-area 282 - normal summary-LSAs inter-area 283 - optionally, use crankback to ABR or LER if LSP setup request fails 284 - feedback [feedback] can be used to help build LSR TE routing database 285 > advantage: reduced LSA flooding between areas 286 > disadvantage: end-to-end path may not be optimal (LSP choices not based on 287 whole topology database), signaling setup time may not be negligible, no 288 possibility to compute diversely routed paths 290 b. [kompella]/scenario 3 approach: 291 - LER gets TE information from backbone-area and computes path to tail-end 292 ABR, tail-end ABR computes rest of path 293 - LER stores both backbone and intra-area SIDB/FIDB for both head-end and 294 backbone area 295 - use crankback if LSP setup request fails 296 - feedback can be used to help build LSR TE routing database 297 > advantage: head-end and backbone area topology database used for LSP 298 determination 299 > disadvantage: large amount of downloaded backbone TE information, call set 300 up failure in tail-end area (mitigating approach presented in [kompella]), 301 no possibility to compute diversely routed paths, end-to-end path may not be 302 optimal (LSP choices not based on whole topology database) 304 c. [sudheer1] approach: 305 - ABRs flood TE-summary-LSA's to other areas 306 - LER sets up LSP based on topology database, including summary-LSA 307 information 308 - transit LSRs use crankback if LSP setup request fails, ABR or LER may try 309 another LSP 310 - SIDB/FIDB flooded intra-area 311 - summarized SIDB/FIDB flooded inter-area (in TE-summary-LSAs) 312 - feedback can be used to help build LSR TE routing database 313 > advantage: reduces flooded information between areas compared to methods 314 that flood entire SIDB/FIDB information 315 > disadvantage: possible scalability issue in amount of flooded information, 316 potentially no possibility to summarize some constraints, end-to-end path 317 may not be optimal (LSP choices not based on whole topology database), no 318 possibility to compute diversely routed path 320 d. D-SDR query approach [te_qos_routing]: 321 - ABRs flood SIDB-LSA's to other areas 322 - LER queries LSRs along candidate LSPs for FIDB information (at time of LSP 323 setup or modification) 324 - LER sets up LSP based on SIDB topology database and FIDB query-information 325 - transit LSRs use crankback if LSP setup request fails, ABR or LER may try 326 another LSP 327 - SIDB flooded intra-area & inter-area 328 - feedback can be used to build LSR TE routing database 329 > advantage: reduces flooded information within areas and between areas, 330 possibility to compute diversely routed paths 331 > disadvantage: extensive use of query capability, end-to-end path may not 332 be optimal (LSP choices not based on whole topology database) 334 4.1.2 Path Computation Server SDR (PCS-SDR) Methods 336 a. [kompella/scenario 2&4, lee, vasseur, te-qos-routing] approach: 337 - this is a distributed PCS approach wherein PCSs could be separate or 338 combined ABR/PCS 339 - PCS(s) within area gather intra-area link-state information (reduces 340 intra-area flooding) 341 - LER queries a PCS in backbone area for path 342 - LER does not download TE information from backbone area (reduces flooding 343 across areas) 344 - crankback may be used for LSP rerouting 345 - PCS may try path query to another PCS within area to determine another LSP 346 - intra-area SIDB/FIDB flooded only to PCSs 347 - uses LER-PCS query 348 > advantage: requires no TE-summary-LSA flooding between areas, possible 349 intra-area LSA flooding reduction, end-to-end optimal path (whole topology 350 database used for LSP determination), possibility to compute diversely 351 routed paths 352 > disadvantage: requires PCS implementation with PCS backup, signaling 353 overhead 355 b. [kompella]/scenario 5 approach: 356 - LER queries central PCS for path 357 - SIDB/FIDB flooded intra-area and to central PCS 358 - uses LER-PCS query 359 - may use crankback for LSP rerouting 360 > advantage: requires no TE-summary-LSA flooding between areas, possible 361 intra-area LSA flooding reduction, end-to-end optimal path (whole topology 362 database used for LSP determination), global optimization possible, 363 possibility to compute diversely routed paths 364 > disadvantage: requires PCS implementation with PCS backup, signaling 365 overhead 367 4.2 EDR Methods 369 Success-to-the-top EDR (STT-EDR) approach [te_qos_routing]: 370 - LER determines CRLSP based on SIDB 371 - uses crankback if LSP setup request fails 372 - SIDB information flooded intra-area and inter-area 373 - no FIDB flooding required 374 - feedback used to build LSR TE routing database 375 > advantage: intra-area and inter-area LSA flooding reduction 376 > disadvantage: end-to-end path may not be optimal (LSP choices not based on 377 whole topology database), no possibility to compute diversely routed paths 379 4.3 TDR Methods [te_framework, te_qos_routing] 381 - LSP selection performed by off-line centralized system 382 - candidate LSPs are pre-planned based on previously measured traffic and 383 downloaded periodically to LSRs 384 - LSP selection patterns change periodically (e.g., each hour) to respond to 385 measured hourly shifts in traffic loads and are periodically recalculated 386 (e.g., each week) 387 > advantage: intra-area and inter-area LSA flooding reduction, possibility 388 to compute diversely routed paths 389 > disadvantage: end-to-end path may not be optimal (LSP choices not adaptive 390 to network status) 392 5. Requirements for Multi-Area TE Protocol Extensions 394 Initial requirements are given here for protocol support of the multi-area 395 TE methods, which include needs to support 397 * path-computation-server (PCS) functionality [kompella, lee, vasseur, 398 te-qos-routing], 399 * query functionality [query, vasseur], 400 * crankback functionality [crankback], 402 and, optionally, 404 * TE feedback functionality [feedback], and 405 * summary-LSA functionality [summary_lsa]. 407 Details of the proposed protocol upgrades necessitated by the 408 various multi-area TE solution approaches are already available in the 409 various drafts referenced. 411 6. Security Considerations 413 The multi-area routing extensions for RSVP-TE and CRLDP inherit the same 414 security mechanisms described in [rsvp_te, crldp] to protect against 415 spoofing attacks of a session, the privacy of signaling messages, and the 416 denial of service (DoS) attacks. Different areas may apply distinct 417 security models and may have different means of signaling security 418 (especially if one area does not use MPLS). Joining security domains would 419 introduce security issues that need to be addressed. 421 7. Acknowledgments 423 Comments and suggestions from Dan Awduche are much appreciated. 425 8. References 427 [abarbanel] Ben Abarbanel, Senthil K. Venkatachalam, "BGP-4 support for 428 Traffic Engineering," work in progress. 430 [awduche] D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE 431 Communications Magazine, December 1999. 433 [class] Francois Le Faucheur, et. al., "Requirements for support of 434 Diff-Serv-aware MPLS Traffic Engineering," work in progress. 436 [crldp] B. Jamoussi, et al., "Constraint-Based LSP Setup using LDP," work in 437 progress. 439 [crankback] Atsushi Iwata, Norihito Fujita, Gerald R. Ash, Adrian Farrel, 440 "Crankback Routing Extensions for MPLS Signaling,", work in progress. 442 [feedback] Peter Ashwood-Smith, Bilel Jamoussi, Don Fedyk, Darek Skalecki 443 "Improving Topology Data Base Accuracy with LSP Feedback," work in progress. 445 [gmpls] P. Ashwood-Smith and L. Berger, et al., "Generalized MPLS-Signaling 446 Functional Description,", work in progress. 448 [hierarchiy_restoration_requirements] Wai Sum Lai, et. al., "Network 449 Hierarchy and Multilayer Survivability," work in progress. 451 [igp-scale] Ash, G., et. al., "Proposed Mechanisms for Congestion Control/ 452 Failure Recovery in OSPF & ISIS Networks," work in progress. 454 [isis] R. Callon, "Use of OSI IS-IS for Routing in TCP/IP and Dual 455 Environments," RFC1195, December 1990. 457 [kompella] Kireeti Kompella, Yakov Rekhter, JP Vasseur, "Multi-area MPLS 458 Traffic Engineering," work in progress. 460 [lee] Cheng-Yin Lee, Alicja Celer, Neil Gammage, Sudhakar Ganti, Gerald Ash, 461 "Distributed Route Exchangers," work in progress. 463 [ldp] L. Andersson, et. al., "LDP Specification," RFC 3036, January 2001. 465 [mp-lambda-s] D. Awduche, et al., "Multi-Protocol Lambda Switching: 466 Combining MPLS Traffic Engineering Control with Optical Crossconnects," IEEE 467 Communications Magazine, March 2001. 469 [ospf] J. Moy, "OSPF Version 2," RFC2328, April 1998. 471 [query] Cheng-Yin Lee, Sudhakar Ganti, "Path Request and Path Reply 472 Message,", work in progress. 474 [recovery] S. Makam, et. al., "Framework for MPLS-based Recovery," work in 475 progress. 477 [rsvp] R. Braden, et al., "Resource ReSerVation Protocol (RSVP)--Version 1 478 Functional Specification, RFC2205, September 1997. 480 [rsvp_te] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels," work in 481 progress. 483 [strand1] John Strand, Angela Chiu, Robert Tkach, "Issues for Routing in the 484 Optical Layer," IEEE Communications Magazine, February 2001. 486 [strand2] John Strand, Yong Xue, "Routing for Optical Networks With Multiple 487 Routing Domains," oif2001.046 (for a copy send an email request to 488 jls@research.att.com). 490 [sudheer1] Senthil K. Venkatachalam, Sudheer Dharanikota, "A Framework for 491 the LSP Setup Across IGP Areas for MPLS Traffic Engineering,", work in 492 progress. 494 [sudheer2] Senthil K. Venkatachalam, Sudheer Dharanikota, Thomas D. Nadeau, 495 "OSPF, IS-IS, RSVP, CR-LDP extensions to support inter-area traffic 496 engineering using MPLS TE," work in progress. 498 [summary_lsa] Atsushi Iwata, Norihito Fujita, "Traffic Engineering 499 Extensions to OSPF Summary LSA," work in progress. 501 [te_qos_routing] G. Ash, "Traffic Engineering & QoS methods for IP-, ATM-, & 502 TDM-Based Multiservice Networks," work in progress. 504 [te_framework] D. Awduche, et. al., "Overview & Principles of Internet 505 Traffic Engineering" work in progress. 507 [te_requirements] D. Awduche, et al., "Requirements for Traffic Engineering 508 Over MPLS," RFC2702, September 1999. 510 [unique] Angela Chiu, John Strand, Robert Tkach, "Unique Features and 511 Requirements for The Optical Layer Control Plane," work in progress. 513 [vasseur] JP Vasseur, "RSVP Path Computation Request and Reply Messages," 514 work in progress. 516 9. Authors' Addresses 518 Jerry Ash 519 AT&T 520 Room MT D5-2A01 521 200 Laurel Avenue 522 Middletown, NJ 07748, USA 523 Phone: +1-(732)-420-4578 524 Fax: +1-(732)-368-8659 525 Email: gash@att.com 527 Alicja Celer 528 Nortel Networks 529 Email: aceler@nortelnetworks.com 531 Sudheer Dharanikota 532 Nayna Networks 533 157 Topaz Drive 534 Milpitas, CA 95035 535 Phone: (408)-956-8000 x357 536 Email: sudheer@nayna.com 538 Adrian Farrel 539 Movaz Networks, Inc. 540 7926 Jones Branch Drive, Suite 615 541 McLean, VA 22102 542 Phone: +1-(703)-847-9847 543 Email: afarrel@movaz.com 545 Norihito Fujita 546 NEC Corporation 547 Networking Research Laboratories 548 1-1, Miyazaki, 4-Chome, Miyamae-ku, 549 Kawasaki, Kanagawa, 216-8555, JAPAN 550 Phone: +81-(44)-856-2123 551 Fax: +81-(44)-856-2230 552 Email: n-fujita@bk.jp.nec.com 554 Neil Gammage 555 Motorola 556 Email: neil.gammage@motorola.com 558 Sudhakar Ganti 559 Tropic Networks Inc. 560 135 Michael Cowpland Drive 561 Kanata, Ontario, Canada, K2M 2E9 562 Email: sganti@tropicnetworks.com 564 Atsushi Iwata 565 NEC Corporation 566 Networking Research Laboratories 567 1-1, Miyazaki, 4-Chome, Miyamae-ku, 568 Kawasaki, Kanagawa, 216-8555, JAPAN 569 Phone: +81-(44)-856-2123 570 Fax: +81-(44)-856-2230 571 Email: a-iwata@ah.jp.nec.com 572 Atsushi Iwata 574 Cheng-Yin Lee 575 King Associates 576 Email: : leecy@sympatico.ca 578 Dimitri Papadimitriou 579 Optical Networking Alcatel NSG-NA 580 Corporate Research Center - Network Strategy Group 581 Francis Wellesplein, 1 582 B-2018, Antwerpen - Belgium 583 Phone: +323-2408491 584 Email: Dimitri.Papadimitriou@alcatel.be 586 John Strand 587 AT&T 588 Room MT A5-1D06 589 200 Laurel Avenue 590 Middletown, NJ 07748, USA 591 Phone: +1-(732)-420-9036 592 Fax: +1-(732)-368-9433 593 Email: jstrand@att.com 595 Jean Philippe Vasseur 596 Cisco Systems, Inc. 597 11, rue Camille Desmoulins 598 92782 Issy les Moulineaux Cedex 9 599 France 600 Email: jpv@cisco.com 602 Senthil K. Venkatachalam 603 Alcatel USA 604 45195 Business Court, Suite 400 605 Dulles, VA 20166 606 Phone: (703)654-8635 607 Email: Senthil.Venkatachalam@usa.alcatel.com 609 10. Copyright Statement 611 Copyright (C) The Internet Society (1998). All Rights Reserved. 613 This document and translations of it may be copied and furnished to others, 614 and derivative works that comment on or otherwise explain it or assist in 615 its implementation may be prepared, copied, published and distributed, in 616 whole or in part, without restriction of any kind, provided that the above 617 copyright notice and this paragraph are included on all such copies and 618 derivative works. 620 However, this document itself may not be modified in any way, such as by 621 removing the copyright notice or references to the Internet Society or other 622 Internet organizations, except as needed for the purpose of developing 623 Internet standards in which case the procedures for copyrights defined in 624 the Internet Standards process must be followed, or as required to translate 625 it into languages other than English. 627 The limited permissions granted above are perpetual and will not be revoked 628 by the Internet Society or its successors or assigns. 630 This document and the information contained herein is provided on an "AS IS" 631 basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 632 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 633 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 634 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 635 PARTICULAR PURPOSE. 637 Appendix A. Multi-Area TE Routing Methods 639 Internet Traffic Engineering is concerned with the performance optimization 640 of operational networks [awduche]. It encompasses the measurement, modeling, 641 characterization, and control of Internet traffic, and the application of 642 techniques to achieve specific performance objectives, including the 643 reliable and expeditious movement of traffic through the network, the 644 efficient utilization of network resources, and the planning of network 645 capacity. 647 Multi-area or multi-AS topologies are normally used with IP routing 648 protocols (e.g., OSPF, BGP). Traffic trunks can be defined by LSPs between 649 LSRs, and are used to allocate the bandwidth of the logical links to various 650 LSR pairs. TE LSP routing is characterized by the LSP choices used in the 651 method and rules to select one LSP for a given connection or 652 bandwidth-allocation request. When an LSP bandwidth-allocation request is 653 initiated by an LER, the LER implementing the routing method executes the 654 LSP selection rules to find an admissible LSP from among the LSPs that 655 satisfy the request. In a network with source routing, the LER maintains 656 control of the LSP request, and in the case of multi-area TE, this must be 657 done across different areas. 659 With source routing, the LER identifies the entire selected LSP including 660 all intermediate or via LSRs (VLSRs) and egress LSR (ELSR) in the LSP in an 661 explicit-route (ER) parameter. Some VLSRs may lie on the boundary of areas 662 and are area border routers (ABRs). If the QoS or traffic parameters cannot 663 be realized at any one of the VLSRs in the LSP setup request, then the VLSR 664 generates a crankback parameter which allows a VLSR to return control of the 665 bandwidth-allocation request to the LER or ABR for further alternate 666 routing. 668 LSPs are determined by (normally proprietary) algorithms based on the 669 network topology and reachable address information. LSPs can cross multiple 670 areas within an AS, and also cross multiple ASs. An LER may select an LSP 671 based on the routing rules and the QoS resource management criteria, which 672 must be satisfied on each link in the LSP. In addition to controlling 673 bandwidth allocation, the QoS resource management procedures can check other 674 QoS parameters, such as end-to-end transfer delay, delay variation, and 675 transmission quality considerations such as loss, echo, and noise. 676 LSP selection methods are categorized into the following three types: 678 * state-dependent routing (SDR) LSP selection, 679 * event-dependent routing (EDR) LSP selection, and 680 * time-dependent routing (TDR) LSP selection 682 LSP choices can be changed dynamically, either on-line, in real 683 time, as in SDR or EDR, or in an off-line, preplanned, time-varying manner, 684 as in TDR. Real-time LSP selection does not depend on precalculated LSP 685 choices. Rather, the LSR or path computation server (PCS) senses the 686 immediate traffic load and if necessary searches out new LSPs through the 687 network. On-line, real-time LSP selection methods include EDR and SDR. With 688 off-line, pre-planned TDR LSP selection, LSP choices might change every hour 689 or at least several times a day to respond to measured hourly shifts in 690 traffic loads, and are periodically recalculated, perhaps each week. Note 691 that SDR LSP selection is the only method currently available and deployed. 693 An LER can fully calculate an ER at the source based on TDR, SDR, or 694 EDR LSP selection, or the ER can include loose hops which are used at ABRs. 695 In the latter case, the ER processing rules allow the ABRs to insert a 696 series of hops to navigate to the next ABR, thus the LSP choice is not 697 constrained to the LER. This distinction is made in [crankback], but only 698 after the initial signaling attempt (with the LER-signaled ER) has failed. 699 The designation of ABRs along the path is a possible method that may or may 700 not use crankback. 702 A.1 State-Dependent Routing (SDR) LSP Selection 704 SDR LSP selection is the only method currently available and 705 deployed. In SDR, the LSP choices are altered automatically according to 706 the state of the network. For a given SDR method, the LSP selection rules 707 are implemented to determine the LSP choices in response to changing network 708 status, and are used over a relatively short time period. Information on 709 network status may be collected at a central path computation server (PCS) 710 processor or distributed to multiple PCSs or the LSRs in the network. 712 The information exchange may be performed by 714 * flooding the information to all the PCSs and/or LSRs in the network 715 * querying PCSs or LSRs on an on-demand basis for needed information, 716 * feeding the information back on LSP signaling messages 717 * a combination of any of the above 719 SDR methods route LSP bandwidth-allocation requests on the best available 720 LSP on the basis of network state information. For example, in the least 721 loaded routing (LLR) method, the residual capacity of candidate LSPs is 722 calculated, and the LSP having the largest residual capacity is selected for 723 the bandwidth-allocation request. Various relative levels of link occupancy 724 can be used to define link load states, such as lightly-loaded, 725 heavily-loaded, or bandwidth-not-available states. In general, SDR methods 726 calculate a LSP cost for each bandwidth-allocation request based on various 727 factors such as the path metric (IGP or TE metric) or reservation state of 728 the links in the network. 730 In SDR, the LSP choices are designed on-line by the LER or an PCS through 731 the use of network status and topology information obtained through 732 information exchange with other LSRs and/or other PCSs. There are various 733 implementations of SDR distinguished by whether the computation of the LSP 734 choices is 736 a) distributed among all the LSRs in an AS, or 737 b) done in a centralized PCS per AS, or perhaps several PCSs (e.g., 1 738 or more per AS area). 740 This leads to two different implementations of SDR: 742 a) distributed SDR (D-SDR) -- here each LSR in the AS obtains topology 743 and status information from all the other LSRs. Normally the topology 744 status information is flooded throughout each area in the AS, and between 745 areas with summary-LSAs. In another form of D-SDR, rather than flooding 746 information an LER queries the other LSRs in the candidate LSPs to obtain 747 topology and status information. To determine an LSP explicit route, the 748 LER executes a particular routing optimization procedure such as LLR. 750 b) path computation server SDR (PCS-SDR) -- here the centralized PCS or 751 several PCSs obtain topology and status information from the various LSRs 752 within an AS or within an AS-area. The topology/status information can be 753 sent on a periodic basis (e.g., every few seconds) or based on 754 topology/status changes. The PCS performs a computation of the candidate 755 LSPs on a periodic basis (e.g., every few seconds) or on-demand (e.g., 756 initiated by a query from an LER). To determine the LSP explicit route, the 757 PCS computes the constrained route by executing a particular routing 758 optimization procedure such as LLR. The LSPs are either transmitted to the 759 LSRs on a periodic basis (e.g., every few seconds) or provided on demand 760 from an LER. 762 The essential distinction between D-SDR and PCS-SDR LSP selection is where 763 the TE routing database is kept and the LSP choices are made. In the D-SDR 764 case, the database and LSP choices are made at the LSRs themselves. In the 765 PCS-SDR case, the database and LSP choices are made at the PCS(s). Note 766 that in PCS-SDR the path computation server may be a dedicated off-line 767 server or one or several ABR LSRs (see scenarios 2, 4, and 5 of [Kompella]). 769 In either instance, LSP explicit routes may be determined based on the 770 constraints specified and analysis of the status data. For example, an LSP 771 selection method might provide that the primary (shortest) LSP choice is 772 used if the bandwidth is available. If the bandwidth is unavailable on one 773 or more links, a second LSP is selected from the list of feasible LSPs on 774 the basis of having the greatest level of idle bandwidth at the time. This 775 second LSP may be used to provide bandwidth capacity in addition to that 776 already provided by the primary LSP between the LER and egress LSR. The 777 second LSP may be selected from among a pre-stored list of candidate LSPs or 778 computed on line based on the constraints and network status information in 779 the TE routing database. Dynamically activated bandwidth reservation can be 780 used to protect against inefficient LSP usage, and other controls used to 781 automatically modify LSP choices during network overloads and failures 782 [te_qos_routing]. 784 A.2 Event-Dependent Routing (EDR) LSP Selection 786 EDR LSP selection is an optional method that is not currently available and 787 deployed. In EDR, the LSP choices are updated locally on the basis of 788 whether connections succeed or fail on a given LSP choice. In the EDR 789 learning approaches, the LSP last tried, which is also successful, is tried 790 again until blocked, at which time another LSP is selected at random and 791 tried on the next bandwidth-allocation request. Success-to-the-top (STT) 792 EDR LSP selection is a decentralized, on-line LSP selection method with 793 update based on random routing. STT-EDR uses a simplified decentralized 794 learning method: The primary LSP LSP-p is used first if available, and a 795 currently successful alternate LSP LSP-s is used until it is blocked. In 796 the case that LSP-s is blocked (e.g., bandwidth is not available on one 797 or more links), a new alternate LSP LSP-n is selected at random as the 798 alternate LSP choice for the next bandwidth-allocation request overflow 799 from the primary LSP. Dynamically activated bandwidth reservation is used 800 under congestion conditions to protect traffic on the primary LSP. STT-EDR 801 uses crankback when an alternate LSP is blocked at a VLSR, and the 802 bandwidth-allocation request advances to a new random LSP choice. In 803 STT-EDR, many LSP choices can be tried by a given bandwidth-allocation 804 request before the request is blocked. 806 The main point of EDR is that is does not require a centralized database of 807 FIDB information, such as is provided in D-SDR at each LSR through flooding 808 or query, or in PCS-SDR at each PCS. In the case of EDR, the FIDB 809 information is accessed locally at each LSR as the LSP is set up or 810 modified. Hence in EDR, the FIDB information is decentralized, however with 811 SDR the FIDB information is kept in one database, either in the LSRs or 812 centralized in an PCS. In the EDR learning approaches, the current alternate 813 LSP choice can be updated randomly, cyclically, or by some other means, and 814 may be maintained as long as a connection can be established successfully on 815 the LSP. Hence the LSP selection is constructed with the information 816 determined during connection setup, and no additional information is 817 required by the LER. 819 A.3 Time-Dependent Routing (TDR) LSP Selection 821 TDR LSP selection is an optional method that is not currently available and 822 deployed. With TDR methods the LSP choices are altered at a fixed point in 823 time during the day or week. TDR LSP choices are determined on an off-line, 824 preplanned basis and are implemented consistently over a time period. The 825 TDR LSP choices are determined considering the time variation of traffic 826 load in the network, for example based on measured hourly load patterns. 827 Several TDR time periods are used to divide up the hours into contiguous 828 routing intervals. Typically, the TDR LSP choices used in the network are 829 coordinated to take advantage of noncoincidence of busy hours among the 830 traffic loads. 832 In TDR, the LSP choices are preplanned and designed off-line using a 833 centralized system, which employs a TDR network design model. The off-line 834 computation determines the optimal routes from a potentially very large 835 number of possible alternatives, in order to maximize network throughput 836 and/or minimize the network cost. The designed LSP choices are loaded and 837 stored in the various LSRs in the TDR network, and periodically recomputed 838 and updated (e.g., every week) by the central system. In this way an LER 839 does not require additional network information to construct TDR LSP 840 choices, once the LSP choices have been loaded. This is in contrast to the 841 design of LSP choices on-line in real time, such as in the SDR and EDR 842 methods described below. LSPs in the TDR routing table may consist of time 843 varying routing choices and use a subset of the available LSPs. That is, we 844 can distinguish between LSP calculation/choice and LSP establishment. In 845 TDR, the LSP choices are made off line and are changed by a change in time 846 period. In SDR and EDR, the LSP choices are determined on line and changed 847 by a change in the network state and/or an event such as a blocked LSP 848 request (a variant of SDR and EDR could be to have the LSP choices made off 849 line). 851 LSPs in the TDR routing table may consist of several (possibly 852 multiple-link) LSPs through multiple VLSRs. If a connection on one link in a 853 LSP is blocked (e.g., because of insufficient bandwidth), the 854 bandwidth-allocation request then attempts another complete LSP. 855 Implementation of such a routing method can be done through control from the 856 LER or ABR, plus a crankback capability that allows a bandwidth-allocation 857 request blocked on a link in an LSP to return to the LER or ABR for further 858 alternate routing on other LSPs. 860 Changing a TDR LSP should be done, for example, using a make before break 861 method to avoid traffic disruption. If a TDR LSP change should fail due to 862 lack of available resources, this would trigger alarms and the use of the 863 previous TDR LSP could be used in the interim. 865 A.4 Inter-AS LSP Selection 867 In selecting LSPs between autonomous systems (ASs), which themselves may 868 consist of multiple areas, inter-AS routing capabilities such as BGP 869 [abarbanel] need to be considered. Though not specifically addressed in this 870 draft, some of the multi-area TE methods described herein can very well be 871 used to address the needs of multi-AS LSP selection as well. Details of 872 inter-AS LSP selection are TBD.