Applicability of GMPLS for beyond 100 Gbit/s Optical Transport NetworkZTE CorporationNanjingChinawang.qilei@zte.com.cnInfinera CorpSunnyvaleCAUnited States of Americarvaliveti@infinera.comHuaweiChinazhenghaomian@huawei.comHai Gaoming BVAlmereNetherlandshuubatwork@gmail.comNokiasergio.belotti@nokia.com
rtg
ccamp
This document examines the applicability of using existing GMPLS routing
and signaling 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 ITU-T Recommendation G.709.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
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.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. OTN Terminology Used in This Document
. Overview of OTUCn/ODUCn in G.709
. OTUCn
. OTUCn-M
. ODUCn
. Tributary Slot Granularity
. Structure of OPUCn MSI with Payload Type 0x22
. Client Signal Mappings
. GMPLS Implications and Applicability
. TE Link Representation
. GMPLS Signaling
. GMPLS Routing
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
. Possible Future Work
Contributors
Authors' Addresses
Introduction
The current GMPLS routing
and signaling
extensions support the control of the Optical Transport Network (OTN) signals and capabilities that
were defined in the 2012 version of ITU-T
Recommendation G.709 .
In 2016, a new version of ITU-T
Recommendation G.709 was published: .
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*100 Gbit/s.
According to the definition in , 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
does not introduce any new features to
OTUCn and ODUCn compared to , this document first presents an overview of the OTUCn and ODUCn signals in
and then analyzes how the current GMPLS routing and signaling mechanisms can
be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links.
This document assumes that readers are familiar with OTN, GMPLS, and how
GMPLS is applied in OTN. As such, this document doesn't provide
any background pertaining to OTN that include links with capacities
of 100 Gbit/s or less; this background could be found in documents such as
and
.
This document provides an overview of the data plane primitives
that enable links with capacities greater than 100 Gbit/s and analyzes the extensions
that would be required in the current GMPLS routing and signaling mechanisms
to support evolution in OTN.
OTN Terminology Used in This Document
FlexO:
Flexible OTN information structure. This information structure usually
has a specific bitrate and frame format that consists of overhead and payload,
which are used as a group for the transport of an OTUCn signal.
LSP:
Label Switched Path
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 .
ODUs can be formed in two ways: a) by encapsulating a single non-OTN client,
such as SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy) or Ethernet, or b) by multiplexing lower-rate ODUs.
In general, the ODU layer represents the path 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 two types: fixed rate and flexible rate. Flexible-rate
ODUs, called "ODUflex", have a rate that is 239/238 times
the bitrate of the client signal they encapsulate.
ODUC:
Optical Data Unit-C. This signal has a bandwidth of approximately 100 Gbit/s and
is of a slightly higher bitrate than the fixed rate ODU4 signal. This signal
has the format defined in Figure 12-1 of . This signal represents the building block for
constructing a higher-rate signal called "ODUCn" (defined below).
ODUCn:
Optical Data Unit-Cn, where Cn indicates the bitrate of approximately n*100 Gbit/s.
This frame structure consists of "n" interleaved frame and multiframe
synchronous instances of the ODUC signal, each of which has the format defined in
Figure 12-1 of .
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. defines specific ODUflex containers that are required to transport
specific clients such as 50GE, 200GE, 400GE, etc.
ODUk:
Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. The term "ODUk" refers
to an ODU whose bitrate is fully specified by the index k. The bitrates of the
ODUk signal for k = {0, 1, 2, 2e, 3, 4} are approximately 1.25 Gbit/s, 2.5 Gbit/s, 10 Gbit/s,
10.3 Gbit/s, 40 Gbit/s, and 100 Gbit/s, respectively.
OPUC:
Optical Payload Unit-C. This signal has a payload of approximately 100 Gbit/s. This
structure represents the payload area of the ODUC signal.
OPUCn:
Optical Payload Unit-Cn, where Cn indicates that the bitrate is
approximately n*100 Gbit/s. This structure represents the payload area of the ODUCn
signal.
OTN:
Optical Transport Network
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 layer overhead.
The structure of this signal is illustrated in Figure 11-4 of
. Note that
the term "fully standardized" is defined by ITU-T in Section 6.1.1 of
.
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:
Payload Structure Indicator. This is a 256-byte signal
that describes the composition of the OPU signal. This field is
a concatenation of the payload type (PT) and the Multiplex
Structure Indicator (MSI) defined below.
TPN:
Tributary Port Number. The tributary port number is used to
indicate the port number of the client signal that is being
transported in one specific tributary slot.
Detailed descriptions for some of these terms can be found in .Overview of OTUCn/ODUCn in G.709
This section provides an overview of the OTUCn/ODUCn signals defined in
.
The text in this section is purely descriptive
and is not normative. For a full description of OTUCn/ODUCn signals,
please refer to .
In the event of any discrepancy
between this text and ,
that other document is definitive.OTUCn
In order to carry client signals with rates greater than 100 Gbit/s,
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*100 Gbit/s. The following are the key characteristics of
the OTUCn signal:
The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals
perform digital section-layer roles only (see Section 6.1.1 of
)
The OTUCn signals are 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 .
Note that the OTUC signal doesn't include the Forward Error Correction (FEC) columns
illustrated in Figure 11-1 of .
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. ITU-T
Recommendation 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.
OTUCn-M
The standard OTUCn signal has the same rate as the ODUCn signal. This
implies that the OTUCn signal can only be transported over wavelength
groups that have a total capacity of multiples of (approximately) 100 Gbit/s.
Modern optical interfaces support a variety of bitrates 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*100 Gbit/s, it is possible to "crunch" the OTUCn, and the unused
tributary slots are thus not transmitted. supports the notion of a reduced-rate OTUCn signal,
termed "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.ODUCn
The ODUCn signal defined in
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 the frames have the same overhead and payload
areas 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
OTUCn signal, which provides the regenerator section layer. In some
scenarios, the ODUCn and OTUCn signals will be coterminated, i.e.,
they will have identical source/sink locations (see
). In ,
the term "OTN Switch" has the same meaning as that used in
.
allows for the ODUCn signal to pass through one or more digital regenerator
nodes (shown as nodes B and C in ),
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 Section 7.1 of
.
In this example, the ODUCn is carried by three OTUCn segments.
Specifically, the OPUCn signal flows through these regenerators
unchanged. That is, the set of client signals, their TPNs, and tributary-slot
allocations remains unchanged.ODUCn Signal
+--------+ +--------+
| +-----------+ |
| OTN |-----------| OTN |
| Switch +-----------+ Switch |
| A | | B |
| +-----------+ |
+--------+ +--------+
<--------ODUCn------->
<-------OTUCn------>
ODUCn Signal - Multi-Hop
+---------+ +--------+ +--------+ +--------+
| +--------+ | | +----------+ |
| OTN |--------| OTN | | OTN |----------| OTN |
| Switch +--------+ Regen +--------+ Regen +----------+ Switch |
| A | | B | | C | | D |
| +--------+ | | +----------+ |
+---------+ +--------+ +--------+ +--------+
<-------------------------ODUCn-------------------------->
<---------------><-----------------><------------------>
OTUCn OTUCn OTUCn
Tributary Slot Granularity
introduced the support for 1.25 Gbit/s granular tributary
slots in OPU2, OPU3, and OPU4 signals.
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.Structure of OPUCn MSI with Payload Type 0x22
As mentioned above, the OPUCn signal has 20*n tributary slots (TSs) (each 5
Gbit/s). 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 (see Section 20.4.1 of ):
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) indicates the port number 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 Figure 15-6 of .
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 Section 17 of .
The terms "ODUj" and "ODUk" are used in a multiplexing scenario, with
ODUj being a low-order ODU that is multiplexed into ODUk, a high-order ODU.
As 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 100 Gbit/s or less, they can be transported over
either an ODUk (k=1..4) or an ODUCn. For ODUflex connections
with rates greater than 100 Gbit/s, ODUCn is required.
ODU Virtual Concatenation (VCAT) 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-100 Gbit/s clients using
ODU VCAT shall continue to be supported.
Digital Structure of OTN Interfaces (from Figure 6-1 of )
Clients (e.g., SONET/SDH and Ethernet)
| | | | | |
| | | | | |
| | | | | |
+---+---+---+----+ | | |
| OPUj | | | |
+----------------+ | | |
| ODUj | | | |
+----------------+----------------------+---+---+----------+
| |
| OPUk |
+----------------------------------------------------------+
| |
| ODUk k in {0,1,2,2e,3,4,flex}|
+-------------------------+-----+--------------------------+
| | | |
| OTUk, OTUk-SC, OTUk-V | | OPUCn |
+-------------------------+ +--------------------------+
| |
| ODUCn |
+--------------------------+
| |
| OTUCn |
+--------------------------+
GMPLS Implications and ApplicabilityTE Link Representation 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. provides an
illustration of a one-hop OTUCn TE link.One-Hop OTUCn TE Link
+----------+ +---------+
| OTN | | OTN |
| Switch +-------------------+ Switch |
| A | | B |
+----------+ +---------+
|<---------OTUCn Link---------->|
|<---------TE Link------------->|
It is possible to create TE links that span more than one hop by creating
forward adjacencies (FAs) between non-adjacent nodes
(see ). In ,
nodes B and C are performing the ODUCn regeneration
function described in Section 7.1 of
and are not electrically switching the ODUCn signal from one interface to another.
As in the one-hop case, multi-hop TE links advertise the ODU switching capability.Multi-Hop ODUCn TE Link
+--------+ +--------+ +--------+ +---------+
| OTN | | OTN | | OTN | | OTN |
| Switch |<------->| Regen |<-------->| Regen |<------->| Switch |
| A | OTUCn | B | OTUCn | C | OTUCn | D |
+--------+ Link +--------+ Link +--------+ Link +---------+
|<-------------------- 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, ODUk, or OTUk), as well as the link
attribute information (e.g., slot granularity and list of available
tributary slot).GMPLS Signaling
Once the ODUCn TE link is configured, the GMPLS mechanisms defined in
can be reused to set up ODUk/ODUflex LSPs with no changes.
As the resource on the ODUCn link that can be seen by the ODUk/ODUflex
client signal is a set of 5 Gbit/s slots, the label defined in
is able to accommodate the requirement of the setup of an ODUk/ODUflex client
signal over an ODUCn link. In , 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; therefore, the two nodes terminating the
TE link know (by internal/local configuration) the attributes of the ODUCn TE
Link.
The TPN defined in (where it is referred to as
"tributary port #")
for an ODUCn link has 14
bits while this field in
only has 12 bits, so 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., 40 Tbit/s links), this need is not urgent.
The example in
illustrates the label format defined in for multiplexing ODU4 onto ODUC10. One ODUC10 has 200
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-zero, which
is very inefficient. The inefficiency grows for larger values of "n", and
an optimized label format may be desirable. Label Format
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
GMPLS Routing
For routing, it is deemed that no extension to the current mechanisms
defined in
is needed.
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 .
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.
IANA Considerations
This document has no IANA actions.
Security Considerations
This document analyzes the applicability of protocol extensions in
and for use in the 2020 version of
ITU-T Recommendation G.709
and finds that no new extensions are needed. Therefore, this document
introduces no new security considerations to the existing signaling and
routing protocols beyond those already described in
and .
Please refer to
and
for further details of the specific security measures. Additionally,
addresses the security aspects that are relevant in the context of GMPLS.
ReferencesNormative ReferencesInterfaces for the optical transport networkITU-TSecurity Framework for MPLS and GMPLS NetworksThis document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport NetworksThis document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport NetworksITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.Informative ReferencesFlexible OTN short-reach interfacesITU-TInterfaces for the optical transport networkITU-TInterfaces for the optical transport networkITU-TArchitecture of optical transport networksITU-TFramework for GMPLS and PCE Control of G.709 Optical Transport NetworksThis document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs).This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs. Possible Future Work
As noted in ,
the GMPLS TPN field defined in
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. 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 pairing of LSP encoding type and Generalized Payload Identifier (G-PID) to ensure correct interoperability.ContributorsInfinera CorpSunnyvaleCAUnited States of AmericaIHussain@infinera.comEricssondaniele.ceccarelli@ericsson.comInfinera CorpSunnyvaleUnited States of Americarrao@infinera.comHuaweizhangfatai@huawei.comHuaweiitalo.busi@huawei.comNokiaDieter.Beller@nokia.comZTEBeijingzhang.yuanbin@zte.com.cnCisco Systemszali@cisco.comd.king@lancaster.ac.ukCisco Systemsmanojk2@cisco.comCisco Systemsabonfant@cisco.comFujitsutochio@fujitsu.comAuthors' AddressesZTE CorporationNanjingChinawang.qilei@zte.com.cnInfinera CorpSunnyvaleCAUnited States of Americarvaliveti@infinera.comHuaweiChinazhenghaomian@huawei.comHai Gaoming BVAlmereNetherlandshuubatwork@gmail.comNokiasergio.belotti@nokia.com