tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5440

 
 
 

Path Computation Element (PCE) Communication Protocol (PCEP)

Part 4 of 4, p. 59 to 87
Prev RFC Part

 


prevText      Top      Up      ToC       Page 59 
9.  IANA Considerations

   IANA assigns values to the PCEP protocol parameters (messages,
   objects, TLVs).

   IANA established a new top-level registry to contain all PCEP
   codepoints and sub-registries.

   The allocation policy for each new registry is by IETF Consensus: new
   values are assigned through the IETF consensus process (see
   [RFC5226]).  Specifically, new assignments are made via RFCs approved
   by the IESG.  Typically, the IESG will seek input on prospective
   assignments from appropriate persons (e.g., a relevant Working Group
   if one exists).

9.1.  TCP Port

   PCEP has been registered as TCP port 4189.

9.2.  PCEP Messages

   IANA created a registry for PCEP messages.  Each PCEP message has a
   message type value.


   Value     Meaning                          Reference
     1        Open                          This document
     2        Keepalive                     This document
     3        Path Computation Request      This document
     4        Path Computation Reply        This document
     5        Notification                  This document
     6        Error                         This document
     7        Close                         This document

9.3.  PCEP Object

   IANA created a registry for PCEP objects.  Each PCEP object has an
   Object-Class and an Object-Type.

   Object-Class Value   Name                               Reference

          1             OPEN                               This document
                        Object-Type
                            1

          2             RP                                 This document
                        Object-Type
                            1

Top      Up      ToC       Page 60 
          3             NO-PATH                            This document
                        Object-Type
                            1

          4             END-POINTS                         This document
                        Object-Type
                            1: IPv4 addresses
                            2: IPv6 addresses

          5             BANDWIDTH                          This document
                        Object-Type
                          1: Requested bandwidth
                          2: Bandwidth of an existing TE LSP
                             for which a reoptimization is performed.

          6             METRIC                             This document
                        Object-Type
                            1

          7             ERO                                This document
                        Object-Type
                            1

          8             RRO                                This document
                        Object-Type
                            1

          9             LSPA                               This document
                        Object-Type
                            1

         10             IRO                                This document
                        Object-Type
                            1

         11             SVEC                               This document
                        Object-Type
                            1

         12             NOTIFICATION                       This document
                        Object-Type
                            1

         13             PCEP-ERROR                         This document
                        Object-Type
                            1

Top      Up      ToC       Page 61 
         14             LOAD-BALANCING                     This document
                        Object-Type
                            1

         15             CLOSE                              This document
                        Object-Type
                            1

9.4.  PCEP Message Common Header

   IANA created a registry to manage the Flag field of the PCEP Message
   Common Header.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bits are currently defined for the PCEP message common header.

9.5.  Open Object Flag Field

   IANA created a registry to manage the Flag field of the OPEN object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bits are currently for the OPEN Object flag field.

9.6.  RP Object

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

Top      Up      ToC       Page 62 
   o  Defining RFC

   Several bits are defined for the RP Object flag field in this
   document.  The following values have been assigned:

   Codespace of the Flag field (RP Object)

     Bit      Description              Reference

      26      Strict/Loose          This document
      27      Bi-directional        This document
      28      Reoptimization        This document
     29-31    Priority              This document


9.7.  NO-PATH Object Flag Field

   IANA created a registry to manage the codespace of the NI field and
   the Flag field of the NO-PATH object.


    Value       Meaning                        Reference

      0    No path satisfying the set        This document
           of constraints could be found
      1    PCE chain broken                  This document

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   One bit is defined for the NO-PATH Object flag field in this
   document:

   Codespace of the Flag field (NO-PATH Object)

     Bit      Description                      Reference

      0    Unsatisfied constraint indicated    This document

Top      Up      ToC       Page 63 
9.8.  METRIC Object

   IANA created a registry to manage the codespace of the T field and
   the Flag field of the METRIC Object.

   Codespace of the T field (Metric Object)

    Value      Meaning          Reference

      1        IGP metric      This document
      2        TE metric       This document
      3        Hop Counts      This document

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   Several bits are defined in this document.  The following values have
   been assigned:

   Codespace of the Flag field (Metric Object)

     Bit      Description         Reference

      6       Computed metric    This document
      7       Bound              This document

9.9.  LSPA Object Flag Field

   IANA created a registry to manage the Flag field of the LSPA object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   One bit is defined for the LSPA Object flag field in this document:

Top      Up      ToC       Page 64 
   Codespace of the Flag field (LSPA Object)

     Bit      Description             Reference

      7    Local Protection Desired   This document


9.10.  SVEC Object Flag Field

   IANA created a registry to manage the Flag field of the SVEC object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   Three bits are defined for the SVEC Object flag field in this
   document:

   Codespace of the Flag field (SVEC Object)

     Bit      Description      Reference

      21      SRLG Diverse     This document
      22      Node Diverse     This document
      23      Link Diverse     This document

9.11.  NOTIFICATION Object

   IANA created a registry for the Notification-type and Notification-
   value of the NOTIFICATION object and manages the code space.

   Notification-type  Name                                 Reference
         1            Pending Request cancelled            This document
                      Notification-value
                        1: PCC cancels a set of pending requests
                        2: PCE cancels a set of pending requests

         2            Overloaded PCE                       This document
                      Notification-value
                        1: PCE in congested state
                        2: PCE no longer in congested state

Top      Up      ToC       Page 65 
   IANA created a registry to manage the Flag field of the NOTIFICATION
   object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bits are currently for the Flag Field of the NOTIFICATION object.

9.12.  PCEP-ERROR Object

   IANA created a registry for the Error-Type and Error-value of the
   PCEP Error Object and manages the code space.

Top      Up      ToC       Page 66 
   For each PCEP error, an Error-Type and an Error-value are defined.

Error-  Meaning                                           Reference
Type
  1     PCEP session establishment failure                This document
        Error-value=1: reception of an invalid Open message or
                       a non Open message.
        Error-value=2: no Open message received before the expiration
                       of the OpenWait timer
        Error-value=3: unacceptable and non-negotiable session
                       characteristics
        Error-value=4: unacceptable but negotiable session
                       characteristics
        Error-value=5: reception of a second Open message with
                       still unacceptable session characteristics
        Error-value=6: reception of a PCErr message proposing
                       unacceptable session characteristics
        Error-value=7: No Keepalive or PCErr message received
                       before the expiration of the KeepWait timer
        Error-value=8: PCEP version not supported
  2     Capability not supported                          This document
  3     Unknown Object                                    This document
         Error-value=1: Unrecognized object class
         Error-value=2: Unrecognized object Type
  4     Not supported object                              This document
         Error-value=1: Not supported object class
         Error-value=2: Not supported object Type
  5     Policy violation                                  This document
         Error-value=1: C bit of the METRIC object set
                        (request rejected)
         Error-value=2: O bit of the RP object cleared
                        (request rejected)
  6     Mandatory Object missing                          This document
         Error-value=1: RP object missing
         Error-value=2: RRO missing for a reoptimization
                        request (R bit of the RP object set)
         Error-value=3: END-POINTS object missing
  7     Synchronized path computation request missing     This document
  8     Unknown request reference                         This document
  9     Attempt to establish a second PCEP session        This document
 10     Reception of an invalid object                    This document
         Error-value=1: reception of an object with P flag
                        not set although the P flag must be
                        set according to this specification.

   IANA created a registry to manage the Flag field of the PCEP-ERROR
   object.

Top      Up      ToC       Page 67 
   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bits are currently for the Flag Field of the PCEP-ERROR Object.

9.13.  LOAD-BALANCING Object Flag Field

   IANA created a registry to manage the Flag field of the LOAD-
   BALANCING object.

   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bits are currently for the Flag Field of the LOAD-BALANCING
   Object.

9.14.  CLOSE Object

   The CLOSE object MUST be present in each Close message in order to
   close a PCEP session.  The reason field of the CLOSE object specifies
   the reason for closing the PCEP session.  The reason field of the
   CLOSE object is managed by IANA.

   Reasons

    Value        Meaning
      1          No explanation provided
      2          DeadTimer expired
      3          Reception of a malformed PCEP message
      4          Reception of an unacceptable number of unknown
                 requests/replies
      5          Reception of an unacceptable number of unrecognized
                 PCEP messages

   IANA created a registry to manage the flag field of the CLOSE object.

Top      Up      ToC       Page 68 
   New bit numbers may be allocated only by an IETF Consensus action.
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   No bits are currently for the Flag Field of the CLOSE Object.

9.15.  PCEP TLV Type Indicators

   IANA created a registry for the PCEP TLVs.

    Value         Meaning                    Reference

      1          NO-PATH-VECTOR TLV         This document
      2          OVERLOAD-DURATION TLV      This document
      3          REQ-MISSING TLV            This document

9.16.  NO-PATH-VECTOR TLV

   IANA manages the space of flags carried in the NO-PATH-VECTOR TLV
   defined in this document, numbering them from 0 as the least
   significant bit.

   New bit numbers may be allocated only by an IETF Consensus action.

   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Name flag

   o  Reference

   Bit Number       Name                         Reference
     31             PCE currently unavailable    This document
     30             Unknown destination          This document
     29             Unknown source               This document

Top      Up      ToC       Page 69 
10.  Security Considerations

10.1.  Vulnerability

   Attacks on PCEP may result in damage to active networks.  If path
   computation responses are changed, the PCC may be encouraged to set
   up inappropriate LSPs.  Such LSPs might deviate to parts of the
   network susceptible to snooping, or might transit congested or
   reserved links.  Path computation responses may be attacked by
   modification of the PCRep message, by impersonation of the PCE, or by
   modification of the PCReq to cause the PCE to perform a different
   computation from that which was originally requested.

   It is also possible to damage the operation of a PCE through a
   variety of denial-of-service attacks.  Such attacks can cause the PCE
   to become congested with the result that path computations are
   supplied too slowly to be of value for PCCs.  This could lead to
   slower-than-acceptable recovery times or delayed LSP establishment.
   In extreme cases, it may be that service requests are not satisfied.

   PCEP could be the target of the following attacks:

   o  Spoofing (PCC or PCE impersonation)

   o  Snooping (message interception)

   o  Falsification

   o  Denial of Service

   In inter-AS scenarios when PCE-to-PCE communication is required,
   attacks may be particularly significant with commercial as well as
   service-level implications.

   Additionally, snooping of PCEP requests and responses may give an
   attacker information about the operation of the network.  Simply by
   viewing the PCEP messages someone can determine the pattern of
   service establishment in the network and can know where traffic is
   being routed, thereby making the network susceptible to targeted
   attacks and the data within specific LSPs vulnerable.

   The following sections identify mechanisms to protect PCEP against
   security attacks.

Top      Up      ToC       Page 70 
10.2.  TCP Security Techniques

   At the time of writing, TCP-MD5 [RFC2385] is the only available
   security mechanism for securing the TCP connections that underly PCEP
   sessions.

   As explained in [RFC2385], the use of MD5 faces some limitations and
   does not provide as high a level of security as was once believed.  A
   PCEP implementation supporting TCP-MD5 SHOULD be designed so that
   stronger security keying techniques or algorithms that may be
   specified for TCP can be easily integrated in future releases.

   The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new
   security procedures for TCP, but is not yet complete.  Since it is
   believed that [TCP-AUTH] will offer significantly improved security
   for applications using TCP, implementers should expect to update
   their implementation as soon as the TCP Authentication Option is
   published as an RFC.

   Implementations MUST support TCP-MD5 and should make the security
   function available as a configuration option.

   Operators will need to observe that some deployed PCEP
   implementations may pre-date the completion of [TCP-AUTH], and it
   will be necessary to configure policy for secure communication
   between PCEP speakers that support the TCP Authentication Option, and
   those that don't.

   An alternative approach for security over TCP transport is to use the
   Transport Layer Security (TLS) protocol [RFC5246].  This provides
   protection against eavesdropping, tampering, and message forgery.
   But TLS doesn't protect the TCP connection itself, because it does
   not authenticate the TCP header.  Thus, it is vulnerable to attacks
   such as TCP reset attacks (something against which TCP-MD5 does
   protect).  The use of TLS would, however, require the specification
   of how PCEP initiates TLS handshaking and how it interprets the
   certificates exchanged in TLS.  That specification is out of the
   scope of this document, but could be the subject of future work.

10.3.  PCEP Authentication and Integrity

   Authentication and integrity checks allow the receiver of a PCEP
   message to know that the message genuinely comes from the node that
   purports to have sent it and to know whether the message has been
   modified.

Top      Up      ToC       Page 71 
   The TCP-MD5 mechanism [RFC2385] described in the previous section
   provides such a mechanism subject to the concerns listed in [RFC2385]
   and [RFC4278].  These issues will be addressed and resolved by
   [TCP-AUTH].

10.4.  PCEP Privacy

   Ensuring PCEP communication privacy is of key importance, especially
   in an inter-AS context, where PCEP communication end-points do not
   reside in the same AS, as an attacker that intercepts a PCE message
   could obtain sensitive information related to computed paths and
   resources.

   PCEP privacy can be ensured by encryption.  TCP MAY be run over IPsec
   [RFC4303] tunnels to provide the required encryption.  Note that
   IPsec can also ensure authentication and integrity; in which case,
   TCP-MD5 or TCP-AO would not be required.  However, there is some
   concern that IPsec on this scale would be hard to configure and
   operate.  Use of IPSec with PCEP is out of the scope of this document
   and may be addressed in a separate document.

10.5.  Key Configuration and Exchange

   Authentication, tamper protection, and encryption all require the use
   of keys by sender and receiver.

   Although key configuration per session is possible, it may be
   particularly onerous to operators (in the same way as for the Border
   Gateway Protocol (BGP) as discussed in [BGP-SEC]).  If there is a
   relatively small number of PCCs and PCEs in the network, manual key
   configuration MAY be considered a valid choice by the operator,
   although it is important to be aware of the vulnerabilities
   introduced by such mechanisms (i.e., configuration errors, social
   engineering, and carelessness could all give rise to security
   breaches).  Furthermore, manually configured keys are less likely to
   be regularly updated which also increases the security risk.  Where
   there is a large number of PCCs and PCEs, the operator could find
   that key configuration and maintenance is a significant burden as
   each PCC needs to be configured to the PCE.

   An alternative to individual keys is the use of a group key.  A group
   key is common knowledge among all members of a trust domain.  Thus,
   since the routers in an IGP area or an AS are part of a common trust
   domain [MPLS-SEC], a PCEP group key MAY be shared among all PCCs and
   PCEs in an IGP area or AS.  The use of a group key will considerably
   simplify the operator's configuration task while continuing to secure

