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

[Carmine Daloia <[e-mail]>]

Hi Sudheer,

See inline.

Thanks
Carmine

Sudheer Dharanikota wrote:

> Hi Carmine:
>
> Carmine Daloia wrote:
>
>> 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?
>>  
>>
> YOur solution precludes local restoration options.


No it doesn't. For local restoration options (I assume you mean 
span/link restoration) the tail-end and head-end nodes of the 
protection/restoration domain are the adjacent cross-connects. So as I 
said before, the signaling to determine if a fault occurred within a 
protection/restoration domain and then initiate a switch takes place 
between the head-end and tail-end nodes of a protection/restoration 
domain. This domain could be a span/link or an end-to-end path.

> Cheers,
>
> sudheer
>
>>  
>> 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: [phone] Ext 287
>>> fax: [phone]
>>>
>>>     -----Original Message-----
>>>     From: Carmine Daloia [mailto:[e-mail] ]
>>>     Sent: Wednesday, November 21, 2001 8:29 AM
>>>     To: Carmine Daloia
>>>     Cc: Jonathan Lang; [e-mail] ; [e-mail] ;
>>>     [e-mail]
>>>     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:[e-mail]]
>>>>>>Sent: Monday, November 19, 2001 6:44 AM
>>>>>>To: [e-mail]
>>>>>>Cc: [e-mail]; [e-mail]
>>>>>>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
>>>>>>