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
>>>>
>>
>