idnits 2.17.1 draft-ietf-tewg-interas-mpls-te-req-05.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. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The proposed solution(s) SHOULD not introduce unnecessary complexity to the current operating network to such a degree that it would affect the stability and diminish the benefits of deploying such a solution over SP networks. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The deployment of inter-AS MPLS TE SHOULD not have impact on existing BGP-based traffic engineering or MPLS TE mechanisms to allow for a smooth migration or co-existence. -- 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 (January 2004) is 7406 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: 'ISIS-TE' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE-CAP' is defined on line 1186, but no explicit reference was found in the text == Unused Reference: 'BGP-Label' is defined on line 1197, but no explicit reference was found in the text == Unused Reference: 'INTER-AS-TE' is defined on line 1200, but no explicit reference was found in the text == Unused Reference: 'TE-SURVIV' is defined on line 1236, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'TE-REQ') ** Obsolete normative reference: RFC 1771 (ref. 'BGP') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. 'LSPPING' ** Downref: Normative reference to an Informational RFC: RFC 3564 (ref. 'DS-TE') -- No information found for draft-ietf-tewg-diff - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'DSTE-PROT' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-03 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-13) exists of draft-ietf-ospf-ospfv3-traffic-01 == Outdated reference: A later version (-05) exists of draft-vasseur-mpls-computation-rsvp-03 -- Possible downref: Normative reference to a draft: ref. 'PATH-COMP' -- Possible downref: Normative reference to a draft: ref. 'OSPF-TE-CAP' ** Downref: Normative reference to an Informational RFC: RFC 3469 (ref. 'MPLS-Recov') ** Obsolete normative reference: RFC 3107 (ref. 'BGP-Label') (Obsoleted by RFC 8277) -- Possible downref: Normative reference to a draft: ref. 'INTER-AS-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'EXCLUDE-ROUTE' -- 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) Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 12 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 Document: JP Vasseur, Co-Editor 4 draft-ietf-tewg-interas-mpls-te-req-05.txt CISCO Systems, Inc 5 January 2004 6 Expires: July 2004 8 MPLS Inter-AS Traffic Engineering requirements 9 draft-ietf-tewg-interas-mpls-te-req-05.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are Working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document discusses requirements for the support of inter-AS 32 MPLS Traffic Engineering (MPLS TE). The main objective of this 33 document is to present a set of requirements which would result in a 34 set of general guidelines in the definition, selection and 35 specification development for any technical solution(s) meeting 36 these requirements. 38 Summary for Sub-IP related Internet Drafts 40 RELATED DOCUMENTS: 41 None 43 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 44 TEWG 46 WHY IS IT TARGETED AT THIS WG(s) 47 It is stated in the charter that documenting SP requirements in this 48 area are one of the work items to be undertaken by TEWG. 50 JUSTIFICATION 51 The TEWG charter further states that "The working group may also 52 consider the problems of traffic engineering across autonomous 53 systems boundaries." 54 This draft discusses the requirements for a traffic engineering 55 mechanism across autonomous systems boundaries that would also be 56 interoperable with current intra-AS traffic engineering mechanisms. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 62 this document are to be interpreted as described in RFC-2119. 64 Table of Contents 66 1. Introduction.......................................................3 67 2. Contributing Authors...............................................4 68 3. Definitions and Requirements Statement.............................5 69 3.1. Definitions......................................................5 70 3.2. Objectives and Requirements of Inter-AS Traffic Engineering......6 71 3.2.1. Inter-AS Bandwidth Guarantees..................................6 72 3.2.2. Inter-AS Resource Optimization.................................7 73 3.2.3. Fast Recovery across ASes......................................8 74 3.3. Inter-AS Traffic Engineering Requirements Statement..............8 75 4. Application Scenarios..............................................8 76 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees....9 77 4.1.1. Scenario I - Extended or Virtual PoP...........................9 78 4.1.2. Scenario II - Extended or Virtual Trunk.......................10 79 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE......11 80 4.2. Application Scenarios Requiring Inter-AS Resource Optimization..12 81 4.2.1. Scenario IV - TE across multi-AS within a Single SP 82 Administrative Domain.........................................12 83 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport..13 84 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering......14 85 5.1. Requirements within one SP Administrative Domain................14 86 5.1.1. Inter-AS MPLS TE Operations and Interoperability..............14 87 5.1.2. Protocol Signaling and Path Computations......................15 88 5.1.3. Optimality....................................................15 89 5.1.4. Support of diversely routed inter-AS TE LSP...................15 90 5.1.5. Re-optimization...............................................16 91 5.1.6. Fast Recovery support using MPLS TE Fast Reroute..............16 92 5.1.7. DS-TE Support.................................................17 93 5.1.8. Scalability and Hierarchical LSP Support......................17 94 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels..............17 95 5.1.10. Inter-AS MPLS TE Management..................................18 96 5.1.10.1. Inter-AS MPLS TE MIB Requirements..........................18 97 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements.............18 98 5.1.11. Extensibility................................................19 99 5.1.12. Complexity and Risks.........................................19 100 5.1.13. Backward Compatibility.......................................19 101 5.2. Requirements for Inter-AS MPLS TE across Multiple SP 102 Administrative Domains..........................................19 103 5.2.1. Confidentiality...............................................19 104 5.2.2. Policy Control................................................20 105 5.2.2.1. Inter-AS TE Agreement Enforcement Polices...................20 106 5.2.2.2. Inter-AS TE Rewrite Policies................................21 107 5.2.2.3 Inter-AS Traffic Policing....................................21 108 6. Evaluation Criteria...............................................22 109 6.1. Detailed Requirement Satisfactions..............................22 110 6.2. Performance.....................................................22 111 7. Security Considerations...........................................22 112 8. Acknowledgement...................................................22 113 9. Editor's Addresses................................................23 114 10. Normative References.............................................23 115 11. Informative References...........................................24 116 12. Full Copyright Statement.........................................25 117 Appendix A. Brief Description of BGP based Inter-AS Traffic 118 Engineering..............................................26 120 1. Introduction 122 The MPLS Traffic Engineering mechanism documented in [TE-RSVP] may 123 be deployed by Service Providers to achieve some of the most 124 important objectives of network traffic engineering as described in 125 [TE-OVW]. These objectives are summarized as listed below: 127 - Supporting end-to-end services requiring QoS guarantees 128 - Performing network resource optimization 129 - Providing fast recovery 131 However, this traffic engineering mechanism can only be used within 132 an Autonomous System (AS). 134 This document discusses requirements for an inter-AS MPLS Traffic 135 Engineering mechanism that may be used to achieve the same set of 136 objectives across AS boundaries within or beyond SPs'administrative 137 domains. 139 The document will also present a set of application scenarios where 140 the inter-AS traffic engineering mechanism may be required. 142 These application scenarios will also be used to further facilitate 143 the discussions for a list of detailed requirements for such an 144 inter-AS Traffic Engineering mechanism along with the evaluation 145 criteria for any technical solution(s) meeting these requirements. 147 Please note that there are other means of traffic engineering 148 including IGP metrics based (for use within an AS) and BGP attribute 149 based (for use across ASes; see Appendix A) traffic engineering 150 mechanisms. However, these means offer coarser control of traffic 151 paths, and do not readily offer bandwidth guarantees or fast 152 restoration, and therefore will not be discussed further in this 153 document. 155 This document doesn't make any claims with respect to whether it is 156 possible to have a practical solution that meets all the 157 requirements listed in this document. 159 2. Contributing Authors 161 This document was the collective work of several. The text and 162 content of this document was contributed by the editors and the 163 co-authors listed below (The contact information for the editors 164 appears in section 9, and is not repeated below.): 166 Kenji Kumaki 167 KDDI Corporation 168 Garden Air Tower 169 Iidabashi, Chiyoda-ku, 170 Tokyo 102-8460, 171 JAPAN 172 E-mail : ke-kumaki@kddi.com 174 Paul Mabey 175 Qwest Communications 176 950 17th Street, 177 Denver, CO 80202 178 USA 179 Email: pmabey@qwest.com 181 Nadim Constantine 182 Infonet Services Corporation 183 2160 E. Grand Ave. 184 El Segundo, CA 90025 185 USA 186 Email: nadim_constantine@infonet.com 188 Pierre Merckx 189 EQUANT 190 1041 route des Dolines - BP 347 191 06906 SOPHIA ANTIPOLIS Cedex 192 FRANCE 193 Email: pierre.merckx@equant.com 195 Ting Wo Chung 196 Bell Canada 197 181 Bay Street, Suite 350 198 Toronto, Ontario, Canada, M5J 2T3 199 Email: ting_wo.chung@bell.ca 201 Jean-Louis Le Roux 202 France Telecom 203 2, avenue Pierre-Marzin 204 22307 Lannion Cedex 205 France 206 E-mail: jeanlouis.leroux@francetelecom.com 207 Yonghwan Kim 208 SBC Laboratories, Inc. 209 4698 Willow Road 210 Pleasanton, CA 94588 211 USA 212 Email: Yonghwan_Kim@labs.sbc.com 214 3. Definitions and Requirements Statement 216 3.1. Definitions 218 The following provides a list of abbreviations or acronyms 219 specifically pertaining to this document: 221 SP: Service Providers including regional or global providers 223 SP Administrative Domain: a single SP administration over a network 224 or networks that may consist of one AS or 225 multiple ASes. 227 IP-only networks: SP's network where IP routing protocols such as 228 IGP/ BGP are activated 230 IP/MPLS networks: SP's network where MPLS switching capabilities and 231 signaling controls (e.g. ones described in 232 [MPLS-ARCH]) are activated in addition to IP 233 routing protocols. 235 Intra-AS TE: A generic definition for traffic engineering mechanisms 236 operating over IP-only and/ or IP/MPLS network within an 237 AS. 239 Inter-AS TE: A generic definition for traffic engineering mechanisms 240 operating over IP-only and/ or IP/MPLS network across 241 one or multiple ASes. 243 TE LSP: MPLS Traffic Engineering Label Switched Path 245 Intra-AS MPLS TE: An MPLS Traffic Engineering mechanism where its 246 TE LSPs Head-end LSR and Tail-end LSR reside in 247 the same AS for traffic engineering purposes. 249 Inter-AS MPLS TE: An MPLS Traffic Engineering mechanism where its 250 TE LSPs Head-end LSR and Tail-end LSR do not 251 reside within the same AS or both Head-end LSR and 252 Tail-end LSR are in the same AS but the TE LSP 253 transiting path may be across different ASes 255 ASBR Routers: Border routers used to connect to another AS of a 256 different or the same Service Provider via one or more 257 links inter-connecting between ASes. 259 Inter-AS TE Path: An TE path traversing multiple ASes and ASBRs, 260 e.g. AS1-ASBR1-inter-AS link(s)-ASBR2-AS2... 261 ASBRn-ASn. 263 Inter-AS TE Segment: A portion of the Inter-AS TE path. 265 CE: Customer Edge Equipment 267 PE: Provider Edge Equipment that has direct connections to CEs. 269 P: Provider Equipment that has backbone trunk connections only. 271 VRF: Virtual Private Network (VPN) Routing and Forwarding Instance. 273 PoP: Point of presence or a node in SP's network. 275 SRLG: A set of links may constitute a 'shared risk link group' 276 (SRLG) if they share a resource whose failure may affect all 277 links in the set as defined in [GMPLS-ROUT]. 279 Please note that the terms of CE, PE and P used throughout this 280 document are generic in their definitions. In particular, whenever 281 such acronyms are used, it does not necessarily mean that CE is 282 connected to a PE in a VRF environment described in such IETF drafts 283 as [BGP-MPLSVPN]. 285 3.2. Objectives and Requirements of Inter-AS Traffic Engineering 287 As mentioned in section 1 above, some SPs have requirements for 288 achieving the same set of traffic engineering objectives as 289 presented in [TE-OVW] across AS boundaries. 291 This section examines these requirements in each of the key 292 corresponding areas: 1) Inter-AS bandwidth guarantees; 2) 293 Inter-AS Resource Optimization and 3) Fast Recovery across ASes, 294 i.e. Recovery of Inter-AS Links/SRLG and ASBR Nodes. 296 3.2.1. Inter-AS Bandwidth Guarantees 298 The DiffServ IETF working group has defined a set of mechanisms 299 described in [DIFF_ARCH], [DIFF_AF] and [DIFF_EF] or [MPLS-Diff] 300 that can be activated at the edge or over a DiffServ domain to 301 contribute to the enforcement of a (set of) QoS policy(ies), which 302 can be expressed in terms of maximum one-way transit delay, 303 inter-packet delay variation, loss rate, etc. 305 Many SPs have some or full deployment of Diffserv implementations in 306 their networks today, either across the entire network or at the 307 least, on the edge of the network across CE-PE links. 309 In situations where strict QOS bounds are required, admission 310 control inside the backbone of a network is in some cases required 311 in addition to current Diffserv mechanisms. 313 When the propagation delay can be bounded, the performance targets, 314 such as maximum one-way transit delay may be guaranteed by providing 315 bandwidth guarantees along the Diffserv-enabled path. 317 One typical example of this requirement is to provide bandwidth 318 guarantees over an end-to-end path for VoIP traffic classified as EF 319 (Expedited Forwarding [DIFF_EF]) class in a Diffserv-enabled 320 network. When the EF path is extended across multiple ASes, 321 inter-AS bandwidth guarantee is then required. 323 Another case for inter-AS bandwidth guarantee is the requirement for 324 guaranteeing a certain amount of transit bandwidth across one or 325 multiple ASes. 327 Several application scenarios are presented to further illustrate 328 this requirement in section 4 below. 330 3.2.2. Inter-AS Resource Optimization 332 In Service Provider (SP) networks, the BGP protocol [BGP] is 333 deployed to exchange routing information between ASes. The inter-AS 334 capabilities of BGP may also be employed for traffic engineering 335 purposes across the AS boundaries. Appendix A provides a 336 brief description of the current BGP-based inter-AS traffic 337 engineering practices. 339 SPs have managed to survive with this coarse set of BGP-based 340 traffic engineering facilities across inter-AS links in a largely 341 best effort environment. Certainly in many cases ample bandwidth 342 within SP's network and across inter-AS links reduces the need for 343 more elaborated inter-AS TE policies. 345 However, in the case where a SP network is deployed over multiple 346 ASes, for example, as the number of inter-AS links grows, the 347 complexity of the inter-AS policies and the difficulty in inter-AS 348 TE path optimization increase to a level such that it may soon 349 become unmanageable. 351 Another example is where inter-AS links are established between 352 different SP administrative domains. Un-deterministic factors such 353 as un-coordinated routing and network changes as well as sub-optimum 354 traffic conditions would potentially lead to a complex set of 355 Inter-AS traffic engineering policies where current traffic 356 engineering mechanisms would probably not scale well. 358 In these situations where resource optimization is required and/ or 359 specific routing requirements arise, the BGP-based inter-AS 360 facilities will need to be complemented by a more granular inter-AS 361 traffic engineering mechanism. 363 3.2.3. Fast Recovery across ASes 365 When extending services such as VoIP across ASes, customers often 366 demands SPs to maintain the same level of performance targets such 367 as packet loss and service availability as ones that can be achieved 368 within an AS. As a consequence, fast convergence in a stable 369 fashion upon link/SRLG/node failures becomes a strong requirement. 370 This is clearly difficult to achieve with current inter-domain 371 techniques, especially in cases of link/SRLG failures between ASBRs 372 or ASBR node failures. 374 3.3. Inter-AS Traffic Engineering Requirements Statement 376 Just as in the applicable case of deploying MPLS TE in a SP's 377 network, an inter-AS TE method in addition to BGP-based traffic 378 engineering capabilities needs to be deployed across inter-AS links 379 over where resource optimization, QOS guarantees and fast recovery 380 are required. 382 This is especially critical in a Diffserv-enabled, multi-class 383 environment described in [PSTE] where statistical performance 384 targets must be maintained consistently over the entire path 385 across different ASes. 387 The approach of extending current intra-AS MPLS TE capabilities 388 [TE-RSVP] across inter-AS links for IP/MPLS networks is considered 389 here because of already available implementations and operational 390 experiences. 392 Please note that the inter-AS traffic engineering over an IP-only 393 network is for future consideration since there is no sufficient 394 interest for similar requirements to those of IP/MPLS networks 395 at this time. More specifically, this document only covers the 396 inter-AS TE requirements for packet based IP/MPLS networks. 398 4. Application Scenarios 400 The following sections present a few application scenarios over 401 IP/MPLS networks where requirements cannot be addressed with current 402 intra-AS MPLS TE mechanism and give rise to considerations for 403 inter-AS MPLS traffic engineering requirements. 405 Although not explicitly noted in the following discussions, fast 406 recovery of traffic path(s) crossing multiple ASes in a stable 407 fashion is particularly important in case of link/SRLG/node failures 408 at AS boundaries for all application scenarios presented here. 410 4.1. Application Scenarios Requiring Inter-AS Bandwidth Guarantees 412 4.1.1 Scenario I - Extended or Virtual PoP (VPoP) 414 A global service provider (SP1), for example would like to expand 415 its reach in a region where a regional service provider's (SP2) 416 network has already established an extended coverage in its PoP 417 density. 419 In this scenario, the SP1 may establish interconnections with SP2 in 420 one or multiple points in that region. It may then use SP2's 421 network as an extended transport by co-locating aggregation routers 422 in some SP2's PoPs that are in the regions where SP1 has a larger 423 number of customer sites. 425 In order to ensure bandwidth capacity provided by SP2 and achieve 426 some degrees of transparency to SP2's network changes in terms of 427 capacity and network conditions, one or more Inter-AS MPLS TE 428 trunk(s) can be built between SP1's ASBR or PE router inside AS1 and 429 SP1's PE routers co-locating in SP2's PoPs, as illustrated in the 430 diagram below: 432 <===========Inter-AS MPLS TE Tunnel===========> 433 ----- ----- 434 ________|ASBR |___Inter-AS___|ASBR |________ 435 | | RTR | Link | RTR | | 436 ---- ----- ----- ----- ----- 437 |SP1 |_____| SP2 | | SP1 | 438 |VPoP| |P/PE | |P/PE | 439 ---- ----- ----- ----- ----- 440 |________|ASBR |___Inter-AS___|ASBR |________| 441 | RTR | Link | RTR | 442 ----- ----- 443 <=================Inter-AS MPLS TE Tunnel=================> 444 +-SP1 AS1-+ +-------SP2 AS2-----+ +------SP1 AS1------+ 446 In situations where end-to-end Diffserv paths must be maintained, 447 both SP's networks may need to provision Diffserv PHB at each hop 448 supporting a set of traffic classes with compatible performance 449 targets. The subsequent issues regarding Service Level Agreement 450 (SLA) boundaries, reporting and measuring system inter-operability 451 and support demarcations are beyond the scope of this document and 452 will therefore not be discussed here. 454 Note also that either the SP1 or SP2 network may not be a 455 Diffserv-aware network. The scenario would still apply to provide 456 bandwidth guarantees. 458 The SP2, on the other hand, can similarly choose to expand its reach 459 beyond its servicing region over SP1's network via inter-AS MPLS 460 TE paths. 462 It is worth mentioning that these remote aggregation routers 463 co-located in other SP's network will unlikely participate in 464 hosting SP's IGP and BGP routing planes and will most likely 465 maintain its own AS or be part of the SP1's AS. In this case, such 466 TE tunnels may cross several ASes, but the Head-end and Tail-end 467 LSRs of TE tunnel may have the same AS number, as shown in the 468 diagram above. 470 4.1.2. Scenario II - Extended or Virtual Trunk 472 Instead of co-locating a PE router in SP2's PoP, SP1, for example 473 may also choose to aggregate customer VPN sites onto a SP2's PE 474 router where inter-AS TE tunnels can be built and signaled through 475 SP2's MPLS network between the SP2 PoP (to which SP1 customer CEs 476 are directly connected) and SP1's ASBR or PE routers inside SP2's 477 network. This allows SP1�s customers connected to SP2 PE router to 478 receive a guaranteed bandwidth service up to the TE LSP tail-end 479 router located in SP1's network. 481 In this scenario, there could be two applicable cases: 483 Case 1 - the inter-AS MPLS TE tunnel functions as an extended or 484 virtual trunk aggregating SP1 CE's local-loop access circuits on 485 SP2's MPLS network over which the bandwidth can be guaranteed to the 486 TE LSP tail-end router located in SP1�s network, as shown in the 487 diagram below: 489 <====Inter-AS MPLS TE Tunnel====> 490 or 491 < ===Inter-AS MPLS TE Tunnel===============> 493 ---- ----- ----- ----- ----- 494 | CE |_____Local___| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | 495 | | Loop | PE | | RTR | Link | RTR | |PE | 496 ---- ----- ----- ----- ----- 498 +SP1 Customer AS3+ +-----SP2 AS2---+ +-SP1 AS1-------+ 500 Case 2 - the inter-AS MPLS TE tunnel in this case functions as an 501 extended or virtual local access link from SP1's CE on SP2's network 502 to the SP1's ASBR or PE: 504 <==============Inter-AS MPLS TE Tunnel==============> 505 or 506 <==============Inter-AS MPLS TE Tunnel========================> 508 ---- ----- ----- ----- ----- 509 | CE |____Local_____| SP2 |___|ASBR |___Inter-AS___|ASBR |___|SP1 | 510 | | Loop | PE | | RTR | Link | RTR | |PE | 511 ---- ----- ----- ----- ----- 513 +SP1 Customer AS3+ +------SP2 AS2---+ +--SP1 AS1-----+ 514 In case 2 above, SP2 may elect to establish an aggregating or 515 hierarchical intra-AS MPLS TE tunnel between the transiting P or PE 516 router and SP2's ASBR router just to reduce the number of tunnel 517 states signaled from the SP2 PE to where SP1's CEs are connected. 519 4.1.3. Scenario III - End-to-end Inter-AS MPLS TE From CE to CE 521 In this scenario as illustrated below, customers require to 522 establish MPLS TE tunnel from CE1 to CE2 end-to-end across several 523 SP's networks. One application example would be the guaranteed 524 bandwidth for voice- or video-over-IP services. 526 <======================Inter-AS MPLS TE Tunnel==================> 528 --- ----- ----- ----- ----- --- 529 |CE1|_____| SP2 |___|ASBR |__Inter-AS__|ASBR |____| SP1 |_____|CE2| 530 | | | PE | | RTR | Link | RTR | | PE | | | 531 --- ----- ----- ----- ----- --- 533 +Cust AS1+ +---SP2 AS-----+ +-------SP1 AS-------+ +Cust ASx+ 535 The diagram below illustrates another example where CE1 and CE2 are 536 customers of SP1 with eBGP peering relationships established across 537 the CE-PE links. A inter-AS MPLS TE tunnel may then be established 538 from CE1 in AS1 to CE2 which may belong to the same AS or different 539 AS than that of CE1 across SP1's network in AS2. 541 <===============Inter-AS MPLS TE Tunnel=====================> 543 --- ----- ---- ---- ----- --- 544 |CE1|______| SP1 |_____|SP1 |____|SP1 |____| SP1 |_________|CE2| 545 | | | PE1 | |P1 | |P2 | | PE2 | | | 546 --- ----- ---- ---- ----- --- 548 +-Cust AS1-+ +-------------SP1 AS2----------------+ +-Cust ASx-+ 550 The above example shows that SP1's network has a single AS. 551 Obviously, there may be multiple ASes between CE1 and CE2 as well in 552 the SP1's network. 554 In addition, where both CE1 and CE2 residing in the same AS, they 555 likely share the same private AS number. 557 Scenario III however, will not scale well should there be a larger 558 number of inter-AS TE MPLS tunnels in some degrees of partial mesh 559 or full mesh. Therefore, it is expected that this scenario will 560 not have a large number of deployments, unless some mechanisms such 561 as hierarchical intra-AS TE-LSPs are used to reduce the number of 562 signaling states 564 4.2. Application Scenarios Requiring Inter-AS Resource Optimization 566 The scenarios presented in this section mainly deal with inter-AS 567 resource optimization. 569 4.2.1. Scenario IV - TE across multi-AS within a Single SP 570 Administrative Domain 572 As mentioned in [TE-APP], SPs have generally admitted that the 573 current MPLS TE mechanism provides a great deal of tactical and 574 strategic values in areas of traffic path optimization [TE-RSVP] and 575 rapid local repair capabilities [TE-FRR] via a set of on-line or 576 off-line constraint-based searching algorithms. 578 From a service provider's perspective, another way of stating the 579 objectives of traffic engineering is to be able to deliver more 580 customer traffic with already available capacity in the network 581 without violating performance targets, and/ or to provide better QOS 582 services via an improved network utilization, operating more likely 583 below congestion thresholds. 585 It is worth noting that situations where resource provisioning is 586 not an issue, e.g. low density in inter-AS connectivity or ample 587 inter-AS capacity may not require more scalable and granular TE 588 facilities beyond BGP routing policies since such policies could be 589 rather simple and because inter-AS resource optimization is not an 590 absolute requirement. 592 However many SPs, especially those with networks across multiple 593 continents as well as sparsely connected, have designed their 594 multi-AS routing policies, for example, along or within the 595 continental or sub-continental boundaries where the number of ASes 596 can range from a very few to dozens. Generally, inter-continent or 597 sub-continent capacity is very expensive. Some Service Providers 598 have multiple ASes in the same country and would like to optimize 599 resources over their inter-region links. This would demand a 600 more scalable degree of resource optimization, which warrants the 601 consideration of extending current intra-AS MPLS TE capabilities 602 across inter-AS links. 604 In addition, one may only realize higher efficiency in conducting 605 traffic optimization and path protection/ restoration planning when 606 coordinating all network resources (not partially) as a whole. For 607 a network which may consist of many ASes, this could be realized via 608 the establishment of inter-AS TE LSPs as shown in the diagragm 609 below: 611 <===================Inter-AS MPLS Tunnel=============> 612 -------- -------- -------- 613 | |_______________| |____________| | 614 | SP1 |_______________| SP1 |____________| SP1 | 615 | AS1 |_______________| AS2 |____________| AS3 | 616 | | | | | | 617 -------- -------- -------- 618 || || 619 || --------- || 620 ||___________________| SP1 |________________|| 621 |____________________| AS4 |_________________| 622 | | 623 --------- 624 The motivation for inter-AS MPLS TE is even more prominent in a 625 Diffserv-enabled network over which statistical performance targets 626 are to be maintained from any point to any point of the network as 627 illustrated in the diagram below with an inter-AS DS-TE LSP: 629 <===================Inter-AS MPLS DS-TE Tunnel=============> 630 ---- ----- ----- ----- ----- ---- 631 | PE |__| P |___|ASBR |___Inter-AS___|ASBR |___|P |___|PE | 632 | RTR| | RTR | | RTR | Link | RTR | |RTR | |RTR | 633 ---- ----- ----- ----- ----- ---- 634 +------------SP1 AS1---------+ +------------SP1 AS2------+ 636 For example , the inter-AS MPLS DS-TE LSP shown in the diagram above 637 could be used to transport a set of L2 Pseudo Wires or VoIP traffic 638 with corresponding QoS requirement. 640 Furthermore, fast recovery in case of ASBR-ASBR link failure or ASBR 641 node failure is a strong requirement for such services. 643 4.2.2. Scenario V - Transit ASes as Primary and Redundant Transport 645 Scenario V presents another possible deployment case. SP1 with AS1 646 wants to link a regional network to its core backbone by building an 647 inter-AS MPLS TE tunnel over one or multiple transit ASes belonging 648 to SP2, SP3, etc. as shown in the following diagram: 650 <===========Inter-AS MPLS TE Tunnel=======> 651 [ ] [ ] [ ] 652 [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] 653 [ |P/PE|__|ASBR|]_Inter-AS_[|ASBR|.|ASBR|]_Inter-AS_[|ASBR| |P/PE|] 654 [ |RTR | |RTR |] Link [|RTR | |RTR |] Link [|RTR | |RTR |] 655 [ ---- ---- ] [ ---- ---- ] [ ---- ---- ] 656 [ ] [ ] [ ] 657 <================Inter-AS MPLS TE Tunnel=====================> 658 +SP1 Regional ASx+ +Transit SP2 AS2,etc...SPi ASi+ +------SP1 AS1-+ 660 This scenario can be viewed as a broader case of Scenario I shown in 661 section 4.1.1 where the "VPoP" could be expanded into a regional 662 network of SP1. By the same token, the AS number for SP1's 663 regional network ASx may be the same as or different from AS1. 665 The inter-AS MPLS TE LSP in this case may also be used to backup an 666 internal path as depicted in the diagram below, although this could 667 introduce routing complexities: 669 <===========Inter-AS MPLS TE Tunnel=======> 670 +----------------------------SP1 AS1-----------------------------+ 671 [ ] 672 [ ---- ---- ---- ---- ] 673 [ |P/PE|__|ASBR|__________Primary Intera-AS________|P | |PE |] 674 [ |RTR | |RTR | Link |RTR | |RTR |] 675 [ ---- ---- ---- ---- ] 676 [ | | ] 677 [ ---- ---- ] 678 [ |ASBR| |ASBR| ] 679 [ |RTR | |RTR | ] 680 [ ---- ---- ] 681 ^ | | ^ 682 | | | | 683 | | [ ] | | 684 | | [ ---- ---- ] | | 685 | |__ Inter-AS_[|ASBR|..|ASBR|]_Inter-AS_| | 686 | Link [|RTR | |RTR |] Link | 687 | [ ---- ---- ] | 688 | [ ] | 689 | | 690 +======Backup Inter-AS MPLS TE Tunnel======+ 691 +Transit SP2 AS2,SP3 AS3,etc....SPi ASi+ 693 5. Detailed Requirements for Inter-AS MPLS Traffic Engnineering 695 This section discusses detailed requirements for inter-AS MPLS TE in 696 two principal areas: 1) requirements for inter-AS MPLS TE in the 697 same SP administrative domain and 2) requirements for inter-AS MPLS 698 TE across different SP administrative domains. 700 5.1. Requirements within one SP Administrative Domain 702 This section presents detailed requirements for inter-AS MPLS TE 703 within the same SP administrative domain. 705 5.1.1. Inter-AS MPLS TE Operations and Interoperability 707 The inter-AS MPLS TE solution SHOULD be consistent with requirements 708 discussed in [TE-REQ] and the derived solution MUST be such that 709 it will interoperate seamlessly with current intra-AS MPLS TE 710 mechanism and inherit its capability sets from [TE-RSVP]. 712 The proposed solution SHOULD allow to provision at the Head/Tail end 713 with end-to-end RSVP signaling (eventually with loose paths) 714 traversing across the interconnected ASBRs, without further 715 provisioning required along the transit path. 717 5.1.2. Protocol Signaling and Path Computations 719 One can conceive that an inter-AS MPLS TE tunnel path signaled 720 across inter-AS links consists of a sequence of intra-AS segments. 722 The proposed solution SHOULD provide the ability to either 723 explicitly select or auto-discover the following elements 724 when signaling the inter-AS TE LSP path: 726 - a set of AS numbers as loose HoPs 727 - a set of LSRs including ASBRs 729 and to specify the above elements in the ERO and record them in the 730 RRO of the Resv message just to keep track of the set of ASes or 731 ASBRs traversed by the inter-As TE LSP. 733 In the case of establishing inter-AS TE LSP traversing multiple ASes 734 within the same SP networks, the solution SHOULD also allow the 735 Headend LSR to explicitly specify the hops across anyone of 736 the transiting ASes and the TE tunnel headhend SHOULD also check 737 the explicit segment to make sure that the constrainsts are met. 739 In addition, The proposed solution SHOULD also provide the ability 740 to specify and signal that certain loose or explicit nodes (e.g. AS 741 numbers, etc.) and resources to be explicitly excluded in the 742 inter-AS TE LSP path establishment, such as one defined in 743 [EXCLUDE-ROUTE] for instance. 745 5.1.3 Optimality 747 The solution SHOULD allow the set up of an inter-AS TE LSP that 748 complies with a set of TE constraints defined in [TE-REQ]) and 749 follow an optimal path. 751 An optimal path is defined as a path whose end-to-end cost is 752 minimal, based upon either an IGP or a TE metric. Note that in 753 the case of an inter-AS path across several ASes having completely 754 different IGP metric policies, the notion of minimal path might 755 require IGP metric normalization, for example. 757 The solution SHOULD provide mechanism(s) to compute and establish an 758 optimal end-to-end path for the inter-AS TE LSP and SHOULD also 759 allow for reduced suboptimality since the path may not remain 760 optimal for the life-time of the LSP 762 5.1.4 Support of diversely routed inter-AS TE LSP 764 In some cases it might be desirable to set up multiple inter-AS TE 765 LSPs between a pair of LSRs, when: 767 (1) A single TE LSP satisfying the required set of constraints 768 cannot be found, in which case it may require load splitting. 770 (2) Multiple TE paths may be required to limit the impact of a 771 network element failure to a portion of the traffic. As an 772 example, two VoIP gateways may load balance the traffic among 773 a set of inter-AS TE LSPs. 775 (3) Path protection (e.g. 1:1 or 1:N) as discussed in 776 [MPLS-Recov]. 778 In the examples above, being able to set up diversely routed TE LSPs 779 becomes a requirement for inter-AS TE. 781 The solution SHOULD be able to set up a set of link/SRLG/Node 782 diversely routed inter-AS TE LSPs. 784 5.1.5. Re-optimization 786 Once an inter-AS TE LSP has been established and should there be any 787 resource or other changes inside anyone of transiting ASes, the 788 solution MUST be able to re-optimize the LSP accordingly and 789 non-disruptively, either upon expiration of a configurable timer or 790 triggered by a network event or a manual request at the TE tunnel 791 Head-end. 793 The solution SHOULD provide an option for the Head-End LSRs to 794 control if re-optimizing or not should there exist a more optimal 795 path in one of the ASes. 797 In the case of an identical set of traversed path, the solution 798 SHOULD provide an option for the Head-End LSRs to control if 799 re-optimizing or not should there exist a more optimal path in one 800 of the transit ASes along the inter-AS TE LSP path. 802 Furthermore, the solution MUST provide the ability to reject 803 re-optimizatization at AS boundaries. 805 5.1.6. Fast Recovery support using MPLS TE Fast Reroute 807 There are in general two or more inter-AS links between multiple 808 pair of ASBRs for redundancy. The topological density between ASes 809 in a SP network with multi-ASes is generally much higher. In the 810 event of an inter-AS link failure, rapid local protection SHOULD 811 also be made available and interoperate with current intra-AS MPLS 812 TE fast re-route mechanism from [TE-FRR]. 814 The traffic routed onto an inter-AS TE tunnel SHOULD also be fast 815 protected against any node failure where the node could be internal 816 to an AS or at the AS boundary. 818 5.1.7. DS-TE Support 820 The proposed inter-AS MPLS TE solution SHOULD also satisfy core 821 requirements documented in [DS-TE] and interoperate seamlessly with 822 current intra-AS MPLS DS-TE mechanism [DSTE-PROT]. 824 It is worth pointing out that the compatibility clause in section 825 4.1 of [DS-TE] SHOULD also be faithfully applied in the development 826 of the solutions. 828 5.1.8. Scalability and Hierarchical LSP Support 830 The proposed solution(s) MUST have minimum impact on the network 831 scalability from both intra and inter-AS perspectives. 833 This requirement applies to all of the following: 835 - IGP (impact in terms of IGP flooding, Path computation, etc.). 836 - BGP (impact in terms of additional information carried within 837 BGP, number of routes, flaps, overload events, etc.). 838 - RSVP TE (message rate, number of retained states, ,etc.). 840 It is also conceivable that there would potentially be scalability 841 issues as the number of required inter-AS MPLS TE tunnels increases. 842 In order to reduce the number of tunnel states to be maintained by 843 each transiting PoP, the proposed solution SHOULD allow TE LSP 844 aggregation such that individual tunnels can be carried onto one or 845 more aggregating LSP(s). One such mechanism, for example is 846 described in [MPLS-LSPHIE]. 848 5.1.9. Mapping of traffic onto Inter-AS MPLS TE Tunnels 850 There SHOULD be several possibilities to map a particular traffic 851 to a particular destination onto a specific inter-AS TE LSP. 853 For example, static routing could be used if IP destination 854 addresses are known. Another example is to utilize static routing 855 using recursive BGP route resolution. 857 In cases where inter-AS MPLS TE tunnels are terminated at P routers 858 in a PoP where there could also be multiple PE routers, the proposed 859 solution SHOULD provide the ability whereby to "announce" the 860 inter-AS MPLS TE tunnels as a link into the IGPs (ISIS or OSPF) with 861 the link's cost associated with it. By doing so, PE routers that do 862 not participate in the inter-AS TE path computation can take into 863 account such links in its IGP-based SPF computation. 865 5.1.10. Inter-AS MPLS TE Management 867 5.1.10.1. Inter-AS MPLS TE MIB Requirements 869 An inter-AS TE MIB is required for use with network management 870 protocols by SPs to manage and configure inter-AS traffic 871 engineering tunnels. This new MIB MUST extend (and not reinvent) 872 the existing MIBs to accommodate this new functionality. 874 An inter-AS TE MIB should include features, for example: 875 - the setup of inter-AS TE tunnels with associated constraints 876 (e.g. resources) 877 - the collection of traffic and performance statistics not only 878 at the tunnel Headend, but any other points of the TE tunnel. 879 - the inclusion of both IPv4/v6 + AS# or AS# subobjects in the 880 ERO in the path message, e.g: 882 EXPLICIT_ROUTE class object: 883 address1 (loose IPv4 Prefix, /AS1) 884 address2 (loose IPv4 Prefix, /AS1) 885 AS2 (AS number) 886 address3 (loose IPv4 prefix, /AS3) 887 address4 (loose IPv4 prefix, /AS3) - destination 889 or 891 address1 (loose IPv4 Prefix, /AS1) 892 address2 (loose IPv4 Prefix, /AS1) 893 address3 (loose IPv4 Prefix, /AS2) 894 address4 (loose IPv4 Prefix, /AS2) 895 address5 (loose IPv4 prefix, /AS3) 896 address6 (loose IPv4 prefix, /AS3) - destination 898 - Similarly, the inclusion of the RRO object in the resv. message 899 recording subojects such as interface IPv4/v6 address (if not 900 hidden), AS number, a label, a node-id (when required), etc. 901 - inter-AS specific attributes as discussed in section 5 of this 902 document including, for example inter-AS MPLS TE tunnel 903 accounting records across each AS segment. 905 5.1.10.2. Inter-AS MPLS TE Fault Management Requirements 907 In a MPLS network, a SP wants to detect both control plane and data 908 plane failures. But tools for fault detection over LSPs haven't 909 been widely developed so far. SPs today manually troubleshoot such 910 failures in a hop-by-hop fashion across the data path. If they 911 detect an error on the data plane, they have to check the control 912 plane in order to determine where the faults come from. 914 The proposed solution SHOULD be able to interoperate with fault 915 detection mechanisms of intra-AS TE and MAY or MAY NOT require the 916 inter-AS TE tunnel ending addresses to be known or routable across 917 IGP areas (OSPF) or levels(IS-IS) within the transiting ASes with 918 working return paths. 920 For example, [LSPPING] is being considered as a failure detection 921 mechanism over the data plane against the control plane and could 922 be used to troubleshoot intra-AS TE LSPs. Such facilities, if 923 adopted, SHOULD then be extended to inter-AS TE paths. 925 The above example, however depicts one such mechanism that does 926 require a working return path such that diagnostic test packets can 927 return via an alternate data plane, such as a global IPv4 path in 928 the event that the LSP is broken. 930 [MPLS-TTL] presents how TTL may be processed across a hierarchical 931 MPLS networks and such a facility as this SHOULD also be extended 932 to inter-AS TE links. 934 5.1.11. Extensibility 936 The solution(s) MUST allow extensions as both inter-AS MPLS TE and 937 current intra-AS MPLS TE specifications evolve. 939 5.1.12. Complexity and Risks 941 The proposed solution(s) SHOULD not introduce unnecessary complexity 942 to the current operating network to such a degree that it would 943 affect the stability and diminish the benefits of deploying such a 944 solution over SP networks. 946 5.1.13. Backward Compatibility 948 The deployment of inter-AS MPLS TE SHOULD not have impact on 949 existing BGP-based traffic engineering or MPLS TE mechanisms to 950 allow for a smooth migration or co-existence. 952 5.2. Requirements for Inter-AS MPLS TE across Multiple SP 953 Administrative Domains. 955 The requirements for inter-AS MPLS TE across multiple SP admin 956 domains SHOULD include all requirements discussed in section 5.1 957 above in addition to what are presented in this section here. 959 Please note that the SP with multi-AS networks may choose not to 960 turn on the features discussed in the following two sections when 961 building TE tunnels across ASes in its own domain. 963 5.2.1. Confidentiality 965 Since an inter-AS TE LSP may span multiple ASes belonging to 966 different SPs, the solution MIGHT allow to "hide" the set of hops 967 used by the TE LSP within an AS as illustrated in the following 968 example: 970 [ ASBR1-----ASBR2 ] 971 [ ] [ ] 972 [ A ] [ B ] 973 [ AS1 ] [ AS2 ] 974 [ SP1 ]-----[ SP2 ] 975 [ ] [ ] 977 Suppose there is an inter-AS TE LSP from A (within AS1 of SP1) to B 978 (within AS2 of SP2). When computing an inter-AS TE LSP path, the 979 set of hops within AS2 might be hidden to AS1. In this case, the 980 solution will allow A to learn that the more optimal TE LSP path to 981 B that complies with the set of constraints traverses ASBR2 without 982 a detailed knowledge of the lists of the hops used within AS2. 984 Optionally, the TE LSP path cost within AS2 could be provided to A, 985 via for example PCC-PCS signaling [PATH-COMP], such that A (PCC) 986 could use this information to compute an optimal path, even if the 987 computed path is not provided by AS2. 989 In addition, the management requirements discussed in section 5.1.10 990 above, when used across different SP admin domains, SHOULD include 991 similar confidentiality requirements discussed here in terms of 992 "hiding" intermediate hops or interface address and/ or labels in 993 the transiting or peering SPs. 995 5.2.2. Policy Control 997 In some cases, policy control might be necessary at the AS 998 boundaries, namely ingress policy controls enabling SPs to enforce 999 the inter-AS policies per interconnect agreements or modify some 1000 requested parameters conveyed by incoming inter-AS MPLS TE signaling 1001 requests. 1003 It is worth noting that such policy control mechanism may also be 1004 used between ASes within a SP. 1006 This section only discusses the elements that may be used to form a 1007 set of ingress control policies. However, how exactly SPs establish 1008 bilateral or multilateral agreements upon which the control policies 1009 can be built are beyond the scope of this document. 1011 5.2.2.1. Inter-AS TE Agreement Enforcement Polices 1013 The following provides a set of TE-LSP parameters in the inter-AS TE 1014 requests(RSVP Path Message) that could be enforced at the AS 1015 boundaries: 1017 - RSVP-TE session attributes: affinities and preemption 1018 priorities 1019 - Per AS or SP bandwidth admission control to ensure that RSVP-TE 1020 messages do not request for bandwidth resources over their 1021 allocation. 1023 - Request origins which can be represented by HE tunnel ending IP 1024 address, originating AS#, neighbor AS#, neighbor ASBR interface 1025 IP address, etc. 1026 - DS-TE TE-Class . 1027 - FRR attribute: local protection desired bit, node protection 1028 desired bit and bandwidth protection desired bit carried in the 1029 SESSION 1030 - ATTRIBUTE or the FAST-REROUTE objects in the RSVP Path message 1031 as defined in [TE-FRR]. 1032 - Optimization allowed or not. 1034 In some cases, a TE policy server could also be used for the 1035 enforcement of inter-AS TE policies. This requirement could allow 1036 SPs to make the inter-AS TE policies scale better. 1038 The signaling of a non policy compliant request SHOULD trigger the 1039 generation of a RSVP Path Error message by the policy enforcing 1040 node towards the Head-end LSR, indicating the cause. The 1041 Head-end LSR SHOULD take appropriate actions, such as re-route, upon 1042 receipt of such a message. 1044 5.2.2.2. Inter-AS TE Rewrite Policies 1046 In some situations, SPs may need to rewrite some attributes of the 1047 incoming inter-AS TE signaling requests due to for example, a lack 1048 of resources for a particular TE-Class, non compliant preemption, 1049 upon mutual agreements. The following lists a set of parameters 1050 that can potentially be rewritten at the AS boundaries: 1052 - RSVP-TE session attributes: affinities and preemption 1053 priorities 1054 - DS-TE TE-Class . 1055 - ERO expansion requests 1057 Simimarly, the re-writing node SHOULD generate a RSVP Path Error 1058 Message towards the Head-end LSR indicating the cause in terms 1059 of types of changes made so as to maintain the end-to-end integrity 1060 of inter-AS TE LSP. 1062 5.2.2.3 Inter-AS Traffic Policing 1064 The proposed solution SHOULD also provide a set of policing 1065 mechanisms which could be configured on the inter-AS links, 1066 to ensure that traffic routed through the tunnel does not exceed 1067 the bandwidth negotiated during LSP signaling. 1069 For example, an ingress policer could be configured to enforce 1070 the traffic contract on the mutually agreed resource requirements 1071 of the established inter-AS TE LSP (i.e. RSVP bandwidth) on the 1072 interface to which the inter-AS link is connected. 1074 6. Evaluation Criteria 1076 There may be multiple solutions to satisfy the requirements for 1077 Inter-AS MPLS TE presented in previous sections. 1079 This section provides general guidelines, which could be applied in 1080 the selection of an optimum solution. 1082 6.1. Detailed Requirement Satisfactions 1084 The proposed solution SHOULD include at least all of the 1085 Application Scenarios presented in section 4 above. It MUST meet all 1086 the requirements described in section 5 each time a MUST is 1087 specified. 1089 If a solution can fulfill just a subset of those requirements in 1090 section 5, then it MUST be explicitly documented 1092 6.2. Performance 1094 The solution SHOULD be evaluated taking into account various 1095 performance criteria: 1097 - Degree of path optimality of the inter-AS TE LSP path 1098 - TE LSP setup time. 1099 - Fail and restoration time 1100 - Impact and scalability of the control plane due to added 1101 overheads, etc. 1102 - Impact and scalability of the data/forwarding plane due to 1103 added overheads, etc. 1105 Other criteria might be added as this draft will evolve. 1107 7. Security Considerations 1109 The proposed solution(s) MUST address security issues across 1110 multiple SP administrative domains. Although inter-AS MPLS TE is 1111 not expected to add specific security extensions beyond those of 1112 current intra-AS TE, greater considerations MUST be given in terms 1113 of how to establish a trusted model across AS boundaries. SPs 1114 SHOULD have a means to authenticating, such as using RSVP INTEGRITY 1115 object, allowing and possibly denying inter-AS signaling requests 1116 and SHOULD be protected from DoS attacks. 1118 8. Acknowledgement 1120 We would like to thank Yuichi Ikejiri, David Allan, Kurt Erik 1121 Lindqvist, Dave McDysan, Christian Jacquenet, Kireeti Kompella, 1122 Ed Kern, Jim Boyle, Thomas Nadeauor and Yakov Rekhter for their 1123 suggestions and helpful comments during the discussions of this 1124 draft. 1126 9. Editor's Addresses 1128 Raymond Zhang 1129 Infonet Services Corporation 1130 2160 E. Grand Ave. 1131 El Segundo, CA 90025 1132 USA 1133 Email: raymond_zhang@infonet.com 1135 JP Vasseur 1136 CISCO Systems, Inc. 1137 300 Beaver Brook Road 1138 Boxborough , MA - 01719 1139 USA 1140 Email: jpv@cisco.com 1142 10. Normative References 1144 [TE-REQ], Awduche et. al., "Requirements for Traffic Engineering 1145 over MPLS", RFC2702, September 1999. 1147 [TE-RSVP], Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP 1148 Tunnels", RFC 3209, December 2001 1150 [GMPLS-ROUT], Kompella, et. al., "RGeneralized Multi-Protocol Label 1151 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1152 Engineering (RSVP-TE) Extensions, RFC 3473, January 2003. 1154 [BGP], Rekhter, et. al., "A Border Gateway Protocol 4 (BGP-4)", 1155 RFC 1771, March 1995 1157 [LSPPING], Kompella, et.. al.," Detecting Data Plane Liveliness in 1158 MPLS", Internet Draft , June 2003, 1159 (Work in Progress) 1161 [MPLS-TTL], Agarwal, et. al., "Time to Live (TTL) Processing in MPLS 1162 Networks", RFC 3443, January, 2003 1164 [DS-TE], Le Faucheur, et. al., ''Requirements for support of 1165 DiffServ-aware MPLS Traffic Engineering'', RFC 3564, July, 2003 1167 [DSTE-PROT], Le Faucheur, et. al., "Protocol extensions for support 1168 of Diff-Serv-aware MPLS Traffic Engineering", draft-ietf-tewg-diff 1169 -te-proto-05.txt, September, 2003 (Work in Progress). 1171 [TE-FRR], Pan, et. al., "Fast Reroute Techniques in RSVP-TE", 1172 draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, June 2003 1173 (Work in Progress). 1175 [ISIS-TE], Smit, Li, "IS-IS extensions for Traffic Engineering", 1176 draft-ietf-isis-traffic-05.txt, August, 2003 (Work in Progress). 1178 [OSPF-TE] Katz, Yeung, "Traffic Engineering Extensions to OSPF", 1179 draft-ietf-ospf-ospfv3-traffic-01.txt, June, 2001 1180 (Work in Progress). 1182 [PATH-COMP], Vasseur, et. al., ''RSVP Path computation request and 1183 reply messages'', draft-vasseur-mpls-computation-rsvp-03.txt, June 1184 2002. (Work in Progress) 1186 [OSPF-TE-CAP], Vasseur, Psenak. "OSPF TE TLV capabilities", 1187 draft-vasseur-mpls-ospf-te-cap-00.txt, October 2002. 1188 (Work in Progress) 1190 [MPLS-LSPHIE] Kompella, Rekhter, "LSP Hierarchy with Generalized 1191 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt , March 2002. 1192 (work in progress) 1194 [MPLS-Recov], Sharma V., et al, "Framework for Multi-Protocol Label 1195 Switching (MPLS)-based Recovery", RFC 3469, Feb, 2003 1197 [BGP-Label], Rekhter and Rosen, "Carrying Label Information in 1198 BGP-4", RFC 3107, May 2001 1200 [INTER-AS-TE], Vasseur and Zhang, "Inter-AS MPLS Traffic 1201 Engineering", draft-vasseur-inter-as-te-01.txt, June, 2003 (work 1202 in progress). 1204 [EXCLUDE-ROUTE], Farrel, et. al., "draft-ietf-ccamp-rsvp-te-exclude 1205 -route-00.txt", June 2003 (work in progress). 1207 11. Informative References 1209 [MPLS-ARCH], Rosen, et. al., "Multiprotocol Label Switching 1210 Architecture", RFC 3031, January 2001 1212 [BGP-MPLSVPN], Rosen, et. al., "BGP/MPLSVPN", draft-ietf-l3vpn 1213 -rfc2547bis-01.txt, July 2002 (work in progress). 1215 [DIFF_ARCH], Blake, et. al., "An Architecture for Differentiated 1216 Services", RFC 2475, December 1998. 1218 [DIFF_AF], Heinanen,et. al., "Assured Forwarding PHB Group", RFC 1219 2597, June 1999. 1221 [DIFF_EF], Davie, et. al., "An Expedited Forwarding PHB (Per-Hop 1222 Behavior)", RFC 3246, March 2002. 1224 [MPLS-Diff], Le Faucheur, et. al., "MPLS Support of Differentiated 1225 Services", RFC 3270, May 2002 1227 [TE-OVW], Awduche, et. al., "Overview and Principles of Internet 1228 Traffic Engineering", RFC 3272,May 2002 1230 [PSTE], Li, et. al., "A Provider Architecture for Differentiated 1231 Services and Traffic Engineering", RFC 2430, October 1998 1233 [TE-APP], Boyle, et. al., "Applicability Statement of Traffic 1234 Engineering", RFC 3346, August 2002. 1236 [TE-SURVIV], Lai, et. al., "Network Hierachy and Multilayer 1237 Suvivability", RFC 3386, November, 2002. 1239 12. Full Copyright Statement 1241 Copyright (C) The Internet Society (2003). All Rights Reserved. 1243 This document and translations of it may be copied and furnished to 1244 others, and derivative works that comment on or otherwise explain it 1245 or assist in its implementation may be prepared, copied, published 1246 and distributed, in whole or in part, without restriction of any 1247 kind, provided that the above copyright notice and this paragraph 1248 are included on all such copies and derivative works. However, this 1249 document itself may not be modified in any way, such as by removing 1250 the copyright notice or references to the Internet Society or other 1251 Internet organizations, except as needed for the purpose of 1252 developing Internet standards in which case the procedures for 1253 copyrights defined in the Internet Standards process MUST be 1254 followed, or as required to translate it into languages other than 1255 English. 1257 The limited permissions granted above are perpetual and will not be 1258 revoked by the Internet Society or its successors or assigns. 1260 This document and the information contained herein is provided on an 1261 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1262 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1263 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1264 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1265 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1267 Appendix A. Brief Description of BGP based Inter-AS Traffic 1268 Engineering 1270 In today's Service Provider (SP) network, BGP is deployed to meet 1271 two different sets of requirements: 1273 - Establishing a scalable exterior routing plane separating from 1274 data forwarding plane within SP's administrative domain 1275 - Exchanging network reachability information with different BGP 1276 autonomous systems (ASes) that could belong to a different SP 1277 or simply, a different AS within a SP network. 1279 Over connections across the AS boundaries, traffic engineering may 1280 also be accomplished via a set of BGP capabilities by appropriately 1281 enforcing BGP-based inter-AS routing policies. The current 1282 BGP-based inter-AS traffic engineering practices may be summarized 1283 as follows: 1285 - "Closest exit" routing where egress traffic from one SP to 1286 another follows the path defined by the lowest IGP or intra-AS 1287 MPLS TE tunnel metrics of the BGP next-HOP of exterior routes 1288 learned from other AS over the inter-AS links 1289 - "BGP path attribute" based routing selection mechanism where 1290 the egress traffic path is determined by interconnect (peering 1291 or transit) policies based upon one or a combination of BGP 1292 path attributes, like AS_PATH, MULTI_EXIT_DISC (MED), and 1293 Local_Pref. 1295 SPs have often faced a number of un-deterministic factors in their 1296 practices of inter-AS traffic engineering employing the methods 1297 mentioned above: 1299 - Sub-optimum traffic distribution across inter-AS links 1300 - Un-deterministic traffic condition changes due to uncoordinated 1301 IGP routing policies or topology changes within other AS and 1302 uncoordinated BGP routing policy changes (MED or as-prepend, 1303 etc.) 1305 In addition, to achieve some degrees of granularity, SPs may choose 1306 to enforce BGP inter-AS policies that are specific to one or a set 1307 of inter-AS links for ingress traffic destined to certain PoPs or 1308 regions within SP's network from another AS by tagging certain sets 1309 of routes with a specific attribute when announcing to another AS. 1310 This of course goes under the assumption that the other AS permits 1311 automated egress policy by matching the predefined attribute from 1312 incoming routes.