[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                 M. Boucadair (Ed.)
                                                         P. Morand (Ed.)
Internet Draft                                        France Telecom R&D
Document: draft-boucadair-pcp-interas-00.txt                October 2004
Category: Standards Track


                  Inter-AS PCE Communication protocol
                   draft-boucadair-pcp-interas-00.txt


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667 [RFC3667].  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 become aware will be disclosed, in
   accordance with
   RFC 3668 [RFC3668].

   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
   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 on April 2005.


Abstract

   This draft describes a new protocol allowing communication between
   two Path Computation Elements (PCEs) located in different domains in
   order  to  compute  inter-domain  paths  satisfying  a  set  of  QoS
   constraints. This protocol could also be used for intra-domain
   purposes.




Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 1]


Internet Draft         PCE Communication protocol           October 2004


Table of Contents


   1.      Contributors................................................2
   2.      Terminology.................................................2
   3.      Introduction................................................3
   4.      Conventions used in this document...........................4
   5.      Overview of overall service approach........................4
   6.      PCE to PCE communication....................................5
   7.      PCP messages................................................6
   7.1.    Common header...............................................6
   7.2.    OPEN message................................................7
   7.3.    ACCEPT message..............................................7
   7.4.    CLOSE message...............................................7
   7.5.    REQUEST message.............................................8
   7.6.    RESPONSE-PATH message......................................11
   7.7.    PATH-ERROR message.........................................12
   7.8.    CANCEL message.............................................13
   7.9.    ACKNOWLEDGE message........................................14
   7.10.  KEEPALIVE message (KA)......................................14
   8.      Exchange of PCP messages...................................14
   8.1.    Communication..............................................14
   8.2.    OPEN (OPN).................................................14
   8.3.    ACCEPT (ACP)...............................................15
   8.4.    CLOSE (CLO)................................................15
   8.5.    REQUEST (REQ)..............................................15
   8.6.    RESPONSE (RSP).............................................18
   8.7.    ACKNOWLEDGE (ACK)..........................................18
   8.8.    CANCEL (CCL)...............................................19
   9.      State diagram..............................................19
   10.     Security Considerations....................................19
   11.     References.................................................20
   12.     Acknowledgments............................................20
   13.     Author's Addresses.........................................21

1. Contributors

   o Hamid Asgari (Thales Research and Technology)
   o Panagiotis Georgatsos (Algonet)
   o David Griffin (University College London)
   o Micheal Howarth (University of Surrey)


2. Terminology

   This memo makes use of the following terms:

     o Path Computation Element (PCE): an entity that is responsible
        for computing/finding inter/intra domain LSPs. This entity can
        simultaneously act as client and a server. Several PCEs can be
        deployed in a given AS.

Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 2]


Internet Draft         PCE Communication protocol           October 2004



     o Path Computation Client (PCC): a PCE acting as a client. This
        entity is responsible for issuing path computation requests that
        fulfill the Service Management constraints for the establishment
        of inter/intra domain LSPs.

     o Path Computation Server (PCS): a PCE acting as a server. This
        entity is responsible for handling path computation requests
        including neighboring PCC constraints.

     o High-level service: is the service using a PCE-based system as
        an underlying infrastructure (an inter-domain QoS VPNs service
        for instance)

     o High-level service customer: is a customer that subscribes to a
        High-level service.

     o pSLS: A provider SLS is an SLS established between two Internet
        Network Providers (INP) with the purpose of extending the
        geographical span of their service offers.

     o SLS Management: this includes service ordering (i.e establishing
        contracts  between  peers)  and  invocation  (i.e  committing
        resources before traffic can be admitted)

     o Q-BGP: QoS-inferred BGP. A modified BGP protocol that takes into
        account QoS information as input to for its route selection
        process.

     o Domain: within this draft it denotes an Autonomous system.


3. Introduction

   Nowadays, services are deployed on a same basic infrastructure (best-
   effort shared IP network) on which more elaborate functionalities
   (MPLS for instance) rely for providing enhanced network services.
   Especially  those  intended  for  specific  corporate  customers  or
   providers needs. These extra functionalities were introduced because
   the basic IP approach failed to support those added-value services or
   was not considered to be efficient enough.

   MPLS is a technical solution that has been successfully deployed by a
   large number of providers for supporting connection-oriented services
   such as IP VPN services for which traffic isolation is an important
   criterion. Then, the solution evolved to encompass QoS issues, and
   Traffic engineering functions were then progressively introduced. Up
   to now, some providers have deployed MPLS TE but only within their
   own domains.



Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 3]


Internet Draft         PCE Communication protocol           October 2004


   Extending the scope of offered intra-domain services (like QoS-based
   services), using MPLS as infrastructure, to the Internet scale is
   conditioned by the cooperation between service providers. Several
   proposals have been proposed within the IETF in order to deal with
   this issue but only from inter-AS point of view (see for example
   [INTERAREA-REQ], [INTERAS-REQ], [PCE-ARCH] and [PCE-FWK]).

   Inter-provider issues need to be studied further in order to build a
   complete end-to-end solution.

   Draft [INTERAS-PCE] describes a solution that could be implemented in
   order to offer end-to-end services. This solution requires a close
   cooperation between distinct Path Computation Elements (PCE) that are
   located in distinct domains.

   This draft describes a protocol to use for communication between two
   Path computation Elements.

   The structure of this draft is as follows:
     o Section 5 presents an overview of the overall service approach;.
     o Section 6 lists characteristics of the PCP protocol;.
     o Sections 7 and 8 detail the PCP messages and operations.


4. 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 [RFC2119].


5. Overview of overall service approach

   Neighboring domains establish pSLSs between themselves. An inter-
   domain routing protocol runs between the domains. This inter-domain
   routing protocol is used to announce PCE unique identifiers [PCE-
   DISCOVERY] across the Internet in order for other PCEs to be able to
   discover possible paths towards every AS having a PCE. Therefore,
   when an AS wants to establish an LSP between 2 addresses, its PCE
   forms a path computation request containing the HEAD-END-ADDRESS and
   the TAIL-END-ADDRESS defining the future LSP. In addition to the IP
   address of the head and the tail of the LSP, each X-END-ADRESS
   contains also the PCE unique identifier of the AS these IP addresses
   belong to. Using information reported by BGP the PCE identifies
   possible paths that reach the target AS identified by its PCE unique
   identifier. It then selects one of these paths and forms a new
   request, which is sent to the neighboring PCE it selected along that
   path.

   The  path  computation  request  is  propagated  downstream  to  the
   appropriate PCEs and is repeated until the request reaches the

Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 4]


Internet Draft         PCE Communication protocol           October 2004


   destination PCE. Each PCE along the path ensures that the constraints
   expressed by the request are satisfied. Each PCE is responsible for
   computing both the intra- and inter-domain sub-path and to ensure
   that resources are available and will remain available until the LSP
   is effectively created. If for some reasons the path computation
   aborts, all resources must be relaxed.

   After authenticating the identity of LSP requester (originating) PCE,
   the destination PCE sends a reply message back to the downstream
   domain's PCE accepting the request. The LSP sub-path (from the
   ingress ASBR and the final destination) is inserted in the message.
   The next downstream domain's PCE does the same adding its own
   relevant sub-path to the overall loose or strict path. At the end of
   the chain, the originating PCE does also the same. An end-to-end path
   has thus been computed. The originating PCE is now in a position to
   provide the service request handler with appropriate information
   (end-to-end inter-domain path) allowing an RSVP reservation to be
   issued for the establishment of the LSP.

   At the service/application level, when an originating AS wants to
   establish an LSP towards a destination ASs, there MUST exist a
   preliminary agreement between the two ASs (Service providers owning
   these PCEs). This agreement specifies both the tail-end and head-end
   address of the LSP, together with the PCE unique identifier of the
   originating and destination AS. This allows only agreed LSP to be
   established.


6. PCE to PCE communication

   A PCE can act as a client (PCC) or a server (PCS). A PCC is
   responsible for issuing requests. PCS is responsible for handling
   requests received from PCCs.

            +------------+                       +------------+
            |    PCE     |                       |    PCE     |
            |            |                       |            |
            |  +------+  |                       |  +------+  |
            |  | PCC  |  |                       |  | PCC  |  |
            |  |      |<-|-------\               |  |      |  |
            |  +--/\--+  |       |               |  +--/\--+  |
            |     ||     |       |PCP            |     ||     |
            |     ||     |       |               |     ||     |
            |  +--\/--+  |       |               |  +--\/--+  |
            |  | PCS  |  |       \---------------|->| PCS  |  |
            |  |      |  |                       |  |      |  |
            |  +------+  |                       |  +------+  |
            +------------+                       +------------+

   PCP protocol is used for communication between a PCC and a PCS.


Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 5]


Internet Draft         PCE Communication protocol           October 2004


   PCP is a simple query and response protocol that can be used between
   PCE  entities  to  collaborate  for  computing  an  inter-domain  QoS
   constrained path.

   The main characteristics of the PCP protocol include:

     o The protocol employs a client/server model in which a PCE can
        both act as a client and/or a server at the same time. A PCE
        Client  (PCC)  sends  requests,  cancellation  and  receives
        responses.

     o The protocol uses TCP as its transport protocol for reliable
        exchange of messages between PCE. Therefore, no additional
        mechanisms are necessary for reliable communication between two
        PCE.

     o In this first version, PCP does not provide any encryption
        mechanism, replay protection, and message integrity. But PCP can
        reuse existing protocols for security such as IPSEC [RFC2401] or
        TLS [RFC2246] to authenticate and secure the channel between two
        PCE.

     o The PCP protocol described below supports only a basic path
        computation service. In particular it doesn't support additional
        path computation constraints, nor enhanced reporting features in
        case of path computation failure.

7. PCP messages

   This section discusses the PCP message formats and objects exchanged
   between PCE entities.

