draft-ietf-ccamp-lmp-wdm-03.txt | draft-ietf-ccamp-lmp-wdm-04.txt | |||
---|---|---|---|---|
Network Working Group A. Fredette, Editor | This Internet-Draft, draft-ietf-ccamp-lmp-wdm-03.txt, was published as a Proposed Standard, RFC 4209 | |||
Internet Draft (Hatteras Networks) | (http://www.ietf.org/rfc/rfc4209.txt), on 2005-11-1. | |||
Category: Standards Track | ||||
Expiration Date: June 2004 J. Lang, Editor | ||||
(Rincon Networks) | ||||
December 2003 | ||||
Link Management Protocol (LMP) for Dense Wavelength Division | ||||
Multiplexing (DWDM) Optical Line Systems | ||||
draft-ietf-ccamp-lmp-wdm-03.txt | ||||
Status of this Memo | ||||
This document is an Internet-Draft and is in full conformance with | ||||
all provisions of Section 10 of RFC2026. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF), its areas, and its working groups. Note that | ||||
other groups may also distribute working documents as Internet- | ||||
Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six | ||||
months and may be updated, replaced, or obsoleted by other documents | ||||
at any time. It is inappropriate to use Internet- Drafts as | ||||
reference material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
Abstract | ||||
The Link Management Protocol (LMP) is defined to manage traffic | ||||
engineering (TE) links. In its present form, LMP focuses on peer | ||||
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 | ||||
a peer node and an adjacent optical line system (OLS). These | ||||
extensions are intended to satisfy the "Optical Link Interface | ||||
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: | ||||
o Modified the IANA Considerations section as a result of IESG | ||||
review. | ||||
1. Introduction | ||||
Networks are being developed with routers, switches, optical cross- | ||||
connects (OXCs), dense wavelength division multiplexing (DWDM) | ||||
optical line systems (OLSs), and add-drop multiplexors (ADMs) that | ||||
use a common control plane [e.g., Generalized MPLS (GMPLS)] to | ||||
dynamically provision resources and to provide network survivability | ||||
using protection and restoration techniques. | ||||
The Link Management Protocol (LMP) is being developed as part of the | ||||
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 signaling and/or routing (e.g., OXC-to-OXC, as illustrated | ||||
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) | ||||
are proposed. These extensions are intended to satisfy the "Optical | ||||
Link Interface Requirements" described in [OLI]. It is assumed that | ||||
the reader is familiar with LMP as defined in [LMP]. | ||||
+------+ +------+ +------+ +------+ | ||||
| | ----- | | | | ----- | | | ||||
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | | ||||
| | ----- | | | | ----- | | | ||||
+------+ +------+ +------+ +------+ | ||||
^ ^ | ||||
| | | ||||
+---------------------LMP---------------------+ | ||||
Figure 1: LMP Model | ||||
Consider two peer nodes (e.g., two OXCs) interconnected by a | ||||
wavelength-multiplexed link; i.e., a DWDM optical link (see Figure 1 | ||||
above). Information about the configuration of this link and its | ||||
current state is known by the two OLSs (OLS1 and OLS2), and allowing | ||||
them to communicate this information to the corresponding peer nodes | ||||
(OXC1 and OXC2) via LMP can improve network usability by reducing | ||||
required manual configuration and by enhancing fault detection and | ||||
recovery. | ||||
Information about the state of LSPs using the DWDM optical link is | ||||
known by the peer nodes (OXC1 and OXC2), and allowing them to | ||||
communicate this information to the corresponding OLSs (OLS1 and | ||||
OLS2) is useful for alarm management and link monitoring. Alarm | ||||
management is important because the administrative state of an LSP, | ||||
known to the peer nodes (e.g., via the Admin Status object of GMPLS | ||||
signaling [GMPLS-SIG]) can be used to suppress spurious alarm | ||||
reporting from the OLSs. | ||||
The model for extending LMP to OLSs is shown in Figure 2. | ||||
+------+ +------+ +------+ +------+ | ||||
| | ----- | | | | ----- | | | ||||
| OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | | ||||
| | ----- | | | | ----- | | | ||||
+------+ +------+ +------+ +------+ | ||||
^ ^ ^ ^ ^ ^ | ||||
| | | | | | | ||||
| +-----LMP-----+ +-----LMP-----+ | | ||||
| | | ||||
+----------------------LMP-----------------------+ | ||||
Figure 2: Extended LMP Model | ||||
In this model, a peer node may have LMP sessions with adjacent OLSs | ||||
as well as adjacent peer nodes. In Figure 2, for example, the OXC1- | ||||
OXC2 LMP session can be used to build traffic-engineering (TE) links | ||||
for GMPLS signaling and routing, as described in [LMP]. The OXC1- | ||||
OLS1 and the OXC2-OLS2 LMP sessions are used to exchange information | ||||
about the configuration of the DWDM optical link and its current | ||||
state and information about the state of LSPs using that link. | ||||
The latter type of LMP sessions is discussed in this document. It is | ||||
important to note that a peer node may have LMP sessions with one or | ||||
more OLSs and an OLS may have LMP sessions with one or more peer | ||||
nodes. | ||||
Although there are many similarities between an LMP session between | ||||
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 | ||||
is used to provide the basis for GMPLS signaling and routing. The | ||||
latter type of LMP session is used to augment knowledge about the | ||||
links between peer nodes. | ||||
A peer node maintains its peer node - OLS LMP sessions and its peer | ||||
node - peer node LMP sessions independently. This means that it MUST | ||||
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 | ||||
up in the absence of any peer node - OLS LMP sessions and vice | ||||
versa. | ||||
1.1. Terminology | ||||
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 cross-connect | ||||
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 | ||||
OLSs. In particular, this document is intended for use with OLSs | ||||
having SONET, SDH, and Ethernet user ports. | ||||
At the time of this writing, work is ongoing in the area of fully | ||||
transparent wavelength routing; however, it is premature to identify | ||||
the necessary information to be exchanged between a peer node and an | ||||
OLS in this context. Nevertheless, the protocol described in this | ||||
document provides the necessary framework in which to exchange | ||||
whatever additional information is deemed appropriate. | ||||
2. LMP Extensions for Optical Line Systems | ||||
LMP currently consists of four main procedures, of which the first | ||||
two are mandatory and the last two are optional: | ||||
1. Control channel management | ||||
2. Link property correlation | ||||
3. Link verification | ||||
4. Fault management | ||||
All four functions are supported in LMP-WDM. | ||||
2.1. Control Channel Management | ||||
As in [LMP], we do not specify the exact implementation of the | ||||
control channel; it could be, for example, a separate wavelength, | ||||
fiber, Ethernet link, an IP tunnel routed over a separate management | ||||
network, a multi-hop IP network, or the overhead bytes of a data | ||||
link. | ||||
The control channel management for a peer node - OLS link is the | ||||
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 - 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: | ||||
Class = 6. | ||||
o C-Type = TBA, LMP-WDM_CONFIG | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|W|O| (Reserved) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
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 VerifyTransportMechanism (included in the BeginVerify and | ||||
BeginVerifyAck messages) is used to allow nodes to negotiate a link | ||||
verification method and is essential for line systems that have | ||||
access to overhead bytes rather than the payload. The VerifyId | ||||
(provided by the remote node in the BeginVerifyAck message, and used | ||||
in all subsequent Test messages) is used to differentiate Test | ||||
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. | ||||
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 coordination 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 | ||||
Interface Ids and correlate the properties of the TE link. (Note | ||||
that the term "TE Link" originated from routing/signaling | ||||
applications of LMP, whereas this concept does not necessarily apply | ||||
to an OLS. However, the term is used in this document to remain | ||||
consistent with LMP terminology.) The LinkSummary message includes | ||||
one or more DATA_LINK objects. The contents of the DATA_LINK object | ||||
consist of a series of variable-length data items called Data Link | ||||
sub-objects describing the capabilities of the data links. | ||||
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: | ||||
0 1 | ||||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ | ||||
| Type | Length | (Sub-object contents) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ | ||||
Type: 8 bits | ||||
The Type indicates the type of contents of the sub-object. | ||||
Length: 8 bits | ||||
The Length field contains the total length of the sub-object in | ||||
bytes, including the Type and Length fields. The Length MUST be | ||||
at least 4, and MUST be a multiple of 4. | ||||
The following Link Characteristics are exchanged on a per data link | ||||
basis. | ||||
2.3.1. Link Group ID | ||||
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 | ||||
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 | ||||
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 | ||||
individual ChannelStatus messages for each data link. A data link | ||||
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 | ||||
upon the types of fault correlation and aggregation supported by a | ||||
given OLS. From a practical perspective, the Link Group ID is used | ||||
to map (or group) data links into "failable entities" known | ||||
primarily to the OLS. If one of those failable entities fails, all | ||||
associated data links are failed and the peer node is notified with | ||||
a single message. | ||||
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 | ||||
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 | ||||
with Link Group ID of the failed laser. The peer node that receives | ||||
the single failure notification then knows which data links are | ||||
affected. Similarly, an OLS could create a Link Group ID for a | ||||
fiber, to report a failure affecting all of the data links | ||||
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 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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type | Length | (Reserved) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Link Group ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Reserved field should be sent as zero and ignored on receipt. | ||||
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. | ||||
2.3.2. Shared Risk Link Group (SRLG) Identifier | ||||
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 | ||||
diverse path computation (see [GMPLS-RTG]). | ||||
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 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) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| SRLG value #1 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| SRLG value #2 | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
// ... // | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| SRLG value #(N-1) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| SRLG value #N | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Reserved field should be sent as zero and ignored on receipt. | ||||
Shared Risk Link Group Value: 32 bits | ||||
See [GMPLS-RTG]. List as many SRLGs as apply. | ||||
2.3.3. Bit Error Rate (BER) Estimate | ||||
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 | ||||
relative to the total number of bits received in a transmission, | ||||
usually expressed as ten to a negative power. For example, a | ||||
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 | ||||
error. The BER is an indication of overall signal quality. | ||||
The format of the BER Estimate sub-object (Type=TBD; Length=4) 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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type | Length | BER | (Reserved) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Reserved field should be sent as zero and ignored on receipt. | ||||
BER: 8 bits | ||||
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. | ||||
2.3.4. Optical Protection | ||||
This indicates whether the link is protected by the OLS. This | ||||
information can be used as a measure of link capability. It may be | ||||
advertised by routing and used by signaling as a selection criterion | ||||
as described in [RFC3471]. | ||||
The format of the Optical Protection sub-object (Type=TBD; Length=4) | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type | Length | (Reserved) | Link Flags| | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Reserved field should be sent as zero and ignored on receipt. | ||||
Link Flags: 6 bits | ||||
Encoding for Link Flags is defined in Section 7 of [RFC3471]. | ||||
2.3.5. Total Span Length | ||||
This indicates the total distance of fiber in the OLS. This may be | ||||
used as a routing metric or to estimate delay. | ||||
The format of the Total Span Length sub-object (Type=TBD, Length=8) | ||||
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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type | Length | (Reserved) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Span Length | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Reserved field should be sent as zero and ignored on receipt. | ||||
Span Length: 32 bits | ||||
This value represents the total Length of the WDM span in meters | ||||
expressed as an unsigned (long) integer. | ||||
2.3.6. Administrative Group (Color) | ||||
The administrative group (or Color) to which the data link belongs. | ||||
The format of the Administrative Group sub-object (Type=TBD, | ||||
Length=8) 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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Type | Length | (Reserved) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Administrative Group | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
The Reserved field should be sent as zero and ignored on receipt. | ||||
Administrative Group: 32 bits | ||||
A 32 bit value as defined in [RFC3630]. | ||||
2.4. Fault Management | ||||
Fault management consists of three major functions: | ||||
1. Fault Detection | ||||
2. Fault Localization | ||||
3. Fault Notification | ||||
The fault detection mechanisms are the responsibility of the | ||||
individual nodes and are not specified as part of this protocol. | ||||
Fault detection mechanisms may include a bit error rate (BER) | ||||
exceeding a threshold, loss of signal (LOS) and SONET/SDH-level | ||||
errors. It is the responsibility of the OLS to translate these | ||||
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 | ||||
procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest, | ||||
and ChannelStatusResponse Messages) to inform the adjacent peer node | ||||
of failures it has detected, in order to initiate the LMP fault | ||||
localization procedures between peer nodes, but it does not | ||||
participate in those procedures. | ||||
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 | ||||
example, the OLS may be able to pinpoint the fault to a particular | ||||
amplifier in a span of thousands of kilometers in length. | ||||
To report data link failures and recovery conditions, LMP-WDM uses | ||||
the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and | ||||
ChannelStatusResponse Messages defined in [LMP]. | ||||
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 | ||||
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 | ||||
new LINK GROUP CHANNEL_STATUS object is defined below for this | ||||
purpose. This object may be used in place of the CHANNEL_STATUS | ||||
objects described in [LMP] in the ChannelStatus message. | ||||
2.4.1. LINK_GROUP CHANNEL_STATUS Object | ||||
The LINK_GROUP CHANNEL_STATUS object is used to indicate the status | ||||
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 | ||||
sub-object of the DATA_LINK Object. | ||||
The format of the LINK_GROUP CHANNEL_STATUS object is as follows | ||||
(Class = 13, C-Type =TBA 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 | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Link Group ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|A|D| Channel Status | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| : | | ||||
// : // | ||||
| : | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Link Group ID | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
|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. Intellectual Property Considerations | ||||
The IETF takes no position regarding the validity or scope of any | ||||
intellectual property or other rights that might be claimed to | ||||
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.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., Editor, "The Link Management Protocol | ||||
(LMP)," (work in progress). | ||||
[LMP-SDH] Lang, J. P., Papadimitriou, D., "SONET/SDH Encoding for | ||||
Link Management Protocol (LMP) Test messages," (work in | ||||
progress). | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
Requirement Levels," BCP 14, RFC 2119, March 1997. | ||||
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label | ||||
Switching (GMPLS) - Signaling Functional Description," | ||||
RFC 3471, January 2003. | ||||
[RFC3630] Katz, D., Yeung, D., and Kompella, K., "Traffic | ||||
Engineering (TE) Extensions to OSPF Version 2," RFC | ||||
3630, September 2003. | ||||
4.2. Informative References | ||||
[OLI] Fredette, A., Editor, "Optical Link Interface | ||||
Requirements," (work in progress). | ||||
5. Security Considerations | ||||
LMP message security uses IPsec as described in [LMP]. This document | ||||
only defines new LMP objects that are carried in existing LMP | ||||
messages. As such, this document introduces no other new security | ||||
considerations not covered in [LMP]. | ||||
6. IANA Considerations | ||||
LMP [LMP] defines the following name spaces and how IANA can make | ||||
assignments in those namespaces: | ||||
- LMP Message Type. | ||||
- LMP Object Class. | ||||
- 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 new assignments: | ||||
LMP Object Class Types: | ||||
o under CONFIG class name (as defined in [LMP]) | ||||
- LMP-WDM_CONFIG (suggested C-Type = 2) | ||||
o under CHANNEL_STATUS class name (as defined in [LMP]) | ||||
- LINK_GROUP (suggested C-Type = 4) | ||||
LMP Sub-Object Class names: | ||||
o under DATA_LINK Class name (as defined in [LMP]) | ||||
- 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 | ||||
EMail: Afredette@HatterasNetworks.com | ||||
Jonathan P. Lang | ||||
Rincon Networks | ||||
829 De La Vina, Suite 220 | ||||
Santa Barbara, CA 93101, USA | ||||
EMail: 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. 1 change blocks. | ||||
0 lines changed or deleted | 0 lines changed or added | |||
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |