draft-ietf-ccamp-lmp-wdm-01.txt   draft-ietf-ccamp-lmp-wdm-02.txt 
CCAMP Working Group A. Fredette, Editor CCAMP Working Group A. Fredette, Editor
Internet Draft Hatteras Networks Internet Draft (Hatteras Networks)
Expiration Date: March 2003 J. Lang, Editor Category: Proposed Standard
Calient Networks Expiration Date: September 2003 J. Lang, Editor
(Rincon Networks)
September 2002 March 2003
Link Management Protocol (LMP) for DWDM Optical Line Systems Link Management Protocol (LMP) for Dense Wavelength Division
draft-ietf-ccamp-lmp-wdm-01.txt Multiplexing (DWDM) Optical Line Systems
draft-ietf-ccamp-lmp-wdm-02.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. 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.
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Abstract Abstract
The Link Management Protocol (LMP) is defined to manage traffic The Link Management Protocol (LMP) is defined to manage traffic
engineering (TE) links. In its present form, LMP focuses on peer engineering (TE) links. In its present form, LMP focuses on peer
nodes; i.e., nodes that peer in signaling and/or routing. In this nodes; i.e., nodes that peer in signaling and/or routing. In this
document we propose extensions to LMP to allow it to be used between document we propose extensions to LMP to allow it to be used between
a peer node and an adjacent optical line system (OLS). These a peer node and an adjacent optical line system (OLS). These
extensions are intended to satisfy the "Optical Link Interface extensions are intended to satisfy the "Optical Link Interface
Requirements" described in a companion document. Requirements" described in a companion document.
[Editor's note: "Changes from previous version" notes can be removed
prior to publication as an RFC.]
Changes from previous version: Changes from previous version:
o Editorial changes. o Editorial changes resulting from AD review.
o Removed the Trace monitoring section to be put in SONET/SDH
technology specific draft.
o Moved the LMP-WDM support bit from the common header of LMP
messages to a new LMP-WDM_CONFIG object.
1. Introduction 1. Introduction
Networks are being developed with routers, switches, optical Networks are being developed with routers, switches, optical cross-
crossconnects (OXCs), DWDM optical line systems (OLSs), and add-drop connects (OXCs), dense wavelength division multiplexing (DWDM)
multiplexors (ADMs) that use a common control plane [e.g., optical line systems (OLSs), and add-drop multiplexors (ADMs) that
Generalized MPLS (GMPLS)] to dynamically provision resources and to use a common control plane [e.g., Generalized MPLS (GMPLS)] to
provide network survivability using protection and restoration dynamically provision resources and to provide network survivability
techniques. using protection and restoration techniques.
The Link Management Protocol (LMP) is being developed as part of the The Link Management Protocol (LMP) is being developed as part of the
GMPLS protocol suite to manage traffic engineering (TE) links [LMP]. GMPLS protocol suite to manage traffic engineering (TE) links [LMP].
In its present form, LMP focuses on peer nodes; i.e., nodes that peer In its present form, LMP focuses on peer nodes; i.e., nodes that
in signaling and/or routing (e.g., OXC-to-OXC, as illustrated in peer in signaling and/or routing (e.g., OXC-to-OXC, as illustrated
Figure 1). In this document, extensions to LMP to allow it to be in Figure 1). In this document, extensions to LMP to allow it to be
used between a peer node and an adjacent optical line system (OLS) used between a peer node and an adjacent optical line system (OLS)
are proposed. These extensions are intended to satisfy the "Optical are proposed. These extensions are intended to satisfy the "Optical
Link Interface Requirements" described in [OLI]. It is assumed that Link Interface Requirements" described in [OLI]. It is assumed that
the reader is familiar with LMP as defined in [LMP]. the reader is familiar with LMP as defined in [LMP].
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| | ----- | | | | ----- | | | | ----- | | | | ----- | |
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
| | ----- | | | | ----- | | | | ----- | | | | ----- | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
skipping to change at page 3, line 46 skipping to change at page 4, line 44
two peer nodes and an LMP session between a peer node and an OLS, two peer nodes and an LMP session between a peer node and an OLS,
there are some differences as well. The former type of LMP session there are some differences as well. The former type of LMP session
is used to provide the basis for GMPLS signaling and routing. The is used to provide the basis for GMPLS signaling and routing. The
latter type of LMP session is used to augment knowledge about the latter type of LMP session is used to augment knowledge about the
links between peer nodes. links between peer nodes.
A peer node maintains its peer node - OLS LMP sessions and its peer A peer node maintains its peer node - OLS LMP sessions and its peer
node - peer node LMP sessions independently. This means that it MUST node - peer node LMP sessions independently. This means that it MUST
be possible for LMP sessions to come up in any order. In particular, be possible for LMP sessions to come up in any order. In particular,
it MUST be possible for a peer node - peer node LMP session to come 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. up in the absence of any peer node - OLS LMP sessions and vice
versa.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The reader is assumed to be familiar with the terminology in [LMP]. The reader is assumed to be familiar with the terminology in [LMP].
DWDM: Dense wavelength division multiplexor DWDM: Dense wavelength division multiplexor
OLS: Optical line system OLS: Optical line system
Opaque: Opaque:
A device is called X-opaque if it examines or modifies the X A device is called X-opaque if it examines or modifies the X
aspect of the signal while forwarding an incoming signal from aspect of the signal while forwarding an incoming signal from
input to output. input to output.
OXC: Optical crossconnect OXC: Optical cross-connect
Transparent: Transparent:
As defined in [LMP], a device is called X-transparent if it As defined in [LMP], a device is called X-transparent if it
forwards incoming signals from input to output without examining forwards incoming signals from input to output without examining
or modifying the X aspect of the signal. For example, a Frame or modifying the X aspect of the signal. For example, a Frame
Relay switch is network-layer transparent; an all-optical switch Relay switch is network-layer transparent; an all-optical switch
is electrically transparent. is electrically transparent.
1.2. Scope of LMP-WDM Protocol 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.
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 information to be exchanged between a peer node and an the necessary information to be exchanged between a peer node and an
OLS in this context. Never-the-less, the protocol described in this OLS in this context. Nevertheless, the protocol described in this
document provides the necessary framework in which to exchange document provides the necessary framework in which to exchange
whatever additional information is deemed appropriate. whatever additional information is deemed appropriate.
2. LMP Extensions for Optical Line Systems 2. LMP Extensions for Optical Line Systems
LMP currently consists of four main procedures, of which the first LMP currently consists of four main procedures, of which the first
two are mandatory and the last two are optional: two are mandatory and the last two are optional:
1. Control channel management 1. Control channel management
2. Link property correlation 2. Link property correlation
skipping to change at page 5, line 5 skipping to change at page 6, line 5
All four functions are supported in LMP-WDM. All four functions are supported in LMP-WDM.
2.1. Control Channel Management 2.1. Control Channel Management
As in [LMP], we do not specify the exact implementation of the As in [LMP], we do not specify the exact implementation of the
control channel; it could be, for example, a separate wavelength, control channel; it could be, for example, a separate wavelength,
fiber, Ethernet link, an IP tunnel routed over a separate management fiber, Ethernet link, an IP tunnel routed over a separate management
network, a multi-hop IP network, or the overhead bytes of a data network, a multi-hop IP network, or the overhead bytes of a data
link. link.
The control channel management for a peer node - OLS link is the same The control channel management for a peer node - OLS link is the
as for a peer node - peer node link, as described in [LMP]. same as for a peer node - peer node link, as described in [LMP].
To distinguish between a peer node - OLS LMP session from a peer node To distinguish between a peer node - OLS LMP session from a peer
- peer node LMP session, a new LMP-WDM CONFIG object is defined (C- node - peer node LMP session, a new LMP-WDM CONFIG object is defined
Type = TBA by IANA). The format of the CONFIG object is as follows: (C-Type = TBA by IANA). The format of the CONFIG object is as
follows:
Class = 6. Class = 6.
o C-Type = TBA, LMP-WDM_CONFIG o C-Type = TBA, LMP-WDM_CONFIG
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|W|O| (Reserved) | |W|O| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 32 skipping to change at page 6, line 33
The Reserved field should be sent as zero and ignored on receipt. The Reserved field should be sent as zero and ignored on receipt.
WDM: 1 bit WDM: 1 bit
This bit indicates support for the LMP-WDM extensions defined This bit indicates support for the LMP-WDM extensions defined
in this draft. in this draft.
OLS: 1 bit OLS: 1 bit
If set, this bit indicates that the sender is an optical line If set, this bit indicates that the sender is an optical line
system (OLS). If clear, this bit indicates that the sender is system (OLS). If clear, this bit indicates that the sender is a
a peer node. peer node.
The LMP-WDM extensions are designed for peer node - OLS LMP 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 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 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 -OLS LMP session between two peer nodes or a peer node - peer node
LMP session between a peer node and an OLS. LMP session between a peer node and an OLS.
If the node does not support the LMP-WDM extensions, it MUST reply If the node does not support the LMP-WDM extensions, it MUST reply
to the Config message with a ConfigNack message. to the Config message with a ConfigNack message.
skipping to change at page 6, line 12 skipping to change at page 7, line 15
in all subsequent Test messages) is used to differentiate Test in all subsequent Test messages) is used to differentiate Test
messages from different LMP Link Verification procedures. In messages from different LMP Link Verification procedures. In
addition to the Test procedure described in [LMP], the trace addition to the Test procedure described in [LMP], the trace
monitoring function of [LMP-SDH] may be used for link verification monitoring function of [LMP-SDH] may be used for link verification
when the OLS user ports are SONET or SDH. when the OLS user ports are SONET or SDH.
In a combined LMP and LMP-WDM context, there is an interplay between 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 the data links being managed by peer node - peer node LMP sessions
and peer node - OLS LMP sessions. For example, in Figure 2, the and peer node - OLS LMP sessions. For example, in Figure 2, the
OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1, 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 and the OXC2-OLS2 LMP session manages the data links between OXC2
OLS2. However, the OXC1-OXC2 LMP session manages the data links and OLS2. However, the OXC1-OXC2 LMP session manages the data links
between OXC1 and OXC2, which are actually a concatenation of the data between OXC1 and OXC2, which are actually a concatenation of the
links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and data links between OXC1 and OLS1, the DWDM span between OLS1 and
the data links between OXC2 and OLS2, and it is these concatenated OLS2, and the data links between OXC2 and OLS2, and it is these
links which comprise the TE links which are advertised in the GMPLS concatenated links which comprise the TE links which are advertised
TE link state database. in the GMPLS TE link state database.
The implication of this is that when the data links between OXC1 and The implication of this is that when the data links between OXC1 and
OXC2 are being verified, using the LMP link verification procedure, OXC2 are being verified, using the LMP link verification procedure,
OLS1 and OLS2 need to make themselves transparent with respect to OLS1 and OLS2 need to make themselves transparent with respect to
these concatenated data links. The co-ordination of verification of these concatenated data links. The coordination of verification of
OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is
responsibility of the peer nodes, OXC1 and OXC2. the responsibility of the peer nodes, OXC1 and OXC2.
It is also necessary for these peer nodes to understand the mappings 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 between the data links of the peer node - OLS LMP session and the
concatenated data links of the peer node - peer node LMP session. concatenated data links of the peer node - peer node LMP session.
2.3. Link Summarization 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 that Interface Ids and correlate the properties of the TE link. (Note
the term "TE Link" originated from routing/signaling applications of that the term "TE Link" originated from routing/signaling
LMP, whereas this concept does not necessarily apply to an OLS. applications of LMP, whereas this concept does not necessarily apply
However, the term is used in this document to remain consistent with to an OLS. However, the term is used in this document to remain
LMP terminology.) The LinkSummary message includes one or more consistent with LMP terminology.) The LinkSummary message includes
DATA_LINK objects. The contents of the DATA_LINK object consist of a one or more DATA_LINK objects. The contents of the DATA_LINK object
series of variable-length data items called Data Link sub-objects consist of a series of variable-length data items called Data Link
describing the capabilities of the data links. sub-objects describing the capabilities of the data links.
In this document, several additional Data Link sub-objects are In this document, several additional Data Link sub-objects are
defined to describe additional link characteristics. The link defined to describe additional link characteristics. The link
characteristics are, in general, those needed by the CSPF to select characteristics are, in general, those needed by the CSPF to select
the path for a particular LSP. These link characteristics describe the path for a particular LSP. These link characteristics describe
the specified peer node - OLS data link as well as the associated the specified peer node - OLS data link as well as the associated
DWDM span between the two OLSs. DWDM span between the two OLSs.
The format of the Data Link sub-objects follows the format described 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:
skipping to change at page 7, line 18 skipping to change at page 8, line 18
| 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 sub-object. 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
be at least 4, and MUST be a multiple of 4. at least 4, and MUST be a multiple of 4.
The following Link Characteristics are exchanged on a per data link The following Link Characteristics are exchanged on a per data link
basis. basis.
2.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 the assigned to a group of data links. This ID can be used to reduce the
control traffic in the event of a failure by enabling a single control traffic in the event of a failure by enabling a single
ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see
Section 2.4.1) to be used for a group of data links instead of Section 2.4.1) to be used for a group of data links instead of
individual ChannelStatus messages for each data link. A data link individual ChannelStatus messages for each data link. A data link
may be a member of multiple groups. This is achieved by including may be a member of multiple groups. This is achieved by including
multiple Link Group ID sub-objects in the LinkSummary message. 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 primarily to map (or group) data links into "failable entities" known
to the OLS. If one of those failable entities fails, all associated primarily to the OLS. If one of those failable entities fails, all
data links are failed and the peer node is notified with a single associated data links are failed and the peer node is notified with
message. a single 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. The data links associated with each laser would then each be OLS. The data links associated with each laser would then each be
assigned the Link Group ID for that laser. If a laser fails, the OLS assigned the Link Group ID for that laser. If a laser fails, the OLS
would then report a single failure affecting all of the data links would then report a single failure affecting all of the data links
with Link Group ID of the failed laser. The peer node that receives with Link Group ID of the failed laser. The peer node that receives
the single failure notification then knows which data links are the single failure notification then knows which data links are
affected. Similarly, an OLS could create a Link Group ID for a affected. Similarly, an OLS could create a Link Group ID for a
fiber, to report a failure affecting all of the data links associated fiber, to report a failure affecting all of the data links
with that fiber if a loss-of-signal (LOS) is detected for that fiber. associated with that fiber if a loss-of-signal (LOS) is detected for
that fiber.
The format of the Link Group ID sub-object (Type=TBD, Length=8) is as The format of the Link Group ID sub-object (Type=TBD, Length=8) is
follows: 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 | (Reserved) | | Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID | | Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt. The Reserved field should be sent as zero and ignored on receipt.
Link Group ID: 32 bits Link Group ID: 32 bits
Link Group ID 0xFFFFFFFF is reserved and indicates all data Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of Link Group links in a TE link. All data links are members of Link Group
0xFFFFFFFF by default. 0xFFFFFFFF by default.
2.3.2. Shared Risk Link Group Identifier (SRLG) 2.3.2. Shared Risk Link Group (SRLG) Identifier
This identifies the SRLGs of which the data link is a member. This This identifies the SRLGs of which the data link is a member. This
information may be configured on an OLS by the user and used for information may be configured on an OLS by the user and used for
diverse path computation (see [GMPLS-RTG]). 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, Length=(N+1)*4 where N
is the number of SRLG values) 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 | (Reserved) | | Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #1 | | SRLG value #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #2 | | SRLG value #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ............ | // ... //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #(N-1) | | SRLG value #(N-1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG value #N | | SRLG value #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt. The Reserved field should be sent as zero and ignored on receipt.
Length: 8 bits
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
See [GMPLS-RTG]. List as many SRLGs as apply. See [GMPLS-RTG]. List as many SRLGs as apply.
2.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 sub-object (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
skipping to change at page 9, line 37 skipping to change at page 10, line 37
BER: 8 bits BER: 8 bits
The exponent from the BER representation described above. I.e., 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. if the BER is 10 to the minus X, the BER field is set to X.
2.3.4. Optical Protection 2.3.4. Optical Protection
This indicates whether the link is protected by the OLS. This This indicates whether the link is protected by the OLS. This
information can be used as a measure of link capability. It may be information can be used as a measure of link capability. It may be
advertised by routing and used by signaling as a selection criterion advertised by routing and used by signaling as a selection criterion
as described in [GMPLS-SIG]. as described in [RFC3471].
The format of the Optical Protection sub-object (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 | (Reserved) | Link Flags| | Type | Length | (Reserved) | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt. The Reserved field should be sent as zero and ignored on receipt.
Link Flags: 6 bits Link Flags: 6 bits
Encoding for Link Flags is defined in Section 7 of [GMPLS-SIG]. Encoding for Link Flags is defined in Section 7 of [RFC3471].
2.3.5. Total Span Length 2.3.5. Total Span Length
This indicates the total distance of fiber in the OLS. This may be This indicates the total distance of fiber in the OLS. This may be
used as a routing metric or to estimate delay. used as a routing metric or to estimate delay.
The format of the Total Span Length sub-object (Type=TBD, Length=8) The format of the Total Span Length sub-object (Type=TBD, Length=8)
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 | (Reserved) | | Type | Length | (Reserved) |
skipping to change at page 10, line 54 skipping to change at page 12, line 4
2.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 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 a bit error rate (BER) Fault detection mechanisms may include a bit error rate (BER)
exceeding a threshold, loss of signal (LOS) and SONET/SDH-level exceeding a threshold, loss of signal (LOS) and SONET/SDH-level
errors. It is the responsibility of the OLS to translate these errors. It is the responsibility of the OLS to translate these
failures into OK, SF, or SD as described in [LMP]. failures into (Signal) OK, Signal Failure (SF), or Signal Degrade
(SD) as described in [LMP].
I.e., an OLS uses the messages defined in the LMP fault localization I.e., an OLS uses the messages defined in the LMP fault localization
procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest, procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest,
and ChannelStatusResponse Messages) to inform the adjacent peer node and ChannelStatusResponse Messages) to inform the adjacent peer node
of failures it has detected, in order to initiate the LMP fault of failures it has detected, in order to initiate the LMP fault
localization procedures between peer nodes, but it does not localization procedures between peer nodes, but it does not
participate in those procedures. participate in those procedures.
The OLS may also execute its own fault localization process to allow The OLS may also execute its own fault localization process to allow
it to determine the location of the fault along the DWDM span. For it to determine the location of the fault along the DWDM span. For
example, the OLS may be able to pinpoint the fault to a particular example, the OLS may be able to pinpoint the fault to a particular
amplifier in a span thousands of kilometers in length. amplifier in a span of thousands of kilometers in length.
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, a Link Each data link is identified by an Interface_ID. In addition, a Link
Group ID may be assigned to a group of data links (see Section Group ID may be assigned to a group of data links (see Section
2.3.1). The Link Group ID may be used to reduce the control traffic 2.3.1). The Link Group ID may be used to reduce the control traffic
by providing channel status information for a group of data links. A by providing channel status information for a group of data links. A
new LINK GROUP CHANNEL_STATUS object is defined below for this new LINK GROUP CHANNEL_STATUS object is defined below for this
purpose. This object may be used in place of the CHANNEL_STATUS purpose. This object may be used in place of the CHANNEL_STATUS
objects described in [LMP] in the ChannelStatus message. objects described in [LMP] in the ChannelStatus message.
2.4.1. LINK GROUP CHANNEL_STATUS Object 2.4.1. LINK_GROUP CHANNEL_STATUS Object
The LINK GROUP CHANNEL_STATUS object is used to indicate the status The LINK_GROUP CHANNEL_STATUS object is used to indicate the status
of the data links belonging to a particular Link Group. The of the data links belonging to a particular Link Group. The
correlation of data links to Group ID is made with the Link Group ID correlation of data links to Group ID is made with the Link Group ID
sub-object of 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 = 13, C-Type =TBA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Group ID | | Link Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status | |A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
skipping to change at page 12, line 16 skipping to change at page 13, line 20
Link Group ID 0xFFFFFFFF is reserved and indicates all data Link Group ID 0xFFFFFFFF is reserved and indicates all data
links in a TE link. All data links are members of Link Group links in a TE link. All data links are members of Link Group
0xFFFFFFFF by default. 0xFFFFFFFF by default.
Channel Status: 32 bits Channel Status: 32 bits
The values for the Channel Status field are defined in [LMP]. The values for the Channel Status field are defined in [LMP].
This Object is non-negotiable. This Object is non-negotiable.
3. Security Considerations 3. Intellectual Property Considerations
This document only defines new LMP objects extending the The IETF takes no position regarding the validity or scope of any
capabilities of [LMP]. This document does not introduce any new intellectual property or other rights that might be claimed to
security considerations. pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
4. References 4. References
4.1. Normative References 4.1. Normative References
[GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in
Support of Generalized MPLS," (work in progress).
[LMP] Lang, J. P., ed., "The Link Management Protocol (LMP)," [LMP] Lang, J. P., ed., "The Link Management Protocol (LMP),"
(work in progress). (work in progress).
[GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
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 [LMP-SDH] Lang, J. P., Papadimitriou, D.,"SONET/SDH Encoding for
Link Management Protocol (LMP) Test messages," (work in Link Management Protocol (LMP) Test messages," (work in
progress). progress).
[GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in
Support of Generalized MPLS," (work in progress). [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC3471] Ashwood-Smith, P., Banerjee, A., et al, "Generalized
MPLS - Signaling Functional Description," RFC 3471,
January 2003.
[OSPF-TE] Katz, D, Yeung, D., and Kompella, K., "Traffic [OSPF-TE] Katz, D, Yeung, D., and Kompella, K., "Traffic
Engineering Extensions to OSPF Version 2," (work in Engineering Extensions to OSPF Version 2," (work in
progress). progress).
4.2. Informative References 4.2. Informative References
[OLI] Fredette, A., Editor, "Optical Link Interface [OLI] Fredette, A., Editor, "Optical Link Interface
Requirements", (work in progress). Requirements," (work in progress).
5. Contributors 5. Security Considerations
Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake, LMP message security uses IPsec as described in [LMP]. This document
David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette, Rohit only defines new LMP objects that are carried in existing LMP
Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P. messages. As such, this document introduces no other new security
Lang, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan considerations not covered in [LMP].
Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong Xue,
Lucy Yong, John Yu.
6. Contact Address 6. IANA Considerations
Jonathan P. Lang Andre Fredette
Calient Networks Hatteras Networks LMP defines the following name spaces that require management:
25 Castilian Drive P.O. Box 110025
Goleta, CA 93117 Research Triangle Park - LMP Message Type.
Email: jplang@calient.net NC 27709-0025 - LMP Object Class.
Afredette@HatterasNetworks.com - LMP Object Class type (C-Type) unique within the Object Class.
- LMP Sub-object Class type (Type) unique within the Object Class.
This memo introduces the following name spaces which need
assignment:
o CONFIG
- LMP-WDM_CONFIG (suggested C-Type = 2)
o CHANNEL_STATUS
- LINK_GROUP (suggested C-Type = 4)
LMP sub-object Class type (C-Type) should be assigned from the range
0-127.
o DATA_LINK
- Link_GroupId (suggested sub-object Type = 3)
- SRLG (suggested sub-object Type = 4)
- BER_Estimate (suggested sub-object Type = 5)
- Optical_Protection (suggested sub-object Type = 6)
- Total_Span_Length (suggested sub-object Type = 7)
- Administrative_Group (suggested sub-object Type = 8)
7. Contributors
Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John
Drake, David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette,
Rohit Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan,
Jonathan P. Lang, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou,
Jagan Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong
Xue, Lucy Yong, John Yu.
8. Contact Address
Andre Fredette
Hatteras Networks
P.O. Box 110025
Research Triangle Park
NC 27709-0025, USA
E-mail: Afredette@HatterasNetworks.com
Jonathan P. Lang
Rincon Networks
110 El Paseo
Santa Barbara, CA 93101, USA
E-mail: jplang@ieee.org
9. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

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