Network Working Group                Nabil Bitar (Editor)
                                   Verizon
Internet Draft                       Verizon
                                     Raymond Zhang (Editor)
                                     BT Infonet
Intended Status: Informational       Kenji Kumaki (Editor)
                                     KDDI Corporation

Expires: January April 2007              August                  October 2006

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

                  draft-ietf-pce-interas-pcecp-reqs-00.txt

             draft-ietf-pce-interas-pcecp-reqs-01.txt

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.

   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 a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire in December 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document discusses requirements for the support of the

   Multiprotocol Label Switching Traffic Engineered (MPLS-TE)
   LabelSwitched Paths (LSPs) may be established wholly within an
   Autonomous System (AS) or may cross AS boundaries.

   The Path Computation Element Communication Protocol (PCECP) in inter-AS
   applications. Its main objective (PCE) is to present a set component that is capable of requirements
   which would result in guidelines
   computing paths for the definition, selection MPLS-TE LSPs. The PCE Communication
   Protocol(PCECP) is defined to allow communication between Path
   Computation Clients (PCCs) and
   specification development PCEs, and between PCEs. The PCECP is
   used to request paths and to supply computed paths in responses.
   Generic requirements for any technical solution(s) meeting these
   requirements. the PCECP are set out in "Path Computation
   Element(PCE) Communication Protocol Generic Requirements", RFC 4657.
   This document extends those requirements to cover the use of PCECP
   in support of inter-AS MPLS-TE.

Conventions used in this document

   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.

   Table of Contents

   1. Introduction.....................................................2 Introduction.....................................................3
   2. Definitions......................................................3
   3. Reference Model..................................................4
   4. Detailed PCECP Requirements for Inter-AS (G)MPLS-TE..............4
   4.1.1. PCC/PCE-PCE Computation.............5
   4.1. PCE Communication Protocol Requirements..............4
   4.1.1.1. Requirements........................5
   4.1.1. Requirements on for path computation requests..................4
   4.1.1.2. requests...................5
   4.1.2. Requirements on for path computation responses.................6
   4.1.2. responses..................6
   4.2. Scalability and Performance Requirements.....................6
   4.1.3. Requirements.......................7
   4.3. Management, Aliveness Detection Detection, and Recovery Requirements....7
   4.1.4. Confidentiality..............................................8
   4.1.5. Requirements.....8
   4.4. Confidentiality................................................8
   4.5. Policy Controls Effecting Affecting inter-AS PCECP.....................8
   4.1.5.1. PCECP.......................9
   4.5.1. Inter-AS PCE Peering Policy Controls.......................8
   4.1.5.2. Controls.........................9
   4.5.2. Inter-AS PCE Reinterpretation Polices......................9 Policies......................10
   5. Security Considerations..........................................9 Considerations.........................................10
   6. IANA Considerations..............................................9 Considerations.............................................11
   7. Acknowledgments..................................................9 Acknowledgments.................................................11
   8. Authors' Addresses...............................................9 Addresses..............................................11
   9. Normative References............................................10 References............................................11
   10. Informative References.........................................10 References.........................................12

1. Introduction

   MPLS Inter-AS traffic engineering requirements [INTERAS-TE-REQ]
   defined

   [RFC4216] defines the scenarios motivating the deployment of inter-AS MPLS
   traffic engineering. [INTERAS-TE-REQ] also specified inter-
   AS Multiprotocol Label Switching Traffic Engineering (MPLS-TE).
   [RFC4216] specifies the requirements for inter-AS MPLS traffic engineering MPLS-TE when the ASes
   ASs are under the administration of one Service Provider (SP) administration or the
   administration of different SPs.

   Today, there are three

   Three signaling options in are defined for 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, [RFC4206].

   [INTERD-TE-PDPC] defines mechanisms for inter-domain path the computation of inter-
   domain TE LSPs using network elements along the signaling and data paths. paths to
   compute per-domain path segments. The mechanisms in [INTERD-TE-
   PDPC] [INTERD-TE-PDPC]
   do not provide the capability to guarantee an optimum TE path across multiple ASes. A (G)MPLS-TE ASs where an
   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), AS) among all possible paths that satisfy
   the LSP TE-constraints.

   The Path Computation Element (PCE) [RFC4655] is a component that is
   capable of computing paths for MPLS-TE LSPs. The requirements for a
   PCE have risen come from SP needs Service Provider (SP) demands to compute a more optimum path than that can be achieved by mechanisms provided in
   [INTERD-TE-PDPC],
   paths across multiple domains, and to be able to separate the path
   computation elements from the forwarding elements.

   The PCE Communication Protocol (PCECP) is defined to allow
   communication between Path Computation Clients (PCCs) and PCEs, and
   between PCEs. The PCECP is used to request paths and to supply
   computed paths in responses. Generic requirements for the PCE discovery protocol (PCEDP) and
   PCC/PCE-PCE communication protocol (PCECP) PCECP are
   discussed in [PCEDP-
   REQ] and [PCECP-REQ], respectively. Complementary to these already-
   defined generic requirements, this [RFC4657]. This document provides a set of PCECP
   requirements that are specific to (G)MPLS-TE 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. computation.

