RFC 4328

RFC 4328: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control 🎀

Okay bestie, so this is RFC 4328, written by D. Papadimitriou, Ed. from Alcatel 💅 It's dated January 2006 and it's on the Standards Track. It updates RFC 3471, so it's basically an upgrade to that earlier spec ✨

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright Notice

Copyright (C) The Internet Society (2006). 🧚

Abstract

This doc is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It explains the technology-specific stuff needed to extend GMPLS signaling so it can control Optical Transport Networks (OTN). It also covers the so-called pre-OTN developments 🦋

Table of Contents

1. Introduction ....................................................2
   1.1. Conventions Used in This Document ..........................3
2. GMPLS Extensions for G.709 - Overview ...........................3
3. Generalized Label Request .......................................4
   3.1. Common Part ................................................5
        3.1.1. LSP Encoding Type ...................................5
        3.1.2. Switching Type ......................................6
        3.1.3. Generalized-PID (G-PID) .............................6
   3.2. G.709 Traffic Parameters ...................................8
        3.2.1. Signal Type (ST) ....................................8
        3.2.2. Number of Multiplexed Components (NMC) ..............9
        3.2.3. Number of Virtual Components (NVC) .................10
        3.2.4. Multiplier (MT) ....................................10
        3.2.5. Reserved Fields ....................................10
4. Generalized Label ..............................................10
   4.1. ODUk Label Space ..........................................11
   4.2. Label Distribution Rules ..................................13
   4.3. Optical Channel Label Space ...............................14
5. Examples .......................................................14
6. RSVP-TE Signaling Protocol Extensions ..........................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................16
9. Acknowledgements ...............................................18
10. References ....................................................18
   10.1. Normative References .....................................18
   10.2. Informative References ...................................19
11. Contributors ..................................................19
Appendix A. Abbreviations .........................................21
Appendix B. G.709 Indexes .........................................22

1. Introduction ✨

Okay so, Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] takes MPLS, which only handled Packet Switching Capable (PSC) interfaces and switching, and levels it up. It adds four new classes of interfaces and switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch (LSC), and Fiber-Switch (FSC) Capable 💖 The functional description of the MPLS signaling extensions needed to support these new classes is in [RFC3471]. [RFC3473] then describes the RSVP-TE-specific formats and mechanisms needed to support all four classes of interfaces 🔥

This document gets into the technology details specific to G.709 Optical Transport Networks (OTN), as specified in the ITU-T G.709 recommendation [ITUT-G709] (and its referenced documents), including the pre-OTN developments. As [RFC3471] says, G.709 technology-specific parameters are carried through the signaling protocol in dedicated traffic parameter objects 🦋

The G.709 traffic parameters defined hereafter (see Section 3.2) MUST be used when the label is encoded as defined in this document. Moreover, the label MUST be encoded as defined in Section 4 when these G.709 traffic parameters are used. Those two rules are non-negotiable, bestie 🫶

So, pre-OTN developments are Optical Channel, Digital Wrapper, and Forward Error Correction (FEC) solutions that are not fully G.709 compliant. Details about pre-OTN Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) based solutions, including Section/Regenerator Section overhead (SOH/RSOH) and Line/Multiplex Section overhead (LOH/MSOH) transparency, are covered in [RFC3946] 🌈

Note on ITU-T G.709 Recommendation The views on the ITU-T G.709 OTN Recommendation in this document are intentionally limited to the GMPLS perspective within the IETF CCAMP WG context. So the goal here is NOT to copy the ITU-T OTN recommendations. If you want more detail about the corresponding technologies, you're strongly encouraged to check the matching ITU-T documents, which are also referenced in this memo 🙈

1.1. Conventions Used in This Document

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 also need to know the terminology used in ITU-T [ITUT-G709], plus [RFC3471] and [RFC3473]. The abbreviations used in this document are detailed in Appendix 1 📚

2. GMPLS Extensions for G.709 - Overview ✨

[ITUT-G709] defines several networking layers that make up the optical transport hierarchy:

• with full functionality:
  • Optical Transmission Section (OTS)
  • Optical Multiplex Section (OMS)
  • Optical Channel (OCh)
• with reduced functionality:
  • Optical Physical Section (OPS)
  • Optical Channel with reduced functionality (OChr)

It also defines two layers that make up the digital transport hierarchy:

• Optical Channel Transport Unit (OTUk)
• Optical Channel Data Unit (ODUk)

