idnits 2.17.1 draft-ietf-tewg-interas-mpls-te-req-08.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 23) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The proposed solution SHOULD be able to interoperate with fault detection mechanisms of intra-AS TE and MAY or MAY NOT require the inter-AS TE tunnel ending addresses to be known or routable across IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with working return paths. -- 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.) -- The document date (August 2004) is 7194 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'TE-SURVIV' is defined on line 1134, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE-CAP' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: 'BGP-Label' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: 'INTER-AS-TE' is defined on line 1186, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') -- No information found for draft-ietf-l3vpn - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3272 (ref. 'TE-OVW') (Obsoleted by RFC 9522) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) -- No information found for draft-ietf-tewg-diff - is the name correct? == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-05 -- Obsolete informational reference (is this intentional?): RFC 2370 (ref. 'OSPF-TE') (Obsoleted by RFC 5250) == Outdated reference: A later version (-05) exists of draft-vasseur-mpls-computation-rsvp-03 -- Obsolete informational reference (is this intentional?): RFC 3107 (ref. 'BGP-Label') (Obsoleted by RFC 8277) Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF Internet Draft Raymond Zhang, Editor 2 Internet Engineering Task Force Infonet Services Corporation 3 draft-ietf-tewg-interas-mpls-te-req-08.txt JP Vasseur, Co-Editor 4 Expires: Feb. 2005 CISCO Systems,Inc 5 August 2004 7 MPLS Inter-AS Traffic Engineering requirements 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or made obsolete by other 19 documents at any time. It is inappropriate to use an Internet-Draft 20 as reference material or to cite it other than as "work in 21 progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document discusses requirements for the support of inter-AS 31 MPLS Traffic Engineering (MPLS TE). Its main objective is to 32 present a set of requirements which would result in general 33 guidelines for the definition, selection and 34 specification development for any technical solution(s) meeting 35 these requirements. 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in [RFC-2119]. 43 Table of Contents 45 1. Introduction.......................................................3 46 2. Contributing Authors...............................................4 47 3. Definitions and Requirements Statement.............................5 48 3.1. Definitions......................................................5 49 3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6 50 3.2.1. Inter-AS Bandwidth Guarantees..................................6 51 3.2.2. Inter-AS Resource Optimization.................................7 52 3.2.3. Fast Recovery across ASes......................................8 53 3.3. Inter-AS Traffic Engineering Requirements Statement..............8 54 4. Application Scenarios..............................................8 55 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees....9 56 4.1.1. Scenario I - Extended or Virtual PoP...........................9 57 4.1.2. Scenario II - Extended or Virtual Trunk.......................10 58 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE......11 59 4.2. Application Scenarios Requiring Inter-AS Resource Optimization..12 60 4.2.1. Scenario IV - TE across multi-AS within a Single SP 61 Administrative Domain.........................................12 62 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13 63 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14 64 5.1. Requirements within one SP Administrative Domain................14 65 5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14 66 5.1.2. Protocol Signaling and Path Computations......................15 67 5.1.3. Optimality....................................................15 68 5.1.4. Support of diversely routed inter-AS TE LSP...................15 69 5.1.5. Re-optimization...............................................16 70 5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16 71 5.1.7. DS-TE Support.................................................17 72 5.1.8. Scalability and Hierarchical LSP Support......................17 73 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels..............17 74 5.1.10. Inter-AS MPLS TE Management..................................18 75 5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................18 76 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18 77 5.1.11. Extensibility................................................19 78 5.1.12. Complexity and Risks.........................................19 79 5.1.13. Backward Compatibility.......................................19 80 5.1.14. Performance..................................................19 81 5.2. Requirements for Inter-AS MPLS TE across Multiple SP 82 Administrative Domains..........................................20 83 5.2.1. Confidentiality...............................................20 84 5.2.2. Policy Control................................................20 85 5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................21 86 5.2.2.2. Inter-AS TE Rewrite Policies................................21 87 5.2.2.3 Inter-AS Traffic Policing....................................22 88 6. Security Considerations...........................................22 89 7. Acknowledgement...................................................22 90 8. Editor's Addresses................................................22 91 9. Normative References............................................. 23 92 10. Informative References...........................................23 93 11. Full Copyright Statement.........................................25 94 Appendix A. Brief Description of BGP based Inter-AS Traffic 95 Engineering..............................................26 97 1. Introduction 99 The MPLS Traffic Engineering (TE) mechanism documented in [TE-RSVP] 100 may be deployed by Service Providers to achieve some of the most 101 important objectives of network traffic engineering as described in 102 [TE-OVW]. These objectives are summarized as: 104 - Supporting end-to-end services requiring QoS guarantees 105 - Performing network resource optimization 106 - Providing fast recovery 108 However, this traffic engineering mechanism can only be used within 109 an Autonomous System (AS). 111 This document discusses requirements for an inter-AS MPLS Traffic 112 Engineering mechanism that may be used to achieve the same set of 113 objectives across AS boundaries within or beyond a SP's 114 aministrative domains. 116 The document will also present a set of application scenarios where 117 the inter-AS traffic engineering mechanism may be required. 119 These application scenarios will facilitate discussions for a 120 detailed requirements list for this inter-AS Traffic Engineering 121 mechanism. 123 Please note that there are other means of traffic engineering 124 including Interior Gateway Protocol (IGP); metrics based (for use 125 within an AS); and Border Gateway Protocol (BGP) attribute based 126 (for use across ASes, as described in Appendix A). However, because 127 these means offer coarser control of traffic paths and do not 128 readily offer bandwidth guarantees or fast restoration, they will 129 not be discussed further in this document. 131 This document doesn't make any claims with respect to whether it is 132 possible to have a practical solution that meets all the 133 requirements listed in this document. 135 2. Contributing Authors 137 The text and content of this document was contributed to by the 138 co-authors listed below (The contact information for the editors 139 appears in section 9, and is not repeated below.): 141 Kenji Kumaki 142 KDDI Corporation 143 Garden Air Tower 144 Iidabashi, Chiyoda-ku, 145 Tokyo 102-8460, JAPAN 146 E-mail : ke-kumaki@kddi.com 148 Paul Mabey 149 Qwest Communications 150 950 17th Street, 151 Denver, CO 80202, USA 152 Email: pmabey@qwest.com 154 Nadim Constantine 155 Infonet Services Corporation 156 2160 E. Grand Ave. 157 El Segundo, CA 90025. USA 158 Email: nadim_constantine@infonet.com 160 Pierre Merckx 161 EQUANT 162 1041 route des Dolines - BP 347 163 06906 SOPHIA ANTIPOLIS Cedex, FRANCE 164 Email: pierre.merckx@equant.com 166 Ting Wo Chung 167 Bell Canada 168 181 Bay Street, Suite 350 169 Toronto, Ontario, Canada, M5J 2T3 170 Email: ting_wo.chung@bell.ca 172 Jean-Louis Le Roux 173 France Telecom 174 2, avenue Pierre-Marzin 175 22307 Lannion Cedex, France 176 E-mail: jeanlouis.leroux@francetelecom.com 178 Yonghwan Kim 179 SBC Laboratories, Inc. 180 4698 Willow Road 181 Pleasanton, CA 94588, USA 182 Email: Yonghwan_Kim@labs.sbc.com 184 3. Definitions and Requirements Statement 186 3.1. Definitions 188 The following provides a list of abbreviations or acronyms 189 specifically pertaining to this document: 191 SP: Service Providers including regional or global providers 193 SP Administrative Domain: a single SP administration over a network 194 or networks that may consist of one AS or 195 multiple ASes. 197 IP-only networks: SP's network where IP routing protocols such as 198 IGP/ BGP are activated 200 IP/MPLS networks: SP's network where MPLS switching capabilities and 201 signaling controls (e.g. ones described in 202 [MPLS-ARCH]) are activated in addition to IP 203 routing protocols. 205 Intra-AS TE: A generic definition for traffic engineering mechanisms 206 operating over IP-only and/ or IP/MPLS network within 207 an 208 AS. 210 Inter-AS TE: A generic definition for traffic engineering mechanisms 211 operating over IP-only and/ or IP/MPLS network across 212 one or multiple ASes. 214 TE LSP: MPLS Traffic Engineering Label Switched Path 216 Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its 217 TE Label Switched Path (LSP), Head-end Label 218 Switching Router (LSR) and Tail-end LSR reside in 219 the same AS for traffic engineering purposes. 221 Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its 222 TE LSPs Head-end LSR and Tail-end LSR do not 223 reside within the same AS or both Head-end LSR and 224 Tail-end LSR are in the same AS but the TE LSP 225 transiting path may be across different ASes 227 ASBR Routers: Border routers used to connect to another AS of a 228 different or the same Service Provider via one or more 229 links inter-connecting between ASes. 231 Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, 232 e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... 233 ASBRn-ASn. 235 Inter-AS TE Segment: A portion of the Inter-AS TE path. 237 Inter-AS DS-TE: Diffserv-aware Inter-AS TE. 239 CE: Customer Edge Equipment 241 PE: Provider Edge Equipment that has direct connections to CEs. 243 P: Provider Equipment that has backbone trunk connections only. 245 VRF: Virtual Private Network (VPN) Routing and Forwarding Instance. 247 PoP: Point of presence or a node in SP's network. 249 SRLG: A set of links may constitute a 'shared risk link group' 250 (SRLG) if they share a resource whose failure may affect all 251 links in the set as defined in [GMPLS-ROUT]. 253 Please note that the terms of CE, PE and P used throughout this 254 document are generic in their definitions. In particular, whenever 255 such acronyms are used, it does not necessarily mean that CE is 256 connected to a PE in a VRF environment described in such IETF drafts 257 as [BGP-MPLSVPN]. 259 3.2. Objectives and Requirements of Inter-AS Traffic Engineering 261 As mentioned in section 1 above, some SPs have requirements for 262 achieving the same set of traffic engineering objectives as 263 presented in [TE-OVW] across AS boundaries. 265 This section examines these requirements in each of the key 266 corresponding areas: 1) Inter-AS bandwidth guarantees; 2) 267 Inter-AS Resource Optimization and 3) Fast Recovery across ASes, 268 i.e. Recovery of Inter-AS Links/SRLG and ASBR Nodes. 270 3.2.1. Inter-AS Bandwidth Guarantees 272 The DiffServ IETF working group has defined a set of mechanisms 273 described in [DIFF_ARCH], [DIFF_AF] and [DIFF_EF] or [MPLS-Diff] 274 that can be activated at the edge or over a DiffServ domain to 275 contribute to the enforcement of a (set of) QoS policy(ies), which 276 can be expressed in terms of maximum one-way transit delay, 277 inter-packet delay variation, loss rate, etc. 279 Many SPs have partial or full deployment of Diffserv implementations 280 in their networks today, either across the entire network or 281 minimally on the edge of the network across CE-PE links. 283 In situations where strict Quality of Service (QOS) bounds are 284 required, admission control inside the backbone of a network is in 285 some cases required in addition to current Diffserv mechanisms. 287 When the propagation delay can be bounded, the performance targets, 288 such as maximum one-way transit delay, may be guaranteed by 289 providing bandwidth guarantees along the Diffserv-enabled path. 291 One typical example of this requirement is to provide bandwidth 292 guarantees over an end-to-end path for VoIP traffic classified as EF 293 (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled 294 network. When the EF path is extended across multiple ASes, 295 inter-AS bandwidth guarantee is then required. 297 Another case for inter-AS bandwidth guarantee is the requirement for 298 guaranteeing a certain amount of transit bandwidth across one or 299 multiple ASes. 301 Several application scenarios are presented to further illustrate 302 this requirement in section 4 below. 304 3.2.2. Inter-AS Resource Optimization 306 In Service Provider (SP) networks, the BGP protocol [BGP] is 307 deployed to exchange routing information between ASes. The inter-AS 308 capabilities of BGP may also be employed for traffic engineering 309 purposes across the AS boundaries. Appendix A provides a 310 brief description of the current BGP-based inter-AS traffic 311 engineering practices. 313 SPs have managed to survive with this coarse set of BGP-based 314 traffic engineering facilities across inter-AS links in a largely 315 best-effort environment. Certainly in many cases ample bandwidth 316 within SP's network and across inter-AS links reduces the need for 317 more elaborate inter-AS TE policies. 319 However, in the case where a SP network is deployed over multiple 320 ASes, for example, as the number of inter-AS links grows, the 321 complexity of the inter-AS policies and the difficulty in inter-AS 322 TE path optimization increase to a level such that it may soon 323 become unmanageable. 325 Another example is where inter-AS links are established between 326 different SP administrative domains. Un-deterministic factors such 327 as un-coordinated routing and network changes, as well as sub- 328 optimum traffic conditions would potentially lead to a complex set 329 of Inter-AS traffic engineering policies where current traffic 330 engineering mechanisms would probably not scale well. 332 In these situations where resource optimization is required and/ or 333 specific routing requirements arise, the BGP-based inter-AS 334 facilities will need to be complemented by a more granular inter-AS 335 traffic engineering mechanism. 337 3.2.3. Fast Recovery across ASes 339 When extending services such as VoIP across ASes, customers often 340 reqiure SPs to maintain the same level of performance targets, such 341 as packet loss and service availability, as achieved within an AS. 342 As a consequence, fast convergence in a stable fashion upon 343 link/SRLG/node failures becomes a strong requirement. This is 344 clearly difficult to achieve with current inter-domain techniques, 345 especially in cases of link/SRLG failures between ASBRs or ASBR node 346 failures. 348 3.3. Inter-AS Traffic Engineering Requirements Statement 350 Just as in the applicable case of deploying MPLS TE in a SP's 351 network, an inter-AS TE method in addition to BGP-based traffic 352 engineering capabilities needs to be deployed across inter-AS links 353 where resource optimization, QOS guarantees and fast recovery 354 are required. 356 This is especially critical in a Diffserv-enabled, multi-class 357 environment described in [PSTE] where statistical performance 358 targets must be maintained consistently over the entire path 359 across different ASes. 361 The approach of extending current intra-AS MPLS TE capabilities 362 [TE-RSVP] across inter-AS links for IP/MPLS networks is considered 363 here because of already available implementations and operational 364 experiences. 366 Please note that the inter-AS traffic engineering over an IP-only 367 network is for future consideration since there is not sufficient 368 interest for similar requirements to those of IP/MPLS networks 369 at this time. More specifically, this document only covers the 370 inter-AS TE requirements for packet based IP/MPLS networks. 372 4. Application Scenarios 374 The following sections present a few application scenarios over 375 IP/MPLS networks where requirements cannot be addressed with current 376 intra-AS MPLS TE mechanism and give rise to considerations for 377 inter-AS MPLS traffic engineering requirements. 379 Although not explicitly noted in the following discussions, fast 380 recovery of traffic path(s) crossing multiple ASes in a stable 381 fashion is particularly important in the case of link/SRLG/node 382 failures at AS boundaries for all application scenarios presented 383 here. 385 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees 387 4.1.1 Scenario I - Extended or Virtual PoP (VPoP) 389 A global service provider (SP1) would like to expand its reach into 390 a region where a regional service provider's (SP2) network has 391 already established a denser network presence. 393 In this scenario, the SP1 may establish interconnections with SP2 in 394 one or multiple points in that region. In their customer dense 395 regions, SP1 may utilize SP2's network as an extended transport by 396 co-locating aggregation routers in SP2's PoPs. 398 In order to ensure bandwidth capacity provided by SP2 and achieve 399 some degrees of transparency to SP2's network changes in terms of 400 capacity and network conditions, one or more Inter-AS MPLS TE 401 trunk(s) can be built between SP1's ASBR or PE router inside AS1 and 402 SP1's PE routers co-locating in SP2's PoPs, as illustrated in the 403 diagram below: 405 <===========Inter-AS MPLS TE Tunnel===========> 406 ----- ----- 407 ________|ASBR |___Inter-AS___|ASBR |________ 408 | | RTR | Link | RTR | | 409 ---- ----- ----- ----- ----- 410 |SP1 |_Inter-AS_| SP2 | | SP1 | 411 |VPoP| Link |P/PE | |P/PE | 412 ---- ----- ----- ----- ----- 413 |________|ASBR |___Inter-AS___|ASBR |________| 414 | RTR | Link | RTR | 415 ----- ----- 416 <=================Inter-AS MPLS TE Tunnel======================> 417 +-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+ 419 In situations where end-to-end Diffserv paths must be maintained, 420 both SP's networks may need to provision Diffserv PHB at each hop 421 supporting a set of traffic classes with compatible performance 422 targets. The subsequent issues regarding Service Level Agreement 423 (SLA) boundaries, reporting and measuring system inter-operability 424 and support demarcations are beyond the scope of this document and 425 will therefore not be discussed here. 427 If either SP1�s or SP2�s network is not a Diffserv-aware network, 428 the scenario would still apply to provide bandwidth guarantees. 430 The SP2, on the other hand, can similarly choose to expand its reach 431 beyond its servicing region over SP1's network via inter-AS MPLS 432 TE paths. 434 It is worth mentioning that these remote aggregation routers 435 co-located in another SP's network are unlikely to host SP1's IGP 436 and BGP routing planes and will more likely maintain their own AS or 437 be part of the SP1's AS. In this case, such TE tunnels may cross 438 several ASes, but the Head-end and Tail-end LSRs of TE tunnel may 439 have the same AS number, as shown in the diagram above. 441 4.1.2. Scenario II - Extended or Virtual Trunk 443 Instead of co-locating a PE router in SP2's PoP, SP1 may also choose 444 to aggregate customer VPN sites onto a SP2's PE router where inter- 445 AS TE tunnels can be built and signaled through SP2's MPLS network 446 between the SP2 PoP (to which SP1�a customer CEs are directly 447 connected) and SP1's ASBR or PE routers inside SP2's network. This 448 allows SP1's customers connected to SP2 PE router to receive a 449 guaranteed bandwidth service up to the TE LSP tail-end router 450 located in SP1's network. 452 In this scenario, there could be two applicable cases: 454 Case 1 - the inter-AS MPLS TE tunnel functions as an extended or 455 virtual trunk aggregating SP1�s CE's local-loop access circuits on 456 SP2's MPLS network over which the bandwidth can be guaranteed to the 457 TE LSP tail-end router located in SP1's network, as shown in the 458 diagram below: 460 <====Inter-AS MPLS TE Tunnel====> 461 or 462 < ===Inter-AS MPLS TE Tunnel===============> 464 ---- ----- ----- ----- ----- 465 | CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | 466 | | Loop | PE | | RTR | Link | RTR | |PE | 467 ---- ----- ----- ----- ----- 469 +SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+ 471 Case 2 - the inter-AS MPLS TE tunnel in this case functions as an 472 extended or virtual local access link from SP1's CE on SP2's network 473 to the SP1's ASBR or PE: 475 <==============Inter-AS MPLS TE Tunnel==============> 476 or 477 <==============Inter-AS MPLS TE Tunnel========================> 479 ---- ----- ----- ----- ----- 480 | CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | 481 | | Loop | PE | | RTR | Link | RTR | |PE | 482 ---- ----- ----- ----- ----- 484 +SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+ 485 In case 2 above, SP2 may elect to establish an aggregating or 486 hierarchical intra-AS MPLS TE tunnel between the transiting P or PE 487 router and SP2's ASBR router just to reduce the number of tunnel 488 states signaled from the SP2 PE to where SP1's CEs are connected. 490 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE 492 In this scenario as illustrated below, customers require the 493 establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across 494 several SPs� networks. One application example would be the 495 guaranteed bandwidth for voice- or video-over-IP services. 497 <======================Inter-AS MPLS TE Tunnel==================> 499 --- ----- ----- ----- ----- --- 500 |CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2| 501 | | | PE | | RTR | Link | RTR | | PE | | | 502 --- ----- ----- ----- ----- --- 504 +Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+ 506 The diagram below illustrates another example where CE1 and CE2 are 507 customers of SP1 with extenal BGP (eBGP) peering relationships 508 established across the CE-PE links. An inter-AS MPLS TE tunnel may 509 then be established from CE1 in ASx to CE2 which may belong to the 510 same AS or a different AS than that of CE1 across SP1's network in 511 AS2. 513 <===============Inter-AS MPLS TE Tunnel=====================> 515 --- ----- ---- ---- ----- --- 516 |CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2| 517 | | | PE1 | |P1 | |P2 | | PE2 | | | 518 --- ----- ---- ---- ----- --- 520 +-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+ 522 The above example shows that SP1's network has a single AS. 523 Obviously, there may be multiple ASes between CE1 and CE2 as well as 524 in the SP1's network. 526 In addition, where both CE1 and CE2 reside in the same AS, they will 527 likely share the same private AS number. 529 Scenario III however, will not scale well if there is a greater 530 number of inter-AS TE MPLS tunnels in some degrees of partial mesh 531 or full mesh. Therefore, it is expected that this scenario will 532 have few deployments, unless some mechanisms such as hierarchical 533 intra-AS TE-LSPs are used to reduce the number of signaling states. 535 4.2. Application Scenarios Requiring Inter-AS Resource Optimization 537 The scenarios presented in this section mainly deal with inter-AS 538 resource optimization. 540 4.2.1. Scenario IV - TE across multi-AS within a Single SP 541 Administrative Domain 543 As mentioned in [TE-APP], SPs have generally admitted that the 544 current MPLS TE mechanism provides a great deal of tactical and 545 strategic value in areas of traffic path optimization [TE-RSVP] and 546 rapid local repair capabilities [TE-FRR] via a set of on-line or 547 off-line constraint-based searching algorithms. 549 From a service provider's perspective, another way of stating the 550 objectives of traffic engineering is to utilize available capacity 551 in the network for delivering customer traffic without violating 552 performance targets, and/ or to provide better QOS services via an 553 improved network utilization, operating more likely below congestion 554 thresholds. 556 It is worth noting that situations where resource provisioning is 557 not an issue, e.g. low density in inter-AS connectivity or ample 558 inter-AS capacity, it may not require more scalable and granular TE 559 facilities beyond BGP routing policies since such policies can be 560 rather simple and because inter-AS resource optimization is not an 561 absolute requirement. 563 However many SPs, especially those with networks across multiple 564 Continents, as well as those with sparsely connected networks, have 565 designed their multi-AS routing policies along or within the 566 continental or sub-continental boundaries where the number of ASes 567 can range from a very few to dozens. Generally, inter-continent or 568 sub-continent capacity is very expensive. Some Service Providers 569 have multiple ASes in the same country and would like to optimize 570 resources over their inter-region links. This would demand a 571 more scalable degree of resource optimization, which warrants the 572 consideration of extending current intra-AS MPLS TE capabilities 573 across inter-AS links. 575 In addition, one may only realize higher efficiency in conducting 576 traffic optimization and path protection/ restoration planning when 577 coordinating all network resources (not partially) as a whole. For 578 a network which may consist of many ASes, this could be realized via 579 the establishment of inter-AS TE LSPs as shown in the diagragm 580 below: 582 <===================Inter-AS MPLS Tunnel=============> 583 -------- -------- -------- 584 | |_______________| |____________| | 585 | SP1 |_______________| SP1 |____________| SP1 | 586 | AS1 |_______________| AS2 |____________| AS3 | 587 | | | | | | 588 -------- -------- -------- 589 || || 590 || --------- || 591 ||___________________| SP1 |________________|| 592 |____________________| AS4 |_________________| 593 | | 594 --------- 595 The motivation for inter-AS MPLS TE is even more prominent in a 596 Diffserv-enabled network over which statistical performance targets 597 are to be maintained from any point to any point of the network as 598 illustrated in the diagram below with an inter-AS DS-TE LSP: 600 <===================Inter-AS MPLS DS-TE Tunnel=============> 601 ---- ----- ----- ----- ----- ---- 602 | PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE | 603 | RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR | 604 ---- ----- ----- ----- ----- ---- 605 +------------SP1 AS1---------+ +------------SP1 AS2------+ 607 For example , the inter-AS MPLS DS-TE LSP shown in the diagram above 608 could be used to transport a set of L2 Pseudo Wires or VoIP traffic 609 with corresponding QoS requirement. 611 Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR 612 node failure is a strong requirement for such services. 614 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport 616 Scenario V presents another possible deployment case. SP1 with AS1 617 wants to link a regional network to its core backbone by building an 618 inter-AS MPLS TE tunnel over one or multiple transit ASes belonging 619 to SP2, SP3, etc. as shown in the following diagram: 621 <===========Inter-AS MPLS TE Tunnel=======> 622 [ ] [ ] [ ] 623 [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] 624 [ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|] 625 [ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |] 626 [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] 627 [ ] [ ] [ ] 628 <================Inter-AS MPLS TE Tunnel=====================> 629 +SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+ 631 This scenario can be viewed as a broader case of Scenario I shown in 632 section 4.1.1 where the "VPoP" could be expanded into a regional 633 network of SP1. By the same token, the AS number for SP1's regional 634 network ASx may be the same as or different from AS1. 636 The inter-AS MPLS TE LSP in this case may also be used to backup an 637 internal path as depicted in the diagram below, although this could 638 introduce routing complexities: 640 <===========Inter-AS MPLS TE Tunnel=======> 641 +----------------------------SP1 AS1-----------------------------+ 642 [ ] 643 [ ---- ---- ---- ---- ] 644 [ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |] 645 [ |RTR | |RTR | Link |RTR | |RTR |] 646 [ ---- ---- ---- ---- ] 647 [ | | ] 648 [ ---- ---- ] 649 [ |ASBR| |ASBR| ] 650 [ |RTR | |RTR | ] 651 [ ---- ---- ] 652 ^ | | ^ 653 | | | | 654 | | [ ] | | 655 | | [ ---- ---- ] | | 656 | |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| | 657 | Link [|RTR | |RTR |] Link | 658 | [ ---- ---- ] | 659 | [ ] | 660 | | 661 +======Backup Inter-AS MPLS TE Tunnel======+ 662 +Transit SP2 AS2,SP3 AS3,etc....SPi ASi+ 664 5. Detailed Requirements for Inter-AS MPLS Traffic Engineering 666 This section discusses detailed requirements for inter-AS MPLS TE in 667 two principal areas: 1) requirements for inter-AS MPLS TE in the 668 same SP administrative domain and 2) requirements for inter-AS MPLS 669 TE across different SP administrative domains. 671 5.1. Requirements within one SP Administrative Domain 673 This section presents detailed requirements for inter-AS MPLS TE 674 within the same SP administrative domain. 676 5.1.1. Inter-AS MPLS TE Operations and Interoperability 678 The inter-AS MPLS TE solution SHOULD be consistent with requirements 679 discussed in [TE-REQ] and the derived solution MUST be such that 680 it will interoperate seamlessly with current intra-AS MPLS TE 681 mechanism and inherit its capability sets from [TE-RSVP]. 683 The proposed solution SHOULD allow the provisioning of a TE LSP at 684 the Head/Tail end with end-to-end Resource Reservation Protocol 685 (RSVP) signaling (eventually with loose paths) traversing across the 686 interconnected ASBRs, without further provisioning required along 687 the transit path. 689 5.1.2. Protocol Signaling and Path Computations 691 One can conceive that an inter-AS MPLS TE tunnel path signaled 692 across inter-AS links consists of a sequence of intra-AS segments. 694 The proposed solution SHOULD provide the ability to either 695 explicitly select or auto-discover the following elements when 696 signaling the inter-AS TE LSP path: 698 - a set of AS numbers as loose HoPs and/or 699 - a set of LSRs including ASBRs 701 It should also specify the above elements in the Explicit Route 702 Object (ERO) and record them in the Record Route Object (RRO) of the 703 Resv message just to keep track of the set of ASes or ASBRs 704 traversed by the inter-As TE LSP. 706 In the case of establishing inter-AS TE LSP traversing multiple ASes 707 within the same SP networks, the solution SHOULD also allow the 708 Head-end LSR to explicitly specify the hops across any one of 709 the transiting ASes and the TE tunnel Head-end SHOULD also check 710 the explicit segment to make sure that the constraints are met. 712 In addition, the proposed solution SHOULD provide the ability 713 to specify and signal that certain loose or explicit nodes (e.g. AS 714 numbers, etc.) and resources are to be explicitly excluded in the 715 inter-AS TE LSP path establishment, such as one defined in 716 [EXCLUDE-ROUTE] for instance. 718 5.1.3 Optimality 720 The solution SHOULD allow the set-up of an inter-AS TE LSP that 721 complies with a set of TE constraints defined in [TE-REQ]) and 722 follows an optimal path. 724 An optimal path is defined as a path whose end-to-end cost is 725 minimal, based upon either an IGP or a TE metric. Note that in 726 the case of an inter-AS path across several ASes having completely 727 different IGP metric policies, the notion of minimal path might 728 require IGP metric normalization. 730 The solution SHOULD provide mechanism(s) to compute and establish an 731 optimal end-to-end path for the inter-AS TE LSP and SHOULD also 732 allow for reduced optimality (or sub-optimality) since the path may 733 not remain optimal for the life-time of the LSP 735 5.1.4 Support of diversely routed inter-AS TE LSP 737 In some cases it might be desirable to set up multiple inter-AS TE 738 LSPs between a pair of LSRs when: 740 (1) a single TE LSP satisfying the required set of constraints 741 cannot be found, in which case it may require load splitting; 743 (2) multiple TE paths may be required to limit the impact of a 744 network element failure to a portion of the traffic (as an 745 example, two VoIP gateways may load balance the traffic among 746 a set of inter-AS TE LSPs); 748 (3) path protection (e.g. 1:1 or 1:N) as discussed in 749 [MPLS-Recov]. 751 In the examples above, being able to set up diversely routed TE LSPs 752 becomes a requirement for inter-AS TE. 754 The solution SHOULD be able to set up a set of link/SRLG/Node 755 diversely routed inter-AS TE LSPs. 757 5.1.5. Re-optimization 759 Once an inter-AS TE LSP has been established, and should there be 760 any resource or other changes inside anyone of the ASes, the 761 solution MUST be able to re-optimize the LSP accordingly and 762 non-disruptively, either upon expiration of a configurable timer or 763 triggered by a network event or a manual request at the TE tunnel 764 Head-End. 766 The solution SHOULD provide an option for the Head-End LSRs to 767 control if re-optimizing or not should there exist a more optimal 768 path in one of the ASes. 770 In the case of an identical set of traversed path, the solution 771 SHOULD provide an option for the Head-End LSRs to control if 772 re-optimizing or not should there exist a more optimal path in one 773 of the transit ASes along the inter-AS TE LSP path. 775 Furthermore, the solution MUST provide the ability to reject 776 re-optimization at AS boundaries. 778 5.1.6. Fast Recovery support using MPLS TE Fast Reroute 780 There are in general two or more inter-AS links between multiple 781 pair of ASBRs for redundancy. The topological density between ASes 782 in a SP network with multi-ASes is generally much higher. In the 783 event of an inter-AS link failure, rapid local protection SHOULD 784 also be made available and interoperate with current intra-AS MPLS 785 TE fast re-route mechanism from [TE-FRR]. 787 The traffic routed onto an inter-AS TE tunnel SHOULD also be fast 788 protected against any node failure where the node could be internal 789 to an AS or at the AS boundary. 791 5.1.7. DS-TE Support 793 The proposed inter-AS MPLS TE solution SHOULD satisfy core 794 requirements documented in [DS-TE] and interoperate seamlessly with 795 the current intra-AS MPLS DS-TE mechanism [DSTE-PROT]. 797 It is worth pointing out that the compatibility clause in section 798 4.1 of [DS-TE] SHOULD also be faithfully applied to the solution 799 development 801 5.1.8. Scalability and Hierarchical LSP Support 803 The proposed solution(s) MUST have a minimum impact on network 804 scalability from both intra and inter-AS perspectives. 806 This requirement applies to all of the following: 808 - IGP (impact in terms of IGP flooding, Path computation, etc.) 809 - BGP (impact in terms of additional information carried within 810 BGP, number of routes, flaps, overload events, etc.) 811 - RSVP TE (message rate, number of retained states, ,etc.) 813 It is also conceivable that there would potentially be scalability 814 issues as the number of required inter-AS MPLS TE tunnels increases. 815 In order to reduce the number of tunnel states to be maintained by 816 each transiting PoP, the proposed solution SHOULD allow TE LSP 817 aggregation such that individual tunnels can be carried onto one or 818 more aggregating LSP(s). One such mechanism, for example is 819 described in [MPLS-LSPHIE]. 821 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels 823 There SHOULD be several possibilities to map particular traffic 824 to a particular destination onto a specific inter-AS TE LSP. 826 For example, static routing could be used if IP destination 827 addresses are known. Another example is to utilize static routing 828 using recursive BGP route resolution. 830 The proposed solution SHOULD also provide the ability to "announce" 831 the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) 832 with the link's cost associated with it. By doing so, PE routers 833 that do not participate in the inter-AS TE path computation can take 834 into account such links in its IGP-based SPF computation. 836 5.1.10. Inter-AS MPLS TE Management 838 5.1.10.1. Inter-AS MPLS TE MIB Requirements 840 An inter-AS TE Management Information Base (MIB) is required for use 841 with network management protocols by SPs to manage and configure 842 inter-AS traffic engineering tunnels. This new MIB SHOULD extend 843 (and not reinvent) the existing MIBs to accommodate this new 844 functionality. 846 An inter-AS TE MIB should have features that include: 847 - The setup of inter-AS TE tunnels with associated constraints 848 (e.g. resources) 849 - The collection of traffic and performance statistics not only 850 at the tunnel headend, but any other points of the TE tunnel. 851 - The inclusion of both IPv4/v6 + AS# or AS# subobjects in the 852 ERO in the path message, e.g: 854 EXPLICIT_ROUTE class object: 855 address1 (loose IPv4 Prefix, /AS1) 856 address2 (loose IPv4 Prefix, /AS1) 857 AS2 (AS number) 858 address3 (loose IPv4 prefix, /AS3) 859 address4 (loose IPv4 prefix, /AS3) - destination 861 or 863 address1 (loose IPv4 Prefix, /AS1) 864 address2 (loose IPv4 Prefix, /AS1) 865 address3 (loose IPv4 Prefix, /AS2) 866 address4 (loose IPv4 Prefix, /AS2) 867 address5 (loose IPv4 prefix, /AS3) 868 address6 (loose IPv4 prefix, /AS3) - destination 870 - Similarly, the inclusion of the RRO object in the resv message 871 recording sub-objects such as interface IPv4/v6 address (if not 872 hidden), AS number, a label, a node-id (when required), etc. 873 - Inter-AS specific attributes as discussed in section 5 of this 874 document including, for example inter-AS MPLS TE tunnel 875 accounting records across each AS segment 877 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements 879 In a MPLS network, a SP wants to detect both control plane and data 880 plane failures. But tools for fault detection over LSPs haven't 881 been widely developed so far. SPs today manually troubleshoot such 882 failures in a hop-by-hop fashion across the data path. If they 883 detect an error on the data plane, they have to check the control 884 plane in order to determine where the faults come from. 886 The proposed solution SHOULD be able to interoperate with fault 887 detection mechanisms of intra-AS TE and MAY or MAY NOT require the 888 inter-AS TE tunnel ending addresses to be known or routable across 889 IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with 890 working return paths. 892 For example, [LSPPING] is being considered as a failure detection 893 mechanism over the data plane against the control plane and could 894 be used to troubleshoot intra-AS TE LSPs. Such facilities, if 895 adopted, SHOULD then be extended to inter-AS TE paths. 897 However, the above example depicts one such mechanism that does 898 require a working return path such that diagnostic test packets can 899 return via an alternate data plane, such as a global IPv4 path in 900 the event that the LSP is broken. 902 [MPLS-TTL] presents how TTL may be processed across a hierarchical 903 MPLS networks and such a facility as this SHOULD also be extended 904 to inter-AS TE links. 906 5.1.11. Extensibility 908 The solution(s) MUST allow extensions as both inter-AS MPLS TE and 909 current intra-AS MPLS TE specifications evolve. 911 5.1.12. Complexity and Risks 913 The proposed solution(s) SHOULD NOT introduce unnecessary complexity 914 to the current operating network to such a degree that it would 915 affect the stability and diminish the benefits of deploying such a 916 solution over SP networks. 918 5.1.13. Backward Compatibility 920 The deployment of inter-AS MPLS TE SHOULD NOT impact on 921 existing BGP-based traffic engineering or MPLS TE mechanisms, but 922 allow for a smooth migration or co-existence. 924 5.1.14. Performance 926 The solution SHOULD be evaluated taking into account various 927 performance criteria: 929 - Degree of path optimality of the inter-AS TE LSP path 930 - TE LSP setup time 931 - Failure and restoration time 932 - Impact and scalability of the control plane due to added 933 overheads, etc. 934 - Impact and scalability of the data/forwarding plane due to 935 added overheads, etc. 937 5.2. Requirements for Inter-AS MPLS TE across Multiple SP 938 Administrative Domains 940 The requirements for inter-AS MPLS TE across multiple SP admin 941 domains SHOULD include all requirements discussed in section 5.1 942 above in addition to those that are presented in this section here. 944 Please note that the SP with multi-AS networks may choose not to 945 turn on the features discussed in the following two sections when 946 building TE tunnels across ASes in its own domain. 948 5.2.1. Confidentiality 950 Since an inter-AS TE LSP may span multiple ASes belonging to 951 different SPs, the solution MIGHT allow hiding the set of 952 hops used by the TE LSP within an AS as illustrated in the following 953 example: 955 [ ASBR1-----ASBR2 ] 956 [ ] [ ] 957 [ A ] [ B ] 958 [ AS1 ] [ AS2 ] 959 [ SP1 ]-----[ SP2 ] 960 [ ] [ ] 962 Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B 963 (within AS2 of SP2). When computing an inter-AS TE LSP path, the 964 set of hops within AS2 might be hidden to AS1. In this case, the 965 solution will allow A to learn that the more optimal TE LSP path to 966 B that complies with the set of constraints traverses ASBR2 without 967 a detailed knowledge of the lists of hops used within AS2. 969 Optionally, the TE LSP path cost within AS2 could be provided to A, 970 via for example PCC-PCS signaling [PATH-COMP], such that A (PCC) 971 could use this information to compute an optimal path, even if the 972 computed path is not provided by AS2. 974 In addition, the management requirements discussed in section 5.1.10 975 above, when used across different SP admin domains, SHOULD include 976 similar confidentiality requirements discussed here in terms of 977 "hiding" intermediate hops or interface address and/or labels in 978 the transiting or peering SPs. 980 5.2.2. Policy Control 982 In some cases, policy control might be necessary at the AS 983 boundaries, namely ingress policy controls enabling SPs to enforce 984 the inter-AS policies per interconnect agreements or modify some 985 requested parameters conveyed by incoming inter-AS MPLS TE signaling 986 requests. 988 It is worth noting that such a policy control mechanism may also be 989 used between ASes within a SP. 991 This section only discusses the elements that may be used to form a 992 set of ingress control policies but exactly how SPs establish 993 bilateral or multilateral agreements upon which the control policies 994 can be built are beyond the scope of this document. 996 5.2.2.1. Inter-AS TE Agreement Enforcement Polices 998 The following provides a set of TE-LSP parameters in the inter-AS TE 999 Requests (RSVP Path Message) that could be enforced at the AS 1000 boundaries: 1002 - RSVP-TE session attributes: affinities and preemption 1003 priorities 1004 - Per AS or SP bandwidth admission control to ensure that RSVP-TE 1005 messages do not request for bandwidth resources over their 1006 allocation 1007 - Request origins which can be represented by Head-End tunnel 1008 ending IP address, originating AS#, neighbor AS#, neighbor ASBR 1009 interface IP address, etc. 1010 - DS-TE TE-Class 1011 - FRR attribute: local protection desired bit, node protection 1012 desired bit and bandwidth protection desired bit carried in the 1013 SESSION 1014 - ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message 1015 as defined in [TE-FRR] 1016 - Optimization allowed or not allowed 1018 In some cases, a TE policy server could also be used for the 1019 enforcement of inter-AS TE policies. Implementations SHOULD allow 1020 the use of a policy enforcement server. This requirement could 1021 allow SPs to make the inter-AS TE policies scale better. 1023 The signaling of a non policy compliant request SHOULD trigger the 1024 generation of a RSVP Path Error message by the policy enforcing 1025 node towards the Head-end LSR, indicating the cause. The 1026 Head-end LSR SHOULD take appropriate actions, such as re-route, upon 1027 receipt of such a message. 1029 5.2.2.2. Inter-AS TE Rewrite Policies 1031 In some situations, SPs may need to rewrite some attributes of the 1032 incoming inter-AS TE signaling requests due to a lack of resources 1033 for a particular TE-Class, non-compliant preemption, or upon mutual 1034 agreements. The following lists parameters that can potentially be 1035 rewritten at the AS boundaries: 1037 - RSVP-TE session attributes: affinities and preemption 1038 priorities 1039 - DS-TE TE-Class 1040 - ERO expansion requests 1042 Similarly, the re-writing node SHOULD generate a RSVP Path Error 1043 Message towards the Head-end LSR indicating the cause in terms 1044 of types of changes made so as to maintain the end-to-end integrity 1045 of inter-AS TE LSP. 1047 5.2.2.3 Inter-AS Traffic Policing 1049 The proposed solution SHOULD also provide a set of policing 1050 mechanisms which could be configured on the inter-AS links 1051 to ensure that traffic routed through the tunnel does not exceed 1052 the bandwidth negotiated during LSP signaling. 1054 For example, an ingress policer could be configured to enforce 1055 the traffic contract on the mutually agreed resource requirements 1056 of the established inter-AS TE LSP (i.e. RSVP bandwidth) on the 1057 interface to which the inter-AS link is connected. 1059 6. Security Considerations 1061 The proposed solution(s) MUST address security issues across 1062 multiple SP administrative domains. Although inter-AS MPLS TE is 1063 not expected to add specific security extensions beyond those of 1064 current intra-AS TE, greater considerations MUST be given in terms 1065 of how to establish a trusted model across AS boundaries. SPs 1066 SHOULD have a means to authenticate (such as using RSVP INTEGRITY 1067 Object), allow and possibly denying inter-AS signaling requests 1068 and SHOULD be protected from DoS attacks. 1070 7. Acknowledgement 1072 We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik 1073 Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, 1074 Ed Kern, Jim Boyle, Thomas Nadeauor and Yakov Rekhter for their 1075 suggestions and helpful comments during the discussions of this 1076 draft. 1078 8. Editor's Addresses 1080 Raymond Zhang 1081 Infonet Services Corporation 1082 2160 E. Grand Ave. 1083 El Segundo, CA 90025 1084 USA 1085 Email: raymond_zhang@infonet.com 1087 JP Vasseur 1088 CISCO Systems, Inc. 1089 300 Beaver Brook Road 1090 Boxborough , MA - 01719 1091 USA 1092 Email: jpv@cisco.com 1094 9. Normative References 1096 [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering 1097 over MPLS", RFC2702, September 1999. 1099 [TE-RSVP], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP 1100 Tunnels", RFC 3209, December 2001 1102 [RFC-2119], S. Bradner, "Key words for use in RFCs to Indicate 1103 Requirement Levels", RFC 2119, March 1997 1105 10. Informative References 1107 [MPLS-ARCH], Rosen, et. al., "Multiprotocol Label Switching 1108 Architecture", RFC 3031, January 2001 1110 [BGP-MPLSVPN], Rosen, et. al., "BGP/MPLSVPN", draft-ietf-l3vpn 1111 -rfc2547bis-01.txt, September 2003 (work in progress). 1113 [DIFF_ARCH], Blake, et. al., "An Architecture for Differentiated 1114 Services", RFC 2475, December 1998. 1116 [DIFF_AF], Heinanen,et. al., "Assured Forwarding PHB Group", RFC 1117 2597, June 1999. 1119 [DIFF_EF], Davie, et. al., "An Expedited Forwarding PHB (Per-Hop 1120 Behavior)", RFC 3246, March 2002. 1122 [MPLS-Diff], Le Faucheur, et. al., "MPLS Support of Differentiated 1123 Services", RFC 3270, May 2002 1125 [TE-OVW], Awduche, et. al., "Overview and Principles of Internet 1126 Traffic Engineering", RFC 3272,May 2002 1128 [PSTE], Li, et. al., "A Provider Architecture for Differentiated 1129 Services and Traffic Engineering", RFC 2430, October 1998 1131 [TE-APP], Boyle, et. al., "Applicability Statement of Traffic 1132 Engineering", RFC 3346, August 2002. 1134 [TE-SURVIV], Lai, et. al., "Network Hierachy and Multilayer 1135 Suvivability", RFC 3386, November, 2002. 1137 [GMPLS-ROUT], Kompella, et. al., "Generalized Multi-Protocol Label 1138 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1139 Engineering (RSVP-TE) Extensions, RFC 3473, January 2003. 1141 [BGP], Rekhter, et. al., "A Border Gateway Protocol 4 (BGP-4)", 1142 RFC 1771, March 1995 1144 [LSPPING], Kompella, et.. al.," Detecting Data Plane Liveliness in 1145 MPLS", Internet Draft , 1146 August 2004, (Work in Progress) 1148 [MPLS-TTL], Agarwal, et. al., "Time to Live (TTL) Processing in MPLS 1149 Networks", RFC 3443, January, 2003 1151 [DS-TE], Le Faucheur, et. al., ''Requirements for support of 1152 DiffServ-aware MPLS Traffic Engineering'', RFC 3564, July, 2003 1154 [DSTE-PROT], Le Faucheur, et. al., "Protocol extensions for support 1155 of Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff 1156 -te-proto-04.txt, September 2004 (Work in Progress). 1158 [TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE", 1159 draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt, November 2003 1160 (Work in Progress). 1162 [ISIS-TE], Smit, Li, "IS-IS extensions for Traffic Engineering", 1163 draft-ietf-isis-traffic-05.txt, August, 2003 (Work in Progress). 1165 [OSPF-TE] Katz, Yeung, "Traffic Engineering (TE) Extensions to 1166 OSPF Version 2", RFC 2370, September 2003. 1168 [PATH-COMP], Vasseur, et. al., ''RSVP Path computation request and 1169 reply messages'', draft-vasseur-mpls-computation-rsvp-03.txt, June 1170 2002. (Work in Progress) 1172 [OSPF-TE-CAP], Vasseur, Psenak. "OSPF TE TLV capabilities", 1173 draft-vasseur-mpls-ospf-te-cap-00.txt, October 2002. 1174 (Work in Progress) 1176 [MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierarchy with Generalized 1177 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , September 2002. 1178 (work in progress) 1180 [MPLS-Recov], Sharma V., et al, "Framework for Multi-Protocol Label 1181 Switching (MPLS)-based Recovery", RFC 3469, Feb, 2003 1183 [BGP-Label], Rekhter and Rosen, "Carrying Label Information in 1184 BGP-4", RFC 3107, May 2001 1186 [INTER-AS-TE], Vasseur and Ayyangar, "Inter-AS MPLS Traffic 1187 Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt, 1188 August, 2004 (work in progress). 1190 [EXCLUDE-ROUTE], Farrel, et. al., "draft-ietf-ccamp-rsvp-te-exclude 1191 -route-01.txt", June 2004 (work in progress). 1193 11. Full Copyright Statement 1195 Copyright (C) The Internet Society (2003). All Rights Reserved. 1197 This document and translations of it may be copied and furnished to 1198 others, and derivative works that comment on or otherwise explain it 1199 or assist in its implementation may be prepared, copied, published 1200 and distributed, in whole or in part, without restriction of any 1201 kind, provided that the above copyright notice and this paragraph 1202 are included on all such copies and derivative works. However, this 1203 document itself may not be modified in any way, such as by removing 1204 the copyright notice or references to the Internet Society or other 1205 Internet organizations, except as needed for the purpose of 1206 developing Internet standards in which case the procedures for 1207 copyrights defined in the Internet Standards process MUST be 1208 followed, or as required to translate it into languages other than 1209 English. 1211 The limited permissions granted above are perpetual and will not be 1212 revoked by the Internet Society or its successors or assigns. 1214 This document and the information contained herein is provided on an 1215 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1216 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1217 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1218 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1219 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1221 Appendix A. Brief Description of BGP based Inter-AS Traffic 1222 Engineering 1224 In today's Service Provider (SP) network, BGP is deployed to meet 1225 two different sets of requirements: 1227 - Establishing a scalable exterior routing plane separate from 1228 The data forwarding plane within SP's administrative domain 1229 - Exchanging network reachability information with different BGP 1230 autonomous systems (ASs) that could belong to a different SP 1231 or simply, a different AS within a SP network 1233 Over connections across the AS boundaries, traffic engineering may 1234 also be accomplished via a set of BGP capabilities by appropriately 1235 enforcing BGP-based inter-AS routing policies. The current 1236 BGP-based inter-AS traffic engineering practices may be summarized 1237 as follows: 1239 - "Closest exit" routing where egress traffic from one SP to 1240 another follows the path defined by the lowest IGP or intra-AS 1241 MPLS TE tunnel metrics of the BGP next-HOP of exterior routes 1242 learned from other AS over the inter-AS links 1243 - "BGP path attribute" based routing selection mechanism where 1244 the egress traffic path is determined by interconnect (peering 1245 or transit) policies based upon one or a combination of BGP 1246 path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and 1247 Local_Pref. 1249 SPs have often faced a number of un-deterministic factors in the 1250 practices of inter-AS traffic engineering employing the methods 1251 mentioned above: 1253 - Sub-optimum traffic distribution across inter-AS links 1254 - Un-deterministic traffic condition changes due to uncoordinated 1255 IGP routing policies or topology changes within other AS and 1256 uncoordinated BGP routing policy changes (MED or as-prepend, 1257 etc.) 1259 In addition, to achieve some degrees of granularity, SPs may choose 1260 to enforce BGP inter-AS policies that are specific to one or a set 1261 of inter-AS links for ingress traffic destined to certain PoPs or 1262 regions within SP's network from another AS by tagging certain sets 1263 of routes with a specific attribute when announcing to another AS. 1264 This of course goes under the assumption that the other AS permits 1265 automated egress policy by matching the predefined attribute from 1266 incoming routes.