GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5441

Network Working Group JP. Vasseur, Ed. Request for Comments: 5441 Cisco Systems, Inc Category: Standards Track R. Zhang

                                                            BT Infonet
                                                              N. Bitar
                                                               Verizon
                                                           JL. Le Roux
                                                        France Telecom
                                                            April 2009

A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute

       Shortest Constrained Inter-Domain Traffic Engineering
                        Label Switched Paths

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents in effect on the date of
 publication of this document (http://trustee.ietf.org/license-info).
 Please review these documents carefully, as they describe your rights
 and restrictions with respect to this document.
 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Vasseur, et al. Standards Track [Page 1] RFC 5441 BRPC April 2009

Abstract

 The ability to compute shortest constrained Traffic Engineering Label
 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
 Generalized MPLS (GMPLS) networks across multiple domains has been
 identified as a key requirement.  In this context, a domain is a
 collection of network elements within a common sphere of address
 management or path computational responsibility such as an IGP area
 or an Autonomous Systems.  This document specifies a procedure
 relying on the use of multiple Path Computation Elements (PCEs) to
 compute such inter-domain shortest constrained paths across a
 predetermined sequence of domains, using a backward-recursive path
 computation technique.  This technique preserves confidentiality
 across domains, which is sometimes required when domains are managed
 by different service providers.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
 3.  General Assumptions  . . . . . . . . . . . . . . . . . . . . .  5
 4.  BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.1.  Domain Path Selection  . . . . . . . . . . . . . . . . . .  6
   4.2.  Mode of Operation  . . . . . . . . . . . . . . . . . . . .  6
 5.  PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . .  8
 6.  VSPT Encoding  . . . . . . . . . . . . . . . . . . . . . . . .  9
 7.  Inter-AS TE Links  . . . . . . . . . . . . . . . . . . . . . . 10
 8.  Usage in Conjunction with Per-Domain Path Computation  . . . . 10
 9.  BRPC Procedure Completion Failure  . . . . . . . . . . . . . . 10
 10. Applicability  . . . . . . . . . . . . . . . . . . . . . . . . 11
   10.1. Diverse End-to-End Path Computation  . . . . . . . . . . . 11
   10.2. Path Optimality  . . . . . . . . . . . . . . . . . . . . . 12
 11. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . 12
 12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 12
 13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 12
 14. Manageability Considerations . . . . . . . . . . . . . . . . . 13
   14.1. Control of Function and Policy . . . . . . . . . . . . . . 13
   14.2. Information and Data Models  . . . . . . . . . . . . . . . 13
   14.3. Liveness Detection and Monitoring  . . . . . . . . . . . . 13
   14.4. Verifying Correct Operation  . . . . . . . . . . . . . . . 13
   14.5. Requirements on Other Protocols and Functional
         Components . . . . . . . . . . . . . . . . . . . . . . . . 14
   14.6. Impact on Network Operation  . . . . . . . . . . . . . . . 14
   14.7. Path Computation Chain Monitoring  . . . . . . . . . . . . 14
 15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   15.1. New Flag of the RP Object  . . . . . . . . . . . . . . . . 14
   15.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 14

Vasseur, et al. Standards Track [Page 2] RFC 5441 BRPC April 2009

   15.3. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15
 16. Security Considerations  . . . . . . . . . . . . . . . . . . . 15
 17. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   18.1. Normative References . . . . . . . . . . . . . . . . . . . 16
   18.2. Informative References . . . . . . . . . . . . . . . . . . 16

1. Introduction

 The requirements for inter-area and inter-AS MPLS Traffic Engineering
 (TE) have been developed by the Traffic Engineering Working Group (TE
 WG) and have been stated in [RFC4105] and [RFC4216], respectively.
 The framework for inter-domain Multiprotocol Label Switching (MPLS)
 Traffic Engineering (TE) has been provided in [RFC4726].
 [RFC5152] defines a technique for establishing an inter-domain
 Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the
 path is computed during the signaling process on a per-domain basis
 by the entry boundary node of each domain (each node responsible for
 triggering the computation of a section of an inter-domain TE LSP
 path is always along the path of such TE LSP).  This path computation
 technique fulfills some of the requirements stated in [RFC4105] and
 [RFC4216] but not all of them.  In particular, it cannot guarantee to
 find an optimal (shortest) inter-domain constrained path.
 Furthermore, it cannot be efficiently used to compute a set of inter-
 domain diversely routed TE LSPs.
 The Path Computation Element (PCE) architecture is defined in
 [RFC4655].  The aim of this document is to describe a PCE-based path
 computation procedure to compute optimal inter-domain constrained
 (G)MPLS TE LSPs.
 Qualifying a path as optimal requires some clarification.  Indeed, a
 globally optimal TE LSP placement usually refers to a set of TE LSPs
 whose placements optimize the network resources with regards to a
 specified objective function (e.g., a placement that reduces the
 maximum or average network load while satisfying the TE LSP
 constraints).  In this document, an optimal inter-domain constrained
 TE LSP is defined as the shortest path satisfying the set of required
 constraints that would be obtained in the absence of multiple domains
 (in other words, in a totally flat IGP network between the source and
 destination of the TE LSP).  Note that this requires the use of
 consistent metric schemes in each domain (see Section 13).

Vasseur, et al. Standards Track [Page 3] RFC 5441 BRPC April 2009

1.1. Requirements Language

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

2. Terminology

 ABR: Area Border Routers.  Routers used to connect two IGP areas
 (areas in OSPF or levels in IS-IS).
 ASBR: Autonomous System Border Router.  Router used to connect
 together ASes of the same or different service providers via one or
 more inter-AS links.
 Boundary Node (BN): a boundary node is either an ABR in the context
 of inter-area Traffic Engineering or an ASBR in the context of
 inter-AS Traffic Engineering.
 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along
 a determined sequence of domains.
 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
 a determined sequence of domains.
 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.
 Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
 LSP: Label Switched Path.
 LSR: Label Switching Router.
 PCC: Path Computation Client.  Any client application requesting a
 path computation to be performed by a Path Computation Element.
 PCE: Path Computation Element.  An entity (component, application, or
 network node) that is capable of computing a network path or route
 based on a network graph and applying computational constraints.
 PCE(i) is a PCE with the scope of domain(i).
 TED: Traffic Engineering Database.
 VSPT: Virtual Shortest Path Tree.
 The notion of contiguous, stitched, and nested TE LSPs is defined in
 [RFC4726] and will not be repeated here.

Vasseur, et al. Standards Track [Page 4] RFC 5441 BRPC April 2009

3. General Assumptions

 In the rest of this document, we make the following set of
 assumptions common to inter-area and inter-AS MPLS TE:
 o  Each IGP area or Autonomous System (AS) is assumed to be Traffic
    Engineering enabled.
 o  No topology or resource information is distributed between domains
    (as mandated per [RFC4105] and [RFC4216]), which is critical to
    preserve IGP/BGP scalability and confidentiality.
 o  While certain constraints like bandwidth can be used across
    different domains, other TE constraints (such as resource
    affinity, color, metric, etc. [RFC2702]) could be translated at
    domain boundaries.  If required, it is assumed that, at the domain
    boundary nodes, there will exist some sort of local mapping based
    on policy agreement, in order to translate such constraints across
    domain boundaries during the inter-PCE communication process.
 o  Each AS can be made of several IGP areas.  The path computation
    procedure described in this document applies to the case of a
    single AS made of multiple IGP areas, multiple ASes made of a
    single IGP area, or any combination of the above.  For the sake of
    simplicity, each AS will be considered to be made of a single area
    in this document.  The case of an inter-AS TE LSP spanning
    multiple ASes, where some of those ASes are themselves made of
    multiple IGP areas, can be easily derived from this case by
    applying the BRPC procedure described in this document,
    recursively.
 o  The domain path (the set of domains traversed to reach the
    destination domain) is either administratively predetermined or
    discovered by some means that is outside of the scope of this
    document.

4. BRPC Procedure

 The BRPC procedure is a multiple-PCE path computation technique as
 described in [RFC4655].  A possible model consists of hosting the PCE
 function on boundary nodes (e.g., ABR or ASBR), but this is not
 mandated by the BRPC procedure.
 The BRPC procedure relies on communication between cooperating PCEs.
 In particular, the PCC sends a PCReq to a PCE in its domain.  The
 request is forwarded between PCEs, domain-by-domain, until the PCE
 responsible for the domain containing the LSP destination is reached.
 The PCE in the destination domain creates a tree of potential paths

Vasseur, et al. Standards Track [Page 5] RFC 5441 BRPC April 2009

 to the destination (the Virtual Shortest Path Tree - VSPT) and passes
 this back to the previous PCE in a PCRep.  Each PCE in turn adds to
 the VSPT and passes it back until the PCE in the source domain uses
 the VSPT to select an end-to-end path that the PCE sends to the PCC.
 The BRPC procedure does not make any assumption with regards to the
 nature of the inter-domain TE LSP that could be contiguous, nested,
 or stitched.
 Furthermore, no assumption is made on the actual path computation
 algorithm in use by a PCE (e.g., it can be any variant of Constrained
 Shortest Path First (CSPF) or an algorithm based on linear
 programming to solve multi-constraint optimization problems).

4.1. Domain Path Selection

 The PCE-based BRPC procedure applies to the computation of an optimal
 constrained inter-domain TE LSP.  The sequence of domains to be
 traversed is either administratively predetermined or discovered by
 some means that is outside of the scope of this document.  The PCC
 MAY indicate the sequence of domains to be traversed using the
 Include Route Object (IRO) defined in [RFC5440] so that it is
 available to all PCEs.  Note also that a sequence of PCEs MAY be
 enforced by policy on the PCC, and this constraint can be carried in
 the PCEP path computation request (as defined in [PCE-MONITOR]).
 The BRPC procedure guarantees to compute the optimal path across a
 specific sequence of traversed domains (which constitutes an
 additional constraint).  In the case of an arbitrary set of meshed
 domains, the BRPC procedure can be used to compute the optimal path
 across each domain set in order to get the optimal constrained path
 between the source and the destination of the TE LSP.  The BRPC
 procedure can also be used across a subset of all domain sequences,
 and the best path among these sequences can then be selected.

4.2. Mode of Operation

 Definition of VSPT(i)
 In each domain i:
 o  There is a set of X-en(i) entry BNs noted BN-en(k,i) where
    BN-en(k,i) is the kth entry BN of domain(i).
 o  There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where
    BN-ex(k,i) is the kth exit BN of domain(i).

Vasseur, et al. Standards Track [Page 6] RFC 5441 BRPC April 2009

 VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to
 PCE(i-1):
                      Root (TE LSP destination)
                      /         |            \
                BN-en(1,i)   BN-en(2,i) ... BN-en(j,i).
                 where [X-en(i)] is the number of
              entry BNs in domain i and j<= [X-en(i)]
                       Figure 1: MP2P Tree
 Each link of tree VSPT(i) represents the shortest constrained path
 between BN-en(j,i) and the TE LSP destination that satisfies the set
 of required constraints for the TE LSP (bandwidth, affinities, etc.).
 These are path segments to reach the TE LSP destination from
 BN-en(j,i).
 Note that PCE(i) only considers the entry BNs of domain(i), i.e.,
 only the BNs that provide connectivity from domain(i-1).  In other
 words, the set BN-en(k,i) is only made of those BNs that provide
 connectivity from domain (i-1) to domain(i).  Furthermore, some BNs
 may be excluded according to policy constraints (either due to local
 policy or policies signaled in the path computation request).
 Step 1:
 First, the PCC needs to determine the PCE capable of serving its path
 computation request (this can be done with local configuration or via
 IGP discovery (see [RFC5088] and [RFC5089])).  The path computation
 request is then relayed until reaching a PCE(n) such that the TE LSP
 destination resides in the domain(n).  At each step of the process,
 the next PCE can either be statically configured or dynamically
 discovered via IGP/BGP extensions.  If no next PCE can be found or
 the next-hop PCE of choice is unavailable, the procedure stops and a
 path computation error is returned (see Section 9).  If PCE(i-1)
 discovers multiple PCEs for the adjacent domain(i), PCE(i) may select
 a subset of these PCEs based on some local policies or heuristics.
 The PCE selection process is outside of the scope of this document.
 Step 2:
 PCE(n) computes VSPT(n), the tree made of the list of shortest
 constrained paths between every BN-en(j,n) and the TE LSP destination
 using a suitable path computation algorithm (e.g., CSPF) and returns
 the computed VSPT(n) to PCE(n-1).

Vasseur, et al. Standards Track [Page 7] RFC 5441 BRPC April 2009

 Step i:
 For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the
 shortest constrained paths between each BN-en(j,i) and the TE LSP
 destination.  It does this by considering its own TED and the
 information in VSPT(i+1).
 In the case of inter-AS TE LSP computation, this also requires adding
 the inter-AS TE links that connect the domain(i) to the domain(i+1).
 Step n:
 Finally, PCE(1) computes the end-to-end shortest constrained path
 from the source to the destination and returns the corresponding path
 to the requesting PCC in the form of a PCRep message as defined in
 [RFC5440].
 Each branch of the VSPT tree (path) may be returned in the form of an
 explicit path (in which case, all the hops along the path segment are
 listed) or a loose path (in which case, only the BN is specified) so
 as to preserve confidentiality along with the respective cost.  In
 the latter case, various techniques can be used in order to retrieve
 the computed explicit paths on a per-domain basis during the
 signaling process, thanks to the use of path keys as described in
 [PATH-KEY].
 A PCE that can compute the requested path for more than one
 consecutive domain on the path SHOULD perform this computation for
 all such domains before passing the PCRep to the previous PCE in the
 sequence.
 BRPC guarantees to find the optimal (shortest) constrained inter-
 domain TE LSP according to a set of defined domains to be traversed.
 Note that other variants of the BRPC procedure relying on the same
 principles are also possible.
 Note also that in case of Equal Cost Multi-Path (ECMP) paths, more
 than one path could be returned to the requesting PCC.

5. PCEP Protocol Extensions

 The BRPC procedure requires the specification of a new flag of the RP
 object carried within the PCReq message (defined in [RFC5440]) to
 specify that the shortest paths satisfying the constraints from the
 destination to the set of entry boundary nodes are requested (such a
 set of paths forms the downstream VSPT as specified in Section 4.2).

Vasseur, et al. Standards Track [Page 8] RFC 5441 BRPC April 2009

 The following new flag of the RP object is defined:
 VSPT Flag
 Bit Number      Name Flag
    25           VSPT
 When set, the VSPT Flag indicates that the PCC requests the
 computation of an inter-domain TE LSP using the BRPC procedure
 defined in this document.
 Because path segments computed by a downstream PCE in the context of
 the BRPC procedure MUST be provided along with their respective path
 costs, the C flag of the METRIC object carried within the PCReq
 message MUST be set.  It is the choice of the requester to
 appropriately set the O bit of the RP object.

6. VSPT Encoding

 The VSPT is returned within a PCRep message.  The encoding consists
 of a non-ordered list of Explicit Route Objects (EROs) where each ERO
 represents a path segment from a BN to the destination specified in
 the END-POINT object of the corresponding PCReq message.
 Example:
 <---- area 1 ----><---- area 0 -----><------ area 2 ------>
                                     ABR1-A-B-+
                                      |       |
                                     ABR2-----D
                                      |       |
                                     ABR3--C--+
  Figure 2: An Example of VSPT Encoding Using a Set of EROs
 In the simple example shown in Figure 2, if we make the assumption
 that a constrained path exists between each ABR and the destination
 D, the VSPT computed by a PCE serving area 2 consists of the
 following non-ordered set of EROs:
 o  ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP
    address)-D(TE Router ID)
 o  ERO2: ABR2(TE Router ID)-D(TE Router ID)
 o  ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID)
 The PCReq message, PCRep message, PCEP END-POINT object, and ERO
 object are defined in [RFC5440].

