Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5440

Path Computation Element (PCE) Communication Protocol (PCEP)

Pages: 87
Proposed Standard
Errata
Updated by:  789682538356
Part 4 of 4 – Pages 59 to 87
First   Prev   None

Top   ToC   RFC5440 - Page 59   prevText

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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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   ToC   RFC5440 - 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