Re: LMP-WDM - Link Group IDs in Fault Localization

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Duncan,

I didn't see an answer to your question.

> I have a question on an aspect of behaviour relating to Link Group IDs
> in fault localization in LMP-WDM.
>
> The LMP-WDM spec section 2.4 states the following:
>
>      Each data link is identified by an Interface_ID. In addition, a
Link
>      Group ID may be assigned to a group of data links (see Section
>      2.3.1). The Link Group ID may be used to reduce the control traffic
>      by providing channel status information for a group of data links.
A
>      new LINK GROUP CHANNEL_STATUS object is defined below for this
>      purpose. This object may be used in place of the CHANNEL_STATUS
>      objects described in [RFC4204] in the ChannelStatus message.
>
> This specifies that the Link Group IDs may be present in ChannelStatus
> messages but not the ChannelStatusRequest message.
>
> So say we send a ChannelStatus message containing a Link Group ID to the
> upstream node.  If an Ack is not received or we do not receive a
> corresponding ChannelStatusMessage result then when we prompt the
> upstream node with a ChannelStatusRequest message we need to use the
> interface ids of the datalinks contained in the Link Group ID rather
> than the Link Group ID itself.
>
> Is this the intended behaviour ?

I think the intention is purely to reduce the traffic when there is a
failure of a group of data links that are likely to fail together
(presumably because of a component failure). That is, to allow the
detecting component to send a single ChannelStatus message reporting the
group of failed links. Thus, the 4209 documents its use only on the
ChannelStatus message.

Your question raises a couple of points.
1. Link Group ID is not to be used on a ChannelStatusAck because it
  is not needed. The Ack contains a message ID to correlate with the
  ChannelStatus.
2. If an Ack is not received then something is badly broken since the
  receiver of a ChannelStatus message MUST send an Ack, and since
  the message transfer is reliable.
3. If the downstream node (originator of the ChannelStatus message)
   does not receive a ChannelStatus message from upstream indicating
   that the error has been correlated, then it is allowed to prompt with
   a ChannelStatusRequest. It is a good question whether this request
   should enquire about a Link Group or about individual links.
   The same question might have been asked about the indication of
   the failure of all data links that make up a TE link (see RFC4204
   section 6.2). Here we can only indicate the entire TE link on a
   ChannelStatus message. We can't do it on a ChannelStatusRequest
   or Response.
   I would say that where there is ambiguity and the implementations are
   not operating optimally (i.e. not sending ChannelStatus upon
correlation
   of the error) we should fall back to basic processing of each data link
   in turn. This scenario constitutes an error condition (in the software
   component) and we do not need to optimise the protocol for that case.

Does that answer?
Cheers,
Adrian