Vasseur, et al. Standards Track [Page 9] RFC 5441 BRPC April 2009

7. Inter-AS TE Links

 In the case of inter-AS TE LSP path computation, the BRPC procedure
 requires the knowledge of the traffic engineering attributes of the
 inter-AS TE links.  The process by which the PCE acquires this
 information is out of the scope of the BRPC procedure, which is
 compliant with the PCE architecture defined in [RFC4655].
 That said, a straightforward solution consists of allowing the ASBRs
 to flood the TE information related to the inter-ASBR links although
 no IGP TE is enabled over those links (there is no IGP adjacency over
 the inter-ASBR links).  This allows the PCE of a domain to get entire
 TE visibility up to the set of entry ASBRs in the downstream domain
 (see the IGP extensions defined in [RFC5316] and [RFC5392]).

8. Usage in Conjunction with Per-Domain Path Computation

 The BRPC procedure may be used to compute path segments in
 conjunction with other path computation techniques (such as the per-
 domain path computation technique defined in [RFC5152]) to compute
 the end-to-end path.  In this case, end-to-end path optimality can no
 longer be guaranteed.

9. BRPC Procedure Completion Failure

 If the BRPC procedure cannot be completed because a PCE along the
 domain does not recognize the procedure (VSPT flag of the RP object),
 as stated in [RFC5440], the PCE sends a PCErr message to the upstream
 PCE with an Error-Type=4 (Not supported object), Error-value=4
 (Unsupported parameter).  The PCE may include the parent object (RP
 object) up to and including (but no further than) the unknown or
 unsupported parameter.  In this case where the unknown or unsupported
 parameter is a bit flag (VSPT flag), the included RP object should
 contain the whole bit flag field with all bits after the parameter at
 issue set to zero.  The corresponding path computation request is
 then cancelled by the PCE without further notification.
 If the BRPC procedure cannot be completed because a PCE along the
 domain path recognizes but does not support the procedure, it MUST
 return a PCErr message to the upstream PCE with an Error-Type "BRPC
 procedure completion failure".
 The PCErr message MUST be relayed to the requesting PCC.
 PCEP-ERROR objects are used to report a PCEP protocol error and are
 characterized by an Error-Type that specifies the type of error and
 an Error-value that provides additional information about the error
 type.  Both the Error-Type and the Error-value are managed by IANA.

