[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Localizing Fault for Protection/Restoration

Jonathan,

Please see comments inline.

Thanks
Carmine

Jonathan Lang wrote:
C12BBE1C7A8F7344808CD8C2A345DFB8455AE5@pulsar.chromisys.com"> 
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 
t
ogether 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.
My concern is that this ChannelStatus message is not really a part of the link management application but a part of the protection/restoration application. If protection/restoration was not provided why would such a message be needed in the upstream direction?

When protection/restoration architectures are defined, I believe it is possible that some of these architectures will need a type of ChannelStatus message that is described in LMP, however the message will be needed between the edges of the protection/restoration domain (which I agree could very well be a single link if span protection/restoration is performed - but not always). Note that the protection/restoration edges may not always coincide with the LMP protocol edges and therefore the protection/restoration application would need to define its own "ChannelStatus" message anyway since it cannot be sure LMP will be running between the same points as the protection/restoration application.

What are your thoughts?
C12BBE1C7A8F7344808CD8C2A345DFB8455AE5@pulsar.chromisys.com"> 


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 m
essage. 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