Top      Up      ToC       Page 72 
   PCEP against attack from outside the network.  However, it must be
   noted that the more entities that have access to a key, the greater
   the risk of that key becoming public.

   With the use of a group key, separate keys would need to be
   configured for the PCE-to-PCE communications that cross trust domain
   (e.g., AS) boundaries, but the number of these relationships is
   likely to be very small.

   PCE discovery ([RFC5088] and [RFC5089]) is a significant feature for
   the successful deployment of PCEP in large networks.  This mechanism
   allows a PCC to discover the existence of suitable PCEs within the
   network without the necessity of configuration.  It should be obvious
   that, where PCEs are discovered and not configured, the PCC cannot
   know the correct key to use.  There are three possible approaches to
   this problem that retain some aspect of security:

   o  The PCCs may use a group key as previously discussed.

   o  The PCCs may use some form of secure key exchange protocol with
      the PCE (such as the Internet Key Exchange protocol v2 (IKE)
      [RFC4306]).  The drawback to this is that IKE implementations on
      routers are not common and this may be a barrier to the deployment
      of PCEP.  Details are out of the scope of this document and may be
      addressed in a separate document.

   o  The PCCs may make use of a key server to determine the key to use
      when talking to the PCE.  To some extent, this is just moving the
      problem, since the PCC's communications with the key server must
      also be secure (for example, using Kerberos [RFC4120]), but there
      may some (minor) benefit in scaling if the PCC is to learn about
      several PCEs and only needs to know one key server.  Note that key
      servers currently have very limited implementation.  Details are
      out of the scope of this document and may be addressed in a
      separate document.

   PCEP relationships are likely to be long-lived even if the PCEP
   sessions are repeatedly closed and re-established.  Where protocol
   relationships persist for a large number of protocol interactions or
   over a long period of time, changes in the keys used by the protocol
   peers is RECOMMENDED [RFC4107].  Note that TCP-MD5 does not allow the
   key to be changed without closing and reopening the TCP connection
   which would result in the PCEP session being terminated and needing
   to be restarted.  That might not be a significant issue for PCEP.
   Note also that the plans for the TCP Authentication Option [TCP-AUTH]
   will allow dynamic key change (roll-over) for an active TCP
   connection.

Top      Up      ToC       Page 73 
   If key exchange is used (for example, through IKE), then it is
   relatively simple to support dynamic key updates and apply these to
   PCEP.

   Note that in-band key management for the TCP Authentication Option
   [TCP-AUTH] is currently unresolved.

   [RFC3562] sets out some of the issues for the key management of
   secure TCP connections.

10.6.  Access Policy

   Unauthorized access to PCE function represents a variety of potential
   attacks.  Not only may this be a simple denial-of-service attack (see
   Section 10.7), but it would be a mechanism for an intruder to
   determine important information about the network and operational
   network policies simply by inserting bogus computation requests.
   Furthermore, false computation requests could be used to predict
   where traffic will be placed in the network when real requests are
   made, allowing the attacker to target specific network resources.

   PCEs SHOULD be configurable for access policy.  Where authentication
   is used, access policy can be achieved through the exchange or
   configuration of keys as described in Section 10.5.  More simple
   policies MAY be configured on PCEs in the form of access lists where
   the IP addresses of the legitimate PCCs are listed.  Policies SHOULD
   also be configurable to limit the type of computation requests that
   are supported from different PCCs.

   It is RECOMMENDED that access policy violations are logged by the PCE
   and are available for inspection by the operator to determine whether
   attempts have been made to attack the PCE.  Such mechanisms MUST be
   lightweight to prevent them from being used to support denial-of-
   service attacks (see Section 10.7).

10.7.  Protection against Denial-of-Service Attacks

   Denial-of-service (DoS) attacks could be mounted at the TCP level or
   at the PCEP level.  That is, the PCE could be attacked through
   attacks on TCP or through attacks within established PCEP sessions.

10.7.1.  Protection against TCP DoS Attacks

   PCEP can be the target of TCP DoS attacks, such as for instance SYN
   attacks, as is the case for all protocols that run over TCP.  Other
   protocol specifications have investigated this problem and PCEP can
   share their experience.  The reader is referred to the specification

Top      Up      ToC       Page 74 
   of the Label Distribution Protocol (LDP) [RFC5036] for example.  In
   order to protect against TCP DoS attacks, PCEP implementations can
   support the following techniques.

   o  PCEP uses a single registered port for all communications.  The
      PCE SHOULD listen for TCP connections only on ports where
      communication is expected.

   o  The PCE MAY implement an access list to immediately reject (or
      discard) TCP connection attempts from unauthorized PCCs.

   o  The PCE SHOULD NOT allow parallel TCP connections from the same
      PCC on the PCEP-registered port.

   o  The PCE MAY require the use of the MD5 option on all TCP
      connections, and MAY reject (or discard) any connection setup
      attempt that does not use MD5.  A PCE MUST NOT accept any SYN
      packet for which the MD5 segment checksum is invalid.  Note,
      however, that the use of MD5 requires that the receiver use CPU
      resources to compute the checksum before it can decide to discard
      an otherwise acceptable SYN segment.

10.7.2.  Request Input Shaping/Policing

   A PCEP implementation may be subject to DoS attacks within a
   legitimate PCEP session.  For example, a PCC might send a very large
   number of PCReq messages causing the PCE to become congested or
   causing requests from other PCCs to be queued.

   Note that the direct use of the Priority field on the RP object to
   prioritize received requests does not provide any protection since
   the attacker could set all requests to be of the highest priority.

   Therefore, it is RECOMMENDED that PCE implementations include input
   shaping/policing mechanisms that either throttle the requests
   received from any one PCC, or apply queuing or priority-degradation
   techniques to over-communicative PCCs.

   Such mechanisms MAY be set by default, but SHOULD be available for
   configuration.  Such techniques may be considered particularly
   important in multi-service-provider environments to protect the
   resources of one service provider from unwarranted, over-zealous, or
   malicious use by PCEs in another service provider.

