Subject: Comments on draft-li-ccamp-confirm-data-channel-status-00

From: Dan Li <[email-masked]>
Date: Wed, 07 Feb 2007 15:35:18 +0800

Hi,

We have received many comments on this draft, some optional solutions also proposed for detecting the data channel mismatch status, here we try to summarize these options and what's our understanding:

1. Use BeginVerify and BeginVerifyAck Messages

The data channel mismatch situation also can be detected by using the BeginVerify and BeginVerfyAck Messages. 
Whenever the "available" side wants to determine whether any data channel mismatches exist it starts an LMP verification process. [RFC4204] states:
Therefore, to ensure proper verification of data link
connectivity, it is required that, until the data links are
allocated for user traffic, they must be opaque (i.e., lose
their transparency). To support various degrees of opaqueness
(e.g., examining overhead bytes, terminating the IP payload,
etc.) and, hence, different mechanisms to transport the Test
messages, a Verify Transport Mechanism field is included in
the BeginVerify and BeginVerifyAck messages."

This means that when data links are de-allocated they should re-enter that opaque state.
The issue is that the BeginVerify does not exchange DATA LINK but LINK objects (there is no flags in the former) hence the only reply you would receive is "unwilling to verify" while ideally you should receive "unwilling to verify (allocated)" such as the other side can map it with local knowledge and detect the mismatch.

[dan] Right, so it would be necessary to extend the BeginVerify to include a list of DATA LINKs (as we have done in our new messages) presumably as sub-information of the LINK so that all data links associated with the link are confirmed at the same time.
The really big issue I have with this is that Verify is a destructive process. That is, you can use your confirm process described in the previous section while data is passing, but the Verify process requires that the data links are opaque. I think that this means that it is not an acceptable option.

2. Use Fault Management Messages

Per [RFC4204], LMP supports the possibility to signal the status of a data channel using the Fault Management procedures. The ChannelStatusRequest message is ued by one end of a data channel to request that the other end sends back a report on its view of the status of the data channel in a ChannelStatus message. The ChannelStatus message includes a CHANNEL_STATUS object to list each reported data channel by giving its interface identifier and a numeric status value. The ChannelStatusRequest message may ask for the status of more than one data channel by including a list of interface identifiers, but cannot include the sender's status.
The possible status of the data channel currently reported in the CHANNEL_STATUS object are:
o          Signal Okay (OK): Channel is operational
o          Signal Degrade (SD): A soft failure caused by a BER exceeding a preselected threshold.  The specific BER used to define the threshold is configured.
o          Signal Fail (SF): A hard signal failure including (but not limited to) loss of signal (LOS), loss of frame (LOF), or Line AIS.
So we can extend the channel status values to indicate the cross-connection status of the Data Channel. By exchanging the Data Channel Status between the two ends of the data link, we can find the data channel mismatches if there are some.

[dan] This is possible, but has a backwards compatibility issue because the field is a number not a bit-field. It is not possible to continue to represent the existing statuses as well as the new statuses. A better solution, therefore, would be to add a new object to the message.
[dan] It is also the case that this mechanism requires and additional message exchange for both ends to know that the link is correctly operational.

Best regards,

Dan Li

Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972910
Fax: +86-755-28972935
***************************************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
***************************************************************************************