RFC 4209

Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems

📅 published October 2005, from ietf

Network Working Group 🎀 A. Fredette, Ed. (Hatteras Networks) Request for Comments: 4209 Category: Standards Track ✨ Date: October 2005 Editors: A. Fredette, Ed., Hatteras Networks, and J. Lang, Ed., Sonos Inc. Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates 🌸

Status of This Memo 💅

okay so this doc is an Internet standards track protocol spec for the Internet community, and it's basically asking for discussion and suggestions for improvements 🫶 If you want to know where this protocol stands officially, check the current edition of the "Internet Official Protocol Standards" (STD 1). And yes, distribution of this memo is unlimited, so share it with everyone 🍓

Copyright (C) The Internet Society (2005).

Abstract 🧚

okay so the Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links 💖 Right now LMP is all about peer nodes, which are nodes that peer in signaling and/or routing. This document proposes extensions so LMP can be used between a peer node and an adjacent optical line system (OLS) 🌈 These extensions are meant to satisfy the "Optical Link Interface Requirements" described in a companion document, and that's the whole vibe ✨

1. Introduction ✨

Networks are being built with routers, switches, optical cross-connects (OXCs), dense wavelength division multiplexing (DWDM) optical line systems (OLSes), and add-drop multiplexors (ADMs) 💜 They all use a common control plane, like Generalized MPLS (GMPLS), so they can dynamically provision resources and keep the network surviving with protection and restoration techniques. It's giving reliability 👑

LMP is part of the GMPLS protocol suite and manages traffic engineering (TE) links [RFC4204]. Right now it focuses on peer nodes, meaning nodes that peer in signaling and/or routing (for example, OXC-to-OXC, as shown in Figure 1) 🎀 This document extends LMP so it can be used between a peer node and an adjacent OLS. These extensions are meant to satisfy the "Optical Link Interface Requirements" described in [OLI]. It's assumed you already know LMP from [RFC4204] 🫶

      +------+       +------+       +------+       +------+
      |      | ----- |      |       |      | ----- |      |
      | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
      |      | ----- |      |       |      | ----- |      |
      +------+       +------+       +------+       +------+
         ^                                             ^
         |                                             |
         +---------------------LMP---------------------+

                       Figure 1: LMP Model

Picture two peer nodes (say, two OXCs) connected by a wavelength-multiplexed link, which is a DWDM optical link (see Figure 1 above) 🌸 The two OLSes (OLS1 and OLS2) know the configuration of this link and its current state. If they can tell the matching peer nodes (OXC1 and OXC2) about it over LMP, the network gets easier to use because there's less manual configuration to do, and fault detection and recovery get better 💅

The peer nodes (OXC1 and OXC2) know the state of LSPs using the DWDM optical link. Letting them share that info with the OLSes (OLS1 and OLS2) helps with alarm management and link monitoring 🔥 Alarm management really matters here, because the administrative state of an LSP, which the peer nodes know through the Admin Status object of GMPLS signaling [RFC3471], can be used to stop spurious alarm reporting from the OLSes 🙈

Here's the model for extending LMP to OLSes, shown in Figure 2 🧚

      +------+       +------+       +------+       +------+
      |      | ----- |      |       |      | ----- |      |
      | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 |
      |      | ----- |      |       |      | ----- |      |
      +------+       +------+       +------+       +------+
        ^  ^             ^              ^             ^  ^
        |  |             |              |             |  |
        |  +-----LMP-----+              +-----LMP-----+  |
        |                                                |
        +----------------------LMP-----------------------+

                   Figure 2: Extended LMP Model

In this model, a peer node can have LMP sessions with adjacent OLSes as well as with adjacent peer nodes 💖 In Figure 2, the OXC1-OXC2 LMP session can build traffic-engineering (TE) links for GMPLS signaling and routing, as described in [RFC4204]. The OXC1-OLS1 and OXC2-OLS2 LMP sessions swap info about the configuration and current state of the DWDM optical link, plus info about the state of LSPs using that link 🌈

This document is about the second kind of LMP session. Also, a peer node can have LMP sessions with one or more OLSes, and an OLS can have LMP sessions with one or more peer nodes 🦋

LMP sessions between two peer nodes and LMP sessions between a peer node and an OLS have a lot in common, but they're different too ✨ The peer-to-peer kind provides the basis for GMPLS signaling and routing. The peer-node-to-OLS kind is used to add to what's known about the links between peer nodes 👑

