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

[Carmine Daloia <[e-mail]>]

Hi Sudheer,

My last comment wasn't meant to be an argument :-)

Maybe if I propose some text specific to the suppression of downstream 
alarms that would help clarify the scope of applicability. The text 
would state that when client devices (e.g., SONET/SDH cross-connects, IP 
routers) are interconnected via a standard OTN network then the 
suppression of downstream alarms is already handled in the 
transport/user plane via the OTN overhead (both in-band via the digitial 
overhead as well as out-of-band via non-associated overhead). Also the 
text would address PXCs within a standard OTN network. In this case, 
again the suppression of downstream alarms is handled via the OTN overhead.

The implementation proposed in LMP for suppression of downstream alarms 
applies to PXCs or client devices (e.g, SONET/SDH cross-connects or IP 
routers) interconnected via a non-standard DWDM network. In this case, 
it is assummed that the non-standard DWDM network does not provide the 
neccesary overhead within the transport/user plane to suppress alarms on 
PXCs and client devices and therefore LMP provides a mechanism to carry 
such alarm suppression messages in the control plane.

I'll take a crack at specific text so that the group can review it. Does 
this sound like something that would be helpful.

Thanks
Carmine

Sudheer Dharanikota wrote:

> Hi again:
>
> Carmine Daloia wrote:
>
>>>>  
>>>> I am not assuming inband communication is supported between the 
>>>> cross-connect and the line system. That is why I said that when the 
>>>> PXC and line system are from different vendors such OAM signals 
>>>> would have to be carried over a separate channel (e.g., LMP-WDM 
>>>> control channel). However, I don't see why such signals would have 
>>>> to be carried over an LMP control channel between cross-connects. 
>>>> Also, my point about performance was that we would have to see if 
>>>> the LMP control channel would meet the performance requirements for 
>>>> such OAM signals. It very well might. If not, a bit-oriented 
>>>> signaling interface may be needed between the PXC and the line system.
>>>>  
>>>
>>> Ok Let us address the issues separately...
>>>
>>> 1. Communication between Line System and Cross connect
>>>
>>> Defining a bit-oriented (physical) interface and protocol is not 
>>> really the task (in my opinion)
>>> of IETF.
>>> I am not sure if are creating a problem to solve with the alarm 
>>> suppression.
>>> Let me explain...
>>>
>>> Let us assume we can correlate and suppress the alarms between the 
>>> Line systems
>>> and corss connects. Then we donot need an elaborate bit-oriented 
>>> protocol. This
>>> has an assumption that we are talking about not hundereds of 
>>> failures but a couple of
>>> failures (for example fiber cuts).
>>
>> As I said, I am not suggesting that we need a bit-oriented protocol. 
>> My main point was that for the communication between the line-system 
>> and cross-connect, we need to understand the applications that 
>> require such communication and the requirements for those 
>> applications. It may be that the requirements can be met by carrying 
>> messages over IP (e.g., LMP-WDM). This is an issue for LMP-WDM and 
>> not for LMP (i.e., running between cross-connects) anyway. So for the 
>> sake of focusing some of this discussion let me suggest we focus on 
>> communication between the adjacent cross-connects and we can even 
>> assume that LMP-WDM handles the Cross-connect and Line System 
>> communication.
>
> Agreed we need to focus on LMP not DWDM-LMP :-) But...
> the intention of the OLI document was to underdstand the requirements.
> I thought most of us vouch for these requirements. Let us put the
> requirements in the back-burner. If it is bit-oriented protocol it
> does not interest most of us :-)
>
>>  
>>
>>> 2. Communication between cross connects
>>>
>>> THis is needed to localize a fault which in turn can be used as a 
>>> trigger for local
>>> restoration.
>>>
>> Localize a fault for what reason? To understand if the fault is 
>> within the protection/restoration domain. For span 
>> protection/restoration the end-points of the domain coincide with the 
>> LMP end-points. For end-to-end protection/restoration the end-points 
>> do not coincide with the LMP end-points. Because the end-points of a 
>> protection/restoration domain do not always coincide with the 
>> end-points of a LMP protocol, I don't think it is a good idea to lump 
>> messages related to protection/restoration in LMP. It will result in 
>> similar messages having to be defined in other protocols and 
>> therefore a duplication of work and processing.
>>  
>
> Again... span protection can be performed easily with the current
> mechanisms supported by LMP in out-of-band communication
> scenarios.
>
> In case of overlaping restoration scenarios such as span and end-to-end
> it is required to have a localization + an attempt to recover + (if 
> this fails)
> report to end-to-end entities for recovery. THis also vouch for the
> inclusion of such mechanisms in LMP.
>
>>  
>> Will this duplication cause major issues in a network. I doubt it... 
>> but it just doesn't seem right from an architecture perspective.
>>
>>>  
>>
> Well I guess I cannot buy this argument :-)
>
> Cheers,
>
> sudheer
>
>>>  
>>>  
>>>
>>> - sudheer
>>>
>>>>  
>>>> Thanks
>>>> Carmine
>>>>
>>>> Sudheer Dharanikota wrote:
>>>>
>>>>> Carmine...
>>>>>
>>>>> Again can you suggest a way to communicate such signals
>>>>> between line systems and cross connects when inband
>>>>> communication is not supported between these two systems?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> sudheer
>>>>>
>>>>> Carmine Daloia wrote:
>>>>>
>>>>>> 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 noti
>>>>>>>>>fication 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 th
>>>>>>>>>e 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
>>>>>>>>>