Re: [T1X1.5] Re: Suppression of Downstream Alarms...
Carmine Daloia <daloia@lucent.com> Wed, 21 November 2001 14:22 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 21 Nov 2001 06:20:52 -0800
Message-ID: <3BFBB8B9.9000302@lucent.com>
Date: Wed, 21 Nov 2001 09:22:49 -0500
From: Carmine Daloia <daloia@lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: George Young <george.young@meriton.com>
CC: ccamp@ops.ietf.org
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
Content-Type: multipart/alternative; boundary="------------020802070302010102080307"
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-prot-issues-00.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