idnits 2.17.1 draft-ietf-ccamp-inter-domain-framework-00.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 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 672. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 779), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2004) is 7188 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 687, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'OVERLAY' is defined on line 747, 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) == Outdated reference: A later version (-03) exists of draft-ietf-tewg-interarea-mpls-te-req-02 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-interarea-mpls-te-req (ref. 'INTER-AREA') == Outdated reference: A later version (-09) exists of draft-ietf-tewg-interas-mpls-te-req-07 ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-interas-mpls-te-req (ref. 'INTER-AS') -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) == Outdated reference: A later version (-05) exists of draft-ietf-mpls-rsvpte-attributes-03 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-crankback-01 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-rsvp-te-exclude-route-01 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-lsp-fastreroute-06 == Outdated reference: A later version (-13) exists of draft-ietf-mpls-lsp-ping-05 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-gmpls-overlay-04 == Outdated reference: A later version (-01) exists of draft-ietf-ccamp-tunproto-00 Summary: 13 errors (**), 0 flaws (~~), 15 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Adrian Farrel 3 IETF Internet Draft Olddog Consulting 4 Proposed Status: Informational 5 Expires: January 2004 Jean-Philippe Vasseur 6 Cisco Systems, Inc. 8 Arthi Ayyangar 9 Juniper Networks 11 August 2004 13 draft-ietf-ccamp-inter-domain-framework-00.txt 15 A Framework for Inter-Domain MPLS Traffic Engineering 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance with 22 RFC 3668. 24 Working documents of the Internet Engineering Task Force (IETF), its 25 areas, and its working groups. Note that other groups may also 26 distribute working documents as 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. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document provides a framework for establishing and controlling 45 Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 46 Label Switched Paths (LSPs) in multi-domain networks. 48 For the purposes of this document, a domain is considered to be any 49 collection of network elements within a common sphere of address 50 management or path computational responsibility. Examples of such 51 domains include IGP areas and Autonomous Systems. 53 1. Introduction 55 The Traffic Engineering Working Group has developed requirements for 56 inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and 57 [INTER-AS]. 59 Various proposals have subsequently been made to address some or all 60 of these requirements through extensions to the RSVP-TE and IGP 61 (ISIS, OSPF) protocols and procedures. 63 This document introduces the techniques for establishing TE LSPs 64 across multiple domains. The functional components of these 65 techniques are separated into the mechanisms for discovering 66 reachability and TE information, for computing the paths of LSPs, and 67 for signaling the LSPs. Note that the aim is this document is not to 68 detail each of those techniques which are covered in separate 69 documents, but rather to propose a framework for inter-domain MPLS 70 Traffic Engineering. 72 For the purposes of this document, a domain is considered to be any 73 collection of network elements within a common sphere of address 74 management or path computational responsibility. Examples of such 75 domains include IGP areas and Autonomous Systems. However, domains of 76 computational responsibility may also exist as sub-domains of areas 77 or ASs. Wholly or partially overlapping domains are not within the 78 scope of this document. 80 1.1. Nested Domains 82 Nested domains are outside the scope of this document. It may be that 83 some domains that are nested administratively or for the purposes of 84 address space management can be considered as adjacent domains for 85 the purposes of this document, however the fact that the domains are 86 nested is then immaterial. 88 In the context of MPLS TE, domain A is considered to be nested within 89 domain B if domain A is wholly contained in Domain B, and domain B is 90 fully or partially aware of the TE characteristics and topology of 91 domain A. 93 For further consideration of nested domains see [MRN] 95 1.2. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Signaling Options 103 Three distinct options for signaling TE LSPs across multiple domains 104 are identified. The choice of which options to use may be influenced 105 by the path computation technique used (see section 3), although some 106 path computation may apply to multiple TE LSP types. The choice may 107 further depend on the application to which the TE LSPs are put and 108 the nature, topology and switching capabilities of the network. 110 A comparison of the usages of the different signaling options is 111 beyond the scope of this document and should be the subject of a 112 separate applicability statement. 114 2.1. LSP Nesting 116 Forwarding Adjacencies (FAs) are introduced and explained in detail 117 in [HIER]. No further description is necessary in this document. 119 FAs can be used in support of inter-domain TE LSPs. In particular, an 120 FA may be used to achieve connectivity between any pair of LSRs 121 within a domain. The ingress and egress of the FA LSP could be the 122 edge nodes of the domain in which case connectivity is achieved 123 across the entire domain, or they could be any other pair of LSRs in 124 the domain. 126 The technique of carrying one TE LSP within another is termed LSP 127 nesting. An FA may provide a TE LSP tunnel to transport (i.e. nest) 128 multiple TE LSPs along a common part of their paths. Alternatively, a 129 TE LSP may carry (i.e. nest) a single LSP in a one-to-one mapping. 131 The signaling trigger for the establishment of an FA LSP may be the 132 receipt of a signaling request for the TE LSP that it will carry, or 133 may be a management action to 'pre-engineer' a domain to be crossed 134 by TE LSPs that would be used as FAs by the traffic that has to 135 traverse the domain. Furthermore, the mapping (inheritance rules) 136 between attributes of the nested and FA LSPs (including bandwidth) 137 may be statically pre-configured or, for on-demand FA LSPs, may be 138 dynamic according to the properties of the nested LSPs. 140 Note that a hierarchical LSP may be constructed to span multiple 141 domains or parts of domains, however how or whether such an LSP could 142 be advertised as an FA that spans domains is open for study. The end 143 points of a hierarchical LSP are not necessarily on domain 144 boundaries, so nesting is not limited to domain boundaries. 146 Note also that the IGP/EGP routing topology is maintained unaffected 147 by the LSP connectivity and TE links introduced by FA LSPs. That is, 148 the routing protocols do not exchange messages over the FA LSPs, and 149 such LSPs do not create adjacencies between routers. During this 150 operation the SENDER_TEMPLATE and SESSION objects remain unchanged 151 along the entire length of the LSP. 153 2.2. Contiguous LSP 155 A single contiguous LSP is established from ingress to egress in a 156 single signaling exchange. No further LSPs are required be 157 established to support this LSP. Signaling occurs between adjacent 158 neighbors only (no tunneling), and hop-by-hop signaling is used. 160 2.3. LSP Stitching 162 In the LSP stitching model separate LSPs (referred to as a TE LSP 163 segments) are established and are "stitched" together in the data 164 plane so that a single end-to-end label switched path is achieved. 165 The distinction is that the component LSP segments are signaled as 166 distinct TE LSPs in the control plane. Each signaled TE LSP segment 167 has a different source and destination. 169 LSP stitching can be used in support of inter-domain TE LSPs. In 170 particular, an LSP segment may be used to achieve connectivity 171 between any pair of LSRs within a domain. The ingress and egress of 172 the LSP segment could be the edge nodes of the domain in which case 173 connectivity is achieved across the entire domain, or they could be 174 any other pair of LSRs in the domain. 176 The signaling trigger for the establishment of a TE LSP segment may 177 be the establishment of the previous TE LSP segment, the receipt of 178 setup request for TE LSP that it plans to stitch to a local TE LSP 179 segment, or may be a management action. 181 2.4. Hybrid Methods 183 There is nothing to prevent the mixture of signaling methods 184 described above when establishing a single, end-to-end, inter-domain 185 TE LSP. It may be desirable in this case for the choice of the 186 various methods to be indicated along the path perhaps through the 187 RRO. 189 If there is a desire to restrict which methods are used, this MUST be 190 signaled as described in the next section. 192 2.5. Control of Downstream Choice of Signaling Method 194 Notwithstanding the previous section, an ingress LSR MAY wish to 195 restrict the signaling methods applied to a particular LSP at domain 196 boundaries across the network. Such control, where it is required, 197 may be achieved by the definition of appropriate new flags in the 198 SESSION-ATTRIBUTE object or the Attributes Flags TLV of the 199 LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to 200 provide this level of control, the functional requirement to control 201 the way in which the network delivers a service must be established 202 and due consideration must be given to the impact on 203 interoperability. 205 3. Path Computation Techniques 207 The discussion of path computation techniques within this document is 208 limited significantly to the determination of where computation may 209 take place and what components of the full path may be determined. 211 The techniques used are closely tied to the signaling methodologies 212 described in the previous section in that certain computation 213 techniques may require the use of particular signaling approaches and 214 vice versa. 216 Any discussion of the appropriateness of a particular path 217 computation technique in any given circumstance is beyond the scope 218 of this document and should be described in a separate applicability 219 statement. 221 3.1. Management Configuration 223 Path computation may be performed by offline tools or by a network 224 planner. The resultant path may be supplied to the ingress LSR as 225 part of the TE LSP or service request, and encoded by the ingress LSR 226 as an ERO on the Path message that is sent out. 228 There is no reason why the path provided by the operator should not 229 span multiple domains if the relevant information is available to the 230 planner or the offline tool. The definition of what information is 231 needed to perform this operation and how that information is 232 gathered, is outside the scope of this document. 234 3.2. Head End Computation 236 The head end, or ingress, LSR may assume responsibility for path 237 computation when the operator supplies part or none of the explicit 238 path. The operator MUST, in any case, supply at least the destination 239 address (egress) of the LSP. 241 3.2.1. Multi-Domain Visibility Computation 243 If the ingress has sufficient visibility of the topology and TE 244 information for all of the domains across which it will route the LSP 245 to its destination then it may compute and provide the entire path. 246 The quality of this path is best if the ingress has full visibility 247 into all relevant domains rather than just sufficient visibility to 248 provide some path to the destination. 250 Extreme caution must be exercised in consideration of the 251 distribution of the requisite TE information. See section 4. 253 3.2.2. Partial Visibility Computation 255 It may be that the ingress does not have full visibility of the 256 topology of all domains, but does have information about the 257 connectedness of the domains and the TE resource availability across 258 the domains. In this case, the ingress is not able to provide a fully 259 specified strict explicit path from ingress to egress. However, the 260 ingress can supply an explicit path that comprises: 261 - explicit hops from ingress to the local domain boundary 262 - loose hops representing the domain entry points across the network 263 - a loose hop identifying the egress. 265 Alternatively, the explicit path may be expressed as: 266 - explicit hops from ingress to the local domain boundary 267 - strict hops giving abstract nodes representing each domain in turn 268 - a loose hop identifying the egress. 270 These two explicit path formats may be mixed. 272 This form of explicit path relies on some further computation 273 technique being applied at the domain boundaries. See section 3.3. 275 As with the multi-domain visibility option, extreme caution must be 276 exercised in consideration of the distribution of the requisite TE 277 information. See section 4. 279 3.2.3. Local Domain Visibility Computation 281 A final possibility for ingress-based computation is that the ingress 282 LSR has visibility only within its own domain, and connectivity 283 information only as far as determining one or more domain exit points 284 that may be suitable for carrying the LSP to its egress. 286 In this case the ingress builds an explicit path that comprises just: 287 - explicit hops from ingress to the local domain boundary 288 - a loose hop identifying the egress. 290 3.3. Domain Boundary Computation 292 If the partial explicit path methods described in sections 3.2.2 or 293 3.2.3 are applied then the LSR at each domain boundary is responsible 294 for ensuring that there is sufficient path information added to the 295 Path message to carry it at least to the next domain boundary (that 296 is, out of the new domain). 298 If the LSR at the domain boundary has full visibility to the egress 299 then it can supply the entire explicit path. Note however, that the 300 ERO processing rules of [RFC3209] state that it SHOULD only update 301 the ERO as far as the next specified hop (that is, the next domain 302 boundary if one was supplied in the original ERO) and, of course, 303 MUST NOT insert ERO subobjects immediately before a strict hop. 305 If the LSR at the domain boundary has only partial visibility (using 306 the definitions of section 3.2.2) it will fill in the path as far as 307 the next domain boundary, and will supply further domain/domain 308 boundary information if not already present in the ERO. 310 If the LSR at the domain boundary has only local visibility into the 311 immediate domain it will simply add information to the ERO to carry 312 the Path message as far as the next domain boundary. 314 3.4. Path Computation Element 316 The computation techniques in sections 3.2 and 3.3 rely on topology 317 and TE information being distributed to the ingress LSR and those 318 LSRs at domain boundaries. These LSRs are responsible for computing 319 paths. Note that there may be scaling concerns with distributing the 320 required information - see section 4. 322 An alternative technique places the responsibility for path 323 computation with a Path Computation Element (PCE). There may be 324 either a centralized PCE, or multiple PCEs (each having a local 325 visibility and collaborating in a distributed fashion to compute an 326 end to end path) across the entire network and even within any one 327 domain. The PCE may collect topology and TE information from the same 328 sources as would be used by LSRs in the paragraph, or though other 329 means. 331 Each LSR called upon to perform path computation (and even the 332 offline management tools described in section 3.1) may abdicate the 333 task to a PCE of its choice. The selection of PCE(s) may be driven by 334 static configuration or the dynamic discovery by means of IGP or BGP 335 extensions. 337 3.4.1. Multi-Domain Visibility Computation 339 A PCE may have full visibility, perhaps through connectivity to 340 multiple domains. In this case it is able to supply a full explicit 341 path as in section 3.2.1. 343 3.4.2. Path Computation Use of PCE When Preserving Confidentiality 345 Note that although a centralized PCE or multiple collaborative PCEs 346 may have full visibility into one or more domains, it may be 347 desirable (e.g to preserve confidentiality) that the full path is not 348 provided to the ingress LSR. Instead, a partial path is supplied (as 349 in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are 350 required to make further requests for each successive segment of the 351 path. 353 In this way an end-to-end path may be computed using the full network 354 capabilities, but confidentiality between domains may be preserved. 355 Optionally, the PCE(s) may compute the entire path at the first 356 request and hold it in storage for subsequent requests, or it may 357 recompute the best path on each request or at regular intervals. 359 It may be the case that the centralized PCE or the collaboration 360 between PCEs may define a trust relationship greater than that 361 normally operational between domains. 363 3.4.3. Per-Domain Computation Servers 365 A third way that PCEs may be used is simply to have one (or more) per 366 domain. Each LSR within a domain that wishes to derive a path across 367 the domain may consult its local PCE. 369 This mechanism could be used for all path computations within the 370 domain, or specifically limited to computations for LSPs that will 371 leave the domain where external connectivity information can then be 372 restricted to just the PCE. 374 3.5. Optimal Path Computation 376 An optimal route might be defined as the route that would be computed 377 in the absence of domain boundaries. It is easy to construct examples 378 that show that partitioning a network into domains, and the resulting 379 loss or aggregation of routing information may lead to the 380 computation of routes that are other than optimal. It is impossible 381 to guarantee optimal routing in the presence of aggregation / 382 abstraction / summarization of routing information. 384 It is beyond the scope of this document to define what is an optimum 385 path for an inter-domain TE LSP. This debate is abdicated in favor of 386 requirements documents and applicability statements. Note, however, 387 that the meaning of certain computation metrics may differ between 388 domains (see section 5.6). 390 4. Distributing Reachability and TE Information 392 The path computation techniques described in the previous section 393 make certain demands upon the distribution of reachability 394 information and the TE capabilities of nodes and links within domains 395 as well as the TE connectivity across domains. 397 Currently, TE information is distributed within domains by additions 398 to IGPs [RFC3630], [RFC3784]. 400 In cases where two domains are interconnected by one or more links 401 (that is, the domain boundary falls on a link rather than on a node), 402 there SHOULD be a mechanism to distribute the TE information 403 associated with the links to the corresponding domains. This would 404 facilitate better path computation and reduce TE-related crankbacks 405 on these links. 407 Where a domain is a subset of an IGP area, filtering of TE 408 information may be applied at the domain boundary. This filtering may 409 be one way, or two way. 411 Where information needs to reach a PCE that spans multiple domains, 412 the PCE may snoop on the IGP traffic in each domain, or play an 413 active part as an IGP-capable node in each domain. The PCE might also 414 receive TEDB updates from a proxy within the domain. 416 It could be possible that an LSR that performs path computation (for 417 example, and ingress LSR) obtains the topology and TE information of 418 not just its own domain, but other domains as well. This information 419 may be subject to filtering applied by the advertising domain (for 420 example, the information may be limited to FAs across other domains, 421 or the information may be aggregated or abstracted). 423 Where any cross-domain reachability and TE information needs to be 424 advertised, consideration must be given to TE extensions to BGP, and 425 how these may be fed to the IGPs. Techniques for inter-domain TE 426 aggregation are also for further study. However, it must be noted 427 that any extensions that cause a significant increase in the amount 428 of processing (such as aggregation computation) at domain boundaries, 429 or a significant increase in the amount of information flooded (such 430 as detailed TE information) need to be treated with extreme caution 431 and compared carefully with the scaling requirements expressed in 432 [INTER-AREA] and [INTER-AS]. 434 5. Comments on Advanced Functions 436 This section provides some non-definitive comments on the constraints 437 placed on advanced MPLS TE functions by inter-domain MPLS. It does 438 not attempt to state the implications of using one inter-domain 439 technique or another. Such material is deferred to appropriate 440 applicability statements where statements about the capabilities of 441 existing or future signaling, routing and computation techniques to 442 deliver the functions listed should be made. 444 5.1. LSP Re-Optimization 446 Re-optimization is the process of moving a TE LSP from one path to 447 another, more preferable path (where no attempt is made in this 448 document to define 'preferable' as no attempt was made to define 449 'optimal'). Make-before-break techniques are usually applied to 450 ensure that traffic is disrupted as little as possible. The Shared 451 Explicit style is usually used to avoid double booking of network 452 resources. 454 Re-optimization may be available within a single domain. 455 Alternatively, re-optimization may involve a change in route across 456 several domains or might involve a choice of different transit 457 domains. 459 Re-optimization requires that all or part of the path of the LSP be 460 re-computed. The techniques used may be selected as described in 461 section 3, and this will influence whether the whole or part of the 462 path is re-optimized. 464 The trigger for path computation and re-optimization may be an 465 operator request, a timer, or information about a change in 466 availability of network resources. This trigger MUST be applied to 467 the point in the network that requests re-computation and controls 468 re-optimization and may require additional signaling. 470 Note also that where multiple diverse paths are applied end-to-end 471 (i.e. not simply within protection domains - see section 5.5) the 472 point of calculation for re-optimization (whether it is PCE, ingress, 473 or domain entry point) needs to know all such paths before attempting 474 re-optimization of any one path. 476 5.2. LSP Setup Failure 478 When an inter-domain LSP setup fails in some domain other than the 479 first, various options are available for reporting and retrying the 480 LSP. 482 In the first instance, a retry may be attempted within the domain 483 that contains the failure. That retry may be attempted by nodes 484 wholly within the domain, or the failure may be referred back to the 485 LSR at the domain boundary. 487 If the failure cannot be bypassed within the domain where the failure 488 occurred (perhaps there is no suitable alternate route, perhaps 489 rerouting is not allowed by domain policy, or perhaps the Path 490 message specifically bans such action), the error MUST be reported 491 back to the previous or head-end domain. 493 Subsequent repair attempts may be made by domains further upstream, 494 but will only be properly effective if sufficient information about 495 the failure and other failed repair attempts is also passed back 496 upstream [CRANKBACK]. Note that there is a tension between this 497 requirement and that of confidentiality although crankback 498 aggregation may be applicable at domain boundaries. 500 Further attempts to signal the failed LSP may apply the information 501 about the failures as constraints to path computation, or may signal 502 them as specific path exclusions [EXCLUDE]. 504 When requested by signaling, the failure may also be systematically 505 reported to the head-end LSR. 507 5.3. LSP Repair 509 An LSP that fails after it has been established may be repaired 510 dynamically by re-routing. The behavior in this case is either like 511 that for re-optimization, or for handling setup failures (see 512 previous two sections). 514 Fast Reroute may also be used (see below). 516 5.4. Fast Reroute 518 MPLS Traffic Engineering Fast Reroute ([FRR]) defines local 519 protection schemes intended to provide fast recovery (in 10s of 520 msecs) of fast-reroutable TE LSPs upon link/SRLG/Node failure. A 521 backup TE LSP is configured and signaled at each hop, and activated 522 upon detecting or being informed of a network element failure. The 523 node immediately upstream of the failure (called the PLR (Point of 524 Local Repair)) reroutes the set of protected TE LSPs onto the 525 appropriate backup tunnel(s) and around the failed resource. 527 In the context of inter-domain TE, there are several different 528 failure scenarios that must be analyzed. Provision of suitable 529 solutions may be further complicated by the fact that [FRR] specifies 530 two distinct modes of operation referred to as the "one to one mode" 531 and the "facility back-up mode". 533 The failure scenarios specific to inter-domain TE are as follows: 534 - Failure of a domain edge node that is present in both domains. 535 There are two sub-cases: 536 - The PLR and the MP are in the same domain 537 - The PLR and the MP are in different domains. 538 - Failure of a domain edge node that is only present in one of the 539 domains. 540 - Failure of an inter-domain link. 542 The techniques that must be employed to use Fast Reroute for the 543 different methods of signaling LSPs identified in section 2 differ 544 considerably. These should be explained further in applicability 545 statements of, in the case, of a change in base behavior, in 546 implementation guidelines specific to the signaling techniques. 548 Note that after local repair has been performed, it may be desirable 549 to re-optimize the LSP (see section 5.1). If the point of 550 re-optimization (for example the ingress LSR) lies in a different 551 domain to the failure, it may rely on the delivery of a PathErr or 552 Notify message to inform it of the local repair event. 554 5.5. Comments on Path Diversity 556 Diverse paths may be required in support of load sharing and/or 557 protection. Such diverse paths may be required to be node diverse, 558 link diverse, fully path diverse (that is, link and node diverse), or 559 SRLG diverse. 561 Diverse path computation is a classic problem familiar to all graph 562 theory majors. The problem is compounded when there are areas of 563 'private knowledge' such as when domains do not share topology 564 information. The problem is generally considered to be easier and 565 more efficient when the diverse paths can be computed 566 'simultaneously' on the fullest set of information. That being said, 567 various techniques (out of the scope of this document) exist to 568 ensure end to end path diversity across multiple domains. 570 Many network technologies utilize 'protection domains' because they 571 fit well with the capabilities of the technology. As a result, many 572 domains are operated as protection domains. In this model, protection 573 paths converge at domain boundaries. 575 5.6. Domain-Specific Constraints 577 While the meaning of certain constraints, like bandwidth, can be 578 assumed to be constant across different domains, other TE constraints 579 (such as resource affinity, color, metric, priority, etc.) may have 580 different meanings in different domains and this may impact the 581 ability to support DiffServ-aware MPLS, or to manage pre-emption. 583 In order to achieve consistent meaning and LSP establishment, this 584 fact must be considered when performing constraint-based path 585 computation or when signaling across domain boundaries. 587 A mapping function can be derived for most constraints based on 588 policy agreements between the Domain administrators. 590 5.7. Policy Control 592 Domain boundaries are natural points for policy control. There is 593 little to add on this subject except to note that a TE LSP that 594 cannot be established on a path through one domain because of a 595 policy applied at the domain boundary, may be satisfactorily 596 established using a path that avoids the demurring domain. In any 597 case, when a TE LSP signaling attempt is rejected due to non 598 compliance with some policy constraint, this SHOULD be reflected to 599 the ingress LSR. 601 5.8. Inter-domain OAM 603 Some elements of OAM may be intentionally confined within a domain. 604 Others (such as end-to-end liveness and connectivity testing) clearly 605 need to span the entire multi-domain TE LSP. Where issues of 606 confidentiality are strong, collaboration between PCEs or domain 607 boundary nodes might be required in order to provide end-to-end OAM. 609 The different signaling mechanisms described above may need 610 refinements to [LSPPING], [BFD-MPLS] or the use of [TUNTRACE] to gain 611 full end-to-end visibility. These protocols should, however, be 612 considered in the light of confidentiality requirements. 614 Route recording is a commonly used feature of signaling that provides 615 OAM information about the path of an established LSP. When an LSP 616 traverses a domain boundary, the border node may remove or aggregate 617 some of the recorded information for confidentiality or other policy 618 reasons. 620 5.9. Point to Multipoint 622 Inter-domain point-to-multipoint (P2MP) requirements are explicitly 623 out of scope of this document. They may be covered by other documents 624 dependent on the details of MPLS TE P2MP solutions. 626 6. Security Considerations 628 Requirements for security within domains are unchanged from [RFC3209] 629 and [RFC3473], but requirements for inter-domain security are, if 630 anything, more significant. 632 Authentication techniques identified for use with RSVP-TE can only 633 operate across domain boundaries if there is coordination between the 634 administrators of those domains. 636 Confidentiality may also be considered to be security factors. 638 Applicability statements for particular combinations of signaling, 639 routing and path computation techniques are expected to contain 640 detailed security sections. 642 7. Acknowledgements 644 The authors would like to extend their warmest thanks to Kireeti 645 Kompella for convincing them to expend efforts on this document. 647 Grateful thanks to Dimitri Papadimitriou and Tomohiro Otani for their 648 review and suggestions on the text. 650 8. Intellectual Property Considerations 652 The IETF takes no position regarding the validity or scope of any 653 Intellectual Property Rights or other rights that might be claimed to 654 pertain to the implementation or use of the technology described in 655 this document or the extent to which any license under such rights 656 might or might not be available; nor does it represent that it has 657 made any independent effort to identify any such rights. Information 658 on the procedures with respect to rights in RFC documents can be 659 found in BCP 78 and BCP 79. 661 Copies of IPR disclosures made to the IETF Secretariat and any 662 assurances of licenses to be made available, or the result of an 663 attempt made to obtain a general license or permission for the use of 664 such proprietary rights by implementers or users of this 665 specification can be obtained from the IETF on-line IPR repository at 666 http://www.ietf.org/ipr. 668 The IETF invites any interested party to bring to its attention any 669 copyrights, patents or patent applications, or other proprietary 670 rights that may cover technology that may be required to implement 671 this standard. Please address the information to the IETF at 672 ietf-ipr@ietf.org. 674 9. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, March 1997. 679 [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", 680 RFC 3209, December 2001. 682 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label 683 Switching (GMPLS) Signaling - Resource ReserVation 684 Protocol-Traffic Engineering (RSVP-TE) Extensions", 685 RFC 3473, January 2003. 687 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 688 RFC 3667, February 2004. 690 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 691 Technology", BCP 79, RFC 3668, February 2004. 693 [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with 694 Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08. 695 txt, March 2002 (work in progress). 697 [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of 698 Inter-Area and Inter-AS MPLS Traffic Engineering", 699 draft-ietf-tewg-interarea-mpls-te-req-02.txt, June 2004 700 (work in progress). 702 [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic 703 Engineering requirements", 704 draft-ietf-tewg-interas-mpls-te-req-07.txt, June 2004 705 (work in progress). 707 10. Informational References 709 [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 710 Extensions to OSPF Version 2", RFC 3630, September 2003 712 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 713 Engineering", RFC 3784, June 2004. 715 [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of 716 Attributes for Multiprotocol Label Switching (MPLS) 717 Label Switched Path (LSP) Establishment Using RSVP-TE", 718 draft-ietf-mpls-rsvpte-attributes-03.txt, March 2004 719 (work in progress). 721 [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", (work 722 in progress). 724 [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for 725 MPLS Signaling", draft-ietf-ccamp-crankback-01.txt, 726 January 2004 (work in progress). 728 [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, 729 draft-ietf-ccamp-rsvp-te-exclude-route-01.txt, December 730 2003 (work in progress). 732 [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 733 for LSP Tunnels", 734 draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt, 735 (work in progress). 737 [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness 738 in MPLS", Internet Draft 739 draft-ietf-mpls-lsp-ping-05.txt, February 2004 (work in 740 progress). 742 [MRN] Papadimitriou, D., et al., "Generalized MPLS 743 Architecture for Multi-Region Networks", 744 draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, 745 February 2004 (work in progress). 747 [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay 748 Model", draft-ietf-ccamp-gmpls-overlay-04.txt, April 749 2004 (work in progress). 751 [TUNTRACE] Bonica, R., et al., "Generic Tunnel Tracing Protocol 752 (GTTP) Specification", draft-ietf-ccamp-tunproto-00, 753 March 2004 (work in progress). 755 11. Authors' Addresses 757 Adrian Farrel 758 Old Dog Consulting 759 EMail: adrian@olddog.co.uk 761 Jean-Philippe Vasseur 762 Cisco Systems, Inc. 763 300 Beaver Brook Road 764 Boxborough , MA - 01719 765 USA 766 Email: jpv@cisco.com 768 Arthi Ayyangar 769 Juniper Networks, Inc 770 1194 N.Mathilda Ave 771 Sunnyvale, CA 94089 772 USA 773 Email: arthi@juniper.net 775 12. Full Copyright Statement 777 Copyright (C) The Internet Society (2004). This document is subject 778 to the rights, licenses and restrictions contained in BCP 78, and 779 except as set forth therein, the authors retain all their rights. 781 This document and the information contained herein are provided on an 782 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 783 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 784 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 785 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 786 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 787 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.