7.1. Common header

   Each PCP message consists of the PCP header followed by a number of
   arguments depending on the nature of the operation.

               0              1              2              3
        +--------------+--------------+--------------+--------------+
        |   Version    |    Op Code   |       Message Length        |
        +--------------+--------------+--------------+--------------+

   Global note: //// implies field is reserved, set to 0.

   The fields in the header are:

   Version: 8 bits. PCP version number. Current version is 1.

   Op Code: 8 bits. The PCP operations are:

                1 = OPEN                (OPN)

Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 6]


Internet Draft         PCE Communication protocol           October 2004


                2 = ACCEPT              (ACP)
                3 = CLOSE               (CLO)
                4 = REQUEST             (REQ)
                5 = RESPONSE            (RSP)
                6 = PATH-ERROR          (ERR)
                7 = CANCEL              (CCL)
                8 = ACKNOWLEDGE         (ACK)
                9 = KEEP-ALIVE          (KA)

   Message Length: 16 bits

   This is the size of the message in octets, which includes the
   standard PCP header and all encapsulated objects. Messages MUST be
   aligned on 4 octet intervals.

7.2. OPEN message

              0             1              2             3
          +-------------+-------------+-------------+-------------+
          |                                                       |
          |                         PCSID                         |
          |                                                       |
          |                                                       |
          +-------------+-------------+-------------+-------------+

   The message contains only one argument. This PCSID is propagated by
   BGP between the domains. This is a routable IPv4 or IPv6 address
   identifying a PCS of a domain. This PCSID must be inserted by the PCE
   opening a PCP session. The size of the PCSID is 4 or 16 bytes.

7.3. ACCEPT message

                 0             1              2             3
          +-------------+-------------+-------------+-------------+
          |         KA-Timer          |///////////////////////////|
          +-------------+-------------+-------------+-------------+

     o KA-Timer (Keep-Alive Timer): The argument of the accept message
        is a 2 octets integer value which represents a timer value
        expressed in units of seconds.  This timer value is treated as a
        delta. KA-Timer is used to specify the maximum time interval
        over which a PCP message MUST be sent by the two communication
        entities. The range of finite timeouts is 1 to 65535 seconds
        represented as an unsigned two-octet integer. The value of zero
        implies infinity.

7.4. CLOSE message

   The close message contains an error code indicating the reason of the
   close of the session.


Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 7]


Internet Draft         PCE Communication protocol           October 2004


                  0             1              2             3
          +--------------+--------------+--------------+--------------+
          |          Error-Code         | ////////////////////////////|
          +--------------+--------------+--------------+--------------+

   Error-Code:
        1 = Shutting Down
        2 = Bad Message Format
        3 = Incorrect identifier
        4 = Unable to process
        5 = Protocol error

7.5. REQUEST message

   The Request message is sent by the PCC for computing and inter-domain
   path.

          +-------------+
   1 byte |    TTL      |
          +-------------+
   1 byte |     L0      |
          +-------------+-------------+-------------+-------------+
   2 bytes|                       AS-NUMBER                       |
          +-------------+-------------+-------------+-------------+
          //                                                      //
          +-------------+-------------+-------------+-------------+
   2 bytes|                       AS-NUMBER                       |
          +-------------+-------------+-------------+-------------+
   2 bytes|            L1             |
          +-------------+-------------+-------//----+-------------+
          |                  PATH-COMPUTATION-ID                  |
          |-----------------------------------//------------------|
   2 bytes|            L2             |
          +-------------+-------------+-------//----+-------------+
          |                  PATH-REFERENCE-ID                    |
          +-------------+-------------+-------//----+-------------+
   2 bytes|                  REQ-REFERENCE-ID                     |
          +-------------+-------------+-------------+-------------+
   1 byte |   ADD-TYPE  |
          +-------------+-------------+-------//----+-------------+
          |                  HEAD-END-ADDRESS                     |
          +-------------+-------------+-------//----+-------------+
          |                  TAIL-END-ADDRESS                     |
          +-------------+-------------+-------//----+-------------+
   1 byte |  NUMBER-OF-QC-CONSTRAINT  +
          +-------------+-------------+
   2 bytes|   QC-CONSTRAINT-LENGTH    +
          +-------------+-------------+
   1 byte |   QOS-CLASS-IDENTIFIER    +
          +-------------+-------------+---------------------------+
   1 byte |   QOS-INFO-CODE           +   QOS-INFO-SUB-CODE       |

Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 8]


