RFC 5440
Path Computation Element (PCE) Communication Protocol (PCEP)
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 document9.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
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
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
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
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 document9.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:
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
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.
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.
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.
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 document9.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
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.
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.
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
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.
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
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.
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.
[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.
[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.
[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.
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.
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.
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.
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.
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.
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.
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
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
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.comAuthors' 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