[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-leroux-pce-pcecp-interarea-reqs) 00 01 02 03 04 05 06 RFC 5376

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00 August 2006

Network Working Group              Nabil Bitar (Editor)
Internet Draft                     Raymond Zhang (Editor)
                                   BT Infonet
                                   Kenji Kumaki (Editor)
                                   KDDI Corporation

Expires: January 2007              August 2006

  Inter-AS Requirements for the Path Computation Element Communication
                            Protocol (PCECP)


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-

   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

   This Internet-Draft will expire in December 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Bitar et al.        Inter-AS Requirements for PCECP            [Page 1]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006


   This document discusses requirements for the support of the Path
   Computation Element Communication Protocol (PCECP) in inter-AS
   applications. Its main objective is to present a set of requirements
   which would result in guidelines for the definition, selection and
   specification development for any technical solution(s) meeting these

   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. Introduction.....................................................2
   2. Definitions......................................................3
   3. Reference Model..................................................4
   4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............4
   4.1.1. PCC/PCE-PCE Communication Protocol Requirements..............4 Requirements on path computation requests..................4 Requirements on path computation responses.................6
   4.1.2. Scalability and Performance Requirements.....................6
   4.1.3. Management, Aliveness Detection and Recovery Requirements....7
   4.1.4. Confidentiality..............................................8
   4.1.5. Policy Controls Effecting inter-AS PCECP.....................8 Inter-AS PCE Peering Policy Controls.......................8 Inter-AS PCE Reinterpretation Polices......................9
   5. Security Considerations..........................................9
   6. IANA Considerations..............................................9
   7. Acknowledgments..................................................9
   8. Authors' Addresses...............................................9
   9. Normative References............................................10
   10. Informative References.........................................10


   MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ]
   defined the scenarios motivating the deployment of inter-AS MPLS
   traffic engineering. [INTERAS-TE-REQ] also specified the requirements
   for inter-AS MPLS traffic engineering when the ASes are under one
   Service Provider (SP) administration or the administration of
   different SPs.

   Today, there are three signaling options in setting up an inter-AS
   TE LSP: 1) contiguous TE LSP as documented in [INTERD-TESIG]; 2)
   Stitched inter-AS TE LSP discussed in [LSP-STITCHING]; 3) nested TE
   LSP as in [LSP-HIERARCHY]. In addition, [INTERD-TE-PDPC] defines
   mechanisms for inter-domain path computation using network elements
   along the signaling and data paths.  The mechanisms in [INTERD-TE-

Bitar, Zhang et al.                                           [Page 2]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006

   PDPC] do not provide the capability to guarantee an optimum TE path
   across multiple ASes. A (G)MPLS-TE optimum path for an LSP is one
   that has the smallest cost, according to a normalized TE metric
   (based upon a TE-metric or IGP metric adopted in each transit AS),
   among all possible paths that satisfy the LSP TE-constraints.

   The requirements for a PCE have risen from SP needs to compute a more
   optimum path than that can be achieved by mechanisms provided in
   [INTERD-TE-PDPC], and be able to separate the path computation
   elements from the forwarding elements.

   Generic requirements for the PCE discovery protocol (PCEDP) and
   PCC/PCE-PCE communication protocol (PCECP) are discussed in [PCEDP-
   REQ] and [PCECP-REQ], respectively. Complementary to these already-
   defined generic requirements, this document provides a set of PCECP
   requirements that are specific to (G)MPLS-TE inter-AS path
   computation using a PCE-based approach.

   Section 2 of this document states some definitions. Section 3 defines
   a reference model. Section 4 states inter-AS PCECP requirements.
   Section 5 discusses security issues.


   This document adopts the definitions and acronyms defined in
   [INTERAS-TE-REQ] Section 3.1 and [PCE-ARCH] Section 2. In addition,
   we use the following terminology:

    PCECP: PCE Communication Protocol

    PCEDP: PCE Discovery Protocol

    Inter-AS (G)MPLS-TE path: A (G)MPLS-TE path that traverses two or
    more ASes

    Intra-AS (G)MPLS-TE path: A (G)MPLS-TE path that is confined to a
    single AS. It may traverse on or more IGP areas.

    Inter-area PCE: A PCE responsible for computing (G)MPLS-TE paths or
    path segments traversing across multi-IGP areas.

    Intra-AS PCE: A PCE responsible for computing (G)MPLS-TE paths
    traversing a single AS.

    Inter-AS PCE: A PCE responsible for computing inter-AS (G)MPLS-
    TE paths or path segments, by possibly cooperating with intra-AS
    PCEs, across one or more ASes.