Internet Draft         PCE Communication protocol           October 2004


          +-------------+-------------+-------------+-------------+
   2 bytes|                  QOS-INFO-VALUE                       |
          +-------------+-------------+-------------+-------------+
          |   QOS-INFO-CODE           +   QOS-INFO-SUB-CODE       |
          +-------------+-------------+-------------+-------------+
          |                  QOS-INFO-VALUE                       |
          +-------------+-------------+-------------+-------------+
          |   QOS-INFO-CODE           +   QOS-INFO-SUB-CODE       |
          +-------------+-------------+-------------+-------------+
          |                  QOS-INFO-VALUE                       |
          +-------------+-------------+-------------+-------------+

     o TTL: is the maximum number of ASs that can be crossed by the
        path. This field is decremented by one each time a PCS issues a
        request.

     o L0: is a 1-byte length field. It represents the number of ASs
        that have already been crossed.

     o AS-NUMBER: is a 2 bytes length field representing an AS number.
        The first AS-NUMBER value of the list is the AS-NUMBER of the
        PCC that initialized a path computation.

     o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of
        this field is 2 bytes.

     o PATH-COMPUTATION-ID: is a globally unique value that identifies
        a path computation occurrence. It is a variable-length field. It
        is suggested, at least in this first specification, that this
        identifier  is  computed  using  the  PCSID  of  the  domain,
        concatenated with the date and an identifier that will be
        computed by the first requesting PCC each time a request will
        have to be issued. Across PCC reboots, this identifier must be
        unique. This PATH-COMPUTATION-ID will be replicated in all
        subsequent request initiated by the PCEs along the path.

     o L2: is the length in bytes of the PATH-REFERENCE-ID. Size of
        this field is 2 bytes.

     o PATH-REFERENCE-ID:  is  a  variable-length  field.  It  is  an
        identifier that represents a pre-agreement between the head and
        the tail-end domain that allows the PCS from the terminating
        domain to accept or reject the path computation request.

     o REQ-REFERENCE-ID: is a 2 bytes length field representing an
        unsigned integer. This field is used to identify the REQUEST. It
        allows making the difference between several REQ issued for
        different  path  computation  (but  same  PATH-COMPUTATION-ID)
        between two neighbor ASs interconnected via multiple links.



Boucadair (Ed.)   Standards Track - Expires April 2005          [Page 9]


Internet Draft         PCE Communication protocol           October 2004


     o ADD-TYPE: indicates the nature of the IP addresses of the tail-
        end and head-end termination:
          o 1 = IPv4
          o 2 = IPv6

      o HEAD-END-ADDRESS: is the head-end address of the future LSP
        represented in the form HEAD-END@PCSID. This is a couple of
        IPv4  or  IPv6  address.  The  first  address  of  the  couple
        identifies a loopback or an interface address of a network
        element, the second element is the PCSID of the domain owning
        the previous address.

      o TAIL-END-ADDRESS:  is  the  tail-end  address  of  the  LSP
        represented in the form TAIL-END@PCSID. This is a couple of
        IPv4  or  IPv6  address.  The  first  address  of  the  couple
        identifies a loopback or an interface address of a network
        element, the second element is the PCSID of the domain owning
        the previous address.

   These above parameters MUST be present in each REQUEST and in the
   same order.

     o NUMBER-OF-QC-CONSTRAINT: represents the number of QoS class
        constraints the PCS must take into account when computing a
        path. A QoS class constraint contains a QoS-Class-Identifier
        (like a DSCP value) followed by additional constraints. The size
        of this filed is 1 byte. This field in not really necessary in
        this first version of the specification but it could become
        useful if additional path constraints were included in the
        request.

     o QC-CONSTRAINT-LENGTH: is the number in byte of the QoS-Class-
        Constraint that follows. The size of this field is 2 bytes.

     o QOS-CLASS-IDENTIFIER: identifies a particular QoS-class. The
        size of the field is 1 byte.

     o QOS-INFO-CODE: this field identifies the type of QoS
        information. The size of this field is 4 bits. This code could
        be:
          o (0) Reserved
          o (1) Packet rate
          o (2) One-way delay metric
          o (3) Inter-packet delay variation

     o QOS-INFO-SUB-CODE: this field carries the sub-type of the QoS
        information. The following sub-types have been identified. The
        size of this field is 4 bits.
          o (0) None
          o (1) Reserved rate
          o (2) Available rate

Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 10]


Internet Draft         PCE Communication protocol           October 2004


          o (3) Loss rate
          o (4) Minimum one-way delay
          o (5) Maximum one-way delay
          o (6) Average one-way delay

     o QOS-INFO-VALUE: this field indicates the value of the QoS
        information. These are the constraints that the PCE should
        respect. The corresponding units depend on the instantiation of
        the QoS information code.

7.6. RESPONSE-PATH message

   This message is sent back when a path has been successfully computed.

          +-------------+-------------+
   2 bytes|            L1             |
          +-------------+-------------+-------//----+-------------+
          |                  PATH-COMPUTATION-ID                  |
          |-----------------------------------//------------------|
   2 bytes|                    REQ-REFERENCE-ID                   |
          |-----------------------------------//------------------|
   1 bytes| PATH-LENGTH |
          +-------------+
   1 byte |   ADD-TYPE  |
          +-------------+-------------+-------//----+-------------+
          |                       NEXT-HOP                        |
          +-------------+-------------+-------//----+-------------+
          //                                                     //
          +-------------+-------------+-------//----+-------------+
          |                       NEXT-HOP                        |
          +-------------+-------------+-------//----+-------------+
   8 bytes|       VALIDITY-DATE       +
          +-------------+-------------+
   1 byte |  NUMBER-OF-QC-CONSTRAINT  +
          +-------------+-------------+
   2 bytes|   QC-CONSTRAINT-LENGTH    +
          +-------------+-------------+
   1 byte |   QOS-CLASS-IDENTIFIER    +
          +-------------+-------------+---------------------------+
   1 byte |   QOS-INFO-CODE           +   QOS-INFO-SUB-CODE       |
          +-------------+-------------+-------------+-------------+
   2 bytes|                  QOS-INFO-VALUE                       |
          +-------------+-------------+-------------+-------------+
          |   QOS-INFO-CODE           +   QOS-INFO-SUB-CODE       |
          +-------------+-------------+-------------+-------------+
          |                  QOS-INFO-VALUE                       |
          +-------------+-------------+-------------+-------------+
          |   QOS-INFO-CODE           +   QOS-INFO-SUB-CODE       |
          +-------------+-------------+-------------+-------------+
          |                  QOS-INFO-VALUE                       |
          +-------------+-------------+-------------+-------------+

Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 11]