Vasseur, et al. Standards Track [Page 10] RFC 5441 BRPC April 2009

 A new Error-Type is defined that relates to the BRPC procedure.
Error-Type       Meaning
    13           BRPC procedure completion failure
                 Error-value
                   1: BRPC procedure not supported by one or more PCEs
                      along the domain path

10. Applicability

 As discussed in Section 3, the requirements for inter-area and
 inter-AS MPLS Traffic Engineering have been developed by the Traffic
 Engineering Working Group (TE WG) and have been stated in [RFC4105]
 and [RFC4216], respectively.  Among the set of requirements, both
 documents indicate the need for some solution that provides the
 ability to compute an optimal (shortest) constrained inter-domain TE
 LSP and to compute a set of diverse inter-domain TE LSPs.

10.1. Diverse End-to-End Path Computation

 PCEP (see [RFC5440]) allows a PCC to request the computation of a set
 of diverse TE LSPs by setting the SVEC object's flags L, N, or S to
 request link, node, or SRLG (Shared Risk Link Group) diversity,
 respectively.  Such requests MUST be taken into account by each PCE
 along the path computation chain during the VSPT computation.  In the
 context of the BRPC procedure, a set of diversely routed TE LSPs
 between two LSRs can be computed since the path segments of the VSPT
 are simultaneously computed by a given PCE.  The BRPC procedure
 allows for the computation of diverse paths under various objective
 functions (such as minimizing the sum of the costs of the N diverse
 paths, etc.).
 By contrast, with a 2-step approach consisting of computing the first
 path followed by computing the second path after having removed the
 set of network elements traversed by the first path (if that does not
 violate confidentiality preservation), one cannot guarantee that a
 solution will be found even if such solution exists.  Furthermore,
 even if a solution is found, it may not be the most optimal one with
 respect to an objective function such as minimizing the sum of the
 paths' costs, bounding the path delays of both paths, and so on.
 Finally, it must be noted that such a 2-step path computation
 approach is usually less efficient in terms of signaling delays since
 it requires that two serialized TE LSPs be set up.

