draft-ietf-ccamp-lmp-wdm-00.txt   draft-ietf-ccamp-lmp-wdm-01.txt 
Network Working Group Andre Fredette (Editor) CCAMP Working Group A. Fredette, Editor
Internet Draft Jonathan Lang (Calient Networks) (Editor) Internet Draft Hatteras Networks
Expiration Date: August 2002 Expiration Date: March 2003 J. Lang, Editor
Osama Aboul-Magd (Nortel Networks) Calient Networks
S. Brorson (Axiowave Networks)
S. Dharanikota (Nayna Networks, Inc)
John Drake (Calient Networks)
David Drysdale (Data Connection)
W. L. Edwards (iLambda Networks)
Adrian Farrel (Movaz Networks)
R. Goyal (Axiowave Networks)
Hirokazu Ishimatsu (Japan Telecom)
Monika Jaeger (T-systems)
R. Krishnan (Axiowave Networks)
Raghu Mannam (Hitachi Telecom)
Eric Mannie (Ebone (GTS))
Dimitri Papadimitriou (Alcatel)
Vasant Sahay (Nortel Networks)
Jagan Shantigram (PhotonEx Corp.)
Ed Snyder (PhotonEx Corp.)
George Swallow (Cisco Systems)
G. Tumuluri (Calient Networks)
Y. Xue (UUNET/WorldCom)
Lucy Yong (Williams Communications)
J. Yu
February 2002 September 2002
Link Management Protocol (LMP) for DWDM Optical Line Systems Link Management Protocol (LMP) for DWDM Optical Line Systems
draft-ietf-ccamp-lmp-wdm-01.txt
draft-ietf-ccamp-lmp-wdm-00.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026]. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
ABSTRACT Abstract
A suite of protocols is being developed in the IETF to allow
networks consisting of photonic switches (PXCs), optical The Link Management Protocol (LMP) is defined to manage traffic
crossconnects (OXCs), routers, switches, DWDM optical line systems engineering (TE) links. In its present form, LMP focuses on peer
(OLSs), and optical add-drop multiplexors (OADMs) to use an MPLS- nodes; i.e., nodes that peer in signaling and/or routing. In this
based control plane to dynamically provision resources and to document we propose extensions to LMP to allow it to be used between
provide network survivability using protection and restoration a peer node and an adjacent optical line system (OLS). These
techniques. As part of this protocol suite, the Link Management
Protocol (LMP) [LMP] is defined to "maintain control channel
connectivity, verify component link connectivity, and isolate link,
fiber, or channel failures within the network." In it's present
form, [LMP] focuses on peer communications (eg. OXC-to-OXC). In
this document we propose extensions to LMP for use with OLSs. These
extensions are intended to satisfy the "Optical Link Interface extensions are intended to satisfy the "Optical Link Interface
Requirements" described in [OLI]. Requirements" described in a companion document.
CONTENTS Changes from previous version:
1. Introduction.......................................................3
2. Scope of LMP-WDM Protocol..........................................5 o Editorial changes.
3. LMP Extensions for Optical Line Systems............................5 o Removed the Trace monitoring section to be put in SONET/SDH
3.1. Control Channel Management.......................................6 technology specific draft.
3.2. Link Verification................................................6 o Moved the LMP-WDM support bit from the common header of LMP
3.3. Link Summarization...............................................6 messages to a new LMP-WDM_CONFIG object.
3.3.1. Link Group ID..................................................7
3.3.2. Shared Risk Link Group Identifier (SRLG):......................8
3.3.3. Bit Error Rate (BER) Estimate..................................9
3.3.4. Optical Protection.............................................9
3.3.5. Total Span Length:............................................10
3.3.6. Administrative Group (Color)..................................10
3.4. Fault Management................................................10
3.4.1. LINK GROUP CHANNEL_STATUS Object..............................11
3.5. Alarm Management................................................12
3.6. Trace Monitoring................................................13
3.6.1. TraceMonitor Message (MsgType = TBD)..........................13
3.6.1.1. TRACE Object................................................13
3.6.2. TraceMonitorAck Message (MsgType = TBD).......................14
3.6.3. TraceMonitorNack Message (MsgType = TBD)......................14
3.6.3.1. ERROR_CODE Class............................................15
3.6.4. TraceMismatch Message (MsgType = TBD).........................15
3.6.5. TraceMismatchAck Message (MsgType = TBD)......................15
3.6.6. TraceReq Message (MsgType = TBD)..............................15
3.6.7. TraceReport Message (MsgType = TBD)...........................16
3.6.8. TraceReqNak Message (MsgType = TBD)...........................16
3.6.9. InsertTraceReq Message (MsgType = TBD)........................16
3.6.10. InsertTraceAck Message (MsgType = TBD).......................16
3.6.11. InsertTraceNack Message (MsgType = TBD)......................17
4. Security Considerations...........................................17
5. Work Items........................................................17
6. References........................................................18
7. Author's Addresses................................................19
1. Introduction 1. Introduction
Future networks will consist of photonic switches (PXCs), optical Networks are being developed with routers, switches, optical
crossconnects (OXCs), routers, switches, DWDM optical line systems crossconnects (OXCs), DWDM optical line systems (OLSs), and add-drop
(OLSs), and optical add-drop multiplexors (OADMs) that use the GMPLS multiplexors (ADMs) that use a common control plane [e.g.,
control plane to dynamically provision resources and to provide Generalized MPLS (GMPLS)] to dynamically provision resources and to
network survivability using protection and restoration techniques. provide network survivability using protection and restoration
A pair of nodes (e.g., a PXC and an OLS) may be connected by techniques.
thousands of fibers. Furthermore, multiple fibers and/or multiple
wavelengths may be combined into a single bundled link. [LMP] The Link Management Protocol (LMP) is being developed as part of the
Defines the Link Management Protocol (LMP) to "maintain control GMPLS protocol suite to manage traffic engineering (TE) links [LMP].
channel connectivity, verify component link connectivity, and In its present form, LMP focuses on peer nodes; i.e., nodes that peer
isolate link, fiber, or channel failures within the network." In in signaling and/or routing (e.g., OXC-to-OXC, as illustrated in
it's present form, [LMP] focuses on peer communications (eg. OXC-to- Figure 1). In this document, extensions to LMP to allow it to be
OXC) as illustrated in Figure 1. In this document, extensions to used between a peer node and an adjacent optical line system (OLS)
LMP for use with OLSs are proposed. These extensions are intended are proposed. These extensions are intended to satisfy the "Optical
to satisfy the "Optical Link Interface Requirements" described in Link Interface Requirements" described in [OLI]. It is assumed that
[OLI]. It is assumed that the reader is familiar with LMP as the reader is familiar with LMP as defined in [LMP].
defined in [LMP].
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | ----- | | | | ----- | | | | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | | | | ----- | | | | ----- | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
^ ^ ^ ^
| | | |
+----------------------LMP----------------------+ +---------------------LMP---------------------+
Figure 1: Base LMP Model Figure 1: LMP Model
A great deal of information about a link between two OXCs is known Consider two peer nodes (e.g., two OXCs) interconnected by a
by the OLS. Exposing this information to the control plane via LMP wavelength-multiplexed link; i.e., a DWDM optical link (see Figure 1
can improve network usability by further reducing required manual above). Information about the configuration of this link and its
configuration and also by greatly enhancing fault detection and current state is known by the two OLSs (OLS1 and OLS2), and allowing
recovery. Fault detection is particularly an issue when the network them to communicate this information to the corresponding peer nodes
is using all-optical photonic switches (PXC). Once a connection is (OXC1 and OXC2) via LMP can improve network usability by reducing
established, PXCs have only limited visibility into the health of required manual configuration and by enhancing fault detection and
the connection. Even though the PXC is all-optical, long-haul OLSs recovery.
typically terminate channels electrically and regenerate them
optically, which presents an opportunity to monitor the health of a
channel between PXCs. LMP-WDM can then be used by the OLS to
provide this information to the PXC using LMP-WDM.
In addition to the link information known to the OLS that is Information about the state of LSPs using the DWDM optical link is
exchanged through LMP-WDM, some information known to the OXC may known by the peer nodes (OXC1 and OXC2), and allowing them to
also be exchanged with the OLS through LMP-WDM. This information is communicate this information to the corresponding OLSs (OLS1 and
useful for alarm management and link monitoring (i.e., trace OLS2) is useful for alarm management and link monitoring. Alarm
monitoring). Alarm management is important because the management is important because the administrative state of an LSP,
administrative state of a connection, known to the OXC (e.g., this known to the peer nodes (e.g., via the Admin Status object of GMPLS
information may be learned through the Admin Status object of GMPLS signaling [GMPLS-SIG]) can be used to suppress spurious alarm
signaling [GMPLS]), can be used to suppress spurious alarms. For reporting from the OLSs.
example, the OXC may know that a connection is ˘up÷, ˘down÷, in a
˘testing÷ mode, or being deleted (˘deletion-in-progress÷). The OXC
can use this information to inhibit alarm reporting from the OLS
when a connection is ˘down÷, ˘testing÷, or being deleted.
The model for extending LMP to OLSs is shown in Figure 2. The model for extending LMP to OLSs is shown in Figure 2.
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | ----- | | | | ----- | | | | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | | | | ----- | | | | ----- | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | | | | | |
| +-----LMP-----+ +-----LMP----+ | | +-----LMP-----+ +-----LMP-----+ |
| | | |
+----------------------LMP----------------------+ +----------------------LMP-----------------------+
Figure 2: Extended LMP Model Figure 2: Extended LMP Model
In this model, an OXC may have multiple LMP sessions corresponding In this model, a peer node may have LMP sessions with adjacent OLSs
to multiple peering relationships. At each level, LMP provides link as well as adjacent peer nodes. In Figure 2, for example, the OXC1-
management functionality (i.e., control channel management, physical OXC2 LMP session can be used to build traffic-engineering (TE) links
connectivity verification, link property correlation) for that for GMPLS signaling and routing, as described in [LMP]. The OXC1-
peering relationship. For example, the OXC-OXC LMP session in OLS1 and the OXC2-OLS2 LMP sessions are used to exchange information
Figure 2 can be used to build traffic-engineering (TE) links for about the configuration of the DWDM optical link and its current
GMPLS signaling and routing, and are managed as described in [LMP]. state and information about the state of LSPs using that link.
At the transport level, the OXC-OLS LMP session (also shown in
Figure 2) is used to augment knowledge about the links between the
OXCs. The management of these LMP sessions is discussed in this
draft. It is important to note that an OXC may peer with one or more
OLSs and an OLS may peer with one or more OXCs.
Although there are many similarities between an OXC-OXC LMP session The latter type of LMP sessions is discussed in this document. It is
and an OXC-OLS LMP session, particularly for control management and important to note that a peer node may have LMP sessions with one or
link verification, there are some differences as well. These more OLSs and an OLS may have LMP sessions with one or more peer
differences can primarily be attributed to the nature of an OXC-OLS nodes.
link, and the purpose of OXC-OLS LMP sessions. As previously
mentioned, the OXC-OXC links can be used to provide the basis for
GMPLS signaling and routing at the optical layer. The information
exchanged over LMP-WDM sessions is used to augment knowledge about
the links between OXCs.
In order for the information exchanged over the OXC-OLS LMP sessions Although there are many similarities between an LMP session between
to be used by the OXC-OXC session, the information must be two peer nodes and an LMP session between a peer node and an OLS,
coordinated by the OXC. However, the two LMP sessions are run there are some differences as well. The former type of LMP session
independently and MUST be maintained separately. One critical is used to provide the basis for GMPLS signaling and routing. The
requirement when running an OXC-OLS LMP session is the ability of latter type of LMP session is used to augment knowledge about the
the OLS to make a data link transparent when not doing the links between peer nodes.
verification procedure. This is because the same data link may be
verified between OXC-OLS and between OXC-OXC. The BeginVerify
procedure of [LMP] is used to coordinate the Test procedure (and
hence the transparency/opaqueness of the data links).
To maintain independence between the sessions, it MUST be possible A peer node maintains its peer node - OLS LMP sessions and its peer
for the LMP sessions to come up in any order. In particular, it node - peer node LMP sessions independently. This means that it MUST
MUST be possible for an OXC-OXC LMP session to come up without an be possible for LMP sessions to come up in any order. In particular,
OXC-OLS LMP session being brought up, and vice-versa. it MUST be possible for a peer node - peer node LMP session to come
up in the absence of any peer node - OLS LMP sessions and vice versa.
Additional details about the extensions required for LMP are 1.1. Terminology
outlined in the next section.
2. Scope of LMP-WDM Protocol The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar with the terminology in [LMP].
DWDM: Dense wavelength division multiplexor
OLS: Optical line system
Opaque:
A device is called X-opaque if it examines or modifies the X
aspect of the signal while forwarding an incoming signal from
input to output.
OXC: Optical crossconnect
Transparent:
As defined in [LMP], a device is called X-transparent if it
forwards incoming signals from input to output without examining
or modifying the X aspect of the signal. For example, a Frame
Relay switch is network-layer transparent; an all-optical switch
is electrically transparent.
1.2. Scope of LMP-WDM Protocol
This document focuses on extensions required for use with opaque This document focuses on extensions required for use with opaque
OLSs. In particular, this document is intended for use with OLSs OLSs. In particular, this document is intended for use with OLSs
having SONET, SDH, and Ethernet user ports. having SONET, SDH, and Ethernet user ports.
If multiplexing is performed by an OLS using LMP-WDM, it is assumed
that it is done in such a way that it is ˘transparent÷ to the OLS
clients. Otherwise, the OLS may be required to become actively
involved in connection establishment by running higher-layer GMPLS
protocols. In this case, the OLS would effectively be treated as
just another switch in the optical network. Such active OLS
involvement is beyond the scope of this document.
At the time of this writing, work is ongoing in the area of fully At the time of this writing, work is ongoing in the area of fully
transparent wavelength routing; however, it is premature to identify transparent wavelength routing; however, it is premature to identify
the necessary characteristics to exchange. That said, the protocol the necessary information to be exchanged between a peer node and an
described in this document provides the necessary framework in which OLS in this context. Never-the-less, the protocol described in this
to exchange additional information as it is deemed appropriate. document provides the necessary framework in which to exchange
whatever additional information is deemed appropriate.
3. LMP Extensions for Optical Line Systems 2. LMP Extensions for Optical Line Systems
As currently defined, LMP consists of four types of functions: LMP currently consists of four main procedures, of which the first
two are mandatory and the last two are optional:
1. Control Channel Management 1. Control channel management
2. Link Verification 2. Link property correlation
3. Link Summarization 3. Link verification
4. Fault Management 4. Fault management
All four functions are supported in LMP-WDM. Additionally, a trace All four functions are supported in LMP-WDM.
monitoring function is added. (Note: Other monitoring types will be
considered in a future release.)
In this document we follow the convention of [LMP] and use the term 2.1. Control Channel Management
"data link" to refer to either "component links" or "ports".
It is very important to understand the subtle distinctions between As in [LMP], we do not specify the exact implementation of the
the different types of links being considered in the extended LMP- control channel; it could be, for example, a separate wavelength,
WDM. For example, in Figure 2 when OXC1 and OXC2 complete the fiber, Ethernet link, an IP tunnel routed over a separate management
verify process, the links being verified are the end-to-end links network, a multi-hop IP network, or the overhead bytes of a data
between the OXC's. It is the TE link composed of these "data links" link.
that are advertised in the routing protocols and used for the
purposes of connection setup. The verify procedure between OXC1 and
OLS1, on the other hand verifies the shorter link between these two
nodes. However, each of these shorter links is a segment of one of
the larger end-to-end links. The verify serves two functions: to
verify connectivity and exchange handles by which each data link is
referred. Furthermore, it is up to the OXC to correlate the handles
between the various LMP sessions.
Once a control channel has been established and the OXC-OLS The control channel management for a peer node - OLS link is the same
verification procedure has been completed successfully, the OXC and as for a peer node - peer node link, as described in [LMP].
OLS may exchange information regarding link configuration (i.e.,
using the LinkSummary exchange). An OXC may also receive
notification regarding the operational status from an OLS (i.e.,
using the ChannelStatus exchange).
In subsequent sections, specific additions are proposed to extend To distinguish between a peer node - OLS LMP session from a peer node
LMP to work with OLSs. - peer node LMP session, a new LMP-WDM CONFIG object is defined (C-
Type = TBA by IANA). The format of the CONFIG object is as follows:
3.1. Control Channel Management Class = 6.
As in [LMP], we do not specify the exact implementation of the o C-Type = TBA, LMP-WDM_CONFIG
control channel; it could be, for example, a separate wavelength or
fiber, an Ethernet link, an IP tunnel through a separate management
network, or the overhead bytes of a data link.
The control channel management for OXC-OLS links is the same as for 0 1 2 3
OXC-OXC links, as described in [LMP]. The ˘LMP-WDM Support÷ flag in 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
the LMP Common Header is used to indicate support for the objects +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
defined in this draft. This informs the receiving node that the |W|O| (Reserved) |
LMP-WDM extensions will be used for the session. If the LMP-WDM +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
extensions are not supported by the node, it MUST reply to the
Config Message with a ConfigNack Message.
3.2. Link Verification The Reserved field should be sent as zero and ignored on receipt.
WDM: 1 bit
This bit indicates support for the LMP-WDM extensions defined
in this draft.
OLS: 1 bit
If set, this bit indicates that the sender is an optical line
system (OLS). If clear, this bit indicates that the sender is
a peer node.
The LMP-WDM extensions are designed for peer node - OLS LMP
sessions. The OLS bit allows a node to identify itself as an OLS or
a peer node. This is used to detect misconfiguration of a peer node
-OLS LMP session between two peer nodes or a peer node - peer node
LMP session between a peer node and an OLS.
If the node does not support the LMP-WDM extensions, it MUST reply
to the Config message with a ConfigNack message.
If a peer node that is configured to run LMP-WDM receives a Config
message with the OLS bit clear in LMP-WDM_CONFIG Object, it MUST
reply to the Config message with a ConfigNack message.
2.2. Link Verification
The Test procedure used with OLSs is the same as described in [LMP]. The Test procedure used with OLSs is the same as described in [LMP].
The VerifyTransportMechanism (included in the BeginVerify and The VerifyTransportMechanism (included in the BeginVerify and
BeginVerifyAck messages) is used to allow nodes to negotiate a link BeginVerifyAck messages) is used to allow nodes to negotiate a link
verification method and is essential for transmission systems which verification method and is essential for line systems that have
have access to overhead bytes rather than the payload. The VerifyId access to overhead bytes rather than the payload. The VerifyId
(provided by the remote node in the BeginVerifyAck message, and used (provided by the remote node in the BeginVerifyAck message, and used
in all subsequent Test messages) is used to differentiate Test in all subsequent Test messages) is used to differentiate Test
messages from different LMP sessions. messages from different LMP Link Verification procedures. In
addition to the Test procedure described in [LMP], the trace
monitoring function of [LMP-SDH] may be used for link verification
when the OLS user ports are SONET or SDH.
3.3. Link Summarization In a combined LMP and LMP-WDM context, there is an interplay between
the data links being managed by peer node - peer node LMP sessions
and peer node - OLS LMP sessions. For example, in Figure 2, the
OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1,
and the OXC2-OLS2 LMP session manages the data links between OXC2 and
OLS2. However, the OXC1-OXC2 LMP session manages the data links
between OXC1 and OXC2, which are actually a concatenation of the data
links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and
the data links between OXC2 and OLS2, and it is these concatenated
links which comprise the TE links which are advertised in the GMPLS
TE link state database.
The implication of this is that when the data links between OXC1 and
OXC2 are being verified, using the LMP link verification procedure,
OLS1 and OLS2 need to make themselves transparent with respect to
these concatenated data links. The co-ordination of verification of
OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the
responsibility of the peer nodes, OXC1 and OXC2.
It is also necessary for these peer nodes to understand the mappings
between the data links of the peer node - OLS LMP session and the
concatenated data links of the peer node - peer node LMP session.
2.3. Link Summarization
As in [LMP], the LinkSummary message is used to synchronize the As in [LMP], the LinkSummary message is used to synchronize the
Interface Ids and correlate the properties of the TE link. (Note Interface Ids and correlate the properties of the TE link. (Note that
that the term ŠTE LinkĂ originated from routing/signaling the term "TE Link" originated from routing/signaling applications of
applications of LMP, whereas this concept doesnĂt necessarily apply LMP, whereas this concept does not necessarily apply to an OLS.
to an OLS. However, the term is used in this draft to remain However, the term is used in this document to remain consistent with
consistent with LMP terminology.) Additional Data Link sub-objects LMP terminology.) The LinkSummary message includes one or more
are defined in this draft to extend the LinkSummary message to DATA_LINK objects. The contents of the DATA_LINK object consist of a
include additional link characteristics. These sub-objects are series of variable-length data items called Data Link sub-objects
described in the following subsections. The link characteristics, describing the capabilities of the data links.
in general, are those characteristics needed by the control plane
for constraint-based routing in the selection of a path for a
particular connection.
The format of the Data Link Sub-Objects follows the format described In this document, several additional Data Link sub-objects are
defined to describe additional link characteristics. The link
characteristics are, in general, those needed by the CSPF to select
the path for a particular LSP. These link characteristics describe
the specified peer node - OLS data link as well as the associated
DWDM span between the two OLSs.
The format of the Data Link sub-objects follows the format described
in [LMP] and is shown below for readability: in [LMP] and is shown below for readability:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Sub-object contents) | | Type | Length | (Sub-object contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
Type: 8 bits Type: 8 bits
The Type indicates the type of contents of the subobject. The Type indicates the type of contents of the sub-object.
Length: 8 bits Length: 8 bits
The Length field contains the total length of the sub-object in The Length field contains the total length of the sub-object in
bytes, including the Type and Length fields. The Length MUST bytes, including the Type and Length fields. The Length MUST
be at least 4, and MUST be a multiple of 4. be at least 4, and MUST be a multiple of 4.
The following Link Characteristics are advertised on a per data link The following Link Characteristics are exchanged on a per data link
basis. basis.
3.3.1. Link Group ID 2.3.1. Link Group ID
The main purpose of the Link Group ID is to reduce control traffic The main purpose of the Link Group ID is to reduce control traffic
during failures that affect many data links. A local ID may be during failures that affect many data links. A local ID may be
assigned to a group of data links. This ID can be used to reduce assigned to a group of data links. This ID can be used to reduce the
the control traffic in the case of a failure by enabling the systems control traffic in the event of a failure by enabling a single
to send a single message for a group instead of individual messages ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see
for each member of the group. A link may be a member of multiple Section 2.4.1) to be used for a group of data links instead of
groups. This is achieved by presenting multiple Link Group ID individual ChannelStatus messages for each data link. A data link
Objects in the LinkSummary message. may be a member of multiple groups. This is achieved by including
multiple Link Group ID sub-objects in the LinkSummary message.
The Link Group ID feature allows Link Groups to be assigned based The Link Group ID feature allows Link Groups to be assigned based
upon the types of fault correlation and aggregation supported by a upon the types of fault correlation and aggregation supported by a
given OLS. From a practical perspective, the Link Group ID is used given OLS. From a practical perspective, the Link Group ID is used
to map (or group) data links into "failable entities" known only to to map (or group) data links into "failable entities" known primarily
the OLS. If one of those failable entities fails, all associated to the OLS. If one of those failable entities fails, all associated
data links are failed and the OXC may be notified with a single data links are failed and the peer node is notified with a single
message. message.
For example, an OLS could create a Link Group for each laser in the For example, an OLS could create a Link Group for each laser in the
OLS. This group could be associated with data links during OLS. The data links associated with each laser would then each be
discovery/initialization time. Multiple data links could be assigned the Link Group ID for that laser. If a laser fails, the OLS
associated with a single group (depending on the kind of would then report a single failure affecting all of the data links
multiplexing supported in the system). If a laser fails, the OLS with Link Group ID of the failed laser. The peer node that receives
can report a failure for the group. The OXC that receives the group the single failure notification then knows which data links are
failure message can determine the associated link or links. Another affected. Similarly, an OLS could create a Link Group ID for a
group could be assigned for a fiber to report all data links down fiber, to report a failure affecting all of the data links associated
that are associated with that fiber if LOS is detected at the fiber with that fiber if a loss-of-signal (LOS) is detected for that fiber.
level. Depending on the physical OLS implementation, it may make
sense to allocate other groups, such as all data links on a
particular circuit card. With this method, the OXC only needs to
know about the externally visible data links. The OLS can associate
the data links with logical groups and the OXC doesn't need to know
anything about the physical OLS implementation or how data links are
multiplexed electrically or optically within the system.
The format of the Link Group ID sub-object (Type=TBD, Length=8) is The format of the Link Group ID sub-object (Type=TBD, Length=8) is as
as follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link Group ID | | Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID (cont) | (Reserved) | | Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Group ID: 32 bits The Reserved field should be sent as zero and ignored on receipt.
Link Group ID 0xFFFFFFFF is reserved and indicates all data links
in a TE link. All data links are members of Link Group 0xFFFFFFFF
by default.
Reserved: 16 bits Link Group ID: 32 bits
Must be set to zero on transmit and ignored on receive. Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of Link Group
0xFFFFFFFF by default.
3.3.2. Shared Risk Link Group Identifier (SRLG): 2.3.2. Shared Risk Link Group Identifier (SRLG)
SRLGs of which the data link is a member. This information is This identifies the SRLGs of which the data link is a member. This
manually configured on an OLS by the user and may be used for information may be configured on an OLS by the user and used for
diverse path computation. diverse path computation (see [GMPLS-RTG]).
The format of the SRLG sub-object (Type=TBD) is as follows: The format of the SRLG sub-object (Type=TBD) is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SRLG value #1 | | Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #1(cont) | SRLG value #2 | | SRLG value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ | | ............ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #(N-1)(cont) | SRLG value #N | | SRLG value #(N-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #N(cont) | (Reserved) | | SRLG value #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Length: 8 bits Length: 8 bits
The length is (N+1)*4, where N is the number of SRLG values. The length is (N+1)*4, where N is the number of SRLG values.
Shared Risk Link Group Value: 32 bits Shared Risk Link Group Value: 32 bits
List as many SRLGs as apply. See [GMPLS-RTG]. List as many SRLGs as apply.
Reserved: 16 bits
Must be set to zero on transmit and ignored on receive.
3.3.3. Bit Error Rate (BER) Estimate 2.3.3. Bit Error Rate (BER) Estimate
This Object provides an estimate of the BER for the data link. This object provides an estimate of the BER for the data link.
The bit error rate (BER) is the proportion of bits that have errors The bit error rate (BER) is the proportion of bits that have errors
relative to the total number of bits received in a transmission, relative to the total number of bits received in a transmission,
usually expressed as ten to a negative power. For example, a usually expressed as ten to a negative power. For example, a
transmission might have a BER of "10 to the minus 13", meaning that, transmission might have a BER of "10 to the minus 13", meaning that,
out of every 10,000,000,000,000 bits transmitted, one bit may be in out of every 10,000,000,000,000 bits transmitted, one bit may be in
error. The BER is an indication of overall signal quality. error. The BER is an indication of overall signal quality.
The format of the BER Estimate subobject (Type=TBD; Length=4) is as The format of the BER Estimate sub-object (Type=TBD; Length=4) is as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | BER | Reserved | | Type | Length | BER | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BER: 8 bits The Reserved field should be sent as zero and ignored on receipt.
The exponent from the BER representation described above. For
example, if the BER is 10 to the minus X, the BER field is set to
X.
Reserved: 8 bits BER: 8 bits
Must be set to zero on transmit and ignored on receive. The exponent from the BER representation described above. I.e.,
if the BER is 10 to the minus X, the BER field is set to X.
3.3.4. Optical Protection 2.3.4. Optical Protection
Whether the OLS protects the link internally. This information can This indicates whether the link is protected by the OLS. This
be used as a measure of quality of the link. It may be advertised information can be used as a measure of link capability. It may be
by routing and used by signaling as a selection criterion as advertised by routing and used by signaling as a selection criterion
described in [GMPLS]. as described in [GMPLS-SIG].
The format of the Optical Protection subobject (Type=TBD; Length=4) The format of the Optical Protection sub-object (Type=TBD; Length=4)
is as follows: is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Link Flags| Reserved | | Type | Length | (Reserved) | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Flags: 6 bits The Reserved field should be sent as zero and ignored on receipt.
Encoding for Link Flags can be found in [GMPLS].
Reserved: 10 bits Link Flags: 6 bits
Must be set to zero on transmit and ignored on receive. Encoding for Link Flags is defined in Section 7 of [GMPLS-SIG].
3.3.5. Total Span Length: 2.3.5. Total Span Length
The total distance of fiber in OLS. May be used as a routing metric This indicates the total distance of fiber in the OLS. This may be
or to estimate delay. used as a routing metric or to estimate delay.
The format of the Span Length sub-object (Type=TBD, Length=8) is as The format of the Total Span Length sub-object (Type=TBD, Length=8)
follows: is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Span Length | | Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Span Length (cont) | (Reserved) | | Span Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Span Length: 32 bits The Reserved field should be sent as zero and ignored on receipt.
Total Length of the WDM span in meters expressed as an unsigned
integer.
Reserved: 16 bits Span Length: 32 bits
Must be set to zero on transmit and ignored on receive. This value represents the total Length of the WDM span in meters
expressed as an unsigned (long) integer.
3.3.6. Administrative Group (Color) 2.3.6. Administrative Group (Color)
The administrative group (or Color) to which the data link belongs. The administrative group (or Color) to which the data link belongs.
The format of the Administrative Group sub-object (Type=TBD, The format of the Administrative Group sub-object (Type=TBD,
Length=8) is as follows: Length=8) is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Administrative Group | | Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Group (cont) | (Reserved) | | Administrative Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Administrative Group: 32 bits The Reserved field should be sent as zero and ignored on receipt.
A 32 bit value.
Reserved: 16 bits Administrative Group: 32 bits
Must be set to zero on transmit and ignored on receive. A 32 bit value as defined in [OSPF-TE].
3.4. Fault Management 2.4. Fault Management
Fault management consists of three major functions: Fault management consists of three major functions:
1. Fault Detection 1. Fault Detection
2. Fault Localization 2. Fault Localization
3. Fault Notification 3. Fault Notification
The actual Fault Detection mechanisms are the responsibility of the The fault detection mechanisms are the responsibility of the
individual nodes and are not specified as part of this protocol. individual nodes and are not specified as part of this protocol.
Fault detection mechanisms may include such things as bit error rate Fault detection mechanisms may include a bit error rate (BER)
(BER) exceeding a threshold, loss of signal (LOS) and SONET/SDH- exceeding a threshold, loss of signal (LOS) and SONET/SDH-level
level errors. It is the responsibility of the OLS to translate errors. It is the responsibility of the OLS to translate these
these failures into OK, SF, or SD as described in LMP. failures into OK, SF, or SD as described in [LMP].
Running LMP-WDM on the OLS allows the OLS to notify an attached OXC I.e., an OLS uses the messages defined in the LMP fault localization
or router when it detects a fault. The OXCs and routers continue to procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest,
execute the fault localization procedure as currently specified in and ChannelStatusResponse Messages) to inform the adjacent peer node
[LMP]. The main enhancement when using LMP-WDM is that the OLS may of failures it has detected, in order to initiate the LMP fault
initiate the process (both downstream and upstream). It is localization procedures between peer nodes, but it does not
important to note that the OLS does not participate in end-to-end participate in those procedures.
fault localization as described in [LMP].
The OLS may also execute its own fault localization process that may The OLS may also execute its own fault localization process to allow
allow it to determine the location of the fault much more it to determine the location of the fault along the DWDM span. For
specifically than the OXCs can. For example, the OLS may be able to example, the OLS may be able to pinpoint the fault to a particular
pinpoint the fault to a particular amplifier along a set of fibers amplifier in a span thousands of kilometers in length.
that can span 1000's of kilometers.
To report data link failures and recovery conditions, LMP-WDM uses To report data link failures and recovery conditions, LMP-WDM uses
the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and
ChannelStatusResponse Messages defined in [LMP]. ChannelStatusResponse Messages defined in [LMP].
Each data link is identified by an Interface_ID. In addition, LMP- Each data link is identified by an Interface_ID. In addition, a Link
WDM specifies a Link Group_ID that may be assigned to a group of Group ID may be assigned to a group of data links (see Section
data links (see Section 3.3.1). The Link Group ID may be used to 2.3.1). The Link Group ID may be used to reduce the control traffic
reduce the control traffic by providing channel status information by providing channel status information for a group of data links. A
for a group of data links. A new LINK GROUP_CHANNEL STATUS object is new LINK GROUP CHANNEL_STATUS object is defined below for this
defined below for this purpose. This object may be used in place of purpose. This object may be used in place of the CHANNEL_STATUS
the CHANNEL_STATUS objects described in [LMP] in the ChannelStatus objects described in [LMP] in the ChannelStatus message.
message.
3.4.1. LINK GROUP CHANNEL_STATUS Object 2.4.1. LINK GROUP CHANNEL_STATUS Object
The LINK GROUP_STATUS object is used to indicate the status of the The LINK GROUP CHANNEL_STATUS object is used to indicate the status
data links belonging to a particular Link Group. The correlation of of the data links belonging to a particular Link Group. The
data links to Group ID is made with the Link Group ID subobject of correlation of data links to Group ID is made with the Link Group ID
the DATA_LINK Object. sub-object of the DATA_LINK Object.
The format of the LINK GROUP_CHANNEL STATUS object is as follows The format of the LINK GROUP CHANNEL_STATUS object is as follows
(Class = 18, C-Type to be assigned by IANA): (Class = 13, C-Type =TBA by IANA):
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length | | Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Status | |A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
// : // // : //
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID | | Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel Status | |A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Group_ID: 32 bits
Link Group ID 0xFFFFFFFF is reserved and indicates all data links
in a TE link. All data links are members of Link Group 0xFFFFFFFF
by default.
Channel_Status: 32 bits
The values for the Channel_Status field are defined in [LMP].
This Object is non-negotiable.
3.5. Alarm Management
Alarm management is an important feature of LMP-WDM because it can
be used to suppress cascading and/or spurious alarms during normal
connection procedures. For example, the OXC may know that a
connection is ˘up÷, ˘down÷, in a ˘testing÷ mode, or being deleted
(˘deletion-in-progress÷). The OXC can use this information to
inhibit alarm reporting from the OLS when the state of a connection
changes in a controlled fashion.
Alarm management is controlled using the Active bit of the
CHANNEL_STATUS object (see [LMP]).
In the following, we describe how the Active bit can be used in
conjunction with the Admin Status object of [GMPLS] to manage alarms
during graceful connection deletion.
Consider the network of Figure 3 where a wavelength LSP has been
established using RSVP-GMPLS from OXC-A through OXC-B to OXC-C. To
support graceful deletion of the LSP, the Deletion in Progress bit
is set in the Admin Status object of a Path message that is
transmitted from OXC-A through OXC-B to OXC-C. This bit indicates
that ˘local actions related to LSP teardown should be taken.÷ As
part of the local actions for LSP teardown, each OXC should notify
itĂs neighboring OLS(s) that the data link is now deactive. For
example, OXC-B should notify OLS-B1 and OLS-B2 that the link is
deactive before forwarding the Path message to the next node. This
ensures that when the connection is removed multiple alarms are not
triggered at each of the line systems.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| OXC |---| OLS | | OLS |---| OXC |---| OLS | | OLS |---| OXC |
| A |---| A1 |===| B1 |---| B |---| B2 |===| C1 |---| C |
| |---| | | |---| |---| | | |---| |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | ^ ^ ||| ^ ^ | |
| +--------+ +--------+|+--------+ +--------+ |
| LMP-WDM LMP-WDM | LMP-WDM LMP-WDM |
+-------------------------------+------------------------------+
GMPLS Signaling GMPLS Signaling
Figure 3: Alarm Management Example
3.6. Trace Monitoring
The trace monitoring features described in this section allow a PXC
to do basic trace monitoring on circuits by using the capabilities
on an attached OLS.
. An OLS Client may request the OLS to monitor a link for a
specific pattern in the overhead using the TraceMonitorReq
Message. An example of this overhead is the SONET Section
Trace message transmitted in the J0 byte. If the actual trace
message does not match the expected trace message, the OLS MUST
report the mismatch condition.
. An OLS client may request the value of the current trace
message on a given data link using the TraceReq Message.
3.6.1. TraceMonitor Message (MsgType = TBD)
The TraceMonitor message is sent over the control channel and is
used to request an OLS to monitor a data link for a specific trace
value. An OLS MUST respond to a TraceMonitor message with either a
TraceMonitorAck or TraceMonitorNack Message.
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
If supported by the hardware, traces of different types may be
monitored simultaneously (e.g., Section and Path trace messages may
exist simultaneously on the same data link).
3.6.1.1. TRACE Object
The format of the TRACE object is as follows (Class and C-Type to be
assigned by IANA):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Trace Message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Group ID: 32 bits
The Trace Object is non-negotiable. Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of Link Group
Trace Type: 16 bits 0xFFFFFFFF by default.
The type of the trace message:
1 ű SONET Section Trace (J0 Byte)
2 ű SONET Path Trace (J1 Byte)
3 ű SDH Section Trace (J0 Byte)
4 ű SDH Path Trace (J1 Byte)
Other types TBD.
Trace Length: 16 bits
The Length in bytes of the trace message provided.
Trace Message:
Expected message. The valid length and value combinations are
determined by the specific technology (e.g., SONET or SDH) and
are beyond the scope of this document. The message MUST be
padded with zeros to a 32-bit boundary, if necessary.
3.6.2. TraceMonitorAck Message (MsgType = TBD)
The TraceMonitorAck message is used to indicate that all of the
Trace Objects in the TraceMonitor message have been received and
processed correctly.
The format is as follows:
<TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP].
3.6.3. TraceMonitorNack Message (MsgType = TBD)
The TraceMonitorNack message is used to indicate that the Trace
Object in the TraceMonitor message was not processed correctly.
This could be because the trace monitoring requested is not
supported or there was an error in the value.
The format is as follows:
<TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The MESSAGE_ID_ACK object is defined in [LMP].
The TraceMonitorNack message uses the ERROR_CODE C-Type,
3.6.3.1. ERROR_CODE Class
C-Type = 20 (see [LMP])
LMP-WDM defines the following new error code bit-values:
TBD1 = Unsupported Trace Type
TBD2 = Invalid Trace Message
All other values are Reserved. Channel Status: 32 bits
Multiple bits may be set to indicate multiple errors. The values for the Channel Status field are defined in [LMP].
This Object is non-negotiable. This Object is non-negotiable.
3.6.4. TraceMismatch Message (MsgType = TBD) 3. Security Considerations
The TraceMismatch message is sent over the control channel and is
used to report a trace mismatch on a data link for which trace
monitoring was requested.
A neighboring node that receives a TraceMismatch message MUST
respond with a TraceMismatchAck message. The format is as follows:
<TraceMismatch Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> [<LOCAL_INTERFACE_ID> ...]
The LOCAL_INTERFACE_ID object is defined in [LMP]. The
LOCAL_INTERFACE_ID in this message is the local Interface Id of the
link that has a trace mismatch. A trace mismatch for multiple
LOCAL_INTERFACE_ID's may be reported in the same message.
3.6.5. TraceMismatchAck Message (MsgType = TBD)
The TraceMismatchAck message is used to acknowledge receipt of a
TraceMismatch message.
The format is as follows:
<TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP] and must be copied
from the TraceMismatch Message being acknowledged.
3.6.6. TraceReq Message (MsgType = TBD)
The TraceReq message is sent over the control channel and is used to
request the current trace value of indicated data links.
A node that receives a TraceReq message MUST respond with a
TraceReport message. The format is as follows:
<TraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE REQ>
The format of the TRACE_REQ object is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: Defined in Section 3.6.1.1.
3.6.7. TraceReport Message (MsgType = TBD)
The TraceReport message is sent over the control channel after
receiving a TraceReq message.
<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
The TraceReport message MUST include a TRACE Object (as described in
Section 3.6.1.1) for the link requested.
3.6.8. TraceReqNak Message (MsgType = TBD)
The TraceReqNak message is sent over the control channel after
receiving a TraceReq message.
<TraceReqNak Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The TraceReqNak message MUST include an ERROR_CODE Object (as
described in Section 3.6.3) for the link requested.
3.6.9. InsertTraceReq Message (MsgType = TBD)
The InsertTraceReq message is sent over the control channel and is
used to request an OLS to send a specific trace message on a data
link. An OLS MUST respond to a InsertTraceReq message with either a
InsertTraceAck or InsertTraceNak Message.
<InsertTraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
3.6.10. InsertTraceAck Message (MsgType = TBD)
The InsertTraceAck message is used to indicate that the TRACE Object
in the InsertTrace message has been received and processed
correctly.
The format is as follows:
<InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [LMP].
3.6.11. InsertTraceNack Message (MsgType = TBD)
The InsertTraceNack message is used to indicate that the Trace
Object in the InsertTrace message was not processed correctly. This
could be because the trace monitoring requested is not supported or
there was an error in the value.
The format is as follows:
<InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The MESSAGE_ID_ACK object is defined in [LMP]. The ERROR_CODE
Object usage is described in Section 3.6.3.1.
4. Security Considerations
General LMP security issues are discussed in [LMP]. As in [LMP],
LMP-WDM exchanges may be authenticated using the Cryptographic
authentication option. MD5 is currently the only message digest
algorithm specified. The InsertTraceReq and TraceMonitor messages
introduced in this document present an opportunity for an intruder
to disrupt transmission. Authentication of messages is recommended
if the control network itself is not secure.
5. Work Items
The following work items have been identified. They will be
addressed in a future version of this draft:
1. Error messages may be needed in response to some of the defined
messages.
2. Provide description of procedures and interactions for running
LMP and LMP-WDM on the same link. Include description of how
control over link transparency works during the Verify
procedure.
3. Determine whether some functions are optional and, if so,
provide a capability negotiation mechanism.
6. References
[GMPLS] Berger, L., Ashwood-Smith, Peter, editors,
"Generalized MPLS - Signaling Functional Description",
Internet Draft, draft-ietf-mpls-generalized-signaling-
02.txt, (work in progress), March 2001.
[Bra96] Bradner, S., "The Internet Standards Process -- This document only defines new LMP objects extending the
Revision 3," BCP 9, RFC 2026, October 1996. capabilities of [LMP]. This document does not introduce any new
security considerations.
[DBC00] Drake, J., Blumenthal, D., Ceuppens, L., et al., 4. References
"Interworking between Photonic (Optical) Switches and
Transmission Systems over Optical Link Interface (OLI)
using Extensions to LMP", OIF Contribution
oif2000.254, (work in progress), November 2000.
[KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling 4.1. Normative References
in MPLS Traffic Engineering," Internet Draft, draft-
kompella-mpls-bundle-02.txt, (work in progress), July
2000.
[KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF [LMP] Lang, J. P., ed., "The Link Management Protocol (LMP),"
Extensions in Support of Generalized MPLS," Internet (work in progress).
Draft, draft-kompella-ospf-extensions-00.txt, (work in [GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
progress), July 2000. MPLS - Signaling Functional Description," (work in
progress).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[LMP-SDH] Lang, J. P., Papadimitriou, D.,"SONET/SDH Encoding for
Link Management Protocol (LMP) Test messages," (work in
progress).
[GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in
Support of Generalized MPLS," (work in progress).
[OSPF-TE] Katz, D, Yeung, D., and Kompella, K., "Traffic
Engineering Extensions to OSPF Version 2," (work in
progress).
[LMP] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter, 4.2. Informative References
Y., Berger, L., Saha, D., Basak, D., Sandick, H.,
Zinin, A., "Link Management Protocol (LMP)", Internet
Draft, draft-ietf-ccamp-lmp-02.txt, (work in
progress), July 2001.
[OLI] Fredette, A., Editor, "Optical Link Interface [OLI] Fredette, A., Editor, "Optical Link Interface
Requirements", Internet Draft, draft-many-oli-reqts- Requirements", (work in progress).
00.txt, (work in progress), June 2001.
[SDH] ITU-T G.707, "Network node interface for the
synchronous digital hierarchy (SDH)", 1996.
[SONET] GR-253-CORE, "Synchronous Optical Network (SONET)
Transport Systems: Common Generic Criteria", Telcordia
Technologies, Issue 3, September 2000
[T.50] ITU-T T.50, "International Reference Alphabet (IRA)
(formerly International Alphabet No. 5 or IA5)
Information technology 7-bit coded character set for
information interchange.", 1992.
7. Author's Addresses
Osama S. Aboul-Magd Rohit Goyal
Nortel Networks Axiowave Networks
P.O. Box 3511, Station C 100 Nickerson Road
Ottawa, Ontario, Canada Marlborough, MA 01752
K1Y 4H7 email: rgoyal@axiowave.com
Phone: 613-763-5827
email: osama@nortelnetworks.com Hirokazu Ishimatsu
Japan Telecom
Stuart Brorson 2-9-1 Hatchobori. Chuo-ku,
Axiowave Networks Tokyo, 104-0032 Japan
100 Nickerson Road email: hirokazu@japan-
Marlborough, MA 01752 telecom.co.jp
email: sdb@axiowave.com
Monika Jaeger
Sudheer Dharanikota T-systems
Nayna Networks, Inc. Monika.Jaeger@t-systems.de
157 Topaz Drive,
Milpitas, CA 95035 Ram Krishnan
email: sudheer@nayna.com Axiowave Networks
100 Nickerson Road
John Drake Marlborough, MA 01752
Calient Networks email: ram@axiowave.com
5853 Rue Ferrari
San Jose, CA 95138 Jonathan P. Lang
email: jdrake@calient.net Calient Networks
Court25 Castilian Drive
David Drysdale Goleta, CA 93117
Data Connection Ltd email: jplang@calient.net
dmd@dataconnection.com
Raghu Mannam
W. L. Edwards Hitachi Telecom (USA), Inc.
iLambda Networks rmannam@hitel.com
Aspen, CO
email: texas@ilambda.com Eric Mannie
Ebone (GTS)
Adrian Farrel (Movaz Networks) Terhulpsesteenweg 6A
Movaz Networks, Inc. 1560 Hoeilaart
7926 Jones Branch Drive, Belgium
Suite 615 Email: eric.mannie@gts.com
McLean, VA 22102
email: afarrel@movaz.com Dimitri Papadimitriou
Alcatel
Andre Fredette Francis Wellesplein 1,
email: afredette@charter.net B-2018 Antwerpen, Belgium
email: dimitri.Papadimitriou
@alcatel.be
Jagan Shantigram Yong Xue
PhotonEx Corporation UUNET/WorldCom
8C Preston 22001 Loudoun County Parkway
Bedford, MA 01730 Ashburn, VA 20148
email: jagan@photonex.com email: yxue@uu.net
Ed Snyder Lucy Yong 5. Contributors
PhotonEx Corporation Williams Communications
8C Preston Court 2 East First Street
Bedford, MA 01730 Tulsa, OK 74172
email: esnyder@photonex.com lucy.yong@wilcom.com
George Swallow John Yu Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake,
Cisco Systems, Inc. Zaffire, Inc David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette, Rohit
250 Apollo Drive 2630 Orchard Parkway Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P.
Chelmsford, MA 01824 San Jose, CA 95134 Lang, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan
Email: swallow@cisco.com email: jzyu@zaffire.com Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong Xue,
Lucy Yong, John Yu.
Gopala Tumuluri 6. Contact Address
Calient Networks Jonathan P. Lang Andre Fredette
5853 Rue Ferrari Calient Networks Hatteras Networks
San Jose, CA 95138 25 Castilian Drive P.O. Box 110025
email: krishna@calient.net Goleta, CA 93117 Research Triangle Park
Email: jplang@calient.net NC 27709-0025
Afredette@HatterasNetworks.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/