A peer node keeps its peer node-to-OLS LMP sessions and its peer node-to-peer node LMP sessions independently 💅 That means LMP sessions MUST be able to come up in any order. Specifically, a peer node-to-peer node LMP session MUST be able to come up without 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] 💜

You're assumed to know 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 🔥
  • 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, and an all-optical switch is electrically transparent. ✨

1.2. Scope of LMP-WDM Protocol 🦋

This document focuses on the extensions needed for opaque OLSes 👑 It's specifically meant for OLSes that have SONET, SDH, and Ethernet user ports 💖

Work on fully transparent wavelength routing is still ongoing. It's too early to say what info a peer node and an OLS should swap in that context 🥺 Even so, the protocol here gives you the framework to swap any extra info that turns out to be appropriate 🌈

2. LMP Extensions for Optical Line Systems 🧚

LMP has four main procedures. 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 💖

Same as in [RFC4204], this doc doesn't pin down the exact implementation of the control channel 🫶 It could be a separate wavelength, a fiber, an Ethernet link, an IP tunnel routed over a separate management network, a multi-hop IP network, or the overhead bytes of a data link 🦋

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 tell a peer node-to-OLS LMP session apart from a peer node-to-peer node LMP session, there's a new LMP-WDM CONFIG object (C-Type = 2) 👑 Here's the format:

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 shows support for the LMP-WDM extensions defined in this document 🌸
  • OLS (1 bit): If set, this bit means the sender is an optical line system (OLS). If clear, it means the sender is a peer node 🍓

The LMP-WDM extensions are designed for peer node-to-OLS LMP sessions 🙈 The OLS bit lets a node say whether it's an OLS or a peer node. That's what catches misconfiguration, like a peer node-to-OLS LMP session that's really between two peer nodes, or a peer node-to-peer node LMP session that's really between a peer node and an OLS 🔥

If the node doesn't support the LMP-WDM extensions, it MUST reply to the Config message with a ConfigNack message 😭

And if a peer node that's configured to run LMP-WDM gets a Config message with the OLS bit clear in the LMP-WDM_CONFIG object, it MUST reply to the Config message with a ConfigNack message too 💀

okay so the Test procedure for OLSes is literally the same one from [RFC4204] 🫶 no need to reinvent the wheel, bestie. The VerifyTransportMechanism (it shows up in both the BeginVerify and BeginVerifyAck messages) is how nodes negotiate which link verification method to use, and it's essential for line systems that only get to see overhead bytes instead of the payload 💅. The VerifyId is the one the remote node hands over in the BeginVerifyAck message, and then every Test message uses it. It's what keeps Test messages from different LMP Link Verification procedures from getting mixed up 🦋. Also, on top of the Test procedure from [RFC4204], the trace monitoring function of [RFC4207] can be used for link verification when the OLS user ports are SONET or SDH ✨.

In a combined LMP and LMP-WDM setup, things get a little plot twisty 🎀. There's an interplay between the data links managed by peer node-to-peer node LMP sessions and the ones managed by 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. But the OXC1-OXC2 LMP session manages the data links between OXC1 and OXC2, and those 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. These concatenated links are what make up the TE links that get advertised in the GMPLS TE link state database 👑.

So here's the vibe check: 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 those concatenated data links 🙈. Coordinating the verification of the OXC1-OLS1 and OXC2-OLS2 data links so that transparency actually happens is the responsibility of the peer nodes, OXC1 and OXC2. It's also necessary for those peer nodes to understand the mappings between the data links of the peer node to OLS LMP session and the concatenated data links of the peer node to peer node LMP session. Iconic teamwork, honestly 🌈.

As in [RFC4204], the LinkSummary message is used to synchronize the Interface_Ids and correlate the properties of the TE link ✨. (Quick side note: the term "TE link" came from the routing and signaling side of LMP, and the concept doesn't necessarily apply to an OLS. We still use the term in this document so it stays consistent with LMP terminology 🧚.) The LinkSummary message includes one or more DATA_LINK objects. The contents of a DATA_LINK object are a series of variable-length data items called Data Link sub-objects, which describe the capabilities of the data links 💜.

This document defines several additional Data Link sub-objects to describe extra link characteristics 🌸. The link characteristics are, in general, the ones the CSPF needs in order to select the path for a particular LSP. They describe the specified peer node-to-OLS data link, plus the associated DWDM span between the two OLSes. Main character energy for sure 💅.

The format of the Data Link sub-objects follows the format described in [RFC4204], and it's 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 🦋.

The main purpose of the Link Group ID is to reduce control traffic during failures that affect many data links 😭. A local ID can be assigned to a group of data links. This ID can cut down on control traffic when something fails, because a single ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see Section 2.4.1) can be used for a whole group of data links, instead of sending individual ChannelStatus messages for each data link. A data link may be a member of multiple groups, and that's achieved by including multiple Link Group ID sub-objects in the LinkSummary message 🔥.

The Link Group ID feature lets Link Groups get assigned based on the types of fault correlation and aggregation a given OLS supports. Practically speaking, the Link Group ID is used to map (or group) data links into "failable entities" that are known mainly to the OLS 🧚. If one of those failable entities fails, all associated data links fail too, and the peer node gets 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 report a single failure affecting all of the data links with the Link Group ID of the failed laser. The peer node that receives that single failure notification then knows exactly which data links are affected ✨. Similarly, an OLS could create a Link Group ID for a fiber, so it can report one failure affecting all of the data links associated with that fiber if a loss-of-signal (LOS) is detected on 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 👑.

This identifies the SRLGs that the data link is a member of 🫶. This information may be configured on an OLS by the user, and it can be 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 🧚.

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 gives 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 🎀.

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 🌈. It 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) that the data link belongs to 🎨.

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] 💜.

2.4. Fault Management 🚨

okay so fault management between a peer and an OLS follows the procedures in [RFC4204] 🫶, and this section adds a few extra extensions on top. the info the OLS-peer fault management learns can kick off peer-to-peer LMP fault management, or it can trigger GMPLS signaling/routing procedures directly. the way that it all connects is iconic ✨

fault management has three major parts 👑:

  1. Fault Detection
  2. Fault Localization
  3. Fault Notification

fault detection is each node's own job, and this protocol doesn't specify it 💅

fault detection mechanisms can include a Bit Error Rate (BER) going over a threshold, plus loss-of-signal (LOS) and SONET/SDH-level errors 😭. it's the OLS's responsibility to translate these failures into (Signal) OK, Signal Failure (SF), or Signal Degrade (SD), as described in [RFC4204] 🎀

so basically, an OLS uses the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse messages (the LMP fault localization messages) to tell the adjacent peer node about failures it has detected 📣. that's how the LMP fault localization procedures between peer nodes get started. the OLS doesn't take part in those procedures though 🙈

the OLS can also run its own fault localization process 🧚 so it can figure out where the fault is along the DWDM span. for example, it might be able to pinpoint a fault to one particular amplifier in a span that's thousands of kilometers long 🌈

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 🍓. a Link Group ID can also be assigned to a group of data links (see Section 2.3.1). the Link Group ID can cut down on control traffic, because it gives channel status info for a whole group of data links at once ✨ this is where the new LINK GROUP CHANNEL_STATUS object comes in, and it's defined below 💜. it can be used in place of the CHANNEL_STATUS objects described in [RFC4204] inside the ChannelStatus message 🫶

the LINK_GROUP CHANNEL_STATUS object shows the status of the data links that belong to a particular Link Group 🌸. the data links get matched up to a Group ID through the Link Group ID sub-object of the DATA_LINK object 🔥

the format of the LINK_GROUP CHANNEL_STATUS object looks like this (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                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

here's the breakdown 🧁

  • Link Group ID (32 bits): the Link Group ID 0xFFFFFFFF is reserved, and it means all data links in a TE link 😤. by default, every data link is a member of Link Group 0xFFFFFFFF 💅
  • Channel Status (32 bits): the values for this field are defined in [RFC4204] 🩷

this object is non-negotiable 🔒✨

3. Security Considerations 🔐

okay this one is serious, bestie 😭 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].

4. IANA Considerations 📋

the LMP spec [RFC4204] defines the following name spaces, and the ways IANA can make assignments to them 🗂️:

  • 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 adds the following new assignments ✨

LMP Object Class Types:

  • under CONFIG class name (as defined in [RFC4204])
    • LMP-WDM_CONFIG (C-Type = 2)
  • under CHANNEL_STATUS class name (as defined in [RFC4204])
    • LINK_GROUP (C-Type = 4)

LMP Sub-Object Class names:

  • 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 want to give a huge shoutout to 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 💜🌟

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.

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

okay, the legal bit, read it with me 🙈

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 doesn't take a position on 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 🤷‍♀️. it also doesn't say whether any license under those rights might or might not be available, and it doesn't claim to have made any independent effort to identify any such rights. info about 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 to get a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be found in 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 required to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌷

funding for the RFC Editor function is currently provided by the Internet Society 💖✨

📦 where this page comes from