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 > > > > > >
- Re: FW: [T1X1.5] Re: Suppression of Downstream Al… Carmine Daloia
- FW: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… Jonathan Lang
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- RE: [T1X1.5] Re: Suppression of Downstream Alarms… George Young
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Dimitri Papadimitriou
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Maarten Vissers
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Sudheer Dharanikota
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Dimitri Papadimitriou
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Sudheer Dharanikota
- Re: Suppression of Downstream Alarms... Sudheer Dharanikota
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: [T1X1.5] Re: Suppression of Downstream Alarms… Carmine Daloia
- Re: Suppression of Downstream Alarms... Carmine Daloia
- Re: Suppression of Downstream Alarms... Germano Gasparini
- RE: Suppression of Downstream Alarms... neil.2.harrison
- RE: Suppression of Downstream Alarms... Jonathan Lang
- RE: Suppression of Downstream Alarms... Malcolm Betts