Only the OCh and the ODUk layers are defined as switching layers, though 💅 Both OCh (but not OChr) and ODUk layers include the overhead for supervision and management. The OCh overhead is transported in a non-associated manner (also called the non-associated overhead naOH) in the Optical Transport Module (OTM) Overhead Signal (OOS), together with the OTS and OMS non-associated overhead. The OOS is transported over a dedicated wavelength, called the Optical Supervisory Channel (OSC). It should be noticed that the naOH is only functionally specified, so it's open to vendor-specific solutions 👀 The ODUk overhead is transported in an associated manner, as part of the digital ODUk frame.

As [ITUT-G709] describes, G.709 supports ODUk mapping into OTUk (k = 1, 2, 3) in addition to ODUk multiplexing. That's the multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, specifically:

• ODU1 into ODU2 multiplexing
• ODU1 into ODU3 multiplexing
• ODU2 into ODU3 multiplexing
• ODU1 and ODU2 into ODU3 multiplexing

So, GMPLS can control G.709 OTN by creating:

• a Digital Path layer, by extending the previously defined "Digital Wrapper" in [RFC3471] to the ODUk (digital) path layer.
• an Optical Path layer, by extending the "Lambda" concept (defined in [RFC3471]) to the OCh (optical) path layer.
• a label space structure, modeled as a tree whose root is an OTUk signal and whose leaves are the ODUj signals (k >= j). This lets you pinpoint the exact position of a particular ODUj signal in an ODUk multiplexing structure 🌸

That means the GMPLS signaling extensions for G.709 need to cover the Generalized Label Request, the Generalized Label, and the technology-dependent objects inside the so-called traffic parameters, as specified in [RFC3946] for SONET/SDH networks. Because digital-domain multiplexing (like ODUk multiplexing) was specified in the amended version of the G.709 ITU-T recommendation (October 2001), this document also proposes a label space definition for that purpose. Also, the G.709 ODUk (i.e., Digital Path) and OCh (i.e., Optical Path) layers are used directly to define the corresponding label spaces 🍓

3. Generalized Label Request 🧚

The Generalized Label Request, as defined in [RFC3471], has a common part (used for any switching technology) and a technology-dependent part (the traffic parameters). In this section, both parts get extended so GMPLS signaling can reach the G.709 transport plane recommendation (see [ITUT-G709]) 🦋

3.1. Common Part

As [RFC3471] defines it, the common part of the Generalized Label Request is made of the LSP Encoding Type, the Switching Type, and the Generalized Protocol Identifier (Generalized-PID). The encoding of the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in [RFC3473] Section 2.1 💖

As mentioned above, this document extends the LSP Encoding Type, the Switching Type, and the G-PID (Generalized-PID) values so they can handle the G.709 Recommendation [ITUT-G709] 👑

3.1.1. LSP Encoding Type ✨

okay so G.709 has two networking layers 🫶: the ODUk layers and the OCh layer. That means the LSP Encoding Type code-points can mirror those two layers, which [RFC3471] Section 3.1 called "Digital Wrapper" and "Lambda". The LSP Encoding Type gets specified per networking layer, or more precisely per group of functional networking layers: the ODUk layers and the OCh layer. Main character energy 👑

So there's a new LSP Encoding Type code-point for the G.709 Digital Path layer, and it enlarges the existing "Digital Wrapper" code-point from [RFC3471]. The new one MUST be generated when the interface or tunnel carrying the traffic supports G.709 compliant Digital Path layer encoding. The old one MUST only be used for non-G.709 compliant Digital Wrapper layer(s) encoding. 💅 A transit or an egress node (the one receiving a Path message with a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message with a "Routing problem/Unsupported Encoding" indication if the requested LSP Encoding Type can't be supported on the incoming interface. Not me being dramatic, it's literally required 😭

