RE: [T1X1.5] Re: Suppression of Downstream Alarms...

Jonathan Lang <jplang@calient.net> Wed, 21 November 2001 17:20 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 21 Nov 2001 09:29:21 -0800
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8455B1E@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: 'George Young' <george.young@meriton.com>, Carmine Daloia <daloia@lucent.com>
Cc: ccamp@ops.ietf.org
Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
Date: Wed, 21 Nov 2001 09:20:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

George,
  This note makes a lot of sense.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:george.young@meriton.com]
> Sent: Wednesday, November 21, 2001 6:37 AM
> To: Carmine Daloia
> Cc: ccamp@ops.ietf.org
> Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
> 
> 
> Hello Carmine,
>  
> For span protection, LMP can stand on its own, localizing the fault,
making sure
> that both ends of the fault span know about the failure.
>  
> In a transparent network (which is where my company is focused), the node
at the receive
> end of a faulty link, and any nodes downstream (in the data flow
direction) become aware 
> of the fault, so one end of the path knows almost immediately.
>  
> For path protection, there would still be a need for signalling to the
other end. The benefit 
> of using LMP to localize the fault, is that only one node need initiate
> the signalling to the 
> head and the tail of the connection to toggle to the backup path.
>  
> Regards,
> George R. Young
> Meriton Networks Inc. 
> 329 March Rd., Kanata, ON, Canada, K2K 2E1 
> phone: +1 613-270-9279 Ext 287 
> fax: +1 613-270-9268 
> 
> -----Original Message-----
> From: Carmine Daloia [mailto:daloia@lucent.com]
> Sent: Wednesday, November 21, 2001 9:23 AM
> To: George Young
> Cc: ccamp@ops.ietf.org
> Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
> 
> 
> Hi George,
> 
> Thanks for the pointer to your draft. I will definitely read over it.
> Just looking at it quickly and understanding what is in LMP, it seems
> that even under path protection/restoration, there is an intermediate
> node that detects a failure (and localizes the failure to ensure that
> the failure occured on that particular link) and then signals over the
> control plane to the head-end and tail-end nodes of the
> protection/restoration domain to initiate protection/restoration.
> 
> It seems to me that the tail-end and head-end nodes 
> themselves would be
> able to detect the defect in the transport/user plane since the defect
> occured between the two ends and they can then coordinate 
> switching for
> protection/restoration without having to wait for any notification
> message sent from an intermediate NE.  This should improve the
> protection/restoration time since the head-end and tail-end won't need
> to wait for intermediate nodes to localize a fault and then 
> signal over
> a control plane requesting a proteciton/restoration switch. Any
> thoughts?
> 
> Thanks
> Carmine
> 
> George Young wrote:
> 
> 
> Hello Carmine,
>  
> Meriton Networks intends to use LMP as a fault localization 
> mechanism in
> a network of
> our transparent optical switches, currently in the 
> pre-production phase.
>  
> I've done some discrete event simulation work to characterize the
> performance of an IP
> network in support LMP management signals, and the resulting 
> signalling
> messages needed
> to initiate protection/restoration, and based on the results, have not
> seen any need to change 
> our design direction.
>  
> I've also written and submitted an IETF draft 
> http://search.ietf.org/internet-drafts/draft-young-opt-nni-pro
> t-issues-0
> 0.txt 
> dealing with the importance of control network performance, 
> particularly
> when extended across 
> multiple networks, and would appreciate any comments you might have.
>  
> Regards,
> George R. Young
> Meriton Networks Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> -----Original Message-----
> From: Carmine Daloia [ mailto:daloia@lucent.com]
> Sent: Wednesday, November 21, 2001 8:29 AM
> To: Carmine Daloia
> Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org
> Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
> 
> 
> Jonathan,
> 
> Forgot to mention, that the performance aspects of carrying OAM type
> signals over an IP based control channel in LMP-WDM would have to be
> analyzed. It is possible that the IP Control Channel will not provide
> fast enough transfer to actually suppress downstream alarms, however
> that needs to be analyzed as part of LMP-WDM.
> 
> Thanks
> Carmine
> 
> Carmine Daloia wrote:
> 
> 
> Jonathan,
> 
> The LMP-WDM document specifies the signaling between the Cross-connect
> and OLS, assuming they are from different vendors. If they are from
> different vendors, then a standard interface is needed to 
> exchange some
> information. One type of information that would need to be 
> exchanged is
> some OAM signals. Maarten described some of these signals in his VBI
> document. However, I don't see why OAM signals would have to be
> exchanged directly between the cross-connects themselves via LMP.
> 
> Let's look at the following network.
> 
> OXC1 --- OLSA --- OXC2 --- OLSB --- OXC3 --- OLSC --- OXC4
> 
> Note that the OLS consists of DWDM Mux/Dmux Terminals and Optical
> Amplifiers.
> 
> Let's assume a failure on OLSA. OLSA via overhead within an OSC
> suppresses alarms within OLSA. OAM messages (e.g., Optical 
> Channel FDI)
> could be carried over the LMP-WDM control channel to OXC2. OXC2 will
> have to forward the FDI signals downstream over the LMP-WDM control
> channel to OLSB. OLSB will then forward these FDI signals over its OSC
> and then over the LMP-WDM control channel to OXC3..... etc...
> 
> Note that OXC2 does not need to directly forward these FDI signals to
> OXC3. So it is possible, that in LMP-WDM, we may need to 
> define messages
> corresponding to FDI signals to suppress downstream alarms, however we
> don't need to define such messages in LMP.
> 
> Thanks
> Carmine
> 
> Jonathan Lang wrote:
> 
> 
> Carmine,
>   Please see inline.
> 
> Thanks,
> Jonathan
> 
> 
> -----Original Message-----
> From: Carmine Daloia [ mailto:daloia@lucent.com]
> Sent: Monday, November 19, 2001 6:44 AM
> To:  ccamp@ops.ietf.org
> Cc:  tsg15q11@itu.int;  t1x15@t1.org
> Subject: LMP: Suppression of Downstream Alarms...
> 
> 
> Hi all,
> 
> As I read through Section 6 "Fault Management", one issue 
> that it seems 
> to be addressing is "Suppression of Downstream Alarms".
> 
> In section 6.2, it states that "If data links fail between 
> two PXCs, the
> 
> power monitoring system in all of the downstream nodes may detect LOL 
> and indicate a failure. To avoid multiple alarms stemming 
> from the same 
> failure, LMP provides a failure notification through the
> 
>  Cha
> nn
> elStatus 
> message...".
> 
> I agree that the suppression of downstream alarms is an 
> important issue.
> 
> great!
> 
> 
> If we look at standard networks (both SONET/SDH and OTN), this 
> capability is already provided by the overhead in SDH/SONET and G.709 
> OTN. G.709 OTN handles suppression of alarms in both all-optical 
> networks as well as opaque networks. I don't think we need to 
> burden the
> 
> control plane with such functions when the transport plane 
> handles this 
> in standard networks. In fact the transport plane handles 
> suppression of
> 
> alarms on all equipment in the network (not just cross-connects).
> 
> If we look at a pre-OTN ("non-standard") scenario consisting of 
> Cross-connects, Optical Line Systems, and Optical Amplifiers 
> supporting 
> a DWDM networked solution, we can analyze two scenarios. One 
> scenario is
> 
> an opaque network (e.g., the OLS supports 3R). In this scenario, the 
> downstream Cross-connects would not detect LOL upon faults occurring 
> upstream. The 3R points on the OLS Line Systems would insert 
> some type 
> of signal
> 
>  dow
> ns
> tream. Therefore the mechanism described in Section 6.2 
> does not apply. Another scenario is an all-optical pre-OTN 
> network. Note
> 
> that other equipment besides Cross-connects (e.g., Optical 
> Amplifiers) 
> in an all-optical network may alarm due to upstream faults. 
> These alarms
> 
> also need to be suppressed. LMP seems to only address the 
> suppression of
> 
> downstream alarms on cross-connects without taking into consideration 
> the network that sits between the cross-connects. Is LMP also 
> expected 
> to have to be processed on Optical Amplifiers? This seems to be 
> undesirable, especially given all the various applications 
> that seem to 
> be included into the LMP protocol that would not have anything to do 
> with Optical Amplifieris.
> 
> For interaction between cross-connects and Line Systems, 
> please see OLI
> Requirements document
> ( http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt)
> and
> corresponding LMP-WDM protocol document (new version to be uploaded
> tomorrow, but old version can be found at
> http://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).
> 
> 
> Any other views?
> 
> Carmine
> 
> 
> 
> 
> 
>