Vasseur, et al. Standards Track [Page 11] RFC 5441 BRPC April 2009

10.2. Path Optimality

 BRPC guarantees that the optimal (shortest) constrained inter-domain
 path will always be found, subject to policy constraints.  Both in
 the case where local path computation techniques are used (such as to
 build stitched or nested TE LSPs), and in the case where a domain has
 more than one BN-en or more than one BN-ex, it is only possible to
 guarantee optimality after some network change within the domain by
 completely re-executing the BRPC procedure.

11. Reoptimization of an Inter-Domain TE LSP

 The ability to reoptimize an existing inter-domain TE LSP path has
 been explicitly listed as a requirement in [RFC4105] and [RFC4216].
 In the case of a TE LSP reoptimization request, the reoptimization
 procedure defined in [RFC5440] applies when the path in use (if
 available on the head-end) is provided as part of the path
 computation request so that the PCEs involved in the reoptimization
 request can avoid double bandwidth accounting.

12. Path Computation Failure

 If a PCE requires to relay a path computation request according to
 the BRPC procedure defined in this document to a downstream PCE and
 no such PCE is available, the PCE MUST send a negative path
 computation reply to the requester using a PCReq message as specified
 in [RFC5440] that contains a NO-PATH object.  In such case, the
 NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [RFC5440])
 with the newly defined bit named "BRPC path computation chain
 unavailable" set.
 Bit number     Name Flag
    28           BRPC path computation chain unavailable