Bitar, Zhang et al.                                           [Page 3]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006

  Reference Model

   Figure 1 depicts the reference model for PCEs in an inter-AS
   application. We refer to two types of PCE functions in this document:
   inter-AS PCEs and intra-AS PCEs. Inter-AS PCEs perform the procedures
   needed for inter-AS (G)MPLS-TE path computation while intra-AS PCEs
   perform the functions needed for intra-AS (G)MPLS-TE path
   computation. This document focuses on the PCE Communication Protocol
   requirements used by inter-AS PCEs to communicate path
   requests/responses to other inter-AS PCEs and by intra-AS PCEs to
   communicate path requests/responses to inter-AS PCEs and vice versa.

            Inter-AS        Inter-AS              Inter AS
              PCE1<---------->PCE2<-------------->  PCE3
               ::              ::                    ::
         |      |        |            |        |           |
         |      |        |            |        |           |
         <==AS1=>       <====AS2======>      <=====AS3===>

      Figure 1 Inter and Intra-AS PCE Reference Model

  Detailed PCECP Requirements for Inter-AS (G)MPLS-TE

   This section discusses detailed PCECP requirements for inter-AS
   (G)MPLS-TE applications using a PCE-based approach. Depending on the
   operation environment, service providers may use some or all of the
   capabilities of a PCECP that satisfies these requirements.
   Specifically, some requirements are more applicable to inter-AS
   inter-provider (G)MPLS-TE operation than intra-provider operations.

      PCC/PCE-PCE Communication Protocol Requirements

   Requirements specific to inter-AS PCECP path computation requests
   and responses are discussed in section and,
         Requirements on path computation requests

Bitar, Zhang et al.                                           [Page 4]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006

   Following are inter-AS specific requirements on PCECP requests for
   path computation

   - PCECP MUST allow the specification of a path computation request
   priority as specified in [PCECP-REQ]. Priority-based message
   processing is a local decision to a PCE and is out of the scope of
   this document. However, in inter-AS operation, a policy may be
   enforced on a path computation request so that the path computation
   request priority is altered when progressing the request within the
   same AS or across other ASes. PCECP SHOULD allow the notification of
   the requester of such a change when it happens. Such notification MAY
   be suppressed by configuration action on a neighboring inter-AS PCE

   - A path computation request to an inter-AS PCE MUST be able to
   specify ASBRs and/or ASes as strict and loose nodes in the path of
   the LSP to the destination. A PCE MUST also be able to specify a
   preferred ASBR for exiting to the next AS for reaching the
   destination through a neighboring AS. If such a constraint cannot
   be satisfied at a PCE, PCECP SHOULD allow a PCE to notify the
   requestor of that fact in the path error message.

   - PCECP MUST enable enlisting a list of ASes and/or ASBRs to be
   excluded in the path computation.

   - PCECP MUST enable an inter-AS PCE to specify the AS on whose behalf
   it is sending the request. This is specifically important when the
   inter-AS PCE has identified many ASes within its scope to the other
   inter-AS PCE at the other end of the communication.

   - A PCC or PCE (including inter-AS PCE) MUST be able to specify in
   its PCECP path computation request the need for computing an end-to-
   end path with protection against node, link, and/or SRLG
   failure using 1:1 detours or facility backup. An inter-AS PCE may
   itself ask for a similarly protected path. In addition, it may ask
   for protection across all ASes the path can traverse or across
   specific ASes.

   - A PCC or PCE MUST be able to specify in its path request to an
   inter-AS PCE the retturn of a minimum of two diversified paths
   (i.e., paths that do not share common nodes, links and/or SRLGs).

   - A PCECP path computation request message MUST enable the
   specification of AS-only diversified path computation.

   - A PCECP path computation request message MUST be able to identify
   the scope of diversified path computation to be end-to-end (i.e.,
   between the endpoints of the (G)MPLS-TE tunnel) or to be limited to a
   specific AS.