2. Definitions

   This document adopts the definitions and acronyms defined in
   [INTERAS-TE-REQ] Section 3.1
   3 of [RFC4216] and [PCE-ARCH] Section 2. 2 of [RFC4655]. 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 An MPLS-TE or Generalized MPLS (GMPLS)
   path that traverses two or more ASes ASs.

   Intra-AS (G)MPLS-TE path: A (G)MPLS-TE An MPLS-TE or GMPLS path that is confined
   to a single AS. It may traverse on one 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 MPLS-TE or GMPLS paths
    traversing
   remaining within a single AS.

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

3. 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 MPLS-TE or GMPLS path computation
   while intra-AS PCEs perform the functions needed for intra-AS (G)MPLS-TE MPLS-
   TE or GMPLS path computation. This document focuses on

   Following is a scenario that depicts the PCE Communication Protocol
   requirements used by inter-AS PCEs to communicate path
   requests/responses to other interaction among PCCs,
   inter-AS PCEs and by intra-AS intra-area PCEs based on Figure 1. R1 in AS1
   wants to
   communicate setup a TE-LSP or a GMPLS path requests/responses with certain constraints
   to inter-AS PCEs and vice versa.

            Inter-AS        Inter-AS              Inter AS
              PCE1<---------->PCE2<-------------->  PCE3
               ::              ::                    ::
         R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
         |      |        |            |        |           |
         |      |        |            |        |           |
         R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
                               ::
                             Intra-AS
                               PCE
         <==AS1=>       <====AS2======>      <=====AS3===>

      Figure 1 Inter and Intra-AS PCE Reference Model

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

   This section discusses detailed PCECP requirements for inter-AS
   (G)MPLS-TE applications R7 in AS3. R1 determines, using a PCE-based approach. Depending on the
   operation environment, service providers may use some or all mechanisms out of the
   capabilities scope of a PCECP
   this document, that satisfies these requirements.
   Specifically, some requirements are more applicable R7 is an AS-external route and that it needs to inter-AS
   inter-provider (G)MPLS-TE operation than intra-provider operations.

4.1.1.       PCC/PCE-PCE Communication Protocol Requirements

   Requirements specific
   contact Inter-AS PCE1 to inter-AS compute the path. R1, as a PCC, sends a
   PCECP path computation requests
   and responses are discussed in section 4.1.1.1 request to PCE1. PCE1 determines that R7 is reachable via
   AS2 and 4.1.1.2,
   respectively.

 4.1.1.1.          Requirements on path computation requests
   Following are inter-AS specific requirements on PCECP requests that PCE2 is the PCE to ask for path computation

   - across AS2.
   PCE1 sends a PCECP MUST allow the specification of path request to PCE2. Inter-AS PCE2 in turn sends
   a PCECP path computation request
   priority to Intra-AS PCE R4 to compute a path within AS2
   (In certain cases, the same router such R3 can assume both inter-AS
   and intra-AS path computation functions). R4 returns a PCECP path
   response to PCE2 with ASBR3 as specified in [PCECP-REQ]. Priority-based message
   processing is the entry point to AS2 from AS1 and
   ASBR7 as the exit point to AS3. PCE2 then sends a local decision PCECP path request
   to PCE3 to compute the path segment across AS3, starting at ASBR7 and
   terminating at R7. PCE3 returns a PCECP path response to PCE2 with
   the path segment ASBR7-R7. PCE2 then return path ASBR3-ASBR7-R7 to
   PCE1 which in turn returns path ASBR1-ASBR3-ASBR7-R7 to PCC R1.

   As described in the above scenario, in general, a PCC may contact an
   inter-AS PCE to request an inter-AS path, and is out of that PCE may supply
   the scope path itself, or may solicit the services of
   this document. However, in other PCEs which
   may, themselves be inter-AS operation, a policy PCEs, or may be
   enforced on a intra-AS PCEs with the
   responsibility for computing path computation request so that segments within just one AS.

   This document describes the PCE Communication Protocol requirements
   for inter-AS path computation
   request priority is altered when progressing computation. That is, for PCCs to communicate path
   requests for inter-AS paths to a PCE, and for the request within PCE to respond. It
   also includes the
   same requirements for PCEs to communicate inter-AS path
   requests and responses.

             Inter-AS        Inter-AS              Inter AS or across other ASes.
        PCC <->PCE1<--------->PCE2<--------------->PCE3
         ::     ::             ::                   ::
         R1---ASBR1====ASBR3---R3---ASBR5====ASBR7---R5---R7
         |      |        |            |        |           |
         |      |        |            |        |           |
         R2---ASBR2====ASBR4---R4---ASBR6====ASBR8---R6---R8
                               ::
                             Intra-AS
                               PCE
         <==AS1=>        <====AS2======>       <=====AS3===>

      Figure 1 Inter and Intra-AS PCE Reference Model