13. Metric Normalization

 In the case of inter-area TE, the same IGP/TE metric scheme is
 usually adopted for all the IGP areas (e.g., based on the link-speed,
 propagation delay, or some other combination of link attributes).
 Hence, the proposed set of mechanisms always computes the shortest
 path across multiple areas that obey the required set of constraints
 with respect to a specified objective function.  Conversely, in the
 case of inter-AS TE, in order for this path computation to be
 meaningful, metric normalization between ASes may be required.  One
 solution to avoid IGP metric modification would be for the service
 providers to agree on a TE metric normalization scheme and use the TE

Vasseur, et al. Standards Track [Page 12] RFC 5441 BRPC April 2009

 metric for TE LSP path computation (in that case, the use of the TE
 metric must be requested in the PCEP path computation request) using
 the METRIC object (defined in [RFC5440]).

14. Manageability Considerations

 This section follows the guidance of [PCE-MANAGE].

14.1. Control of Function and Policy

 The only configurable item is the support of the BRPC procedure on a
 PCE.  The support of the BRPC procedure by the PCE MAY be controlled
 by a policy module governing the conditions under which a PCE should
 participate in the BRPC procedure (origin of the requests, number of
 requests per second, etc.).  If the BRPC is not supported/allowed on
 a PCE, it MUST send a PCErr message as specified in Section 9.