Same energy for the G.709 Optical Channel layer 🦋. It enlarges the existing "Lambda" code-point from [RFC3471]. The new one MUST be generated when the interface or tunnel carrying the traffic supports G.709-compliant Optical Channel layer encoding. The old one MUST only be used for non-G.709 compliant Lambda layer(s) encoding. A transit or an egress node (receiving a Path message that contains a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message with a "Routing problem/Unsupported Encoding" indication if the requested LSP Encoding Type can't be supported on the incoming interface.

So the new additional code-points are:

    Value           Type
    -----           ----
    12             G.709 ODUk (Digital Path)
    13             G.709 Optical Channel

And the code-point for the G.709 Optical Channel (OCh) layer also tells you whether an end-system can use the G.709 non-associated overhead (naOH), aka the OTM Overhead Signal (OOS) multiplexed into the OTM-n.m interface signal. Iconic overhead flex 🌈

3.1.2. Switching Type 🎀

The Switching Type tells you what kind of switching should happen at the end of a particular link (see [RFC4202]).

Here's the tea: no new Switching Type values are needed for G.709 🍓. ODUk switching (and so its LSPs) belongs to the TDM class, and OCh switching (and its LSPs) belongs to the Lambda class, aka LSC. Done and dusted ✨

Intermediate and egress nodes MUST verify that the value in the Switching Type field is supported on the incoming interface. If the requested value can't be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication. No vibes, just rules 🙈

3.1.3. Generalized-PID (G-PID) 🧚

The G-PID is a 16 bits field, defined in [RFC3471], that identifies the payload an LSP carries, so basically the client layer of that LSP. The endpoints of the G.709 LSP use it 💜

When the client payload goes over the Digital Path layer, you get these G-PID values on top of the payload identifiers from [RFC3471]:

• CBRa: asynchronous Constant Bit Rate (i.e., mapping of STM-16/OC- 48, STM-64/OC-192 and STM-256/OC-768)
• CBRb: bit synchronous Constant Bit Rate (i.e., mapping of STM- 16/OC-48, STM-64/OC-192 and STM-256/OC-768)
• ATM: mapping at 2.5, 10 and 40 Gbps
• BSOT: non-specific client Bit Stream with Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream)
• BSNT: non-specific client Bit Stream without Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream)
• ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps
• ESCON: Enterprise Systems Connection
• FICON: Fiber Connection

When the client payload goes over the Optical Channel layer, these are the extra G-PID values, again on top of the [RFC3471] ones:

• CBR: Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC- 192 and STM-256/OC-768)
• OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps

When client payloads like Ethernet MAC/PHY and IP/PPP are wrapped in the Generic Framing Procedure (GFP), as described in ITU-T G.7041, there are dedicated G-PID values for those too 🫶

For the pre-OTN era, the G-PID field can use one of the values already defined in [RFC3471] when these client payloads go over a so-called lambda LSP:

• Ethernet PHY (1 Gbps and 10 Gbps)
• Fiber Channel

Here's the summary of G-PID values against the LSP Encoding Type 📊:

Value     G-PID Type                       LSP Encoding Type
-----     ----------                       -----------------
 47       G.709 ODUj                       G.709 ODUk (with k > j)
 48       G.709 OTUk(v)                    G.709 OCh
                                           ODUk mapped into OTUk(v)
 49       CBR/CBRa                         G.709 ODUk, G.709 OCh
 50       CBRb                             G.709 ODUk
 51       BSOT                             G.709 ODUk
 52       BSNT                             G.709 ODUk
 53       IP/PPP (GFP)                     G.709 ODUk (and SDH)
 54       Ethernet MAC (framed GFP)        G.709 ODUk (and SDH)
 55       Ethernet PHY (transparent GFP)   G.709 ODUk (and SDH)
 56       ESCON                            G.709 ODUk, Lambda, Fiber
 57       FICON                            G.709 ODUk, Lambda, Fiber
 58       Fiber Channel                    G.709 ODUk, Lambda, Fiber

Note: Values 49 and 50 include mapping of SDH.

And this one is the update to the G-PID values already defined in [RFC3471] 🔥:

Value     G-PID Type                 LSP Encoding Type
-----     ----------                 -----------------
 32       ATM Mapping                SDH, G.709 ODUk
 33       Ethernet PHY               SDH, G.709 OCh, Lambda, Fiber
 34       Sonet/SDH                  G.709 OCh, Lambda, Fiber
 35       Reserved (SONET Dep.)      G.709 OCh, Lambda, Fiber

---

3.2. G.709 Traffic Parameters 🦋

When the G.709 Digital Path Layer or the G.709 Optical Channel Layer is set in the LSP Encoding Type field, the technology dependent info (aka the traffic parameters) gets carried on top of what's already in the Generalized Label Request.

The G.709 traffic parameters look like this:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Signal Type  |   Reserved    |              NMC              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              NVC              |        Multiplier (MT)        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In this frame, NMC is Number of Multiplexed Components, NVC is Number of Virtual Components, and MT is Multiplier. Each field is built to support G.709 LSP requests 🎀

The RSVP-TE encoding of the G.709 traffic-parameters is covered in Section 6, so go check that out 💅

3.2.1. Signal Type (ST) 🌸

This 8 bits field says which G.709 Elementary Signal makes up the requested LSP. The permitted values are:

   Value     Type
   -----     ----
     0       Not significant
     1       ODU1 (i.e., 2.5 Gbps)
     2       ODU2 (i.e., 10  Gbps)
     3       ODU3 (i.e., 40  Gbps)
     4       Reserved (for future use)
     5       Reserved (for future use)
     6       OCh at 2.5 Gbps
     7       OCh at 10  Gbps
     8       OCh at 40  Gbps
     9-255   Reserved (for future use)

The Signal Type value depends on the LSP Encoding Type value from Section 3.1.1 and [RFC3471]:

