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

[Sudheer Dharanikota <[e-mail]>]

Hi Carmen:

It is common to deploy a local restoration for faster
recovery for some faults
(such as fiber cut) and end-to-end recovery for little
slower recovery for
faults such as node failures.

In such a scenario... what do you mean by head-end and
tail-end :-)

Cheers,

sudheer


Carmine Daloia wrote:

> 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.txtdealing
>> >>  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 Do
>> >>      >> > wnstream 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 fail
>> >>      >> > ure 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 poin
>> >>      >> > ts 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
>> >>      >> >
>> >>      >> >