Internet Draft         PCE Communication protocol           October 2004



     o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of
        this field is 2 bytes.

     o PATH-COMPUTATION-ID: is a globally unique value that identifies
        a path computation occurrence. It is a variable-length field.
        This value of this identifier MUST be the same as the one
        provided by the REQUEST.

     o REQ-REFERENCE-ID: is a 2 bytes length field representing an
        unsigned integer. This field is used to reference the initial
        REQUEST.

     o PATH-LENGTH: indicates the number of next hops that form the
        path. The size of this filed is 1 byte.

     o ADD-TYPE: indicates the nature of the IP addresses in the PATH.
        The size of this filed is 1 byte.
          o 1 = IPv4
          o 2 = IPv6

     o NEXT-HOP: IP address of a next hop that is part of the computed
        path. Size of this field depends on the nature of the IP
        address.

     o VALIDITY-DATE: represents the GMT date after which the computed
        path returned will not be valid. The size of this field is 8
        bytes.

   These above parameters MUST be present in each RESPONSE and in the
   same order.

   The other parameters have the same meaning than for the REQUEST
   except:

     o QOS-INFO-VALUE: represents the QoS guarantees of the path, for
        this  particular  QoS-INFO-CODE  parameter  (delay,  jitter,à)
        between the ingress ASBR of the responding PCS domain and the
        tail-end of the path.

7.7. PATH-ERROR message

   This message is sent back when a path could not be computed.

          +-------------+-------------+
   2 bytes|            L1             |
          +-------------+-------------+-------//----+-------------+
          |                  PATH-COMPUTATION-ID                  |
          |-----------------------------------//------------------|
   2 bytes|                    REQ-REFERENCE-ID                   |
          |-----------------------------------//------------------|

Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 12]


Internet Draft         PCE Communication protocol           October 2004


   1 bytes|        REASON-CODE        |
          +-------------+-------------+

     o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of
        this field is 2 bytes.

     o PATH-COMPUTATION-ID: is a globally unique value that identifies
        a path computation occurrence. It is a variable-length field.
        This identifier MUST be the same as the one provided by the
        REQUEST.

     o REQ-REFERENCE-ID: is a 2 bytes length field representing an
        unsigned integer. This field is used to reference the initial
        REQUEST.

     o REASON-CODE: indicate the reason of the failure. Identified
        failure are:

        1 = No resource available
        2 = Path reference error
        3 = Abnormal termination
        4 = PATH-COMPUTATION-ID already used
        5 = TTL expired
        6 = Loop detected
        7 = Request already handled

7.8. CANCEL message

   This message is sent by a PCC or a PCS when a path computation must
   be cancelled.

          +-------------+-------------+
   2 bytes|            L1             |
          +-------------+-------------+-------//----+-------------+
          |                  PATH-COMPUTATION-ID                  |
          |-----------------------------------//------------------|
   2 bytes|                    REQ-REFERENCE-ID                   |
          |-------------------------------------------------------|

     o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of
        this field is 2 bytes.

     o PATH-COMPUTATION-ID: is a globally unique value that identifies
        a path computation occurrence. It is a variable-length field.
        This identifier MUST be the same as the one provided by the
        REQUEST.

     o REQ-REFERENCE-ID: is a 2 bytes length field representing an
        unsigned integer. This field is used to reference the initial
        REQUEST.


Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 13]


Internet Draft         PCE Communication protocol           October 2004


7.9. ACKNOWLEDGE message

   This message is sent by a PCC to a PCS to confirm the reservation of
   the path. This feature is particularly used when a PCC launches
   multiple REQUESTs during its path computation phase.

          +-------------+-------------+
   2 bytes|            L1             |
          +-------------+-------------+-------//----+-------------+
          |                  PATH-COMPUTATION-ID                  |
          |-----------------------------------//------------------|
   2 bytes|                    REQ-REFERENCE-ID                   |
          |-------------------------------------------------------|

     o L1: is the length in bytes of the PATH-COMPUTATION-ID. Size of
        this field is 2 bytes.

     o PATH-COMPUTATION-ID: is globally unique value that identifies a
        path computation occurrence. It is a variable-length field. This
        identifier MUST be the same as the one provided by the REQUEST.

     o REQ-REFERENCE-ID: is a 2 bytes length field representing an
        unsigned integer. This field is used to reference the initial
        REQUEST.