• if the LSP Encoding Type value is the G.709 Digital Path layer, then the valid values are the ODUk signals (k = 1, 2 or 3).
• if the LSP Encoding Type value is the G.709 Optical Channel layer, then the valid values are the OCh at 2.5, 10, or 40 Gbps.
• if the LSP Encoding Type is "Lambda" (which includes the pre-OTN Optical Channel layer) then the valid value is irrelevant (Signal Type = 0).
• if the LSP Encoding Type is "Digital Wrapper", then the valid value is irrelevant (Signal Type = 0).

Several transforms can be applied one after another to the Elementary Signal to build the Final Signal the LSP actually requests 🧠. Each transform is optional and must be ignored if it's zero. The Multiplier (MT) doesn't count here, since it can't be zero, and it must be ignored if it's one. The transforms must be applied strictly in this order:

• First, virtual concatenation (using the NVC field) can optionally be applied directly on the Elementary Signal to form a Composed Signal
• Second, a multiplication (using the Multiplier field) can optionally be applied, either directly on the Elementary Signal, or on the virtually concatenated signal from the first phase. The resulting signal is referred to as Final Signal.

3.2.2. Number of Multiplexed Components (NMC) 🍓

The NMC field is 16 bits and says how many ODU tributary slots an ODUj uses when it's multiplexed into an ODUk (k > j) for the requested LSP. It doesn't apply when an ODUk is mapped into an OTUk, and it's irrelevant at the Optical Channel layer. In both cases it MUST be set to zero (NMC = 0) when sent, and it should be ignored when received.

At the Digital Path layer, especially for ODU2 connections multiplexed into one ODU3 payload, NMC says how many individual tributary slots (NMC = 4) make up the requested connection. Those components are still handled inside one connection entity. For all the other multiplexing cases defined so far (see Section 2), the NMC field is set to 1 ✨

3.2.3. Number of Virtual Components (NVC) 🌈

The NVC field is 16 bits and is for ODUk virtual concatenation (aka ODUk Inverse Multiplexing) 🦄. It says how many ODU1, ODU2, or ODU3 Elementary Signals are requested to be virtually concatenated into an ODUk-Xv signal. These signals MUST be of the same type, no mixing 💖

The field is set to 0 by default, which means no virtual concatenation is requested.

Heads up: right now this field only applies to G.709 ODUk LSPs. Values above zero are only acceptable for ODUk Signal Types. So when a G.709 OCh LSP is requested, the NVC MUST be set to zero (NVC = 0), and it should be ignored when received 🙈

3.2.4. Multiplier (MT) 🔁

okay bestie, the Multiplier field is 16 bits and it's basically the "how many copies do you want" 🙋‍♀️. It counts how many identical Elementary Signals or Composed Signals the LSP is asking for, and those together form the Final Signal ✨. A Composed Signal is what you get when you apply the NMC and NVC fields to an elementary Signal Type, so it's kind of a layered glow-up 💅. Right now GMPLS signaling assumes that all the Composed Signals live on the same LSP, so no splitting them up across different ones 🫶.

The field is set to one by default, which just means "I want exactly one instance of the signal" 🌸. Intermediate and egress nodes MUST check that they themselves, plus the interfaces the LSP is going to be set up on, can actually handle the multiplier you asked for 🔍. If they can't, the receiver node MUST send back a PathErr message (see Section 6) 😭.

Zero is not a valid value for MT 💀. If a node gets a zero, it MUST generate a PathErr message (see Section 6). No zeros allowed, periodt 🙅‍♀️.

3.2.5. Reserved Fields 🎀

The reserved fields are 8 bits in row 1 and 32 bits in row 3, and they're saved for future use 🔮. When you send them, reserved bits SHOULD be set to zero. When you receive them, they MUST be ignored ✨. Basically: send zeros, don't panic about anything you find in there 🧚.

---

4. Generalized Label 🌈

This section is all about the Generalized Label value space for Digital Paths and Optical Channels 🦋. The Generalized Label itself is defined in [RFC3471], and the RSVP-TE GENERALIZED_LABEL object format is in [RFC3473] Section 2.3 📦.

The label distribution rules in Section 4.2 follow the ones from [RFC3946] when they apply 💜.

4.1. ODUk Label Space 🍓

At the Digital Path layer (the ODUk layers), G.709 gives us three client payload bit rates 💫. Each one has its own Optical Data Unit (ODU) frame. ODUk refers to the frame at bit rate k, where k = 1 (2.5 Gbps), 2 (10 Gbps), or 3 (40 Gbps) 🏎️.

On top of mapping ODUk into OTUk, the G.709 label space also covers sub-levels of ODUk multiplexing 🧩. That's when ODUj (j = 1, 2) gets multiplexed into an ODUk where k > j. The combos are:

