doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc4209.txt b/doc/rfc/rfc4209.txt
new file mode 100644
index 0000000..008d986
--- /dev/null
+++ b/doc/rfc/rfc4209.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                   A. Fredette, Ed.
+Request for Comments: 4209                             Hatteras Networks
+Category: Standards Track                                   J. Lang, Ed.
+                                                              Sonos Inc.
+                                                            October 2005
+
+
+                  Link Management Protocol (LMP) for
+   Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+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.  This
+   document proposes 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.
+
+1.  Introduction
+
+   Networks are being developed with routers, switches, optical cross-
+   connects (OXCs), dense wavelength division multiplexing (DWDM)
+   optical line systems (OLSes), 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
+   [RFC4204].  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 are
+   proposed to allow it to be used between a peer node and an adjacent
+   optical line system (OLS).  These extensions are intended to satisfy
+
+
+
+Fredette & Lang             Standards Track                     [Page 1]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   the "Optical Link Interface Requirements" described in [OLI].  It is
+   assumed that the reader is familiar with LMP, as defined in
+   [RFC4204].
+
+         +------+       +------+       +------+       +------+
+         |      | ----- |      |       |      | ----- |      |
+         | 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 OLSes (OLS1 and OLS2).  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 OLSes (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 [RFC3471]), can be used to suppress spurious alarm
+   reporting from the OLSes.
+
+   The model for extending LMP to OLSes is shown in Figure 2.
+
+         +------+       +------+       +------+       +------+
+         |      | ----- |      |       |      | ----- |      |
+         | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
+         |      | ----- |      |       |      | ----- |      |
+         +------+       +------+       +------+       +------+
+           ^  ^             ^              ^             ^  ^
+           |  |             |              |             |  |
+           |  +-----LMP-----+              +-----LMP-----+  |
+           |                                                |
+           +----------------------LMP-----------------------+
+
+                      Figure 2: Extended LMP Model
+
+
+
+
+Fredette & Lang             Standards Track                     [Page 2]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   In this model, a peer node may have LMP sessions with adjacent OLSes,
+   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 [RFC4204].  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 OLSes 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-to-OLS LMP sessions and its peer
+   node-to-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-to-peer node LMP
+   session to come up in the absence of any peer node-to-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
+   [RFC4204].
+
+   DWDM: Dense wavelength division multiplexing
+
+   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
+
+
+
+Fredette & Lang             Standards Track                     [Page 3]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   Transparent:
+
+      As defined in [RFC4204], 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
+   OLSes.  In particular, this document is intended for use with OLSes
+   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
+   additional information that 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 [RFC4204], 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-to-OLS link is the
+   same as for a peer node-to-peer node link, as described in [RFC4204].
+
+   To distinguish between a peer node-to-OLS LMP session and a peer
+   node-to-peer node LMP session, a new LMP-WDM CONFIG object is defined
+   (C-Type = 2).  The format of the CONFIG object is as follows:
+
+
+
+
+Fredette & Lang             Standards Track                     [Page 4]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   Class = 6
+
+   o     C-Type = 2, 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 document.
+
+   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-to-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-to-OLS LMP session between two peer nodes or a peer node-to-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 OLSes is the same as described in
+   [RFC4204].  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
+
+
+
+
+
+Fredette & Lang             Standards Track                     [Page 5]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   addition to the Test procedure described in [RFC4204], the trace
+   monitoring function of [RFC4207] 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-to-peer node LMP sessions
+   and peer node-to-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.  It is these concatenated links
+   that comprise the TE links that 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 [RFC4204], 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, and 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-to-OLS data link, as well as the associated
+   DWDM span between the two OLSes.
+
+
+
+
+
+
+Fredette & Lang             Standards Track                     [Page 6]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   The format of the Data Link sub-objects follows the format described
+   in [RFC4204] 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 on
+   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 a 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
+
+
+
+Fredette & Lang             Standards Track                     [Page 7]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   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 = 3, 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 [RFC4202]).
+
+   The format of the SRLG sub-object (Type = 4, 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.
+
+
+
+Fredette & Lang             Standards Track                     [Page 8]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   Shared Risk Link Group Value: 32 bits
+
+         See [RFC4202].  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 = 5; 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.  That
+         is, 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 = 6; 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.
+
+
+
+Fredette & Lang             Standards Track                     [Page 9]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+   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 = 7, 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 = 8, 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].
+
+
+
+
+Fredette & Lang             Standards Track                    [Page 10]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+2.4.  Fault Management
+
+   The Fault Management procedure used between a peer and an OLS follows
+   the procedures described in [RFC4204]; some further extensions are
+   defined in this section.  The information learned from the OLS-peer
+   fault management procedures may be used to trigger peer-peer LMP
+   fault management, or may be used to trigger GMPLS signaling/routing
+   procedures directly.
+
+   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, and 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 [RFC4204].
+
+   That is, 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 [RFC4204].
+
+   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 [RFC4204] in the ChannelStatus message.
+
+
+
+
+Fredette & Lang             Standards Track                    [Page 11]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+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 = 4):
+
+    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
+
+         The Link Group ID 0xFFFFFFFF is reserved and indicates all data
+         links in a TE link.  All data links are members of the Link
+         Group 0xFFFFFFFF by default.
+
+   Channel Status: 32 bits
+
+         The values for the Channel Status field are defined in
+         [RFC4204].
+
+   This object is non-negotiable.
+
+3.  Security Considerations
+
+   LMP message security uses IPsec, as described in [RFC4204].  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 [RFC4204].
+
+
+
+
+
+
+Fredette & Lang             Standards Track                    [Page 12]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+4.  IANA Considerations
+
+   LMP [RFC4204] defines the following name spaces and the ways in which
+   IANA can make assignments to these 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 [RFC4204])
+         -  LMP-WDM_CONFIG       (C-Type = 2)
+
+      o  under CHANNEL_STATUS class name (as defined in [RFC4204])
+         -  LINK_GROUP           (C-Type = 4)
+
+   LMP Sub-Object Class names:
+
+      o  under DATA_LINK Class name (as defined in [RFC4204])
+         -  Link_GroupId         (sub-object Type = 3)
+         -  SRLG                 (sub-object Type = 4)
+         -  BER_Estimate         (sub-object Type = 5)
+         -  Optical_Protection   (sub-object Type = 6)
+         -  Total_Span_Length    (sub-object Type = 7)
+         -  Administrative_Group (sub-object Type = 8)
+
+5.  Contributors
+
+   The authors would like to acknowledge 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, and
+   John Yu.
+
+
+
+
+
+
+
+
+
+
+
+
+Fredette & Lang             Standards Track                    [Page 13]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC4202]   Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
+               Extensions in Support of Generalized Multi-Protocol Label
+               Switching (GMPLS)", RFC 4202, September 2005.
+
+   [RFC4204]   Lang, J., Ed., "The Link Management Protocol (LMP)", RFC
+               4204, September 2005.
+
+   [RFC4207]   Lang, J., and D. Papadimitriou, "Synchronous Optical
+               Network (SONET)/Synchronous Digital Hierarchy (SDH)
+               Encoding for Link Management Protocol (LMP) Test
+               Messages", RFC 4207, September 2005.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3471]   Berger, L., "Generalized Multi-Protocol Label Switching
+               (GMPLS) Signaling Functional Description", RFC 3471,
+               January 2003.
+
+   [RFC3630]   Katz, D., Kompella, K., and D. Yeung, "Traffic
+               Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
+               September 2003.
+
+6.2.  Informative References
+
+   [OLI]       Fredette, A., Editor, "Optical Link Interface
+               Requirements", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fredette & Lang             Standards Track                    [Page 14]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+Editors' Addresses
+
+   Andre Fredette
+   Hatteras Networks
+   P.O. Box 110025
+   Research Triangle Park
+   NC 27709-0025, USA
+
+   EMail: Afredette@HatterasNetworks.com
+
+
+   Jonathan P. Lang
+   Sonos, Inc.
+   223 E. De La Guerra St.
+   Santa Barbara, CA 93101
+
+   EMail: jplang@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fredette & Lang             Standards Track                    [Page 15]
+
+RFC 4209           LMP for DWDM Optical Line Systems        October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Fredette & Lang             Standards Track                    [Page 16]
+