idnits 2.17.1 draft-ietf-tewg-interas-mpls-te-req-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1289. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 == There is 1 instance 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 12) being 61 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 (September 2004) is 7162 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 1194, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 1220, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE-CAP' is defined on line 1230, but no explicit reference was found in the text == Unused Reference: 'BGP-Label' is defined on line 1241, but no explicit reference was found in the text == Unused Reference: 'INTER-AS-TE' is defined on line 1244, 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) == 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: 8 errors (**), 0 flaws (~~), 14 warnings (==), 13 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-09.txt JP Vasseur, Co-Editor 4 Expires: March. 2005 CISCO Systems,Inc 5 September 2004 7 MPLS Inter-AS Traffic Engineering requirements 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This document discusses requirements for the support of inter-AS 42 MPLS Traffic Engineering (MPLS TE). Its main objective is to 43 present a set of requirements and scenarios which would result in 44 general guidelines for the definition, selection and specification 45 development for any technical solution(s) meeting these requirements 46 and supporting the scenarios. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in [RFC-2119]. 54 MPLS Inter-AS TE requirements............... September 2004 56 Table of Contents 58 1. Introduction.......................................................3 59 2. Contributing Authors...............................................4 60 3. Definitions and Requirements Statement.............................5 61 3.1. Definitions......................................................5 62 3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6 63 3.2.1. Inter-AS Bandwidth Guarantees..................................6 64 3.2.2. Inter-AS Resource Optimization.................................7 65 3.2.3. Fast Recovery across ASes......................................8 66 3.3. Inter-AS Traffic Engineering Requirements Statement..............8 67 4. Application Scenarios..............................................8 68 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees....9 69 4.1.1. Scenario I - Extended or Virtual PoP...........................9 70 4.1.2. Scenario II - Extended or Virtual Trunk.......................10 71 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE......11 72 4.2. Application Scenarios Requiring Inter-AS Resource Optimization..12 73 4.2.1. Scenario IV - TE across multi-AS within a Single SP 74 Administrative Domain.........................................12 75 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13 76 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14 77 5.1. Requirements within one SP Administrative Domain................14 78 5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14 79 5.1.2. Protocol Signaling and Path Computations......................15 80 5.1.3. Optimality....................................................15 81 5.1.4. Support of diversely routed inter-AS TE LSP...................15 82 5.1.5. Re-optimization...............................................16 83 5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16 84 5.1.7. DS-TE Support.................................................17 85 5.1.8. Scalability and Hierarchical LSP Support......................17 86 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels..............17 87 5.1.10. Inter-AS MPLS TE Management..................................18 88 5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................18 89 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18 90 5.1.11. Extensibility................................................19 91 5.1.12. Complexity and Risks.........................................19 92 5.1.13. Backward Compatibility.......................................19 93 5.1.14. Performance..................................................19 94 5.2. Requirements for Inter-AS MPLS TE across Multiple SP 95 Administrative Domains..........................................20 96 5.2.1. Confidentiality...............................................20 97 5.2.2. Policy Control................................................20 98 5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................21 99 5.2.2.2. Inter-AS TE Rewrite Policies................................21 100 5.2.2.3 Inter-AS Traffic Policing....................................22 101 6. Security Considerations...........................................22 102 7. Acknowledgements..................................................22 103 8. Editor's Addresses................................................22 104 9. Normative References............................................. 23 105 10. Informative References...........................................23 107 MPLS Inter-AS TE requirements September 2004 109 11. Full Copyright Statement.........................................25 110 12. Intellectual Property............................................25 111 13. Acknowledgement..................................................25 112 Appendix A. Brief Description of BGP based Inter-AS Traffic 113 Engineering..............................................26 115 1. Introduction 117 The MPLS Traffic Engineering (TE) mechanism documented in [TE-RSVP] 118 may be deployed by Service Providers (SPs) to achieve some of the 119 most important objectives of network traffic engineering as 120 described in [TE-OVW]. These objectives are summarized as: 122 - Supporting end-to-end services requiring QoS guarantees 123 - Performing network resource optimization 124 - Providing fast recovery 126 However, this traffic engineering mechanism can only be used within 127 an Autonomous System (AS). 129 This document discusses requirements for an inter-AS MPLS Traffic 130 Engineering mechanism that may be used to achieve the same set of 131 objectives across AS boundaries within or beyond a SP's 132 aministrative domains. 134 The document will also present a set of application scenarios where 135 the inter-AS traffic engineering mechanism may be required. This 136 mechanism could be implemented based upon the requirements presented 137 in this document. 139 These application scenarios will also facilitate discussions for a 140 detailed requirements list for this inter-AS Traffic Engineering 141 mechanism. 143 Please note that there are other means of traffic engineering 144 including Interior Gateway Protocol (IGP); metrics based (for use 145 within an AS); and Border Gateway Protocol (BGP) attribute based 146 (for use across ASes, as described in Appendix A), which provide 147 coarser control of traffic paths. However, this document addresses 148 requirements for a MPLS based, fine-grained approach for inter-AS 149 TE. 151 This document doesn't make any claims with respect to whether it is 152 possible to have a practical solution that meets all the 153 requirements listed in this document. 155 MPLS Inter-AS TE requirements.............. September 2004 157 2. Contributing Authors 159 The text and content of this document was contributed to by the 160 co-authors listed below (The contact information for the editors 161 appears in section 9, and is not repeated below.): 163 Kenji Kumaki 164 KDDI Corporation 165 Garden Air Tower 166 Iidabashi, Chiyoda-ku, 167 Tokyo 102-8460, JAPAN 168 E-mail : ke-kumaki@kddi.com 170 Paul Mabey 171 Qwest Communications 172 950 17th Street, 173 Denver, CO 80202, USA 174 Email: pmabey@qwest.com 176 Nadim Constantine 177 Infonet Services Corporation 178 2160 E. Grand Ave. 179 El Segundo, CA 90025. USA 180 Email: nadim_constantine@infonet.com 182 Pierre Merckx 183 EQUANT 184 1041 route des Dolines - BP 347 185 06906 SOPHIA ANTIPOLIS Cedex, FRANCE 186 Email: pierre.merckx@equant.com 188 Ting Wo Chung 189 Bell Canada 190 181 Bay Street, Suite 350 191 Toronto, Ontario, Canada, M5J 2T3 192 Email: ting_wo.chung@bell.ca 194 Jean-Louis Le Roux 195 France Telecom 196 2, avenue Pierre-Marzin 197 22307 Lannion Cedex, France 198 E-mail: jeanlouis.leroux@francetelecom.com 200 Yonghwan Kim 201 SBC Laboratories, Inc. 202 4698 Willow Road 203 Pleasanton, CA 94588, USA 204 Email: Yonghwan_Kim@labs.sbc.com 206 MPLS Inter-AS TE requirements.............. September 2004 208 3. Definitions and Requirements Statement 210 3.1. Definitions 212 The following provides a list of abbreviations or acronyms 213 specifically pertaining to this document: 215 SP: Service Providers including regional or global providers 217 SP Administrative Domain: a single SP administration over a network 218 or networks that may consist of one AS or 219 multiple ASes. 221 IP-only networks: SP's network where IP routing protocols such as 222 IGP/ BGP are activated 224 IP/MPLS networks: SP's network where MPLS switching capabilities and 225 signaling controls (e.g. ones described in 226 [MPLS-ARCH]) are activated in addition to IP 227 routing protocols. 229 Intra-AS TE: A generic definition for traffic engineering mechanisms 230 operating over IP-only and/ or IP/MPLS network within 231 an AS. 233 Inter-AS TE: A generic definition for traffic engineering mechanisms 234 operating over IP-only and/ or IP/MPLS network across 235 one or multiple ASes. Since this document only 236 addresses IP/MPLS networks, any reference to Inter-AS 237 TE in this document refers only to IP/MPLS networks and 238 is not intended to address IP-only TE requirements. 240 TE LSP: MPLS Traffic Engineering Label Switched Path 242 Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its 243 TE Label Switched Path (LSP), Head-end Label 244 Switching Router (LSR) and Tail-end LSR reside in 245 the same AS for traffic engineering purposes. 247 Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its 248 TE LSPs Head-end LSR and Tail-end LSR do not 249 reside within the same AS or both Head-end LSR and 250 Tail-end LSR are in the same AS but the TE LSP 251 transiting path may be across different ASes 253 ASBR Routers: Border routers used to connect to another AS of a 254 different or the same Service Provider via one or more 255 links inter-connecting between ASes. 257 Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, 258 e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... 259 ASBRn-ASn. 261 MPLS Inter-AS TE requirements.............. September 2004 263 Inter-AS TE Segment: A portion of the Inter-AS TE path. 265 Inter-AS DS-TE: Diffserv-aware Inter-AS TE. 267 CE: Customer Edge Equipment 269 PE: Provider Edge Equipment that has direct connections to CEs. 271 P: Provider Equipment that has backbone trunk connections only. 273 VRF: Virtual Private Network (VPN) Routing and Forwarding Instance. 275 PoP: Point of presence or a node in SP's network. 277 SRLG: A set of links may constitute a 'shared risk link group' 278 (SRLG) if they share a resource whose failure may affect all 279 links in the set as defined in [GMPLS-ROUT]. 281 Please note that the terms of CE, PE and P used throughout this 282 document are generic in their definitions. In particular, whenever 283 such acronyms are used, it does not necessarily mean that CE is 284 connected to a PE in a VRF environment described in such IETF drafts 285 as [BGP-MPLSVPN]. 287 3.2. Objectives and Requirements of Inter-AS Traffic Engineering 289 As mentioned in section 1 above, some SPs have requirements for 290 achieving the same set of traffic engineering objectives as 291 presented in [TE-OVW] across AS boundaries. 293 This section examines these requirements in each of the key 294 corresponding areas: 1) Inter-AS bandwidth guarantees; 2) 295 Inter-AS Resource Optimization and 3) Fast Recovery across ASes, 296 i.e. Recovery of Inter-AS Links/SRLG and ASBR Nodes. 298 3.2.1. Inter-AS Bandwidth Guarantees 300 The DiffServ IETF working group has defined a set of mechanisms 301 described in [DIFF_ARCH], [DIFF_AF] and [DIFF_EF] or [MPLS-Diff] 302 that can be activated at the edge or over a DiffServ domain to 303 contribute to the enforcement of a (set of) QoS policy(ies), which 304 can be expressed in terms of maximum one-way transit delay, 305 inter-packet delay variation, loss rate, etc. 307 Many SPs have partial or full deployment of Diffserv implementations 308 in their networks today, either across the entire network or 309 minimally on the edge of the network across CE-PE links. 311 In situations where strict Quality of Service (QOS) bounds are 312 required, admission control inside the backbone of a network is in 313 some cases required in addition to current Diffserv mechanisms. 315 MPLS Inter-AS TE requirements September 2004 317 When the propagation delay can be bounded, the performance targets, 318 such as maximum one-way transit delay, may be guaranteed by 319 providing bandwidth guarantees along the Diffserv-enabled path. 321 One typical example of this requirement is to provide bandwidth 322 guarantees over an end-to-end path for VoIP traffic classified as EF 323 (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled 324 network. When the EF path is extended across multiple ASes, 325 inter-AS bandwidth guarantee is then required. 327 Another case for inter-AS bandwidth guarantee is the requirement for 328 guaranteeing a certain amount of transit bandwidth across one or 329 multiple ASes. 331 Several application scenarios are presented to further illustrate 332 this requirement in section 4 below. 334 3.2.2. Inter-AS Resource Optimization 336 In Service Provider (SP) networks, the BGP protocol [BGP] is 337 deployed to exchange routing information between ASes. The inter-AS 338 capabilities of BGP may also be employed for traffic engineering 339 purposes across the AS boundaries. Appendix A provides a 340 brief description of the current BGP-based inter-AS traffic 341 engineering practices. 343 SPs have managed to survive with this coarse set of BGP-based 344 traffic engineering facilities across inter-AS links in a largely 345 best-effort environment. Certainly in many cases ample bandwidth 346 within SP's network and across inter-AS links reduces the need for 347 more elaborate inter-AS TE policies. 349 However, in the case where a SP network is deployed over multiple 350 ASes, for example, as the number of inter-AS links grows, the 351 complexity of the inter-AS policies and the difficulty in inter-AS 352 TE path optimization increase to a level such that it may soon 353 become unmanageable. 355 Another example is where inter-AS links are established between 356 different SP administrative domains. Nondeterministic factors such 357 as uncoordinated routing and network changes, as well as sub- 358 optimum traffic conditions would potentially lead to a complex set 359 of Inter-AS traffic engineering policies where current traffic 360 engineering mechanisms would probably not scale well. 362 In these situations where resource optimization is required and/ or 363 specific routing requirements arise, the BGP-based inter-AS 364 facilities will need to be complemented by a more granular inter-AS 365 traffic engineering mechanism. 367 MPLS Inter-AS TE requirements September 2004 369 3.2.3. Fast Recovery across ASes 371 When extending services such as VoIP across ASes, customers often 372 reqiure SPs to maintain the same level of performance targets, such 373 as packet loss and service availability, as achieved within an AS. 374 As a consequence, fast convergence in a stable fashion upon 375 link/SRLG/node failures becomes a strong requirement. This is 376 clearly difficult to achieve with current inter-domain techniques, 377 especially in cases of link/SRLG failures between ASBRs or ASBR node 378 failures. 380 3.3. Inter-AS Traffic Engineering Requirements Statement 382 Just as in the applicable case of deploying MPLS TE in a SP's 383 network, an inter-AS TE method in addition to BGP-based traffic 384 engineering capabilities needs to be deployed across inter-AS links 385 where resource optimization, bandwidth guarantees and fast recovery 386 are required. 388 This is especially critical in a Diffserv-enabled, multi-class 389 environment described in [PSTE] where statistical performance 390 targets must be maintained consistently over the entire path 391 across different ASes. 393 The approach of extending current intra-AS MPLS TE capabilities 394 [TE-RSVP] across inter-AS links for IP/MPLS networks is considered 395 here because of already available implementations and operational 396 experiences. 398 Please note that the inter-AS traffic engineering over an IP-only 399 network is for future consideration since there is not sufficient 400 interest for similar requirements to those of IP/MPLS networks 401 at this time. More specifically, this document only covers the 402 inter-AS TE requirements for packet based IP/MPLS networks. 404 4. Application Scenarios 406 The following sections present a few application scenarios over 407 IP/MPLS networks where requirements cannot be addressed with current 408 intra-AS MPLS TE mechanism and give rise to considerations for 409 inter-AS MPLS traffic engineering requirements. 411 Although not explicitly noted in the following discussions, fast 412 recovery of traffic path(s) crossing multiple ASes in a stable 413 fashion is particularly important in the case of link/SRLG/node 414 failures at AS boundaries for all application scenarios presented 415 here. 417 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees 419 4.1.1 Scenario I - Extended or Virtual PoP (VPoP) 421 A global service provider (SP1) would like to expand its reach into 422 a region where a regional service provider's (SP2) network has 423 already established a denser network presence. 425 In this scenario, the SP1 may establish interconnections with SP2 in 426 one or multiple points in that region. In their customer dense 427 regions, SP1 may utilize SP2's network as an extended transport by 428 co-locating aggregation routers in SP2's PoPs. 430 In order to ensure bandwidth capacity provided by SP2 and achieve 431 some degrees of transparency to SP2's network changes in terms of 432 capacity and network conditions, one or more Inter-AS MPLS TE 433 trunk(s) can be built between SP1's ASBR or PE router inside AS1 and 434 SP1's PE routers co-locating in SP2's PoPs, as illustrated in the 435 diagram below: 437 <===========Inter-AS MPLS TE Tunnel===========> 438 ----- ----- 439 ________|ASBR |___Inter-AS___|ASBR |________ 440 | | RTR | Link | RTR | | 441 ---- ----- ----- ----- ----- 442 |SP1 |_Inter-AS_| SP2 | | SP1 | 443 |VPoP| Link |P/PE | |P/PE | 444 ---- ----- ----- ----- ----- 445 |________|ASBR |___Inter-AS___|ASBR |________| 446 | RTR | Link | RTR | 447 ----- ----- 448 <=================Inter-AS MPLS TE Tunnel======================> 449 +-SP1 AS1-+ +---SP2 AS2-----+ +------SP1 AS1------+ 451 In situations where end-to-end Diffserv paths must be maintained, 452 both SP's networks may need to provision Diffserv PHB at each hop 453 supporting a set of traffic classes with compatible performance 454 targets. The subsequent issues regarding Service Level Agreement 455 (SLA) boundaries, reporting and measuring system inter-operability 456 and support demarcations are beyond the scope of this document and 457 are not discussed further. 459 If either SP1's or SP2's network is not a Diffserv-aware network, 460 the scenario would still apply to provide bandwidth guarantees. 462 The SP2, on the other hand, can similarly choose to expand its reach 463 beyond its servicing region over SP1's network via inter-AS MPLS 464 TE paths. 466 MPLS Inter-AS TE requirements September 2004 468 It is worth mentioning that these remote aggregation routers 469 co-located in another SP's network are unlikely to host SP1's IGP 470 and BGP routing planes and will more likely maintain their own AS or 471 be part of the SP1's AS. In this case, such TE tunnels may cross 472 several ASes, but the Head-end and Tail-end LSRs of TE tunnel may 473 have the same AS number, as shown in the diagram above. 475 4.1.2. Scenario II - Extended or Virtual Trunk 477 Instead of co-locating a PE router in SP2's PoP, SP1 may also choose 478 to aggregate customer VPN sites onto a SP2's PE router where inter- 479 AS TE tunnels can be built and signaled through SP2's MPLS network 480 between the SP2 PoP (to which SP1 a customer CEs are directly 481 connected) and SP1's ASBR or PE routers inside SP2's network. This 482 allows SP1's customers connected to SP2 PE router to receive a 483 guaranteed bandwidth service up to the TE LSP tail-end router 484 located in SP1's network. 486 In this scenario, there could be two applicable cases: 488 Case 1 - the inter-AS MPLS TE tunnel functions as an extended or 489 virtual trunk aggregating SP1's CE's local-loop access circuits on 490 SP2's MPLS network over which the bandwidth can be guaranteed to the 491 TE LSP tail-end router located in SP1's network, as shown in the 492 diagram below: 494 <====Inter-AS MPLS TE Tunnel====> 495 or 496 < ===Inter-AS MPLS TE Tunnel===============> 498 ---- ----- ----- ----- ----- 499 | CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | 500 | | Loop | PE | | RTR | Link | RTR | |PE | 501 ---- ----- ----- ----- ----- 503 +SP1 Customer ASx+ +-----SP2 AS2---+ +-SP1 AS1-------+ 505 Case 2 - the inter-AS MPLS TE tunnel in this case functions as an 506 extended or virtual local access link from SP1's CE on SP2's network 507 to the SP1's ASBR or PE: 509 <==============Inter-AS MPLS TE Tunnel==============> 510 or 511 <==============Inter-AS MPLS TE Tunnel========================> 513 ---- ----- ----- ----- ----- 514 | CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | 515 | | Loop | PE | | RTR | Link | RTR | |PE | 516 ---- ----- ----- ----- ----- 518 +SP1 Customer ASx+ +------SP2 AS2---+ +--SP1 AS1-----+ 520 MPLS Inter-AS TE requirements September 2004 522 In case 2 above, SP2 may elect to establish an aggregating or 523 hierarchical intra-AS MPLS TE tunnel between the transiting P or PE 524 router and SP2's ASBR router just to reduce the number of tunnel 525 states signaled from the SP2 PE to where SP1's CEs are connected. 527 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE 529 In this scenario as illustrated below, customers require the 530 establishment of MPLS TE tunnel from CE1 to CE2 end-to-end across 531 several SPs� networks. 533 <======================Inter-AS MPLS TE Tunnel==================> 535 --- ----- ----- ----- ----- --- 536 |CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2| 537 | | | PE | | RTR | Link | RTR | | PE | | | 538 --- ----- ----- ----- ----- --- 540 +Cust ASx+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASy+ 542 The diagram below illustrates another example where CE1 and CE2 are 543 customers of SP1 with extenal BGP (eBGP) peering relationships 544 established across the CE-PE links. An inter-AS MPLS TE tunnel may 545 then be established from CE1 in ASx to CE2 which may belong to the 546 same AS or a different AS than that of CE1 across SP1's network in 547 AS2. 549 <===============Inter-AS MPLS TE Tunnel=====================> 551 --- ----- ---- ---- ----- --- 552 |CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2| 553 | | | PE1 | |P1 | |P2 | | PE2 | | | 554 --- ----- ---- ---- ----- --- 556 +-Cust ASx-+ +-------------SP1 AS2----------------+ +-Cust ASy-+ 558 The above example shows that SP1's network has a single AS. 559 Obviously, there may be multiple ASes between CE1 and CE2 as well as 560 in the SP1's network. 562 In addition, where both CE1 and CE2 reside in the same AS, they will 563 likely share the same private AS number. 565 Scenario III however, will not scale well if there is a greater 566 number of inter-AS TE MPLS tunnels in some degrees of partial mesh 567 or full mesh. Therefore, it is expected that this scenario will 568 have few deployments, unless some mechanisms such as hierarchical 569 intra-AS TE-LSPs are used to reduce the number of signaling states. 571 MPLS Inter-AS TE requirements Septmber 2004 573 4.2. Application Scenarios Requiring Inter-AS Resource Optimization 575 The scenarios presented in this section mainly deal with inter-AS 576 resource optimization. 578 4.2.1. Scenario IV - TE across multi-AS within a Single SP 579 Administrative Domain 581 As mentioned in [TE-APP], SPs have generally admitted that the 582 current MPLS TE mechanism provides a great deal of tactical and 583 strategic value in areas of traffic path optimization [TE-RSVP] and 584 rapid local repair capabilities [TE-FRR] via a set of on-line or 585 off-line constraint-based searching algorithms. 587 From a service provider's perspective, another way of stating the 588 objectives of traffic engineering is to utilize available capacity 589 in the network for delivering customer traffic without violating 590 performance targets, and/ or to provide better QOS services via an 591 improved network utilization, operating more likely below congestion 592 thresholds. 594 It is worth noting that situations where resource provisioning is 595 not an issue, e.g. low density in inter-AS connectivity or ample 596 inter-AS capacity, it may not require more scalable and granular TE 597 facilities beyond BGP routing policies since such policies can be 598 rather simple and because inter-AS resource optimization is not an 599 absolute requirement. 601 However many SPs, especially those with networks across multiple 602 continents, as well as those with sparsely connected networks, have 603 designed their multi-AS routing policies along or within the 604 continental or sub-continental boundaries where the number of ASes 605 can range from a very few to dozens. Generally, inter-continent or 606 sub-continent capacity is very expensive. Some Service Providers 607 have multiple ASes in the same country and would like to optimize 608 resources over their inter-region links. This would demand a 609 more scalable degree of resource optimization, which warrants the 610 consideration of extending current intra-AS MPLS TE capabilities 611 across inter-AS links. 613 In addition, one may only realize higher efficiency in conducting 614 traffic optimization and path protection/ restoration planning when 615 coordinating all network resources as a whole, rather than 616 partially. For a network which may consist of many ASes, this could 617 be realized via the establishment of inter-AS TE LSPs as shown in 618 the diagragm below: 620 MPLS Inter-AS TE requirements September 2004 622 <===================Inter-AS MPLS Tunnel=============> 623 -------- -------- -------- 624 | |_______________| |____________| | 625 | SP1 |_______________| SP1 |____________| SP1 | 626 | AS1 |_______________| AS2 |____________| AS3 | 627 | | | | | | 628 -------- -------- -------- 629 || || 630 || --------- || 631 ||___________________| SP1 |________________|| 632 |____________________| AS4 |_________________| 633 | | 634 --------- 635 The motivation for inter-AS MPLS TE is even more prominent in a 636 Diffserv-enabled network over which statistical performance targets 637 are to be maintained from any point to any point of the network as 638 illustrated in the diagram below with an inter-AS DS-TE LSP: 640 <===================Inter-AS MPLS DS-TE Tunnel=============> 641 ---- ----- ----- ----- ----- ---- 642 | PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE | 643 | RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR | 644 ---- ----- ----- ----- ----- ---- 645 +------------SP1 AS1---------+ +------------SP1 AS2------+ 647 For example , the inter-AS MPLS DS-TE LSP shown in the diagram above 648 could be used to transport a set of L2 Pseudo Wires or VoIP traffic 649 with corresponding bandwidth requirement. 651 Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR 652 node failure is a strong requirement for such services. 654 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport 656 Scenario V presents another possible deployment case. SP1 with AS1 657 wants to link a regional network to its core backbone by building an 658 inter-AS MPLS TE tunnel over one or multiple transit ASes belonging 659 to SP2, SP3, etc. as shown in the following diagram: 661 <===========Inter-AS MPLS TE Tunnel=======> 662 [ ] [ ] [ ] 663 [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] 664 [ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|] 665 [ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |] 666 [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] 667 [ ] [ ] [ ] 668 <================Inter-AS MPLS TE Tunnel=====================> 669 +SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+ 671 This scenario can be viewed as a broader case of Scenario I shown in 672 section 4.1.1 where the "VPoP" could be expanded into a regional 673 network of SP1. By the same token, the AS number for SP1's regional 674 network ASx may be the same as or different from AS1. 676 MPLS Inter-AS TE requirements September 2004 678 The inter-AS MPLS TE LSP in this case may also be used to backup an 679 internal path as depicted in the diagram below, although this could 680 introduce routing complexities: 682 <===========Inter-AS MPLS TE Tunnel=======> 683 +----------------------------SP1 AS1-----------------------------+ 684 [ ] 685 [ ---- ---- ---- ---- ] 686 [ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |] 687 [ |RTR | |RTR | Link |RTR | |RTR |] 688 [ ---- ---- ---- ---- ] 689 [ | | ] 690 [ ---- ---- ] 691 [ |ASBR| |ASBR| ] 692 [ |RTR | |RTR | ] 693 [ ---- ---- ] 694 ^ | | ^ 695 | | | | 696 | | [ ] | | 697 | | [ ---- ---- ] | | 698 | |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| | 699 | Link [|RTR | |RTR |] Link | 700 | [ ---- ---- ] | 701 | [ ] | 702 | | 703 +======Backup Inter-AS MPLS TE Tunnel======+ 704 +Transit SP2 AS2,SP3 AS3,etc....SPi ASi+ 706 5. Detailed Requirements for Inter-AS MPLS Traffic Engineering 708 This section discusses detailed requirements for inter-AS MPLS TE in 709 two principal areas: 1) requirements for inter-AS MPLS TE in the 710 same SP administrative domain and 2) requirements for inter-AS MPLS 711 TE across different SP administrative domains. 713 5.1. Requirements within one SP Administrative Domain 715 This section presents detailed requirements for inter-AS MPLS TE 716 within the same SP administrative domain. 718 5.1.1. Inter-AS MPLS TE Operations and Interoperability 720 The inter-AS MPLS TE solution SHOULD be consistent with requirements 721 discussed in [TE-REQ] and the derived solution MUST be such that 722 it will interoperate seamlessly with current intra-AS MPLS TE 723 mechanism and inherit its capability sets from [TE-RSVP]. 725 The proposed solution SHOULD allow the provisioning of a TE LSP at 726 the Head/Tail end with end-to-end Resource Reservation Protocol 727 (RSVP) signaling (eventually with loose paths) traversing across the 728 interconnected ASBRs, without further provisioning required along 729 the transit path. 731 MPLS Inter-AS TE requirements September 2004 733 5.1.2. Protocol Signaling and Path Computations 735 One can conceive that an inter-AS MPLS TE tunnel path signaled 736 across inter-AS links consists of a sequence of ASes, ASBRs and 737 Inter-AS links. 739 The proposed solution SHOULD provide the ability to either 740 explicitly select or auto-discover the following elements when 741 signaling the inter-AS TE LSP path: 743 - a set of AS numbers as loose HoPs and/or 744 - a set of LSRs including ASBRs 746 It should also specify the above elements in the Explicit Route 747 Object (ERO) and record them in the Record Route Object (RRO) of the 748 Resv message just to keep track of the set of ASes or ASBRs 749 traversed by the inter-As TE LSP. 751 In the case of establishing inter-AS TE LSP traversing multiple ASes 752 within the same SP networks, the solution SHOULD also allow the 753 Head-end LSR to explicitly specify the hops across any one of 754 the transiting ASes and the TE tunnel Head-end SHOULD also check 755 the explicit segment to make sure that the constraints are met. 757 In addition, the proposed solution SHOULD provide the ability 758 to specify and signal that certain loose or explicit nodes (e.g. AS 759 numbers, etc.) and resources are to be explicitly excluded in the 760 inter-AS TE LSP path establishment, such as one defined in 761 [EXCLUDE-ROUTE] for instance. 763 5.1.3 Optimality 765 The solution SHOULD allow the set-up of an inter-AS TE LSP that 766 complies with a set of TE constraints defined in [TE-REQ]) and 767 follows an optimal path. 769 An optimal path is defined as a path whose end-to-end cost is 770 minimal, based upon either an IGP or a TE metric. Note that in 771 the case of an inter-AS path across several ASes having completely 772 different IGP metric policies, the notion of minimal path might 773 require IGP metric normalization. 775 The solution SHOULD provide mechanism(s) to compute and establish an 776 optimal end-to-end path for the inter-AS TE LSP and SHOULD also 777 allow for reduced optimality (or sub-optimality) since the path may 778 not remain optimal for the life-time of the LSP 780 5.1.4 Support of diversely routed inter-AS TE LSP 782 In some cases it might be desirable to set up multiple inter-AS TE 783 LSPs between a pair of LSRs when: 785 MPLS Inter-AS TE requirements September 2004 787 (1) a single TE LSP satisfying the required set of constraints 788 cannot be found, in which case it may require load splitting; 790 (2) multiple TE paths may be required to limit the impact of a 791 network element failure to a portion of the traffic (as an 792 example, two VoIP gateways may load balance the traffic among 793 a set of inter-AS TE LSPs); 795 (3) path protection (e.g. 1:1 or 1:N) as discussed in 796 [MPLS-Recov]. 798 In the examples above, being able to set up diversely routed TE LSPs 799 becomes a requirement for inter-AS TE. 801 The solution SHOULD be able to set up a set of link/SRLG/Node 802 diversely routed inter-AS TE LSPs. 804 5.1.5. Re-optimization 806 Once an inter-AS TE LSP has been established, and should there be 807 any resource or other changes inside anyone of the ASes, the 808 solution MUST be able to re-optimize the LSP accordingly and 809 non-disruptively, either upon expiration of a configurable timer or 810 triggered by a network event or a manual request at the TE tunnel 811 Head-End. 813 The solution SHOULD provide an option for the Head-End LSRs to 814 control if re-optimizing or not should there exist a more optimal 815 path in one of the ASes. 817 In the case of an identical set of traversed path, the solution 818 SHOULD provide an option for the Head-End LSRs to control if 819 re-optimizing or not should there exist a more optimal path in one 820 of the transit ASes along the inter-AS TE LSP path. 822 Furthermore, the solution MUST provide the ability to reject 823 re-optimization at AS boundaries. 825 5.1.6. Fast Recovery support using MPLS TE Fast Reroute 827 There are in general two or more inter-AS links between multiple 828 pairs of ASBRs for redundancy. The topological density between ASes 829 in a SP network with multi-ASes is generally much higher. In the 830 event of an inter-AS link failure, rapid local protection SHOULD 831 also be made available and SHOULD interoperate with current intra-AS 832 MPLS TE fast re-route mechanism from [TE-FRR]. 834 The traffic routed onto an inter-AS TE tunnel SHOULD also be fast 835 protected against any node failure where the node could be internal 836 to an AS or at the AS boundary. 838 MPLS Inter-AS TE requirements September 2004 840 5.1.7. DS-TE Support 842 The proposed inter-AS MPLS TE solution SHOULD satisfy core 843 requirements documented in [DS-TE]. 845 It is worth pointing out that the compatibility clause in section 846 4.1 of [DS-TE] SHOULD also be faithfully applied to the solution 847 development 849 5.1.8. Scalability and Hierarchical LSP Support 851 The proposed solution(s) MUST have a minimum impact on network 852 scalability from both intra and inter-AS perspectives. 854 This requirement applies to all of the following: 856 - IGP (impact in terms of IGP flooding, Path computation, etc.) 857 - BGP (impact in terms of additional information carried within 858 BGP, number of routes, flaps, overload events, etc.) 859 - RSVP TE (message rate, number of retained states, ,etc.) 861 It is also conceivable that there would potentially be scalability 862 issues as the number of required inter-AS MPLS TE tunnels increases. 863 In order to reduce the number of tunnel states to be maintained by 864 each transiting PoP, the proposed solution SHOULD allow TE LSP 865 aggregation such that individual tunnels can be carried onto one or 866 more aggregating LSP(s). One such mechanism, for example is 867 described in [MPLS-LSPHIE]. 869 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels 871 There SHOULD be several possibilities to map particular traffic 872 to a particular destination onto a specific inter-AS TE LSP. 874 For example, static routing could be used if IP destination 875 addresses are known. Another example is to utilize static routing 876 using recursive BGP route resolution. 878 The proposed solution SHOULD also provide the ability to "announce" 879 the inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) 880 with the link's cost associated with it. By doing so, PE routers 881 that do not participate in the inter-AS TE path computation can take 882 into account such links in its IGP-based SPF computation. 884 MPLS Inter-AS TE requirements September 2004 886 5.1.10. Inter-AS MPLS TE Management 888 5.1.10.1. Inter-AS MPLS TE MIB Requirements 890 An inter-AS TE Management Information Base (MIB) is required for use 891 with network management protocols by SPs to manage and configure 892 inter-AS traffic engineering tunnels. This new MIB SHOULD extend 893 (and not reinvent) the existing MIBs to accommodate this new 894 functionality. 896 An inter-AS TE MIB should have features that include: 897 - The setup of inter-AS TE tunnels with associated constraints 898 (e.g. resources) 899 - The collection of traffic and performance statistics not only 900 at the tunnel headend, but any other points of the TE tunnel. 901 - The inclusion of both IPv4/v6 + AS# or AS# subobjects in the 902 ERO in the path message, e.g: 904 EXPLICIT_ROUTE class object: 905 address1 (loose IPv4 Prefix, /AS1) 906 address2 (loose IPv4 Prefix, /AS1) 907 AS2 (AS number) 908 address3 (loose IPv4 prefix, /AS3) 909 address4 (loose IPv4 prefix, /AS3) - destination 911 or 913 address1 (loose IPv4 Prefix, /AS1) 914 address2 (loose IPv4 Prefix, /AS1) 915 address3 (loose IPv4 Prefix, /AS2) 916 address4 (loose IPv4 Prefix, /AS2) 917 address5 (loose IPv4 prefix, /AS3) 918 address6 (loose IPv4 prefix, /AS3) - destination 920 - Similarly, the inclusion of the RRO object in the resv message 921 recording sub-objects such as interface IPv4/v6 address (if not 922 hidden), AS number, a label, a node-id (when required), etc. 923 - Inter-AS specific attributes as discussed in section 5 of this 924 document including, for example inter-AS MPLS TE tunnel 925 accounting records across each AS segment 927 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements 929 In a MPLS network, a SP wants to detect both control plane and data 930 plane failures. But tools for fault detection over LSPs haven't 931 been widely developed so far. SPs today manually troubleshoot such 932 failures in a hop-by-hop fashion across the data path. If they 933 detect an error on the data plane, they have to check the control 934 plane in order to determine where the faults come from. 936 MPLS Inter-AS TE requirements September 2004 938 The proposed solution SHOULD be able to interoperate with fault 939 detection mechanisms of intra-AS TE and MAY or MAY NOT require the 940 inter-AS TE tunnel ending addresses to be known or routable across 941 IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with 942 working return paths. 944 For example, [LSPPING] is being considered as a failure detection 945 mechanism over the data plane against the control plane and could 946 be used to troubleshoot intra-AS TE LSPs. Such facilities, if 947 adopted, SHOULD then be extended to inter-AS TE paths. 949 However, the above example depicts one such mechanism that does 950 require a working return path such that diagnostic test packets can 951 return via an alternate data plane, such as a global IPv4 path in 952 the event that the LSP is broken. 954 [MPLS-TTL] presents how TTL may be processed across a hierarchical 955 MPLS networks and such a facility as this SHOULD also be extended 956 to inter-AS TE links. 958 5.1.11. Extensibility 960 The solution(s) MUST allow extensions as both inter-AS MPLS TE and 961 current intra-AS MPLS TE specifications evolve. 963 5.1.12. Complexity and Risks 965 The proposed solution(s) SHOULD NOT introduce unnecessary complexity 966 to the current operating network to such a degree that it would 967 affect the stability and diminish the benefits of deploying such a 968 solution over SP networks. 970 5.1.13. Backward Compatibility 972 The deployment of inter-AS MPLS TE SHOULD NOT impact existing BGP- 973 based traffic engineering or MPLS TE mechanisms, but allow for a 974 smooth migration or co-existence. 976 5.1.14. Performance 978 The solution SHOULD be evaluated taking into account various 979 performance criteria: 981 - Degree of path optimality of the inter-AS TE LSP path 982 - TE LSP setup time 983 - Failure and restoration time 984 - Impact and scalability of the control plane due to added 985 overheads, etc. 986 - Impact and scalability of the data/forwarding plane due to 987 added overheads, etc. 989 MPLS Inter-AS TE requirements September 2004 991 5.2. Requirements for Inter-AS MPLS TE across Multiple SP 992 Administrative Domains 994 The requirements for inter-AS MPLS TE across multiple SP admin 995 domains SHOULD include all requirements discussed in section 5.1 996 above in addition to those that are presented in this section here. 998 Please note that the SP with multi-AS networks may choose not to 999 turn on the features discussed in the following two sections when 1000 building TE tunnels across ASes in its own domain. 1002 5.2.1. Confidentiality 1004 Since an inter-AS TE LSP may span multiple ASes belonging to 1005 different SPs, the solution MIGHT allow hiding the set of 1006 hops used by the TE LSP within an AS as illustrated in the following 1007 example: 1009 [ ASBR1-----ASBR2 ] 1010 [ ] [ ] 1011 [ A ] [ B ] 1012 [ AS1 ] [ AS2 ] 1013 [ SP1 ]-----[ SP2 ] 1014 [ ] [ ] 1016 Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B 1017 (within AS2 of SP2). When computing an inter-AS TE LSP path, the 1018 set of hops within AS2 might be hidden to AS1. In this case, the 1019 solution will allow A to learn that the more optimal TE LSP path to 1020 B that complies with the set of constraints traverses ASBR2 without 1021 a detailed knowledge of the lists of hops used within AS2. 1023 Optionally, the TE LSP path cost within AS2 could be provided to A, 1024 via for example PCC-PCS signaling [PATH-COMP], such that A (PCC) 1025 could use this information to compute an optimal path, even if the 1026 computed path is not provided by AS2. 1028 In addition, the management requirements discussed in section 5.1.10 1029 above, when used across different SP admin domains, SHOULD include 1030 similar confidentiality requirements discussed here in terms of 1031 "hiding" intermediate hops or interface address and/or labels in 1032 the transiting or peering SPs. 1034 5.2.2. Policy Control 1036 In some cases, policy control might be necessary at the AS 1037 boundaries, namely ingress policy controls enabling SPs to enforce 1038 the inter-AS policies per interconnect agreements or modify some 1039 requested parameters conveyed by incoming inter-AS MPLS TE signaling 1040 requests. 1042 MPLS Inter-AS TE requirements September 2004 1044 It is worth noting that such a policy control mechanism may also be 1045 used between ASes within a SP. 1047 This section only discusses the elements that may be used to form a 1048 set of ingress control policies but exactly how SPs establish 1049 bilateral or multilateral agreements upon which the control policies 1050 can be built are beyond the scope of this document. 1052 5.2.2.1. Inter-AS TE Agreement Enforcement Polices 1054 The following provides a set of TE-LSP parameters in the inter-AS TE 1055 Requests (RSVP Path Message) that SHOULD be enforced at the AS 1056 boundaries: 1058 - RSVP-TE session attributes: affinities and preemption 1059 priorities 1060 - Per AS or SP bandwidth admission control to ensure that RSVP-TE 1061 messages do not request for bandwidth resources over their 1062 allocation 1063 - Request origins which can be represented by Head-End tunnel 1064 ending IP address, originating AS#, neighbor AS#, neighbor ASBR 1065 interface IP address, etc. 1066 - DS-TE TE-Class 1067 - FRR attribute: local protection desired bit, node protection 1068 desired bit and bandwidth protection desired bit carried in the 1069 SESSION 1070 - ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message 1071 as defined in [TE-FRR] 1072 - Optimization allowed or not allowed 1074 In some cases, a TE policy server could also be used for the 1075 enforcement of inter-AS TE policies. Implementations SHOULD allow 1076 the use of a policy enforcement server. This requirement could 1077 allow SPs to make the inter-AS TE policies scale better. 1079 The signaling of a non policy compliant request SHOULD trigger the 1080 generation of a RSVP Path Error message by the policy enforcing 1081 node towards the Head-end LSR, indicating the cause. The 1082 Head-end LSR SHOULD take appropriate actions, such as re-route, upon 1083 receipt of such a message. 1085 5.2.2.2. Inter-AS TE Rewrite Policies 1087 In some situations, SPs may need to rewrite some attributes of the 1088 incoming inter-AS TE signaling requests due to a lack of resources 1089 for a particular TE-Class, non-compliant preemption, or upon mutual 1090 agreements. The following lists parameters that can potentially be 1091 rewritten at the AS boundaries: 1093 - RSVP-TE session attributes: affinities and preemption 1094 priorities 1095 - DS-TE TE-Class 1096 - ERO expansion requests 1098 MPLS Inter-AS TE requirements September 2004 1100 Similarly, the re-writing node SHOULD generate a RSVP Path Error 1101 Message towards the Head-end LSR indicating the cause in terms 1102 of types of changes made so as to maintain the end-to-end integrity 1103 of inter-AS TE LSP. 1105 5.2.2.3 Inter-AS Traffic Policing 1107 The proposed solution SHOULD also provide a set of policing 1108 mechanisms which could be configured on the inter-AS links 1109 to ensure that traffic routed through the tunnel does not exceed 1110 the bandwidth negotiated during LSP signaling. 1112 For example, an ingress policer could be configured to enforce 1113 the traffic contract on the mutually agreed resource requirements 1114 of the established inter-AS TE LSP (i.e. RSVP bandwidth) on the 1115 interface to which the inter-AS link is connected. 1117 6. Security Considerations 1119 The proposed solution(s) MUST address security issues across 1120 multiple SP administrative domains. Although inter-AS MPLS TE is 1121 not expected to add specific security extensions beyond those of 1122 current intra-AS TE, greater considerations MUST be given in terms 1123 of how to establish a trusted model across AS boundaries. SPs 1124 SHOULD have a means to authenticate (such as using RSVP INTEGRITY 1125 Object), allow and possibly denying inter-AS signaling requests 1126 and SHOULD be protected from DoS attacks. 1128 7. Acknowledgements 1130 We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik 1131 Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, 1132 Ed Kern, Jim Boyle, Thomas Nadeauor, Yakov Rekhter and Bert Wijnen 1133 for their suggestions and helpful comments during the discussions of 1134 this draft. 1136 8. Editor's Addresses 1138 Raymond Zhang 1139 Infonet Services Corporation 1140 2160 E. Grand Ave. 1141 El Segundo, CA 90025 1142 USA 1143 Email: raymond_zhang@infonet.com 1145 JP Vasseur 1146 CISCO Systems, Inc. 1147 300 Beaver Brook Road 1148 Boxborough , MA - 01719 1149 USA 1150 Email: jpv@cisco.com 1152 MPLS Inter-AS TE requirements September 2004 1154 9. Normative References 1156 [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering 1157 over MPLS", RFC2702, September 1999. 1159 [TE-RSVP], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP 1160 Tunnels", RFC 3209, December 2001 1162 [RFC-2119], S. Bradner, "Key words for use in RFCs to Indicate 1163 Requirement Levels", RFC 2119, March 1997 1165 10. Informative References 1167 [MPLS-ARCH], Rosen, et. al., "Multiprotocol Label Switching 1168 Architecture", RFC 3031, January 2001 1170 [BGP-MPLSVPN], Rosen, et. al., "BGP/MPLSVPN", draft-ietf-l3vpn 1171 -rfc2547bis-01.txt, September 2003 (work in progress). 1173 [DIFF_ARCH], Blake, et. al., "An Architecture for Differentiated 1174 Services", RFC 2475, December 1998. 1176 [DIFF_AF], Heinanen,et. al., "Assured Forwarding PHB Group", RFC 1177 2597, June 1999. 1179 [DIFF_EF], Davie, et. al., "An Expedited Forwarding PHB (Per-Hop 1180 Behavior)", RFC 3246, March 2002. 1182 [MPLS-Diff], Le Faucheur, et. al., "MPLS Support of Differentiated 1183 Services", RFC 3270, May 2002 1185 [TE-OVW], Awduche, et. al., "Overview and Principles of Internet 1186 Traffic Engineering", RFC 3272,May 2002 1188 [PSTE], Li, et. al., "A Provider Architecture for Differentiated 1189 Services and Traffic Engineering", RFC 2430, October 1998 1191 [TE-APP], Boyle, et. al., "Applicability Statement of Traffic 1192 Engineering", RFC 3346, August 2002. 1194 [TE-SURVIV], Lai, et. al., "Network Hierachy and Multilayer 1195 Suvivability", RFC 3386, November, 2002. 1197 [GMPLS-ROUT], Kompella, et. al., "Generalized Multi-Protocol Label 1198 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1199 Engineering (RSVP-TE) Extensions, RFC 3473, January 2003. 1201 [BGP], Rekhter, et. al., "A Border Gateway Protocol 4 (BGP-4)", 1202 RFC 1771, March 1995 1204 [LSPPING], Kompella, et.. al.," Detecting Data Plane Liveliness in 1205 MPLS", Internet Draft , 1206 August 2004, (Work in Progress) 1208 MPLS Inter-AS TE requirements September 2004 1210 [MPLS-TTL], Agarwal, et. al., "Time to Live (TTL) Processing in MPLS 1211 Networks", RFC 3443, January, 2003 1213 [DS-TE], Le Faucheur, et. al., ''Requirements for support of 1214 DiffServ-aware MPLS Traffic Engineering'', RFC 3564, July, 2003 1216 [TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE", 1217 draft-ietf-mpls-rsvp-lsp-fastreroute-05.txt, November 2003 1218 (Work in Progress). 1220 [ISIS-TE], Smit, Li, "IS-IS extensions for Traffic Engineering", 1221 draft-ietf-isis-traffic-05.txt, August, 2003 (Work in Progress). 1223 [OSPF-TE] Katz, Yeung, "Traffic Engineering (TE) Extensions to 1224 OSPF Version 2", RFC 2370, September 2003. 1226 [PATH-COMP], Vasseur, et. al., ''RSVP Path computation request and 1227 reply messages'', draft-vasseur-mpls-computation-rsvp-03.txt, June 1228 2002. (Work in Progress) 1230 [OSPF-TE-CAP], Vasseur, Psenak. "OSPF TE TLV capabilities", 1231 draft-vasseur-mpls-ospf-te-cap-00.txt, October 2002. 1232 (Work in Progress) 1234 [MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierarchy with Generalized 1235 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , September 2002. 1236 (work in progress) 1238 [MPLS-Recov], Sharma V., et al, "Framework for Multi-Protocol Label 1239 Switching (MPLS)-based Recovery", RFC 3469, Feb, 2003 1241 [BGP-Label], Rekhter and Rosen, "Carrying Label Information in 1242 BGP-4", RFC 3107, May 2001 1244 [INTER-AS-TE], Vasseur and Ayyangar, "Inter-AS MPLS Traffic 1245 Engineering", draft-vasseur-ccamp-inter-area-as-te-00.txt, 1246 August, 2004 (work in progress). 1248 [EXCLUDE-ROUTE], Farrel, et. al., "draft-ietf-ccamp-rsvp-te-exclude 1249 -route-01.txt", June 2004 (work in progress). 1251 MPLS Inter-AS TE requirements September 2004 1253 11. Full Copyright Statement 1255 Copyright (C) The Internet Society (2004). This document is subject 1256 to the rights, licenses and restrictions contained in BCP 78, and 1257 except as set forth therein, the authors retain all their rights. 1259 This document and the information contained herein are provided on 1260 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1261 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1262 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1263 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1264 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1267 12. Intellectual Property 1269 The IETF takes no position regarding the validity or scope of any 1270 Intellectual Property Rights or other rights that might be claimed 1271 to pertain to the implementation or use of the technology described 1272 in this document or the extent to which any license under such 1273 rights might or might not be available; nor does it represent that 1274 it has made any independent effort to identify any such rights. 1275 Information on the procedures with respect to rights in RFC 1276 documents can be found in BCP 78 and BCP 79. 1278 Copies of IPR disclosures made to the IETF Secretariat and any 1279 assurances of licenses to be made available, or the result of an 1280 attempt made to obtain a general license or permission for the use 1281 of such proprietary rights by implementers or users of this 1282 specification can be obtained from the IETF on-line IPR repository 1283 at http://www.ietf.org/ipr. 1285 The IETF invites any interested party to bring to its attention any 1286 copyrights, patents or patent applications, or other proprietary 1287 rights that may cover technology that may be required to implement 1288 this standard. Please address the information to the IETF at ietf- 1289 ipr@ietf.org. 1291 13. Acknowledgement 1293 Funding for the RFC Editor function is currently provided by the 1294 Internet Society. 1296 MPLS Inter-AS TE requirements September 2004 1298 Appendix A. Brief Description of BGP based Inter-AS Traffic 1299 Engineering 1301 In today's Service Provider (SP) network, BGP is deployed to meet 1302 two different sets of requirements: 1304 - Establishing a scalable exterior routing plane separate from 1305 The data forwarding plane within SP's administrative domain 1306 - Exchanging network reachability information with different BGP 1307 autonomous systems (ASs) that could belong to a different SP 1308 or simply, a different AS within a SP network 1310 Over connections across the AS boundaries, traffic engineering may 1311 also be accomplished via a set of BGP capabilities by appropriately 1312 enforcing BGP-based inter-AS routing policies. The current 1313 BGP-based inter-AS traffic engineering practices may be summarized 1314 as follows: 1316 - "Closest exit" routing where egress traffic from one SP to 1317 another follows the path defined by the lowest IGP or intra-AS 1318 MPLS TE tunnel metrics of the BGP next-HOP of exterior routes 1319 learned from other AS over the inter-AS links 1320 - "BGP path attribute" based routing selection mechanism where 1321 the egress traffic path is determined by interconnect (peering 1322 or transit) policies based upon one or a combination of BGP 1323 path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and 1324 Local_Pref. 1326 SPs have often faced a number of un-deterministic factors in the 1327 practices of inter-AS traffic engineering employing the methods 1328 mentioned above: 1330 - Sub-optimum traffic distribution across inter-AS links 1331 - Un-deterministic traffic condition changes due to uncoordinated 1332 IGP routing policies or topology changes within other AS and 1333 uncoordinated BGP routing policy changes (MED or as-prepend, 1334 etc.) 1336 In addition, to achieve some degrees of granularity, SPs may choose 1337 to enforce BGP inter-AS policies that are specific to one or a set 1338 of inter-AS links for ingress traffic destined to certain PoPs or 1339 regions within SP's network from another AS by tagging certain sets 1340 of routes with a specific attribute when announcing to another AS. 1341 This of course goes under the assumption that the other AS permits 1342 automated egress policy by matching the predefined attribute from 1343 incoming routes.