14.2. Information and Data Models

 A BRPC MIB module will be specified in a separate document.

14.3. Liveness Detection and Monitoring

 The BRPC procedure is a multiple-PCE path computation technique and,
 as such, a set of PCEs are involved in the path computation chain.
 If the path computation chain is not operational either because at
 least one PCE does not support the BRPC procedure or because one of
 the PCEs that must be involved in the path computation chain is not
 available, procedures are defined to report such failures in Sections
 9 and 12, respectively.  Furthermore, a built-in diagnostic tool to
 check the availability and performances of a PCE chain is defined in
 [PCE-MONITOR].

14.4. Verifying Correct Operation

 Verifying the correct operation of BRPC can be performed by
 monitoring a set of parameters.  A BRPC implementation SHOULD provide
 the following parameters:
 o  Number of successful BRPC procedure completions on a per-PCE-peer
    basis
 o  Number of BRPC procedure completion failures because the VSPT flag
    was not recognized (on a per-PCE-peer basis)
 o  Number of BRPC procedure completion failures because the BRPC
    procedure was not supported (on a per-PCE-peer basis)

Vasseur, et al. Standards Track [Page 13] RFC 5441 BRPC April 2009

14.5. Requirements on Other Protocols and Functional Components

 The BRPC procedure does not put any new requirements on other
 protocols.  That said, since the BRPC procedure relies on the PCEP
 protocol, there is a dependency between BRPC and PCEP; consequently,
 the BRPC procedure inherently makes use of the management functions
 developed for PCEP.

