idnits 2.17.1 draft-ietf-ccamp-inter-domain-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 773. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 779. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 896), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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 (February 2005) is 7000 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: 'RFC3667' is defined on line 794, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 797, but no explicit reference was found in the text == Unused Reference: 'OVERLAY' is defined on line 859, 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) ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-interarea-mpls-te-req (ref. 'INTER-AREA') ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-interas-mpls-te-req (ref. 'INTER-AS') -- Possible downref: Normative reference to a draft: ref. 'STITCH' -- Possible downref: Normative reference to a draft: ref. 'PCE' -- 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: 11 errors (**), 0 flaws (~~), 5 warnings (==), 11 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: August 2005 Jean-Philippe Vasseur 5 Cisco Systems, Inc. 7 Arthi Ayyangar 8 Juniper Networks 10 February 2005 12 A Framework for Inter-Domain MPLS Traffic Engineering 13 draft-ietf-ccamp-inter-domain-framework-01.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 This document provides a framework for establishing and controlling 47 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 48 Label Switched Paths (LSPs) in multi-domain 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 ............................................... 58 1.1. Nested Domains ......................................... 59 1.2. Conventions used in this document ...................... 60 2. Signaling Options .......................................... 61 2.1. LSP Nesting ............................................ 62 2.2. Contiguous LSP ......................................... 63 2.3. LSP Stitching .......................................... 64 2.4. Hybrid Methods ......................................... 65 2.5. Control of Downstream Choice of Signaling Method ....... x 66 3. Path Computation Techniques ................................ 67 3.1. Management Configuration ............................... 68 3.2. Head End Computation ................................... 69 3.2.1. Multi-Domain Visibility Computation ................ 70 3.2.2. Partial Visibility Computation ..................... 71 3.2.3. Local Domain Visibility Computation ................ 72 3.3. Domain Boundary Computation ............................ 73 3.4. Path Computation Element ............................... 74 3.4.1. Multi-Domain Visibility Computation ................ 75 3.4.2. Path Computation Use of PCE When Preserving 76 Confidentiality .................................... 77 3.4.3. Per-Domain Computation Servers ..................... 78 3.5. Optimal Path Computation ............................... 79 4. Distributing Reachability and TE Information ............... 80 5. Comments on Advanced Functions ............................. 81 5.1. LSP Re-Optimization .................................... 82 5.2. LSP Setup Failure ...................................... 83 5.3. LSP Repair ............................................. 84 5.4. Fast Reroute ........................................... 85 5.5. Comments on Path Diversity ............................. 86 5.6. Domain-Specific Constraints ............................ 87 5.7. Policy Control ......................................... 88 5.8. Inter-domain OAM ....................................... 89 5.9. Point-to-Multipoint .................................... 90 5.10. Applicability to Non-Packet Technologies .............. 91 6. Security Considerations .................................... 92 7. IANA Considerations ........................................ 93 8. Acknowledgements ........................................... 94 9. Intellectual Property Considerations ....................... 95 10. Normative References ...................................... 96 11. Informational References .................................. 97 12. Authors' Addresses ........................................ 98 13. Full Copyright Statement .................................. 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 TE LSPs 111 across multiple domains. The functional components of these 112 techniques are separated into the mechanisms for discovering 113 reachability and TE information, for computing the paths of LSPs, and 114 for signaling the LSPs. Note that the aim of this document is not to 115 detail each of those techniques which are covered in separate 116 documents, but rather to propose a framework for inter-domain MPLS 117 Traffic Engineering. 119 Note that in the remainder of this document, the term 'MPLS Traffic 120 Engineering' is used equally to apply to MPLS and GMPLS traffic 121 engineering in packet and non-packet environments. 123 For the purposes of this document, a domain is considered to be any 124 collection of network elements within a common sphere of address 125 management or path computational responsibility. Examples of such 126 domains include IGP areas and Autonomous Systems. However, domains of 127 computational responsibility may also exist as sub-domains of areas 128 or ASs. Wholly or partially overlapping domains are not within the 129 scope of this document. 131 1.1. Nested Domains 133 Nested domains are outside the scope of this document. It may be that 134 some domains that are nested administratively or for the purposes of 135 address space management can be considered as adjacent domains for 136 the purposes of this document, however the fact that the domains are 137 nested is then immaterial. 139 In the context of MPLS TE, domain A is considered to be nested within 140 domain B if domain A is wholly contained in Domain B, and domain B is 141 fully or partially aware of the TE characteristics and topology of 142 domain A. 144 For further consideration of nested domains see [MRN] 146 1.2. Conventions used in this document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Signaling Options 154 Three distinct options for signaling TE LSPs across multiple domains 155 are identified. The choice of which options to use may be influenced 156 by the path computation technique used (see section 3), although some 157 path computation techniques may apply to multiple TE LSP types. The 158 choice may further depend on the application to which the TE LSPs are 159 put and the nature, topology and switching capabilities of the 160 network. 162 A comparison of the usages of the different signaling options is 163 beyond the scope of this document and should be the subject of a 164 separate applicability statement. 166 2.1. LSP Nesting 168 Forwarding Adjacencies (FAs) are introduced and explained in detail 169 in [HIER]. No further description is necessary in this document. 171 FAs can be used in support of inter-domain TE LSPs. In particular, an 172 FA may be used to achieve connectivity between any pair of LSRs 173 within a domain. The ingress and egress of the FA LSP could be the 174 edge nodes of the domain in which case connectivity is achieved 175 across the entire domain, or they could be any other pair of LSRs in 176 the domain. 178 The technique of carrying one TE LSP within another is termed LSP 179 nesting. An FA may provide a TE LSP tunnel to transport (i.e. nest) 180 multiple TE LSPs along a common part of their paths. Alternatively, a 181 TE LSP may carry (i.e. nest) a single LSP in a one-to-one mapping. 183 The signaling trigger for the establishment of an FA LSP may be the 184 receipt of a signaling request for the TE LSP that it will carry, or 185 may be a management action to 'pre-engineer' a domain to be crossed 186 by TE LSPs that would be used as FAs by the traffic that has to 187 traverse the domain. Furthermore, the mapping (inheritance rules) 188 between attributes of the nested and FA LSPs (including bandwidth) 189 may be statically pre-configured or, for on-demand FA LSPs, may be 190 dynamic according to the properties of the nested LSPs. 192 Note that a hierarchical LSP may be constructed to span multiple 193 domains or parts of domains. However, how or whether such an LSP 194 could be advertised as an FA that spans domains is open for study. 195 The end points of a hierarchical LSP are not necessarily on domain 196 boundaries, so nesting is not limited to domain boundaries. 198 Note also that the IGP/EGP routing topology is maintained unaffected 199 by the LSP connectivity and TE links introduced by FA LSPs. That is, 200 the routing protocols do not exchange messages over the FA LSPs, and 201 such LSPs do not create routing adjacencies between routers. 203 During the operation of establishing a nested LSP that uses a 204 hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain 205 unchanged along the entire length of the nested LSP. 207 2.2. Contiguous LSP 209 A single contiguous LSP is established from ingress to egress in a 210 single signaling exchange. No further LSPs are required to be 211 established to support this LSP. Signaling occurs between adjacent 212 neighbors only (no tunneling), and hop-by-hop signaling is used. 214 2.3. LSP Stitching 216 LSP Stitching is described in [STITCH]. 218 In the LSP stitching model separate LSPs (referred to as a TE LSP 219 segments) are established and are "stitched" together in the data 220 plane so that a single end-to-end label switched path is achieved. 221 The distinction is that the component LSP segments are signaled as 222 distinct TE LSPs in the control plane. Each signaled TE LSP segment 223 has a different source and destination. 225 LSP stitching can be used in support of inter-domain TE LSPs. In 226 particular, an LSP segment may be used to achieve connectivity 227 between any pair of LSRs within a domain. The ingress and egress of 228 the LSP segment could be the edge nodes of the domain in which case 229 connectivity is achieved across the entire domain, or they could be 230 any other pair of LSRs in the domain. 232 The signaling trigger for the establishment of a TE LSP segment may 233 be the establishment of the previous TE LSP segment, the receipt of 234 setup request for TE LSP that it plans to stitch to a local TE LSP 235 segment, or may be a management action. 237 LSP segments may be managed as FAs and advertised as TE links. 239 2.4. Hybrid Methods 241 There is nothing to prevent the mixture of signaling methods 242 described above when establishing a single, end-to-end, inter-domain 243 TE LSP. It may be desirable in this case for the choice of the 244 various methods to be indicated along the path perhaps through the 245 RRO. 247 If there is a desire to restrict which methods are used, this MUST be 248 signaled as described in the next section. 250 2.5. Control of Downstream Choice of Signaling Method 252 Notwithstanding the previous section, an ingress LSR MAY wish to 253 restrict the signaling methods applied to a particular LSP at domain 254 boundaries across the network. Such control, where it is required, 255 may be achieved by the definition of appropriate new flags in the 256 SESSION-ATTRIBUTE object or the Attributes Flags TLV of the 257 LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to 258 provide this level of control, the functional requirement to control 259 the way in which the network delivers a service must be established 260 and due consideration must be given to the impact on 261 interoperability. 263 3. Path Computation Techniques 265 The discussion of path computation techniques within this document is 266 limited significantly to the determination of where computation may 267 take place and what components of the full path may be determined. 269 The techniques used are closely tied to the signaling methodologies 270 described in the previous section in that certain computation 271 techniques may require the use of particular signaling approaches and 272 vice versa. 274 Any discussion of the appropriateness of a particular path 275 computation technique in any given circumstance is beyond the scope 276 of this document and should be described in a separate applicability 277 statement. 279 Path computation algorithms are firmly out of scope of this document. 281 3.1. Management Configuration 283 Path computation may be performed by offline tools or by a network 284 planner. The resultant path may be supplied to the ingress LSR as 285 part of the TE LSP or service request, and encoded by the ingress LSR 286 as an ERO on the Path message that is sent out. 288 There is no reason why the path provided by the operator should not 289 span multiple domains if the relevant information is available to the 290 planner or the offline tool. The definition of what information is 291 needed to perform this operation and how that information is 292 gathered, is outside the scope of this document. 294 3.2. Head End Computation 296 The head end, or ingress, LSR may assume responsibility for path 297 computation when the operator supplies part or none of the explicit 298 path. The operator MUST, in any case, supply at least the destination 299 address (egress) of the LSP. 301 3.2.1. Multi-Domain Visibility Computation 303 If the ingress has sufficient visibility of the topology and TE 304 information for all of the domains across which it will route the LSP 305 to its destination then it may compute and provide the entire path. 306 The quality of this path (that is, its optimality as discussed in 307 section 3.5) is best if the ingress has full visibility into all 308 relevant domains rather than just sufficient visibility to provide 309 some path to the destination. 311 Extreme caution must be exercised in consideration of the 312 distribution of the requisite TE information. See section 4. 314 3.2.2. Partial Visibility Computation 316 It may be that the ingress does not have full visibility of the 317 topology of all domains, but does have information about the 318 connectedness of the domains and the TE resource availability across 319 the domains. In this case, the ingress is not able to provide a fully 320 specified strict explicit path from ingress to egress. However, the 321 ingress can supply an explicit path that comprises: 322 - explicit hops from ingress to the local domain boundary 323 - loose hops representing the domain entry points across the network 324 - a loose hop identifying the egress. 326 Alternatively, the explicit path may be expressed as: 327 - explicit hops from ingress to the local domain boundary 328 - strict hops giving abstract nodes representing each domain in turn 329 - a loose hop identifying the egress. 331 These two explicit path formats may be mixed. 333 This form of explicit path relies on some further computation 334 technique being applied at the domain boundaries. See section 3.3. 336 As with the multi-domain visibility option, extreme caution must be 337 exercised in consideration of the distribution of the requisite TE 338 information. See section 4. 340 3.2.3. Local Domain Visibility Computation 342 A final possibility for ingress-based computation is that the ingress 343 LSR has visibility only within its own domain, and connectivity 344 information only as far as determining one or more domain exit points 345 that may be suitable for carrying the LSP to its egress. 347 In this case the ingress builds an explicit path that comprises just: 348 - explicit hops from ingress to the local domain boundary 349 - a loose hop identifying the egress. 351 3.3. Domain Boundary Computation 353 If the partial explicit path methods described in sections 3.2.2 or 354 3.2.3 are applied then the LSR at each domain boundary is responsible 355 for ensuring that there is sufficient path information added to the 356 Path message to carry it at least to the next domain boundary (that 357 is, out of the new domain). 359 If the LSR at the domain boundary has full visibility to the egress 360 then it can supply the entire explicit path. Note however, that the 361 ERO processing rules of [RFC3209] state that it SHOULD only update 362 the ERO as far as the next specified hop (that is, the next domain 363 boundary if one was supplied in the original ERO) and, of course, 364 MUST NOT insert ERO subobjects immediately before a strict hop. 366 If the LSR at the domain boundary has only partial visibility (using 367 the definitions of section 3.2.2) it will fill in the path as far as 368 the next domain boundary, and will supply further domain/domain 369 boundary information if not already present in the ERO. 371 If the LSR at the domain boundary has only local visibility into the 372 immediate domain it will simply add information to the ERO to carry 373 the Path message as far as the next domain boundary. 375 3.4. Path Computation Element 377 The computation techniques in sections 3.2 and 3.3 rely on topology 378 and TE information being distributed to the ingress LSR and those 379 LSRs at domain boundaries. These LSRs are responsible for computing 380 paths. Note that there may be scaling concerns with distributing the 381 required information - see section 4. 383 An alternative technique places the responsibility for path 384 computation with a Path Computation Element (PCE) [PCE]. There may be 385 either a centralized PCE, or multiple PCEs (each having local 386 visibility and collaborating in a distributed fashion to compute an 387 end-to-end path) across the entire network and even within any one 388 domain. The PCE may collect topology and TE information from the same 389 sources as would be used by LSRs in the previous paragraph, or though 390 other means. 392 Each LSR called upon to perform path computation (and even the 393 offline management tools described in section 3.1) may abdicate the 394 task to a PCE of its choice. The selection of PCE(s) may be driven by 395 static configuration or the dynamic discovery by means of IGP or BGP 396 extensions. 398 3.4.1. Multi-Domain Visibility Computation 400 A PCE may have full visibility, perhaps through connectivity to 401 multiple domains. In this case it is able to supply a full explicit 402 path as in section 3.2.1. 404 3.4.2. Path Computation Use of PCE When Preserving Confidentiality 406 Note that although a centralized PCE or multiple collaborative PCEs 407 may have full visibility into one or more domains, it may be 408 desirable (e.g to preserve confidentiality) that the full path is not 409 provided to the ingress LSR. Instead, a partial path is supplied (as 410 in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are 411 required to make further requests for each successive segment of the 412 path. 414 In this way an end-to-end path may be computed using the full network 415 capabilities, but confidentiality between domains may be preserved. 416 Optionally, the PCE(s) may compute the entire path at the first 417 request and hold it in storage for subsequent requests, or it may 418 recompute the best path on each request or at regular intervals. 420 It may be the case that the centralized PCE or the collaboration 421 between PCEs may define a trust relationship greater than that 422 normally operational between domains. 424 3.4.3. Per-Domain Computation Servers 426 A third way that PCEs may be used is simply to have one (or more) per 427 domain. Each LSR within a domain that wishes to derive a path across 428 the domain may consult its local PCE. 430 This mechanism could be used for all path computations within the 431 domain, or specifically limited to computations for LSPs that will 432 leave the domain where external connectivity information can then be 433 restricted to just the PCE. 435 3.5. Optimal Path Computation 437 An optimal route might be defined as the route that would be computed 438 in the absence of domain boundaries. Another constraint to the 439 definition of 'optimal' might be to reduce or limit the number of 440 domains crossed by the LSP. It is easy to construct examples 441 that show that partitioning a network into domains, and the resulting 442 loss or aggregation of routing information may lead to the 443 computation of routes that are other than optimal. It is impossible 444 to guarantee optimal routing in the presence of aggregation / 445 abstraction / summarization of routing information. 447 It is beyond the scope of this document to define what is an optimum 448 path for an inter-domain TE LSP. This debate is abdicated in favor of 449 requirements documents and applicability statements. Note, however, 450 that the meaning of certain computation metrics may differ between 451 domains (see section 5.6). 453 4. Distributing Reachability and TE Information 455 The path computation techniques described in the previous section 456 make certain demands upon the distribution of reachability 457 information and the TE capabilities of nodes and links within domains 458 as well as the TE connectivity across domains. 460 Currently, TE information is distributed within domains by additions 461 to IGPs [RFC3630], [RFC3784]. 463 In cases where two domains are interconnected by one or more links 464 (that is, the domain boundary falls on a link rather than on a node), 465 there SHOULD be a mechanism to distribute the TE information 466 associated with the inter-domain links to the corresponding domains. 467 This would facilitate better path computation and reduce TE-related 468 crankbacks on these links. 470 Where a domain is a subset of an IGP area, filtering of TE 471 information may be applied at the domain boundary. This filtering may 472 be one way, or two way. 474 Where information needs to reach a PCE that spans multiple domains, 475 the PCE may snoop on the IGP traffic in each domain, or play an 476 active part as an IGP-capable node in each domain. The PCE might also 477 receive TEDB updates from a proxy within the domain. 479 It could be possible that an LSR that performs path computation (for 480 example, an ingress LSR) obtains the topology and TE information of 481 not just its own domain, but other domains as well. This information 482 may be subject to filtering applied by the advertising domain (for 483 example, the information may be limited to FAs across other domains, 484 or the information may be aggregated or abstracted). 486 Where any cross-domain reachability and TE information needs to be 487 advertised, consideration must be given to TE extensions to BGP, and 488 how these may be fed to the IGPs. Techniques for inter-domain TE 489 aggregation are also for further study. However, it must be noted 490 that any extensions that cause a significant increase in the amount 491 of processing (such as aggregation computation) at domain boundaries, 492 or a significant increase in the amount of information flooded (such 493 as detailed TE information) need to be treated with extreme caution 494 and compared carefully with the scaling requirements expressed in 495 [INTER-AREA] and [INTER-AS]. 497 5. Comments on Advanced Functions 499 This section provides some non-definitive comments on the constraints 500 placed on advanced MPLS TE functions by inter-domain MPLS. It does 501 not attempt to state the implications of using one inter-domain 502 technique or another. Such material is deferred to appropriate 503 applicability statements where statements about the capabilities of 504 existing or future signaling, routing and computation techniques to 505 deliver the functions listed should be made. 507 5.1. LSP Re-Optimization 509 Re-optimization is the process of moving a TE LSP from one path to 510 another, more preferable path (where no attempt is made in this 511 document to define 'preferable' as no attempt was made to define 512 'optimal'). Make-before-break techniques are usually applied to 513 ensure that traffic is disrupted as little as possible. The Shared 514 Explicit style is usually used to avoid double booking of network 515 resources. 517 Re-optimization may be available within a single domain. 518 Alternatively, re-optimization may involve a change in route across 519 several domains or might involve a choice of different transit 520 domains. 522 Re-optimization requires that all or part of the path of the LSP be 523 re-computed. The techniques used may be selected as described in 524 section 3, and this will influence whether the whole or part of the 525 path is re-optimized. 527 The trigger for path computation and re-optimization may be an 528 operator request, a timer, or information about a change in 529 availability of network resources. This trigger MUST be applied to 530 the point in the network that requests re-computation and controls 531 re-optimization and may require additional signaling. 533 Note also that where multiple diverse paths are applied end-to-end 534 (i.e. not simply within protection domains - see section 5.5) the 535 point of calculation for re-optimization (whether it is PCE, ingress, 536 or domain entry point) needs to know all such paths before attempting 537 re-optimization of any one path. 539 5.2. LSP Setup Failure 541 When an inter-domain LSP setup fails in some domain other than the 542 first, various options are available for reporting and retrying the 543 LSP. 545 In the first instance, a retry may be attempted within the domain 546 that contains the failure. That retry may be attempted by nodes 547 wholly within the domain, or the failure may be referred back to the 548 LSR at the domain boundary. 550 If the failure cannot be bypassed within the domain where the failure 551 occurred (perhaps there is no suitable alternate route, perhaps 552 rerouting is not allowed by domain policy, or perhaps the Path 553 message specifically bans such action), the error MUST be reported 554 back to the previous or head-end domain. 556 Subsequent repair attempts may be made by domains further upstream, 557 but will only be properly effective if sufficient information about 558 the failure and other failed repair attempts is also passed back 559 upstream [CRANKBACK]. Note that there is a tension between this 560 requirement and that of confidentiality although crankback 561 aggregation may be applicable at domain boundaries. 563 Further attempts to signal the failed LSP may apply the information 564 about the failures as constraints to path computation, or may signal 565 them as specific path exclusions [EXCLUDE]. 567 When requested by signaling, the failure may also be systematically 568 reported to the head-end LSR. 570 5.3. LSP Repair 572 An LSP that fails after it has been established may be repaired 573 dynamically by re-routing. The behavior in this case is either like 574 that for re-optimization, or for handling setup failures (see 575 previous two sections). 577 Fast Reroute may also be used (see below). 579 5.4. Fast Reroute 581 MPLS Traffic Engineering Fast Reroute ([FRR]) defines local 582 protection schemes intended to provide fast recovery (in 10s of 583 msecs) of fast-reroutable TE LSPs upon link/SRLG/Node failure. A 584 backup TE LSP is configured and signaled at each hop, and activated 585 upon detecting or being informed of a network element failure. The 586 node immediately upstream of the failure (called the PLR - Point of 587 Local Repair) reroutes the set of protected TE LSPs onto the 588 appropriate backup tunnel(s) and around the failed resource. 590 In the context of inter-domain TE, there are several different 591 failure scenarios that must be analyzed. Provision of suitable 592 solutions may be further complicated by the fact that [FRR] specifies 593 two distinct modes of operation referred to as the "one to one mode" 594 and the "facility back-up mode". 596 The failure scenarios specific to inter-domain TE are as follows: 598 - Failure of a domain edge node that is present in both domains. 599 There are two sub-cases: 601 - The PLR and the MP are in the same domain 603 - The PLR and the MP are in different domains. 605 - Failure of a domain edge node that is only present in one of the 606 domains. 608 - Failure of an inter-domain link. 610 The techniques that must be employed to use Fast Reroute for the 611 different methods of signaling LSPs identified in section 2 differ 612 considerably. These should be explained further in applicability 613 statements of, in the case, of a change in base behavior, in 614 implementation guidelines specific to the signaling techniques. 616 Note that after local repair has been performed, it may be desirable 617 to re-optimize the LSP (see section 5.1). If the point of 618 re-optimization (for example the ingress LSR) lies in a different 619 domain to the failure, it may rely on the delivery of a PathErr or 620 Notify message to inform it of the local repair event. 622 It is important to note that Fast Reroute techniques are only 623 applicable to packet switching networks because other network 624 technologies cannot apply label stacking within the same switching 625 type. Segment protection [SEG-PROT] provides a suitable alternative 626 that is applicable to packet and non-packet networks. 628 5.5. Comments on Path Diversity 630 Diverse paths may be required in support of load sharing and/or 631 protection. Such diverse paths may be required to be node diverse, 632 link diverse, fully path diverse (that is, link and node diverse), or 633 SRLG diverse. 635 Diverse path computation is a classic problem familiar to all graph 636 theory majors. The problem is compounded when there are areas of 637 'private knowledge' such as when domains do not share topology 638 information. The problem is generally considered to be easier and 639 more efficient when the diverse paths can be computed 640 'simultaneously' on the fullest set of information. That being said, 641 various techniques (out of the scope of this document) exist to 642 ensure end-to-end path diversity across multiple domains. 644 Many network technologies utilize 'protection domains' because they 645 fit well with the capabilities of the technology. As a result, many 646 domains are operated as protection domains. In this model, protection 647 paths converge at domain boundaries. 649 Note that the question of SRLG identification is not yet fully 650 answered. There are two classes of SRLG: 652 - those that indicate resources that are all contained witin one 653 domain 655 - those that span domains. 657 The former might be identified using a combination of domain ID and 658 an SRLG ID that is administered by the domain. The latter requires 659 a wider scope to the SRLG ID, and it is not clear how this would be 660 administered. 662 5.6. Domain-Specific Constraints 664 While the meaning of certain constraints, like bandwidth, can be 665 assumed to be constant across different domains, other TE constraints 666 (such as resource affinity, color, metric, priority, etc.) may have 667 different meanings in different domains and this may impact the 668 ability to support DiffServ-aware MPLS, or to manage pre-emption. 670 In order to achieve consistent meaning and LSP establishment, this 671 fact must be considered when performing constraint-based path 672 computation or when signaling across domain boundaries. 674 A mapping function can be derived for most constraints based on 675 policy agreements between the Domain administrators. The details of 676 such a mapping function are outside the scope of this document, but 677 it is important to note that the default behavior MUST either be 678 that a constant mapping is applied or that any requirement to apply 679 these constraints across a domain boundary must fail in the absence 680 of explicit mapping rules. 682 5.7. Policy Control 684 Domain boundaries are natural points for policy control. There is 685 little to add on this subject except to note that a TE LSP that 686 cannot be established on a path through one domain because of a 687 policy applied at the domain boundary, may be satisfactorily 688 established using a path that avoids the demurring domain. In any 689 case, when a TE LSP signaling attempt is rejected due to 690 non-compliance with some policy constraint, this SHOULD be reflected 691 to the ingress LSR. 693 5.8. Inter-domain OAM 695 Some elements of OAM may be intentionally confined within a domain. 696 Others (such as end-to-end liveness and connectivity testing) clearly 697 need to span the entire multi-domain TE LSP. Where issues of 698 confidentiality are strong, collaboration between PCEs or domain 699 boundary nodes might be required in order to provide end-to-end OAM. 701 The different signaling mechanisms described above may need 702 refinements to [LSPPING], [BFD-MPLS] or the use of [TUNTRACE] to gain 703 full end-to-end visibility. These protocols should, however, be 704 considered in the light of confidentiality requirements. 706 Route recording is a commonly used feature of signaling that provides 707 OAM information about the path of an established LSP. When an LSP 708 traverses a domain boundary, the border node may remove or aggregate 709 some of the recorded information for confidentiality or other policy 710 reasons. 712 5.9. Point-to-Multipoint 714 Inter-domain point-to-multipoint (P2MP) requirements are explicitly 715 out of scope of this document. They may be covered by other documents 716 dependent on the details of MPLS TE P2MP solutions. 718 5.10. Applicability to Non-Packet Technologies 720 Non-packet switching technologies may present particular issues for 721 inter-domain LSPs. While packet switching networks may utilize 722 control planes built on MPLS or GMPLS technology, non-packet networks 723 are limited to GMPLS. 725 The specific architectural considerations and requirements for 726 inter-domain LSP setup in non-packet networks are covered in a 727 separate document [GMPLS-AS]. 729 6. Security Considerations 731 Requirements for security within domains are unchanged from [RFC3209] 732 and [RFC3473], but requirements for inter-domain security are, if 733 anything, more significant. 735 Authentication techniques identified for use with RSVP-TE can only 736 operate across domain boundaries if there is coordination between the 737 administrators of those domains. 739 Confidentiality may also be considered to be security factors. 741 Applicability statements for particular combinations of signaling, 742 routing and path computation techniques are expected to contain 743 detailed security sections. 745 7. IANA Considerations 747 This document makes no requests for any IANA action. 749 8. Acknowledgements 751 The authors would like to extend their warmest thanks to Kireeti 752 Kompella for convincing them to expend effort on this document. 754 Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their 755 review and suggestions on the text. 757 9. Intellectual Property Considerations 759 The IETF takes no position regarding the validity or scope of any 760 Intellectual Property Rights or other rights that might be claimed to 761 pertain to the implementation or use of the technology described in 762 this document or the extent to which any license under such rights 763 might or might not be available; nor does it represent that it has 764 made any independent effort to identify any such rights. Information 765 on the procedures with respect to rights in RFC documents can be 766 found in BCP 78 and BCP 79. 768 Copies of IPR disclosures made to the IETF Secretariat and any 769 assurances of licenses to be made available, or the result of an 770 attempt made to obtain a general license or permission for the use of 771 such proprietary rights by implementers or users of this 772 specification can be obtained from the IETF on-line IPR repository at 773 http://www.ietf.org/ipr. 775 The IETF invites any interested party to bring to its attention any 776 copyrights, patents or patent applications, or other proprietary 777 rights that may cover technology that may be required to implement 778 this standard. Please address the information to the IETF at 779 ietf-ipr@ietf.org. 781 10. Normative References 783 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 784 Requirement Levels", BCP 14, RFC 2119, March 1997. 786 [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", 787 RFC 3209, December 2001. 789 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label 790 Switching (GMPLS) Signaling - Resource ReserVation 791 Protocol-Traffic Engineering (RSVP-TE) Extensions", 792 RFC 3473, January 2003. 794 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 795 RFC 3667, February 2004. 797 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 798 Technology", BCP 79, RFC 3668, February 2004. 800 [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with 801 Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, 802 work in progress. 804 [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of 805 Inter-Area and Inter-AS MPLS Traffic Engineering", 806 draft-ietf-tewg-interarea-mpls-te-req, work in 807 progress. 809 [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic 810 Engineering requirements", 811 draft-ietf-tewg-interas-mpls-te-req, work in progress. 813 [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with 814 Generalized MPLS TE", 815 draft-ayyangar-ccamp-lsp-stitching, work in progress. 817 [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path 818 Computation Element (PCE) Architecture", 819 draft-ash-pce-architecture, work in progress. 821 11. Informational References 823 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 824 Extensions to OSPF Version 2", RFC 3630, September 2003 826 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 827 Engineering", RFC 3784, June 2004. 828 [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of 829 Attributes for Multiprotocol Label Switching (MPLS) 830 Label Switched Path (LSP) Establishment Using RSVP-TE", 831 draft-ietf-mpls-rsvpte-attributes, work in progress. 833 [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work 834 in progress. 836 [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for 837 MPLS Signaling", draft-ietf-ccamp-crankback, 838 work in progress. 840 [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, 841 draft-ietf-ccamp-rsvp-te-exclude-route, work in 842 progress. 844 [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 845 for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, 846 work in progress. 848 [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS 849 Traffic Engineering Requirements", 850 draft-otani-ccamp-interas-GMPLS-TE, work in progress. 852 [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness 853 in MPLS", draft-ietf-mpls-lsp-ping, work in progress. 855 [MRN] K. Shiomoto, et al., "Requirements for GMPLS-based 856 multi-region and multi-layer networks", 857 draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. 859 [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 860 Model", draft-ietf-ccamp-gmpls-overlay, work in 861 progress. 863 [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, 864 A., "GMPLS Based Segment Recovery", 865 draft-ietf-ccamp-gmpls-segment-recovery, work in 866 progress. 868 [TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol 869 (GTTP) Specification", draft-ietf-ccamp-tunproto, 870 work in progress. 872 12. Authors' Addresses 874 Adrian Farrel 875 Old Dog Consulting 876 EMail: adrian@olddog.co.uk 878 Jean-Philippe Vasseur 879 Cisco Systems, Inc. 880 300 Beaver Brook Road 881 Boxborough , MA - 01719 882 USA 883 Email: jpv@cisco.com 885 Arthi Ayyangar 886 Juniper Networks, Inc 887 1194 N.Mathilda Ave 888 Sunnyvale, CA 94089 889 USA 890 Email: arthi@juniper.net 892 13. Full Copyright Statement 894 Copyright (C) The Internet Society (2005). This document is subject 895 to the rights, licenses and restrictions contained in BCP 78, and 896 except as set forth therein, the authors retain all their rights. 898 This document and the information contained herein are provided on an 899 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 900 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 901 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 902 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 903 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 904 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.