GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4726

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:
  1. explicit hops from ingress to the local domain boundary
  2. loose hops representing the domain entry points across the

network

  1. a loose hop identifying the egress.
 Alternatively, the explicit path might be expressed as:
  1. explicit hops from ingress to the local domain boundary
  2. strict hops giving abstract nodes representing each domain in

turn

  1. 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:
  1. explicit hops from ingress to the local domain boundary
  2. 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:
  1. Failure of a domain edge node that is present in both domains.

There are two sub-cases:

  1. The Point of Local Repair (PLR) and the Merge Point (MP) are in

the same domain.

  1. The PLR and the MP are in different domains.
  1. Failure of a domain edge node that is only present in one of the

domains.

  1. 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:
  1. those that indicate resources that are all contained within one

domain

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4726.txt · Last modified: 2006/11/18 01:53 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki