RE: LMP Question: fault management messages

[Jonathan Lang <jplang@calient.net>]

Sameh,
  To address George's comment, we plan to modify the text as follows  (new
text in <<text>>):

Section 6.2 Fault Localization Procedure

...

As part of the fault localization, a downstream node (downstream in terms of
data flow) that detects data link failures will send a ChannelStatus message
to its upstream neighbor <<indicating that a failure has occurred>>
(bundling together the notification of all of the failed data links).  An
upstream node that receives the ChannelStatus message MUST send a
ChannelStatusAck message to the downstream node indicating it has received
the ChannelStatus message.  The upstream node should correlate the failure
to see if the failure is also detected locally (including ingress side) for
the corresponding LSP(s).  If, for example, the failure is clear on the
input of the upstream node or internally, then the upstream node will have
localized the failure.  <<Once the failure is correlated, the upstream node
SHOULD send a ChannelStatus message to the downstream node indicating that
the channel is failed or is ok.  If a ChannelStatus message is not received
by the downstream node, it SHOULD send a ChannelStatusRequest message for
the channel in question.>>  Once the failure has been localized, the
signaling protocols can be used to initiate span or path
protection/restoration procedures.

Thanks,
Jonathan

> -----Original Message-----
> From: Sameh M. Elsharkawy [mailto:selsharkawy@fwion.com]
> Sent: Friday, October 19, 2001 12:46 PM
> To: ccamp@ops.ietf.org
> Subject: RE: LMP Question: fault management messages
> 
> 
> 
> I fully agree with this comment since the removal of ChannelFailNack
message
> from the fault management procedure prevent downstream nodes from
localizing
> the failure on their input ports. If signaling is responsible for
> propagating the information, this will delay the recovery process, until
the
> information   is disseminated by signaling.
> 
> Thanks
> 
> Sameh M. Elsharkawy
> Senior Member of Technical Staff
> FirstWave Intelligent Optical Networks
> 6301 Ivy Lane, Suite 700, Greenbelt, MD 20770
> (301) 345-2137 x1034
> 
> 
> 
> -----Original Message-----
> From: George Young [mailto:george.young@edgeflow.com]
> Sent: Tuesday, October 09, 2001 1:57 PM
> To: ccamp@ops.ietf.org
> Subject: LMP Question: fault management messages
> 
> 
> I've reviewed draft-ietf-ccamp-lmp-01.txt and the new ChannelStatus
> message and its friends.
> 
> In Section 6.2. Fault Localization Procedure, LMP states "Once the
> failure has been localized, the signaling protocols can be used to
> initiate span or path protection/restoration procedures". This is
> workable and signalling can reroute around the link or the path,
> releasing resources as appropriate. However, with the departure of the
> ChannelFailNack, the node at the receive end of the faulty 
> link does not
> find out about the fault from either the signalling protocol 
> or LMP. As
> bidirectional paths are allocated, there is a chance that the failed
> link will be allocated to a subsequent call through this node.
> 
> Furthermore, assuming a signalling protocol has established paths, and
> indicated their active or backup status with the Administrative Status
> object in GMPLS, there does not appear to be any need in LMP for the
> Active/Deactive indications in the CHANNEL_STATUS object. This
> information has already been conveyed by the signalling 
> protocol during
> path establishment.  
> 
> If my understanding is correct, ChannelFailNack functionality 
> is needed
> and the Active and Deactive values of the CHANNEL_STATUS 
> object are not.
> 
> Regards,
> George R. Young
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
>