[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: [T1X1.5] Re: Suppression of Downstream Alarms...
Carmine,
Thanks for the careful review of the document. We've incorporated many of
your comments. Specific responses pasted below: new text identified in
quotes after [Jonathan]
Thanks,
Jonathan
========================
Abstract
Future networks will consist of photonic switches, optical
crossconnects, and routers that may be configured with control
channels and data links. Furthermore, multiple data links may be
combined to form a single traffic engineering (TE) link for routing
purposes. This draft specifies a link management protocol (LMP) that
runs between neighboring nodes and is used to manage TE links.
Specifically, LMP will be used to maintain control channel
connectivity, verify the physical connectivity of the data-bearing
channels, correlate the link property information,
[Insert: suppress downstream alarms in pre-G.709 networks, and localize
faults in both opaque and transparent networks to a particular link
between adjacent cross-connects for protection/restoration actions.]
[Delete: and manage link failures. A unique feature of the fault management
technique is that it is able to localize failures in both opaque and
transparent
networks, independent of the encoding scheme used for the data.]
[Jonathan]"suppress downstream alarms, and localize link failures in both
opaque and transparent networks for protection/restoration purposes."
1. Introduction
<snip>
In GMPLS, the control channels between two adjacent nodes are no
longer required to use the same physical medium as the data-bearing
links between those nodes. For example, a control channel could use
a separate wavelength or fiber, an Ethernet link,
[Delete: or]
an IP tunnel through a separate management network
[Delete: .]
[Insert: , or a multi-hop IP network]
[Jonathan]"an IP tunnel through a separate management network, or a
multi-hop IP network."
2. LMP Overview
<snip>
In this draft,
[Delete: two]
[Insert: three]
additional LMP procedures are defined: link
connectivity verification
[Delete: and fault management]
[Insert: suppression of downstream alarms, and localization
faults in both opaque and transparent networks to a particular link
between adjacent cross-connects for protection/restoration actions]
.
[Delete: These procedures are particularly useful when the control
channels are physically diverse from the data-bearing links.]
[Jonathan] no change made.
Link connectivity
verification is used to verify the physical connectivity of the
data-bearing links between the nodes and exchange the Interface Ids;
Interface Ids are used in GMPLS signaling, either as Port labels or
Component Interface Ids, depending on the configuration. The link
verification procedure uses in-band Test messages that are sent over
the data-bearing links and TestStatus messages that are transmitted
back over the control channel. Note that the Test message is the
only LMP message that must be transmitted over the data-bearing
link.
[Delete: The fault management scheme uses]
[Insert: Both the suppression of downstream alarms and the localization
of faults for protection/restoration use]
ChannelStatus message
exchanges between adjacent nodes
[Delete: to localize failures]
in both opaque
and transparent networks, independent of the encoding scheme used
for the data. As a result, both local span and end-to-end path
protection/restoration procedures can be initiated.
[Jonathan]"Both the suppression of downstream alarms and the localization of
faults for protection/restoration use ChannelStatus message exchanges
between adjacent nodes in both opaque and transparent networks, indepedent
of the encoding scheme used for the data."
[Insert: Note that the fault localization scheme supported in LMP localizes
faults on a link and does not address node failures. Therefore additional
mechanisms are needed to detect node failures for end-to-end path
protection/restoration.]
[Jonathan]no change made.
[Delete: For the LMP link connectivity verification procedure, the free
(unallocated) data-bearing links MUST be opaque (i.e., able to be
terminated); however, once a data link is allocated, it may become
transparent.]
[Insert: For LMP link conncetivity verification procedure between adjacent
PXCs, the test message is generated and termindated by opaque test units
that
may be shared among multiple ports on the PXC. Opaque test units are needed
since the PXC ports are transparent.]
[Jonathan]change made as suggested.
<snip>
The LMP fault management procedure
[Insert: (i.e., the suppression of downstream alarms in pre-G.709 networks,
and the localization of faults to a particular link between adjacent OXCs
for
protection/restoration actions)]
is based on a ChannelStatus
exchange using the following messages: ChannelStatus,
ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse.
The ChannelStatus message is sent unsolicitated and is used to
notify an LMP neighbor about the status of one or more data channels
of a TE link.
[Jonathan]no change made.
3. Control Channel Management
<snip>
For the purposes of LMP, the exact implementation of the control
channel is not specified; it could be, for example, a separate
wavelength or fiber, an Ethernet link, an IP tunnel through a
separate management network,
[Insert: a multi-hop IP network,]
[Jonathan]change made.
<snip>
The control channel can be either explicitly configured or
automatically selected, however, for the purpose of this document
the control channel is assumed to be explicitly configured.
[Insert: The term configured means that the destination IP address to
reach the adjacent node on the far end of the control channel is known
at the near-end. The destination IP address may be manually configured,
or automatically discovered.]
[Jonathan]Replacing the above text starting with "The Control channel.."
with "To establish a control channel, the destination IP address on the far
end of the control channel must be known. This knowledge may be manually
configured or automaticaly discovered."
<snip>
Control channels exist independently of TE links and multiple
control channels may be active simultaneously between a pair of
nodes. Individual control channels can be realized in different
ways; one might be implemented in-fiber while another one may be
implemented out-of-fiber.
[Insert: Maintenance of control channels (i.e., detection of control
channel failures and restoral of communication) is needed. Various
mechanisms could be used to provide maintenance of control channels,
depending on the level of service required. For example, control channel
failures could be detected and restored via normal IP routing protocols,
however this may not support the necessary level of service due to the
time required to update the routing tables. For very fast recovery of
control channels, other mechanisms such as bridging messages at the near-end
and selecting messages at the far-end can be used. LMP defines a Hello
protocol that can be used to detect control failures. To support
the Hello protocol,]
[Delete: As such, ]
control channel parameters MUST
be negotiated over each individual control channel, and LMP Hello
packets MUST be exchanged over each control channel to maintain LMP
connectivity if other mechanisms are not available.
[Jonathan]no change
3.1. Parameter Negotiation
[Insert: Activation of the LMP Hello Protocol]
[Delete: Control channel activation]
begins with a parameter negotiation
exchange using Config, ConfigAck, and ConfigNack messages.
[Jonathan] no change. LMP control channel activation requires Config
message exchange even if LMP Hellos are not run.
<snip>
To begin
[Delete: control channel]
[Insert: Hello Protocol]
activation, a node MUST transmit a Config
message to the remote node.
[Jonathan] no change
3.2. Hello Protocol
Once
[Delete: a control channel]
[Insert: the Hello Protocol]
is activated between two adjacent nodes, the ...
[Jonathan]no change
5. Verifying Link Connectivity
[Question: The following paragraph is a bit confusing to me. What is the
problem
that it is trying to describe? Thanks :-)]
A unique characteristic of all-optical PXCs is that the data-bearing
links are transparent when allocated to user traffic. This
characteristic of PXCs poses a challenge for validating the
connectivity of the data links since shining unmodulated light
through a link may not result in received light at the next PXC.
This is because there may be terminating (or opaque) elements, such
as DWDM equipment, between the PXCs. Therefore, to ensure proper
verification of data link connectivity, it is required that until
the links are allocated for user traffic, they must be opaque. To
support various degrees of opaqueness (e.g., examining overhead
bytes, terminating the payload, etc.), and hence different
mechanisms to transport the Test messages, a Verify Transport
Mechanism field is included in the BeginVerify and BeginVerifyAck
messages. There is no requirement that all data links be terminated
simultaneously, but at a minimum, the data links MUST be able to be
terminated one at a time. Furthermore, for the link verification
procedure it is assumed that the nodal architecture is designed so
that messages can be sent and received over any data link. Note
that this requirement is trivial for DXCs (and OEO devices in
general) since each data link is terminated and processed
electronically before being forwarded to the next OEO device, but
that in PXCs (and transparent devices in general) this is an
additional requirement.
[Jonathan]There is a challenge in verifying the connectivity between PXCs
since a PXC just interconnects ports without termination the signals.
6.2. Fault Localization Procedure
[Insert: 6.2.1 Suppression of downstream alarms in pre-G.709 networks]
[Jonathan] Rather than separate the section into two subsections, I will add
text to clarify both features provided by LMP.
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 ChannelStatus message.
This message may be used to indicate that a single data channel has
failed, multiple data channels have failed, or an entire TE link has
failed.
[Insert: A ChannelStatus message is sent to the downstream node indicating
to the downstream node that the failure has been detected upstream and
therefore to suppress the alarm.]
[Delete: Failure correlation is done locally at each node upon
receipt of the failure notification.]
[Jonathan]no change
[Insert: 6.2.2 Localization of a fault to a link for protection/restoration]
[Jonathan]see comment above
[Delete: As part of the fault localization,]
[Insert: To localize a fault to a particular link between adjacent OXCs,]
[Jonathan]change made.
a downstream node (downstream in
terms of data flow) that detects data link failures will send a
ChannelStatus message to its upstream neighbor indicating that a
failure has occurred (bundling together the notification of all of
the failed data links).
<snip>
Once the failure has been localized, the signaling
protocols can be used to initiate span or path
protection/restoration procedures.
[Insert: Note that the fault localization scheme supported in LMP localizes
faults on a link and does not address node failures. Therefore additional
mechanisms are needed to detect node failures for end-to-end path
protection/restoration.]
[Jonathan]no change.
[Insert: 6.2.2.1 Examples of Fault Localization]
[Delete: 6.3. Examples of Fault Localization]
[Jonathan]see comment above
-----Original Message-----
From: Carmine Daloia [mailto:daloia@lucent.com]
Sent: Monday, November 26, 2001 7:43 AM
To: Sudheer Dharanikota
Cc: Jonathan Lang; ccamp@ops.ietf.org; tsg15q11@itu.int; t1x15@t1.org
Subject: Re: [T1X1.5] Re: Suppression of Downstream Alarms...
Hi Sudheer, Jonathan, and all,
Attached is the LMP draft with my proposed text inserted. I inserted
proposed text on the suppression of downstream alarms, as well as some other
sections.
Please let me know what you think of the proposed text.
The notation I used is as follows:
[Insert: .... new proposed text....]
[Delete: .... text that I propose to be deleted...]
Thanks
Carmine
Sudheer Dharanikota wrote:
Carmine Daloia wrote:
Hi Sudheer,My last comment wasn't meant to be an argument :-)Maybe if I
propose some text specific to the suppressionof downstream alarms that would
help clarify the scope ofapplicability. The text would state that when
clientdevices (e.g., SONET/SDH cross-connects, IP routers) areinterconnected
via a standard OTN network then thesuppression of downstream alarms is
already handled in thetransport/user plane via the OTN overhead (both
in-bandvia the digitial overhead as well as out-of-band vianon-associated
overhead). Also the text would address PXCswithin a standard OTN network. In
this case, again thesuppression of downstream alarms is handled via the
OTNoverhead.The implementation proposed in LMP for suppression ofdownstream
alarms applies to PXCs or client devices (e.g,SONET/SDH cross-connects or IP
routers) interconnected viaa non-standard DWDM network. In this case, it is
as
summedthat the non-standard DWDM network does not provide theneccesary
overhead within the transport/user plane tosuppress alarms on PXCs and
client devices and thereforeLMP provides a mechanism to carry such alarm
suppressionmessages in the control plane.I'll take a crack at specific text
so that the group canreview it. Does this sound like something that would
behelpful.
Sure.Regards,sudheer