• ODU1 into ODU2 multiplexing
• ODU1 into ODU3 multiplexing
• ODU2 into ODU3 multiplexing
• ODU1 and ODU2 into ODU3 multiplexing

To be more precise, ODUj into ODUk multiplexing (k > j) happens when an ODUj gets multiplexed into an ODUk Tributary Unit Group (aka an ODTUG made of ODU tributary slots) that's mapped into an OPUk 🎯. That OPUk then gets mapped into an ODUk, and that ODUk gets mapped into an OTUk. It's a whole nested situation, but iconic 👑.

So the label space ends up looking like a tree 🌳. The root is an OTUk signal, and the leaves are the ODUj signals (k >= j) that can be carried in the tributary slots and switched between those slots. A G.709 Digital Path layer label tells you the exact position of one particular ODUj signal in an ODUk multiplexing structure 📍.

The G.709 Digital Path Layer label (a.k.a. the ODUk label) looks like this 👇:

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Reserved                |     t3    | t2  |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved bits MUST be set to zero when sent, and they SHOULD be ignored when received 🫧.

The t1, t2, and t3 fields are what make the ODUk label space self-consistent 💖. Here's how their values work:

1. t1 (1-bit):
   • t1=1 indicates an ODU1 signal.
   • t1 is not significant for the other ODUk signal types (i.e., t1 value MUST be set to 0 and ignored).
2. t2 (3-bit):
   • t2=1 indicates an ODU2 signal that is not further sub-divided.
   • t2=[2..5] indicates the tributary slot (t2th-2) used by the ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
   • t2 is not significant for an ODU3 (i.e., t2 value MUST be set to 0 and ignored).
3. t3 (6-bit):
   • t3=1 indicates an ODU3 signal that is not further sub-divided.
   • t3=[2..17] indicates the tributary slot (t3th-1) used by the ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
   • t3=[18..33] indicates the tributary slot (t3th-17) used by the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).

Note: in the case of ODU2 into ODU3 multiplexing, you need 4 labels to identify the 4 tributary slots the ODU2 uses, and those tributary time slots have to be allocated in ascending order 📈.

If a label sub-field has t[i]=1 and t[j]=0 (with i, j = 1, 2, or 3 and j > i), then the ODUk signal ODU[i] gets mapped directly into the matching OTUk signal (k=i). This is called mapping an ODUk signal into an OTUk of the same order 🎀. Numbering starts at 1, and zero is only used to mean "this field doesn't matter here." A label field equal to zero is an invalid value 🙅‍♀️.

Examples, because we love an example 🥰:

• t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1
• t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2
• t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3
• t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2
• t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3

4.2. Label Distribution Rules 📬

For ODUk in OTUk mapping, only one label can show up in the Generalized Label 🙌. That single label is encoded as one 32-bit label value (as defined in Section 4.1) inside the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2) ✨.

For ODUj in ODUk (k > j) multiplexing, you get an explicit ordered list of the labels in the multiplex 🧾. This list can be cut down to just one label when NMC = 1. Each label stands for one component (an ODUj tributary slot) of the multiplexed signal 🧩. The order of the labels has to match the order of the ODUj signals going into the multiplex, and it does not follow the physical order of the tributary slots 🔄. This list gets encoded as a sequence of 32-bit label values (as defined in Section 4.1) in the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2) 💜.

For ODUk virtual concatenation, you get the explicit ordered list of all the labels in the concatenation 🔗. Each label is one component of the virtually concatenated signal. The order has to follow the order of the ODUk signals being concatenated, not the physical order of the time-slots ⏱️. This setup keeps virtual concatenation inside a single (component) link 🔒. If you've got multiplexed virtually concatenated signals, the first set of labels covers the components (ODUj tributary slots) of the first virtually concatenated signal, the second set covers the second one, and so on 🪆. This ordered list is encoded as a sequence of 32-bit label values (as defined in Section 4.1) in the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). For ODUk virtual concatenation, the number of label values is set by the NVC value 🔢. Multiplexed ODUk virtual concatenation also uses the NMC value to figure out how many labels go in each set, and the sets are all the same size 📏.