7.10. KEEPALIVE message (KA)

   Message exchanged between two PCEs to maintain TCP session when no
   other messages are exchanged.

   This message has no argument.

8. Exchange of PCP messages

8.1. Communication

   The PCP protocol uses a single persistent TCP connection between a
   PCC and a remote PCS. One PCE server implementation per server MUST
   listen on a well-known TCP port number (to be defined). The PCC is
   responsible for initiating the TCP connection to the PCS. The
   location of the remote PCS is deduced and retrieved from the
   management plane blocks during the path computation process or at PCS
   boot  via  the  SLS  management  block.  PCE  can  have  crossed
   communication; some are acting as a client role, others as a server
   role.

8.2. OPEN (OPN)

   An OPN message MUST be sent before any other message exchange. As
   part of the open message, the PCC provide its PCSID, which allows the
   server to identify the client. It can also use this information to

Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 14]


Internet Draft         PCE Communication protocol           October 2004


   retrieve the client context near its management plane. Only one OPN
   message can be issued at a time.

   If the PCS receives malformed message it MUST close the session using
   the appropriate error code.

8.3. ACCEPT (ACP)

   The ACP message is used to positively respond to the OPN message from
   the PCC. This message will return to the PCC a timer value object
   indicating the maximum time interval between keep-alive messages.
   If the PCS refuses the PCC open message, it will instead issue a
   CLOSE message.

   The KA-Timer corresponds to maximum acceptable intermediate time
   between the generation of messages by the PCEs. The timer value is
   determined by the PCS and is specified in seconds.

8.4. CLOSE (CLO)

   The CLOSE message can be issued by either the PCC or the PCS to
   notify the other that it is no longer available.

   The Error code is included to describe the reason for the close.

   When issuing a CLOSE both the PCC and the PCS MUST delete all the
   internal states related to this PCP session. Additionally, all
   pending requests MUST be explicitly cancelled using a CCL message in
   order to free as much as possible all pending resources reservations
   and/or pre-contracts that could have been established.

8.5. REQUEST (REQ)

   A request is issued by a PCC when it has found a potential path
   toward the target final destination. This request can be issued as a
   consequence  of  a  request  received  from  another  domain  it  has
   agreement with or from its own service management plane.

   When the service request comes from a remote PCC, the server achieves
   the following tasks:

   (0)  If the receiving TTL is zero the PCS MUST discard the request.
        The receiving PCS, decrements by one the received TTL value. If
        the TTL is equal to zero, the request is rejected if the PCS is
        not the last PCS in the chain. In addition the PCS examines the
        AS-PATH included in the received REQ and reject it if it finds
        its own AS number in the list. This mechanism allows avoiding
        possible loops when a limited set of QoS constraints are
        provided in the request.



Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 15]


Internet Draft         PCE Communication protocol           October 2004


   (1)  It checks if the PATH-COMPUTATION-ID of the received REQ is
        already associated to a pre-contract or contract. If this is the
        case, it returns a PATH-ERROR message with a reason-code = 4. It
        checks if the PATH-COMPUTATION-ID and the REQ-REFERENCE-ID of
        the received REQ are already associated to a pre-reservation
        record. If a pre-reservation is found, it returns a PATH-ERROR
        message with a reason-code = 4.

   (2)  It  considers  the  HEAD-END-ADDRESS  and  the  TAIL-END-ADDRESS
        parameters present in the request. The HEAD-END-ADDRESS MUST
        indicate a valid entry point in its domain. If not, the PCS
        returns a PATH-ERROR with an appropriate reason value.

   (3)  Then it extracts the PCSID from the TAIL-END-ADDRESS and parses
        the QoS constraints provided at part of the request message. It
        has thus identified all QoS-class required together with their
        associated QoS constraints.

   (4)  The PCS achieves some policing and verifies that the request
        constraints will not exceed the resources negotiated in the
        pSLS. If resources are exceeded, the PCS returns a PATH-ERROR
        message.

   (5)  If the PCS recognizes its own PCSID in the TAIL-END-ADDRESS, it
        considers the PATH-REFERENCE-ID otherwise it jumps to step (6).
        If this identifier is known from its management plane, the
        request is accepted and processing continues on (51). Otherwise
        the PCS returns a PATH-ERROR message with a reason-code = 2.

        (51) The PCS computes an intra-domain path and verifies the
        availability of the resources along this internal path. If
        available, the PCS interacts with its management plane and
        create a contract, which triggers the administrative reservation
        of the resources. When interacting with the management blocks,
        the PCS MUST provide all information necessary to identify the
        sub-path it selected. In particular it MUST provide the PATH-
        COMPUTATION-ID, the ingress point ASBR address used in its
        domain and the termination point in its domain. The PCS sends a
        RESPONSE-PATH message back to the requesting PCC. If resources
        are not available a PATH-ERROR message is generated.

   (6)  It then queries the dynamic inter-domain traffic-engineering
        block with the retrieved PCSID and the list of requested QoS-
        classes. The dynamic inter-domain TE block returns the available
        BGP announcements. The PCS then verifies whether it can find a
        next-hop ASBR, which announces the PCSID within the requested
        QoS-class. If cannot find it the procedure stops and a PATH-
        ERROR message is returned back to the requesting entity with an
        appropriate reason-code value.



Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 16]


