draft-ietf-pce-pcep-04.txt   draft-ietf-pce-pcep-05.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track JL. Le Roux, Ed. Intended status: Standards Track JL. Le Roux, Ed.
Expires: June 16, 2007 France Telecom Expires: July 16, 2007 France Telecom
December 13, 2006 January 12, 2007
Path Computation Element (PCE) communication Protocol (PCEP) - Version 1 Path Computation Element (PCE) communication Protocol (PCEP) - Version 1
draft-ietf-pce-pcep-04.txt draft-ietf-pce-pcep-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 16, 2007. This Internet-Draft will expire on July 16, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). Copyright (C) The Internet Society (2007).
Abstract Abstract
This document specifies the Path Computation Element communication This document specifies the Path Computation Element communication
Protocol (PCEP) for communications between a Path Computation Client Protocol (PCEP) for communications between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between two PCEs. (PCC) and a Path Computation Element (PCE), or between two PCEs.
Such interactions include path computation requests and path Such interactions include path computation requests and path
computation replies as well as notifications of specific states computation replies as well as notifications of specific states
related to the use of a PCE in the context of MPLS and GMPLS Traffic related to the use of a PCE in the context of MPLS and GMPLS Traffic
Engineering. The PCEP protocol is designed to be flexible and Engineering. The PCEP protocol is designed to be flexible and
skipping to change at page 3, line 15 skipping to change at page 3, line 15
computation requests . . . . . . . . . . . . . . . . . 36 computation requests . . . . . . . . . . . . . . . . . 36
7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38 7.12.2. SVEC Object . . . . . . . . . . . . . . . . . . . . . 38
7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 39 7.12.3. Handling of the SVEC Object . . . . . . . . . . . . . 39
7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40 7.13. NOTIFICATION Object . . . . . . . . . . . . . . . . . . . 40
7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43 7.14. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . . 43
7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 46 7.15. LOAD-BALANCING Object . . . . . . . . . . . . . . . . . . 46
7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 47 7.16. CLOSE Object . . . . . . . . . . . . . . . . . . . . . . . 47
8. Manageability Considerations . . . . . . . . . . . . . . . . . 48 8. Manageability Considerations . . . . . . . . . . . . . . . . . 48
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.1. TCP Port . . . . . . . . . . . . . . . . . . . . . . . . . 48
9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 48 9.2. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 49
9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 49 9.3. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 49
9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 50 9.4. Notification . . . . . . . . . . . . . . . . . . . . . . . 50
9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 51 9.5. PCEP Error . . . . . . . . . . . . . . . . . . . . . . . . 51
9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 52 9.6. NO-PATH-VECTOR TLV . . . . . . . . . . . . . . . . . . . . 52
10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 53 10. PCEP Finite State Machine (FSM) . . . . . . . . . . . . . . . 53
11. Security Considerations . . . . . . . . . . . . . . . . . . . 58 11. Security Considerations . . . . . . . . . . . . . . . . . . . 58
11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 59 11.1. PCEP Authentication and Integrity . . . . . . . . . . . . 59
11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 59 11.2. PCEP Privacy . . . . . . . . . . . . . . . . . . . . . . . 59
11.3. Protection against Denial of Service attacks . . . . . . . 59 11.3. Protection against Denial of Service attacks . . . . . . . 59
11.4. Request input shaping/policing . . . . . . . . . . . . . . 60 11.4. Request input shaping/policing . . . . . . . . . . . . . . 60
skipping to change at page 17, line 43 skipping to change at page 17, line 43
The PCRep message MUST contain at least one RP object. For each The PCRep message MUST contain at least one RP object. For each
reply that is bundled into a single PCReq message, an RP object MUST reply that is bundled into a single PCReq message, an RP object MUST
be included that contains a Request-ID-number identical to the one be included that contains a Request-ID-number identical to the one
specified in the RP object carried in the corresponding PCReq message specified in the RP object carried in the corresponding PCReq message
(see Section 7.3for the definition of the RP object). (see Section 7.3for the definition of the RP object).
A PCRep message may contain a set of computed path(s) corresponding A PCRep message may contain a set of computed path(s) corresponding
to either a single path computation request with load-balancing (see to either a single path computation request with load-balancing (see
Section 7.15) or multiple path computation requests originated by a Section 7.15) or multiple path computation requests originated by a
requesting PCC. The PCReq message may also contain multiple requesting PCC. The PCRep message may also contain multiple
acceptable paths corresponding to the same request. acceptable paths corresponding to the same request.
The bundling of multiple replies to a set of path computation The bundling of multiple replies to a set of path computation
requests within a single PCRep message is supported by the PCEP requests within a single PCRep message is supported by the PCEP
protocol. If a PCE receives non-synchronized path computation protocol. If a PCE receives non-synchronized path computation
requests by means of one or more PCReq messages from a requesting PCC requests by means of one or more PCReq messages from a requesting PCC
it may decide to bundle the computed paths within a single PCRep it may decide to bundle the computed paths within a single PCRep
message so as to reduce the control plane load. Note that the message so as to reduce the control plane load. Note that the
counter side of such an approach is the introduction of additional counter side of such an approach is the introduction of additional
delays for some path computation requests of the set. Conversely, a delays for some path computation requests of the set. Conversely, a
skipping to change at page 22, line 29 skipping to change at page 22, line 29
currently defined. currently defined.
OPEN Object-Class is to be assigned by IANA (recommended value=1) OPEN Object-Class is to be assigned by IANA (recommended value=1)
OPEN Object-Type is to be assigned by IANA (recommended value=1) OPEN Object-Type is to be assigned by IANA (recommended value=1)
The format of the OPEN object body is as follows: The format of the OPEN object body is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Keepalive | Deadtimer | SID | Flags | | Ver | Flags | Keepalive | Deadtimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLV(s) // // Optional TLV(s) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object format Figure 9: OPEN Object format
Ver (Ver - 3 bits): PCEP version. Current version is 1. Ver (Ver - 3 bits): PCEP version. Current version is 1.
Keepalive (8 bits): minimum period of time (in seconds) between the Keepalive (8 bits): minimum period of time (in seconds) between the
skipping to change at page 48, line 25 skipping to change at page 48, line 25
Figure 14: CLOSE Object format Figure 14: CLOSE Object format
Reason (4 bits): specifies the reason for closing the PCEP session. Reason (4 bits): specifies the reason for closing the PCEP session.
The setting of this field is optional. Three values are currently The setting of this field is optional. Three values are currently
defined. defined.
Reasons Reasons
Value Meaning Value Meaning
1 No explanation provided 1 No explanation provided
2 DeadTimer expired 2 DeadTimer expired
3 PCEP session characteristics negotiation failure 3 PCEP session characteristics negotiation failure
4 Reception of a malformed PCEP message
Flags (4 bits): No Flags are currently defined. Flags (4 bits): No Flags are currently defined.
Optional TLVs may be included within the CLOSE object body. The Optional TLVs may be included within the CLOSE object body. The
specification of such TLVs is outside the scope of this document. specification of such TLVs is outside the scope of this document.
8. Manageability Considerations 8. Manageability Considerations
It is expected and required to specify a MIB for the PCEP It is expected and required to specify a MIB for the PCEP
communication protocol (in a separate document). Furthermore, communication protocol (in a separate document). Furthermore,
additional tools related to performance, fault and diagnostic additional tools related to performance, fault and diagnostic
skipping to change at page 62, line 28 skipping to change at page 62, line 28
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
September 2006. September 2006.
[RFC4674] Le Roux, J., "Requirements for Path Computation Element [RFC4674] Le Roux, J., "Requirements for Path Computation Element
(PCE) Discovery", RFC 4674, October 2006. (PCE) Discovery", RFC 4674, October 2006.
14.2. Informative References 14.2. Informative References
[I-D.ietf-ccamp-inter-domain-rsvp-te] [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS
Engineering - RSVP-TE extensions", Traffic Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in
progress), March 2006. progress), January 2007.
[I-D.ietf-pce-disco-proto-isis] [I-D.ietf-pce-disco-proto-isis]
Roux, J., "IS-IS protocol extensions for Path Computation Roux, J., "IS-IS protocol extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
draft-ietf-pce-disco-proto-isis-01 (work in progress), draft-ietf-pce-disco-proto-isis-01 (work in progress),
December 2006. December 2006.
[I-D.ietf-pce-disco-proto-ospf] [I-D.ietf-pce-disco-proto-ospf]
Roux, J., "OSPF protocol extensions for Path Computation Roux, J., "OSPF protocol extensions for Path Computation
Element (PCE) Discovery", Element (PCE) Discovery",
skipping to change at page 63, line 13 skipping to change at page 63, line 13
[I-D.ietf-pce-interas-pcecp-reqs] [I-D.ietf-pce-interas-pcecp-reqs]
Bitar, N., "Inter-AS Requirements for the Path Computation Bitar, N., "Inter-AS Requirements for the Path Computation
Element Communication Protocol (PCECP)", Element Communication Protocol (PCECP)",
draft-ietf-pce-interas-pcecp-reqs-01 (work in progress), draft-ietf-pce-interas-pcecp-reqs-01 (work in progress),
October 2006. October 2006.
[I-D.ietf-pce-pcecp-interarea-reqs] [I-D.ietf-pce-pcecp-interarea-reqs]
Roux, J., "PCE Communication Protocol (PCECP) Specific Roux, J., "PCE Communication Protocol (PCECP) Specific
Requirements for Inter-Area Multi Protocol Label Requirements for Inter-Area Multi Protocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
Engineering", draft-ietf-pce-pcecp-interarea-reqs-04 (work Engineering", draft-ietf-pce-pcecp-interarea-reqs-05 (work
in progress), November 2006. in progress), December 2006.
[I-D.ietf-rpsec-bgpsecrec] [I-D.ietf-rpsec-bgpsecrec]
Christian, B. and T. Tauber, "BGP Security Requirements", Christian, B. and T. Tauber, "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-06 (work in progress), draft-ietf-rpsec-bgpsecrec-06 (work in progress),
June 2006. June 2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
skipping to change at page 64, line 35 skipping to change at page 64, line 35
SyncTimer: the SYNC timer is used in the case of synchronized path SyncTimer: the SYNC timer is used in the case of synchronized path
computation request using the SVEC object defined in Section 7.12.3. computation request using the SVEC object defined in Section 7.12.3.
Consider the case where a PCReq message is received by a PCE that Consider the case where a PCReq message is received by a PCE that
contains the SVEC object referring to M synchronized path computation contains the SVEC object referring to M synchronized path computation
requests. If after the expiration of the SYNC timer all the M path requests. If after the expiration of the SYNC timer all the M path
computation requests have not been received, a protocol error is computation requests have not been received, a protocol error is
triggered and the PCE MUST cancel the whole set of path computation triggered and the PCE MUST cancel the whole set of path computation
requests. A RECOMMENDED value for the SYNC timer is 60 seconds. requests. A RECOMMENDED value for the SYNC timer is 60 seconds.
Editors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
JL Le Roux (editor) JL Le Roux (editor)
France Telecom France Telecom
2, Avenue Pierre-Marzin 2, Avenue Pierre-Marzin
Lannion, 22307 Lannion, 22307
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 13 change blocks. 
20 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/