RE: Localizing Fault for Protection/Restoration

[Jonathan Lang <jplang@calient.net>]

Carmine,
  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: Carmine Daloia [mailto:daloia@lucent.com]
> Sent: Monday, November 19, 2001 11:24 AM
> To: ccamp
> Cc: tsg15q9@itu.int; t1x15@t1.org
> Subject: LMP: Localizing Fault for Protection/Restoration
> 
> 
> Hi all,
> 
> Another issue that is addressed in Section 6 "Fault Management" is the 
> determination of whether a detected defect is due to a fault within a 
> Protection/Restoration subnetwork or outside the subnetwork. The 
> following text is included in Section 6.2, "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).... 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 has been localized, the signaling protocols 
> can be used to initiate span or path protection/restoration 
> procedures."
> 
> I think we need to specify which protection/restoration architectures 
> such a ChannelStatus message would be applicable. All I currently see 
> are boxes and lines, yet we don't know at what layer the 
> protection/restoration is being performed nor do we know what type of 
> monitoring is supported (e.g., non-intrusive monitoring, tandem 
> connection monitoring, etc.). I am not saying that such a mechanism 
> would not be needed, however I think it is more fundamental to agree on 
> the architectures first before we attempt to agree on one particular 
> message that may be needed in some of the architectures. In fact the 
> ChannelStatus message (if specified) should be included in those 
> protection/restoration documents that specify architectures that would 
> require such a message. Note that the ChannelStatus message is actually 
> a message that is communicated between the end-points of a 
> protection/restoration subnetwork. The end-points of a 
> protection/restoration subnetwork could be adjacent cross-connects if 
> span protection/restoration is supported or the end-points could be 
> non-adjacent cross-connects if path protection/restoration is supported. 
> Lumping this ChannelStatus message into LMP automatically forces the 
> end-points to be adjacent cross-connects.
LMP is a "link management protocol" that is designed to manage links between
peers  (this is particularly useful when the interface over which the
control messages are sent/received may not be the same interface over which
the data flows).  As such, it is not clear to me why you are proposing to
run LMP end-to-end across multiple cross-connects.

> 
> Also, the paragraph that I quoted above indicates that once the failure 
> has been localized using the procedures described in LMP, the signaling 
> protocols can be used to initiate span or path protection/restoration. 
> Note that for path protection/restoration, the cross-connects themselves 
> are included within the protection/restoration subnetwork and therefore 
> path protection/restoration needs to restore connections when 
> cross-connects themselves fail. I don't see how the mechanism described 
> in LMP can be used when a cross-connect fails. Assume the network 
> consists of four cross-connects.
> 
>        A------B------C
>         |                      |
>        +------D------+
> 
> Let's assume that cross-connect B fails. According to the mechanism 
> described in LMP, Cross-connect C will send a ChannelStatus back to 
> Cross-connect B, however because B has failed, B will not be able to 
> process the ChannelStatus message. Therefore I don't see how 
> LMP would 
> apply to path protection/restoration.
Path protection/restoration can be initiated due to link or node failures.
The ChannelStatus message is used to isolate link failures.  Node failures
can be detected by the loss of the control channels (possibly in conjunction
with the loss of data channels).  This should be detected at both A and C.

> 
> Carmine
> 
>