For multiplication (when you're using the MT field), you get the explicit ordered list of all the labels in the composed signal 🌟. That representation keeps multiplication inside a single (component) link too 🧷. For multiplication of multiplexed virtually concatenated signals, the first set of labels covers the components of the first multiplexed virtually concatenated signal, the second set covers the second one, and so on. The list is encoded as a sequence of 32-bit label values (as defined in Section 4.1) in the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). When you multiply (equal) ODUk virtually concatenated signals, the number of label values per signal is set by the NVC value. Multiplying multiplexed (equal) ODUk virtual concatenation also uses the NMC value to work out the number of labels per set, and those sets are equal in size 💅.

4.3. Optical Channel Label Space 🌊

At the Optical Channel layer, the label space must be consistently defined as a flat space 🥞. Its values reflect the local assignment of OCh identifiers that line up with the OTM-n.m sub-interface signals (m = 1, 2, or 3). These identifiers don't cover OChr, because the Connection Function (OChr-CF) between OTM-nr.m/OTM-0r.m isn't defined in [ITUT-G798] 🙈.

OCh label space values can be defined in one of two ways. They can be absolute values (channel identifiers, also called Channel IDs or wavelength identifiers) or relative values (channel spacing, also called inter-wavelength spacing) 🌈. Relative values are strictly confined to a per-port label space, while absolute values could be a local label space or a global (per-node) one 📍. This OCh label space works for both the OTN Optical Channel layer and the pre-OTN Optical Channel layer 💫.

Optical Channel label encoding and distribution rules are defined in [RFC3471] 📚. They MUST be used for the Upstream Label, the Suggested Label, and the Generalized Label 🫶.

5. Examples 🎀

Okay bestie, time for the fun part 💖 These examples show the processing from the earlier sections actually happening, step by step.

1. ODUk in OTUk mapping 🦋: okay so when one ODU1 (ODU2 or ODU3) signal is directly carried in an OTU1 (OTU2 or OTU3), the upstream node's request comes out as simply an ODU1 (ODU2 or ODU3) signal request.

The downstream node has to return a unique label, because the ODU1 (ODU2 or ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3). Since only one ODUk signal is requested (Signal Type = 1, 2 or 3), it returns a single ODUk label. For Signal Type = 1, that label could be one of these, for instance:

• t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1
• t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2
• t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3

2. ODU1 into ODUk multiplexing (k > 1) 🌸: when one ODU1 is multiplexed into the payload of a structured ODU2 (or ODU3), the upstream node requests simply an ODU1 signal request.

The downstream node has to return a unique label, because the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). That ODTUG is then mapped into the ODU2 (or ODU3) via OPU2 (or OPU3), and then mapped into the corresponding OTU2 (or OTU3). Since a single ODU1 multiplexed signal is requested (Signal Type = 1 and NMC = 1), the downstream node has to return a single ODU1 label, which can take, for instance, one of the following values:

• t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2
• t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3
• t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3

3. ODU2 into ODU3 multiplexing 🧚: when one unstructured ODU2 is multiplexed into the payload of a structured ODU3, the upstream node requests simply an ODU2 signal request.

The downstream node has to return four labels, because the ODU2 is multiplexed into one ODTUG3. That ODTUG is mapped into an ODU3 (via OPU3), and then mapped into an OTU3. Since an ODU2 multiplexed signal is requested (Signal Type = 2, and NMC = 4), the downstream node has to return four ODU labels, which can take for instance the following values:

• t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3)
• t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3)
• t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3)
• t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)

4. When a single OCh signal of 40 Gbps is requested (Signal Type = 8) ✨, the downstream node must return a single wavelength label as specified in [RFC3471].
5. When requesting multiple ODUk LSP (i.e., with a multiplier (MT) value > 1) 👑, an explicit list of labels is returned to the requestor node.

When the downstream node receives a request for a 4 x ODU1 signal (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into an ODU3, it returns an ordered list of four labels to the upstream node: the first ODU1 label corresponds to the first signal of the LSP, the second ODU1 label corresponds to the second signal of the LSP, etc. For instance, the corresponding labels can take the following values:

• First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3)
• Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3)
• Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3)
• Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)

---

6. RSVP-TE Signaling Protocol Extensions 🌈

Now we get to the RSVP-TE side of things 💅 This section lays out the [RFC3473] protocol extensions needed to fit G.709 traffic parameters in.

The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC and FLOWSPEC objects. The same format is used for both the SENDER_TSPEC object and the FLOWSPEC objects. The content of the objects is defined above in Section 3.2. The objects have the following class and type for G.709:

• G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5
• G.709 FLOWSPEC Object: Class = 9, C-Type = 5

There is no Adspec associated with the G.709 SENDER_TSPEC. Either the Adspec is omitted, or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used, see [RFC2210].

For a particular sender in a session, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the SENDER_TSPEC object received in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. 🫶

Intermediate and egress nodes MUST verify that the node itself, and the interfaces on which the LSP will be established, can support the requested Signal Type, NMC, and NVC values (as defined in Section 3.2). If the requested value(s) cannot be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]).

In addition, if the MT field is received with a zero value, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]). 🙈

---

