RFC 7062
Framework for GMPLS and PCE Control of G.709 Optical Transport Networks
RFC 7062: Framework for GMPLS and PCE Control of G.709 Optical Transport Networks 💖
okay bestie, this one is a framework doc for controlling optical transport networks (OTNs) with GMPLS and PCE. 🦋 It's Informational, so it's not a Standards Track spec, and it came out in November 2013. The authors are F. Zhang (Ed.) from Huawei, D. Li from Huawei, H. Li from CMCC, S. Belotti from Alcatel-Lucent, and D. Ceccarelli from Ericsson. The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates. 🌸
Abstract
okay so the abstract is short and sweet 🎀: this doc gives you a framework so people can build protocol extensions for GMPLS and PCE control of OTNs, as defined in ITU-T Recommendation G.709 (the 2012 edition). ✨
Status of This Memo
this section is the official "what kind of doc is this" bit 💅. It's not an Internet Standards Track spec and it's published just for information. It IS an IETF product with IETF consensus, and it got public review and IESG approval. Being IESG-approved doesn't automatically make something a Internet Standard, though. Check Section 2 of RFC 5741 for that. 🧚
For the current status, errata, and feedback, go to http://www.rfc-editor.org/info/rfc7062.
Copyright Notice
the legal bit 🙈. Copyright is (c) 2013 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, as they were on the publication date, which you can read at http://trustee.ietf.org/license-info. Read those carefully because they spell out your rights. 💜
If you pull Code Components out of this doc, they have to include the Simplified BSD License text from Section 4.e of the Trust Legal Provisions, and they come with no warranty, per that same license. 🔥
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. G.709 Optical Transport Network .................................4
3.1. OTN Layer Network ..........................................5
3.1.1. Client Signal Mapping ...............................6
3.1.2. Multiplexing ODUj onto Links ........................7
3.1.2.1. Structure of MSI Information ...............9
4. Connection Management in OTN ...................................10
4.1. Connection Management of the ODU ..........................11
5. GMPLS/PCE Implications .........................................13
5.1. Implications for Label Switched Path (LSP) Hierarchy ......13
5.2. Implications for GMPLS Signaling ..........................14
5.3. Implications for GMPLS Routing ............................16
5.4. Implications for Link Management Protocol .................18
5.5. Implications for Control-Plane Backward Compatibility .....19
5.6. Implications for Path Computation Elements ................20
5.7. Implications for Management of GMPLS Networks .............20
6. Data-Plane Backward Compatibility Considerations ...............21
7. Security Considerations ........................................21
8. Acknowledgments ................................................22
9. Contributors ...................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................241. Introduction ✨
okay so OTNs are now a mainstream layer 1 technology for transport networks 🌈. Operators want to add GMPLS control-plane features to OTN because they're super useful, like better network resiliency and more efficient resource usage.
GMPLS extends MPLS so it works for TDM networks (like SONET/SDH, PDH, and G.709 sub-lambda), lambda switching optical networks, and spatial switching (for example, from an incoming port or fiber to an outgoing port or fiber). 🦋 The GMPLS architecture lives in [RFC3945]. The signaling and RSVP-TE extensions are in [RFC3471] and [RFC3473]. The routing and OSPF extensions are in [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is in [RFC4204].
The GMPLS signaling extensions in [RFC4328] cover basic GMPLS control of OTN, based on the 2001 revision of G.709. 💅 The 2012 revision, [G709-2012], brings new stuff: more multiplexing structures, two types of Tributary Slots (TSs) (1.25 Gbps and 2.5G bps), and an extended Optical channel Data Unit-j (ODUj) definition that includes the ODUflex function. 🎀
This document looks at the OTN tech changes that affect the GMPLS control-plane protocols. It also explains why and how to update the mechanisms in [RFC4328]. Plus, it gives a framework for GMPLS control of OTN and talks about what it means for using the PCE [RFC4655]. 🫶
For the control plane, the OTN is made up of ODU and wavelength (Optical Channel (OCh)) layers. This doc only focuses on the ODU layer. Control of the wavelength layer is out of scope, so check [RFC6163] if you want the wavelength side. 🧚
2. Terminology 📚
here's the glossary, so you don't get lost in the acronym soup 🍓:
- OTN: Optical Transport Network
- OPU: Optical Channel Payload Unit
- ODU: Optical Channel Data Unit
- OTU: Optical Channel Transport Unit
- OMS: Optical Multiplex Section
- MSI: Multiplex Structure Identifier
- TPN: Tributary Port Number
- LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, or flex) is the container carrying an OTN client. It's either mapped straight into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container. 👑
- HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, or 4) is the entity carrying a multiplex of LO ODUj tributary signals in its OPUk area. ✨
- ODUflex: Flexible ODU. A flexible ODUk can have any bit rate, with a bit rate tolerance of +/-100 ppm (parts per million). 🌸
across the doc, "ODUj" means an ODU acting as an LO ODU, and "ODUk" means an ODU being used as an HO ODU. ⭐
3. G.709 Optical Transport Network 🌊
this section is an informative overview of the OTN bits that matter for control-plane protocols 🦋. It's based on the ITU-T Recommendations, which hold the normative definition of OTN. If you want the deep technical details on OTN architecture and interfaces, go read those Recommendations.
Specifically, [G872-2012] describes the functional architecture of optical transport networks. That covers optical signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. 💜 The legacy OTN referenced by [RFC4328] defines the interfaces used within and between subnetworks of the optical network. Since then, OTN tech has evolved and ITU-T has added lots of new features, like the new ODU0, ODU2e, ODU4, and ODUflex containers described in [G709-2012]. 🔥
3.1. OTN Layer Network 🎀
here's the simplified OTN signal hierarchy, showing the layers the control plane cares about 🫧. Layers below OCh (like the Optical Transmission Section (OTS)) aren't in this figure. For the full hierarchy, see [G709-2012].
Client signal
|
ODUj
|
OTU/OCh
OMSFigure 1: Basic OTN Signal Hierarchy
so basically, client signals get mapped into ODUj containers 🍭. Those ODUj containers get multiplexed onto the OTU/OCh. Then the individual OTU/OCh signals are combined in the OMS using Wavelength Division Multiplexing (WDM), and that aggregated signal is the link between the nodes. 💖 It's giving layers on layers, and it's honestly iconic. 👑
3.1.1. Client Signal Mapping ✨
okay so the client signals get mapped into an LO ODUj 🎀 the current j values from [G709-2012] are: 0, 1, 2, 2e, 3, 4, and flex. the approximate bit rates for these are also defined in [G709-2012], and they're copied into Tables 1 and 2 for you 💖
+-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+
| ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 Kbps |
| ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 Kbps |
| ODU2e | 239/237 x 10,312,500 Kbps |
| | |
| ODUflex for | |
|Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | |
| | |
| ODUflex for Generic | |
| Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | |
| Mapped client signal | |
+-----------------------+-----------------------------------+
Table 1: ODU Types and Bit RatesNOTE: The nominal ODUk rates are approximately: 2,498,775.126 Kbps (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), 104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e). 🧚
+-----------------------+-----------------------------------+
| ODU Type | ODU bit rate tolerance |
+-----------------------+-----------------------------------+
| ODU0 | +/-20 ppm |
| ODU1 | +/-20 ppm |
| ODU2 | +/-20 ppm |
| ODU3 | +/-20 ppm |
| ODU4 | +/-20 ppm |
| ODU2e | +/-100 ppm |
| | |
| ODUflex for CBR | |
| Client signals | +/-100 ppm |
| | |
| ODUflex for GFP-F | |
| Mapped client signal | +/-100 ppm |
+-----------------------+-----------------------------------+
Table 2: ODU Types and Tolerancethere are two options for mapping client signals into ODUflex, and which one you get depends on the type of client signal 💅
- Circuit clients are proportionally wrapped. so the bit rate is defined by the client signal, and the tolerance is fixed to +/-100 ppm. 🦋
- Packet clients are mapped using the Generic Framing Procedure (GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an integral number of tributary slots of the smallest HO ODUk path over which the ODUflex(GFP) may be carried, and the tolerance should be +/-100 ppm. 🌸
note that more info on G.709 client mapping can be found in [G7041] 🫶
3.1.2. Multiplexing ODUj onto Links 🌈
the links between the switching nodes are provided by one or more wavelengths. each wavelength carries one OCh, which carries one OTU, which carries one ODU. since all of these signals have a 1:1:1 relationship, we only refer to the OTU for clarity 🔥 the ODUjs get mapped into the TSs (Tributary Slots) of the OPUk. and in the case where j=k, the ODUj is mapped into the OTU/OCh without multiplexing, which is kind of iconic honestly ✨
the initial versions of G.709 referenced by [RFC4328] only had a single TS granularity, nominally 2.5 Gbps. then [G709-2012] added a second TS granularity, nominally 1.25 Gbps. here's the number and type of TS for each of the currently identified OTUk 👑
Tributary Slot Granularity
2.5 Gbps 1.25 Gbps Nominal Bit Rate
OTU1 1 2 2.5 Gbps
OTU2 4 8 10 Gbps
OTU3 16 32 40 Gbps
OTU4 -- 80 100 Gbpsso here's the tea 🍓 to keep backward compatibility while still letting nodes talk when one end does a 1.25 Gbps TS and the other does a 2.5 Gbps TS, [G709-2012] requires 'new' equipment to fall back to a 2.5 Gbps TS when it's connected to legacy equipment. this info is carried in band by the payload type 🫶
the actual bit rate of the TS in an OTUk depends on the value of k. that means the number of TSs an ODUj occupies can change depending on j and k. for example, an ODU2e uses 9 TSs in an OTU3 but only 8 in an OTU4 😭 here are more examples of how many TSs are used in different cases (referring to Tables 7-9 of [G709-2012]):
- ODU0 into ODU1, ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity 💜
- ODU0 occupies 1 of the 2, 8, 32, or 80 TSs for ODU1, ODU2, ODU3, or ODU4
- ODU1 into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity 💖
- ODU1 occupies 2 of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4
- ODU1 into ODU2 or ODU3 multiplexing with 2.5 Gbps TS granularity 🦋
- ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3
- ODU2 into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity 🌸
- ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4
- ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity ✨
- ODU2 occupies 4 of the 16 TSs for ODU3
- ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity 🔥
- ODU3 occupies 31 of the 80 TSs for ODU4
- ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity 🧚
- ODUflex occupies n of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4 (n <= Total TS number of ODUk)
- ODU2e into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity 👑
- ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for ODU4
in general, the mapping of an ODUj (including ODUflex) into a specific OTUk TS gets decided locally. it can also be explicitly controlled by a specific entity (e.g., head end or Network Management System (NMS)) through Explicit Label Control [RFC3473] 🎀
3.1.2.1. Structure of MSI Information
okay this one's important bestie 🙈 when multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the info that has to be carried in-band so the correct demultiplexing can happen. this info is called MSI, it rides in the OPUk overhead, and it's local to each link. with bidirectional paths, the association between the TPN and TS must be the same in both directions.
the MSI info is organized as a set of entries, with one entry for each HO ODUj TS. the info each entry carries is:
- Payload Type: the type of the transported payload. 💅
- TPN: the port number of the ODUj transported by the HO ODUk. the TPN is the same for all the TSs assigned to the transport of the same ODUj instance. 🦋
for example, an ODU2 carried by an HO ODU3 is described by 4 entries in the OPU3 overhead when the TS granularity is 2.5 Gbps, and by 8 entries when the TS granularity is 1.25 Gbps 🌈
on each node and on every link, two MSI values have to be provisioned (referring to [G798]):
- The Transmitted MSI (TxMSI) information gets inserted in OPU (e.g., OPU3) overhead by the source of the HO ODUk trail. 🍓
- The Expected MSI (ExMSI) information is used to check the Accepted MSI (AcMSI) information. the AcMSI info is the MSI value received in-band, after a three-frame integration. 💜
as described in [G798], the sink of the HO ODU trail checks the complete content of the AcMSI info against the ExMSI. if the AcMSI is different from the ExMSI, then the traffic is dropped, and a payload mismatch alarm is generated. 😭
provisioning of TPN can be done by either a network management system or the control plane. in the last case, the control plane is also responsible for negotiating the provisioned values on a link-by-link basis 🫶
4. Connection Management in OTN ✨
OTN-based connection management is all about controlling the connectivity of ODU paths and OCh 🎀 this document focuses on the connection management of ODU paths. the management of OCh paths is described in [RFC6163] 💖
while [G872-2001] treated the ODU as a set of layers, the same way SDH has been modeled, recent ITU-T OTN architecture progress [G872-2012] agreed to model the ODU as a single-layer network, with the bit rate as a parameter of links and connections. this lets the links and nodes be viewed in a single topology as a common set of resources that can provide ODUj connections no matter what the value of j is 🦋 note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO ODU (which has a one-to-one relationship with the OTU) 🌸
from an ITU-T perspective, the ODU connection topology is represented by that of the OTU link layer, which has the same topology as the OCh layer. this is true whether the OTU supports an HO ODU (where multiplexing is used) or an LO ODU in the case of direct mapping 🧚
so the OTU and OCh layers should be visible in a single topological representation of the network. from a logical perspective, the OTU and OCh may be considered the same logical, switchable entity 👑
note that the OTU link-layer topology may be provided via various infrastructure alternatives, including point-to-point optical connections, optical connections fully in the optical domain, and optical connections involving hybrid sub-lambda/lambda nodes involving 3R, etc. see [RFC6163] for additional info 🌈
Let's go, bestie 🎀
This part picks up right where the last one left off, so no fresh intro needed, we're just vibing straight into the rest of the RFC 🧚
4.1. Connection Management of the ODU
An LO ODUj can be either mapped into the OTUk signal (j = k) or multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is mapped into an OCh. 💜
From the control plane's point of view, there are two kinds of network topology to think about 🦋
(1) ODU layer
In this case, the ODU links are presented between adjacent OTN nodes, as illustrated in Figure 2. In this layer, there are ODU links with a variety of TSs available, and nodes that are Optical Digital Cross Connects (ODXCs). LO ODU connections can be set up based on the network topology. 🌸
Link #5 +--+---+--+ Link #4
+--------------------------| |--------------------------+
| | ODXC | |
| +---------+ |
| Node E |
| |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | |
| |--------| |--------| |--------| |
| ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D
Figure 2: Example Topology for LO ODU Connection ManagementIf an ODUj connection is requested between Node C and Node E, routing/path computation must select a path that has the required number of TSs available and that offers the lowest cost. Signaling is then invoked to set up the path and to provide the information (e.g., selected TSs) required by each transit node to allow the configuration of the ODUj-to-OTUk mapping (j = k) or multiplexing (j < k) and demapping (j = k) or demultiplexing (j < k). 🔥
(2) ODU layer with OCh switching capability
In this case, the OTN nodes interconnect with wavelength switched nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM) or Optical Cross-Connect (OXC)) that are capable of OCh switching; this is illustrated in Figures 3 and 4. There are the ODU layer and the OCh layer, so it is simply a Multi-Layer Network (MLN) (see [RFC6001]). OCh connections may be created on demand, which is described in Section 5.1. ✨
In this case, an operator may choose to allow the underlying OCh layer to be visible to the ODU routing/path computation process, in which case the topology would be as shown in Figure 4. In Figure 3, however, a cloud representing OCh-capable switching nodes is represented. In Figure 3, the operator choice is to hide the real OCh-layer network topology. 🙈
Node E
Link #5 +--------+ Link #4
+------------------------| |------------------------+
| ------ |
| // \\ |
| || || |
| | OCh domain | |
+-+-----+ +------ || || ------+ +-----+-+
| | | \\ // | | |
| |Link #1 | -------- |Link #3 | |
| +--------+ | | +--------+ +
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+Link #2 +---------+ +-------+
Node A Node B Node C Node D
Figure 3: OCh Hidden Topology for LO ODU Connection Management Link #5 +---------+ Link #4
+------------------------| |-----------------------+
| +----| ODXC |----+ |
| +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g |
| +-++ ++-+ |
| | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D
Figure 4: OCh Visible Topology for LO ODUj Connection ManagementIn Figure 4, the cloud in the previous figure is substituted by the real topology. The nodes f, g, and h are nodes with OCh switching capability. 🧚
In the examples (i.e., Figures 3 and 4), we have considered the case in which LO ODUj connections are supported by an OCh connection and the case in which the supporting underlying connection can also be made by a combination of HO ODU/OCh connections. 💅
In this case, the ODU routing/path selection process will request an HO ODU/OCh connection between node C and node E from the OCh domain. The connection will appear at the ODU level as a Forwarding Adjacency, which will be used to create the ODU connection. 👑
5. GMPLS/PCE Implications 🌈
The purpose of this section is to provide a set of requirements to be evaluated for extensions of the current GMPLS protocol suite and the PCE applications and protocols to encompass OTN enhancements and connection management. 🫶
5.1. Implications for Label Switched Path (LSP) Hierarchy 🦋
The path computation for an ODU connection request is based on the topology of the ODU layer. 💖
The OTN path computation can be divided into two layers. One layer is OCh/OTUk; the other is ODUj. [RFC4206] and [RFC6107] define the mechanisms to accomplish creating the hierarchy of LSPs. The LSP management of multiple layers in OTN can follow the procedures defined in [RFC4206], [RFC6001], and [RFC6107]. 🌸
As discussed in Section 4, the route path computation for OCh is in the scope of the Wavelength Switched Optical Network (WSON) [RFC6163]. Therefore, this document only considers the ODU layer for an ODU connection request. 🙈
The LSP hierarchy can also be applied within the ODU layers. One of the typical scenarios for ODU layer hierarchy is to maintain compatibility with introducing new [G709-2012] services (e.g., ODU0 and ODUflex) into a legacy network configuration (i.e., the legacy OTN referenced by [RFC4328]). In this scenario, it may be necessary to consider introducing hierarchical multiplexing capability in specific network transition scenarios. One method for enabling multiplexing hierarchy is by introducing dedicated boards in a few specific places in the network and tunneling these new services through the legacy containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade every network element to [G709-2012] capabilities. 🧚
In such cases, one ODUj connection can be nested into another ODUk (j<k) connection, which forms the LSP hierarchy in the ODU layer. The creation of the outer ODUk connection can be triggered via network planning or by the signaling of the inner ODUj connection. For the former case, the outer ODUk connection can be created in advance based on network planning. For the latter case, the multi-layer network signaling described in [RFC4206], [RFC6107], and [RFC6001] (including related modifications, if needed) is relevant to create the ODU connections with multiplexing hierarchy. In both cases, the outer ODUk connection is advertised as a Forwarding Adjacency (FA). ✨
5.2. Implications for GMPLS Signaling 💜
The signaling function and RSVP-TE extensions are described in [RFC3471] and [RFC3473]. For OTN-specific control, [RFC4328] defines signaling extensions to support control for the legacy G.709 Optical Transport Networks. 🎀
As described in Section 3, [G709-2012] introduced some new features that include the ODU0, ODU2e, ODU4, and ODUflex containers. The mechanisms defined in [RFC4328] do not support such new OTN features, and protocol extensions will be necessary to allow them to be controlled by a GMPLS control plane. 😭
[RFC4328] defines the LSP Encoding Type, the Switching Type, and the Generalized Protocol Identifier (Generalized-PID) constituting the common part of the Generalized Label Request. The G.709 traffic parameters are also defined in [RFC4328]. In addition, the following signaling aspects not included in [RFC4328] should be considered: 🔥
- Support for specifying new signal types and related traffic information
The traffic parameters should be extended in a signaling message to support the new ODUj, including:
- ODU0
- ODU2e
- ODU4
- ODUflex
For the ODUflex signal type, the bit rate MUST be carried additionally in the traffic parameter to set up an ODUflex connection.
For other ODU signal types, the bit rates and tolerances are fixed and can be deduced from the signal types.
- Support for LSP setup using different TS granularity
The signaling protocol SHOULD be able to identify the TS granularity (i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS granularity) to be used for establishing a Hierarchical LSP that will be used to carry service LSP(s) requiring a specific TS granularity.
- Support for LSP setup of new ODUk/ODUflex containers with related mapping and multiplexing capabilities
A new label format MUST be defined to carry the exact TS's allocation information related to the extended mapping and multiplexing hierarchy (for example, ODU0 into ODU2 multiplexing (with 1.25 Gbps TS granularity)), in order to set up the ODU connection.
- Support for TPN allocation and negotiation
TPN needs to be configured as part of the MSI information (see more information in Section 3.1.2.1). A signaling mechanism MUST be identified to carry TPN information if the control plane is used to configure MSI information.
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity Adjustment Scheme (LCAS)
GMPLS signaling SHOULD support the creation of Virtual Concatenation of an ODUk signal with k=1, 2, 3. The signaling SHOULD also support the control of dynamic capacity changing of a VCAT container using LCAS ([G7042]). [RFC6344] has a clear description of VCAT and LCAS control in SONET/SDH and OTN.
- Support for Control of Hitless Adjustment of ODUflex (GFP)
[G7044] has been created in ITU-T to specify hitless adjustment of ODUflex (GFP) (HAO) that is used to increase or decrease the bandwidth of an ODUflex (GFP) that is transported in an OTN.
The procedure of ODUflex (GFP) adjustment requires the participation of every node along the path. Therefore, it is RECOMMENDED to use control-plane signaling to initiate the adjustment procedure in order to avoid manual configuration at each node along the path.
From the perspective of the control plane, control of ODUflex resizing is similar to control of bandwidth increasing and decreasing as described in [RFC3209]. Therefore, the Shared Explicit (SE) style MAY be used for control of HAO.
All the extensions above SHOULD consider the extensibility to match future evolvement of OTN. 🌈
5.3. Implications for GMPLS Routing 🗺️
okay so path computation has to pick a suitable route for every ODUj connection request ✨. to do that, it needs to check how much bandwidth is free on each candidate link 👀. so the routing protocol should be extended to carry enough info to represent the ODU Traffic Engineering (TE) topology 🧚.
The Interface Switching Capability Descriptors from [RFC4202] add a brand new constraint for LSP path computation 💅. [RFC4203] defines the Switching Capability, the related Maximum LSP Bandwidth, and Switching Capability specific information. when the Switching Capability field is TDM, that specific info field includes Minimum LSP Bandwidth, an indication of whether the interface supports Standard or Arbitrary SONET/SDH, and padding 🎀. so we need a new Switching Capability value for [G709-2012] ODU switching, which lets us define a new Switching Capability specific information field 👑. here are the requirements to keep in mind:
- Support for carrying the link multiplexing capability 🌸
as covered in Section 3.1.2, lots of different ODUj types can be multiplexed into the same OTUk 🦋. for example, both ODU0 and ODU1 can be multiplexed into ODU2 💜. an OTU link may support one or more types of ODUj signals, so the routing protocol should be able to carry this multiplexing capability 🫶.
- Support any ODU and ODUflex 🌈
the bit rate (aka bandwidth) of each TS depends on the TS granularity and the signal type of the link 🍓. for example, a 1.25 Gbps TS in an OTU2 is about 1.249409620 Gbps, while a 1.25 Gbps TS in an OTU3 is about 1.254703729 Gbps 🔥.
one LO ODU may need a different number of TSs depending on which HO ODU it's multiplexed into ✨. for example, ODU2e needs 9 TSs when multiplexed into an ODU3, but only 8 TSs when multiplexed into an ODU4 💀. for ODUflex, the total number of TSs to reserve in an HO ODU equals the maximum of [bandwidth of ODUflex / bandwidth of TS of the HO ODU] 🧮.
so the routing protocol should be able to carry the link bandwidth info needed for accurate route computation for every fixed rate ODU, plus ODUflex 💖.
- Support for differentiating between terminating and switching capability 🦄
due to internal constraints and/or limitations, the signal type an interface advertises could be restricted to switched (meaning forwarded to the switching matrix without multiplexing/demultiplexing actions), restricted to terminated (demuxed), or both 🙈. the capability an interface advertises needs extra detail so termination and switching capabilities can be told apart 🫠.
so, to get the flexibility that's needed, the routing protocol should clearly distinguish between terminating and switching capability 💅.
- Support for Tributary Slot Granularity advertisement 🍭
[G709-2012] defines two types of TSs, but each link can only support a single type at any given time 🔒. to do a correct path computation (so the LSP endpoints have matching Tributary Slot Granularity values), the Tributary Slot Granularity needs to be advertised 📣.
- Support different priorities for resource reservation 👑
how many priority levels get supported depends on the operator's policy 🧠. so the routing protocol should be able to support up to 8 priority levels, as defined in [RFC4202] 💜.
- Support link bundling 🧺
as described in [RFC4201], link bundling can improve routing scalability by cutting down the number of TE links the routing protocol has to handle ✨. the routing protocol should be able to bundle multiple OTU links, at the same line rate and muxing hierarchy, between a pair of nodes that a TE link does 🦋. note that link bundling is optional and implementation dependent 🙌.
- Support for Control of Hitless Adjustment of ODUflex (GFP) 🌷
the control plane should support hitless adjustment of ODUflex, so the routing protocol needs to tell whether or not an ODU link can support hitless adjustment of ODUflex (GFP), plus how many resources can be used for resizing 🎀. this can be done by introducing a new signal type, "ODUflex(GFP-F), resizable", which implies that the link supports hitless adjustment of ODUflex (GFP) 🥹.
as mentioned in Section 5.1, one way to enable a multiplexing hierarchy is with dedicated boards that tunnel new services through legacy ODU1, ODU2, and ODU3 containers 🛠️. those dedicated boards may have some constraints on switching matrix access, and detecting and representing those constraints is for further study 🔍.
5.4. Implications for Link Management Protocol 🔗
as discussed in Section 5.3, path computation needs to know the interface switching capability of links 🧩. the two ends of a link may have different switching capabilities, so the link capabilities at both ends should be correlated 💞.
LMP [RFC4204] provides a control-plane protocol for exchanging and correlating link capabilities 📬.
note that LO ODU type info can, in principle, be discovered by routing 🔎. but routing isn't always present (for example, at a User-Network Interface (UNI)), so we need to extend link management protocol capabilities to cover this 🙏. if routing is present, discovery via LMP could also be optional 🌸.
- Correlating the granularity of the TS 🍓
as discussed in Section 3.1.2, the two ends of a link may support different TS granularities 😬. to allow interconnection, the node with 1.25 Gbps granularity should fall back to 2.5 Gbps granularity 🪄.
so the two ends of a link need to correlate the TS granularity 💅. this makes sure the TE link gets used correctly ✨.
- Correlating the supported LO ODU signal types and multiplexing hierarchy capability 🦋
lots of new ODU signal types were introduced in [G709-2012], like ODU0, ODU4, ODU2e, and ODUflex 🤯. equipment might not support every LO ODU signal type introduced by newer standards or documents 🙃. and since legacy OTNs may not support multiplexing hierarchy at all, it's possible that only one end of an ODU link supports the multiplexing hierarchy capability, or that the two ends support different ones 🫣. for example, one end might do ODU0 into ODU1 into ODU3 multiplexing, while the other does ODU0 into ODU2 into ODU3 🎭.
for control and management, the two ends of an HO ODU link need to correlate which LO ODU types they can support, and which multiplexing hierarchy capabilities the other end can provide 💜.
5.5. Implications for Control-Plane Backward Compatibility 🫂
with [G709-2012] in the picture, an OTN could be a mix of nodes 🌈. some nodes support the legacy OTN and run the control-plane protocols defined in [RFC4328], while others support [G709-2012] and the new OTN control plane described in this document 🧁. there's also a third case, for completeness: nodes that support the legacy OTN referenced by [RFC4328] but have a new OTN control plane. those can be considered new nodes with limited capabilities 🌷.
this section talks about how well nodes running the control-plane procedures defined in [RFC4328] for the legacy OTN get along with nodes running the control-plane procedures defined for [G709-2012] in this document 🤝.
compatibility only needs to be considered when controlling an ODU1, ODU2, or ODU3 connection, because the legacy OTN only supports those three ODU signal types 🎯. there are a few possible options here, including:
- a node supporting [G709-2012] could support only the control-plane procedures related to [G709-2012]. in that case, both types of nodes would be unable to jointly control an LSP for an ODU type that both nodes support in the data plane 😭.
- a node supporting [G709-2012] could support both the control plane related to [G709-2012] and the control plane defined in [RFC4328] 🧠.
- such a node could figure out which set of procedures to follow when initiating an LSP, based on the Switching Capability value advertised in routing 🔮.
- such a node could follow the set of procedures based on the Switching Type received in signaling messages from an upstream node 📨.
- such a node, when processing a transit LSP, could choose which signaling procedures to follow based on the Switching Capability value advertised in routing by the next-hop node 🦋.
5.6. Implications for Path Computation Elements 🧭
[RFC7025] describes the requirements for GMPLS applications of PCE, for establishing GMPLS LSPs 📜. once a Path Computation Client (PCC) or another PCE requests a path computation, the PCE needs to consider the GMPLS TE attributes properly 💅. the TE attributes that can be included in the path calculation request message from the PCC, or from the PCE defined in [RFC5440], include switching capability, encoding type, signal type, and so on 🫶.
as described in Section 5.2, new signal types and new signals with variable bandwidth info need to be carried in the extended signaling message for path setup 🛤️. for the same reason, the PCE Communication Protocol (PCECP) also wants to be extended to carry the new signal type and the related variable bandwidth info when a PCC requests a path computation 🌸.
5.7. Implications for Management of GMPLS Networks 🛠️
from the management side, the management function should be able to manage not only the legacy OTN referenced by [RFC4328], but also the new management functions introduced by the new features specified in [G709-2012] (see Sections 3 and 4 for more info) ✨. OTN Operations, Administration, and Maintenance (OAM) configuration can be done through either Network Management Systems (NMS) or the GMPLS control plane, as defined in [TDM-OAM] 🖥️. for more details on management aspects of GMPLS networks, check out [RFC3945] 📖.
in case a PCE is used to perform path computation in OTN, the PCE manageability should be considered (see Section 8 of [RFC5440] for more info) 🎀.
6. Data-Plane Backward Compatibility Considerations ✨
Okay, bestie, let's talk about data-plane backward compatibility 🦋. If MI AUTOpayloadtype is activated (see [G798]), a node that supports 1.25 Gbps TS can interwork with nodes that support 2.5 Gbps TS by combining specific TSs together in the data plane 💖. The control plane must support this TS combination 🫶.
Path
+----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 |
| | \ \--------+--TS7 |
| | \----------+--TS8 |
+----------+ <------------ +----------+
node A Resv node B
Figure 5: Interworking between 1.25 Gbps TS and 2.5 Gbps TSTake Figure 5 as an example 🎀. Say there's an ODU2 link between node A and node B, where node A only supports 2.5 Gbps TS but node B supports 1.25 Gbps TS 🌸. In this case, TS#i and TS#i+4 (where i<=4) on node B get combined together 🧚. When an ODU1 service gets created on this ODU2 link, node B reserves TS#i and TS#i+4 with a granularity of 1.25 Gbps 💅. But in the label that B sends to A, it's indicated that TS#i is reserved with a granularity of 2.5 Gbps 👑.
Going the other way, when node B receives a label from node A saying that TS#i is reserved with a granularity of 2.5 Gbps, node B reserves TS#i and TS#i+4 with a granularity of 1.25 Gbps in its data plane 🔥. It's giving teamwork, periodt ✨.
7. Security Considerations 💀
Okay, this section is serious, so buckle up 😭. Using control-plane protocols for signaling, routing, and path computation opens an OTN up to security threats through attacks on those protocols 🙈. However, this is not greater than the risks already presented by the existing OTN control plane as defined by [RFC4203] and [RFC4328] 🫶. Meanwhile, the Data Communication Network (DCN) for OTN GMPLS control-plane protocols is likely to live in the in-fiber overhead 🌈. That, together with access lists at the network edges, is a significant security feature 🔒. For further details on specific security measures, refer to the documents that define the protocols ([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]) 📚. [RFC5920] gives an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane 💜.
8. Acknowledgments 🌸
Huge thank you to Maarten Vissers and Lou Berger for their reviews and useful comments 💖. Iconic behavior, honestly 👑.
9. Contributors 🍓
Jianrui Han
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28972913
EMail: hanjianrui@huawei.comMalcolm Betts
EMail: malcolm.betts@rogers.comPietro Grandi
Alcatel-Lucent
Optics CTO
Via Trento 30
20059 Vimercate (Milano)
Italy
Phone: +39 039 6864930
EMail: pietro_vittorio.grandi@alcatel-lucent.itEve Varma
Alcatel-Lucent
1A-261, 600-700 Mountain Av
PO Box 636
Murray Hill, NJ 07974-0636
USA
EMail: eve.varma@alcatel-lucent.com10. References 📖
10.1. Normative References 💜
- [G709-2012] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February 2012.
- [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.
- [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
- [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
- [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
- [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
- [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
- [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
- [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
- [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
- [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
- [RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011.
- [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.
10.2. Informative References 🦋
- [G798] ITU-T, "Characteristics of optical transport network hierarchy equipment functional blocks", G.798 Recommendation, December 2012.
- [G872-2001] ITU-T, "Architecture of optical transport networks", G.872 Recommendation, November 2001.
- [G872-2012] ITU-T, "Architecture of optical transport networks", G.872 Recommendation, October 2012.
- [G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April 2011.
- [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for virtual concatenated signals", G.7042/Y.1305, March 2006.
- [G7044] ITU-T, "Hitless adjustment of ODUflex (HAO)", G.7044/Y.1347, October 2011.
- [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
- [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
- [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, April 2011.
- [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
- [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, September 2013.
- [TDM-OAM] Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration", Work in Progress, November 2013.
Authors' Addresses 🎀
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.comDan Li 🌸
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28973237
EMail: huawei.danli@huawei.comHan Li 🧚
China Mobile Communications Corporation
53 A Xibianmennei Ave. Xuanwu District
Beijing 100053
P.R. China
Phone: +86-10-66006688
EMail: lihan@chinamobile.comSergio Belotti 💅
Alcatel-Lucent
Optics CTO
Via Trento 30
20059 Vimercate (Milano)
Italy
Phone: +39 039 6863033
EMail: sergio.belotti@alcatel-lucent.itDaniele Ceccarelli ✨
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
EMail: daniele.ceccarelli@ericsson.com📦 where this page comes from
- ietf: rfc7062 2013-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms