idnits 2.17.1 draft-ietf-ccamp-inter-domain-framework-03.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 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 845. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 958), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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. 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 == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 2005) is 6880 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) == Missing Reference: 'LMP' is mentioned on line 128, but not defined == Missing Reference: 'GMPLS-SEG' is mentioned on line 788, but not defined == Unused Reference: 'RFC3667' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'OVERLAY' is defined on line 918, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) -- No information found for draft-otani-ccamp-interas-GMPLS-TE - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Adrian Farrel 2 IETF Internet Draft Olddog Consulting 3 Proposed Status: Informational 4 Expires: December 2005 Jean-Philippe Vasseur 5 Cisco Systems, Inc. 7 Arthi Ayyangar 8 Juniper Networks 10 June 2005 12 A Framework for Inter-Domain MPLS Traffic Engineering 14 draft-ietf-ccamp-inter-domain-framework-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document provides a framework for establishing and controlling 46 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 47 Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain 48 networks. 50 For the purposes of this document, a domain is considered to be any 51 collection of network elements within a common sphere of address 52 management or path computational responsibility. Examples of such 53 domains include IGP areas and Autonomous Systems. 55 Contents 57 1. Introduction ............................................... 3 58 1.1. Nested Domains ......................................... 3 59 1.2. Conventions used in this document ...................... 4 60 2. Signaling Options .......................................... 4 61 2.1. LSP Nesting ............................................ 4 62 2.2. Contiguous LSP ......................................... 5 63 2.3. LSP Stitching .......................................... 5 64 2.4. Hybrid Methods ......................................... 6 65 2.5. Control of Downstream Choice of Signaling Method ....... 6 66 3. Path Computation Techniques ................................ 6 67 3.1. Management Configuration ............................... 7 68 3.2. Head End Computation ................................... 7 69 3.2.1. Multi-Domain Visibility Computation ................ 7 70 3.2.2. Partial Visibility Computation ..................... 7 71 3.2.3. Local Domain Visibility Computation ................ 8 72 3.3. Domain Boundary Computation ............................ 8 73 3.4. Path Computation Element ............................... 9 74 3.4.1. Multi-Domain Visibility Computation ................ 9 75 3.4.2. Path Computation Use of PCE When Preserving 76 Confidentiality .................................... 9 77 3.4.3. Per-Domain Computation Servers .................... 10 78 3.5. Optimal Path Computation .............................. 10 79 4. Distributing Reachability and TE Information .............. 10 80 5. Comments on Advanced Functions ............................ 11 81 5.1. LSP Re-Optimization ................................... 12 82 5.2. LSP Setup Failure ..................................... 12 83 5.3. LSP Repair ............................................ 13 84 5.4. Fast Reroute .......................................... 13 85 5.5. Comments on Path Diversity ............................ 14 86 5.6. Domain-Specific Constraints ........................... 15 87 5.7. Policy Control ........................................ 16 88 5.8. Inter-domain OAM ...................................... 16 89 5.9. Point-to-Multipoint ................................... 16 90 5.10. Applicability to Non-Packet Technologies ............. 16 91 6. Security Considerations ................................... 17 92 7. IANA Considerations ....................................... 17 93 8. Acknowledgements .......................................... 17 94 9. Intellectual Property Considerations ...................... 17 95 10. Normative References ..................................... 18 96 11. Informational References ................................. 18 97 12. Authors' Addresses ....................................... 19 98 13. Full Copyright Statement ................................. 20 100 1. Introduction 102 The Traffic Engineering Working Group has developed requirements for 103 inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and 104 [INTER-AS]. 106 Various proposals have subsequently been made to address some or all 107 of these requirements through extensions to the RSVP-TE and IGP 108 (ISIS, OSPF) protocols and procedures. 110 This document introduces the techniques for establishing Traffic 111 Engineered (TE) Label Switched Paths (LSPs) across multiple domains. 112 In this context and within the remainder of this document, we 113 consider all source-based and constraint-based routed LSPs and refer 114 to them interchangeably as "TE LSPs" or "LSPs". 116 The functional components of these techniques are separated into the 117 mechanisms for discovering reachability and TE information, for 118 computing the paths of LSPs, and for signaling the LSPs. Note that 119 the aim of this document is not to detail each of those techniques 120 which are covered in separate documents referenced from the sections 121 of this document that introduce the techniques, but rather to propose 122 a framework for inter-domain MPLS Traffic Engineering. 124 Note that in the remainder of this document, the term "MPLS Traffic 125 Engineering" is used equally to apply to MPLS and GMPLS traffic. 126 Specific issues pertaining to the use of GMPLS in inter-domain 127 environments (for example, policy implications of the use of the Link 128 Management Protocol [LMP] on inter-domain links) these are covered in 129 separate documents such as [GMPLS-AS]. 131 For the purposes of this document, a domain is considered to be any 132 collection of network elements within a common sphere of address 133 management or path computational responsibility. Examples of such 134 domains include IGP areas and Autonomous Systems. Wholly or partially 135 overlapping domains (e.g. path computation sub-domains of areas or 136 ASs) are not within the scope of this document. 138 1.1. Nested Domains 140 Nested domains are outside the scope of this document. It may be that 141 some domains that are nested administratively or for the purposes of 142 address space management can be considered as adjacent domains for 143 the purposes of this document, however the fact that the domains are 144 nested is then immaterial. 146 In the context of MPLS TE, domain A is considered to be nested within 147 domain B if domain A is wholly contained in Domain B, and domain B is 148 fully or partially aware of the TE characteristics and topology of 149 domain A. 151 1.2. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 2. Signaling Options 159 Three distinct options for signaling TE LSPs across multiple domains 160 are identified. The choice of which options to use may be influenced 161 by the path computation technique used (see section 3), although some 162 path computation techniques may apply to multiple signaling options. 163 The choice may further depend on the application to which the TE LSPs 164 are put and the nature, topology and switching capabilities of the 165 network. 167 A comparison of the usages of the different signaling options is 168 beyond the scope of this document and should be the subject of a 169 separate applicability statement. 171 2.1. LSP Nesting 173 Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are 174 discussed in further detail in [HIER]. Hierarchical LSPs may 175 optionally be advertised as TE links. Note that a hierarchical LSP 176 that spans multiple domains cannot be advertised in this way because 177 there is no concept of TE information that spans domains. 179 Hierarchical LSPs can be used in support of inter-domain TE LSPs. 180 In particular, a hierarchical LSP may be used to achieve connectivity 181 between any pair of LSRs within a domain. The ingress and egress of 182 the hierarchical LSP could be the edge nodes of the domain in which 183 case connectivity is achieved across the entire domain, or they could 184 be any other pair of LSRs in the domain. 186 The technique of carrying one TE LSP within another is termed LSP 187 nesting. A hierarchical LSP may provide a TE LSP tunnel to transport 188 (i.e. nest) multiple TE LSPs along a common part of their paths. 189 Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a 190 one-to-one mapping. 192 The signaling trigger for the establishment of a hierarchical LSP may 193 be the receipt of a signaling request for the TE LSP that it will 194 carry, or may be a management action to "pre-engineer" a domain to be 195 crossed by TE LSPs that would be used as hierarchical LSPs by the 196 traffic that has to traverse the domain. Furthermore, the mapping 197 (inheritance rules) between attributes of the nested and the 198 hierarchical LSPs (including bandwidth) may be statically 199 pre-configured or, for on-demand hierarchical LSPs, may be dynamic 200 according to the properties of the nested LSPs. Even in the dynamic 201 case inheritance from the properties of the nested LSP(s) can be 202 complemented by local or domain-wide policy rules. 204 Note that a hierarchical LSP may be constructed to span multiple 205 domains or parts of domains. However, such an LSP cannot be 206 advertised as a TE link that spans domains. The end points of a 207 hierarchical LSP are not necessarily on domain boundaries, so nesting 208 is not limited to domain boundaries. 210 Note also that the IGP/EGP routing topology is maintained unaffected 211 by the LSP connectivity and TE links introduced by hierarchical LSPs 212 even if they are advertised as TE links. That is, the routing 213 protocols do not exchange messages over the hierarchical LSPs, and 214 LSPs are not used to create routing adjacencies between routers. 216 During the operation of establishing a nested LSP that uses a 217 hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain 218 unchanged along the entire length of the nested LSP, as do all other 219 objects that have end-to-end significance. 221 2.2. Contiguous LSP 223 A single contiguous LSP is established from ingress to egress in a 224 single signaling exchange. No further LSPs are required to be 225 established to support this LSP so that hierarchical or stitched LSPs 226 are not needed. 228 A contiguous LSP uses the same Session/LSP ID along the whole of its 229 path (that is, at each LSR). The notions of "splicing" together 230 different LSPs, or of "shuffling" Session or LSP identifiers is not 231 considered. 233 2.3. LSP Stitching 235 LSP Stitching is described in [STITCH]. 237 In the LSP stitching model separate LSPs (referred to as a TE LSP 238 segments) are established and are "stitched" together in the data 239 plane so that a single end-to-end label switched path is achieved. 240 The distinction is that the component LSP segments are signaled as 241 distinct TE LSPs in the control plane. Each signaled TE LSP segment 242 has a different source and destination. 244 LSP stitching can be used in support of inter-domain TE LSPs. In 245 particular, an LSP segment may be used to achieve connectivity 246 between any pair of LSRs within a domain. The ingress and egress of 247 the LSP segment could be the edge nodes of the domain in which case 248 connectivity is achieved across the entire domain, or they could be 249 any other pair of LSRs in the domain. 251 The signaling trigger for the establishment of a TE LSP segment may 252 be the establishment of the previous TE LSP segment, the receipt of 253 a setup request for TE LSP that it plans to stitch to a local TE LSP 254 segment, or may be a management action. 256 LSP segments may be managed and advertised as TE links. 258 2.4. Hybrid Methods 260 There is nothing to prevent the mixture of signaling methods 261 described above when establishing a single, end-to-end, inter-domain 262 TE LSP. It may be desirable in this case for the choice of the 263 various methods to be reported along the path, perhaps through the 264 RRO. 266 If there is a desire to restrict which methods are used, this MUST be 267 signaled as described in the next section. 269 2.5. Control of Downstream Choice of Signaling Method 271 Notwithstanding the previous section, an ingress LSR MAY wish to 272 restrict the signaling methods applied to a particular LSP at domain 273 boundaries across the network. Such control, where it is required, 274 may be achieved by the definition of appropriate new flags in the 275 SESSION-ATTRIBUTE object or the Attributes Flags TLV of the 276 LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to 277 provide this level of control, the functional requirement to control 278 the way in which the network delivers a service must be established 279 and due consideration must be given to the impact on 280 interoperability since new mechanisms must be backwards compatible, 281 and care must be taken to avoid allowing standards-conformant 282 implementations each supporting a different functional subset such 283 that they are not capable of estbalishing LSPs. 285 3. Path Computation Techniques 287 The discussion of path computation techniques within this document is 288 limited significantly to the determination of where computation may 289 take place and what components of the full path may be determined. 291 The techniques used are closely tied to the signaling methodologies 292 described in the previous section in that certain computation 293 techniques may require the use of particular signaling approaches and 294 vice versa. 296 Any discussion of the appropriateness of a particular path 297 computation technique in any given circumstance is beyond the scope 298 of this document and should be described in a separate applicability 299 statement. 301 Path computation algorithms are firmly out of scope of this document. 303 3.1. Management Configuration 305 Path computation may be performed by offline tools or by a network 306 planner. The resultant path may be supplied to the ingress LSR as 307 part of the TE LSP or service request, and encoded by the ingress LSR 308 as an ERO on the Path message that is sent out. 310 There is no reason why the path provided by the operator should not 311 span multiple domains if the relevant information is available to the 312 planner or the offline tool. The definition of what information is 313 needed to perform this operation and how that information is 314 gathered, is outside the scope of this document. 316 3.2. Head End Computation 318 The head end, or ingress, LSR may assume responsibility for path 319 computation when the operator supplies part or none of the explicit 320 path. The operator MUST, in any case, supply at least the destination 321 address (egress) of the LSP. 323 3.2.1. Multi-Domain Visibility Computation 325 If the ingress has sufficient visibility of the topology and TE 326 information for all of the domains across which it will route the LSP 327 to its destination then it may compute and provide the entire path. 328 The quality of this path (that is, its optimality as discussed in 329 section 3.5) can be better if the ingress has full visibility into 330 all relevant domains rather than just sufficient visibility to 331 provide some path to the destination. 333 Extreme caution must be exercised in consideration of the 334 distribution of the requisite TE information. See section 4. 336 3.2.2. Partial Visibility Computation 338 It may be that the ingress does not have full visibility of the 339 topology of all domains, but does have information about the 340 connectedness of the domains and the TE resource availability across 341 the domains. In this case, the ingress is not able to provide a fully 342 specified strict explicit path from ingress to egress. However, for 343 example, the ingress might supply an explicit path that comprises: 344 - explicit hops from ingress to the local domain boundary 345 - loose hops representing the domain entry points across the network 346 - a loose hop identifying the egress. 348 Alternatively, the explicit path might be expressed as: 349 - explicit hops from ingress to the local domain boundary 350 - strict hops giving abstract nodes representing each domain in turn 351 - a loose hop identifying the egress. 353 These two explicit path formats could be mixed according to the 354 information available resulting in different combinations of loose 355 hops and abstract nodes. 357 This form of explicit path relies on some further computation 358 technique being applied at the domain boundaries. See section 3.3. 360 As with the multi-domain visibility option, extreme caution must be 361 exercised in consideration of the distribution of the requisite TE 362 information. See section 4. 364 3.2.3. Local Domain Visibility Computation 366 A final possibility for ingress-based computation is that the ingress 367 LSR has visibility only within its own domain, and connectivity 368 information only as far as determining one or more domain exit points 369 that may be suitable for carrying the LSP to its egress. 371 In this case the ingress builds an explicit path that comprises just: 372 - explicit hops from ingress to the local domain boundary 373 - a loose hop identifying the egress. 375 3.3. Domain Boundary Computation 377 If the partial explicit path methods described in sections 3.2.2 or 378 3.2.3 are applied then the LSR at each domain boundary is responsible 379 for ensuring that there is sufficient path information added to the 380 Path message to carry it at least to the next domain boundary (that 381 is, out of the new domain). 383 If the LSR at the domain boundary has full visibility to the egress 384 then it can supply the entire explicit path. Note however, that the 385 ERO processing rules of [RFC3209] state that it SHOULD only update 386 the ERO as far as the next specified hop (that is, the next domain 387 boundary if one was supplied in the original ERO) and, of course, 388 MUST NOT insert ERO subobjects immediately before a strict hop. 390 If the LSR at the domain boundary has only partial visibility (using 391 the definitions of section 3.2.2) it will fill in the path as far as 392 the next domain boundary, and will supply further domain/domain 393 boundary information if not already present in the ERO. 395 If the LSR at the domain boundary has only local visibility into the 396 immediate domain it will simply add information to the ERO to carry 397 the Path message as far as the next domain boundary. 399 3.4. Path Computation Element 401 The computation techniques in sections 3.2 and 3.3 rely on topology 402 and TE information being distributed to the ingress LSR and those 403 LSRs at domain boundaries. These LSRs are responsible for computing 404 paths. Note that there may be scaling concerns with distributing the 405 required information - see section 4. 407 An alternative technique places the responsibility for path 408 computation with a Path Computation Element (PCE) [PCE]. There may be 409 either a centralized PCE, or multiple PCEs (each having local 410 visibility and collaborating in a distributed fashion to compute an 411 end-to-end path) across the entire network and even within any one 412 domain. The PCE may collect topology and TE information from the same 413 sources as would be used by LSRs in the previous paragraph, or though 414 other means. 416 Each LSR called upon to perform path computation (and even the 417 offline management tools described in section 3.1) may abdicate the 418 task to a PCE of its choice. The selection of PCE(s) may be driven by 419 static configuration or the dynamic discovery. 421 3.4.1. Multi-Domain Visibility Computation 423 A PCE may have full visibility, perhaps through connectivity to 424 multiple domains. In this case it is able to supply a full explicit 425 path as in section 3.2.1. 427 3.4.2. Path Computation Use of PCE When Preserving Confidentiality 429 Note that although a centralized PCE or multiple collaborative PCEs 430 may have full visibility into one or more domains, it may be 431 desirable (e.g to preserve confidentiality) that the full path is not 432 provided to the ingress LSR. Instead, a partial path is supplied (as 433 in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are 434 required to make further requests for each successive segment of the 435 path. 437 In this way an end-to-end path may be computed using the full network 438 capabilities, but confidentiality between domains may be preserved. 439 Optionally, the PCE(s) may compute the entire path at the first 440 request and hold it in storage for subsequent requests, or it may 441 recompute each leg of the path on each request or at regular 442 intervals until requested by the LSRs establishing the LSP. 444 It may be the case that the centralized PCE or the collaboration 445 between PCEs may define a trust relationship greater than that 446 normally operational between domains. 448 3.4.3. Per-Domain Computation Elements 450 A third way that PCEs may be used is simply to have one (or more) per 451 domain. Each LSR within a domain that wishes to derive a path across 452 the domain may consult its local PCE. 454 This mechanism could be used for all path computations within the 455 domain, or specifically limited to computations for LSPs that will 456 leave the domain where external connectivity information can then be 457 restricted to just the PCE. 459 3.5. Optimal Path Computation 461 There are many definitions of an optimal path depending on the 462 constraints applied to the path computation. In a multi-domain 463 environment the definitions are multiplied so that an optimal route 464 might be defined as the route that would be computed in the absence 465 of domain boundaries. Alternatively, another constraint might be 466 applied to the path computation to reduce or limit the number of 467 domains crossed by the LSP. 469 It is easy to construct examples that show that partitioning a 470 network into domains, and the resulting loss or aggregation of 471 routing information may lead to the computation of routes that are 472 other than optimal. It is impossible to guarantee optimal routing in 473 the presence of aggregation / abstraction / summarization of routing 474 information. 476 It is beyond the scope of this document to define what is an optimum 477 path for an inter-domain TE LSP. This debate is abdicated in favor of 478 requirements documents and applicability statements for specific 479 deployment scenarios. Note, however, that the meaning of certain 480 computation metrics may differ between domains (see section 5.6). 482 4. Distributing Reachability and TE Information 484 Traffic Engineering information is collected into a TE Database (TED) 485 on which path computation algorithms operate either directly or by 486 first constructing a network graph. 488 The path computation techniques described in the previous section 489 make certain demands upon the distribution of reachability 490 information and the TE capabilities of nodes and links within domains 491 as well as the TE connectivity across domains. 493 Currently, TE information is distributed within domains by additions 494 to IGPs [RFC3630], [RFC3784]. 496 In cases where two domains are interconnected by one or more links 497 (that is, the domain boundary falls on a link rather than on a node), 498 there SHOULD be a mechanism to distribute the TE information 499 associated with the inter-domain links to the corresponding domains. 500 This would facilitate better path computation and reduce TE-related 501 crankbacks on these links. 503 Where a domain is a subset of an IGP area, filtering of TE 504 information may be applied at the domain boundary. This filtering may 505 be one way, or two way. 507 Where information needs to reach a PCE that spans multiple domains, 508 the PCE may snoop on the IGP traffic in each domain, or play an 509 active part as an IGP-capable node in each domain. The PCE might also 510 receive TED updates from a proxy within the domain. 512 It could be possible that an LSR that performs path computation (for 513 example, an ingress LSR) obtains the topology and TE information of 514 not just its own domain, but other domains as well. This information 515 may be subject to filtering applied by the advertising domain (for 516 example, the information may be limited to FAs across other domains, 517 or the information may be aggregated or abstracted). 519 Before starting work on any protocols or protocol extensions to 520 enable cross-domain reachability and TE advertisement in support of 521 inter-domain TE, the requirements and and benefits must be clearly 522 established. This has not been done to date. Where any cross-domain 523 reachability and TE information needs to be advertised, consideration 524 must be given to TE extensions to existing protocols such as BGP, and 525 how the information advertised may be fed to the IGPs. It must be 526 noted that any extensions that cause a significant increase in the 527 amount of processing (such as aggregation computation) at domain 528 boundaries, or a significant increase in the amount of information 529 flooded (such as detailed TE information) need to be treated with 530 extreme caution and compared carefully with the scaling requirements 531 expressed in [INTER-AREA] and [INTER-AS]. 533 5. Comments on Advanced Functions 535 This section provides some non-definitive comments on the constraints 536 placed on advanced MPLS TE functions by inter-domain MPLS. It does 537 not attempt to state the implications of using one inter-domain 538 technique or another. Such material is deferred to appropriate 539 applicability statements where statements about the capabilities of 540 existing or future signaling, routing and computation techniques to 541 deliver the functions listed should be made. 543 5.1. LSP Re-Optimization 545 Re-optimization is the process of moving a TE LSP from one path to 546 another, more preferable path (where no attempt is made in this 547 document to define "preferable" as no attempt was made to define 548 "optimal"). Make-before-break techniques are usually applied to 549 ensure that traffic is disrupted as little as possible. The Shared 550 Explicit style is usually used to avoid double booking of network 551 resources. 553 Re-optimization may be available within a single domain. 554 Alternatively, re-optimization may involve a change in route across 555 several domains or might involve a choice of different transit 556 domains. 558 Re-optimization requires that all or part of the path of the LSP be 559 re-computed. The techniques used may be selected as described in 560 section 3, and this will influence whether the whole or part of the 561 path is re-optimized. 563 The trigger for path computation and re-optimization may be an 564 operator request, a timer, information about a change in 565 availability of network resources, or a change in operational 566 parameters (for example bandwidth) of an LSP. This trigger MUST be 567 applied to the point in the network that requests re-computation and 568 controls re-optimization and may require additional signaling. 570 Note also that where multiple mutually-diverse paths are applied 571 end-to-end (i.e. not simply within protection domains - see section 572 5.5) the point of calculation for re-optimization (whether it is PCE, 573 ingress, or domain entry point) needs to know all such paths before 574 attempting re-optimization of any one path. Mutual diversity here 575 means that a set of computed paths have no commonality. Such 576 diversity might be link, node, SRLG or even domain disjointedness 577 according to circumstances and the service being delivered. 579 It may be the case that re-optimization is best achieved by 580 recomputing the paths of multiple LSPs at once. Indeed, this can be 581 shown to be most efficient when the paths of all LSPs are known, not 582 simply those LSPs that originate at a particular ingress. While this 583 problem is inherited from single domain re-optimization and is out of 584 scope within this document, it should be noted that the problem grows 585 in complexity when LSPs wholly within one domain affect the 586 re-optimization path calculations performed in another domain. 588 5.2. LSP Setup Failure 590 When an inter-domain LSP setup fails in some domain other than the 591 first, various options are available for reporting and retrying the 592 LSP. 594 In the first instance, a retry may be attempted within the domain 595 that contains the failure. That retry may be attempted by nodes 596 wholly within the domain, or the failure may be referred back to the 597 LSR at the domain boundary. 599 If the failure cannot be bypassed within the domain where the failure 600 occurred (perhaps there is no suitable alternate route, perhaps 601 rerouting is not allowed by domain policy, or perhaps the Path 602 message specifically bans such action), the error MUST be reported 603 back to the previous or head-end domain. 605 Subsequent repair attempts may be made by domains further upstream, 606 but will only be properly effective if sufficient information about 607 the failure and other failed repair attempts is also passed back 608 upstream [CRANKBACK]. Note that there is a tension between this 609 requirement and that of confidentiality although crankback 610 aggregation may be applicable at domain boundaries. 612 Further attempts to signal the failed LSP may apply the information 613 about the failures as constraints to path computation, or may signal 614 them as specific path exclusions [EXCLUDE]. 616 When requested by signaling, the failure may also be systematically 617 reported to the head-end LSR. 619 5.3. LSP Repair 621 An LSP that fails after it has been established may be repaired 622 dynamically by re-routing. The behavior in this case is either like 623 that for re-optimization, or for handling setup failures (see 624 previous two sections). 626 Fast Reroute may also be used (see below). 628 5.4. Fast Reroute 630 MPLS Traffic Engineering Fast Reroute ([FRR]) defines local 631 protection schemes intended to provide fast recovery (in 10s of 632 msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node 633 failure. A backup TE LSP is configured and signaled at each hop, and 634 activated upon detecting or being informed of a network element 635 failure. The node immediately upstream of the failure (called the PLR 636 - Point of Local Repair) reroutes the set of protected TE LSPs onto 637 the appropriate backup tunnel(s) and around the failed resource. 639 In the context of inter-domain TE, there are several different 640 failure scenarios that must be analyzed. Provision of suitable 641 solutions may be further complicated by the fact that [FRR] specifies 642 two distinct modes of operation referred to as the "one to one mode" 643 and the "facility back-up mode". 645 The failure scenarios specific to inter-domain TE are as follows: 647 - Failure of a domain edge node that is present in both domains. 648 There are two sub-cases: 650 - The PLR and the MP are in the same domain 652 - The PLR and the MP are in different domains. 654 - Failure of a domain edge node that is only present in one of the 655 domains. 657 - Failure of an inter-domain link. 659 Although it may be possible to apply the same techniques for FRR to 660 the different methods of signaling inter-domain LSPs described in 661 section 2, the results of protection may be different when it is the 662 boundary nodes that need to be protected, and when they are the 663 ingress and egress of a hierarchical LSP or stitched LSP segment. In 664 particular, the choice of Point of Local Repair (PLR) and Merge Point 665 (MP) may be different, and the length of the protection path may be 666 greater. These use of FRR techniques should be explained further in 667 applicability statements or, in the case of a change in base 668 behavior, in implementation guidelines specific to the signaling 669 techniques. 671 Note that after local repair has been performed, it may be desirable 672 to re-optimize the LSP (see section 5.1). If the point of 673 re-optimization (for example the ingress LSR) lies in a different 674 domain to the failure, it may rely on the delivery of a PathErr or 675 Notify message to inform it of the local repair event. 677 It is important to note that Fast Reroute techniques are only 678 applicable to packet switching networks because other network 679 technologies cannot apply label stacking within the same switching 680 type. Segment protection [SEG-PROT] provides a suitable alternative 681 that is applicable to packet and non-packet networks. 683 5.5. Comments on Path Diversity 685 Diverse paths may be required in support of load sharing and/or 686 protection. Such diverse paths may be required to be node diverse, 687 link diverse, fully path diverse (that is, link and node diverse), or 688 SRLG diverse. 690 Diverse path computation is a classic problem familiar to all graph 691 theory majors. The problem is compounded when there are areas of 692 "private knowledge" such as when domains do not share topology 693 information. The problem can be resolved more efficiently (e.g. 694 avoiding the "trap problem") when mutually resource disjoint paths 695 can be computed "simultaneously" on the fullest set of information. 697 That being said, various techniques (out of the scope of this 698 document) exist to ensure end-to-end path diversity across multiple 699 domains. 701 Many network technologies utilize "protection domains" because they 702 fit well with the capabilities of the technology. As a result, many 703 domains are operated as protection domains. In this model, protection 704 paths converge at domain boundaries. 706 Note that the question of SRLG identification is not yet fully 707 answered. There are two classes of SRLG: 709 - those that indicate resources that are all contained witin one 710 domain 712 - those that span domains. 714 The former might be identified using a combination of a globally 715 scoped domain ID, and an SRLG ID that is administered by the domain. 716 The latter requires a global scope to the SRLG ID. Both schemes, 717 therefore, require external administration. The former is able to 718 leverage existing domain ID administration (for example, area and AS 719 numbers), but the latter would require a new administrative policy. 721 5.6. Domain-Specific Constraints 723 While the meaning of certain constraints, like bandwidth, can be 724 assumed to be constant across different domains, other TE constraints 725 (such as resource affinity, color, metric, priority, etc.) may have 726 different meanings in different domains and this may impact the 727 ability to support DiffServ-aware MPLS, or to manage pre-emption. 729 In order to achieve consistent meaning and LSP establishment, this 730 fact must be considered when performing constraint-based path 731 computation or when signaling across domain boundaries. 733 A mapping function can be derived for most constraints based on 734 policy agreements between the Domain administrators. The details of 735 such a mapping function are outside the scope of this document, but 736 it is important to note that the default behavior MUST either be 737 that a constant mapping is applied or that any requirement to apply 738 these constraints across a domain boundary must fail in the absence 739 of explicit mapping rules. 741 5.7. Policy Control 743 Domain boundaries are natural points for policy control. There is 744 little to add on this subject except to note that a TE LSP that 745 cannot be established on a path through one domain because of a 746 policy applied at the domain boundary, may be satisfactorily 747 established using a path that avoids the demurring domain. In any 748 case, when a TE LSP signaling attempt is rejected due to 749 non-compliance with some policy constraint, this SHOULD be reflected 750 to the ingress LSR. 752 5.8. Inter-domain OAM 754 Some elements of OAM may be intentionally confined within a domain. 755 Others (such as end-to-end liveness and connectivity testing) clearly 756 need to span the entire multi-domain TE LSP. Where issues of 757 confidentiality are strong, collaboration between PCEs or domain 758 boundary nodes might be required in order to provide end-to-end OAM, 759 and a significant issue to be resolved is to ensure that the 760 end-points support the various OAM capabilities. 762 The different signaling mechanisms described above may need 763 refinements to [LSPPING], and [BFD-MPLS], etc., to gain full 764 end-to-end visibility. These protocols should, however, be considered 765 in the light of confidentiality requirements. 767 Route recording is a commonly used feature of signaling that provides 768 OAM information about the path of an established LSP. When an LSP 769 traverses a domain boundary, the border node may remove or aggregate 770 some of the recorded information for confidentiality or other policy 771 reasons. 773 5.9. Point-to-Multipoint 775 Inter-domain point-to-multipoint (P2MP) requirements are explicitly 776 out of scope of this document. They may be covered by other documents 777 dependent on the details of MPLS TE P2MP solutions. 779 5.10. Applicability to Non-Packet Technologies 781 Non-packet switching technologies may present particular issues for 782 inter-domain LSPs. While packet switching networks may utilize 783 control planes built on MPLS or GMPLS technology, non-packet networks 784 are limited to GMPLS. 786 On the other hand, some problems such as Fast Re-Route on domain 787 boundaries (see section 5.4) may be handled by the GMPLS technique of 788 segment protection [GMPLS-SEG] that is applicable to both packet and 789 non-packet switching technologies. 791 The specific architectural considerations and requirements for 792 inter-domain LSP setup in non-packet networks are covered in a 793 separate document [GMPLS-AS]. 795 6. Security Considerations 797 Requirements for security within domains are unchanged from [RFC3209] 798 and [RFC3473], but requirements for inter-domain security are, if 799 anything, more significant. 801 Authentication techniques identified for use with RSVP-TE can only 802 operate across domain boundaries if there is coordination between the 803 administrators of those domains. 805 Confidentiality may also be considered to be security factors. 807 Applicability statements for particular combinations of signaling, 808 routing and path computation techniques are expected to contain 809 detailed security sections. 811 7. IANA Considerations 813 This document makes no requests for any IANA action. 815 8. Acknowledgements 817 The authors would like to extend their warmest thanks to Kireeti 818 Kompella for convincing them to expend effort on this document. 820 Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani and Igor 821 Bryskin for their review and suggestions on the text. 823 9. Intellectual Property Considerations 825 The IETF takes no position regarding the validity or scope of any 826 Intellectual Property Rights or other rights that might be claimed to 827 pertain to the implementation or use of the technology described in 828 this document or the extent to which any license under such rights 829 might or might not be available; nor does it represent that it has 830 made any independent effort to identify any such rights. Information 831 on the procedures with respect to rights in RFC documents can be 832 found in BCP 78 and BCP 79. 834 Copies of IPR disclosures made to the IETF Secretariat and any 835 assurances of licenses to be made available, or the result of an 836 attempt made to obtain a general license or permission for the use of 837 such proprietary rights by implementers or users of this 838 specification can be obtained from the IETF on-line IPR repository at 839 http://www.ietf.org/ipr. 841 The IETF invites any interested party to bring to its attention any 842 copyrights, patents or patent applications, or other proprietary 843 rights that may cover technology that may be required to implement 844 this standard. Please address the information to the IETF at 845 ietf-ipr@ietf.org. 847 10. Normative References 849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 850 Requirement Levels", BCP 14, RFC 2119, March 1997. 852 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, 853 "Multiprotocol Label Switching Architecture", RFC 3031, 854 January 2001. 856 [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", 857 RFC 3209, December 2001. 859 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label 860 Switching (GMPLS) Signaling - Resource ReserVation 861 Protocol-Traffic Engineering (RSVP-TE) Extensions", 862 RFC 3473, January 2003. 864 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 865 RFC 3667, February 2004. 867 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 868 Technology", BCP 79, RFC 3668, February 2004. 870 11. Informational References 872 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 873 Extensions to OSPF Version 2", RFC 3630, September 2003 875 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 876 Engineering", RFC 3784, June 2004. 878 [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of 879 Attributes for Multiprotocol Label Switching (MPLS) 880 Label Switched Path (LSP) Establishment Using RSVP-TE", 881 draft-ietf-mpls-rsvpte-attributes, work in progress. 883 [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work 884 in progress. 886 [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for 887 MPLS Signaling", draft-ietf-ccamp-crankback, 888 work in progress. 890 [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, 891 draft-ietf-ccamp-rsvp-te-exclude-route, work in 892 progress. 894 [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 895 for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, 896 work in progress. 898 [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS 899 Traffic Engineering Requirements", 900 draft-otani-ccamp-interas-GMPLS-TE, work in progress. 902 [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with 903 Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, 904 work in progress. 906 [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of 907 Inter-Area and Inter-AS MPLS Traffic Engineering", 908 draft-ietf-tewg-interarea-mpls-te-req, work in 909 progress. 911 [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic 912 Engineering requirements", 913 draft-ietf-tewg-interas-mpls-te-req, work in progress. 915 [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness 916 in MPLS", draft-ietf-mpls-lsp-ping, work in progress. 918 [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 919 Model", draft-ietf-ccamp-gmpls-overlay, work in 920 progress. 922 [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path 923 Computation Element (PCE) Architecture", 924 draft-ietf-pce-architecture, work in progress. 926 [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, 927 A., "GMPLS Based Segment Recovery", 928 draft-ietf-ccamp-gmpls-segment-recovery, work in 929 progress. 931 [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with 932 Generalized MPLS TE", 933 draft-ietf-ccamp-lsp-stitching, work in progress. 935 12. Authors' Addresses 937 Adrian Farrel 938 Old Dog Consulting 939 EMail: adrian@olddog.co.uk 940 Jean-Philippe Vasseur 941 Cisco Systems, Inc. 942 300 Beaver Brook Road 943 Boxborough , MA - 01719 944 USA 945 Email: jpv@cisco.com 947 Arthi Ayyangar 948 Juniper Networks, Inc 949 1194 N.Mathilda Ave 950 Sunnyvale, CA 94089 951 USA 952 Email: arthi@juniper.net 954 13. Full Copyright Statement 956 Copyright (C) The Internet Society (2005). This document is subject 957 to the rights, licenses and restrictions contained in BCP 78, and 958 except as set forth therein, the authors retain all their rights. 960 This document and the information contained herein are provided on an 961 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 962 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 963 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 964 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 965 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 966 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.