Bitar, Zhang et al.                                           [Page 5]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006
         Requirements on path computation responses

   Following are inter-AS specific requirements on PCECP responses for
   path computation:

   - A path computation response MUST be able to include ASBRs and ASes
   on the computed path. In inter-AS intra-provider path
   computation, there may not be any confidentiality issues or
   restrictions that prevent one AS from returning a path with strict
   hops and no loose hops (i.e., nodes and links) within its AS to the
   requesting inter-AS PCE. In this case, the head-end of an LSP could
   receive, as a result of the work of multiple cooperating intra-AS and
   inter-AS PCEs, a path that contains nodes and links as strict hops
   from LSP head-end to tail-end.  In the inter-provider case,
   confidentially and security considerations may require only the
   return of AS numbers and/or ASBRs in path computation response

   - A PCECP response message MUST be able to carry an identifier for a
   path segment computed by the responding PCE. Such an identifier could
   be used in a (G)MPLS-TE path setup message for path expansion at an

   - A PCECP response message MUST be able to carry an inter-AS
   path cost. Path cost normalization across ASes is out
   of the scope of this document and it is expected to be addressed
   in other work on path computation.

   - A PCECP response message SHOULD be able to carry an intra-AS cost
   for a path segment separately from an inter-AS path segment cost.
   Best path selection procedures based on these costs are out of the
   scope of this document.

   - A PCECP response message MUST be able to identify diversified paths
   for the same(G)MPLS-TE LSP when the responding PCE is requested to
   compute such paths. End-to-end (i.e., between the two endpoints of
   the (G)MPLS-TE tunnel) disjoint diversified paths are paths that do
   not share nodes, links or SRLGs except for the LSP head-end and tail-
   end. In cases where diversified path segments are desired within one
   or more ASes, the diversified path segments may share only the ASBRs
   of the first AS and the ASBR of the last AS across these ASes.

      Scalability and Performance Requirements

   When evaluating a PCECP for the inter-AS case, the following
   scalability and performance criteria SHOULD be considered:

   - Message Processing load on the inter-AS PCEs and intra-AS PCEs.
   - Scalability as a function of the following parameters:

