RFC 7139
GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks
GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks ✨
okay bestie, the title block is giving main character energy 💅 This is RFC 7139, published March 2014 by the IETF (Internet Engineering Task Force) 🌸 It's on the Standards Track (ISSN 2070-1721), and it updates RFC 4328. The title block doesn't list anything it obsoletes.
The authors are F. Zhang, Ed. from Huawei (the editor 👑), G. Zhang from CATR, S. Belotti from Alcatel-Lucent, D. Ceccarelli from Ericsson, and K. Pithewan from Infinera. Five companies, one spec, iconic teamwork 🫶
Abstract
ngl this is the hook 🦋 ITU-T Recommendation G.709 [G709-2012] brought in new Optical channel Data Unit (ODU) containers, which are ODU0, ODU4, ODU2e, and ODUflex, plus a glow-up in Optical Transport Network (OTN) flexibility ✨
This document updates the ODU-related parts of RFC 4328 so GMPLS signaling can control the full set of OTN features, meaning ODU0, ODU4, ODU2e, and ODUflex all get covered 💖
Status of This Memo
This is an Internet Standards Track document 🎀
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 📚
Info about the current status of this doc, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7139 🔗
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🌈
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Read those carefully, bestie, because they explain what you can and can't do with it 🙈 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💜
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. GMPLS Extensions for the Evolving G.709 -- Overview .............3
4. Generalized Label Request .......................................4
5. Extensions for Traffic Parameters for Evolving G.709 OTNs .......7
5.1. Usage of ODUflex(CBR) Traffic Parameters ...................8
5.2. Usage of ODUflex(GFP) Traffic Parameters ..................10
5.3. Notification on Errors of OTN-TDM Traffic Parameters ......11
6. Generalized Label ..............................................12
6.1. OTN-TDM Switching Type Generalized Label ..................12
6.2. Procedures ................................................14
6.2.1. Notification on Label Error ........................16
6.3. Supporting Virtual Concatenation and Multiplication .......17
6.4. Examples ..................................................17
7. Supporting Hitless Adjustment of ODUflex(GFP) ..................19
8. Operations, Administration, and Maintenance (OAM)
Considerations .................................................20
9. Control-Plane Backward-Compatibility Considerations ............20
10. Security Considerations .......................................21
11. IANA Considerations ...........................................21
12. References ....................................................23
12.1. Normative References .....................................23
12.2. Informative References ...................................24
13. Contributors ..................................................25
14. Acknowledgments ...............................................261. Introduction ✨
As Optical Transport Network (OTN) tech evolves and gets deployed, it needs better control tech support, and that's what [G709-2012] is asking for 🦋
[RFC7062] gives us a framework for building protocol extensions that support GMPLS and Path Computation Element (PCE) control of OTN as specified in [G709-2012]. Building on that framework, [RFC7096] looks at the info the routing and signaling process in OTNs needs to support GMPLS control of OTN 🧚
[RFC4328] covers the control tech details specific to the 2001 revision of the G.709 spec. This document updates the ODU-related parts of [RFC4328] to add Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions that support control for [G709-2012] 💅
2. 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]. This is the part where the capital letters matter, so read it twice 🙈
3. GMPLS Extensions for the Evolving G.709 -- Overview 🎀
New features for the evolving OTN, like the new ODU0, ODU2e, ODU4, and ODUflex containers, are specified in [G709-2012]. The matching new Signal Types are summarized below 🍓
- Optical channel Transport Unit (OTUk):
OTU4
- Optical channel Data Unit (ODUk):
ODU0ODU2eODU4ODUflex
There's also a new tributary slot granularity (1.25 Gbps) described in [G709-2012]. So now there are two tributary slot (TS) granularities for the foundation OTN ODU1, ODU2, and ODU3 containers 🌈 The 2.5 Gbps TS granularity is used on the legacy interfaces, and the new 1.25 Gbps one is used on the new interfaces. It's giving two lanes, both valid 💖
Besides ODUk mapping into OTUk (k = 1, 2, 3, 4), [G709-2012] also covers multiplexing ODUj (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k > j), as described in Section 3.1.2 of [RFC7062] ✨
Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) is also supported by [G709-2012], in the form OPUk-Xv (k = 1/2/3, X = 1...256) ⭐ Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per [G709-2012] 🙅♀️
[RFC4328] describes GMPLS signaling extensions for the 2001 revision of G.709. However, [RFC7096] doesn't give us a way to signal all the new Signal Types and their related mapping and multiplexing functions 😭 It also only supports the deprecated auto-MSI (Multiframe Structure Identifier) mode, where the Tributary Port Number (TPN) is automatically assigned in the transmit direction and not checked in the receive direction. Not me being like "wait, why is this still a thing" 💀
So this document extends the G.709 Traffic Parameters described in [RFC4328], and it introduces a new flexible and scalable OTN-TDM Generalized Label format. (Here, TDM refers to Time-Division Multiplexing.) It also provides procedures for assigning the Tributary Port Number through the control plane, which is so iconic 👑🫶
4. Generalized Label Request ✨
okay so the GENERALIZED_LABEL_REQUEST object is the one from [RFC3471] 💅 and it carries three things: the Label Switched Path (LSP) Encoding Type, the Switching Type, and the Generalized Protocol Identifier (G-PID) 🎀
[RFC4328] came in and glowed up the object 🦋 It added two new LSP Encoding Type code-points, G.709 ODUk (Digital Path) and G.709 Optical Channel, and it added a list of G-PID values so the object could handle the 2001 revision of G.709 🌸
This document follows those extensions 🫶 It also introduces a new Switching Type to indicate the ODUk Switching Capability [G709-2012]. That's there for backward compatibility with [RFC4328], as described in [RFC7062]. The new Switching Type, the OTN-TDM Switching Type, is defined in [RFC7138] ✨
This document also updates some of the G-PID values from [RFC4328] 😭
Value G-PID Type
----- ----------
47 Type field updated from "G.709 ODUj" to "ODU-2.5G" to
indicate transport of Digital Paths (e.g., at 2.5, 10, and
40 Gbps) via 2.5 Gbps TS granularity.
56 Type field updated from "ESCON" to "SBCON/ESCON" to align
with [G709-2012] payload type 0x1A.Note: Value 47 includes mapping of Synchronous Digital Hierarchy (SDH). 👀
Next up, ODU multiplexing 🧚 The Lower Order ODU (LO ODU), which is the client signal, may be multiplexed into a Higher Order ODU (HO ODU) via 1.25G TS granularity, 2.5G TS granularity, or ODU-any. The G-PID type "ODUk" from [RFC4328] is only used for 2.5 Gbps TS granularity, so two new G-PID types show up to fill the gap 🌈
- ODU-1.25G: Transport of Digital Paths at 1.25, 2.5, 10, 40, and 100 Gbps via 1.25 Gbps TS granularity.
- ODU-any: Transport of Digital Paths at 1.25, 2.5, 10, 40, and 100 Gbps via 1.25 or 2.5 Gbps TS granularity. Basically, the fallback procedure is enabled, so the default 1.25 Gbps TS granularity can fall back to 2.5 Gbps if needed. 🔥
Here's the full list of payload types from [G709-2012] and how they map to the existing and new G-PID types 📋✨
G.709
Payload
Type G-PID Type/Comment LSP Encoding
==== ===== ===================== ===================
0x01 No standard value
0x02 49 CBRa G.709 ODUk
0x03 50 CBRb G.709 ODUk
0x04 32 ATM G.709 ODUk
0x05 59 Framed GFP G.709 ODUk
54 Ethernet MAC (framed GFP) G.709 ODUk
70 64B/66B GFP-F Ethernet G.709 ODUk (k=2)
0x06 Not signaled
0x07 55 Ethernet PHY G.709 ODUk (k=0,3,4)
(transparent GFP)
0x08 58 Fiber Channel G.709 ODUk (k=2e)
0x09 59 Framed GFP G.709 ODUk (k=2)
70 64B/66B GFP-F Ethernet G.709 ODUk (k=2)
0x0A 60 STM-1 G.709 ODUk (k=0)
0x0B 61 STM-4 G.709 ODUk (k=0)
0x0C 58 Fiber Channel G.709 ODUk (k=0)
0x0D 58 Fiber Channel G.709 ODUk (k=1)
0x0E 58 Fiber Channel G.709 ODUflex
0x0F 58 Fiber Channel G.709 ODUflex
0x10 51 BSOT G.709 ODUk
0x11 52 BSNT G.709 ODUk
0x12 62 InfiniBand G.709 ODUflex
0x13 62 InfiniBand G.709 ODUflex
0x14 62 InfiniBand G.709 ODUflex
0x15 63 Serial Digital Interface G.709 ODUk (k=0)
0x16 64 SDI/1.001 G.709 ODUk (k=1)
0x17 63 Serial Digital Interface G.709 ODUk (k=1)
0x18 64 SDI/1.001 G.709 ODUflex
0x19 63 Serial Digital Interface G.709 ODUflex
0x1A 56 SBCON/ESCON G.709 ODUk (k=0)
0x1B 65 DVB_ASI G.709 ODUk (k=0)
0x1C 58 Fiber Channel G.709 ODUk
0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3)
66 G.709 ODU-1.25G G.709 ODUk (k=1)
0x21 66 G.709 ODU-1.25G G.709 ODUk (k=2,3,4)
67 G.709 ODU-any G.709 ODUk (k=2,3)
0x55 No standard value
0x66 No standard value
0x80-0x8F No standard value
0xFD 68 Null Test G.709 ODUk
0xFE 69 Random Test G.709 ODUk
0xFF No standard valueNote: Values 59 and 70 include mapping of SDH. 🙈
Also, the mapping types for ODUj into OPUk are unambiguously set by Table 7-10 of [G709-2012]. So there's no need to carry mapping type information in the signaling. Totally iconic of the spec 💖
And if you want more on G.709 client mapping, [G7041] has you covered 📚🌸
5. Extensions for Traffic Parameters for Evolving G.709 OTNs 🦋
okay, the Traffic Parameters for the OTN-TDM-capable Switching Type get carried in two places. The first is the OTN-TDM SENDER_TSPEC object in the Path message. The second is the OTN-TDM FLOWSPEC object in the Resv message 💅 Here are their class and type numbers:
- OTN-TDM SENDER_TSPEC object: Class = 12, C-Type = 7
- OTN-TDM FLOWSPEC object: Class = 9, C-Type = 7
Both objects use this layout for their Traffic Parameters ✨
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit_Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Signal Type: 8 bits 🎀
This works just like Section 3.2.1 of [RFC4328], with some extra values added on top 🌈
Value Type
----- ----
4 ODU4 (i.e., 100 Gbps)
9 OCh at 100 Gbps
10 ODU0 (i.e., 1.25 Gbps)
11 ODU2e (i.e., 10 Gbps for FC1200 and GE LAN)
12-19 Reserved (for future use)
20 ODUflex(CBR) (i.e., 1.25*N Gbps)
21 ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
23-255 Reserved (for future use)Note: CBR stands for Constant Bit Rate, and GFP-F stands for Generic Framing Procedure - Framed. 🧚
NVC (Number of Virtual Components): 16 bits 💜
This is defined in Section 3.2.3 of [RFC4328]. One thing to know: this field MUST be set to 0 for ODUflex Signal Types. 🙈
Multiplier (MT): 16 bits ✨
This is defined in Section 3.2.4 of [RFC4328]. Same deal here: this field MUST be set to 1 for ODUflex Signal Types. 💅
Bit_Rate: 32 bits 🦋
For ODUflex, that includes ODUflex(CBR) and ODUflex(GFP) Signal Types, this field gives the nominal bit rate of ODUflex in bytes per second. It's encoded as a 32-bit IEEE single-precision floating-point number, referring to [RFC4506] and [IEEE] 🤓
For every other Signal Type, this field MUST be set to zero on transmission, MUST be ignored on receipt, and SHOULD be passed unmodified by transit nodes. So you set it to zero when you send, ignore it when it comes in, and ideally let transit nodes pass it along untouched 🫶
5.1. Usage of ODUflex(CBR) Traffic Parameters ✨
Okay bestie, for ODUflex(CBR) the Bit_Rate info in the ODUflex Traffic Parameters MUST be used to figure out the real bandwidth, which is Bit_Rate * (1 +/- Tolerance) 💅. That's how the total number of tributary slots N on the HO ODUk link gets reserved correctly 🎀. Here's the formula:
N = Ceiling of
ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
---------------------------------------------------------------------
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)So the ODUflex(CBR) nominal bit rate is the line-side bit rate 🦋. That means the client signal bit rate after the 239/238 factor (see Clause 7.3, Table 7-2 of [G709-2012]) and the transcoding factor T, if the CBR client needs it. Clauses 17.7.3, 17.7.4, and 17.7.5 of [G709-2012] give us:
ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / TThe ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary slots) nominal bit rate is the nominal bit rate of one tributary slot of ODUk. Check out Table 1 (which references Table 7-7 of [G709-2012]) 🌸:
ODUk.ts Minimum Nominal Maximum
-----------------------------------------------------------
ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608
ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823
ODU4.ts 1,301,683.217 1,301,709.251 1,301,735.285
Table 1: Actual TS Bit Rate of ODUk (in Kbps)A few notes on those numbers 🧚:
Minimum bit rate of ODTUk.ts =
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
Maximum bit rate of ODTUk.ts =
ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance)
Where: HO OPUk bit rate tolerance = 20 ppm (parts per million)The bit rate tolerance is implicit in Signal Type. The ODUflex(CBR) bit rate tolerance is fixed at 100 ppm, as Table 7-2 of [G709-2012] describes 🔥.
This means a node that receives a Path message with an ODUflex(CBR) nominal bit rate can work out a precise number of tributary slots and set up the cross-connection for the ODUflex service. Iconic, honestly 👑.
One more thing: the bit rates of the tributary slots are different for each ODUk, so the total number of tributary slots reserved for the ODUflex(CBR) might not match across different HO ODUk links 🌈.
Here's an example to show how the ODUflex(CBR) Traffic Parameters get used 💖:
+-----+ +---------+ +-----+
| +-------------+ +-----+ +-------------+ |
| +=============+\| ODU |/+=============+ |
| +=============+/| flex+-+=============+ |
| +-------------+ | |\+=============+ |
| +-------------+ +-----+ +-------------+ |
| | | | | |
| | ....... | | ....... | |
| A +-------------+ B +-------------+ C |
+-----+ HO ODU4 +---------+ HO ODU2 +-----+
=========: TSs occupied by ODUflex
---------: available TSs
Figure 1: Example of ODUflex(CBR) Traffic ParametersAs Figure 1 shows, say there's an ODUflex(CBR) service asking for 2.5 Gbps from node A to node C 🦋.
Put another way, the ODUflex Traffic Parameters say Signal Type is 20 (ODUflex(CBR)) and Bit_Rate is 2.5 Gbps. The tolerance isn't signaled, as we covered above 🙈.
- On the HO ODU4 link between node A and B: the maximum bit rate of the ODUflex(CBR) is 2.5 Gbps * (1 + 100 ppm), and the minimum bit rate of an ODU4 tributary slot is 1,301,683.217 Kbps. So the total number of tributary slots N1 to reserve on this link is:
N1 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,301,683.217 Kbps) = 2- On the HO ODU2 link between node B and C: the maximum bit rate of the ODUflex is 2.5 Gbps * (1 + 100 ppm), and the minimum bit rate of an ODU2 tributary slot is 1,249,384.632 Kbps. So the total number of tributary slots N2 to reserve on this link is:
N2 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,249,384.632 Kbps) = 35.2. Usage of ODUflex(GFP) Traffic Parameters 🎀
[G709-2012] recommends that ODUflex(GFP) fills a whole number of tributary slots on the smallest HO ODUk path it might ride over. Table 2 has the details 🍓:
ODU Type | Nominal Bit Rate | Tolerance
---------------------------------+------------------+-----------
ODUflex(GFP) of n TSs, 1<=n<=8 | n * ODU2.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 9<=n<=32 | n * ODU3.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 33<=n<=80 | n * ODU4.ts | +/-100 ppm
Table 2: Recommended ODUflex(GFP) Bit Rates and ToleranceBased on this table, the Bit_Rate field for ODUflex(GFP) MUST be equal to one of these 80 values 🧚:
1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts;
9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.Which means the number of tributary slots needed for ODUflex(GFP), the "n" from Table 2, can be worked out straight from the Bit_Rate field 💜.
5.3. Notification on Errors of OTN-TDM Traffic Parameters 🚨
There's no Adspec tied to the OTN-TDM SENDER_TSPEC object 🙈. So either the Adspec gets left out, or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment gets used (see [RFC2210]).
For a given sender in a session, the OTN-TDM FLOWSPEC object in a Resv message SHOULD have the same contents as the OTN-TDM SENDER_TSPEC object in the matching Path message. If they don't match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error MUST be generated 😭.
Intermediate and egress nodes MUST check that they themselves, and the interfaces the LSP will go over, can support the requested Signal Type, NVC, and Bit_Rate values. If they can't support the requested value(s), the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]) 💀.
Also, if the MT field arrives with a zero value, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]) 🫶.
And if the Signal Type is not ODU1, ODU2, or ODU3, and the NVC field is not 0, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]) ✨.
6. Generalized Label ✨
Bestie, this section is where we define the format of the OTN-TDM Generalized Label 🌸.
6.1. OTN-TDM Switching Type Generalized Label
okay so this is the GENERALIZED_LABEL object format that MUST be used with the OTN-TDM Switching Type 💅✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bit Map ...... ~
~ ...... | Padding Bits ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the OTN-TDM GENERALIZED_LABEL object is how you show that an LO ODUj signal gets multiplexed into an HO ODUk link 🦋 the LO ODUj Signal Type is told to you by the Traffic Parameters, and the type of HO ODUk link is identified by the selected interface carried in the IF_ID RSVP_HOP object. it's a whole team effort, bestie 🫶
TPN: 12 bits 🎀
Indicates the TPN for the assigned tributary slot(s).
- In the case of an LO ODUj multiplexed into an HO ODU1/ODU2/ODU3, only the lower 6 bits of the TPN field are significant; the other bits of the TPN field MUST be set to 0.
- In the case of an LO ODUj multiplexed into an HO ODU4, only the lower 7 bits of the TPN field are significant; the other bits of the TPN field MUST be set to 0.
- In the case of ODUj mapped into OTUk (j=k), the TPN is not needed, and this field MUST be set to 0.
Per [G709-2012], the TPN is what lets the data plane demultiplex correctly 🧚 when an LO ODUj is multiplexed into an HO ODUk occupying one or more TSs, a new TPN value gets configured at both ends of the HO ODUk link and goes into the related MSI byte(s) in the OPUk overhead at the (traffic) ingress end of the link. that way the other end can learn which TS(s) the LO ODUj is using in the data plane. main character energy, honestly 👑
According to [G709-2012], the TPN field MUST be set according to the following tables:
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU2 | ODU1 |1-4 |Fixed, = TS# occupied by ODU1 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Fixed, = TS# occupied by ODU1 |
| ODU3 +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
+-------+-------+----+-------------------------------------------+
Table 3: TPN Assignment Rules (2.5 Gbps TS Granularity)
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU1 | ODU0 |1-2 |Fixed, = TS# occupied by ODU0 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-4 |Flexible, != other existing LO ODU1s' TPNs |
| ODU2 +-------+----+-------------------------------------------+
| |ODU0 & |1-8 |Flexible, != other existing LO ODU0s and |
| |ODUflex| |ODUflexes' TPNs |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Flexible, != other existing LO ODU1s' TPNs |
| +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
| ODU3 +-------+----+-------------------------------------------+
| |ODU0 & | |Flexible, != other existing LO ODU0s and |
| |ODU2e &|1-32|ODU2s and ODUflexes' TPNs |
| |ODUflex| | |
+-------+-------+----+-------------------------------------------+
| ODU4 |Any ODU|1-80|Flexible, != ANY other existing LO ODUs' |
| | | |TPNs |
+-------+-------+----+-------------------------------------------+
Table 4: TPN Assignment Rules (1.25 Gbps TS Granularity)note that for "Flexible" entries, the TPN value MAY not match the TS number as per [G709-2012] 🙈
Length: 12 bits 📏
Indicates the number of bits in the Bit Map field, which is the total number of TSs in the HO ODUk link. the TS granularity (1.25 Gbps or 2.5 Gbps) may be worked out by dividing the HO ODUk link's rate by the value of the Length field. in the context of [G709-2012], a Length of 4 or 16 means 2.5 Gbps granularity, and 2, 8, 32, or 80 means 1.25 Gbps granularity 🍓
in the case of an ODUk mapped into OTUk, there's no need to say which tributary slots get used, so the Length field MUST be set to 0 💀
Bit Map: variable 🌈
Indicates which tributary slots in the HO ODUk the LO ODUj will be multiplexed into. the sequence of the Bit Map follows the sequence of the tributary slots in the HO ODUk. each bit stands for its matching tributary slot in the HO ODUk: a 1 means the LO ODUj will use it, and a 0 means it won't 🦋
Padding Bits 🫧
These get added after the Bit Map so the whole label is a multiple of four bytes, if needed. Padding bits MUST be set to 0 and MUST be ignored on receipt 🧚
6.2. Procedures
okay the ingress node MUST generate a Path message and specify the OTN-TDM Switching Type and the matching G-PID in the GENERALIZED_LABEL_REQUEST object, and that Path message MUST be processed as defined in [RFC3473] 💌
the ingress node of an LSP MAY include a Label ERO (Explicit Route Object) subobject to show the label at each hop along the path. fun fact: the TPN in the Label ERO subobject doesn't have to be assigned by the ingress node 🙈 when a node does assign the TPN, that node MUST assign a valid TPN value and then put it into the TPN field of the GENERALIZED_LABEL object when it receives a Path message ✨
to set up a bidirectional LSP, the ingress node and upstream node MUST generate an UPSTREAM_LABEL object on the outgoing interface. this one shows the reserved TSs of ODUk and the assigned TPN value in the upstream direction, and it gets sent to the downstream node in a Path message for upstream resource reservation 🎀
the ingress node or upstream node MAY generate a LABEL_SET object to show which labels on the outgoing interface in the downstream direction are acceptable. the downstream node will narrow down its choice of labels (TS resources and TPN value) to one that's in the LABEL_SET object 🌸
the ingress node or upstream node MAY also generate a SUGGESTED_LABEL object to show its preferred TS resource and TPN value on the outgoing interface in the downstream direction. the downstream node is not required to use the suggested labels. it can pick a different label based on its own local decision and send that back to the upstream node, as described in [RFC3473] 💅
when an upstream node gets a Resv message containing a GENERALIZED_LABEL object with an OTN-TDM label, it MUST first figure out which ODU Signal Type is multiplexed or mapped into which ODU Signal Type, using the Traffic Parameters and the IF_ID RSVP_HOP object in the received message 🔍
- In the case of ODUj-to-ODUk multiplexing, the node MUST look up the reserved tributary slots in the ODUk that its downstream neighbor node picked, using the positions of the bits set to 1 in the Bit Map field. the node works out the TS granularity (from the total TS number of the ODUk or the pre-configured TS granularity), so it can multiplex the ODUj into the ODUk at that granularity. the node MUST also retrieve the TPN value that its downstream neighbor node assigned from the label, and fill the TPN into the related MSI byte(s) in the OPUk overhead in the data plane. that way the downstream neighbor can check whether the TPN it gets from the data plane matches the Expected MSI (ExMSI) and decide if there's any mismatch defect 🧐
- In the case of ODUk-to-OTUk mapping, the size of the Bit Map field MUST be 0, and no additional procedure is needed 🌷
when a downstream node or egress node gets a Path message containing a GENERALIZED_LABEL_REQUEST object for setting up an ODUj LSP from its upstream neighbor node, the node MUST generate an OTN-TDM label based on the Signal Type of the requested LSP and the available resources (the available tributary slots of ODUk) that will be reserved for the LSP. then it sends the label to its upstream neighbor node 💜
- In the case of ODUj-to-ODUk multiplexing, the node MUST first work out the size of the Bit Map field from the Signal Type and the tributary slot type of the ODUk. then it sets the bits to 1 in the Bit Map field for the reserved tributary slots. the node MUST also assign a valid TPN, which MUST NOT collide with other TPN values used by existing LO ODU connections in the selected HO ODU link, and configure the Expected MSI (ExMSI) using that TPN. after that, the assigned TPN MUST be filled into the label 🦋
- In the case of ODUk-to-OTUk mapping, the TPN field MUST be set to 0. Bit Map information is not required and MUST NOT be included, so the Length field MUST be set to 0 as well 🫶
6.2.1. Notification on Label Error
when an upstream node gets a Resv message containing a GENERALIZED_LABEL object with an OTN-TDM label, the node MUST verify whether the label is acceptable. if it isn't, the node MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. per [RFC3473], that generated ResvErr message MAY include an ACCEPTABLE_LABEL_SET object. apart from label semantics, a downstream node that processes a received ResvErr message and ACCEPTABLE_LABEL_SET object is not changed by this document 🌈
same vibe on the other side: when a downstream node gets a Path message containing an UPSTREAM_LABEL object with an OTN-TDM label, the node MUST verify whether the label is acceptable. if it's not, the node MUST generate a PathErr message with a "Routing problem/Unacceptable label value" indication. per [RFC3473], that generated PathErr message MAY include an ACCEPTABLE_LABEL_SET object. apart from label semantics, the upstream nodes that process a received PathErr message and ACCEPTABLE_LABEL_SET object are not changed by this document 💖
a received label SHALL be considered unacceptable when any one of the following happens 🚫
- The received label doesn't conform to local policy;
- An invalid value appears in the Length field;
- The selected link only supports 2.5 Gbps TS granularity, while the Length field in the label along with the ODUk Signal Type indicates 1.25 Gbps TS granularity;
- The label includes an invalid TPN value that breaks the TPN assignment rules; and
- The indicated resources (i.e., the number of "1"s in the Bit Map field) are inconsistent with the Traffic Parameters.
6.3. Supporting Virtual Concatenation and Multiplication 🎀
okay so, Virtual Concatenation Groups (VCGs) can be set up two ways, per [RFC6344]: the One LSP approach or the Multiple LSPs approach 🦋
if you go with One LSP, the explicit ordered list of all labels MUST match the order of the VCG members. it's basically the same vibe as [RFC4328] 💅
now for multiplexed virtually concatenated signals (NVC > 1): the first label MUST point at the components of the first virtually concatenated signal, the second label MUST point at the components of the second one, and so on 🧚
and if you're multiplying multiplexed virtually concatenated signals (MT > 1), it's the same deal. the first label MUST indicate the components of the first multiplexed virtually concatenated signal, the second label MUST indicate the components of the second, and so on ✨
the support for Virtual Concatenation of ODU1, ODU2, and ODU3 Signal Types from [RFC6344] is NOT changed by this document 🙈 (keeping it as written, it's not modified). Virtual Concatenation of other Signal Types is not supported by [G709-2012], so that's a no-go 💀
and multiplier (MT) usage is exactly as defined in [RFC6344] and [RFC4328] 👑
6.4. Examples 🌈
these examples show off the label format from Section 6.1 of this document, so you can see it in action 💜
(1) ODUk-to-OTUk Mapping:
in this one, the downstream node along an LSP sends back a label saying the ODUk (k=1, 2, 3, 4) is directly mapped into the matching OTUk. this example label is an ODU1 mapped into OTU1 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 0 | Reserved | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+(2) ODUj-to-ODUk Multiplexing:
this one is giving multiplexing vibes 🫶 an ODUj gets multiplexed into several tributary slots of OPUk, and then that gets mapped into OTUk. here are some instances:
- ODU0-to-ODU2 Multiplexing:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 2 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the label above is an ODU0 multiplexed into the second tributary slot of ODU2. there are 8 TSs in ODU2 (so the tributary slot type is 1.25 Gbps), and the TPN value is 2 🌸
- ODU1-to-ODU2 Multiplexing with 1.25 Gbps TS Granularity:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+this label is an ODU1 multiplexed into the 2nd and the 4th tributary slots of ODU2. there are 8 TSs in ODU2 (again, 1.25 Gbps per tributary slot type), and the TPN value is 1 ✨
- ODU2 into ODU3 Multiplexing with 2.5 Gbps TS Granularity:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the label above is an ODU2 multiplexed into the 2nd, 3rd, 5th, and 7th tributary slots of ODU3. there are 16 TSs in ODU3 (so the tributary slot type is 2.5 Gbps), and the TPN value is 1 🧚♀️💖
7. Supporting Hitless Adjustment of ODUflex(GFP) 🦋
[G7044] describes the procedure for hitless resizing of ODUflex(GFP) using the Link Connection Resize (LCR) and Bandwidth Resize (BWR) protocols in the OTN data plane. it's giving smooth resizing with no drama 💅
on the control plane side, signaling messages are REQUIRED to kick off the adjustment procedure 🔥 Sections 2.5 and 4.6.4 of [RFC3209] explain how the Shared Explicit (SE) style gets used in the Traffic Engineering (TE) network for increasing and decreasing bandwidth. that's still applicable for triggering the ODUflex(GFP) adjustment procedure in the data plane 🌈
quick heads up: the SE style MUST be used at the beginning when you create a resizable ODUflex connection (Signal Type = 21). otherwise, an error with Error Code "Conflicting reservation style" MUST be generated when you try to adjust bandwidth 🙈
the SE style at setup is non-negotiable, bestie. skip it and you'll get the "Conflicting reservation style" error when you try to resize. 💀
- Bandwidth Increasing
for the ingress node, to increase the bandwidth of an ODUflex(GFP) connection, a Path message with SE style MUST be sent along the path. keep the Tunnel ID unchanged and assign a new LSP ID 🎀
the ingress node triggers the BWR protocol once the LCR protocols finish successfully on every hop after the Resv message is processed. when BWR succeeds, the ingress node SHOULD send a PathTear message to delete the old control state (the control state of the ODUflex(GFP) before resizing) on the control plane 🧹
a downstream node that receives a Path message with SE style compares the old Traffic Parameters (stored locally) with the new ones carried in the Path message. this tells it how many TSs to add. after choosing and reserving the new available TS(s), the downstream node MUST send back a Resv message carrying both the old and new GENERALIZED_LABEL objects in the SE flow descriptor 👑
an upstream neighbor that receives a Resv message with an SE flow descriptor MUST work out which TS(s) are being added, and then trigger the LCR protocol between itself and its downstream neighbor node 🫶
- Bandwidth Decreasing
for the ingress node, a Path message with SE style SHOULD also be sent to decrease the ODUflex bandwidth 🍓
the ingress node triggers the BWR protocol once the LCR handshake finishes successfully on every hop after the Resv message is processed. when BWR succeeds, the second step of LCR (the link connection decrease procedure) starts on every hop of the connection. after decreasing the bandwidth, the ingress node SHOULD send a ResvErr message to tear down the old control state ✨
a downstream node that receives a Path message with SE style compares the old Traffic Parameters with the new ones carried in the Path message, to figure out how many TSs to decrease. after choosing the TSs to be decreased, the downstream node MUST send back a Resv message carrying both the old and new GENERALIZED_LABEL objects in the SE flow descriptor 💖
an upstream neighbor that receives a Resv message with an SE flow descriptor MUST work out which TS(s) are being decreased, and then trigger the first step of the LCR protocol (the LCR handshake) between itself and its downstream neighbor node 🌸
8. Operations, Administration, and Maintenance (OAM) Considerations 🔧
OTN OAM configuration can be done through either Network Management Systems (NMSs) or the GMPLS control plane, as defined in [TDM-OAM] 🧚 [RFC4783] SHOULD be used for communicating alarm information in GMPLS-based OTN 🚨
Management Information Bases (MIBs) may need to be extended to read new information from the OTN devices, like the OTN-TDM Generalized Label and the OTN-TDM SENDER_TSPEC / FLOWSPEC. this is outside the scope of this document 🙈
for more about the management side of GMPLS-based OTN, check out Section 5.7 of [RFC7062] 💜
9. Control-Plane Backward-Compatibility Considerations 🦋
as [RFC7062] describes, [RFC4328] has already been deployed in the network for nodes that support the 2001 revision of the G.709 specification. so control-plane backward compatibility SHOULD be taken into consideration. here's the breakdown:
- Nodes supporting this document SHOULD support [RFC7138].
- Nodes supporting this document MAY support [RFC4328] signaling.
- A node supporting both sets of procedures (i.e., [RFC4328] and this document) is not required to signal an LSP using both procedures, i.e., to act as a signaling version translator.
- Ingress nodes that support both sets of procedures MAY select which set of procedures to follow based on routing information or local policy.
- Per [RFC3473], nodes that do not support this document will generate a PathErr message, with a "Routing problem/Switching Type" indication 🫶
10. Security Considerations 🔐
this document is a modification to [RFC3473] and [RFC4328]. it only differs in the specific information communicated. so this document introduces no new security considerations to the existing GMPLS signaling protocols 💅 Refer to [RFC3473] and [RFC4328] for further details of the specific security measures. on top of that, [RFC5920] gives an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane.
security is not the place to get sloppy, bestie. read those referenced documents for the full picture, because signaling mistakes in a live OTN can take real traffic down. 🚨😭
11. IANA Considerations ✨
okay bestie, IANA is the crew that keeps the official number lists 📋💖 This section says what they added for RFC 7139. First up, the RSVP "C-Types" that got a new OTN-TDM entry 🎀 You'll find the registry at http://www.iana.org/assignments/rsvp-parameters.
Value Description Reference
7 OTN-TDM [RFC7139]Next, the GMPLS Signaling Parameters registry (http://www.iana.org/assignments/gmpls-sig-parameters) has a G-PID subregistry 🦋 RFC 7139 extends and updates it, and here's the whole glow-up:
Value Type Technology Reference
===== ====================== ========== =========
47 G.709 ODU-2.5G G.709 ODUk [RFC4328]
(IANA updated the Type field) [RFC7139]
56 SBCON/ESCON G.709 ODUk, [RFC4328]
(IANA updated the Type field) Lambda, Fiber [RFC7139]
59 Framed GFP G.709 ODUk [RFC7139]
60 STM-1 G.709 ODUk [RFC7139]
61 STM-4 G.709 ODUk [RFC7139]
62 InfiniBand G.709 ODUflex [RFC7139]
63 SDI (Serial Digital Interface) G.709 ODUk [RFC7139]
64 SDI/1.001 G.709 ODUk [RFC7139]
65 DVB_ASI G.709 ODUk [RFC7139]
66 G.709 ODU-1.25G G.709 ODUk [RFC7139]
67 G.709 ODU-any G.709 ODUk [RFC7139]
68 Null Test G.709 ODUk [RFC7139]
69 Random Test G.709 ODUk [RFC7139]
70 64B/66B GFP-F Ethernet G.709 ODUk [RFC7139]The new G-PIDs also show up in the TC MIB that IANA manages at https://www.iana.org/assignments/ianagmplstc-mib 🧚 Here they are:
g709FramedGFP(59),
g709STM1(60),
g709STM4(61),
g709InfiniBand(62),
g709SDI(63),
g709SDI1point001(64),
g709DVBASI(65),
g709ODU1point25G(66),
g709ODUAny(67),
g709NullTest(68),
g709RandomTest(69),
g709GFPFEthernet(70)Quick heads up 👀 IANA did not rename the MIB objects with values 47 and 56. Those names stay the same.
IANA also made a brand new "OTN Signal Type" subregistry under that same GMPLS Signaling Parameters registry 💜 Some values come from RFC 4328, and the rest are from RFC 7139:
Value Signal Type Reference
----- ----------- ---------
0 Not significant [RFC4328]
1 ODU1 (i.e., 2.5 Gbps) [RFC4328]
2 ODU2 (i.e., 10 Gbps) [RFC4328]
3 ODU3 (i.e., 40 Gbps) [RFC4328]
4 ODU4 (i.e., 100 Gbps) [RFC7139]
5 Unassigned [RFC4328]
6 Och at 2.5 Gbps [RFC4328]
7 OCh at 10 Gbps [RFC4328]
8 OCh at 40 Gbps [RFC4328]
9 OCh at 100 Gbps [RFC7139]
10 ODU0 (i.e., 1.25 Gbps) [RFC7139]
11 ODU2e (i.e., 10 Gbps for FC1200 [RFC7139]
and GE LAN)
12-19 Unassigned [RFC7139]
20 ODUflex(CBR) (i.e., 1.25*N Gbps) [RFC7139]
21 ODUflex(GFP-F), resizable [RFC7139]
(i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable [RFC7139]
(i.e., 1.25*N Gbps)
23-255 Unassigned [RFC7139]New values get assigned through a Standards Action, as defined in [RFC5226] 🔥
12. References
12.1. Normative References
These are the must-reads for understanding the spec 📚 Here's the full list:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Ed., 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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation
Standard", STD 67, RFC 4506, May 2006.
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm
Information", RFC 4783, December 2006.
[RFC6344] Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van
Helvoort, "Operating Virtual Concatenation (VCAT) and the
Link Capacity Adjustment Scheme (LCAS) with Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 6344, August
2011.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, March 2014.
[G709-2012] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709/Y.1331 Recommendation, February 2012.
[G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347,
October 2011.
[G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April
2011.
[IEEE] "IEEE Standard for Binary Floating-Point Arithmetic",
ANSI/IEEE Standard 754-1985, Institute of Electrical and
Electronics Engineers, August 1985.12.2. Informative References
These ones are helpful background, but they aren't required reading 🌸
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of G.709
Optical Transport Networks", RFC 7062, November 2013.
[RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed.,
Caviglia, D., Zhang, F., and D. Li, "Evaluation of
Existing GMPLS Encoding against G.709v3 Optical Transport
Networks (OTNs)", RFC 7096, January 2014.
[TDM-OAM] Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for
SONET/SDH and OTN OAM Configuration", Work in Progress,
November 2013.13. Contributors
Huge thanks to these people who helped build this spec 🫶 Their details are below:
Yi Lin
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28972914
EMail: yi.lin@huawei.com
Yunbin Xu
China Academy of Telecommunication Research of MII
11 Yue Tan Nan Jie
Beijing
P.R. China
Phone: +86-10-68094134
EMail: xuyunbin@mail.ritt.com.cn
Pietro Grandi
Alcatel-Lucent
Optics CTO
Via Trento 30 20059 Vimercate
Milano
Italy
Phone: +39 039 6864930
EMail: pietro_vittorio.grandi@alcatel-lucent.it
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
EMail: diego.caviglia@ericsson.com
Rajan Rao
Infinera Corporation
169, Java Drive
Sunnyvale, CA 94089
USA
EMail: rrao@infinera.com
John E Drake
Juniper
EMail: jdrake@juniper.net
Igor Bryskin
Adva Optical
EMail: IBryskin@advaoptical.com
Jonathan Sadler, Tellabs
EMail: jonathan.sadler@tellabs.com
Kam LAM, Alcatel-Lucent
EMail: kam.lam@alcatel-lucent.com
Francesco Fondelli, Ericsson
EMail: francesco.fondelli@ericsson.com
Lyndon Ong, Ciena
EMail: lyong@ciena.com
Biao Lu, infinera
EMail: blu@infinera.com14. Acknowledgments
The authors gave a big shoutout to Lou Berger, Deborah Brungard, and Xiaobing Zi for their useful comments on this doc 💅✨
Authors' Addresses
Here are the editor and authors, with the contact info exactly as it appears in the spec 🎀
Fatai Zhang (editor)
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28972912
EMail: zhangfatai@huawei.com
Guoying Zhang
China Academy of Telecommunication Research of MII
11 Yue Tan Nan Jie
Beijing
P.R. China
Phone: +86-10-68094272
EMail: zhangguoying@mail.ritt.com.cn
Sergio Belotti
Alcatel-Lucent
Optics CTO
Via Trento 30 20059 Vimercate
Milano
Italy
Phone: +39 039 6863033
EMail: sergio.belotti@alcatel-lucent.it
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
EMail: daniele.ceccarelli@ericsson.com
Khuzema Pithewan
Infinera Corporation
169, Java Drive
Sunnyvale, CA 94089
USA
EMail: kpithewan@infinera.comThat's the whole RFC, bestie! 🌈 Thanks for sticking with me through all six parts 💖
📦 where this page comes from
- ietf: rfc7139 2014-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms