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

Jonathan Lang <jplang@calient.net> Wed, 21 November 2001 18:20 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 21 Nov 2001 10:30:16 -0800
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8455B21@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: 'Carmine Daloia' <daloia@lucent.com>, Sudheer Dharanikota <sudheer@nayna.com>
Cc: ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org
Subject: RE: [T1X1.5] Re: Suppression of Downstream Alarms...
Date: Wed, 21 Nov 2001 10:20:53 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Carmine,
  Please see comments inline.

Thanks,
Jonathan

<snip>
Carmine Daloia wrote: 
Sudheer, 
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. 

[Sudheer] 
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).

[Carmine]
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.

[Jonathan]
LMP fault management can stand on its own without LMP-WDM.  My point in
bringing up LMP-WDM was to address the question you had a couple (hundred?)
emails ago about interaction with line systems.  In fact, there are
applications where LMP can be run between switches on the trunk side as well
(with no OLS in between).

[Sudheer]
2. Communication between cross connects 
THis is needed to localize a fault which in turn can be used as a trigger
for local 
restoration.

[Carmine]
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.

Will this duplication cause major issues in a network. I doubt it... but it
just doesn't seem right from an architecture perspective.

[Jonathan]
I'm not sure there is the architectural overlap that you claim.  There are
many protection domains involved.  There are protection domains within the
OLS.  There are protection domains between OXC and OLS.  There are
protection domains between adjacent OXCs.  There are protection domains
between non-adjacent OXCs.  Each domain has it's own requirements
(transport, timing, etc.), so I don't think it's appropriate to define
protection in only one protocol.


  
- 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:daloia@lucent.com]Sent: Monday, November 19, 2001 6:44 AMTo:
ccamp@ops.ietf.orgCc: tsg15q11@itu.int; t1x15@t1.orgSubject: 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 ChannelStatus 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 downstream.
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
OLIRequirements
document(http://search.ietf.org/internet-drafts/draft-many-oli-reqts-00.txt)
andcorresponding LMP-WDM protocol document (new version to be
uploadedtomorrow, but old version can be found
athttp://search.ietf.org/internet-drafts/draft-fredette-lmp-wdm-02.txt).
Any other views?Carmine