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

[Sudheer Dharanikota <[e-mail]>]

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.

Cheers,

sudheer

>
> Thanks
> Carmine
>
> George Young wrote:
>
>> Hello Carmine, Meriton Networks intends to use LMP as a
>> fault localization mechanism in a network
>> ofour transparent optical switches, currently in the
>> pre-production phase. I've done some discrete event
>> simulation work to characterize the performance of an
>> IPnetwork in support LMP management signals, and the
>> resulting signalling messages neededto 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. YoungMeriton 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 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
>>      >> >  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 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
>>      >> >
>>      >> >