Dear WG,
Please find below the changes in revision -09 of PCEP:
1) New text: "The P flag of the END-POINT object MUST be set in PCReq
message."
2) A New PCErr type and value has been defined.
10 Reception of a malformed object
Error-value=1: reception of an object with P flag not set although
the P-flag must be set according to this specification.
3) Text added for both the RP and END-POINT objects:
"The P flag of the RP object MUST be set in PCReq and PCReq messages and
MUST be cleared in PCNtf and PCErr messages. If the RP objet is received
with the P flag set incorrectely according to the rules states above, the
receiving peer MUST send a PCErr message with Error-type=10 and
Error-value=1. The corresponding path computation request MUST be cancelled
by the PCE without further notification."
4) Clarification on receiving two METRIC object in a PCReq message with B=0.
"If a PCReq message is received that contains two METRIC object with the B
flag set, the receiving peer MUST send a PCErr message with Error-type=10
and Error-value=2."
5) Clarification in 7.1
"If the PCE does not understand an object with the P flag set or understands
the object but decides to ignore the object, the entire PCEP message MUST be
rejected and the PCE MUST send a PCErr message with Error-Type=³Unknown
Object² or ³Not supported Object² along with the corresponding RP object.
Note that if a PCReq includes multiple requests, only requests for which an
object with the P flag set is unknown/unrecognized MUST be rejected."
6) Common PCEP Object
We used to have different TLV format. We have now defined a single TLV
format for all PCEP object.
"A PCEP object may include a set of one or more optional TLV(s). All PCEP
TLV have a common format:
Type: 2 bytes
Lenght: 2 bytes
Value
A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes specifying
the TLV length, and a value field. The Length field defines the length of
the value portion in bytes. The TLV is padded to 4-bytes alignment; padding
is not included in the Length field (so a three bytes value would have a
length of three, but the total size of the TLV would be eight bytes).
Unrecognized TLVs MUST be ignored."
IANA is requested to managed the PCEP Object TLV. A new registry has been
requested.
7) New format for the NO-PATH-VECTOR TLV
"The NO-PATH-VECTOR TLV is compliant with the PCEP TLV format defined in
section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the
TLV length (length of the value portion in bytes) followed by a fix length
value field of 32-bits flags field used to report the reason(s) that led to
unsuccessful path computation.
TYPE: To be assigned by IANA (suggested value=1)
LENGTH: 1
VALUE: 32-bits flags field"
8) New format for the OVERLOAD-DURATION TLV
"The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format defined
in section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying
the TLV length (length of the value portion in bytes) followed by a fix
length value field of 32-bits flags field.
TYPE: To be assigned by IANA (Suggested Value=2)
LENGTH: 4
VALUE: 32-bits flags field indicates the estimated PCE congestion duration
in seconds."
9) New format for the REQ-MISSING TLV
"The REQ-MISSING TLV is compliant with the PCEP TLV format defined in
section 7.1 and is comprised of 2 bytes for the type, 2 bytes specifying the
TLV length (length of the value portion in bytes) followed by a fix length
value field of 4 bytes.
TYPE: To be assigned by IANA (suggested value=3)
LENGTH: 4
VALUE: 4 bytes that indicates the request-id-number that corresponds to the
missing request."
10) Clarification on the SVEC Handling
"When a PCE receives a path computation request that cannot be satisfied
(for example because the PCReq message contains an object with the P bit set
that is not supported), the PCE sends a PCErr message for this request (see
section 7.2) the PCE MUST cancel the whole set of related path computation
requests and MUST send a PCErr message with Error-Type="Synchronized path
computation request missing".
11) Change in the FSM with regards to the Collision resolution procedure:
"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:
* If the system has initiated the current session and 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.
* 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.
* Otherwise, the system checks the PCEP session attributes (Keepalive
frequency, DeadTimer, ...)."
12) Clarification in the IANA section.
Thanks.
JP.
------ Forwarded Message
> From: <[EMAIL PROTECTED]>
> Date: Fri, 16 Nov 2007 16:50:02 -0500
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Subject: [Pce] I-D Action:draft-ietf-pce-pcep-09.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Path Computation Element Working Group of the
> IETF.
>
>
> Title : Path Computation Element (PCE) communication Protocol (PCEP)
> Author(s) : A. Ayyangar, et al.
> Filename : draft-ietf-pce-pcep-09.txt
> Pages : 73
> Date : 2007-11-16
>
> This document specifies the Path Computation Element communication
> Protocol (PCEP) for communications between a Path Computation Client
> (PCC) and a Path Computation Element (PCE), or between two PCEs.
> Such interactions include path computation requests and path
> computation replies as well as notifications of specific states
> related to the use of a PCE in the context of Multiprotocol Label
> Switching (MPLS) and Generalized (GMPLS) Traffic Engineering. The
> PCEP protocol is designed to be flexible and extensible so as to
> easily allow for the addition of further messages and objects, should
> further requirements be expressed in the future.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-09.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [EMAIL PROTECTED] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-ietf-pce-pcep-09.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [EMAIL PROTECTED]
> In the body type:
> "FILE /internet-drafts/draft-ietf-pce-pcep-09.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[EMAIL PROTECTED]>
>
> _______________________________________________
> Pce mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pce
------ End of Forwarded Message
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
