Internet-Draft B100G Extensions October 2022
Wang, et al. Expires 23 April 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-ietf-ccamp-gmpls-otn-b100g-applicability-14
Published:
Intended Status:
Informational
Expires:
Authors:
Q. Wang, Ed.
ZTE Corporation
R. Valiveti, Ed.
Infinera Corp
H. Zheng, Ed.
Huawei
H. Helvoort
Hai Gaoming B.V
S. Belotti
Nokia

Applicability of GMPLS for Beyond 100G Optical Transport Network

Abstract

This document examines the applicability of using existing GMPLS routing and signalling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of G.709.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 23 April 2023.

▲

Table of Contents

1. Introduction

The current GMPLS routing [RFC7138] and signalling [RFC7139] extensions support the control of Optical Transport Network (OTN) signals and capabilities that were defined in the 2012 version of G.709 [ITU-T_G709_2012].

In 2016 a further version of G.709 was published: [ITU-T_G709_2016]. This version introduced higher rate Optical Transport Unit (OTU) and Optical Data Unit (ODU) signals, termed OTUCn and ODUCn respectively, which have a nominal rate of n x 100 Gbit/s. According to the definition in [ITU-T_G709_2016], OTUCn and ODUCn perform only the digital 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) Label Switched Paths (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 OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts with [ITU-T_G709_2020] by first presenting an overview of the OTUCn and ODUCn signals, and then analyzing how the current GMPLS routing and signalling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links.

This document assumes that the reader is familiar with OTN, GMPLS, and how GMPLS is applied in OTN networks. As such, this document doesn't provide any background pertaining to OTN networks that included links with capacities of 100G or less; this background could be found in documents such as [RFC7062] and [RFC7096]. This document provides an overview of the dataplane primitives that enable links with capacities greater than 100G, and analyses the extensions that would be required in the current GMPLS routing & signaling mechanisms to support the evolution in OTN networks.

2. OTN terminology used in this document

Detailed descriptions of these terms can be found in [ITU-T_G709_2020].

3. Overview of the OTUCn/ODUCn in G.709

This section provides an overview of OTUCn/ODUCn signals defined 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 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 definitive.

3.1. OTUCn

In order to carry client signals with rates greater than 100 Gbit/s, [ITU-T_G709_2020] takes a general and scalable approach that 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 (approximately) n*100G. The following are the key characteristics of the OTUCn signal:

  • The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals perform digital section roles only (see [ITU-T_G709_2020]:Section 6.1.1)
  • The OTUCn signals can be viewed as being formed by interleaving n synchronous OTUC signals (which are labeled 1, 2, ..., n).
  • Each of the OTUC instances has the same overhead as the standard OTUk signal in [ITU-T_G709_2020]. Note that the OTUC signal doesn't include the FEC columns illustrated in [ITU-T_G709_2020]:Figure 11-1. The OTUC signal includes an ODUC.
  • The OTUC signal has a slightly higher rate compared to the OTU4 signal (without FEC); this is to ensure that the OPUC payload area can carry an ODU4 signal.
  • The combined signal OTUCn has n instances of OTUC overhead, and n instances of ODUC overhead.

The OTUCn, ODUCn and OPUCn signal structures are presented in a (physical) interface independent manner, by means of n OTUC, ODUC and OPUC instances that are marked #1 to #n.

OTUCn interfaces can be categorized as follows, based on the type of peer network element:

  • inter-domain interfaces: These types of interfaces are used for connecting OTN edge nodes to (a) client equipment (e.g. routers) or (b) hand-off points from other OTN networks. ITU-T Recommendation [ITU-T_G709.1] specifies a flexible interoperable short-reach OTN interface over which an OTUCn (n >=1) is transferred, using bonded Flexible OTN information structure (FlexO) interfaces which belong to a FlexO group.
  • intra-domain interfaces: In these cases, the OTUCn is transported using a proprietary (vendor specific) encapsulation, FEC etc. It is also possible to transport OTUCn for intra-domain links using FlexO.

3.1.1. OTUCn-M

The standard OTUCn signal has the same rate as that of the ODUCn signal. This implies that the OTUCn signal can only be transported over wavelength groups which have a total capacity of multiples of (approximately) 100G. Modern optical interfaces support a variety of bit rates per wavelength, depending on the reach requirements for the optical path. 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 the unused tributary slots. 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 instance) but with only M (M is less than 20*n) OPUCn tributary slots available to carry ODUk LSPs.

3.2. ODUCn

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 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 a higher rate since its payload area can embed an ODU4 signal.

