[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 rfc4927                                     
Network Working Group                             J.-L. Le Roux (Editor)
Internet Draft                                            France Telecom

Category: Informational
Expires: August 2006
                                                           February 2006

 PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area
                       (G)MPLS Traffic Engineering


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Le Roux et al.                                                  [Page 1]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006


   For scalability purposes a network may comprise multiple IGP areas.
   An inter-area TE-LSP is an LSP that transits through at least two IGP
   areas. In a multi-area network, topology visibility remains local to
   a given area, and a head-end LSR cannot compute alone an inter-area
   shortest constrained path. One key application of the Path
   Computation Element (PCE) based architecture is the computation of
   inter-area TE-LSP paths. This document lists a detailed set of PCE
   Communication Protocol (PCECP) specific requirements for support of
   inter-area TE-LSP path computation. It complements generic
   requirements for a PCE Communication Protocol.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119.

Table of Contents

   1.      Contributors................................................3
   2.      Terminology.................................................3
   3.      Introduction................................................3
   4.      Motivations for PCE-based Inter-Area Path Computation.......4
   5.      Detailed Inter-Area Specific Requirements on PCECP..........5
   5.1.    Control of area crossing....................................5
   5.2.    Area Recording..............................................6
   5.3.    Strict Explicit Path and Loose Path.........................6
   5.4.    PCE-list Enforcement and Recording in Multiple PCE
   5.5.    Inclusion of Area IDs in Request............................6
   5.6.    Inter-area Diverse Path computation.........................7
   5.7.    Inter-Area Policies.........................................7
   6.      Manageability Considerations................................7
   7.      Security Considerations.....................................8
   8.      Acknowledgments.............................................8
   9.      Informative References......................................8
   10.     Editor Address:.............................................9
   11.     Contributors' Addresses.....................................9
   12.     Intellectual Property Statement............................10

Le Roux et al.                                                [Page 2]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

1. Contributors

   The following are the authors that contributed to the present

   Jerry Ash (AT&T)
   Nabil Bitar (Verizon)
   Dean Cheng (Cisco)
   Kenji Kumaki (KDDI)
   J.L. Le Roux (France Telecom)
   Eiji Oki (NTT)
   Raymond Zhang (BT Infonet)
   Renhai Zhang (Huawei)

2. Terminology

      LSR: Label Switching Router.

      LSP: MPLS Label Switched Path.

      TE-LSP: Traffic Engineering Label Switched Path.

      IGP area: OSPF Area or IS-IS level.

      ABR: IGP Area Border Router, a router that is attached to more
           than one IGP areas (ABR in OSPF or L1/L2 router in IS-IS).

      Inter-Area TE LSP: TE LSP that traverses more than one IGP area.

      CSPF: Constrained Shortest Path First.

      SRLG: Shared Risk Link Group.

      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

      PCC: Path Computation Client, any application that request path
           computation to be performed by a PCE.

      PCECP: PCE Communication Protocol, a protocol for communication
             between PCCs and PCEs, and between PCEs.

3. Introduction

   [RFC4105] lists a set of motivations and requirements for setting up
   TE-LSPs across IGP area boundaries. These LSPs are called inter-area
   TE-LSPs. These requirements include the computation of inter-
   area shortest constrained paths with key guideline being to respect
   the IGP hierarchy concept, and particularly the containment of
   topology information. The main challenge with inter-area MPLS-TE

Le Roux et al.                                                [Page 3]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

   relies actually on path computation. Indeed the head-end LSR cannot
   compute a constrained path across areas, as its topology visibility
   is limited to its own area.

   Inter-area path computation is one of the key applications of the PCE
   based architecture [PCE-ARCH]. The computation of optimal inter-area
   paths may be achieved using the services of one or more PCEs.
   Such PCE-based inter-area path computation could rely for instance on
   a single multi-area PCE that has the TE database of all the areas in
   the IGP domain and can directly compute an end-to-end constrained
   shortest path.  Alternatively, this could rely on the cooperation
   between PCEs whereby each PCE covers one or more IGP areas and the
   full set of PCEs covers all areas.

   The generic requirements for a PCE Communication Protocol (PCECP),
   which allows a PCC to send path computation requests to a PCE and the
   PCE to sent path computation responses to a PCC, are set forth in
   [PCE-COM-REQ]. The use of a PCE-based approach for inter-area path
   computation implies specific requirements on a PCE Communication
   Protocol, in addition to the generic requirements already listed in
   [PCE-COM-REQ]. This document complements these generic requirements
   by listing a detailed set of PCECP requirements specific to inter-
   area path computation.

   It is expected that a solution for a PCECP satisfies these

   Note that PCE-based inter-area path computation may require a
   mechanism for an automatic PCE discovery across areas, which is out
   of the scope of this document. Detailed requirements for such a
   mechanism are discussed in [PCE-DISCO-REQ].

4. Motivations for PCE-based Inter-Area Path Computation

   IGP hierarchy allows improving IGP scalability, by dividing the IGP
   domain into areas and limiting the flooding scope of topology
   information to area boundaries. A router in an area has full topology
   information for its own area but only reachability to destinations in
   other areas._ Thus, a head-end LSR cannot compute an end-to-end
   constrained path that traverses more than one IGP area.

   A solution for computing inter-area TE-LSP path currently relies on a
   per domain path computation ([PD-COMP]). It is based on loose hop
   routing with an ERO expansion on each ABR. This can allow setting up
   a constrained path, but faces two major limitations:
   - This does not allow computing an optimal constrained path
   - This may lead to several crankback signaling messages and
     hence delay the LSP setup, and also invoke possible alternate
     routing activities.

   Note that, here, by optimal constrained path we mean the shortest
   constrained path across multiple areas, taking into account either

Le Roux et al.                                                [Page 4]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

   the IGP or TE metric [METRIC]. In other words, such a path is the
   path that would have been computed by making use of some CSPF
   algorithm in the absence of multiple IGP areas.

   The PCE based architecture [PCE-ARCH] is well suited to inter-area
   path computation, as it allows overcoming the path computation
   limitations resulting from the limited topology visibility, by
   introducing path computation entities with more topology visibility,
   or by allowing cooperation between path computation entities in each

   There are two main approaches for the computation of an inter-area
   optimal path:
   - Single PCE computation: The path is computed by a single PCE that
     has topology visibility in all areas and can alone compute an end-
     to-end optimal constrained path.
   - Multiple PCE computation with inter-PCE communication: the path
     computation is distributed on multiple PCEs, which have partial
     topology visibility. They compute path segments in their areas of
     visibility and collaborate with each other so as to arrive at an
     end-to-end optimal constrained path. Such collaboration is ensured
     thanks to inter-PCE communication.

   Note that the use of a PCE-based approach, to perform inter-area path
   computation implies specific functional requirements in a PCECP, in
   addition to the generic requirements listed in [PCE-COM-REQ]. These
   specific requirements are discussed in next section.

5. Detailed Inter-Area Specific Requirements on PCECP

   This section lists a set of additional requirements for the PCECP
   that complement requirements listed in [PCE-COM-REQ] and are specific
   to inter-area (G)MPLS TE path computation.

5.1. Control of area crossing

   In addition to the path constraints specified in Section 6.1.16 of
   [PCE-COM-REQ], the request message MUST allow indicating whether area
   crossing is allowed or not.
   Indeed, when the source and destination reside in the same IGP area,
   there may be intra-area and inter-area feasible paths. As set forth
   in [RFC4105], if the shortest path is an inter-area path, an operator
   either may want to avoid, as far as possible, crossing areas and thus
   may prefer selecting a sub-optimal intra-area path or, conversely,
   may prefer to use a shortest path, even if it crosses areas.

   Also, when the source and destinations reside in the same area it may
   be useful to know whether the returned path is an inter-area path.
   Hence the response message MUST allow indicating whether the computed
   path is crossing areas.

Le Roux et al.                                                [Page 5]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

5.2. Area Recording

   It may be useful for the PCC to know the set of areas crossed by an
   inter-area path and the corresponding path segments. Hence the
   response message MUST support the inclusion of the identifiers of the
   crossed areas and MUST allow identifying the corresponding path

5.3. Strict Explicit Path and Loose Path

   A Strict Explicit Path is defined as a set of strict hops, while a
   Loose Path is defined as a set of at least one loose hop and zero,
   one ore more strict hops. An inter-area path may be strictly explicit
   or loose (e.g. a list of ABRs as loose hops). It may be useful to
   indicate to the PCE if a Strict Explicit path is required or not.
   Hence the PCECP request message MUST allow indicating whether a
   Strict Explicit Path is required/desired.

5.4. PCE-list Enforcement and Recording in Multiple PCE Computation

   In case of multiple-PCE inter-area path computation, a PCC may want
   to indicate a preferred list of PCEs to be used. Hence the PCECP
   request message MUST support the inclusion of a list of preferred
   PCEs. Note that this requires that a PCC in one area have knowledge
   of PCEs in other areas. This could rely on configuration or on a PCE
   discovery mechanism, allowing discovery across area boundaries (see

   Also it would be useful to know the list of PCEs which effectively
   participated in the computation. Hence the request message MUST
   support a request for PCE recording and the response message MUST
   support the recording of the set of one or more PCEs that took part
   in the computation.
   It may also be useful to know the path segments computed by each PCE.
   Hence the request message SHOULD allow a request for the
   identification of path segments computed by a PCE, and the response
   message SHOULD allow identifying the path segments computed by each

5.5. Inclusion of Area IDs in Request

   The knowledge of the areas in which the source and destination lie
   would allow selection of appropriate cooperating PCEs. A PCE may not
   be able to determine the location of the source and destination and
   in such a case it would be useful that a PCC indicates the source and
   destination area IDs.
   For that purpose the request message MUST support the inclusion of
   the source and destination area IDs. Note that this information could
   be learned by the PCC through configuration.

Le Roux et al.                                                [Page 6]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

5.6. Inter-area Diverse Path computation

   For various reasons, including protection and load balancing, the
   computation of diverse inter-area paths may be required.
   There are various levels of diversity in an inter-area context:
        -Per-area diversity (intra-area path segments are link, node or
         SRLG disjoint)
        -Inter-area diversity (end-to-end inter-area paths are link,
         node or SRLG disjoint)

   Note that two paths may be disjoint in the backbone area but non-
   disjoint in peripheral areas. Also two paths may be node disjoint
   within areas but may share ABRs, in which case path segments within
   an area are node disjoint but end-to-end paths are not node-disjoint.

   The request message MUST allow requesting the computation of a set of
   inter-area diverse paths between the same node pair or between
   distinct node pairs. It MUST allow indicating the required level of
   intra-area diversity (link, node, SRLG) on a per area basis, as well
   as the level of inter-area diversity (shared ABRs or ABR

   The response message MUST allow indicating the level of diversity of
   a set of computed loose paths.

   Note that specific objective functions may be requested for diverse
   path computation, such as minimizing the cumulated cost of a set of
   diverse paths as set forth in [PCE-COM-REQ].

5.7. Inter-Area Policies

   As already defined in Section 5.1, a request message MUST allow
   indicating whether area crossing is allowed or not.

   A PCE may want to apply policies based on the initiating PCC.
   In a multiple-PCE computation the address of the initiating PCC may
   no longer be part of the request messages sent between PCEs.
   Hence, the request message MUST support the inclusion of the address
   of the originating PCC.

   Note that in some cases it is important to contain an inter-area
   path within a single AS. Hence the request message MUST allow
   indicating that AS crossing is not authorized.

6. Manageability Considerations

   The inter-area application does not imply new manageability
   requirements beyond those already defined in [PCE-COM-REQ].

Le Roux et al.                                                [Page 7]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

7. Security Considerations

   IGP areas are administrated by the same entity. Hence the inter-area
   application does not imply a new trust model, or new security issues
   beyond those already defined in [PCE-COM-REQ].

8. Acknowledgments

   We would also like to thank Adrian Farrel, Jean-Philippe Vasseur,
   Bruno Decraene, Yannick Le Louedec and Dimitri Papadimitriou for
   their useful comments and suggestions.

9. Informative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
   3667, February 2004.

   [BCP79] Bradner, S., "Intellectual Property Rights in IETF
   Technology", RFC 3979, March 2005.

   [RFC4105] Le Roux J.L., Vasseur J.P., Boyle, J., et al. "Requirements
   for inter-area MPLS-TE" RFC 4105, June 2005.

   [PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, “Path Computation
   Element (PCE) Based Architecture”, work in progress.

   [PCE-COM-REQ] J. Ash, J.L Le Roux et. al., “PCE Communication
   Protocol Generic Requirements”, work in progress.

   [PCE-DISC-REQ] J.L. Le Roux et. al., “Requirements for Path
   Computation Element (PCE) Discovery”, work in progress.

   [PD-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., "A Per-domain path
   computation method for computing Inter-domain Traffic Engineering
   (TE) Label Switched Path (LSP)", work in progress.

   [METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P.,
   and T. Telkamp, "Use of Interior Gateway Protocol(IGP) Metric as a
   second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May

   [ID-RSVP] Ayyangar, A., Vasseur, J.P., "Inter domain GMPLS Traffic
   Engineering - RSVP-TE extensions", work in progress.

Le Roux et al.                                                [Page 8]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

10. Editor Address:

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   Email: jeanlouis.leroux@francetelecom.com

11. Contributors' Addresses

   Jerry Ash
   Room MT D5-2A01
   200 Laurel Avenue
   Middletown, NJ 07748, USA
   Phone: +1-(732)-420-4578
   Email: gash@att.com

   Nabil Bitar
   40 Sylvan Road
   Waltham, MA 02145
   Email: nabil.bitar@verizon.com

   Dean Cheng
   Cisco Systems Inc.
   3700 Cisco Way
   San Jose CA 95134 USA
   Phone: +1 408 527 0677
   Email: dcheng@cisco.com

   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower
   Iidabashi, Chiyoda-ku,
   Tokyo 102-8460, JAPAN
   Phone: +81-3-6678-3103
   Email: ke-kumaki@kddi.com

   Eiji Oki
   Midori-cho 3-9-11
   Musashino-shi, Tokyo 180-8585, JAPAN
   Email: oki.eiji@lab.ntt.co.jp

   Raymond Zhang
   BT INFONET Services Corporation
   2160 E. Grand Ave.
   El Segundo, CA 90245 USA
   Email: raymond_zhang@bt.infonet.com

Le Roux et al.                                                [Page 9]

Internet Draft draft-ietf-pce-pcecp-interarea-reqs-01.txt  February 2006

   Renhai Zhang
   Huawei Technologies
   No. 3 Xinxi Road, Shangdi,
   Haidian District,
   Beijing City,
   P. R. China
   Email: zhangrenhai@huawei.com

12. Intellectual Property Statement

   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

   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

   Disclaimer of Validity

   This document and the information contained herein are provided on an

   Copyright Statement

   Copyright (C) The Internet Society (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.

Le Roux et al.                                               [Page 10]