4. Detailed PCECP SHOULD allow Requirements for Inter-AS Computation

   This section discusses detailed PCECP requirements for inter-AS
   MPLS-TE and GMPLS. Depending on the notification deployment environment, some or
   all of the requester of such requirements described here may be utilized.
   Specifically, some requirements are more applicable to inter-
   provider inter-AS MPLS-TE and GMPLS operations than to intra-
   provider operations.

    4.1. PCE Communication Protocol Requirements

   Requirements specific to inter-AS PCECP path computation requests
   and responses are discussed in Sections 4.1.1 and 4.1.2,
   respectively.

4.1.1. Requirements for path computation requests

   The following are inter-AS specific requirements for PCECP requests
   for path computation:

   1. [RFC4657] states the requirement for a priority level to be
   associated with each path computation request. This document does
   not change when that requirement, but in addition it happens. Such notification MAY MUST be suppressed by configuration action on possible for
   an inter-AS PCE to apply local policy to vary the priority of path
   computation requests received across AS borders. PCECP MAY include a neighboring
   mechanism to inform the requesting inter-AS PCE
   basis.

   - of the change in
   priority that was applied.

   2. A path computation request to by an inter-AS PCE or a PCC to another
   inter-AS PCE MUST be able to specify the sequence of ASs and/or
   ASBRs across the network by providing ASBRs and/or ASes ASs as strict and loose nodes hops in
   the desired path of the LSP to the destination. A For instance, an
   inter-AS PCE MUST also be be able to specify to the inter-AS PCE serving
   the neighboring AS a preferred ASBR for exiting to the next that AS for reaching and reach
   the
   destination through a neighboring AS. If such a constraint cannot destination. That is, where multiple ASBRs exist, the requester
   MUST be satisfied at able to indicate a PCE, non-mandatory preference for one of them.

   3. PCECP SHOULD MUST allow a PCE requester to notify the
   requestor of that fact in the path error message.

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

   - computed path.

   4. A PCECP MUST enable an path request from one inter-AS PCE to specify another MUST
   include the previous AS on whose behalf
   it is sending number in the request. This is specifically important when path of the
   inter-AS PCE has identified many ASes within its scope LSP to enable the other
   inter-AS PCE at the other end
   correct application of local policy at the communication.

   - second inter-AS PCE.

   5. A path computation request from a PCC or to an inter-AS PCE (including or an
   inter-AS PCE) PCE to another 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 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 It MUST be possible to request protection across
   all ASes the path can traverse ASs or across specific ASes.

   - A PCC or PCE ASs.

   6. The disjoint path requirements specified in [RFC4657] are
   extended such that it MUST be able possible to specify apply a constraint of AS-
   diversity in its path request to an
   inter-AS PCE the retturn computation of a minimum set 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.

   - or more paths.

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

 4.1.1.2.

4.1.2. Requirements on for path computation responses

   Following

   The following are inter-AS specific requirements on PCECP responses for PCECresponses
   for path computation:

   -

   1. A PCECP 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 one inter-AS PCEs, a path that contains nodes and links as strict hops
   from LSP head-end PCE to