7. Security Considerations 🔒

Plot twist: this document adds no new security considerations on top of [RFC3473] 😭 Still, the whole vibe here is that it's a sensitive area, so keep your eyes open.

---

8. IANA Considerations 📋

Two values have been defined by IANA for this document:

Two RSVP C-Types in registry:

    http://www.iana.org/assignments/rsvp-parameters
    - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see
      Section 6.

    - A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see
      Section 6.

IANA will also track the code-point spaces extended and/or updated by this document. For this purpose, the following new registry entries have been added in the newly requested registry entry: http://www.iana.org/assignments/gmpls-sig-parameters

- LSP Encoding Type:
  Name: LSP Encoding Type
  Format: 8-bit number
  Values:
     [1..11]         defined in [RFC3471]
     12              defined in Section 3.1.1
     13              defined in Section 3.1.1
  Allocation Policy:
     [0..239]        Assigned by IANA via IETF Standards Track RFC
                     Action.
     [240..255]      Assigned temporarily for Experimental Usage.
                     These will not be registered with IANA

- Switching Type:
  Name: Switching Type
  Format: 8-bit number
  Values: defined in [RFC3471]
  Allocation Policy:
     [0..255]        Assigned by IANA via IETF Standards Track RFC
                     Action.

- Generalized PID (G-PID):
  Name: G-PID
  Format: 16-bit number
  Values:
     [0..31]         defined in [RFC3471]
     [32..35]        defined in [RFC3471] and updated by Section
                     3.1.3
     [36..46]        defined in [RFC3471]
     [47..58]        defined in Section 3.1.3
  Allocation Policy:
     [0..31743]      Assigned by IANA via IETF Standards Track RFC
                     Action.
     [31744..32767]  Assigned temporarily for Experimental Usage
     [32768..65535]  Not assigned.  Before any assignments can be
                     made in this range, there MUST be a Standards
                     Track RFC that specifies IANA Considerations
                     that covers the range being assigned.

Note: per [RFC3471], Section 3.1.1, standard Ethertype values are used as G-PIDs for packet and Ethernet LSPs. 🌟

---

9. Acknowledgements 🫶

Huge thanks to the people who made this happen 💜 The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, Massimo Canali, Germano Gasparini, and Fong Liaw for their constructive comments and inputs, as well as James Fu, Siva Sankaranarayanan, and Yangguang Xu for their useful feedback. Many thanks to Adrian Farrel for having thoroughly reviewed this document.

This document incorporates (upon agreement) material and ideas from a work in progress, "Common Label and Label Request Specification for Automatic Switched Transport Network", by Zhi Lin.

---

10. References 📚

10.1. Normative References

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
             Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
             1 Functional Specification", RFC 2205, September 1997.