Internet Draft         PCE Communication protocol           October 2004


   (7)  If one or several next-hops are found, the PCS examines the QoS
        performance guarantees of the announcements and compare the
        values with those requested in the request. If it doesn't
        understand one of the requested QoS constraints, PATH-ERROR
        message  is  sent  back.  Otherwise,  QoS  constraints  are
        successively compared to those received from q-BGP. All next-
        hops  propagating  the  set  of  announcements  satisfying  the
        required QoS constraints are kept. The others are left on side.


   (8)  For each possible next hop ASBR the PCS checks is there are
        enough available resources available at the domain boundaries.
        In particular if some bandwidth guarantees are required the PCS
        checks if the administrative maximum bandwidth agreed during the
        pSLS negotiation phase will not be exceeded. If resources are
        not available the ASBR is left on side and the next ASBR in the
        list                       is                       considered.
        If  resources  are  available,  the  PCS  pre-reserves  the
        corresponding resources near the management plane. At this
        stage, the management plane doesn't create any contract since we
        are  not  sure  that  an  end-to-end  path  exists.  This  pre-
        reservation can be taken into account by the PCS for subsequent
        requests. It can use it as a lock and delay the incoming
        requests or introduce the pre-reservations in its resource
        availability computation according to the local policy enforced.
        When interacting with the management blocks, the PCS must
        provide all information necessary to identify the sub-path it
        selected. In particular it must provide the PATH-COMPUTATION-ID,
        the ingress point address of its domain and the ingress point
        address of the next domain. This latter information can be used
        by the management plane to identify the upstream and downstream
        involved domains.

        o (81) The PCS computes an intra-domain path and verifies the
          availability of the resources along this internal path. If
          resources are available, the sub-path is valid and the PCE
          forms a new REQUEST message which is sent to the PCS of the
          remote domain owning the next-hop ASBR. It adds its own AS
          number to the existing list. If internal resources are not
          available, the PCS discard the pre-reservation and considers
          the next hop ASBR in the list. When building the request the
          PCC keeps the PATH-COMPUTATION-ID, the PATH-REFERENCE-ID, the
          TAIL-END-ADDRESS unchanged. The initial HEAD-END-ADDRESS is
          replaced  by  the  address  of  the  ingress  next-hop  ASBR
          identified during the path computation. The QoS constraints
          characteristics are modified in order to take into account
          the QoS performance guarantees provided by the domain.

   (9)  If QoS constraints cannot be satisfied for any of the ASBR, the
        PCS returns a PATH-ERROR message.


Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 17]


Internet Draft         PCE Communication protocol           October 2004


   Note that it is quite possible that several next hops ASBR can
   satisfy the requested constraints. In such a case the PCS can process
   one next-hop ASBR at a time or several in parallel. For one incoming
   request, there can be multiple simultaneous outgoing requests towards
   different PCS. If several requests are sent toward the same neighbor,
   for  a  same  PATH-COMPUTATION-ID,  the  REQ-REFERENCE-ID  must  be
   different. Nevertheless, this feature can lead to scalability issues
   and needs further investigations.

8.6. RESPONSE (RSP)

   A RESPONSE message is sent by a PCS in response to a request issued
   by a PCC. RSP messages are sent back when a valid end-to-end path has
   been computed. The RSP message MUST initiated by the tail-end domain.

   When a valid end-to-end path has been computed, the PCS of the last
   domain on the path, forms a RSP message. It first inserts the
   original PATH-COMPUTATION-ID. Then its forms a path argument that
   MUST contains the IP address of the tail-end LSP and the IP address
   interface of the ingress ASBR supporting that path. It MAY insert
   between these two extremities, the IP address of additional hops. It
   MAY also indicates the date after which the path will not be valid
   anymore because administratively reserved resources will have been
   relaxed. Then, it MUST indicate QoS guarantees it provides between
   the ingress ASBR and the tail-end address of the LSP. The RSP message
   is then sent to the requesting PCC.

   On receipt, the PCC adds its own intra-domain sub-path to the list.
   It does not indicate the next-hop ASBR since this latter has already
   been inserted by the downstream PCS. This sub-path can be a strict or
   loose description. It also modifies the QoS guarantee parameters so
   that they reflect the QoS guarantees it can provide for its part of
   the path. This is achieved in the same way than for the request, but
   it is an "addition" operation if we consider the delay, for example.
   The VALIDITY-DATE MUST modified so that the value indicates now the
   smaller date between the date received in the RSP message and the
   date reported by the management plane.

   If the PCC sent multiple REQUEST messages in parallel, it MAY wait
   for a RSP or ERR message for all the requests it sent. If the PCC got
   multiple RSP messages it MUST select only one and inform the un-
   selected PCS that they can cancel their reservation. It forms CANCEL
   messages, sends them to the appropriate PCS and cancels its own pre-
   reservation for the corresponding requests. If the PCC doesn't whish
   to wait for a reply, it can send a CANCEL message at any time.

   The PCS can send the consolidated RES message to the requesting PCC
   after sending ACK message to the PCS it decided to keep in the path.

