Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-01.txt

From: [email-masked]
Date: Fri, 03 Mar 2006 18: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) - Version 1
	Author(s)	: J. Vasseur, et al.
	Filename	: draft-ietf-pce-pcep-01.txt
	Pages		: 57
	Date		: 2006-3-3
	
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 MPLS and 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-01.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-01.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-01.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: Wed, 8 Mar 2006 08:55:28 -0500

Dear WG,

Just to inform you that a new revision of PCEP has been posted, with  
the following main changes:

1) We fixed a number of inconsistencies between MUST, MAY, ... +  
other semantic inconsistencies here and there, add new references to  
the application-specific requirement ID for reference, clarified the  
text in a number of places, clarified the notion of optional/ 
mandatory objects.
2) The ID has been restructured a little bit: the Elements of  
Procedure related to several objects were defined in a separate  
section 9, making the ID not easily readable.
3) Appendix A has been removed since it was essentially useful during  
the protocol selection process.

Some substantial changes
*******************************

1) We had introduced two modes: permanent versus per-request. We  
actually do not need to specify this and negotiate the mode upon  
session establishment. If the PCC desires to use a per-request mode  
and establishes a new PCEP session on a per-request basis, this is by  
default supported. So we updated the ID accordingly.

3) Close message + CLOSE Object added.

4) We added a Deadtimer field in the Open message rather than fixing  
the Deadtimer to x times the Keepalive since this might be quite  
useful in several circumstances.

5) The PCEP Session establishment phase with parameter negotiation  
has been updated. Now a PCEP peer can propose alternative PCEP  
session characteristics value by including an OPEN message in PCErr.  
Note that this is also reflected in the FSM.

6) The DELAY object has been removed. A new object (more generic) and  
named the METRIC object has been defined that can be used within a  
PCReq to specify the metric that should be optimized and also a bound  
(optionally) and in a PCRep to indicate the computed path metric.  
This introduces a new more flexible logic (C bit of the RP object has  
been removed).

7) The logic of the P-flag and I-Flag (in common header) has been  
rewritten.

8) The structure of the OPEN object has been changed (reduced). R- 
flag removed.

9) NO-PATH object: section has been reworded for the sake of clarity.  
Ability to suggest a value instead of just reporting the unsatisfied  
constraint. Example added.

10) We clarified that the IP address in the END-POINTS object does  
not have to be the source/destination addresses of the TE LSP since  
this was discussed on the list.

11) SVEC object: added to ability to send synchronized path  
computations in multiple PCReq messages (new PCEP variable added).

12) The B and N bits of the LSPA object have been removed.

13) PCRep message structure has been updated

Of course, comments are more than welcome !

Thanks.

JP.

Begin forwarded message:

> From: [email-masked]
> Date: March 3, 2006 6:50:02 PM EST
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Pce] I-D ACTION:draft-ietf-pce-pcep-01.txt
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>