diff options
Diffstat (limited to 'doc/rfc/rfc4726.txt')
| -rw-r--r-- | doc/rfc/rfc4726.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc4726.txt b/doc/rfc/rfc4726.txt new file mode 100644 index 0000000..06a9f56 --- /dev/null +++ b/doc/rfc/rfc4726.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group A. Farrel +Request for Comments: 4726 Old Dog Consulting +Category: Informational J.-P. Vasseur + Cisco Systems, Inc. + A. Ayyangar + Nuova Systems + November 2006 + + + A Framework for Inter-Domain Multiprotocol Label Switching + Traffic Engineering + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2006). + +Abstract + + This document provides a framework for establishing and controlling + Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) + Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain + networks. + + For the purposes of this document, a domain is considered to be any + collection of network elements within a common sphere of address + management or path computational responsibility. Examples of such + domains include Interior Gateway Protocol (IGP) areas and Autonomous + Systems (ASes). + + + + + + + + + + + + + + + + + +Farrel, et al. Informational [Page 1] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Nested Domains .............................................3 + 2. Signaling Options ...............................................4 + 2.1. LSP Nesting ................................................4 + 2.2. Contiguous LSP .............................................5 + 2.3. LSP Stitching ..............................................5 + 2.4. Hybrid Methods .............................................6 + 2.5. Control of Downstream Choice of Signaling Method ...........6 + 3. Path Computation Techniques .....................................6 + 3.1. Management Configuration ...................................7 + 3.2. Head-End Computation .......................................7 + 3.2.1. Multi-Domain Visibility Computation .................7 + 3.2.2. Partial Visibility Computation ......................7 + 3.2.3. Local Domain Visibility Computation .................8 + 3.3. Domain Boundary Computation ................................8 + 3.4. Path Computation Element ...................................9 + 3.4.1. Multi-Domain Visibility Computation ................10 + 3.4.2. Path Computation Use of PCE When Preserving + Confidentiality ....................................10 + 3.4.3. Per-Domain Computation Elements ....................10 + 3.5. Optimal Path Computation ..................................11 + 4. Distributing Reachability and TE Information ...................11 + 5. Comments on Advanced Functions .................................12 + 5.1. LSP Re-Optimization .......................................12 + 5.2. LSP Setup Failure .........................................13 + 5.3. LSP Repair ................................................14 + 5.4. Fast Reroute ..............................................14 + 5.5. Comments on Path Diversity ................................15 + 5.6. Domain-Specific Constraints ...............................16 + 5.7. Policy Control ............................................17 + 5.8. Inter-Domain Operations and Management (OAM) ..............17 + 5.9. Point-to-Multipoint .......................................17 + 5.10. Applicability to Non-Packet Technologies .................17 + 6. Security Considerations ........................................18 + 7. Acknowledgements ...............................................19 + 8. Normative References ...........................................19 + 9. Informative References .........................................20 + + + + + + + + + + + + +Farrel, et al. Informational [Page 2] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + +1. Introduction + + The Traffic Engineering Working Group has developed requirements for + inter-area and inter-AS Multiprotocol Label Switching (MPLS) Traffic + Engineering in [RFC4105] and [RFC4216]. + + Various proposals have subsequently been made to address some or all + of these requirements through extensions to the Resource Reservation + Protocol Traffic Engineering extensions (RSVP-TE) and to the Interior + Gateway Protocols (IGPs) (i.e., Intermediate System to Intermediate + System (IS-IS) and OSPF). + + This document introduces the techniques for establishing Traffic + Engineered (TE) Label Switched Paths (LSPs) across multiple domains. + In this context and within the remainder of this document, we + consider all source-based and constraint-based routed LSPs and refer + to them interchangeably as "TE LSPs" or "LSPs". + + The functional components of these techniques are separated into the + mechanisms for discovering reachability and TE information, for + computing the paths of LSPs, and for signaling the LSPs. Note that + the aim of this document is not to detail each of those techniques, + which are covered in separate documents referenced from the sections + of this document that introduce the techniques, but rather to propose + a framework for inter-domain MPLS Traffic Engineering. + + Note that in the remainder of this document, the term "MPLS Traffic + Engineering" is used equally to apply to MPLS and Generalized MPLS + (GMPLS) traffic. Specific issues pertaining to the use of GMPLS in + inter-domain environments (for example, policy implications of the + use of the Link Management Protocol [RFC4204] on inter-domain links) + are covered in separate documents such as [GMPLS-AS]. + + For the purposes of this document, a domain is considered to be any + collection of network elements within a common sphere of address + management or path computational responsibility. Examples of such + domains include IGP areas and Autonomous Systems. Wholly or + partially overlapping domains (e.g., path computation sub-domains of + areas or ASes) are not within the scope of this document. + +1.1. Nested Domains + + Nested domains are outside the scope of this document. It may be + that some domains that are nested administratively or for the + purposes of address space management can be considered as adjacent + domains for the purposes of this document; however, the fact that the + domains are nested is then immaterial. In the context of MPLS TE, + domain A is considered to be nested within domain B if domain A is + + + +Farrel, et al. Informational [Page 3] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + wholly contained in domain B, and domain B is fully or partially + aware of the TE characteristics and topology of domain A. + +2. Signaling Options + + Three distinct options for signaling TE LSPs across multiple domains + are identified. The choice of which options to use may be influenced + by the path computation technique used (see section 3), although some + path computation techniques may apply to multiple signaling options. + The choice may further depend on the application to which the TE LSPs + are put and the nature, topology, and switching capabilities of the + network. + + A comparison of the usages of the different signaling options is + beyond the scope of this document and should be the subject of a + separate applicability statement. + +2.1. LSP Nesting + + Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are + discussed in further detail in [RFC4206]. Hierarchical LSPs may + optionally be advertised as TE links. Note that a hierarchical LSP + that spans multiple domains cannot be advertised in this way because + there is no concept of TE information that spans domains. + + Hierarchical LSPs can be used in support of inter-domain TE LSPs. In + particular, a hierarchical LSP may be used to achieve connectivity + between any pair of Label Switching Routers (LSRs) within a domain. + The ingress and egress of the hierarchical LSP could be the edge + nodes of the domain in which case connectivity is achieved across the + entire domain, or they could be any other pair of LSRs in the domain. + + The technique of carrying one TE LSP within another is termed LSP + nesting. A hierarchical LSP may provide a TE LSP tunnel to transport + (i.e., nest) multiple TE LSPs along a common part of their paths. + Alternatively, a TE LSP may carry (i.e., nest) a single LSP in a + one-to-one mapping. + + The signaling trigger for the establishment of a hierarchical LSP may + be the receipt of a signaling request for the TE LSP that it will + carry, or may be a management action to "pre-engineer" a domain to be + crossed by TE LSPs that would be used as hierarchical LSPs by the + traffic that has to traverse the domain. Furthermore, the mapping + (inheritance rules) between attributes of the nested and the + hierarchical LSPs (including bandwidth) may be statically pre- + configured or, for on-demand hierarchical LSPs, may be dynamic + + + + + +Farrel, et al. Informational [Page 4] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + according to the properties of the nested LSPs. Even in the dynamic + case, inheritance from the properties of the nested LSP(s) can be + complemented by local or domain-wide policy rules. + + Note that a hierarchical LSP may be constructed to span multiple + domains or parts of domains. However, such an LSP cannot be + advertised as a TE link that spans domains. The end points of a + hierarchical LSP are not necessarily on domain boundaries, so nesting + is not limited to domain boundaries. + + Note also that the Interior/Exterior Gateway Protocol (IGP/EGP) + routing topology is maintained unaffected by the LSP connectivity and + TE links introduced by hierarchical LSPs even if they are advertised + as TE links. That is, the routing protocols do not exchange messages + over the hierarchical LSPs, and LSPs are not used to create routing + adjacencies between routers. + + During the operation of establishing a nested LSP that uses a + hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain + unchanged along the entire length of the nested LSP, as do all other + objects that have end-to-end significance. + +2.2. Contiguous LSP + + A single contiguous LSP is established from ingress to egress in a + single signaling exchange. No further LSPs are required to be + established to support this LSP so that hierarchical or stitched LSPs + are not needed. + + A contiguous LSP uses the same Session/LSP ID along the whole of its + path (that is, at each LSR). The notions of "splicing" together + different LSPs or of "shuffling" Session or LSP identifiers are not + considered. + +2.3. LSP Stitching + + LSP Stitching is described in [STITCH]. In the LSP stitching model, + separate LSPs (referred to as a TE LSP segments) are established and + are "stitched" together in the data plane so that a single end-to-end + Label Switched Path is achieved. The distinction is that the + component LSP segments are signaled as distinct TE LSPs in the + control plane. Each signaled TE LSP segment has a different source + and destination. + + LSP stitching can be used in support of inter-domain TE LSPs. In + particular, an LSP segment may be used to achieve connectivity + between any pair of LSRs within a domain. The ingress and egress of + the LSP segment could be the edge nodes of the domain in which case + + + +Farrel, et al. Informational [Page 5] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + connectivity is achieved across the entire domain, or they could be + any other pair of LSRs in the domain. + + The signaling trigger for the establishment of a TE LSP segment may + be the establishment of the previous TE LSP segment, the receipt of a + setup request for TE LSP that it plans to stitch to a local TE LSP + segment, or a management action. + + LSP segments may be managed and advertised as TE links. + +2.4. Hybrid Methods + + There is nothing to prevent the mixture of signaling methods + described above when establishing a single, end-to-end, inter-domain + TE LSP. It may be desirable in this case for the choice of the + various methods to be reported along the path, perhaps through the + Record Route Object (RRO). + + If there is a desire to restrict which methods are used, this must be + signaled as described in the next section. + +2.5. Control of Downstream Choice of Signaling Method + + Notwithstanding the previous section, an ingress LSR may wish to + restrict the signaling methods applied to a particular LSP at domain + boundaries across the network. Such control, where it is required, + may be achieved by the definition of appropriate new flags in the + SESSION-ATTRIBUTE object or the Attributes Flags TLV of the + LSP_ATTRIBUTES object [RFC4420]. Before defining a mechanism to + provide this level of control, the functional requirement to control + the way in which the network delivers a service must be established. + Also, due consideration must be given to the impact on + interoperability since new mechanisms must be backwards compatible, + and care must be taken to avoid allowing standards-conformant + implementations that each supports a different functional subset in + such a way that they are not capable of establishing LSPs. + +3. Path Computation Techniques + + The discussion of path computation techniques within this document is + limited significantly to the determination of where computation may + take place and what components of the full path may be determined. + + The techniques used are closely tied to the signaling methodologies + described in the previous section in that certain computation + techniques may require the use of particular signaling approaches and + vice versa. + + + + +Farrel, et al. Informational [Page 6] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + Any discussion of the appropriateness of a particular path + computation technique in any given circumstance is beyond the scope + of this document and should be described in a separate applicability + statement. + + Path computation algorithms are firmly out of the scope of this + document. + +3.1. Management Configuration + + Path computation may be performed by offline tools or by a network + planner. The resultant path may be supplied to the ingress LSR as + part of the TE LSP or service request, and encoded by the ingress LSR + as an Explicit Route Object (ERO) on the Path message that is sent + out. + + There is no reason why the path provided by the operator should not + span multiple domains if the relevant information is available to the + planner or the offline tool. The definition of what information is + needed to perform this operation and how that information is + gathered, is outside the scope of this document. + +3.2. Head-End Computation + + The head-end, or ingress, LSR may assume responsibility for path + computation when the operator supplies part or none of the explicit + path. The operator must, in any case, supply at least the + destination address (egress) of the LSP. + +3.2.1. Multi-Domain Visibility Computation + + If the ingress has sufficient visibility of the topology and TE + information for all of the domains across which it will route the LSP + to its destination, then it may compute and provide the entire path. + The quality of this path (that is, its optimality as discussed in + section 3.5) can be better if the ingress has full visibility into + all relevant domains rather than just sufficient visibility to + provide some path to the destination. + + Extreme caution must be exercised in consideration of the + distribution of the requisite TE information. See section 4. + +3.2.2. Partial Visibility Computation + + It may be that the ingress does not have full visibility of the + topology of all domains, but does have information about the + connectedness of the domains and the TE resource availability across + the domains. In this case, the ingress is not able to provide a + + + +Farrel, et al. Informational [Page 7] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + fully specified strict explicit path from ingress to egress. + However, for example, the ingress might supply an explicit path that + comprises: + + - explicit hops from ingress to the local domain boundary + - loose hops representing the domain entry points across the + network + - a loose hop identifying the egress. + + Alternatively, the explicit path might be expressed as: + + - explicit hops from ingress to the local domain boundary + - strict hops giving abstract nodes representing each domain in + turn + - a loose hop identifying the egress. + + These two explicit path formats could be mixed according to the + information available resulting in different combinations of loose + hops and abstract nodes. + + This form of explicit path relies on some further computation + technique being applied at the domain boundaries. See section 3.3. + + As with the multi-domain visibility option, extreme caution must be + exercised in consideration of the distribution of the requisite TE + information. See section 4. + +3.2.3. Local Domain Visibility Computation + + A final possibility for ingress-based computation is that the ingress + LSR has visibility only within its own domain, and connectivity + information only as far as determining one or more domain exit points + that may be suitable for carrying the LSP to its egress. + + In this case, the ingress builds an explicit path that comprises + just: + + - explicit hops from ingress to the local domain boundary + - a loose hop identifying the egress. + +3.3. Domain Boundary Computation + + If the partial explicit path methods described in sections 3.2.2 or + 3.2.3 are applied, then the LSR at each domain boundary is + responsible for ensuring that there is sufficient path information + added to the Path message to carry it at least to the next domain + boundary (that is, out of the new domain). + + + + +Farrel, et al. Informational [Page 8] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + If the LSR at the domain boundary has full visibility to the egress + then it can supply the entire explicit path. Note, however, that the + ERO processing rules of [RFC3209] state that it should only update + the ERO as far as the next specified hop (that is, the next domain + boundary if one was supplied in the original ERO) and, of course, + must not insert ERO subobjects immediately before a strict hop. + + If the LSR at the domain boundary has only partial visibility (using + the definitions of section 3.2.2), it will fill in the path as far as + the next domain boundary, and will supply further domain/domain + boundary information if not already present in the ERO. + + If the LSR at the domain boundary has only local visibility into the + immediate domain, it will simply add information to the ERO to carry + the Path message as far as the next domain boundary. + + Domain boundary path computations are performed independently from + each other. Domain boundary LSRs may have different computation + capabilities, run different path computation algorithms, apply + different sets of constraints and optimization criteria, and so + forth, which might result in path segment quality that is + unpredictable to and out of the control of the ingress LSR. A + solution to this issue lies in enhancing the information signaled + during LSP setup to include a larger set of constraints and to + include the paths of related LSPs (such as diverse protected LSPs) as + described in [GMPLS-E2E]. + + It is also the case that paths generated on domain boundaries may + produce loops. Specifically, the paths computed may loop back into a + domain that has already been crossed by the LSP. This may or may not + be a problem, and might even be desirable, but could also give rise + to real loops. This can be avoided by using the recorded route (RRO) + to provide exclusions within the path computation algorithm, but in + the case of lack of trust between domains it may be necessary for the + RRO to indicate the previously visited domains. Even this solution + is not available where the RRO is not available on a Path message. + Note that when an RRO is used to provide exclusions, and a loop-free + path is found to be not available by the computation at a downstream + border node, crankback [CRANKBACK] may enable an upstream border node + to select an alternate path. + +3.4. Path Computation Element + + The computation techniques in sections 3.2 and 3.3 rely on topology + and TE information being distributed to the ingress LSR and those + LSRs at domain boundaries. These LSRs are responsible for computing + paths. Note that there may be scaling concerns with distributing the + required information; see section 4. + + + +Farrel, et al. Informational [Page 9] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + An alternative technique places the responsibility for path + computation with a Path Computation Element (PCE) [RFC4655]. There + may be either a centralized PCE, or multiple PCEs (each having local + visibility and collaborating in a distributed fashion to compute an + end-to-end path) across the entire network and even within any one + domain. The PCE may collect topology and TE information from the + same sources as would be used by LSRs in the previous paragraph, or + though other means. + + Each LSR called upon to perform path computation (and even the + offline management tools described in section 3.1) may abdicate the + task to a PCE of its choice. The selection of PCE(s) may be driven + by static configuration or the dynamic discovery. + +3.4.1. Multi-Domain Visibility Computation + + A PCE may have full visibility, perhaps through connectivity to + multiple domains. In this case, it is able to supply a full explicit + path as in section 3.2.1. + +3.4.2. Path Computation Use of PCE When Preserving Confidentiality + + Note that although a centralized PCE or multiple collaborative PCEs + may have full visibility into one or more domains, it may be + desirable (e.g., to preserve topology confidentiality) that the full + path not be provided to the ingress LSR. Instead, a partial path is + supplied (as in section 3.2.2 or 3.2.3), and the LSRs at each domain + boundary are required to make further requests for each successive + segment of the path. + + In this way, an end-to-end path may be computed using the full + network capabilities, but confidentiality between domains may be + preserved. Optionally, the PCE(s) may compute the entire path at the + first request and hold it in storage for subsequent requests, or it + may recompute each leg of the path on each request or at regular + intervals until requested by the LSRs establishing the LSP. + + It may be the case that the centralized PCE or the collaboration + between PCEs may define a trust relationship greater than that + normally operational between domains. + +3.4.3. Per-Domain Computation Elements + + A third way that PCEs may be used is simply to have one (or more) per + domain. Each LSR within a domain that wishes to derive a path across + the domain may consult its local PCE. + + + + + +Farrel, et al. Informational [Page 10] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + This mechanism could be used for all path computations within the + domain, or specifically limited to computations for LSPs that will + leave the domain where external connectivity information can then be + restricted to just the PCE. + +3.5. Optimal Path Computation + + There are many definitions of an optimal path depending on the + constraints applied to the path computation. In a multi-domain + environment, the definitions are multiplied so that an optimal route + might be defined as the route that would be computed in the absence + of domain boundaries. Alternatively, another constraint might be + applied to the path computation to reduce or limit the number of + domains crossed by the LSP. + + It is easy to construct examples that show that partitioning a + network into domains, and the resulting loss or aggregation of + routing information may lead to the computation of routes that are + other than optimal. It is impossible to guarantee optimal routing in + the presence of aggregation / abstraction / summarization of routing + information. + + It is beyond the scope of this document to define what is an optimum + path for an inter-domain TE LSP. This debate is abdicated in favor + of requirements documents and applicability statements for specific + deployment scenarios. Note, however, that the meaning of certain + computation metrics may differ between domains (see section 5.6). + +4. Distributing Reachability and TE Information + + Traffic Engineering information is collected into a TE Database (TED) + on which path computation algorithms operate either directly or by + first constructing a network graph. + + The path computation techniques described in the previous section + make certain demands upon the distribution of reachability + information and the TE capabilities of nodes and links within domains + as well as the TE connectivity across domains. + + Currently, TE information is distributed within domains by additions + to IGPs [RFC3630], [RFC3784]. + + In cases where two domains are interconnected by one or more links + (that is, the domain boundary falls on a link rather than on a node), + there should be a mechanism to distribute the TE information + associated with the inter-domain links to the corresponding domains. + This would facilitate better path computation and reduce TE-related + crankbacks on these links. + + + +Farrel, et al. Informational [Page 11] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + Where a domain is a subset of an IGP area, filtering of TE + information may be applied at the domain boundary. This filtering + may be one way or two way. + + Where information needs to reach a PCE that spans multiple domains, + the PCE may snoop on the IGP traffic in each domain, or play an + active part as an IGP-capable node in each domain. The PCE might + also receive TED updates from a proxy within the domain. + + It is possible that an LSR that performs path computation (for + example, an ingress LSR) obtains the topology and TE information of + not just its own domain, but other domains as well. This information + may be subject to filtering applied by the advertising domain (for + example, the information may be limited to Forwarding Adjacencies + (FAs) across other domains, or the information may be aggregated or + abstracted). + + Before starting work on any protocols or protocol extensions to + enable cross-domain reachability and TE advertisement in support of + inter-domain TE, the requirements and benefits must be clearly + established. This has not been done to date. Where any cross-domain + reachability and TE information needs to be advertised, consideration + must be given to TE extensions to existing protocols such as BGP, and + how the information advertised may be fed to the IGPs. It must be + noted that any extensions that cause a significant increase in the + amount of processing (such as aggregation computation) at domain + boundaries, or a significant increase in the amount of information + flooded (such as detailed TE information) need to be treated with + extreme caution and compared carefully with the scaling requirements + expressed in [RFC4105] and [RFC4216]. + +5. Comments on Advanced Functions + + This section provides some non-definitive comments on the constraints + placed on advanced MPLS TE functions by inter-domain MPLS. It does + not attempt to state the implications of using one inter-domain + technique or another. Such material is deferred to appropriate + applicability statements where statements about the capabilities of + existing or future signaling, routing, and computation techniques to + deliver the functions listed should be made. + +5.1. LSP Re-Optimization + + Re-optimization is the process of moving a TE LSP from one path to + another, more preferable path (where no attempt is made in this + document to define "preferable" as no attempt was made to define + "optimal"). Make-before-break techniques are usually applied to + ensure that traffic is disrupted as little as possible. The Shared + + + +Farrel, et al. Informational [Page 12] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + Explicit style is usually used to avoid double booking of network + resources. + + Re-optimization may be available within a single domain. + Alternatively, re-optimization may involve a change in route across + several domains or might involve a choice of different transit + domains. + + Re-optimization requires that all or part of the path of the LSP be + re-computed. The techniques used may be selected as described in + section 3, and this will influence whether the whole or part of the + path is re-optimized. + + The trigger for path computation and re-optimization may be an + operator request, a timer, information about a change in availability + of network resources, or a change in operational parameters (for + example, bandwidth) of an LSP. This trigger must be applied to the + point in the network that requests re-computation and controls re- + optimization and may require additional signaling. + + Note also that where multiple mutually-diverse paths are applied + end-to-end (i.e., not simply within protection domains; see section + 5.5) the point of calculation for re-optimization (whether it is PCE, + ingress, or domain entry point) needs to know all such paths before + attempting re-optimization of any one path. Mutual diversity here + means that a set of computed paths has no commonality. Such + diversity might be link, node, Shared Risk Link Group (SRLG), or even + domain disjointedness according to circumstances and the service + being delivered. + + It may be the case that re-optimization is best achieved by + recomputing the paths of multiple LSPs at once. Indeed, this can be + shown to be most efficient when the paths of all LSPs are known, not + simply those LSPs that originate at a particular ingress. While this + problem is inherited from single domain re-optimization and is out of + scope within this document, it should be noted that the problem grows + in complexity when LSPs wholly within one domain affect the re- + optimization path calculations performed in another domain. + +5.2. LSP Setup Failure + + When an inter-domain LSP setup fails in some domain other than the + first, various options are available for reporting and retrying the + LSP. + + + + + + + +Farrel, et al. Informational [Page 13] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + In the first instance, a retry may be attempted within the domain + that contains the failure. That retry may be attempted by nodes + wholly within the domain, or the failure may be referred back to the + LSR at the domain boundary. + + If the failure cannot be bypassed within the domain where the failure + occurred (perhaps there is no suitable alternate route, perhaps + rerouting is not allowed by domain policy, or perhaps the Path + message specifically bans such action), the error must be reported + back to the previous or head-end domain. + + Subsequent repair attempts may be made by domains further upstream, + but will only be properly effective if sufficient information about + the failure and other failed repair attempts is also passed back + upstream [CRANKBACK]. Note that there is a tension between this + requirement and that of topology confidentiality although crankback + aggregation may be applicable at domain boundaries. + + Further attempts to signal the failed LSP may apply the information + about the failures as constraints to path computation, or may signal + them as specific path exclusions [EXCLUDE]. + + When requested by signaling, the failure may also be systematically + reported to the head-end LSR. + +5.3. LSP Repair + + An LSP that fails after it has been established may be repaired + dynamically by re-routing. The behavior in this case is either like + that for re-optimization, or for handling setup failures (see + previous two sections). Fast Reroute may also be used (see below). + +5.4. Fast Reroute + + MPLS Traffic Engineering Fast Reroute ([RFC4090]) defines local + protection schemes intended to provide fast recovery (in 10s of + msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node + failure. A backup TE LSP is configured and signaled at each hop, and + activated upon detecting or being informed of a network element + failure. The node immediately upstream of the failure (called the + PLR, or Point of Local Repair) reroutes the set of protected TE LSPs + onto the appropriate backup tunnel(s) and around the failed resource. + + In the context of inter-domain TE, there are several different + failure scenarios that must be analyzed. Provision of suitable + solutions may be further complicated by the fact that [RFC4090] + specifies two distinct modes of operation referred to as the "one to + one mode" and the "facility back-up mode". + + + +Farrel, et al. Informational [Page 14] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + The failure scenarios specific to inter-domain TE are as follows: + + - Failure of a domain edge node that is present in both domains. + There are two sub-cases: + + - The Point of Local Repair (PLR) and the Merge Point (MP) are in + the same domain. + + - The PLR and the MP are in different domains. + + - Failure of a domain edge node that is only present in one of the + domains. + + - Failure of an inter-domain link. + + Although it may be possible to apply the same techniques for Fast + Reroute (FRR) to the different methods of signaling inter-domain LSPs + described in section 2, the results of protection may be different + when it is the boundary nodes that need to be protected, and when + they are the ingress and egress of a hierarchical LSP or stitched LSP + segment. In particular, the choice of PLR and MP may be different, + and the length of the protection path may be greater. These uses of + FRR techniques should be explained further in applicability + statements or, in the case of a change in base behavior, in + implementation guidelines specific to the signaling techniques. + + Note that after local repair has been performed, it may be desirable + to re-optimize the LSP (see section 5.1). If the point of re- + optimization (for example, the ingress LSR) lies in a different + domain to the failure, it may rely on the delivery of a PathErr or + Notify message to inform it of the local repair event. + + It is important to note that Fast Reroute techniques are only + applicable to packet switching networks because other network + technologies cannot apply label stacking within the same switching + type. Segment protection [GMPLS-SEG] provides a suitable alternative + that is applicable to packet and non-packet networks. + +5.5. Comments on Path Diversity + + Diverse paths may be required in support of load sharing and/or + protection. Such diverse paths may be required to be node diverse, + link diverse, fully path diverse (that is, link and node diverse), or + SRLG diverse. + + Diverse path computation is a classic problem familiar to all graph + theory majors. The problem is compounded when there are areas of + "private knowledge" such as when domains do not share topology + + + +Farrel, et al. Informational [Page 15] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + information. The problem can be resolved more efficiently (e.g., + avoiding the "trap problem") when mutually resource disjoint paths + can be computed "simultaneously" on the fullest set of information. + + That being said, various techniques (out of the scope of this + document) exist to ensure end-to-end path diversity across multiple + domains. + + Many network technologies utilize "protection domains" because they + fit well with the capabilities of the technology. As a result, many + domains are operated as protection domains. In this model, + protection paths converge at domain boundaries. + + Note that the question of SRLG identification is not yet fully + answered. There are two classes of SRLG: + + - those that indicate resources that are all contained within one + domain + + - those that span domains. + + The former might be identified using a combination of a globally + scoped domain ID, and an SRLG ID that is administered by the domain. + The latter requires a global scope to the SRLG ID. Both schemes, + therefore, require external administration. The former is able to + leverage existing domain ID administration (for example, area and AS + numbers), but the latter would require a new administrative policy. + +5.6. Domain-Specific Constraints + + While the meaning of certain constraints, like bandwidth, can be + assumed to be constant across different domains, other TE constraints + (such as resource affinity, color, metric, priority, etc.) may have + different meanings in different domains and this may impact the + ability to support Diffserv-aware MPLS, or to manage preemption. + + In order to achieve consistent meaning and LSP establishment, this + fact must be considered when performing constraint-based path + computation or when signaling across domain boundaries. + + A mapping function can be derived for most constraints based on + policy agreements between the domain administrators. The details of + such a mapping function are outside the scope of this document, but + it is important to note that the default behavior must either be that + a constant mapping is applied or that any requirement to apply these + constraints across a domain boundary must fail in the absence of + explicit mapping rules. + + + + +Farrel, et al. Informational [Page 16] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + +5.7. Policy Control + + Domain boundaries are natural points for policy control. There is + little to add on this subject except to note that a TE LSP that + cannot be established on a path through one domain because of a + policy applied at the domain boundary may be satisfactorily + established using a path that avoids the demurring domain. In any + case, when a TE LSP signaling attempt is rejected due to non- + compliance with some policy constraint, this should be reflected to + the ingress LSR. + +5.8. Inter-Domain Operations and Management (OAM) + + Some elements of OAM may be intentionally confined within a domain. + Others (such as end-to-end liveness and connectivity testing) clearly + need to span the entire multi-domain TE LSP. Where issues of + topology confidentiality are strong, collaboration between PCEs or + domain boundary nodes might be required in order to provide end-to- + end OAM, and a significant issue to be resolved is to ensure that the + end-points support the various OAM capabilities. + + The different signaling mechanisms described above may need + refinements to [RFC4379], [BFD-MPLS], etc., to gain full end-to-end + visibility. These protocols should, however, be considered in the + light of topology confidentiality requirements. + + Route recording is a commonly used feature of signaling that provides + OAM information about the path of an established LSP. When an LSP + traverses a domain boundary, the border node may remove or aggregate + some of the recorded information for topology confidentiality or + other policy reasons. + +5.9. Point-to-Multipoint + + Inter-domain point-to-multipoint (P2MP) requirements are explicitly + out of the scope of this document. They may be covered by other + documents dependent on the details of MPLS TE P2MP solutions. + +5.10. Applicability to Non-Packet Technologies + + Non-packet switching technologies may present particular issues for + inter-domain LSPs. While packet switching networks may utilize + control planes built on MPLS or GMPLS technology, non-packet networks + are limited to GMPLS. + + + + + + + +Farrel, et al. Informational [Page 17] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + On the other hand, some problems such as Fast Reroute on domain + boundaries (see section 5.4) may be handled by the GMPLS technique of + segment protection [GMPLS-SEG] that is applicable to both packet and + non-packet switching technologies. + + The specific architectural considerations and requirements for + inter-domain LSP setup in non-packet networks are covered in a + separate document [GMPLS-AS]. + +6. Security Considerations + + Requirements for security within domains are unchanged from [RFC3209] + and [RFC3473], and from [RFC3630] and [RFC3784]. That is, all + security procedures for existing protocols in the MPLS context + continue to apply for the intra-domain cases. + + Inter-domain security may be considered as a more important and more + sensitive issue than intra-domain security since in inter-domain + traffic engineering control and information may be passed across + administrative boundaries. The most obvious and most sensitive case + is inter-AS TE. + + All of the intra-domain security measures for the signaling and + routing protocols are equally applicable in the inter-domain case. + There is, however, a greater likelihood of them being applied in the + inter-domain case. + + Security for inter-domain MPLS TE is the subject of a separate + document that analyzes the security deployment models and risks. + This separate document must be completed before inter-domain MPLS TE + solution documents can be advanced. + + Similarly, the PCE procedures [RFC4655] are subject to security + measures for the exchange computation information between PCEs and + for LSRs that request path computations from a PCE. The requirements + for this security (set out in [RFC4657]) apply whether the LSR and + PCE (or the cooperating PCEs) are in the same domain or lie across + domain boundaries. + + It should be noted, however, that techniques used for (for example) + authentication require coordination of secrets, keys, or passwords + between sender and receiver. Where sender and receiver lie within a + single administrative domain, this process may be simple. But where + sender and receiver lie in different administrative domains, cross- + domain coordination between network administrators will be required + in order to provide adequate security. At this stage, it is not + proposed that this coordination be provided through an automatic + process or through the use of a protocol. Human-to-human + + + +Farrel, et al. Informational [Page 18] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + coordination is more likely to provide the required level of + confidence in the inter-domain security. + + One new security concept is introduced by inter-domain MPLS TE. This + is the preservation of confidentiality of topology information. That + is, one domain may wish to keep secret the way that its network is + constructed and the availability (or otherwise) of end-to-end network + resources. This issue is discussed in sections 3.4.2, 5.2, and 5.8 + of this document. When there is a requirement to preserve inter- + domain topology confidentiality, policy filters must be applied at + the domain boundaries to avoid distributing such information. This + is the responsibility of the domain that distributes information, and + it may be adequately addressed by aggregation of information as + described in the referenced sections. + + Applicability statements for particular combinations of signaling, + routing, and path computation techniques to provide inter-domain MPLS + TE solutions are expected to contain detailed security sections. + +7. Acknowledgements + + The authors would like to extend their warmest thanks to Kireeti + Kompella for convincing them to expend effort on this document. + + Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani, and Igor + Bryskin for their review and suggestions on the text. + + Thanks to Jari Arkko, Gonzalo Camarillo, Brian Carpenter, Lisa + Dusseault, Sam Hartman, Russ Housley, and Dan Romascanu for final + review of the text. + +8. Normative References + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", RFC 3031, + January 2001. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, + V., and G. Swallow, "RSVP-TE: Extensions to RSVP for + LSP Tunnels", RFC 3209, December 2001. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC + 3473, January 2003. + + + + + + +Farrel, et al. Informational [Page 19] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic + Engineering (TE) Extensions to OSPF Version 2", RFC + 3630, September 2003. + + [RFC3784] Smit, H. and T. Li, "Intermediate System to + Intermediate System (IS-IS) Extensions for Traffic + Engineering (TE)", RFC 3784, June 2004. + +9. Informative References + + [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, + "BFD For MPLS LSPs", Work in Progress, June 2006. + + [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for + MPLS Signaling", Work in Progress, May 2005. + + [EXCLUDE] Lee, CY., Farrel, A., and DeCnodder, "Exclude Routes - + Extension to RSVP-TE", Work in Progress, August 2005. + + [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute + Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May + 2005. + + [GMPLS-AS] Otani, T., Kumaki, K., Okamoto, S., and W. Imajuku, + "GMPLS Inter-domain Traffic Engineering Requirements", + Work in Progress, August 2006. + + [GMPLS-E2E] Lang, J.P., Rekhter, Y., and D. Papadimitriou, Editors, + "RSVP-TE Extensions in support of End-to-End + Generalized Multi-Protocol Label Switching (GMPLS)- + based Recovery", Work in Progress, April 2005. + + [GMPLS-SEG] Berger, L., Bryskin, I., Papadimitriou, D., and A. + Farrel, "GMPLS Based Segment Recovery", Work in + Progress, May 2005. + + [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths + (LSP) Hierarchy with Generalized Multi-Protocol Label + Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, + October 2005. + + [RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, + "Requirements for Inter-Area MPLS Traffic Engineering", + RFC 4105, June 2005. + + [RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, + October 2005. + + + + +Farrel, et al. Informational [Page 20] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + + [RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous + System (AS) Traffic Engineering (TE) Requirements", RFC + 4216, November 2005. + + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + + [RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J.-P., and A. + Ayyangar, "Encoding of Attributes for Multiprotocol + Label Switching (MPLS) Label Switched Path (LSP) + Establishment Using Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE)", RFC 4420, February + 2006. + + [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path + Computation Element (PCE)-Based Architecture", RFC + 4655, August 2006. + + [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) + Communication Protocol Generic Requirements", RFC 4657, + September 2006. + + [STITCH] Ayyangar, A. and J.-P. Vasseur, "LSP Stitching with + Generalized MPLS TE", Work in Progress, September 2005. + +Authors' Addresses + + Adrian Farrel + Old Dog Consulting + EMail: adrian@olddog.co.uk + + Jean-Philippe Vasseur + Cisco Systems, Inc + 1414 Massachusetts Avenue + Boxborough, MA 01719 + USA + EMail: jpv@cisco.com + + Arthi Ayyangar + Nuova Systems + EMail: arthi@nuovasystems.com + + + + + + + + + +Farrel, et al. Informational [Page 21] + +RFC 4726 Framework for Inter-Domain TE November 2006 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, + AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY + IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR + PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Farrel, et al. Informational [Page 22] + |