8.7. ACKNOWLEDGE (ACK)


Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 18]


Internet Draft         PCE Communication protocol           October 2004


   The ACK message is used by PCS to confirm to its management plane
   that  the  resources  needed  for  the  path  referenced  by  PATH-
   COMPUTATION-ID present in the message need to be reserved. It allows
   the management plane to create a contract based on information
   previously stores by the PCS during the computation phase. If no ACK
   is received, no contract is created and the negotiation at the
   management level will fail. If for some reasons, no ACK were
   received, the VALIDITY-DATE would be used and the administrative pre-
   reservation automatically removed for that path. ACK messages are
   only accepted if they arrive after the server has issued a RSP
   otherwise they are ignored.

8.8. CANCEL (CCL)

   A CANCEL message can be sent by PCC and PCS. CCL messages can be
   generated during the normal path computation cycle but also in case
   of an abnormal termination of a PCE to PCE communication.

   If a PCE, acting as a server for the PCP session, received a CCL
   message from the PCC, it MUST form new CCL messages and forward a CCL
   message to each PCS to which it sent a REQ for which it did not
   received any positive or negative reply. Once this has been achieved
   it  MUST  delete  all  its  internal  states  referencing  the  PATH-
   COMPUTATION-ID indicated in the message. If the PCE has no pending
   request concerning this PATH-COMPUTATION-ID, it can optionally query
   its  management  plane  to  retrieve  a  possible  existing  contract
   referenced by this PATH-COMPUTATION-ID and delete it. Just before
   deleting this contract, it can form a new CCL message and forward it
   to the next PCS in the path. If it does not, the VALIDITY-DATE will
   be applied.

   The same procedure applies if the PCE server detects a communication
   problem with one of its PCC. In that case, the PCS issues CCL
   messages for all pending request received from this PCC.

   When a PCE, acting as a client for the PCP session, received a CCL
   message from a PCE server, this indicates that a PCS along the path
   towards the target destination has experienced communication problems
   leading to close a PCP communication. In such a case, each PCC
   cancels all the internal states referencing this PATH-COMPUTATION-ID
   and forward this indication to the upstream client PCS up to the
   initial requestor.

9. State diagram

   TBD.

10. Security Considerations

   PCP is a communication protocol that is used between two PCEs. No
   security mechanisms are defined in this PCP specification. It is

Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 19]


Internet Draft         PCE Communication protocol           October 2004


   recommended that a security protocol like IPSec or TLS MUST be
   activated in order to protect PCP sessions.


11. References

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

   [RFC3668] Bradner, S., "Intellectual Property Rights in IETF
      Technology", RFC 3668, February 2004

   [INTERAREA-REQ] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements
      for Support of Inter-Area and Inter-AS MPLS Traffic Engineering",
      draft-ietf-tewg- interarea-mpls-te-req-00.txt, March 2004 (work in
      progress)

   [INTERAS-REQ] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS
      Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-
      te-req-06.txt, January 2004 (work in progress).

   [PCE-ARCH] Ash, J., Farrel, A., Vasseur, JP., " Path Computation
      Element (PCE) Architecture", draft-ash-pce-architecture-00.txt,
      September 2004

   [PCE-FWK] Farrel, A., Vasseur, JP., Ayyangar, A., "A Framework for
      Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter-
      domain-framework-00.txt, August 2004

   [INTERAS-PCE] Boucadair, M., Morand, P., "A Solution for providing
      inter-AS QoS tunnels", draft-mescal-pce-interas-00.txt, October
      2004

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

   [PCE-DISCOVERY] Boucadair, M., Morand, P., "PCE Discovery via Border
      Gateway Protocol", draft-mescal-pce-discovery-00.txt, October 2004

   [RFC2401] Atkinson R., "Security Architecture for the Internet
      Protocol", RFC 2401, August 1998.

   [RFC2246] Dierks T., Allen C., " The TLS Protocol", RFC 2246, January
      1999


12. Acknowledgments

   The authors would also like to thank all the partners of the MESCAL
   (Management of End-to-End Quality of Service Across the Internet At
   Large, http://www.mescal.org) project for the fruitful discussions.

Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 20]


Internet Draft         PCE Communication protocol           October 2004




13. Author's Addresses

   Mohamed Boucadair
   France Telecom R & D
   42, rue des Coutures
   BP 6243
   14066 Caen Cedex 4
   France
   Phone: +33 2 31 75 92 31
   Email: mohamed.boucadair@francetelecom.com

   Pierrick Morand
   France Telecom R & D
   42, rue des Coutures
   BP 6243
   14066 Caen Cedex 4
   France
   Email: pierick.morand@francetelecom.com


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

Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 21]


Internet Draft         PCE Communication protocol           October 2004


   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 (2004).  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.








































Boucadair (Ed.)   Standards Track - Expires April 2005         [Page 22]