Subject: [Pce] Changes in PCEP v6

From: JP Vasseur <[email-masked]>
Date: Fri, 16 Feb 2007 16:28:16 -0500

Dear WG,

Here an update wrt to PCEP Rev-06:

1) Various edits

2) New header format:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |  Flags  |  Message-Type |       Message-Lenght          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Ver

3) New Section (6.7: Error message)

4) A few inconsistencies with regards to session establishment (only  
triggered by PCC) have been fixed.

5) Clarification added:
"In case of TCP connection failure, the PCEP session SHOULD be  
maintained for a period of time equal to the DeadTimer." has been  
replaced by "In case of TCP connection failure, the PCEP session is  
immediatly terminated." in section 5.2.5

6) Reserved field and unassigned
Clarification added:
- Reserved: This field MUST be set to zero on transmission and MUST  
be ignored on receipt.
- Unassigned bits are considered as reserved and MUST be set to zero  
on transmission.

7) The I flag has no meaning in a PCRep message when the P flag had  
been set in the corresponding PCRep message.

8) In the PCEP message header, the version field was 4 bits and in  
the Open Object it was 3 bits.
The version field of OPEN has been aligned to 4 bits (Flags field  
reduced from 5 bits to 4bits).

9) The BNF of the PCReq/PCRep message has been fixed to support  
multiple METRIC objects. BNF also modified to remove SVEC object in  
PCRep message.

10) Clarification added on the use of the METRIC object during  
reoptimization + text modified:
B bit used to report a constraint
	When B=0, metric-value in PCReq may be used to report the cost of a  
reoptimized TE LSP or =0
	When B=0, metric-value in PCRep is used to report the cost of the  
computed path if C=1

11) One Object-Type for the LSPA object (with affinity) rather than two.

12) Clarified that the reception of a malformed message, the system  
sends a CLOSE message, releases the PCEP resources and closes the TCP  
connection.

Reason field (CLOSE object=4): Reception of a malformed PCEP message

11) We had defined the following PCEP Error:

Error-Type    Meaning
    1          PCEP session establishment failure
                Error-value=1: reception of a malformed Open message

In the FSM:

If an error is detected (e.g. malformed 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.

A malformed Open message is no different than any other type of  
malformed PCEP message => CLOSE object with reason=4.

12) Appendix A
Appendix A.  Compliance with the PCECP Requirement Document

    The aim of this section is to list the set of requirements set forth
    in [RFC4657] that are not satisfied by the current revision of this
    document.  This only concerns the requirements listed as MUST
    according to [RFC2119].

    Here is the list of currently unsatisfied requirements:

    o  Allow to select/prefer from advertised list of standard objective
       functions/options

    o  Allow to customize objective function/options

    o  Support "unsynchronized" & "synchronized" objective functions

=> The related work will be covered in a separate ID that will  
discuss those requirements + IGP PCED extensions and PCEP extensions  
since these functions are not required for the base protocol  
specification.

    o  Protocol recovery support resynchronization of information &
       requests between sender & receiver.

=> The document has been updated to address this requirement. The  
resynchronization of information
between the PCC and the PCE will be handled by retransmission.

"If the PCEP session is torn down, the system releases the PCEP  
resources for that PCEP peer, closes the TCP connection and moves to  
the Idle State.
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"

Why ?
Full state recover may be a requirement in *some* context, at the  
price of drastically increase the FSM complexity; there are also many  
contexts (stateless PCE) where retransmitting is not only  
significantly more simple but may even be much faster.

No decision was taken by the WG as to whether work is needed on this  
particular item but it would be covered in a separate ID.

Thanks.

JP.

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce