draft-ietf-ccamp-gmpls-otn-b100g-applicability-02.txt   draft-ietf-ccamp-gmpls-otn-b100g-applicability-03.txt 
Internet Engineering Task Force Q. Wang, Ed. Internet Engineering Task Force Q. Wang, Ed.
Internet-Draft ZTE Corporation Internet-Draft ZTE Corporation
Intended status: Informational R. Valiveti, Ed. Intended status: Informational R. Valiveti, Ed.
Expires: September 7, 2020 Infinera Corp Expires: May 5, 2021 Infinera Corp
H. Zheng, Ed. H. Zheng, Ed.
Huawei Huawei
H. Helvoort H. Helvoort
Hai Gaoming B.V Hai Gaoming B.V
S. Belotti S. Belotti
Nokia Nokia
March 6, 2020 November 1, 2020
Applicability of GMPLS for B100G Optical Transport Network Applicability of GMPLS for B100G Optical Transport Network
draft-ietf-ccamp-gmpls-otn-b100g-applicability-02 draft-ietf-ccamp-gmpls-otn-b100g-applicability-03
Abstract Abstract
This document examines the applicability of using current existing This document examines the applicability of using current existing
GMPLS routing and signaling to set up ODUk/ODUflex over ODUCn link, GMPLS routing and signalling mechanisms to set up ODUk (e.g.,
as a result of the introduction of OTU/ODU links with rates larger ODUflex) LSP over ODUCn links, as defined in the 2016 version of
than 100G in the 2016 version of G.709. G.709.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2020. This Internet-Draft will expire on May 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OTN terminology used in this document . . . . . . . . . . . . 3 2. OTN terminology used in this document . . . . . . . . . . . . 3
3. Overview of B100G in G.709 . . . . . . . . . . . . . . . . . 4 3. Overview of the OTUCn/ODUCn in G.709 . . . . . . . . . . . . 3
3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. OTUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. ODUCn . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. OTUCn-M . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Time Slot Granularity . . . . . . . . . . . . . . . . . . 7
3.4. Time Slot Granularity . . . . . . . . . . . . . . . . . . 8 3.4. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 7
3.5. Structure of OPUCn MSI with Payload type 0x22 . . . . . . 8 3.5. Client Signal Mappings . . . . . . . . . . . . . . . . . 8
3.6. Client Signal Mappings . . . . . . . . . . . . . . . . . 8 4. GMPLS Implications and Applicability . . . . . . . . . . . . 9
4. Applicability and GMPLS Implications . . . . . . . . . . . . 10 4.1. TE-Link Representation . . . . . . . . . . . . . . . . . 9
4.1. Applicability and Challenges . . . . . . . . . . . . . . 10 4.2. Implications and Applicability for GMPLS Signalling . . . 10
4.2. GMPLS Implications and Applicability . . . . . . . . . . 12 4.3. Implications and Applicability for GMPLS Routing . . . . 11
4.2.1. TE-Link Representation . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Implications and Applicability for GMPLS Signalling . 13 6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Implications and Applicability for GMPLS Routing . . 14 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Authors (Full List) . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The current GMPLS routing [RFC7138] and signaling extensions The current GMPLS routing [RFC7138] and signalling [RFC7139]
[RFC7139] only supports the control of OTN signals and capabilities extensions support the control of OTN signals and capabilities that
that were defined in the 2012 version of G.709 [ITU-T_G709_2012]. were defined in the 2012 version of G.709 [ITU-T_G709_2012].
Since the publishment of the latest 2016 version of G.709
[ITU-T_G709_2016], which introduces support for new higher rate ODU
signals, termed ODUCn (which have a nominal rate of n x 100 Gbps),
how to applied GMPLS to ODUCn case should be taken into
consideration. As OTUCn and ODUCn only perform section layer role
only according to the definition in G.709 [ITU-T_G709_2016], which
means the OTUCn and ODUCn are only used to provide for the transfer
of information between two adjacent upper layer cross-connects, i.e.,
ODUk/ODUflex cross connects, it's not appropriate to apply GMPLS to
OTUCn and ODUCn. Therefore, this document mainly focuses on the use
of GMPLS mechanisms to set up ODUk/ODUflex over an existing ODUCn
link.
This document first presents an overview of the changes introduced in
[ITU-T_G709_2016] to motivate the present topic and then analyzes how
the current GMPLS routing and signalling mechanisms can be utilized
to setup ODUk/ODUflex connections over ODUCn links. In order to make
the description in this document clear, how to set up ODUCn link is
also mentioned.
1.1. Scope
For the purposes of the B100G control plane discussion, the OTN In 2016 a new version of G.709 was published: [ITU-T_G709_2016].
should be considered as a combination of ODU and OTSi layers. Note This version introduces new higher rate OTU and ODU signals, termed
that [ITU-T_G709_2016] is deprecating the use of the term "OCh" for OTUCn and ODUCn respectively, which have a nominal rate of n x 100
B100G entities, and leaving it intact only for maintaining continuity Gbit/s. According to the definition in G.709 [ITU-T_G709_2016],
in the description of the signals with bandwidth upto 100G. OTUCn and ODUCn perform only section layer role and ODUCn supports
only ODUk clients. This document focuses on the use of existing
GMPLS mechanisms to set up ODUk (e.g., ODUflex) LSP over ODUCn links,
independently from how these links have been set up
This document presents an overview of the OTUCn and ODUCn signals
introduced in [ITU-T_G709_2016] and analyses how the current GMPLS
routing and signalling mechanisms can be utilized to setup ODUk
(e.g., ODUflex) LSPs over ODUCn links.
This document only focuses on the control of the ODU layer. The Note: after discussion, the authors did not see any impact of 2020
control of the OTSi layer is out of scope of this document. But in version of G.709 on this draft.
order to facilitate the description of the challenges brought by
[ITU-T_G709_2016] to B100G GMPLS routing and signalling, some general
description about OTSi is included in section 4 of this document.
2. OTN terminology used in this document 2. OTN terminology used in this document
a. OPUCn: Optical Payload Unit -Cn. a. OPUCn: Optical Payload Unit - Cn. Where Cn = number of n-bit
client data entities.
b. ODUCn: Optical Data Unit - Cn. b. ODUCn: Optical Data Unit - Cn.
c. OTUCn: Fully standardized Optical Transport Unit - Cn. c. OTUCn: Fully standardized Optical Transport Unit - Cn.
d. OTUCn-M: This signal is an extension of the OTUCn signal d. OTUCn-M: This signal is an extension of the OTUCn signal
introduced above. This signal contains the same amount of introduced above. This signal contains the same amount of
overhead as the OTUCn signal, but contains a reduced amount of overhead as the OTUCn signal, but contains a reduced amount of
payload area. Specifically the payload area consists of M 5G payload area. Specifically, the payload area consists of M 5G
tributary slots (where M is strictly less than 20*n). tributary slots (where M is strictly less than 20*n).
e. PSI: OPU Payload structure Indicator. This is a multi-frame e. PSI: OPU Payload Structure Indicator. This is a 256-byte signal
message and describes the composition of the OPU signal. This that describes the composition of the OPU signal. This field is
field is a concatenation of the Payload type (PT) and the a concatenation of the Payload type (PT) and the Multiplex
Multiplex Structrure Indicator (MSI) defined below. Structure Indicator (MSI) defined below.
f. MSI: Multiplex Structure Indicator. This structure indicates the f. MSI: Multiplex Structure Indicator. This structure indicates the
grouping of the tributary slots in an OPU payload area to realize grouping of the tributary slots in an OPU payload area that
a client signal that is multiplexed into an OPU. The individual realizes a client signal which is multiplexed into an OPU. The
clients multiplexed into the OPU payload area are distinguished individual clients multiplexed into the OPU payload area are
by the Tributary Port number (TPN). distinguished by the Tributary Port number (TPN).
g. GMP: Generic Mapping Procedure.
h. OTSiG: The set of OTSi that supports a single digital client.
i. OTSiA: The OTSiG together with the non-associated overhead
(OTSiG-O).
Detailed description of these terms can be found in [ITU-T_G709_2016] Detailed description of these terms can be found in
and [ITU-T_G807]. [ITU-T_G709_2016].
3. Overview of B100G in G.709 3. Overview of the OTUCn/ODUCn in G.709
This section provides an overview of new features in This section provides an overview of OTUCn/ODUCn signals defined in
[ITU-T_G709_2016]. [ITU-T_G709_2016].
3.1. OTUCn 3.1. OTUCn
In order to carry client signals with rates greater than 100Gbps, In order to carry client signals with rates greater than 100 Gbit/s,
[ITU-T_G709_2016] takes a general and scalable approach that [ITU-T_G709_2016] 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 of
(approximately) n*100G. The following are the key characteristics of (approximately) n*100G. The following are the key characteristics of
the OTUCn signal: the OTUCn signal:
a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals a. The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals
perform digital section roles only (see perform digital section roles only (see
[ITU-T_G709_2016]:Section 6.1.1) [ITU-T_G709_2016]:Section 6.1.1)
skipping to change at page 6, line 5 skipping to change at page 5, line 25
| Inter+Domain | Intra+Domain | Intra+Domain | | Inter+Domain | Intra+Domain | Intra+Domain |
| Interface (IrDI)| Interface (IaDI)| Interface | | Interface (IrDI)| Interface (IaDI)| Interface |
| FlexO (G.709.1) | FlexO (G.709.x) | Proprietary | | FlexO (G.709.1) | FlexO (G.709.x) | Proprietary |
| | (Future) | Encap, FEC etc. | | | (Future) | Encap, FEC etc. |
+--------------------------------------------------------+ +--------------------------------------------------------+
================================================================== ==================================================================
Figure 1: OTUCn transport possibilities Figure 1: OTUCn transport possibilities
3.1.1. OTUCn-M
The standard OTUCn signal has the same rate as that of the ODUCn
signal as shown in Table 1. This implies that the OTUCn signal can
only be transported over wavelength groups which have a total
capacity of multiples of (approximately) 100G. Modern DSPs support a
variety of bit rates per wavelength, depending on the reach
requirements for the optical path. In other words, it is possible to
extend the reach of an optical path (i.e. increase the physical
distance covered) by lowering the bitrate of the digital signal that
is modulated onto the optical signals. If the total rate of the ODUk
LSPs planned to be carried over an ODUCn link is smaller than n*100G,
it is possible to "crunch" the OTUCn not to transmit some of unused
timeslots. With this in mind, ITU-T supports the notion of a reduced
rate OTUCn signal, termed the OTUCn-M. The OTUCn-M signal is derived
from the OTUCn signal by retaining all the n instances of overhead
(one per OTUC slice) but with only M (M is less than 20*n) OPUCn
tributary slots available to carry ODUk LSPs.
As the "crunching" algorithm is not standardized, knowing the value
of M is not enough to decide the timeslot availability.
3.2. ODUCn 3.2. ODUCn
The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by The ODUCn signal [ITU-T_G709_2016] can be viewed as being formed by
the appropriate interleaving of content from n ODUC signal instances. the appropriate interleaving of content from n ODUC signal instances.
The ODUC frames have the same structure as a standard ODU -- in the The ODUC frames have the same structure as a standard ODU -- in the
sense that it has the same Overhead area, and the payload area -- but sense that it has the same Overhead area, and the payload area -- but
has a higher rate since its payload area can embed an ODU4 signal. has a higher rate since its payload area can embed an ODU4 signal.
The ODUCn signals have a rate that is captured in Table 1. The ODUCn signals have a rate that is captured in Table 1.
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| ODU Type | ODU Bit Rate | | ODU Type | ODU Bit Rate |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
| ODUCn | n x 239/226 x 99,532,800 kbit/s = n x 105,258,138.053 | | ODUCn | n x 239/226 x 99,532,800 Kbit/s = n x 105,258,138.053 |
| | kbit/s | | | Kbit/s |
+----------+--------------------------------------------------------+ +----------+--------------------------------------------------------+
Table 1: ODUCn rates Table 1: ODUCn rates
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 co-terminated, i.e.
they will have identical source/sink locations. [ITU-T_G709_2016] they will have identical source/sink locations. [ITU-T_G709_2016]
and [ITU-T_G872] allow for the ODUCn signal to pass through a digital allows for the ODUCn signal to pass through a digital regenerator
regenerator node which will terminate the OTUCn layer, but will pass node which will terminate the OTUCn layer, but will pass the
the regenerated (but otherwise untouched) ODUCn towards a different regenerated (but otherwise untouched) ODUCn towards a different OTUCn
OTUCn interface where a fresh OTUCn layer will be initiated (see interface where a fresh OTUCn layer will be initiated (see Figure 2).
Figure 2). In this case, the ODUCn is carried by 3 OTUCn segments. In this case, the ODUCn is carried by 3 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, trib-slot unchanged. That is, the set of client signals, their TPNs, trib-slot
allocation remains unchanged. The ODUCn Overhead might be modified allocation remains unchanged. The ODUCn Overhead might be modified
if TCM sub-layers are instantiated in order to monitor the if TCM sub-layers are instantiated in order to monitor the
performance of the regenerator hops. In this sense, the ODUCn should performance of the regenerator hops. In this sense, the ODUCn should
NOT be seen as a general ODU which can be switched via an ODUk cross- NOT be seen as a general ODU which can be switched via an ODUk cross-
connect. connect.
================================================================== ==================================================================
skipping to change at page 7, line 30 skipping to change at page 7, line 30
| | | 3R | | 3R | | | | | | 3R | | 3R | | |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
<-------------------------ODUCn--------------------------> <-------------------------ODUCn-------------------------->
<---------------> <---------------> <------------------> <---------------> <---------------> <------------------>
OTUCn OTUCn OTUCn OTUCn OTUCn OTUCn
================================================================== ==================================================================
Figure 2: ODUCn signal Figure 2: ODUCn signal
3.3. OTUCn-M 3.3. Time Slot Granularity
The standard OTUCn signal has the same rate as that of the ODUCn
signal as captured in Table 1. This implies that the OTUCn signal
can only be transported over wavelength groups which have a total
capacity of multiples of (approximately) 100G. Modern DSPs support a
variety of bit rates per wavelength, depending on the reach
requirements for the optical link. In other words, it is possible to
extend the reach of an optical link (i.e. increase the physical
distance covered) by lowering the bitrate of the client signal that
is modulated onto the optical signals. By the very nature of the
OTUCn signal, it is constrained to rates which are multiples of
(approximately) 100G. If it happens that the total rate of the LO-
ODUs carried over the ODUCn is smaller than n X 100G, it is possible
to "crunch" the OTUCn to remove the unused capacity. With this in
mind, ITU-T supports the notion of a reduced rate OTUCn signal,
termed the OTUCn-M. The OTUCn-M signal is derived from the OTUCn
signal by retaining all the n instances of overhead (one per OTUC
slice) but only M tributary slots of capacity.
3.4. Time Slot Granularity
[ITU-T_G709_2012] introduced the support for 1.25G granular tributary [ITU-T_G709_2012] has introduced the support for 1.25G granular
slots in OPU2, OPU3, and OPU4 signals. With the introduction of tributary slots in OPU2, OPU3, and OPU4 signals. With the
higher rate signals, it is not practical for the optical networks introduction of higher rate signals, it is not practical for the
(and the data plane hardware) to support a very large number of optical networks (and the data plane hardware) to support a very
connections at such a fine granularity. ITU-T has defined the OPUC large number of connections at such a fine granularity. [ITU-
with a tributary slot granularity of 5G. This means that the ODUCn T_G709_2012] has defined the OPUC with a 5G tributary slot
signal has 20*n tributary slots (of 5Gbps capacity). It is granularity. This means that the ODUCn signal has 20*n tributary
worthwhile considering that the range of tributary port number (TPN) slots (of 5 Gbit/s capacity). It is worthwhile considering that the
is 10*n instead of 20*n, which restricts the maximum client signals range of tributary port number (TPN) is 10*n instead of 20*n, which
that could be carried over one single ODUC1. restricts the maximum client signals that could be carried over one
single ODUC1.
3.5. 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 5G tributary slots. As mentioned above, the OPUCn signal has 20*n 5G tributary slots.
The OPUCn contains n PSI structures, one per OPUC instance. The PSI The OPUCn MSI field has a fixed length of 40*n bytes and indicates
structure consists of the Payload Type (of 0x22), followed by a the availability and occupation of each TS. Two bytes are used for
Reserved Field (1 byte) and the MSI. The OPUCn MSI field has a fixed each of the 20*n tributary slots, and each such information structure
length of 40*n bytes and indicates the availability of each TS. Two has the following format ([ITU-T_G709_2016] G.709:Section 20.4.1):
bytes are used for each of the 20*n tributary slots, and each such
information structure has the following format ([ITU-T_G709_2016]
G.709:Section 20.4.1):
a. The TS availability bit indicates if the tributary slot is a. The TS availability bit indicates if the tributary slot is
available or unavailable available or unavailable
b. The TS occupation bit indicates if the tributary slot is b. The TS occupation bit indicates if the tributary slot is
allocated or unallocated allocated or unallocated
c. The tributary port bits indicates the port number of the client c. The tributary port number (14 bits) of the client signal that is
signal that is being carried in this specific TS. A flexible being carried in this specific TS. A flexible assignment of
assignment of tributary port to tributary slots is possible. tributary port to tributary slots is possible. Numbering of
Numbering of tributary ports is from 1 to 10n. tributary ports is from 1 to 10*n.
3.6. 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:
a. All client signals with rates less than 100G are mapped into ODU a. All client signals are mapped into an ODUk (e.g., ODUflex) as
container as specified in clause 17 of [ITU-T_G709_2016]. These specified in clause 17 of [ITU-T_G709_2016].
mappings are identical to those specified in the earlier revision
of G.709 [ITU-T_G709_2012]. For example, the 1000BASE-
X/10GBASE-R signals are mapped to ODU0/ODU2e respectively (see
Table 2 -- based on Table 7-2 in [ITU-T_G709_2016])
b. New emerging client signals are usually mapped into ODUflex
signals of the appropriate rates (see Table 2 according to the
Table 7-2 in [ITU-T_G709_2016])
c. ODU Virtual Concatenation is not supported any more. This b. ODU Virtual Concatenation has been deprecated. This simplifies
simplifies the network, and the supporting hardware since the network, and the supporting hardware since multiple different
multiple different mappings for the same client are no longer mappings for the same client are no longer necessary. Note that
necessary. Note that legacy implementations that transported legacy implementations that transported sub-100G clients using
sub-100G clients using ODU VCAT shall continue to be supported. ODU VCAT shall continue to be supported.
d. ODUflex signals are low-order signals only. If the ODUflex c. 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 100G or less, they can be transported over
either an ODUk (k=1..4) or an ODUCn. For ODUflex connections either an ODUk (k=1..4) or an ODUCn. For ODUflex connections
with rates greater than 100G, ODUCn is required. with rates greater than 100G, ODUCn is required.
+----------------+--------------------------------------------------+
| ODU Type | ODU Bit Rate |
+----------------+--------------------------------------------------+
| ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 Kbps |
| ODU2e | 239/237 x 10,312,500 Kbps |
| ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 Kbps |
| ODUflex for | 239/238 x Client signal Bit rate |
| CBR client | |
| signals | |
| ODUflex for | Configured bit rate |
| GFP-F mapped | |
| packet traffic | |
| ODUflex for | s x 239/238 x 5 156 250 kbit/s: s=2,8,5*n, n >= |
| IMP mapped | 1 |
| packet traffic | |
| ODUflex for | 103 125 000 x 240/238 x n/20 kbit/s, where n is |
| FlexE aware | total number of available tributary slots among |
| transport | all PHYs which have been crunched and combined. |
+----------------+--------------------------------------------------+
Note that this table doesn't include ODUCn -- since it cannot be
generated by mapping a non-OTN signal. An ODUCn is always formed by
multiplexing multiple LO-ODUs.
Table 2: Types and rates of ODUs usable for client mappings
================================================================== ==================================================================
Clients (e.g. SONET/SDH, Ethernet) Clients (e.g. SONET/SDH, Ethernet)
+ + + + + +
| | | | | |
+------------------+-------+------+------------------------+ +------------------+-------+------+------------------------+
| OPUk | | OPUk |
+----------------------------------------------------------+ +----------------------------------------------------------+
| ODUk | | ODUk |
+-----------------------+---------------------------+------+ +-----------------------+---------------------------+------+
skipping to change at page 10, line 30 skipping to change at page 9, line 30
+----------+-----------------------+ +----------+-----------------------+
| OTLk.n | | ODUCn | | OTLk.n | | ODUCn |
+----------+ +------------+ +----------+ +------------+
| OTUCn | | OTUCn |
+------------+ +------------+
================================================================== ==================================================================
Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1) Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1)
4. Applicability and GMPLS Implications 4. GMPLS Implications and Applicability
4.1. Applicability and Challenges
This section analyzes the OTUCn deployment scenarios to identify
potential extensions to GMPLS that would be needed. When OTUCn links
are established between line ports of two different network elements,
two scenarios are possible. These scenarios are modeled according to
those illustrated in Appendix XIII of [ITU-T_G709_2016]. Note that
while this Appendix illustrates OTUCn subrating possibilities, the
scenarios serve a more general purpose also. Two possible
realization of OTUCn realizations between nodes are:
a. The first scenario (see Figure 4) deploys OTUCn/OTUCn-M between
two line ports connecting two L1/L0 ODU cross connects (XC)
within one optical transport network. As defined in
[ITU-T_G807], the OTUCn/OTUCn-M signal is transported using by
one OTSiG, which could be comprised of one or more OTSi. The
OTSiG may have non-associated overhead (denoted as OTSiG-O); the
combination of the OTSiG and OTSiG-O is represented by the OTSiA
management/control abstraction. There is a 1:1 mapping
relationship between OTUCn and OTSiG or OTSiA. For example, a
400G OTUC4 signal can be carried over a single OTSi signal with a
400G capcity, or perhaps split into 4 100G digital information
streams each of which is carried over a OTSi signal with a 100G
capacity. In this scenario, it is clear that the OTUCn and ODUCn
link can be automatically established, after/together with the
setup of OTSiG or OTSiA, as both OTUCn and ODUCn perform section
layer only. Once the ODUCn link is automatically established, it
can be advertized as a TE-link and used for setting up ODUk/
ODUflex connections.
b. The second scenario (see depicted in Figure 5) deploys OTUCn/
OTUCn-M between transponders which are in a different domain B,
and are separated from the L1 ODU XCs in domain A and/or C. In
this scenario, the end-to-end ODUCn is actually supported by
three different OTUCn or OTUCn-M segments, which are in turn
carried by their respective OTSi(G) or OTSiA. In this example,
the OTUCn links will be established automatically after/together
with the setup of OTSi(G) or OTSiA. Note that until both
transponder nodes in domain B have been configured, the ODUCn
signal transmitted by node A doesn't reach node C. Until all the
required configuration operations are completed, the ODUCn.STAT
field will reflect the AIS (i.e. error) status. Once all the
provisioning has been performed in domain B, and the links
connecting the edge nodes to transponders in domain B are error
free, the end to end ODUCn flows will be established. In this
case, the receipt of a normal value for the ODUCn.STAT field can
trigger the creation of the ODUCn link.
==================================================================
+--------+ +--------+
| +---------------------+ |
| OTN |---------------------| OTN |
| XC +---------------------+ XC |
| | | |
+--------+ +--------+
<---------- ODUk/ODUflex ----------->
<------------ ODUCn -------------->
<------- OTUCn/OTUCn-M --------->
<--------OTSi(G)/OTSiA--------->
==================================================================
Figure 4: Scenario A
==================================================================
+----------------------------+
A | B | A or C
| | | |
+--------+ | +--------+ +--------+ | +--------+
| +----------|-+ | | +-|--------+ |
| OTN |----------|-| Transp | | Transp |-|--------| OTN |
| XC +----------|-+ onder +------+ onder +-|--------+ XC |
| | | | | | | | | |
+--------+ | +--------+ +--------+ | +--------+
| |
+----------------------------+
<------------------------ODUk/ODUflex----------------------->
<------------------------ ODUCn -------------------------->
<------OTUCn------><---OTUCn/OTUCn-M---><------OTUCn------>
<-OTSi(G)/OTSiA-> <--OTSi(G)/OTSiA--> <-OTSi(G)/OTSiA->
==================================================================
Figure 5: Scenario B
4.2. GMPLS Implications and Applicability
4.2.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 with
TE-Links in GMPLS. Similar to that, ODUCn links can also be TE-Links in GMPLS. Similar to that, ODUCn links can also be
represented as TE-Links, which can be seen in the figure below. represented as TE-Links, which can be seen in the figure below.
================================================================== ==================================================================
+-----+ +-----+ +-----+ +-----+
| | | | | | | |
| A |<-OTUCn Link->| B | | A |<-OTUCn Link->| B |
skipping to change at page 13, line 26 skipping to change at page 10, line 26
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | |
| A |<-OTUCn Link->| B |<-OTUCn Link->| C |<-OTUCn Link->| D | | A |<-OTUCn Link->| B |<-OTUCn Link->| C |<-OTUCn Link->| D |
| | | | | | | | | | | | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|<----------------------- ODUCn Link ------------------------>| |<----------------------- ODUCn Link ------------------------>|
|<------------------------ TE-Link -------------------------->| |<------------------------ TE-Link -------------------------->|
================================================================== ==================================================================
Figure 6: ODUCn TE-Links Figure 4: ODUCn TE-Links
Two endpoints of a TE-Link are configured with the supported resource Two endpoints of a TE-Link are configured with the supported resource
information, which may include whether the TE-Link is supported by an information, which may include whether the TE-Link is supported by an
ODUCn or an ODUk or an OTUk, as well as the link attribute ODUCn or an ODUk or an OTUk, as well as the link attribute
information (e.g., slot granularity, number of tributary slot information (e.g., slot granularity, list of available tributary
available). slot).
4.2.2. Implications and Applicability for GMPLS Signalling 4.2. Implications and Applicability for GMPLS Signalling
Once the ODUCn 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 LSP with no/few changes. RFC7139 can be reused to set up ODUk/ODUflex LSP with no/few changes.
As the resource on the ODUCn link which can be seen by the client As the resource on the ODUCn link which can be seen by the client
ODUk/ODUflex is a set of 5G slots, the label defined in RFC7139 is ODUk/ODUflex is a set of 5G slots, the label defined in RFC7139 is
able to accommodate the requirement of the setup of ODUk/ODUflex over able to accommodate the requirement of the setup of ODUk/ODUflex over
ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is
used to indicate how the LO ODUj signal is multiplexed into the HO used to indicate how the LO ODUj signal is multiplexed into the HO
ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object
is used to indicate how the ODUk signal is multiplexed into the ODUCn is used to indicate how the ODUk signal is multiplexed into the ODUCn
link. The ODUk Signal Type is indicated by Traffic Parameters. The link. The ODUk Signal Type is indicated by Traffic Parameters. The
IF_ID RSVP_HOP object provides a pointer to the interface associated IF_ID RSVP_HOP object provides a pointer to the interface associated
with TE-Link and therefore the two nodes terminating the TE-link know with TE-Link and therefore the two nodes terminating the TE-link know
(by internal/local configuration) the attributes of the ODUCn TE (by internal/local configuration) the attributes of the ODUCn TE
Link. Link.
One thing should be note is the TPN used in RFC7139 and defined in One thing should be note is the TPN used in RFC7139 and defined in
G.709-2016 for ODUCn link. Since the TPN currently defined in G.709 G.709-2016 for ODUCn link. Since the TPN currently defined in G.709
for ODUCn link has 14 bits, while this field in RFC7139 only has 12 for ODUCn link has 14 bits, while this field in RFC7139 only has 12
bits, some extension work is needed, but this is not so urgent since bits, some extension work is needed, but this is not so urgent since
for today networks scenarios 12 bits are enough, as it can support a for today networks scenarios 12 bits are enough, as it can support a
single ODUCn link up to n=400, namely 40Tbit. single ODUCn link up to n=400, namely 40 Tbit/s.
An example is given below to illustrate the label format defined in An example is given below to illustrate the label format defined in
RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G RFC7139 for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5G
slots, and twenty of them are allocated to the ODU4. Along with the slots, and twenty of them are allocated to the ODU4. Along with the
increase of "n", the label may become lengthy, an optimized label increase of "n", the label may become lengthy, an optimized label
format may be needed. format may be needed.
================================================================== ==================================================================
0 1 2 3 0 1 2 3
skipping to change at page 14, line 42 skipping to change at page 11, line 42
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 7: Label format Figure 5: Label format
4.2.3. Implications and Applicability for GMPLS Routing 4.3. Implications and Applicability for GMPLS Routing
For routing, it is deemed that no extension to current mechanisms For routing, it is deemed that no extension to current mechanisms
defined in RFC7138 are needed. Because, once an ODUCn link is up, defined in RFC7138 are needed. Because, once an ODUCn link is up,
the resources that need to be advertised are the resources that the resources that need to be advertised are the resources that
exposed by this ODUCn link and the multiplexing hierarchy on this exposed by this ODUCn link and the multiplexing hierarchy on this
link. Since the ODUCn link is the ultimate hierarchy of the ODU link. Since the ODUCn link is the ultimate hierarchy of the ODU
multiplexing, there is no need to explicitly define a new value to multiplexing, there is no need to explicitly define a new value to
represent the ODUCn signal type in the OSPF-TE routing protocol. represent the ODUCn signal type in the OSPF-TE routing protocol.
The OSPF-TE extension defined in section 4 of RFC7138 can be reused The OSPF-TE extension defined in section 4 of RFC7138 can be reused
skipping to change at page 16, line 34 skipping to change at page 13, line 34
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
7. Contributors 7. Contributors
Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com Rajan Rao, Infinera Corp, Sunnyvale, USA, rrao@infinera.com
Fatai Zhang, Huawei,zhangfatai@huawei.com Fatai Zhang, Huawei,zhangfatai@huawei.com
Italo Busi, Huawei,italo.busi@huawei.com Italo Busi, Huawei,italo.busi@huawei.com
Zheyu Fan, Individual, zheyu2008@gmail.com
Dieter Beller, Nokia, Dieter.Beller@nokia.com Dieter Beller, Nokia, Dieter.Beller@nokia.com
Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn Yuanbin Zhang, ZTE, Beiing, zhang.yuanbin@zte.com.cn
Zafar Ali, Cisco Systems, zali@cisco.com Zafar Ali, Cisco Systems, zali@cisco.com
Daniel King, d.king@lancaster.ac.uk Daniel King, d.king@lancaster.ac.uk
Manoj Kumar, Cisco Systems, manojk2@cisco.com Manoj Kumar, Cisco Systems, manojk2@cisco.com
Antonello Bonfanti, Cisco Systems, abonfant@cisco.com
Akshaya Nadahalli, Individual, nadahalli@gmail.com Antonello Bonfanti, Cisco Systems, abonfant@cisco.com
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
None. None.
10. Normative References 10. References
[ITU-T_G709.1] 10.1. Normative References
ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
2016", , 2016.
[ITU-T_G709_2012] [ITU-T_G709_2012]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
02/2012", http://www.itu.int/rec/T-REC- 02/2012", http://www.itu.int/rec/T-REC-
G..709-201202-S/en, February 2012. G..709-201202-S/en, February 2012.
[ITU-T_G709_2016] [ITU-T_G709_2016]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; ITU-T, "ITU-T G.709: Optical Transport Network Interfaces;
07/2016", http://www.itu.int/rec/T-REC- 07/2016", http://www.itu.int/rec/T-REC-
G..709-201606-P/en, July 2016. G..709-201606-P/en, July 2016.
[ITU-T_G807]
ITU-T, "ITU-T G.807: Generic functional architecture of
the optical media network;
2020", http://www.itu.int/rec/T-REC-G.872/en, February
2020.
[ITU-T_G872]
ITU-T, "ITU-T G.872: The Architecture of Optical Transport
Networks; 2017", http://www.itu.int/rec/T-REC-G.872/en,
January 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 10.2. Informative References
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. [ITU-T_G709.1]
ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface;
2016", , 2016.
Authors' Addresses Authors' Addresses
Qilei Wang (editor) Qilei Wang (editor)
ZTE Corporation ZTE Corporation
Nanjing Nanjing
CN 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
USA USA
Email: rvaliveti@infinera.com Email: rvaliveti@infinera.com
Haomian Zheng (editor) Haomian Zheng (editor)
Huawei Huawei
CN China
Email: zhenghaomian@huawei.com Email: zhenghaomian@huawei.com
Huub van Helvoort Huub van Helvoort
Hai Gaoming B.V Hai Gaoming B.V
Almere
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. 53 change blocks. 
310 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/