14.6. Impact on Network Operation

 The BRPC procedure does not have any significant impact on network
 operation: indeed, BRPC is a multiple-PCE path computation scheme as
 defined in [RFC4655] and does not differ from any other path
 computation request.

14.7. Path Computation Chain Monitoring

 [PCE-MONITOR] specifies a set of mechanisms that can be used to
 gather PCE state metrics.  Because BRPC is a multiple-PCE path
 computation technique, such mechanisms could be advantageously used
 in the context of the BRPC procedure to check the liveness of the
 path computation chain, locate a faulty component, monitor the
 overall performance, and so on.

15. IANA Considerations

15.1. New Flag of the RP Object

 A new flag of the RP object (specified in [RFC5440]) is defined in
 this document.  IANA maintains a registry of RP object flags in the
 "RP Object Flag Field" sub-registry of the "Path Computation Element
 Protocol (PCEP) Numbers" registry.
 IANA has allocated the following value:
     Bit      Description              Reference
     25       VSPT                     This document

15.2. New Error-Type and Error-Value

 IANA maintains a registry of Error-Types and Error-values for use in
 PCEP messages.  This is maintained as the "PCEP-ERROR Object Error
 Types and Values" sub-registry of the "Path Computation Element
 Protocol (PCEP) Numbers" registry.

Vasseur, et al. Standards Track [Page 14] RFC 5441 BRPC April 2009

 A new Error-value is defined for the Error-Type "Not supported
 object" (type 4).
 Error-Type     Meaning and error values                 Reference
    4           Not supported object
                Error-value=4: Unsupported parameter     This document
 A new Error-Type is defined in this document as follows:
 Error-Type     Meaning                                  Reference
   13           BRPC procedure completion failure        This document
                Error-value=1: BRPC procedure not        This document
                supported by one or more PCEs along
                the domain path

15.3. New Flag of the NO-PATH-VECTOR TLV

 A new flag of the NO-PATH-VECTOR TLV defined in [RFC5440]) is
 specified in this document.
 IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the
 "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation
 Element Protocol (PCEP) Numbers" registry.
 IANA has allocated the following allocation value:
    Bit number  Meaning                  Reference
       4        BRPC path computation    This document
                chain unavailable

16. Security Considerations

 The BRPC procedure relies on the use of the PCEP protocol and as such
 is subjected to the potential attacks listed in Section 10 of
 [RFC5440].  In addition to the security mechanisms described in
 [RFC5440] with regards to spoofing, snooping, falsification, and
 denial of service, an implementation MAY support a policy module
 governing the conditions under which a PCE should participate in the
 BRPC procedure.
 The BRPC procedure does not increase the information exchanged
 between ASes and preserves topology confidentiality, in compliance
 with [RFC4105] and [RFC4216].