another MUST be able to tail-end.  In the inter-provider case,
   confidentially and security considerations may require only the
   return of AS numbers and/or include ASBRs and ASs in the computed path computation response
   messages.

   - to
maintain path segment and topology confidentiality.

   2. A PCECP path computation response message from one inter-AS PCE to the
requesting inter-AS PCE MUST be able to carry an identifier for a path
segment computed by it computes to preserve path segment and topology
confidentiality. The objective of the responding PCE. Such an identifier could is to be used included in a (G)MPLS-TE path setup message
the LSP signaling, out of scope of this document, to be used for path
expansion at an
   ASBR.

   - during LSP signaling.

   3. If a constraint for a desired ASBR (see Section 4.1.1,
requirement 3) cannot be satisfied by a PCE, PCECP SHOULD allow the PCE
to notify the requester of that fact in a positive path computation
response.

   4. A PCECP response message path computation request from an inter-AS PCE to a
requesting inter-AS PCE or a PCC MUST be able to carry an a cumulative
inter-AS path cost. Path cost normalization across ASes ASs is out of the
scope of this document and it is expected to be addressed
   in other work on path computation.

   - document.

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

   - PCC AS.

   6. A PCECP path computation 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. same (G)MPLS-TE LSP. 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 head-
end and tail-
   end. tail-end. In cases where diversified path segments are desired
within one or more ASes, the diversified disjoint path segments may share only the
ASBRs of the first AS and the ASBR of the last AS across these ASes.

4.1.2.

    4.2. Scalability and Performance Requirements

   When evaluating a

    PCECP design for use in the inter-AS case, case SHOULD consider the
    following
   scalability and performance criteria SHOULD be considered: criteria:

        - Message Processing load on the inter-AS PCEs and intra-AS PCEs. PCE message processing load.
        - Scalability as a function of the following parameters:
          - number of PCCs within the scope of an inter-AS PCE
          - number of intra-area intra-AS PCEs within the scope of an inter-AS PCE
          - number of peering inter-AS PCEs per inter-AS PCE
        - Added complexity and features to the PCC/PCE-PCE communication
   protocol

4.1.3. caused by inter-AS features.

    4.3. Management, Aliveness Detection Detection, and Recovery Requirements

   [PCECP-REQ]

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

    The PCECP MIB module MUST provide objects to control the behavior
    of PCECP in inter-AS applications, including the ASes ASs within its scope, the ASes
    scope of an inter-AS PCE, neighboring ASs with whose inter-AS
    PCE(s) the inter-AS PCE cannot communicate MUST not communicate, neighboring ASs with via PCECP, the ASes that
    whose inter-AS PCEs the inter-AS PCE can communicate with, communicate,
    confidentiality policies, and traffic engineering policies. Each
    of these two latter requirements SHOULD
   apply per be applicable on inter-AS PCE and/or
    PCE-pair basis or neighboring AS peer. basis (i.e., apply to all inter-
    AS PCEs that belong to a neighboring AS).

    The built-in diagnostic tools MUST enable failure detection and
    status checking of PCC/PCE-PCE PCECP. Diagnotic Diagnostic tools include
    statistics collection on the historical behavior of PCECP as
    specified in [PCECP-REQ]. For inter-AS operations, [RFC4657], but additionally it MUST be possible to
    analyze this statistics
   SHOULD be collected on per inter-AS PCE peer a neighboring AS basis and per AS. For
   instance, (i.e., across
    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 inter-AS PCEs that belong to a neighboring AS).

    The MIB module MUST support trap functions when thresholds are
    crossed or when important events occur for inter-AS PCEs. as stated in [RFC4657].
    These thresholds SHOULD be specifiable per peer neighbor 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. [RFC4657]. The
   inter-AS  PCECP MIB module SHOULD allow control
    of liveliness check behavior by providing a liveliness message
    frequency MIB object. This object and this frequency object SHOULD be specified
    per inter-AS PCE peer. In addition, there SHOULD be 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 inter-AS PCE, the inter-AS PCE is declared
    unreachable.

4.1.4.

    4.4. Confidentiality
    Confidentiality mainly applies to inter-provider (inter-AS) PCE
    communication.
   However, confidentiality It is about protecting the information exchanged
    between PCEs and about protecting the topology information within
    a provider's network. Confidentiality rules may also apply among ASes
    ASs under a single provider. Each SP will in most cases designate
    some PCEs for inter-AS (G)MPLS-TE MPLS-TE or GMPLS path computation within
    its own administrative domain and some other PCEs for inter-provider inter-As (G)MPLS-TE inter-
    provider inter-AS MPLS-TE or GMPLS 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 ASs of different peer SPs.

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