[RFC2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
             Services", RFC 2210, September 1997.

[RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Functional Description", RFC 3471,
             January 2003.

[RFC3473]    Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 3473, January
             2003.

[RFC3946]    Mannie, E. and D. Papadimitriou, "Generalized Multi-
             Protocol Label Switching (GMPLS) Extensions for
             Synchronous Optical Network (SONET) and Synchronous
             Digital Hierarchy (SDH) Control", RFC 3946, October
             2004.

[RFC4202]    Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
             Extensions in Support of Generalized Multi-Protocol
             Label Switching (GMPLS)", RFC 4202, September 2005.

10.2. Informative References

[RFC3945]    Mannie, E., "Generalized Multi-Protocol Label Switching
             (GMPLS) Architecture", RFC 3945, October 2004.

For information on the availability of the following documents, please see http://www.itu.int

[ITUT-G709]  ITU-T, "Interface for the Optical Transport Network
             (OTN)," G.709 Recommendation (and Amendment 1), February
             2001 (October 2001).

[ITUT-G798]  ITU-T, "Characteristics of Optical Transport Network
             Hierarchy Equipment Functional Blocks," G.798
             Recommendation, October 2001.

---

11. Contributors 👑

Here are the amazing people who helped write this 🌈

Alberto Bellato (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
EMail: alberto.bellato@alcatel.it

Sudheer Dharanikota (Consult)
EMail: sudheer@ieee.org

Michele Fontana (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
EMail: michele.fontana@alcatel.it

Nasir Ghani (Sorrento Networks)
9990 Mesa Rim Road,
San Diego, CA 92121, USA
EMail: nghani@sorrentonet.com

Gert Grammel (Alcatel)
Lorenzstrasse, 10,
70435 Stuttgart, Germany
EMail: gert.grammel@alcatel.de
Dan Guo (Turin Networks)
1415 N. McDowell Blvd,
Petaluma, CA 94954, USA
EMail: dguo@turinnetworks.com

Juergen Heiles (Siemens)
Hofmannstr. 51,
D-81379 Munich, Germany
EMail: juergen.heiles@siemens.com

Jim Jones (Alcatel)
3400 W. Plano Parkway,
Plano, TX 75075, USA
EMail: jim.d.jones@alcatel.com

Zhi-Wei Lin (Lucent)
101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA
EMail: zwlin@lucent.com

Eric Mannie (Consult)
EMail: eric_mannie@hotmail.com

Maarten Vissers (Alcatel)
Lorenzstrasse, 10,
70435 Stuttgart, Germany
EMail: maarten.vissers@alcalel.de

Yong Xue (WorldCom)
22001 Loudoun County Parkway,
Ashburn, VA 20147, USA
EMail: yong.xue@wcom.com

Appendix A. Abbreviations ✨

Here's the full glossary of all the acronyms in this doc, bestie 📚 Copied exactly so nothing gets lost:

BSNT         Bit Stream without Octet Timing
BSOT         Bit Stream with Octet Timing
CBR          Constant Bit Rate
ESCON        Enterprise Systems Connection
FC           Fiber Channel
FEC          Forward Error Correction
FICON        Fiber Connection
FSC          Fiber Switch Capable
GCC          General Communication Channel
GFP          Generic Framing Procedure
LSC          Lambda Switch Capable
LSP          Label Switched Path
MS           Multiplex Section
naOH         non-associated Overhead
NMC          Number of Multiplexed Components
NVC          Number of Virtual Components
OCC          Optical Channel Carrier
OCG          Optical Carrier Group
OCh          Optical Channel (with full functionality)
OChr         Optical Channel (with reduced functionality)
ODTUG        Optical Date Tributary Unit Group
ODU          Optical Channel Data Unit
OH           Overhead
OMS          Optical Multiplex Section
OMU          Optical Multiplex Unit
OOS          OTM Overhead Signal
OPS          Optical Physical Section
OPU          Optical Channel Payload Unit
OSC          Optical Supervisory Channel
OTH          Optical Transport Hierarchy
OTM          Optical Transport Module
OTN          Optical Transport Network
OTS          Optical Transmission Section
OTU          Optical Channel Transport Unit
OTUkV        Functionally Standardized OTUk
PPP          Point to Point Protocol
PSC          Packet Switch Capable
RES          Reserved
RS           Regenerator Section
TTI          Trail Trace Identifier
TDM          Time Division Multiplex

---

Appendix B. G.709 Indexes 🧚

Okay, the G.709 indexes are basically the little letters that tell you what flavour of optical stuff you're dealing with. Here's the tea ☕

• Index k: this one stands for a supported bit rate and the different versions of OPUk, ODUk and OTUk. k=1 is roughly 2.5 Gbit/s, k=2 is roughly 10 Gbit/s, k = 3 is roughly 40 Gbit/s, and k = 4 is roughly 160 Gbit/s (under definition). The exact bit-rate values are in kbits/s:

OPU: k=1: 2 488 320.000, k=2:  9 995 276.962, k=3: 40 150 519.322

ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983

OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559

• Index m: this one is about the bit rate, or the set of bit rates, supported on the interface 🔥. It's one or more digits of "k", and each "k" is its own bit rate. The valid values for m are (1, 2, 3, 12, 23, 123).
• Index n: this one tells you the order of the OTM, OTS, OMS, OPS, OCG and OMU. It's the max number of wavelengths that can be supported at the lowest bit rate on that wavelength. A smaller number of higher bit rate wavelengths might also be supported 💅. The case n=0 is a single channel with no specific wavelength assigned to it.
• Index r: if it shows up, it means reduced functionality for the OTM, OCG, OCC and OCh (non-associated overhead is not supported) 🙈. Note that for n=0, the index r isn't needed, because it always implies reduced functionality.

---

Editor's Address 🎀

Here's who edited this doc, so you know where to find them 💌

Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium

Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be

---

Full Copyright Statement 🌸

Copyright (C) The Internet Society (2006) 🦋

This document is covered by the rights, licences and restrictions in BCP 78. Except where that says otherwise, the authors keep all of their rights.

This document and the information in it 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 💜

Okay, so the IETF doesn't take a side on whether any patents or other IP rights around this tech are valid or how far they reach, and it can't promise any licence would be available either. It also doesn't claim it went looking for those rights itself. If you want the rules on rights in RFC docs, check BCP 78 and BCP 79 🧐.

Copies of IPR disclosures sent to the IETF Secretariat, plus any licence assurances, or the outcome of anyone trying to get a general licence or permission to use those proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF also invites anyone to flag any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that info to ietf-ipr@ietf.org 🫶.

---

Acknowledgement 🌈

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 👑