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:
3BFBC4D4.24C77151@nayna.com">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.
3BFBC4D4.24C77151@nayna.com">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: +1 613-270-9279
Ext 287
fax: +1 613-270-9268
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:
3BFBA9CC.1060609@lucent.com" type="cite">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:
C12BBE1C7A8F7344808CD8C2A345DFB8455B10@pulsar.chromisys.com" type="cite">
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 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
|