4.1.5. expansion,
    for instance, during LSP signaling is out of the scope of this
    document.

    4.5. Policy Controls Effecting Affecting inter-AS PCECP

    Section 5.2.2 of [INTERAS-TE-REQ] [RFC4216] discusses the policy control
    requirements on the for 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 that are
    similar to what are discussed in section 5.2.2 of [RFC4216], for
    PCECP. Please note that SPs may still require ingress policy controls on the
   actual signaling paths mentioned above
    during signaling of LSPs to enforce their bilateral or
   multi-lateral multi-
    lateral agreements at the AS boundaries.

 4.1.5.1. boundaries, but signaling is out of scope
    for this document.

4.5.1. 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 PCEs, and an inter-AS PCE that receives
       such requests a request enforces
   some policies applied applicable to its neighboring inter-AS PCEs. the sender of the
       request. These policies may include rewriting some of the parameters' values and
       parameters, or rejecting requests based on some parameters' parameter values.
       Such policies may also be applied in the case of multiple ASes for PCEs belonging to different SPs
       or to PCEs responsible for ASs within a single SP administrative
       domain. Parameters that might be 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 5.2.2.1 of [INTERAS-TE-REQ]. [RFC4216].

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

 4.1.5.2. request has been rejected because a specific parameter did
       not satisfy the local policy.

4.5.2. Inter-AS PCE Reinterpretation Polices Policies

       Each SP may have different definitions in its use of of, for
       example,
   RSVP-TE session attributes, DS-TE TE classes, etc.  A classes. An inter-AS PCE receiving a path
       computation requests request needs to be able to reinterpret some of interpret the
   attributes parameters and
       constraints and adapt them to the native environment local environment.
       Specifically, a request constructed by a PCC or PCE in its own one AS for
   path computation.
       may have parameters and constraints that should be interpreted
       differently by the receiving PCE that is in a different AS. A
       list of such signaling parameters subject to policy reinterpretation
       at AS borders can be found in section 5.2.2.2 of [INTERAS-TE-REQ]. [RFC4216], and
       the list for patch computation request parameters and
       constraints is the same. 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
       objects to enable 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
   earlier.

5. 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 inter-
   AS PCEs under different SP administrative domains. [PCECP-REQ] [RFC4657]
   specifies requirements on PCECP to protect against spoofing,
   snooping and DoS attacks. These requirements become especially
   important in the multi-
   AS multi-AS case. An inter-AS PCE MUST be able to
   authenticate a peering inter-AS PCE as a legitimate peer. Since
   inter-AS PCEs can be auto-discovered by an inter-AS PCE and peering
   sessions are formed dynamically, mechanisms for securely exchanging
   authentication keys across SP boundaries MUST be defined. The
   autodiscovery process itself MUST also be authenticated.

6. IANA Considerations

   This document makes no requests for IANA action.

7. Acknowledgments

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

8. Authors' Addresses

   Nabil Bitar
   Verizon
   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

9. Normative References

   [INTERAS-TE-REQ]

   [RFC4216] Zhang and Vasseur, "MPLS Inter-AS Traffic Engineering
   Requirements", RFC4216, RFC 4216, November 2005.

   [PCE-ARCH]

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

   [PCECP-REQ] J. RFC 4655, August 2006.

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

10. Informative References

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

   [LSP-STITCHING] Ayyangar A., Vasseur JP., "LSP J,P., "Label Switched Path
   Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching-02.txt,
   September 2005, Traffic Engineering", draft-ietf-
   ccamp-lsp-stitching-03.txt, March 2006, (work in progress).

   [LSP-HIERARCHY] Kompella

   [RFC4206] Kompella, K., Rekhter Rekhter, Y., "Label switched Paths (LSP) 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
   progress).

   [INTERD-TE-PDPC] Vasseur, Ayyangar Vasseur,J.P, Ayyangar, A., and Zhang, R., "A Per-domain Per-
   domain path computation method for computing establishing Inter-domain Traffic
   Engineering (TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd-
   path-comp-02.txt, February Paths (LSPs)", draft-ietf-ccamp-inter
   -domain-pd-path-comp-03.txt, August 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 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.

Disclaimer of Validity

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

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.