Top      Up      ToC       Page 75 
11.  Acknowledgments

   The authors would like to thank Dave Oran, Dean Cheng, Jerry Ash,
   Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard
   Douville, Jon Parker, Martin German, and Dennis Aristow for their
   very valuable input.  The authors would also like to thank Fabien
   Verhaeghe for the very fruitful discussions and useful suggestions.
   David McGrew and Brian Weis provided valuable input to the Security
   Considerations section.

   Ross Callon, Magnus Westerlund, Lars Eggert, Pasi Eronen, Tim Polk,
   Chris Newman, and Russ Housley provided important input during IESG
   review.

12.  References

12.1.  Normative References

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

   [RFC2205]        Braden, B., Zhang, L., Berson, S., Herzog, S., and
                    S. Jamin, "Resource ReSerVation Protocol (RSVP) --
                    Version 1 Functional Specification", RFC 2205,
                    September 1997.

   [RFC2385]        Heffernan, A., "Protection of BGP Sessions via the
                    TCP MD5 Signature Option", RFC 2385, August 1998.

   [RFC3209]        Awduche, D., Berger, L., Gan, D., Li, T.,
                    Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
                    to RSVP for LSP Tunnels", RFC 3209, December 2001.

   [RFC3473]        Berger, L., "Generalized Multi-Protocol Label
                    Switching (GMPLS) Signaling Resource ReserVation
                    Protocol-Traffic Engineering (RSVP-TE) Extensions",
                    RFC 3473, January 2003.

   [RFC3477]        Kompella, K. and Y. Rekhter, "Signalling Unnumbered
                    Links in Resource ReSerVation Protocol - Traffic
                    Engineering (RSVP-TE)", RFC 3477, January 2003.

   [RFC4090]        Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
                    Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
                    May 2005.

Top      Up      ToC       Page 76 
   [RFC5226]        Narten, T. and H. Alvestrand, "Guidelines for
                    Writing an IANA Considerations Section in RFCs",
                    BCP 26, RFC 5226, May 2008.

12.2.  Informative References

   [BGP-SEC]        Christian, B. and T. Tauber, "BGP Security
                    Requirements", Work in Progress, November 2008.

   [IEEE.754.1985]  IEEE Standard 754, "Standard for Binary Floating-
                    Point Arithmetic", August 1985.

   [INTER-LAYER]    Oki, E., Roux, J., Kumaki, K., Farrel, A., and T.
                    Takeda, "PCC-PCE Communication and PCE Discovery
                    Requirements for Inter-Layer Traffic Engineering",
                    Work in Progress, January 2009.

   [MPLS-SEC]       Fang, L. and M. Behringer, "Security Framework for
                    MPLS and GMPLS Networks", Work in Progress,
                    November 2008.

   [PCE-MANAGE]     Farrel, A., "Inclusion of Manageability Sections in
                    PCE Working Group Drafts", Work in Progress,
                    January 2009.

   [PCE-MONITOR]    Vasseur, J., Roux, J., and Y. Ikejiri, "A set of
                    monitoring tools for Path Computation Element based
                    Architecture", Work in Progress, November 2008.

   [PCEP-MIB]       Stephan, E. and K. Koushik, "PCE communication
                    protocol (PCEP) Management Information Base",
                    Work in Progress, November 2008.

   [RBNF]           Farrel, A., "Reduced Backus-Naur Form (RBNF) A
                    Syntax Used in Various Protocol Specifications",
                    Work in Progress, November 2008.

   [RFC1321]        Rivest, R., "The MD5 Message-Digest Algorithm",
                    RFC 1321, April 1992.

   [RFC3471]        Berger, L., "Generalized Multi-Protocol Label
                    Switching (GMPLS) Signaling Functional Description",
                    RFC 3471, January 2003.

   [RFC3562]        Leech, M., "Key Management Considerations for the
                    TCP MD5 Signature Option", RFC 3562, July 2003.

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

   [RFC4022]        Raghunarayan, R., "Management Information Base for
                    the Transmission Control Protocol (TCP)", RFC 4022,
                    March 2005.

   [RFC4101]        Rescorla, E. and IAB, "Writing Protocol Models",
                    RFC 4101, June 2005.

   [RFC4107]        Bellovin, S. and R. Housley, "Guidelines for
                    Cryptographic Key Management", BCP 107, RFC 4107,
                    June 2005.

   [RFC4120]        Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
                    "The Kerberos Network Authentication Service (V5)",
                    RFC 4120, July 2005.

   [RFC4278]        Bellovin, S. and A. Zinin, "Standards Maturity
                    Variance Regarding the TCP MD5 Signature Option (RFC
                    2385) and the BGP-4 Specification", RFC 4278,
                    January 2006.

   [RFC4303]        Kent, S., "IP Encapsulating Security Payload (ESP)",
                    RFC 4303, December 2005.

   [RFC4306]        Kaufman, C., "Internet Key Exchange (IKEv2)
                    Protocol", RFC 4306, December 2005.

   [RFC5420]        Farrel, A., Ed., Papadimitriou, D., Vasseur, JP.,
                    and A. Ayyangarps, "Encoding of Attributes for MPLS
                    LSP Establishment Using Resource Reservation
                    Protocol Traffic Engineering (RSVP-TE)", RFC 5420,
                    February 2009.

   [RFC4655]        Farrel, A., Vasseur, J., and J. Ash, "A Path
                    Computation Element (PCE)-Based Architecture",
                    RFC 4655, August 2006.

   [RFC4657]        Ash, J. and J. Le Roux, "Path Computation Element
                    (PCE) Communication Protocol Generic Requirements",
                    RFC 4657, September 2006.

   [RFC4674]        Le Roux, J., "Requirements for Path Computation
                    Element (PCE) Discovery", RFC 4674, October 2006.

