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

Sudheer Dharanikota <sudheer@nayna.com> Wed, 21 November 2001 15:34 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 21 Nov 2001 07:43:00 -0800
Message-ID: <3BFBC983.D84D3696@nayna.com>
Date: Wed, 21 Nov 2001 07:34:27 -0800
From: Sudheer Dharanikota <sudheer@nayna.com>
MIME-Version: 1.0
To: Carmine Daloia <daloia@lucent.com>
CC: Jonathan Lang <jplang@calient.net>, ccamp@ops.ietf.org, tsg15q11@itu.int, t1x15@t1.org
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
Content-Type: multipart/mixed; boundary="------------BBFA08C5A8B1E8B78CEF630F"

Hi again:

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

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

2. Communication between cross connects

THis is needed to localize a fault which in turn can be used
as a trigger for local
restoration.


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