Bitar, Zhang et al.                                           [Page 6]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006

        - number of PCCs within the scope of an inter-AS PCE
        - number of intra-area PCEs within the scope of an inter-AS PCE
        - number of peering inter-AS PCEs
   - Added complexity and features to the PCC/PCE-PCE communication

      Management, Aliveness Detection and Recovery Requirements

   [PCECP-REQ] specifies generic requirements for PCECP management. This
   document addresses new requirements that apply to inter-AS

   The PCECP MIB module MUST provide objects to control the behavior of
   PCECP in inter-AS applications, including the ASes within its scope,
   the ASes the PCE cannot communicate with via PCECP, the ASes that the
   PCE can communicate with, confidentiality policies, and traffic
   engineering policies. Each of these two latter requirements SHOULD
   apply per inter-AS PCE and/or AS peer.

   The built-in diagnostic tools MUST enable failure detection and
   status checking of PCC/PCE-PCE PCECP. Diagnotic tools include
   statistics collection on the historical behavior of PCECP as
   specified in [PCECP-REQ]. For inter-AS operations, this statistics
   SHOULD be collected on per inter-AS PCE peer basis and per AS. For
   instance, the following statistics SHOULD be collected:
   - number of successfully satisfied requests
   - number of rejected requests per reason
   - number of PCE requests
   - number of malformed PCECP messages
   - number of unauthenticated PCECP messages

   The MIB module MUST support trap functions when thresholds are
   crossed or when important events occur for inter-AS PCEs. These
   thresholds SHOULD be specifiable per peer AS as well as per peer
   inter-AS PCE and traps should be accordingly generated.

   Basic liveliness detection for PCC/PCE-PCE communication is described
   in [PCECP-REQ]. Specifically, the PCECP must allow an inter-AS PCE to
   check the liveliness of the neighboring inter-AS PCE(s) it is
   communicating with for inter-AS (G)MPLS-TE path computation. The
   inter-AS PCECP MIB module SHOULD allow control of liveliness check
   behavior by providing a liveliness message frequency MIB object. This
   frequency SHOULD be specified per inter-AS PCE peer. In addition,
   there SHOULD a MIB object that specifies the dead-interval as a
   multiplier of the liveliness message frequency so that if no
   liveliness message is received within that time from an inter-A PCE,
   the inter-AS PCE is declared unreachable.

Bitar, Zhang et al.                                           [Page 7]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006


   Confidentiality mainly applies to inter-provider PCE communication.
   However, confidentiality rules may also apply among ASes under a
   single provider. Each SP will in most cases designate some PCEs for
   inter-AS (G)MPLS-TE path computation within its own administrative
   domain and some other PCEs for inter-provider inter-As (G)MPLS-TE
   path computation.  Among the inter-provider-scoped inter-AS PCEs in
   each SP domain, there may also be a subset of the PCEs specifically
   enabled for path computation across a specific set of ASes of
   different peer SPs.

   PCECP SHOULD allow an SP to hide from other SPs the set of hops,
   within its own AS(es,) traversed by an inter-AS inter-provider
   (G)MPLS-TE LSP (c.f., Section 5.2.1 of [INTERAS-TE-REQ]).  In a
   multi-SP administrative domain environment, SPs want to hide their
   network topologies for security reasons. In addition, SPs do not want
   to reveal the path traversed by an LSP segment within their domains
   to other SPs' domains. Thus, for each partial inter-AS LSP path a PCE
   computes, it may return to its peering PCE in the upstream neighbor
   AS(es) an inter-AS TE LSP  segment from its own AS(es) without
   detailing the explicit intra-AS hops plus partial paths with an
   aggregated TE LSP cost it receives from its downstream PCE. As stated
   earlier, PCECP responses SHOULD be able to carry path-segment
   identifiers without the details of that path segment. An ASBR that
   receives an RSVP-TE path message with an identifier object
   (new object), it can use that object to contact the PCE keyed by
   that identifier and extract the identified path segment as well.

      Policy Controls Effecting inter-AS PCECP

   Section 5.2.2 of [INTERAS-TE-REQ] discusses the policy control
   requirements on the inter-AS RSVP-TE signaling at the AS boundaries
   for the enforcement of interconnect agreements, attribute/parameter
   translation and security hardening.

   This section discusses those policy control requirements for PCECP.
   Please note that SPs may still require ingress policy controls on the
   actual signaling paths mentioned above to enforce their bilateral or
   multi-lateral agreements at the AS boundaries.
         Inter-AS PCE Peering Policy Controls

   In a multi-SP administrative domain environment, each SP itself has
   some policies for a (G)MPLS-TE enabled network. An inter-AS PCE sends
   path computation requests with some parameters to its neighboring
   inter-AS PCEs. An inter-AS PCE that receives such requests enforces
   some policies applied to its neighboring inter-AS PCEs. These
   policies may include rewriting some of the parameters' values and
   rejecting requests based on some parameters' values. Such policies
   may also be applied in the case of multiple ASes within a single SP

