Dear all,

I’m currently working on a research project, called CARRIOCAS, which aims at providing dynamically reconfigurable high speed network for high-performance applications where PCEP is used for path computation. My work in the project is to do modeling, validation, verification, and testing of PCEP. PCEP was described in a formal language IF and some properties were validated. I have some questions that were found during my work. The questions will be posted in four separate emails including this one.

I found that there is a case that never happens in OpenWait state. Is there anybody who can give me any advice if I’m missing something? The detailed case is as follows.

In Appendix A, when a system in OpenWait state receives an Open message from its peer where no errors are detected, OpenRetry is 0, the session characteristics are unacceptable but negotiable, and LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state.

According to our experiments, we found that the above case cannot happen. We analyzed the reason and the result is as follows: we can have LocalOK=1 only when the system in KeepWait state receives a Keepalive message from its peer. Since the system can move to KeepWait state only after receiving an Open message from its peer in OpenWait state, the OpenRetry value is always more than 0 if we have LocalOK=1.

Thanks in advance!

    Iksoon

Dear all,

It seems that there are some problems in the explanation of Appendix A concerning with the Keepalive timer.

In section 4.2.1, Keepalive messages are used to acknowledge Open messages, and once the PCEP session has been successfully established.

In section 6.2, the PCEP session is considered as established once both PCEP peers have received a Keepalive message from their peer.

In Appendix A, if a system in OpenWait state receives an Open message from the PCEP peer before the expiration of the OpenWait timer, it performs collision resolution procedure. If there is no collision, no errors are detected in Open message, and the session characteristics are acceptable to the local system, the system:

   o  Sends a Keepalive message to the PCEP peer,

   o  Starts the Keepalive timer,

   o  Sets the RemoteOK variable to 1.

If LocalOK=0 the system clears the OpenWait timer, starts the KeepWait timer and moves to the KeepWait state.

The statement in section 4.2.1 and starting the Keepalive timer in OpenWait state when LocalOK=0 are contradictory because the system starts keepalive mechanism although the session is not established yet.

Also, it seems that there is another problem. In section 7.3, it is explained that "A sends an Open message to B with Keepalive=10 seconds and Deadtimer=40 seconds.  This means that A sends Keepalive messages (or any other PCEP message) to B every 10 seconds and B can declare the PCEP session with A down if no PCEP message has been received from A within any 40 second period". The Keepalive timer should follow the Keepalive value in the Open message that was sent to its peer (not the Keepalive value in the Open message received from its peer). Therefore, the Keepalive timer can be set only after the peer accepted the parameter values in the Open, i.e. only after the system receives a Keepalive message from its peer.

I think the Keepalive timer and the Deadtimer should be started when the system moves to SessionUP state. Is there anybody who can give me any advice?

Thanks in advance.

    Iksoon

Dear all,

According to section 7.15, if a PCEP peer detects an attempt from another PCEP peer to establish a second PCEP session, it MUST send a PCErr message with Error-type=9, Error-value=1.

In section 6.2, it is mentioned that once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message as specified in Appendix A. Any message received prior to an Open message MUST trigger a protocol error condition causing a PCErr message to be sent with Error-Type 'PCEP session establishment failure' and Error-Value 'reception of an invalid Open message or a non Open message' and the PCEP session establishment attempt MUST be terminated by closing the TCP connection.

Then, in such a case, we have to exchange PCErr messages and I’m wondering if it is necessary. I think it is better to mention that “once the TCP connection has been successfully established, the first message sent by the PCC to the PCE or by the PCE to the PCC MUST be either an Open message or an Error message. Any other message received … “.

Another question is that I’d like to know if it is appropriate to ignore the second connection. In case of connection oriented protocols, we may have resource mismatch problems, i.e. one assumes that a connection is already released while the other is still holding it. If the second connection is always ignored, we cannot have any connection between two peers before resource mismatch problem is resolved.

Thanks in advance.

    Iksoon

Dear all,

According to the Appendix A, if an Open message is received from its peer when the system is in KeepWait state, the system should abort the establishment procedure. In order to have a successful session establishment, in such a case, reply messages must be sent in the order the requests are received.

Isn’t it too strong condition? I think the order of reply messages may be changed in some cases so it might be better to allow the system to receive an Open message in KeepWait state.

Thanks in advance!

    Iksoon

Hello Iksoon,

> we can have LocalOK=1 only when the system in KeepWait state receives a Keepalive message from its peer

I guess your statement comes from the fact that the only place where it is said to set the LocalOK variable to 1 is in keepwait state:

However if you apply the definition of the LocalOk variable you must set the LocalOk variable to 1 each time you receive a positive acknowledgement

of the Open message, whatever is the current state (OpenWait or KeepWair).

More generally the state diagram described in PCEP draft must be carefully interpreted because of the independent Open/Keepalive message flow in opposite

direction which is managed with a single state.

But I agree that strictly speaking in the OpenWait state case there should be statement about the receipt of a KeepAlive message when LocalOk is 0.

Best regards

Fabien