The ODUCn is a multiplex section ODU signal, and is mapped into an OTUCn signal which provides the regenerator section layer. In some scenarios, the ODUCn, and OTUCn signals will be co-terminated, i.e. they will have identical source/sink locations (see Figure 1). In this figure, the term "OTN Switch" has the same meaning as that used in [RFC7138]:Section 3. [ITU-T_G709_2020] allows for the ODUCn 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 will pass the regenerated (but otherwise untouched) ODUCn towards a different OTUCn interface where a fresh OTUCn layer will be initiated. This process is termed as "ODUCn regeneration" in [ITU-T_G872]:Section 7.1. In this example, the ODUCn is carried by 3 OTUCn segments.

Specifically, the OPUCn signal flows through these regenerators unchanged. That is, the set of client signals, their TPNs, tributary-slot allocation remains unchanged.


 +--------+           +--------+
 |        +-----------+        |
 | OTN    |-----------| OTN    |
 | Switch +-----------+ Switch |
 | A      |           |  B     |
 |        +-----------+        |
 +--------+           +--------+
     <--------ODUCn------->
      <-------OTUCn------>
Figure 1: ODUCn signal 

 +---------+        +--------+        +--------+          +--------+
 |         +--------+        |        |        +----------+        |
 | OTN     |--------| OTN    |        | OTN    |----------| OTN    |
 | Switch  +--------+ Regen  +--------+ Regen  +----------+ Switch |
 | A       |        | B      |        | C      |          | D      |
 |         +--------+        |        |        +----------+        |
 +---------+        +--------+        +--------+          +--------+

     <-------------------------ODUCn-------------------------->
      <---------------><-----------------><------------------>
           OTUCn              OTUCn               OTUCn
Figure 2: ODUCn signal - multihop

3.3. Tributary Slot Granularity

[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] 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 capacity). The range of tributary port number (TPN) is 10*n instead of 20*n, which restricts the maximum client signals that could be carried over one single ODUC1.

3.4. Structure of OPUCn MSI with Payload type 0x22

As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary slots (TSs). The OPUCn MSI field has a fixed length of 40*n bytes and indicates the availability and occupation of each TS. Two bytes are used for each of the 20*n tributary slots, and each such information structure has the following format ([ITU-T_G709_2020]:Section 20.4.1):

  • The TS availability bit indicates if the tributary slot is available or unavailable
  • The TS occupation bit indicates if the tributary slot is allocated or unallocated
  • The tributary port number (14 bits) of the client signal that is being carried in this specific TS. A flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports is from 1 to 10*n.

The concatenation of the OPUCn payload type (PT) and the MSI field is carried over the overhead byte designated as PSI in [ITU-T_G709_2020]:Figure 15-6.

3.5. Client Signal Mappings

The approach taken by the ITU-T to map non-OTN client signals to the appropriate ODU containers is as follows:

  • All client signals are mapped into an ODUj, or ODUk (e.g., ODUflex) as specified in clause 17 of [ITU-T_G709_2020].
  • The terms ODUj & ODUk are used in a multiplexing scenario, with ODUj being a low-order ODU which is multiplexed into ODUk, a high-order ODU. As Figure 3 illustrates, the ODUCn is also a high-order ODU into which other ODUs can be multiplexed; the ODUCn itself cannot be multiplexed into any higher rate ODU signal; it is defined to be a section level signal.
  • ODUflex signals are low-order signals only. If the ODUflex entities have rates of 100G or less, they can be transported over either an ODUk (k=1..4) or an ODUCn. For ODUflex connections with rates greater than 100G, ODUCn is required.
  • ODU Virtual Concatenation has been deprecated. This simplifies the network, and the supporting hardware since multiple different mappings for the same client are no longer necessary. Note that legacy implementations that transported sub-100G clients using ODU VCAT shall continue to be supported. 
          Clients (e.g. SONET/SDH, Ethernet)

    |   |   |                           |   |   |
    |   |   |                           |   |   |
    |   |   |                           |   |   |
+---+---+---+----+                      |   |   |
|      OPUj      |                      |   |   |
+----------------+                      |   |   |
|      ODUj      |                      |   |   |
+----------------+----------------------+---+---+----------+
|                                                          |
|                       OPUk                               |
+----------------------------------------------------------+
|                                                          |
|                       ODUk       k in {0,1,2,2e,3,4,flex}|
+-------------------------+-----+--------------------------+
|                         |     |                          |
| OTUk, OTUk-SC, OTUk-V   |     |          OPUCn           |
+-------------------------+     +--------------------------+
                                |                          |
                                |          ODUCn           |
                                +--------------------------+
                                |                          |
                                |          OTUCn           |
                                +--------------------------+
Figure 3: Digital Structure of OTN interfaces (from G.709:Figure 6-1)

4. GMPLS Implications and Applicability

Section 3 of RFC7138 describes how to represent G.709 OTUk/ODUk 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 a one-hop OTUCn TE link.

It is possible to create TE-links that span more than one hop by creating forward adjacencies (FA) between non-adjacent nodes (see Figure 5). In this illustration, the nodes B and C are performing the ODUCn regeneration function described in [ITU-T_G872]:Section 7.1, and are not electrically switching the ODUCn signal from one interface to another. As in the one-hop case, Multiple-hop TE-links advertise the ODU switching capability.

The two endpoints of a TE-Link are configured with the supported 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 attribute information (e.g., slot granularity, list of available tributary slot).

4.2. Implications and Applicability for GMPLS Signalling

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. As the resource on the ODUCn link which can be seen by the client ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in [RFC7139] is able to accommodate the requirement of the setup of ODUk/ODUflex over ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is used to indicate how the lower order (LO) ODUj signal is multiplexed into the higher order (HO) 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 link. The ODUk Signal Type is indicated by Traffic Parameters. The 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 (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 bits, while this field in [RFC7139] only has 12 bits, some extension work will eventually be needed. Given that a 12-bit TPN field can support ODUCn links with up to n=400 (i.e. 40Tbit/s links), this need is not urgent.

An example is given in Figure 6 to illustrate the label format defined in [RFC7139] for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4. With this label encoding, only 20 out of the 200 bits mask are non-zero, and is very inefficient. The inefficiency grows for larger values of "n" and an optimized label format may be desirable.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       TPN = 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 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 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 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 0 0 0 0 0 0 1 0 0 0 0 0|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 0 0 0 0 0 0|               Padding Bits(0)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Manoj Kumar, Cisco Systems, manojk2@cisco.com
Antonello Bonfanti, Cisco Systems, abonfant@cisco.com
Yuji Tochio, Fujitsu, tochio@fujitsu.com

7. IANA Considerations

This memo includes no request to IANA.

8. Security Considerations

This document analyses and reuses the protocol extensions in [RFC7138] and [RFC7139] without introducing any new extensions. Therefore, this document introduces no new security considerations to the existing signalling protocol and routing protocol comparing to [RFC7138] and [RFC7139]. Please refer to [RFC7138] and [RFC7139] for further details of the specific security measures. Additionally, [RFC5920] addresses the security aspects that are relevant in the context of GMPLS.

9. References

9.1. Normative References

[ITU-T_G709_2020]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 06/2020", .
[RFC5920]
Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, , <https://www.rfc-editor.org/info/rfc5920>.
[RFC7138]
Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, DOI 10.17487/RFC7138, , <https://www.rfc-editor.org/info/rfc7138>.
[RFC7139]
Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", RFC 7139, DOI 10.17487/RFC7139, , <https://www.rfc-editor.org/info/rfc7139>.

9.2. Informative References

[ITU-T_G709.1]
ITU-T, "ITU-T G.709.1: Flexible OTN short-reach interface; 2018", .
[ITU-T_G709_2012]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 02/2012", .
[ITU-T_G709_2016]
ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 07/2016", .
[ITU-T_G872]
ITU-T, "ITU-T G.872: Architecture of Optical Transport Networks; 12/2019", .
[RFC7062]
Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, DOI 10.17487/RFC7062, , <https://www.rfc-editor.org/info/rfc7062>.
[RFC7096]
Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed., Caviglia, D., Zhang, F., and D. Li, "Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)", RFC 7096, DOI 10.17487/RFC7096, , <https://www.rfc-editor.org/info/rfc7096>.

Appendix A. Possible Future Work

As noted in Section Section 4.2, the GMPLS TPN field in Section 6.1 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 extend the TPN field in GMPLS to use the Reserved bits immediately adjacent. This would need to be done in a backward compatible way.

Section Section 4.2 further notes that the current encoding of GMPLS labels can be inefficient for larger values of n in ODUCn. Future work might examine a more compact, yet generalized label encoding to address this issue should it be felt, after analysis of the operational aspects, that the current encoding is causing problems. Introduction of a new label encoding would need to be done using a new LSP Encoding Type / G-PID pairing to ensure correct interoperability.

Authors' Addresses

Qilei Wang (editor)
ZTE Corporation
Nanjing
China
Radha Valiveti (editor)
Infinera Corp
Sunnyvale
USA
Haomian Zheng (editor)
Huawei
China
Huub van Helvoort
Hai Gaoming B.V
Almere
Netherlands
Sergio Belotti
Nokia