Top      Up      ToC       Page 78 
   [RFC4927]        Le Roux, J., "Path Computation Element Communication
                    Protocol (PCECP) Specific Requirements for Inter-
                    Area MPLS and GMPLS Traffic Engineering", RFC 4927,
                    June 2007.

   [RFC5036]        Andersson, L., Minei, I., and B. Thomas, "LDP
                    Specification", RFC 5036, October 2007.

   [RFC5088]        Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R.
                    Zhang, "OSPF Protocol Extensions for Path
                    Computation Element (PCE) Discovery", RFC 5088,
                    January 2008.

   [RFC5089]        Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R.
                    Zhang, "IS-IS Protocol Extensions for Path
                    Computation Element (PCE) Discovery", RFC 5089,
                    January 2008.

   [RFC5246]        Dierks, T. and E. Rescorla, "The Transport Layer
                    Security (TLS) Protocol Version 1.2", RFC 5246,
                    August 2008.

   [RFC5376]        Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
                    Requirements for the Path Computation Element
                    Communication Protocol (PCECP)", RFC 5376,
                    November 2008.

   [TCP-AUTH]       Touch, J., Mankin, A., and R. Bonica, "The TCP
                    Authentication Option", Work in Progress,
                    November 2008.

Top      Up      ToC       Page 79 
Appendix A.  PCEP Finite State Machine (FSM)

   The section describes the PCEP finite state machine (FSM).  PCEP
   Finite State Machine

                          +-+-+-+-+-+-+<------+
                   +------| SessionUP |<---+  |
                   |      +-+-+-+-+-+-+    |  |
                   |                       |  |
                   |   +->+-+-+-+-+-+-+    |  |
                   |   |  | KeepWait  |----+  |
                   |   +--|           |<---+  |
                   |+-----+-+-+-+-+-+-+    |  |
                   ||          |           |  |
                   ||          |           |  |
                   ||          V           |  |
                   ||  +->+-+-+-+-+-+-+----+  |
                   ||  |  | OpenWait  |-------+
                   ||  +--|           |<------+
                   ||+----+-+-+-+-+-+-+<---+  |
                   |||         |           |  |
                   |||         |           |  |
                   |||         V           |  |
                   ||| +->+-+-+-+-+-+-+    |  |
                   ||| |  |TCPPending |----+  |
                   ||| +--|           |       |
                   |||+---+-+-+-+-+-+-+<---+  |
                   ||||        |           |  |
                   ||||        |           |  |
                   ||||        V           |  |
                   |||+--->+-+-+-+-+       |  |
                   ||+---->| Idle  |-------+  |
                   |+----->|       |----------+
                   +------>+-+-+-+-+

        Figure 23: PCEP Finite State Machine for the PCC

   PCEP defines the following set of variables:

   Connect:  the timer (in seconds) started after having initialized a
      TCP connection using the PCEP-registered TCP port.  The value of
      the Connect timer is 60 seconds.

   ConnectRetry:  the number of times the system has tried to establish
      a TCP connection with a PCEP peer without success.

Top      Up      ToC       Page 80 
   ConnectMaxRetry:  the maximum number of times the system tries to
      establish a TCP connection using the PCEP-registered TCP port
      before going back to the Idle state.  The value of the
      ConnectMaxRetry is 5.

   OpenWait:  the timer that corresponds to the amount of time a PCEP
      peer will wait to receive an Open message from the PCEP peer after
      the expiration of which the system releases the PCEP resource and
      goes back to the Idle state.  The OpenWait timer has a fixed value
      of 60 seconds.

   KeepWait:  the timer that corresponds to the amount of time a PCEP
      peer will wait to receive a Keepalive or a PCErr message from the
      PCEP peer after the expiration of which the system releases the
      PCEP resource and goes back to the Idle state.  The KeepWait timer
      has a fixed value of 60 seconds.

   OpenRetry:  the number of times the system has received an Open
      message with unacceptable PCEP session characteristics.

   The following two state variables are defined:

   RemoteOK:  a boolean that is set to 1 if the system has received an
      acceptable Open message.

   LocalOK:  a boolean that is set to 1 if the system has received a
      Keepalive message acknowledging that the Open message sent to the
      peer was valid.

   Idle State:

   The idle state is the initial PCEP state where the PCEP (also
   referred to as "the system") waits for an initialization event that
   can either be manually triggered by the user (configuration) or
   automatically triggered by various events.  In Idle state, PCEP
   resources are allocated (memory, potential process, etc.) but no PCEP
   messages are accepted from any PCEP peer.  The system listens to the
   PCEP-registered TCP port.

   The following set of variables are initialized:

      TCPRetry=0,

      LocalOK=0,

      RemoteOK=0,

      OpenRetry=0.