Vasseur, et al. Standards Track [Page 15] RFC 5441 BRPC April 2009

17. Acknowledgments

 The authors would like to thank Arthi Ayyangar, Dimitri
 Papadimitriou, Siva Sivabalan, Meral Shirazipour, and Mach Chen for
 their useful comments.  A special thanks to Adrian Farrel for his
 useful comments and suggestions.

18. References

18.1. Normative References

 [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC5440]      Vasseur, J., Ed. and J. Roux, Ed., "Path Computation
                Element (PCE) Communication Protocol (PCEP)",
                RFC 5440, April 2009.

18.2. Informative References

 [PATH-KEY]     Bradford, R., Vasseur, J., and A. Farrel, "Preserving
                Topology Confidentiality in Inter-Domain Path
                Computation Using a Key-Based Mechanism", Work in
                Progress, November 2008.
 [PCE-MANAGE]   Farrel, A., "Inclusion of Manageability Sections in
                PCE Working Group Drafts", Work in Progress,
                January 2009.
 [PCE-MONITOR]  Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
                monitoring tools for Path Computation Element based
                Architecture", Work in Progress, November 2008.
 [RFC2702]      Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
                J. McManus, "Requirements for Traffic Engineering Over
                MPLS", RFC 2702, September 1999.
 [RFC4105]      Le Roux, J., Vasseur, J., and J. Boyle, "Requirements
                for Inter-Area MPLS Traffic Engineering", RFC 4105,
                June 2005.
 [RFC4216]      Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous
                System (AS) Traffic Engineering (TE) Requirements",
                RFC 4216, November 2005.
 [RFC4655]      Farrel, A., Vasseur, J., and J. Ash, "A Path
                Computation Element (PCE)-Based Architecture",
                RFC 4655, August 2006.

Vasseur, et al. Standards Track [Page 16] RFC 5441 BRPC April 2009

 [RFC4726]      Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework
                for Inter-Domain Multiprotocol Label Switching Traffic
                Engineering", RFC 4726, November 2006.
 [RFC5088]      Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
                "OSPF Protocol Extensions for Path Computation Element
                (PCE) Discovery", RFC 5088, January 2008.
 [RFC5089]      Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
                "IS-IS Protocol Extensions for Path Computation
                Element (PCE) Discovery", RFC 5089, January 2008.
 [RFC5152]      Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-
                Domain Path Computation Method for Establishing Inter-
                Domain Traffic Engineering (TE) Label Switched Paths
                (LSPs)", RFC 5152, February 2008.
 [RFC5316]      Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
                Support of Inter-Autonomous System (AS) MPLS and GMPLS
                Traffic Engineering", RFC 5316, December 2008.
 [RFC5392]      Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
                Support of Inter-Autonomous System (AS) MPLS and GMPLS
                Traffic Engineering", RFC 5392, January 2009.

Vasseur, et al. Standards Track [Page 17] RFC 5441 BRPC April 2009

Authors' Addresses

 JP Vasseur (editor)
 Cisco Systems, Inc
 1414 Massachusetts Avenue
 Boxborough, MA  01719
 USA
 EMail: jpv@cisco.com
 Raymond Zhang
 BT Infonet
 2160 E. Grand Ave.
 El Segundo, CA  90025
 USA
 EMail: raymond.zhang@bt.com
 Nabil Bitar
 Verizon
 117 West Street
 Waltham, MA  02451
 USA
 EMail: nabil.n.bitar@verizon.com
 JL Le Roux
 France Telecom
 2, Avenue Pierre-Marzin
 Lannion,   22307
 FRANCE
 EMail: jeanlouis.leroux@orange-ftgroup.com

Vasseur, et al. Standards Track [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5441.txt · Last modified: 2009/04/06 17:29 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki