Subject: [Pce] I-D Action:draft-ietf-pce-pcep-09.txt

From: [email-masked]
Date: Fri, 16 Nov 2007 16:50:02 -0500

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-masked] 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-masked].
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.
_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Fri, 16 Nov 2007 16:57:26 -0500

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-masked]>
> Date: Fri, 16 Nov 2007 16:50:02 -0500
> To: <[email-masked]>
> Cc: <[email-masked]>
> Subject: [Pce] I-D Action:draft-ietf-pce-pcep-09.txt
> 
> Content-Type: text/plain
> Content-ID: <2007-11-16164622.I-D\@ietf.org>
> 

------ End of Forwarded Message