rfc9376.original   rfc9376.txt 
Internet Engineering Task Force Q. Wang, Ed. Internet Engineering Task Force (IETF) Q. Wang, Ed.
Internet-Draft ZTE Corporation Request for Comments: 9376 ZTE Corporation
Intended status: Informational R. Valiveti, Ed. Category: Informational R. Valiveti, Ed.
Expires: 22 May 2023 Infinera Corp ISSN: 2070-1721 Infinera Corp
H. Zheng, Ed. H. Zheng, Ed.
Huawei Huawei
H. Helvoort H. van Helvoort
Hai Gaoming B.V Hai Gaoming BV
S. Belotti S. Belotti
Nokia Nokia
18 November 2022 March 2023
Applicability of GMPLS for Beyond 100G Optical Transport Network Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network
draft-ietf-ccamp-gmpls-otn-b100g-applicability-15
Abstract Abstract
This document examines the applicability of using existing GMPLS This document examines the applicability of using existing GMPLS
routing and signalling mechanisms to set up Optical Data Unit-k routing and signaling mechanisms to set up Optical Data Unit-k (ODUk)
(ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links
links as defined in the 2020 version of G.709. as defined in the 2020 version of ITU-T Recommendation G.709.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 22 May 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9376.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. OTN terminology used in this document . . . . . . . . . . . . 3 2. OTN Terminology Used in This Document
3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 5 3. Overview of OTUCn/ODUCn in G.709
3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. OTUCn
3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. OTUCn-M
3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. ODUCn
3.3. Tributary Slot Granularity . . . . . . . . . . . . . . . 8 3.3. Tributary Slot Granularity
3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8 3.4. Structure of OPUCn MSI with Payload Type 0x22
3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 9 3.5. Client Signal Mappings
4. GMPLS Implications and Applicability . . . . . . . . . . . . 10 4. GMPLS Implications and Applicability
4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 10 4.1. TE Link Representation
4.2. Implications and Applicability for GMPLS Signalling . . . 11 4.2. GMPLS Signaling
4.3. Implications and Applicability for GMPLS Routing . . . . 12 4.3. GMPLS Routing
5. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. References
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Possible Future Work
9.2. Informative References . . . . . . . . . . . . . . . . . 15 Contributors
Appendix A. Possible Future Work . . . . . . . . . . . . . . . . 16 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The current GMPLS routing [RFC7138] and signalling [RFC7139] The current GMPLS routing [RFC7138] and signaling [RFC7139]
extensions support the control of Optical Transport Network (OTN) extensions support the control of the Optical Transport Network (OTN)
signals and capabilities that were defined in the 2012 version of signals and capabilities that were defined in the 2012 version of
G.709 [ITU-T_G709_2012]. ITU-T Recommendation G.709 [ITU-T_G709_2012].
In 2016 a further version of G.709 was published: [ITU-T_G709_2016]. In 2016, a new version of ITU-T Recommendation G.709 was published:
This version introduced higher rate Optical Transport Unit (OTU) and [ITU-T_G709_2016]. This version introduced higher-rate Optical
Optical Data Unit (ODU) signals, termed OTUCn and ODUCn respectively, Transport Unit (OTU) and Optical Data Unit (ODU) signals, termed
which have a nominal rate of n x 100 Gbit/s. According to the "OTUCn" and "ODUCn", respectively, which have a nominal rate of n*100
definition in [ITU-T_G709_2016], OTUCn and ODUCn perform only the Gbit/s. According to the definition in [ITU-T_G709_2016], OTUCn and
digital section layer role and ODUCn supports only ODUk clients. ODUCn perform only the digital section-layer role, and ODUCn supports
This document focuses on the use of existing GMPLS mechanisms to set only ODUk clients. This document focuses on the use of existing
up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, GMPLS mechanisms to set up ODUk (e.g., ODUflex) Label Switched Paths
independently from how these links have been set up. (LSPs) over ODUCn links, independently from how these links have been
set up.
Because [ITU-T_G709_2020] does not introduce any new features to Because [ITU-T_G709_2020] does not introduce any new features to
OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts OTUCn and ODUCn compared to [ITU-T_G709_2016], this document first
with [ITU-T_G709_2020] by first presenting an overview of the OTUCn presents an overview of the OTUCn and ODUCn signals in
and ODUCn signals, and then analyzing how the current GMPLS routing [ITU-T_G709_2020] and then analyzes how the current GMPLS routing and
and signalling mechanisms can be utilized to set up ODUk (e.g., signaling mechanisms can be utilized to set up ODUk (e.g., ODUflex)
ODUflex) LSPs over ODUCn links. LSPs over ODUCn links.
This document assumes that the reader is familiar with OTN, GMPLS, This document assumes that readers are familiar with OTN, GMPLS, and
and how GMPLS is applied in OTN networks. As such, this document how GMPLS is applied in OTN. As such, this document doesn't provide
doesn't provide any background pertaining to OTN networks that any background pertaining to OTN that include links with capacities
included links with capacities of 100G or less; this background could of 100 Gbit/s or less; this background could be found in documents
be found in documents such as [RFC7062] and [RFC7096]. This document such as [RFC7062] and [RFC7096]. This document provides an overview
provides an overview of the dataplane primitives that enable links of the data plane primitives that enable links with capacities
with capacities greater than 100G, and analyses the extensions that greater than 100 Gbit/s and analyzes the extensions that would be
would be required in the current GMPLS routing & signaling mechanisms required in the current GMPLS routing and signaling mechanisms to
to support the evolution in OTN networks. support evolution in OTN.
2. OTN terminology used in this document 2. OTN Terminology Used in This Document
* FlexO: Flexible OTN information structure. This information FlexO: Flexible OTN information structure. This information
structure is usually with a specific bit rate and frame format, structure usually has a specific bitrate and frame format that
consisting of overhead and payload, which is used as a group for consists of overhead and payload, which are used as a group for
the transport of an OTUCn signal. the transport of an OTUCn signal.
* LSP: Label Switched Path. LSP: Label Switched Path
* ODU: Optical Data Unit. An ODU has the frame structure and MSI: Multiplex Structure Indicator. This structure indicates the
grouping of the tributary slots in an OPU payload area that
realizes a client signal, which is multiplexed into an OPU. The
individual clients multiplexed into the OPU payload area are
distinguished by the Tributary Port Number (TPN).
ODU: Optical Data Unit. An ODU has the frame structure and
overhead, as defined in Figure 12-1 of [ITU-T_G709_2020]. ODUs overhead, as defined in Figure 12-1 of [ITU-T_G709_2020]. ODUs
can be formed in two ways: a) by encapsulating a single non-OTN can be formed in two ways: a) by encapsulating a single non-OTN
client (such as SONET/SDH, Ethernet) b) multiplexing lower-rate client, such as SONET/SDH (Synchronous Optical Network /
ODUs. In general, the ODU layer represents the path layer in OTN Synchronous Digital Hierarchy) or Ethernet, or b) by multiplexing
networks. The only exception is the ODUCn signal (defined below) lower-rate ODUs. In general, the ODU layer represents the path
which is defined to be a section layer signal. In the layer in OTN. The only exception is the ODUCn signal (defined
below), which is defined to be a section-layer signal. In the
classification based on bitrates of the ODU signals, ODUs are of classification based on bitrates of the ODU signals, ODUs are of
two types: Fixed rate, and flexible rate. Flexible rate ODU(s), two types: fixed rate and flexible rate. Flexible-rate ODUs,
called "ODUFlex" have a rate that is 239/238 times the bit rate of called "ODUflex", have a rate that is 239/238 times the bitrate of
the client signal it encapsulates. the client signal they encapsulate.
* ODUk: Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. ODUC: Optical Data Unit-C. This signal has a bandwidth of
The term ODUk references to an ODU whose bit rate is fully approximately 100 Gbit/s and is of a slightly higher bitrate than
specified by the index k. The bit rates of the ODUk signal for k the fixed rate ODU4 signal. This signal has the format defined in
= {0, 1, 2, 2e, 3, 4} are approximately 1.25G, 2.5G, 10G, 10.3G, Figure 12-1 of [ITU-T_G709_2020]. This signal represents the
40G, 100G respectively. building block for constructing a higher-rate signal called
"ODUCn" (defined below).
* ODUflex: Optical Data Unit - flexible rate. An ODUflex has the ODUCn: Optical Data Unit-Cn, where Cn indicates the bitrate of
same frame structure as a "generic" ODU, but with rate that is a approximately n*100 Gbit/s. This frame structure consists of "n"
fixed multiple of the bitrate of the client signal it interleaved frame and multiframe synchronous instances of the ODUC
encapsulates. ITU-T defines specific ODUflex containers that are signal, each of which has the format defined in Figure 12-1 of
[ITU-T_G709_2020].
ODUflex: Optical Data Unit - flexible rate. An ODUflex has the same
frame structure as a "generic" ODU but with a rate that is a fixed
multiple of the bitrate of the client signal it encapsulates.
[ITU-T_G709_2020] defines specific ODUflex containers that are
required to transport specific clients such as 50GE, 200GE, 400GE, required to transport specific clients such as 50GE, 200GE, 400GE,
etc. etc.
* ODUC: Optical Data Unit -C; this signal has a bandwidth of ODUk: Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}.
approximately 100G, and is of a slightly higher bit rate than the The term "ODUk" refers to an ODU whose bitrate is fully specified
fixed rate ODU4 signal. This signal has the format defined in by the index k. The bitrates of the ODUk signal for k = {0, 1, 2,
Figure 12-1 of [ITU-T_G709_2020]. This signal represents the 2e, 3, 4} are approximately 1.25 Gbit/s, 2.5 Gbit/s, 10 Gbit/s,
building block for constructing a higher rate signal called ODUCn 10.3 Gbit/s, 40 Gbit/s, and 100 Gbit/s, respectively.
(defined below).
* ODUCn: Optical Data Unit-Cn; Cn indicates the bit rate of
approximately n*100G. This frame structure consists of "n"
interleaved, frame and multi-frame synchronous instances of the
ODUC signal, each of which has the format defined in Figure 12-1
of [ITU-T_G709_2020].
* OPUC: Optical Payload Unit -C; with a payload of approximately OPUC: Optical Payload Unit-C. This signal has a payload of
100G. This structure represents the payload area of the ODUC approximately 100 Gbit/s. This structure represents the payload
signal. area of the ODUC signal.
* OPUCn: Optical Payload Unit-Cn. Where Cn indicates that the bit OPUCn: Optical Payload Unit-Cn, where Cn indicates that the bitrate
rate is approximately n*100G. This structure represents the is approximately n*100 Gbit/s. This structure represents the
payload area of the ODUCn signal. payload area of the ODUCn signal.
* OTUC: Optical Transport Unit -C; with a bandwidth of approximately OTN: Optical Transport Network
100G. This signal forms the building block of the OTUCn signal
defined below, which has a bandwidth of approximately n*100G.
* OTUCn: Fully standardized Optical Transport Unit-Cn. This frame OTUC: Optical Transport Unit-C. This signal has a bandwidth of
approximately 100 Gbit/s. This signal forms the building block of
the OTUCn signal defined below, which has a bandwidth of
approximately n*100 Gbit/s.
OTUCn: Fully standardized Optical Transport Unit-Cn. This frame
structure is realized by extending the ODUCn signal with the OTU structure is realized by extending the ODUCn signal with the OTU
layer overhead. The structure of this signal is illustrated in layer overhead. The structure of this signal is illustrated in
Figure 11-1 of [ITU-T_G709_2020]. Note that the term "fully Figure 11-4 of [ITU-T_G709_2020]. Note that the term "fully
standardized" is defined by ITU-T in standardized" is defined by ITU-T in Section 6.1.1 of
[ITU-T_G709_2020]:Section 6.1.1. [ITU-T_G709_2020].
* OTUCn-M: This signal is an extension of the OTUCn signal
introduced above. This signal contains the same amount of
overhead as the OTUCn signal, but contains a reduced amount of
payload area. Specifically, the payload area consists of M 5
Gbit/s tributary slots - where M is less than 20*n, which is the
number of tributary slots in the OTUCn signal.
* OTN: Optical Transport Network. OTUCn-M: This signal is an extension of the OTUCn signal introduced
above. This signal contains the same amount of overhead as the
OTUCn signal but contains a reduced amount of payload area.
Specifically, the payload area consists of M tributary slots (each
5 Gbit/s), where M is less than 20*n, which is the number of
tributary slots in the OTUCn signal.
* PSI: OPU Payload Structure Indicator. This is a 256-byte signal PSI: Payload Structure Indicator. This is a 256-byte signal that
that describes the composition of the OPU signal. This field is a describes the composition of the OPU signal. This field is a
concatenation of the Payload type (PT) and the Multiplex Structure concatenation of the payload type (PT) and the Multiplex Structure
Indicator (MSI) defined below. Indicator (MSI) defined below.
* MSI: Multiplex Structure Indicator. This structure indicates the TPN: Tributary Port Number. The tributary port number is used to
grouping of the tributary slots in an OPU payload area that
realizes a client signal which is multiplexed into an OPU. The
individual clients multiplexed into the OPU payload area are
distinguished by the Tributary Port Number (TPN).
* TPN: Tributary Port Number. The tributary port number is used to
indicate the port number of the client signal that is being indicate the port number of the client signal that is being
transported in one specific tributary slot. transported in one specific tributary slot.
Detailed descriptions of these terms can be found in Detailed descriptions for some of these terms can be found in
[ITU-T_G709_2020]. [ITU-T_G709_2020].
3. Overview of the OTUCn/ODUCn in G.709 3. Overview of OTUCn/ODUCn in G.709
This section provides an overview of OTUCn/ODUCn signals defined in This section provides an overview of the OTUCn/ODUCn signals defined
[ITU-T_G709_2020]. The text in this section is purely descriptive in [ITU-T_G709_2020]. The text in this section is purely descriptive
and is not normative. For a full description of OTUCn/ODUCn signals and is not normative. For a full description of OTUCn/ODUCn signals,
please refer to [ITU-T_G709_2020]. In the event of any discrepancy please refer to [ITU-T_G709_2020]. In the event of any discrepancy
between this text and [ITU-T_G709_2020], that other document is between this text and [ITU-T_G709_2020], that other document is
definitive. definitive.
3.1. OTUCn 3.1. OTUCn
In order to carry client signals with rates greater than 100 Gbit/s, In order to carry client signals with rates greater than 100 Gbit/s,
[ITU-T_G709_2020] takes a general and scalable approach that [ITU-T_G709_2020] takes a general and scalable approach that
decouples the rates of OTU signals from the client rate. The new OTU decouples the rates of OTU signals from the client rate. The new OTU
signal is called OTUCn, and this signal is defined to have a rate of signal is called "OTUCn", and this signal is defined to have a rate
(approximately) n*100G. The following are the key characteristics of of (approximately) n*100 Gbit/s. The following are the key
the OTUCn signal: characteristics of the OTUCn signal:
* The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals * The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals
perform digital section roles only (see perform digital section-layer roles only (see Section 6.1.1 of
[ITU-T_G709_2020]:Section 6.1.1) [ITU-T_G709_2020])
* The OTUCn signals can be viewed as being formed by interleaving n * The OTUCn signals are formed by interleaving n synchronous OTUC
synchronous OTUC signals (which are labeled 1, 2, ..., n). signals (which are labeled 1, 2, ..., n).
* Each of the OTUC instances has the same overhead as the standard * Each of the OTUC instances has the same overhead as the standard
OTUk signal in [ITU-T_G709_2020]. Note that the OTUC signal OTUk signal in [ITU-T_G709_2020]. Note that the OTUC signal
doesn't include the FEC columns illustrated in doesn't include the Forward Error Correction (FEC) columns
[ITU-T_G709_2020]:Figure 11-1. The OTUC signal includes an ODUC. illustrated in Figure 11-1 of [ITU-T_G709_2020]. The OTUC signal
includes an ODUC.
* The OTUC signal has a slightly higher rate compared to the OTU4 * The OTUC signal has a slightly higher rate compared to the OTU4
signal (without FEC); this is to ensure that the OPUC payload area signal (without FEC); this is to ensure that the OPUC payload area
can carry an ODU4 signal. can carry an ODU4 signal.
* The combined signal OTUCn has n instances of OTUC overhead, and n * The combined signal OTUCn has n instances of OTUC overhead and n
instances of ODUC overhead. instances of ODUC overhead.
The OTUCn, ODUCn and OPUCn signal structures are presented in a The OTUCn, ODUCn, and OPUCn signal structures are presented in a
(physical) interface independent manner, by means of n OTUC, ODUC and (physical) interface-independent manner, by means of n OTUC, ODUC,
OPUC instances that are marked #1 to #n. and OPUC instances that are marked #1 to #n.
OTUCn interfaces can be categorized as follows, based on the type of OTUCn interfaces can be categorized as follows, based on the type of
peer network element: peer network element:
* inter-domain interfaces: These types of interfaces are used for inter-domain interfaces: These types of interfaces are used for
connecting OTN edge nodes to (a) client equipment (e.g. routers) connecting OTN edge nodes to (a) client equipment (e.g., routers)
or (b) hand-off points from other OTN networks. ITU-T or (b) hand-off points from other OTN. ITU-T Recommendation
Recommendation [ITU-T_G709.1] specifies a flexible interoperable G709.1 [ITU-T_G709.1] specifies a flexible interoperable short-
short-reach OTN interface over which an OTUCn (n >=1) is reach OTN interface over which an OTUCn (n >=1) is transferred,
transferred, using bonded Flexible OTN information structure using bonded Flexible OTN information structure (FlexO)
(FlexO) interfaces which belong to a FlexO group. interfaces, which belong to a FlexO group.
* intra-domain interfaces: In these cases, the OTUCn is transported intra-domain interfaces: In these cases, the OTUCn is transported
using a proprietary (vendor specific) encapsulation, FEC etc. It using a proprietary (vendor-specific) encapsulation, FEC, etc. It
is also possible to transport OTUCn for intra-domain links using is also possible to transport OTUCn for intra-domain links using
FlexO. FlexO.
3.1.1. OTUCn-M 3.1.1. OTUCn-M
The standard OTUCn signal has the same rate as that of the ODUCn The standard OTUCn signal has the same rate as the ODUCn signal.
signal. This implies that the OTUCn signal can only be transported This implies that the OTUCn signal can only be transported over
over wavelength groups which have a total capacity of multiples of wavelength groups that have a total capacity of multiples of
(approximately) 100G. Modern optical interfaces support a variety of (approximately) 100 Gbit/s. Modern optical interfaces support a
bit rates per wavelength, depending on the reach requirements for the variety of bitrates per wavelength, depending on the reach
optical path. If the total rate of the ODUk LSPs planned to be requirements for the optical path. If the total rate of the ODUk
carried over an ODUCn link is smaller than n*100G, it is possible to LSPs planned to be carried over an ODUCn link is smaller than n*100
"crunch" the OTUCn not to transmit the unused tributary slots. ITU-T Gbit/s, it is possible to "crunch" the OTUCn, and the unused
supports the notion of a reduced rate OTUCn signal, termed the OTUCn- tributary slots are thus not transmitted. [ITU-T_G709_2020] supports
M. The OTUCn-M signal is derived from the OTUCn signal by retaining the notion of a reduced-rate OTUCn signal, termed "OTUCn-M". The
all the n instances of overhead (one per OTUC instance) but with only OTUCn-M signal is derived from the OTUCn signal by retaining all the
M (M is less than 20*n) OPUCn tributary slots available to carry ODUk n instances of overhead (one per OTUC instance) but with only M (M is
LSPs. less than 20*n) OPUCn tributary slots available to carry ODUk LSPs.
3.2. ODUCn 3.2. ODUCn
The ODUCn signal defined in [ITU-T_G709_2020] can be viewed as being The ODUCn signal defined in [ITU-T_G709_2020] can be viewed as being
formed by the appropriate interleaving of content from n ODUC signal formed by the appropriate interleaving of content from n ODUC signal
instances. The ODUC frames have the same structure as a standard ODU instances. The ODUC frames have the same structure as a standard ODU
in the sense that it has the same overhead and payload areas, but has in the sense that the frames have the same overhead and payload areas
a higher rate since its payload area can embed an ODU4 signal. but have a higher rate since their payload area can embed an ODU4
signal.
The ODUCn is a multiplex section ODU signal, and is mapped into an The ODUCn is a multiplex section ODU signal and is mapped into an
OTUCn signal which provides the regenerator section layer. In some OTUCn signal, which provides the regenerator section layer. In some
scenarios, the ODUCn, and OTUCn signals will be co-terminated, i.e. scenarios, the ODUCn and OTUCn signals will be coterminated, i.e.,
they will have identical source/sink locations (see Figure 1). In they will have identical source/sink locations (see Figure 1). In
this figure, the term "OTN Switch" has the same meaning as that used Figure 1, the term "OTN Switch" has the same meaning as that used in
in [RFC7138]:Section 3. [ITU-T_G709_2020] allows for the ODUCn Section 3 of [RFC7138]. [ITU-T_G709_2020] allows for the ODUCn
signal to pass through one or more digital regenerator nodes (shown signal to pass through one or more digital regenerator nodes (shown
as Nodes B, C in Figure 2) which will terminate the OTUCn layer, but as nodes B and C in Figure 2), which will terminate the OTUCn layer
will pass the regenerated (but otherwise untouched) ODUCn towards a but will pass the regenerated (but otherwise untouched) ODUCn towards
different OTUCn interface where a fresh OTUCn layer will be a different OTUCn interface where a fresh OTUCn layer will be
initiated. This process is termed as "ODUCn regeneration" in initiated. This process is termed as "ODUCn regeneration" in
[ITU-T_G872]:Section 7.1. In this example, the ODUCn is carried by 3 Section 7.1 of [ITU-T_G872]. In this example, the ODUCn is carried
OTUCn segments. by three OTUCn segments.
Specifically, the OPUCn signal flows through these regenerators Specifically, the OPUCn signal flows through these regenerators
unchanged. That is, the set of client signals, their TPNs, unchanged. That is, the set of client signals, their TPNs, and
tributary-slot allocation remains unchanged. tributary-slot allocations remains unchanged.
+--------+ +--------+ +--------+ +--------+
| +-----------+ | | +-----------+ |
| OTN |-----------| OTN | | OTN |-----------| OTN |
| Switch +-----------+ Switch | | Switch +-----------+ Switch |
| A | | B | | A | | B |
| +-----------+ | | +-----------+ |
+--------+ +--------+ +--------+ +--------+
<--------ODUCn-------> <--------ODUCn------->
<-------OTUCn------> <-------OTUCn------>
Figure 1: ODUCn signal Figure 1: ODUCn Signal
+---------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| +--------+ | | +----------+ | | +--------+ | | +----------+ |
| OTN |--------| OTN | | OTN |----------| OTN | | OTN |--------| OTN | | OTN |----------| OTN |
| Switch +--------+ Regen +--------+ Regen +----------+ Switch | | Switch +--------+ Regen +--------+ Regen +----------+ Switch |
| A | | B | | C | | D | | A | | B | | C | | D |
| +--------+ | | +----------+ | | +--------+ | | +----------+ |
+---------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
<-------------------------ODUCn--------------------------> <-------------------------ODUCn-------------------------->
<---------------><-----------------><------------------> <---------------><-----------------><------------------>
OTUCn OTUCn OTUCn OTUCn OTUCn OTUCn
Figure 2: ODUCn signal - multihop Figure 2: ODUCn Signal - Multi-Hop
3.3. Tributary Slot Granularity 3.3. Tributary Slot Granularity
[ITU-T_G709_2012] introduced the support for 1.25 Gbit/s granular [ITU-T_G709_2012] introduced the support for 1.25 Gbit/s granular
tributary slots in OPU2, OPU3, and OPU4 signals. [ITU-T_G709_2020] tributary slots in OPU2, OPU3, and OPU4 signals. [ITU-T_G709_2020]
defined the OPUC with a 5 Gbit/s tributary slot granularity. This defined the OPUC with a 5 Gbit/s tributary slot granularity. This
means that the ODUCn signal has 20*n tributary slots (of 5 Gbit/s means that the ODUCn signal has 20*n tributary slots (of 5 Gbit/s
capacity). The range of tributary port number (TPN) is 10*n instead capacity). The range of tributary port number (TPN) is 10*n instead
of 20*n, which restricts the maximum client signals that could be of 20*n, which restricts the maximum client signals that could be
carried over one single ODUC1. carried over one single ODUC1.
3.4. Structure of OPUCn MSI with Payload type 0x22 3.4. Structure of OPUCn MSI with Payload Type 0x22
As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary As mentioned above, the OPUCn signal has 20*n tributary slots (TSs)
slots (TSs). The OPUCn MSI field has a fixed length of 40*n bytes (each 5 Gbit/s). The OPUCn MSI field has a fixed length of 40*n
and indicates the availability and occupation of each TS. Two bytes bytes and indicates the availability and occupation of each TS. Two
are used for each of the 20*n tributary slots, and each such bytes are used for each of the 20*n tributary slots, and each such
information structure has the following format information structure has the following format (see Section 20.4.1 of
([ITU-T_G709_2020]:Section 20.4.1): [ITU-T_G709_2020]):
* The TS availability bit indicates if the tributary slot is * The TS availability bit indicates if the tributary slot is
available or unavailable available or unavailable.
* The TS occupation bit indicates if the tributary slot is allocated * The TS occupation bit indicates if the tributary slot is allocated
or unallocated or unallocated.
* The tributary port number (14 bits) of the client signal that is * The tributary port number (14 bits) indicates the port number of
being carried in this specific TS. A flexible assignment of the client signal that is being carried in this specific TS. A
tributary port to tributary slots is possible. Numbering of flexible assignment of tributary port to tributary slots is
tributary ports is from 1 to 10*n. possible. Numbering of tributary ports is from 1 to 10*n.
The concatenation of the OPUCn payload type (PT) and the MSI field is The concatenation of the OPUCn payload type (PT) and the MSI field is
carried over the overhead byte designated as PSI in carried over the overhead byte designated as PSI in Figure 15-6 of
[ITU-T_G709_2020]:Figure 15-6. [ITU-T_G709_2020].
3.5. Client Signal Mappings 3.5. Client Signal Mappings
The approach taken by the ITU-T to map non-OTN client signals to the The approach taken by the ITU-T to map non-OTN client signals to the
appropriate ODU containers is as follows: appropriate ODU containers is as follows:
* All client signals are mapped into an ODUj, or ODUk (e.g., * All client signals are mapped into an ODUj or ODUk (e.g., ODUflex)
ODUflex) as specified in clause 17 of [ITU-T_G709_2020]. as specified in Section 17 of [ITU-T_G709_2020].
* The terms ODUj & ODUk are used in a multiplexing scenario, with * The terms "ODUj" and "ODUk" are used in a multiplexing scenario,
ODUj being a low-order ODU which is multiplexed into ODUk, a high- with ODUj being a low-order ODU that is multiplexed into ODUk, a
order ODU. As Figure 3 illustrates, the ODUCn is also a high- high-order ODU. As Figure 3 illustrates, the ODUCn is also a
order ODU into which other ODUs can be multiplexed; the ODUCn high-order ODU into which other ODUs can be multiplexed. The
itself cannot be multiplexed into any higher rate ODU signal; it ODUCn itself cannot be multiplexed into any higher-rate ODU
is defined to be a section level signal. signal; it is defined to be a section-level signal.
* ODUflex signals are low-order signals only. If the ODUflex * ODUflex signals are low-order signals only. If the ODUflex
entities have rates of 100G or less, they can be transported over entities have rates of 100 Gbit/s or less, they can be transported
either an ODUk (k=1..4) or an ODUCn. For ODUflex connections with over either an ODUk (k=1..4) or an ODUCn. For ODUflex connections
rates greater than 100G, ODUCn is required. with rates greater than 100 Gbit/s, ODUCn is required.
* ODU Virtual Concatenation has been deprecated. This simplifies * ODU Virtual Concatenation (VCAT) has been deprecated. This
the network, and the supporting hardware since multiple different simplifies the network and the supporting hardware since multiple
mappings for the same client are no longer necessary. Note that different mappings for the same client are no longer necessary.
legacy implementations that transported sub-100G clients using ODU Note that legacy implementations that transported sub-100 Gbit/s
VCAT shall continue to be supported. clients using ODU VCAT shall continue to be supported.
Clients (e.g. SONET/SDH, Ethernet) Clients (e.g., SONET/SDH and Ethernet)
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
+---+---+---+----+ | | | +---+---+---+----+ | | |
| OPUj | | | | | OPUj | | | |
+----------------+ | | | +----------------+ | | |
| ODUj | | | | | ODUj | | | |
+----------------+----------------------+---+---+----------+ +----------------+----------------------+---+---+----------+
| | | |
skipping to change at page 10, line 31 skipping to change at line 421
| | | | | | | |
| OTUk, OTUk-SC, OTUk-V | | OPUCn | | OTUk, OTUk-SC, OTUk-V | | OPUCn |
+-------------------------+ +--------------------------+ +-------------------------+ +--------------------------+
| | | |
| ODUCn | | ODUCn |
+--------------------------+ +--------------------------+
| | | |
| OTUCn | | OTUCn |
+--------------------------+ +--------------------------+
Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1) Figure 3: Digital Structure of OTN Interfaces (from Figure 6-1 of
[ITU-T_G709_2020])
4. GMPLS Implications and Applicability 4. GMPLS Implications and Applicability
4.1. TE-Link Representation 4.1. TE Link Representation
Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk with Section 3 of [RFC7138] describes how to represent G.709 OTUk/ODUk
TE-Links in GMPLS. In the same manner, OTUCn links can also be with TE links in GMPLS. In the same manner, OTUCn links can also be
represented as TE-links. Figure 4 below provides an illustration of represented as TE links. Figure 4 provides an illustration of a one-
a one-hop OTUCn TE link. hop OTUCn TE link.
+----------+ +---------+ +----------+ +---------+
| OTN | | OTN | | OTN | | OTN |
| Switch +-------------------+ Switch | | Switch +-------------------+ Switch |
| A | | B | | A | | B |
+----------+ +---------+ +----------+ +---------+
|<---------OTUCn Link---------->| |<---------OTUCn Link---------->|
|<---------TE-Link------------->| |<---------TE Link------------->|
Figure 4: OTUCn TE-Links Figure 4: One-Hop OTUCn TE Link
It is possible to create TE-links that span more than one hop by It is possible to create TE links that span more than one hop by
creating forward adjacencies (FA) between non-adjacent nodes (see creating forward adjacencies (FAs) between non-adjacent nodes (see
Figure 5). In this illustration, the nodes B and C are performing Figure 5). In Figure 5, nodes B and C are performing the ODUCn
the ODUCn regeneration function described in regeneration function described in Section 7.1 of [ITU-T_G872] and
[ITU-T_G872]:Section 7.1, and are not electrically switching the are not electrically switching the ODUCn signal from one interface to
ODUCn signal from one interface to another. As in the one-hop case, another. As in the one-hop case, multi-hop TE links advertise the
Multiple-hop TE-links advertise the ODU switching capability. ODU switching capability.
+--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+ +---------+
| OTN | | OTN | | OTN | | OTN | | OTN | | OTN | | OTN | | OTN |
| Switch |<------->| regen |<-------->| regen |<------->| Switch | | Switch |<------->| Regen |<-------->| Regen |<------->| Switch |
| A | OTUCn | B | OTUCn | C | OTUCn | D | | A | OTUCn | B | OTUCn | C | OTUCn | D |
+--------+ Link +--------+ Link +--------+ Link +---------+ +--------+ Link +--------+ Link +--------+ Link +---------+
|<-------------------- ODUCn Link -------------------->| |<-------------------- ODUCn Link -------------------->|
|<---------------------- TE-Link --------------------->| |<---------------------- TE Link --------------------->|
Figure 5: Multiple-hop ODUCn TE-Link Figure 5: Multi-Hop ODUCn TE Link
The two endpoints of a TE-Link are configured with the supported The two endpoints of a TE link are configured with the supported
resource information, which may include whether the TE-Link is resource information (which may include whether the TE link is
supported by an ODUCn or an ODUk or an OTUk, as well as the link supported by an ODUCn, ODUk, or OTUk), as well as the link attribute
attribute information (e.g., slot granularity, list of available information (e.g., slot granularity and list of available tributary
tributary slot). slot).
4.2. Implications and Applicability for GMPLS Signalling 4.2. GMPLS Signaling
Once the ODUCn TE-Link is configured, the GMPLS mechanisms defined in Once the ODUCn TE link is configured, the GMPLS mechanisms defined in
[RFC7139] can be reused to set up ODUk/ODUflex LSPs with no changes. [RFC7139] can be reused to set up ODUk/ODUflex LSPs with no changes.
As the resource on the ODUCn link which can be seen by the client As the resource on the ODUCn link that can be seen by the ODUk/
ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in ODUflex client signal is a set of 5 Gbit/s slots, the label defined
[RFC7139] is able to accommodate the requirement of the setup of in [RFC7139] is able to accommodate the requirement of the setup of
ODUk/ODUflex over ODUCn link. In [RFC7139], the OTN-TDM an ODUk/ODUflex client signal over an ODUCn link. In [RFC7139], the
GENERALIZED_LABEL object is used to indicate how the lower order (LO) OTN-TDM GENERALIZED_LABEL object is used to indicate how the lower-
ODUj signal is multiplexed into the higher order (HO) ODUk link. In order (LO) ODUj signal is multiplexed into the higher-order (HO) ODUk
a similar manner, the OTN-TDM GENERALIZED_LABEL object is used to link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object is
indicate how the ODUk signal is multiplexed into the ODUCn link. The used to indicate how the ODUk signal is multiplexed into the ODUCn
ODUk Signal Type is indicated by Traffic Parameters. The IF_ID link. The ODUk signal type is indicated by Traffic Parameters. The
RSVP_HOP object provides a pointer to the interface associated with IF_ID RSVP_HOP object provides a pointer to the interface associated
TE-Link and therefore the two nodes terminating the TE-link know (by with TE link; therefore, the two nodes terminating the TE link know
internal/local configuration) the attributes of the ODUCn TE Link. (by internal/local configuration) the attributes of the ODUCn TE
Link.
Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14 The TPN defined in [ITU-T_G709_2020] (where it is referred to as
bits, while this field in [RFC7139] only has 12 bits, some extension "tributary port #") for an ODUCn link has 14 bits while this field in
work will eventually be needed. Given that a 12-bit TPN field can [RFC7139] only has 12 bits, so some extension work will eventually be
support ODUCn links with up to n=400 (i.e. 40Tbit/s links), this need needed. Given that a 12-bit TPN field can support ODUCn links with
is not urgent. up to n=400 (i.e., 40 Tbit/s links), this need is not urgent.
An example is given in Figure 6 to illustrate the label format The example in Figure 6 illustrates the label format defined in
defined in [RFC7139] for multiplexing ODU4 onto ODUC10. One ODUC10 [RFC7139] for multiplexing ODU4 onto ODUC10. One ODUC10 has 200
has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4. slots (each 5 Gbit/s), and twenty of them are allocated to the ODU4.
With this label encoding, only 20 out of the 200 bits mask are non- With this label encoding, only 20 out of the 200 bits mask are non-
zero, and is very inefficient. The inefficiency grows for larger zero, which is very inefficient. The inefficiency grows for larger
values of "n" and an optimized label format may be desirable. values of "n", and an optimized label format may be desirable.
0 1 2 3 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 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 = 3 | Reserved | Length = 200 | | TPN = 3 | Reserved | Length = 200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0| |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0| |0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 32 skipping to change at line 522
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0| |0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0| |0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0| |0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Padding Bits(0) | |0 0 0 0 0 0 0 0| Padding Bits(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Label format Figure 6: Label Format
4.3. Implications and Applicability for GMPLS Routing
For routing, it is deemed that no extension to current mechanisms
defined in [RFC7138] is needed. Because, once an ODUCn link is up,
the resources that need to be advertised are the resources that are
exposed by this ODUCn link and the multiplexing hierarchy on this
link. Since the ODUCn link is the lowest layer of the ODU
multiplexing hierarchy involving multiple ODU layers, and there is a
1:1 correspondence with the OTUCn signal, there is no need to
explicitly define a new value to represent the ODUCn signal type in
the OSPF-TE routing protocol.
The OSPF-TE extension defined in section 4 of [RFC7138] can be reused
to advertise the resource information on the ODUCn link to help
finish the setup of ODUk/ODUflex.
5. Authors (Full List)
Qilei Wang (editor)
ZTE
Nanjing, China
Email: wang.qilei@zte.com.cn
Radha Valiveti (editor)
Infinera Corp
Sunnyvale, CA, USA
Email: rvaliveti@infinera.com
Haomian Zheng (editor)
Huawei
CN
EMail: zhenghaomian@huawei.com
Huub van Helvoort
Hai Gaoming B.V
EMail: huubatwork@gmail.com
Sergio Belotti
Nokia
EMail: sergio.belotti@nokia.com
6. Contributors
Iftekhar Hussain, Infinera Corp, Sunnyvale, CA, USA,
IHussain@infinera.com
Daniele Ceccarelli, Ericsson, daniele.ceccarelli@ericsson.com
Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com
Fatai Zhang, Huawei,zhangfatai@huawei.com
Italo Busi, Huawei,italo.busi@huawei.com
Dieter Beller, Nokia, Dieter.Beller@nokia.com
Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn
Zafar Ali, Cisco Systems, zali@cisco.com
Daniel King, d.king@lancaster.ac.uk 4.3. GMPLS Routing
Manoj Kumar, Cisco Systems, manojk2@cisco.com For routing, it is deemed that no extension to the current mechanisms
defined in [RFC7138] is needed.
Antonello Bonfanti, Cisco Systems, abonfant@cisco.com The ODUCn link, which is the lowest layer of the ODU multiplexing
hierarchy involving multiple ODU layers, is assumed to have been
already configured when GMPLS is used to set up ODUk over ODUCn;
therefore, the resources that need to be advertised are the resources
that are exposed by this ODUCn link and the ODUk multiplexing
hierarchy on it. The 5 Gbit/s OPUCn time slots do not need to be
advertised, while the 1.25 Gbit/s and 2.5 Gbit/s OPUk time slots need
to be advertised using the mechanisms already defined in [RFC7138].
Yuji Tochio, Fujitsu, tochio@fujitsu.com Since there is a 1:1 correspondence between the ODUCn and the OTUCn
signal, there is no need to explicitly define a new value to
represent the ODUCn signal type in the OSPF-TE routing protocol.
7. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
8. Security Considerations 6. Security Considerations
This document analyzed the applicability of protocol extensions in This document analyzes the applicability of protocol extensions in
[RFC7138] and [RFC7139] for use in the 2020 version of G.709 [ITU- [RFC7138] and [RFC7139] for use in the 2020 version of ITU-T
T_G709_2020] and found that no new extensions are needed. Therefore, Recommendation G.709 [ITU-T_G709_2020] and finds that no new
this document introduced no new security considerations to the extensions are needed. Therefore, this document introduces no new
existing signaling and routing protocols beyond those already security considerations to the existing signaling and routing
described in [RFC7138] and [RFC7139]. Please refer to [RFC7138] and protocols beyond those already described in [RFC7138] and [RFC7139].
[RFC7139] for further details of the specific security measures. Please refer to [RFC7138] and [RFC7139] for further details of the
Additionally, [RFC5920] addresses the security aspects that are specific security measures. Additionally, [RFC5920] addresses the
relevant in the context of GMPLS. security aspects that are relevant in the context of GMPLS.
9. References 7. References
9.1. Normative References 7.1. Normative References
[ITU-T_G709_2020] [ITU-T_G709_2020]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; ITU-T, "Interfaces for the optical transport network",
06/2020", June 2020. ITU-T Recommendation G.709, June 2020.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and [RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014, Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>. <https://www.rfc-editor.org/info/rfc7138>.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., [RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139, of Evolving G.709 Optical Transport Networks", RFC 7139,
DOI 10.17487/RFC7139, March 2014, DOI 10.17487/RFC7139, March 2014,
<https://www.rfc-editor.org/info/rfc7139>. <https://www.rfc-editor.org/info/rfc7139>.
9.2. Informative References 7.2. Informative References
[ITU-T_G709.1] [ITU-T_G709.1]
ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; ITU-T, "Flexible OTN short-reach interfaces", ITU-T
2018", 2018. Recommendation G.709.1, June 2018.
[ITU-T_G709_2012] [ITU-T_G709_2012]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; ITU-T, "Interfaces for the optical transport network",
02/2012", February 2012. ITU-T Recommendation G.709, February 2012.
[ITU-T_G709_2016] [ITU-T_G709_2016]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; ITU-T, "Interfaces for the optical transport network",
07/2016", July 2016. ITU-T Recommendation G.709, June 2016.
[ITU-T_G872] [ITU-T_G872]
ITU-T, "ITU-T G.872: Architecture of Optical Transport ITU-T, "Architecture of optical transport networks", ITU-T
Networks; 12/2019", December 2019. Recommendation G.872, December 2019.
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. [RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Ceccarelli, "Framework for GMPLS and PCE Control of G.709
Optical Transport Networks", RFC 7062, Optical Transport Networks", RFC 7062,
DOI 10.17487/RFC7062, November 2013, DOI 10.17487/RFC7062, November 2013,
<https://www.rfc-editor.org/info/rfc7062>. <https://www.rfc-editor.org/info/rfc7062>.
[RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed., [RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed.,
Caviglia, D., Zhang, F., and D. Li, "Evaluation of Caviglia, D., Zhang, F., and D. Li, "Evaluation of
Existing GMPLS Encoding against G.709v3 Optical Transport Existing GMPLS Encoding against G.709v3 Optical Transport
Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, January Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, January
2014, <https://www.rfc-editor.org/info/rfc7096>. 2014, <https://www.rfc-editor.org/info/rfc7096>.
Appendix A. Possible Future Work Appendix A. Possible Future Work
As noted in Section Section 4.2, the GMPLS TPN field in Section 6.1 As noted in Section 4.2, the GMPLS TPN field defined in Section 6.1
of [RFC7139] is only 12 bits whereas an ODUCn link could require up of [RFC7139] is only 12 bits, whereas an ODUCn link could require up
to 14 bits. Although the need is not urgent, future work could to 14 bits. Although the need is not urgent, future work could
extend the TPN field in GMPLS to use the Reserved bits immediately extend the TPN field in GMPLS to use the Reserved bits immediately
adjacent. This would need to be done in a backward compatible way. adjacent. This would need to be done in a backward-compatible way.
Section Section 4.2 further notes that the current encoding of GMPLS Section 4.2 further notes that the current encoding of GMPLS labels
labels can be inefficient for larger values of n in ODUCn. Future can be inefficient for larger values of n in ODUCn. Future work
work might examine a more compact, yet generalized label encoding to might examine a more compact, yet generalized, label encoding to
address this issue should it be felt, after analysis of the address this issue should it be felt, after analysis of the
operational aspects, that the current encoding is causing problems. operational aspects, that the current encoding is causing problems.
Introduction of a new label encoding would need to be done using a Introduction of a new label encoding would need to be done using a
new LSP Encoding Type / G-PID pairing to ensure correct new pairing of LSP encoding type and Generalized Payload Identifier
interoperability. (G-PID) to ensure correct interoperability.
Contributors
Iftekhar Hussain
Infinera Corp
Sunnyvale, CA
United States of America
Email: IHussain@infinera.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Rajan Rao
Infinera Corp
Sunnyvale,
United States of America
Email: rrao@infinera.com
Fatai Zhang
Huawei
Email: zhangfatai@huawei.com
Italo Busi
Huawei
Email: italo.busi@huawei.com
Dieter Beller
Nokia
Email: Dieter.Beller@nokia.com
Yuanbin Zhang
ZTE
Beijing
Email: zhang.yuanbin@zte.com.cn
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Daniel King
Email: d.king@lancaster.ac.uk
Manoj Kumar
Cisco Systems
Email: manojk2@cisco.com
Antonello Bonfanti
Cisco Systems
Email: abonfant@cisco.com
Yuji Tochio
Fujitsu
Email: tochio@fujitsu.com
Authors' Addresses Authors' Addresses
Qilei Wang (editor) Qilei Wang (editor)
ZTE Corporation ZTE Corporation
Nanjing Nanjing
China China
Email: wang.qilei@zte.com.cn Email: wang.qilei@zte.com.cn
Radha Valiveti (editor) Radha Valiveti (editor)
Infinera Corp Infinera Corp
Sunnyvale Sunnyvale, CA
USA United States of America
Email: rvaliveti@infinera.com Email: rvaliveti@infinera.com
Haomian Zheng (editor) Haomian Zheng (editor)
Huawei Huawei
China China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Huub van Helvoort Huub van Helvoort
Hai Gaoming B.V Hai Gaoming BV
Almere Almere
Netherlands Netherlands
Email: huubatwork@gmail.com Email: huubatwork@gmail.com
Sergio Belotti Sergio Belotti
Nokia Nokia
Email: sergio.belotti@nokia.com Email: sergio.belotti@nokia.com
 End of changes. 104 change blocks. 
396 lines changed or deleted 392 lines changed or added

This html diff was produced by rfcdiff 1.48.