Top      Up      ToC       Page 81 
   Upon detection of a local initialization event (e.g., user
   configuration to establish a PCEP session with a particular PCEP
   peer, local event triggering the establishment of a PCEP session with
   a PCEP peer such as the automatic detection of a PCEP peer), the
   system:

   o  Initiates a TCP connection with the PCEP peer,

   o  Starts the Connect timer,

   o  Moves to the TCPPending state.

   Upon receiving a TCP connection on the PCEP-registered TCP port, if
   the TCP connection establishment succeeds, the system:

   o  Sends an Open message,

   o  Starts the OpenWait timer,

   o  Moves to the OpenWait state.

   If the connection establishment fails, the system remains in the Idle
   state.  Any other event received in the Idle state is ignored.

   It is expected that an implementation will use an exponentially
   increasing timer between automatically generated Initialization
   events and between retries of TCP connection establishment.

   TCPPending State:

   If the TCP connection establishment succeeds, the system:

   o  Sends an Open message,

   o  Starts the OpenWait timer,

   o  Moves to the OpenWait state.

   If the TCP connection establishment fails (an error is detected
   during the TCP connection establishment) or the Connect timer
   expires:

   o  If ConnectRetry = ConnectMaxRetry, the system moves to the Idle
      State.

Top      Up      ToC       Page 82 
   o  If ConnectRetry < ConnectMaxRetry, the system:

      1.  Initiates of a TCP connection with the PCEP peer,

      2.  Increments the ConnectRetry variable,

      3.  Restarts the Connect timer,

      4.  Stays in the TCPPending state.

   In response to any other event, the system releases the PCEP
   resources for that peer and moves back to the Idle state.

   OpenWait State:

   In the OpenWait state, the system waits for an Open message from its
   PCEP peer.

   If the system receives an Open message from the PCEP peer before the
   expiration of the OpenWait timer, the system first examines all of
   its sessions that are in the OpenWait or KeepWait state.  If another
   session with the same PCEP peer already exists (same IP address),
   then the system performs the following collision-resolution
   procedure:

   o  If the system has initiated the current session and it has a lower
      IP address than the PCEP peer, the system closes the TCP
      connection, releases the PCEP resources for the pending session,
      and moves back to the Idle state.

   o  If the session was initiated by the PCEP peer and the system has a
      higher IP address that the PCEP peer, the system closes the TCP
      connection, releases the PCEP resources for the pending session,
      and moves back to the Idle state.

   o  Otherwise, the system checks the PCEP session attributes
      (Keepalive frequency, DeadTimer, etc.).

   If an error is detected (e.g., malformed Open message, reception of a
   message that is not an Open message, presence of two OPEN objects),
   PCEP generates an error notification, the PCEP peer sends a PCErr
   message with Error-Type=1 and Error-value=1.  The system releases the
   PCEP resources for the PCEP peer, closes the TCP connection, and
   moves to the Idle state.

Top      Up      ToC       Page 83 
   If no errors are detected, OpenRetry=1, and the session
   characteristics are unacceptable, the PCEP peer sends a PCErr with
   Error-Type=1 and Error-value=5, and the system releases the PCEP
   resources for that peer and moves back to the Idle state.

   If no errors are detected, and the session characteristics are
   acceptable to the local system, the system:

   o  Sends a Keepalive message to the PCEP peer,

   o  Starts the Keepalive timer,

   o  Sets the RemoteOK variable to 1.

   If LocalOK=1, the system clears the OpenWait timer and moves to the
   UP state.

   If LocalOK=0, the system clears the OpenWait timer, starts the
   KeepWait timer, and moves to the KeepWait state.

   If no errors are detected, but the session characteristics are
   unacceptable and non-negotiable, the PCEP peer sends a PCErr with
   Error-Type=1 and Error-value=3, and the system releases the PCEP
   resources for that peer and moves back to the Idle state.

   If no errors are detected, and OpenRetry is 0, and the session
   characteristics are unacceptable but negotiable (such as, the
   Keepalive period or the DeadTimer), then the system:

   o  Increments the OpenRetry variable,

   o  Sends a PCErr message with Error-Type=1 and Error-value=4 that
      contains proposed acceptable session characteristics,

   o  If LocalOK=1, the system restarts the OpenWait timer and stays in
      the OpenWait state.

   o  If LocalOK=0, the system clears the OpenWait timer, starts the
      KeepWait timer, and moves to the KeepWait state.

   If no Open message is received before the expiration of the OpenWait
   timer, the PCEP peer sends a PCErr message with Error-Type=1 and
   Error-value=2, the system releases the PCEP resources for the PCEP
   peer, closes the TCP connection, and moves to the Idle state.

   In response to any other event, the system releases the PCEP
   resources for that peer and moves back to the Idle state.

Top      Up      ToC       Page 84 
   KeepWait State:

   In the Keepwait state, the system waits for the receipt of a
   Keepalive from its PCEP peer acknowledging its Open message or a
   PCErr message in response to unacceptable PCEP session
   characteristics proposed in the Open message.

   If an error is detected (e.g., malformed Keepalive message), PCEP
   generates an error notification, the PCEP peer sends a PCErr message
   with Error-Type=1 and Error-value=1.  The system releases the PCEP
   resources for the PCEP peer, closes the TCP connection, and moves to
   the Idle state.

   If a Keepalive message is received before the expiration of the
   KeepWait timer, then the system sets LocalOK=1 and:

   o  If RemoteOK=1, the system clears the KeepWait timer and moves to
      the UP state.

   o  If RemoteOK=0, the system clears the KeepWait timer, starts the
      OpenWait timer, and moves to the OpenWait State.

   If a PCErr message is received before the expiration of the KeepWait
   timer:

   1.  If the proposed values are unacceptable, the PCEP peer sends a
       PCErr message with Error-Type=1 and Error-value=6, and the system
       releases the PCEP resources for that PCEP peer, closes the TCP
       connection, and moves to the Idle state.

   2.  If the proposed values are acceptable, the system adjusts its
       PCEP session characteristics according to the proposed values
       received in the PCErr message, restarts the KeepWait timer, and
       sends a new Open message.  If RemoteOK=1, the system restarts the
       KeepWait timer and stays in the KeepWait state.  If RemoteOK=0,
       the system clears the KeepWait timer, starts the OpenWait timer,
       and moves to the OpenWait state.

   If neither a Keepalive nor a PCErr is received after the expiration
   of the KeepWait timer, the PCEP peer sends a PCErr message with
   Error-Type=1 and Error-value=7, and the system releases the PCEP
   resources for that PCEP peer, closes the TCP connection, and moves to
   the Idle State.

   In response to any other event, the system releases the PCEP
   resources for that peer and moves back to the Idle state.

Top      Up      ToC       Page 85 
   UP State:

   In the UP state, the PCEP peer starts exchanging PCEP messages
   according to the session characteristics.

   If the Keepalive timer expires, the system restarts the Keepalive
   timer and sends a Keepalive message.

   If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) is received from
   the PCEP peer before the expiration of the DeadTimer, the system
   terminates the PCEP session according to the procedure defined in
   Section 6.8, releases the PCEP resources for that PCEP peer, closes
   the TCP connection, and moves to the Idle State.

   If a malformed message is received, the system terminates the PCEP
   session according to the procedure defined in Section 6.8, releases
   the PCEP resources for that PCEP peer, closes the TCP connection and
   moves to the Idle State.

   If the system detects that the PCEP peer tries to set up a second TCP
   connection, it stops the TCP connection establishment and sends a
   PCErr with Error-Type=9.

   If the TCP connection fails, the system releases the PCEP resources
   for that PCEP peer, closes the TCP connection, and moves to the Idle
   State.

Appendix B.  PCEP Variables

   PCEP defines the following configurable variables:

   Keepalive timer:  minimum period of time between the sending of PCEP
      messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer.  A
      suggested value for the Keepalive timer is 30 seconds.

   DeadTimer:  period of timer after the expiration of which a PCEP peer
      declares the session down if no PCEP message has been received.

   SyncTimer:  timer used in the case of synchronized path computation
      request using the SVEC object defined in Section 7.13.3.  Consider
      the case where a PCReq message is received by a PCE that contains
      the SVEC object referring to M synchronized path computation
      requests.  If after the expiration of the SyncTimer all the M path
      computation requests have not been received, a protocol error is
      triggered and the PCE MUST cancel the whole set of path
      computation requests.  The aim of the SyncTimer is to avoid the
      storage of unused synchronized requests should one of them get
      lost for some reason (e.g., a misbehaving PCC).  Thus, the value

Top      Up      ToC       Page 86 
      of the SyncTimer must be large enough to avoid the expiration of
      the timer under normal circumstances.  A RECOMMENDED value for the
      SyncTimer is 60 seconds.

   MAX-UNKNOWN-REQUESTS:  A RECOMMENDED value is 5.

   MAX-UNKNOWN-MESSAGES:  A RECOMMENDED value is 5.

Appendix C.  Contributors

   The content of this document was contributed by those listed below
   and the editors listed at the end of the document.

   Arthi Ayyangar
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA  94089
   USA

   EMail: arthi@juniper.net


   Adrian Farrel
   Old Dog Consulting
   Phone: +44 (0) 1978 860944

   EMail: adrian@olddog.co.uk


   Eiji Oki
   NTT
   Midori 3-9-11
   Musashino, Tokyo,   180-8585
   JAPAN

   EMail: oki.eiji@lab.ntt.co.jp


   Alia Atlas
   British Telecom

   EMail: akatlas@alum.mit.edu

Top      Up      ToC       Page 87 
   Andrew Dolganow
   Alcatel
   600 March Road
   Ottawa, ON  K2K 2E6
   CANADA

   EMail: andrew.dolganow@alcatel.com


   Yuichi Ikejiri
   NTT Communications Corporation
   1-1-6 Uchisaiwai-cho, Chiyoda-ku
   Tokyo,   100-819
   JAPAN

   EMail: y.ikejiri@ntt.com


   Kenji Kumaki
   KDDI Corporation
   Garden Air Tower Iidabashi, Chiyoda-ku,
   Tokyo,   102-8460
   JAPAN

   EMail: ke-kumaki@kddi.com

Authors' Addresses

   JP Vasseur (editor)
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   EMail: jpv@cisco.com


   JL Le Roux (editor)
   France Telecom
   2, Avenue Pierre-Marzin
   Lannion  22307
   FRANCE

   EMail: jeanlouis.leroux@orange-ftgroup.com