Bitar, Zhang et al.                                           [Page 8]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006

   administrative domain. Parameters subject to policy include
   bandwidth, setup/holding priority, Fast Reroute request,
   Differentiated Services Traffic Engineering (DS-TE) Class Type (CT),
   and others as specified in section of [INTERAS-TE-REQ].

   For path computation requests that are not compliant with configured
   policies, PCECP SHOULD enable a PCE to send an error message to the
   requesting PCC or PCE indicating the cause of errors.
           Inter-AS PCE Reinterpretation Polices

   Each SP may have different definitions in its use of for example,
   RSVP-TE session attributes, DS-TE TE classes, etc.  A PCE receiving
   path computation requests needs to be able to reinterpret some of the
   attributes and adapt them to the native environment in its own AS for
   path computation.  A list of such parameters subject to policy
   reinterpretation can be found in section of [INTERAS-TE-REQ].
   In addition, the transit SPs along the inter-AS TE path may be GMPLS
   transport providers which may require reinterpretation of MPLS
   specific PCECP path request messages for path computation over a
   GMPLS network.  These interpretation policies must be specifiable on
   a per-peer inter-AS PCE or AS basis as part of PCECP MIBs discussed

  Security Considerations

   Security concerns arise between any two communicating elements
   especially when the elements belong to different administrative
   entities. In this case, there are security concerns that need to be
   addressed for communication among inter-AS PCEs and other PCEs in a
   single SP administrative domain as well among inter-AS PCEs under
   different SP administrative domains. [PCECP-REQ] specifies
   requirements on PCECP to protect against spoofing, snooping and DoS
   attacks. These requirements become especially important in the multi-
   AS case.

  IANA Considerations

   This document makes no requests for IANA action.


   We would like to thank Adrian Farrel, Jean-Philippe Vasseur,
   and Jean Louis Le Roux for their useful comments and suggestions.

  Authors' Addresses

   Nabil Bitar

Bitar, Zhang et al.                                           [Page 9]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006

   40 Sylvan Road
   Waltham, MA 02451
   Email: nabil.n.bitar@verizon.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

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

   Normative References

   [INTERAS-TE-REQ] Zhang and Vasseur, "MPLS Inter-AS Traffic
   Engineering Requirements", RFC4216, November 2005.

   [PCE-ARCH] Farrel, Vasseur & Ash, "A Path Computation Element
   (PCE) Based Architecture", draft-ietf-pce-architecture-05.txt
   (Work in Progress).

   [PCECP-REQ] J. Ash, J.L Le Roux et al., "PCE Communication Protocol
   Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-
   06.txt (work in progress).

    Informative References

   [INTERD-TESIG] Ayyangar and Vasseur, "Inter domain GMPLS Traffic
   Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain-
   rsvp-te-02.txt, April 2006 (Work in Progress)

   [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP Stitching with
   Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt,
   September 2005, (work in progress).

   [LSP-HIERARCHY] Kompella K., Rekhter Y., "Label switched Paths (LSP)
   Hierarchy with Generalized MPLS TE", RFC4206, October 2005.

    [PCEDP-REQ] J.L. Le Roux et al., "Requirements for Path Computation
   Element(PCE) Discovery", draft-ietf-pce-discovery-reqs-03 (work in

Bitar, Zhang et al.                                          [Page 10]

Internet Draft  draft-ietf-pce-interas-pcecp-reqs-00   August 2006

   [INTERD-TE-PDPC] Vasseur, Ayyangar and Zhang, "A Per-domain path
   computation method for computing Inter-domain Traffic Engineering
   (TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
   path-comp-02.txt, February 2006, (Work in Progress).

   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 ietf-

   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.

Bitar, Zhang et al.                                          [Page 11]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/