Subject: [CCAMP] Data Link FSM for OTN.

From: Sirish Vadloori <[email-masked]>
Date: Sat, 18 Jun 2011 08:25:15 +0300

Hello Daniele,

This is about the "Link Verification" procedure for OTN specific ports.

According to RFC 4204's Passive LMP Data Link FSM - We move from "PasvTest" state to "Up/Free" state upon the trigger of an event 6 :evTestRcv: Test message was received over the data port and a TestStatusSuccess message is transmitted over the control channel.

This seems to be incomplete when it comes to testing an OTN specific port.

For Example:

1. We have two routers (R1 & R2) connected using an ODU1 port (Data Link) - which could be a combination of two ODU0s. One ODU0 could be from R1 to R2. Another one from R2 to R1. The combination of these two ODU0s will make one bi directional ODU1 data link.

2. Router R1 initiated the verification procedure for the data link ODU1 (The first ODU0 from R1 to R2 in fact). Moves the Data Link FSM to "Test" state.

3. Router R2 will be ready by acknowledging the verification procedure and moves the Data Link FSM to "PasvTest" state.

4. After the successful completion of the test procedure from R1 to R2, we really can't move the Data Link FSM state at router R2 from "PasvTest" state to "Up/Free" state. As the test procedure from R2 to R1 is not done yet (The second ODU0 from R2 to R1).

5. I think we need a modified data link FSM for OTN specific ports which could handle a case like this. We may need an another intermediate state between "PasvTest" and "Up/Free" states which could handle the testing procedure from R2 to R1 too and then upon the successful completion of the testing procedure - we could move the data link FSM state at router R2 to "Up/Free".

Please let me know your opinion on this and in case if my understanding is not correct, please correct me.

Best Regards,

-Sirish

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Julien Meuric <[email-masked]>
Date: Mon, 20 Jun 2011 11:57:27 +0200

Hi Sirish.

 From my understanding, what you describe rather looks like a router 
interconnection using 2 unidirectional ODU0 and I do not see what is 
missing in RFC 4204 procedures.
What is more, even if it might technically happen, I do not see 
operational networks actually provisioning bidirectional services over 
different unidirectional containers built on different timeslots. Why 
not using the same ODU0 in both directions? What about the full ODU1?

Cheers,

Julien

Le 18/06/2011 07:25, Sirish Vadloori a écrit :
> Hello Daniele,
>   
> This is about the “Link Verification” procedure for OTN specific ports.
>   
> According to RFC 4204’s Passive LMP Data Link FSM – We move from “PasvTest” state to “Up/Free” state upon the trigger of an event 6:evTestRcv: Test message was received over the data port and a TestStatusSuccess message is transmitted over the control channel.
>   
> 1.  We have two routers (R1&  R2) connected using an ODU1 port (Data Link) – which could be a combination of two ODU0s. One ODU0 could be from R1 to R2. Another one from R2 to R1. The combination of these two ODU0s will make one bi directional ODU1 data link.
> 2.  Router R1 initiated the verification procedure for the data link ODU1 (The first ODU0 from R1 to R2 in fact). Moves the Data Link FSM to “Test” state.
> 3.  Router R2 will be ready by acknowledging the verification procedure and moves the Data Link FSM to “PasvTest” state.
> 4.  After the successful completion of the test procedure from R1 to R2, we really can’t move the Data Link FSM state at router R2 from “PasvTest” state to “Up/Free” state. As the test procedure from R2 to R1 is not done yet (The second ODU0 from R2 to R1).
> 5.  I think we need a modified data link FSM for OTN specific ports which could handle a case like this. We may need an another intermediate state between “PasvTest” and “Up/Free” states which could handle the testing procedure from R2 to R1 too and then upon the successful completion of the testing procedure – we could move the data link FSM state at router R2 to “Up/Free”.
>   
> This e-mail message is intended for the recipient only and contains 
> information which is CONFIDENTIAL and which may be proprietary to ECI 
> Telecom. If you have received this transmission in error, please 
> inform us by e-mail, phone or fax, and then delete the original and 
> all copies thereof.
>
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Sidd Aanand <[email-masked]>
Date: Mon, 20 Jun 2011 06:05:08 -0400

Julien,

I think the question is more at the OTU level. If an OTU port (data link) is able to receive and correctly process the Test message, the current RFC says that it can move from PasvTest to Up state and announce itself to rest of the routers as available for carrying LSPs. However, isn't it required for the same port to go through an ActiveTest state as well?

Thanks,
Sidd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Meuric
Sent: Monday, June 20, 2011 3:27 PM
To: Sirish Vadloori
Cc: [email-masked]
Subject: Re: [CCAMP] Data Link FSM for OTN.

Hi Sirish.

Cheers,

Julien

Le 18/06/2011 07:25, Sirish Vadloori a écrit :
> According to RFC 4204's Passive LMP Data Link FSM - We move from "PasvTest" state to "Up/Free" state upon the trigger of an event 6:evTestRcv: Test message was received over the data port and a TestStatusSuccess message is transmitted over the control channel.
>   
> 1.  We have two routers (R1&  R2) connected using an ODU1 port (Data Link) - which could be a combination of two ODU0s. One ODU0 could be from R1 to R2. Another one from R2 to R1. The combination of these two ODU0s will make one bi directional ODU1 data link.

---

From: Julien Meuric <[email-masked]>
Date: Mon, 20 Jun 2011 18:29:18 +0200

Hi Sidd.

 From the LMP perspective, links are unidirectional (like within IGPs). 
Quoting section 5 of RFC 4204:
"Data links are tested in the transmit direction because they are 
unidirectional".

In other words, the state of one direction may be different from the 
state of the other direction. When a direction is (has been) tested, it 
is up to the receiving end node to start a test procedure on the other 
direction.

Regards,

Julien