Applicability of GMPLS for Beyond 100G Optical Transport Network

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 OTUC signals (which are labeled 1, 2, ..., n), each of which has the format of a standard OTUk signal without the FEC columns (per [ITU-T_G709_2020] Figure 7-1). The OTUC signal contains the ODUC signals.¶
• Each of the OTUC instance have the same overhead as the standard OTUk signal in [ITU-T_G709_2020]. The combined signal OTUCn has n instances of OTUC overhead, ODUC overhead.¶
• 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 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.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 area, and the payload area, 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. [ITU-T_G709_2020] allows for the ODUCn signal to pass through a digital regenerator node 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 (see Figure 1). In this case, 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, trib-slot allocation remains unchanged.¶

 +--------+           +--------+
 |        +-----------+        |
 | OTN    |-----------| OTN    |
 | DXC    +-----------+ DXC    |
 |        |           |        |
 +--------+           +--------+
     <--------ODUCn------->
      <-------OTUCn------>

 +--------+        +--------+        +--------+          +--------+
 |        +--------+        |        |        +----------+        |
 | OTN    |--------| OTN    |        | OTN    |----------| OTN    |
 | DXC    +--------+ WXC    +--------+ WXC    +----------+ DXC    |
 |        |        | 3R     |        | 3R     |          |        |
 +--------+        +--------+        +--------+          +--------+
     <-------------------------ODUCn-------------------------->
      <---------------> <---------------> <------------------>
           OTUCn              OTUCn               OTUCn

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.¶

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 ODUk (e.g., ODUflex) as specified in clause 17 of [ITU-T_G709_2020].¶
• 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.¶
• 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.¶

                  Clients (e.g. SONET/SDH, Ethernet)
                       +       +      +
                       |       |      |
    +------------------+-------+------+------------------------+
    |                     OPUk                                 |
    +----------------------------------------------------------+
    |                     ODUk                                 |
    +-----------------------+---------------------------+------+
    | OTUk, OTUk.V, OTUkV   |          OPUk             |      |
    +----------+----------------------------------------+      |
    | OTLk.n   |            |          ODUk             |      |
    +----------+            +---------------------+-----+      |
                            | OTUk, OTUk.V, OTUkV |   OPUCn    |
                            +----------+-----------------------+
                            | OTLk.n   |          |   ODUCn    |
                            +----------+          +------------+
                                                  |   OTUCn    |
                                                  +------------+

4.1. TE-Link Representation

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 represented as TE-Links, which can be seen in the Figure 3.¶

+-----+              +-----+
|     |              |     |
|  A  |<-OTUCn Link->|  B  |
|     |              |     |
+-----+              +-----+
   |<--- ODUCn Link -->|
   |<---- TE-Link ---->|

                       3R                    3R
+-----+              +-----+              +-----+              +-----+
|     |              |     |              |     |              |     |
|  A  |<-OTUCn Link->|  B  |<-OTUCn Link->|  C  |<-OTUCn Link->|  D  |
|     |              |     |              |     |              |     |
+-----+              +-----+              +-----+              +-----+
    |<----------------------- ODUCn Link ------------------------>|
    |<------------------------ TE-Link -------------------------->|

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 is needed. Given that a 12-bit TPN field can support ODUCn links with up to n=400 (i.e. 40Tbit/s links), this extension is not urgently needed.¶

An example is given in Figure 4 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. Along with the increase of "n", the label may become lengthy, an optimized label format may be needed.¶

   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)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3. Implications and Applicability for GMPLS Routing

For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] are needed. Because, once an ODUCn link is up, the resources that need to be advertised are the resources that 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, 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.¶