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

[Sudheer Dharanikota <[e-mail]>]

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