RFC 7138 PROPOSED STANDARD ROUTING · OPTICAL · GMPLS
OSPF-TE for OTN: Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks
How OSPF learns which optical containers, slots and bandwidths each OTN link can switch, so GMPLS can plan paths across them.
RFC EDITOR
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, March 2014, <https://www.rfc-editor.org/info/rfc7138>.
BIBTEX
@misc{rfc7138,
series = {Request for Comments},
number = 7138,
howpublished = {RFC 7138},
publisher = {RFC Editor},
doi = {10.17487/RFC7138},
url = {https://www.rfc-editor.org/info/rfc7138},
author = {D. Ceccarelli and F. Zhang and S. Belotti and R. Rao and J. Drake},
title = {{Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks}},
pagetotal = 36,
year = 2014,
month = mar,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Ceccarelli, Ed.
Request for Comments: 7138 Ericsson
Category: Standards Track F. Zhang
ISSN: 2070-1721 Huawei Technologies
S. Belotti
Alcatel-Lucent
R. Rao
Infinera Corporation
J. Drake
Juniper
March 2014
Traffic Engineering Extensions to OSPF
for GMPLS Control of Evolving G.709 Optical Transport Networks
Abstract
This 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.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7138.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. OSPF-TE Extensions ..............................................4
3. TE-Link Representation ..........................................6
4. ISCD Format Extensions ..........................................6
4.1. Switching Capability Specific Information ..................8
4.1.1. Switching Capability Specific Information
for Fixed Containers ................................9
4.1.2. Switching Capability Specific Information
for Variable Containers ............................10
4.1.3. Switching Capability Specific Information --
Field Values and Explanation .......................10
5. Examples .......................................................13
5.1. MAX LSP Bandwidth Fields in the ISCD ......................13
5.2. Example of T, S, and TS Granularity Utilization ...........17
5.2.1. Example of Different TS Granularities ..............18
5.3. Example of ODUflex Advertisement ..........................20
5.4. Example of Single-Stage Muxing ............................22
5.5. Example of Multi-Stage Muxing -- Unbundled Link ...........23
5.6. Example of Multi-Stage Muxing -- Bundled Links ............25
5.7. Example of Component Links with Non-Homogeneous
Hierarchies ...............................................27
6. OSPFv2 Scalability .............................................29
7. Compatibility ..................................................30
8. Security Considerations ........................................30
9. IANA Considerations ............................................31
9.1. Switching Types ...........................................31
9.2. New Sub-TLVs ..............................................31
10. Contributors ..................................................32
11. Acknowledgements ..............................................33
12. References ....................................................33
12.1. Normative References .....................................33
12.2. Informative References ...................................34
1. Introduction
G.709 ("Interfaces for the Optical Transport Network (OTN)")
[G.709-2012] includes new fixed and flexible ODU (Optical channel
Data Unit) containers, includes two types of tributary slots (i.e.,
1.25 Gbps and 2.5 Gbps), and supports various multiplexing
relationships (e.g., ODUj multiplexed into ODUk (j<k)), two different
tributary slots for ODUk (K=1, 2, 3), and the ODUflex service type.
In order to advertise this information in routing, this document
provides encoding specific to OTN technology for use in GMPLS OSPF-TE
as defined in [RFC4203].
For a short overview of OTN evolution and implications of OTN
requirements on GMPLS routing, please refer to [RFC7062]. The
information model and an evaluation against the current solution are
provided in [RFC7096]. The reader is supposed to be familiar with
both of these documents.
Routing information for Optical Channel (OCh) layer (i.e.,
wavelength) is beyond the scope of this document. Please refer to
[RFC6163] and [RFC6566] for further information.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. OSPF-TE Extensions
In terms of GMPLS-based OTN networks, each Optical channel Transport
Unit-k (OTUk) can be viewed as a component link, and each component
link can carry one or more types of ODUj (j<k).
Each TE-Link State Advertisement (LSA) can carry a top-level link TLV
with several nested sub-TLVs to describe different attributes of a
TE-Link. Two top-level TLVs are defined in [RFC3630]: (1) The Router
Address TLV (referred to as the Node TLV) and (2) the TE-Link TLV.
One or more sub-TLVs can be nested into the two top-level TLVs. The
sub-TLV set for the two top-level TLVs are also defined in [RFC3630]
and [RFC4203].
As discussed in [RFC7062] and [RFC7096], OSPF-TE must be extended to
be able to advertise the termination and Switching Capabilities of
each different ODUj and ODUk/OTUk (Optical Transport Unit) and the
advertisement of related multiplexing capabilities. These
capabilities are carried in the Switching Capability specific
information field of the Interface Switching Capability Descriptor
(ISCD) using formats defined in this document. As discussed in
[RFC7062], the use of a technology-specific Switching Capability
specific information field necessitates the definition of a new
Switching Capability value and associated new Switching Capability.
In the following, we will use ODUj to indicate a service type that is
multiplexed into a higher-order (HO) ODU, ODUk to indicate a higher-
order ODU including an ODUj, and ODUk/OTUk to indicate the layer
mapped into the OTUk. Moreover, ODUj(S) and ODUk(S) are used to
indicate the ODUj and ODUk supporting Switching Capability only, and
the ODUj->ODUk format is used to indicate the ODUj-into-ODUk
multiplexing capability.
This notation can be repeated as needed depending on the number of
multiplexing levels. In the following, the term "multiplexing tree"
is used to identify a multiplexing hierarchy where the root is always
a server ODUk/OTUk and any other supported multiplexed container is
represented with increasing granularity until reaching the leaf of
the tree. The tree can be structured with more than one branch if
the server ODUk/OTUk supports more than one hierarchy.
For example, if a multiplexing hierarchy like the following one is
considered:
ODU2 ODU0 ODUflex ODU0
\ / \ /
| |
ODU3 ODU2
\ /
\ /
\ /
\ /
ODU4
the ODU4 is the root of the muxing tree; ODU3 and ODU2 are containers
directly multiplexed into the server; and ODU2 and ODU0 are the
leaves of the ODU3 branch, while ODUflex and ODU0 are the leaves of
the ODU2 one. This means that it is possible to have the following
multiplexing capabilities:
ODU2->ODU3->ODU4
ODU0->ODU3->ODU4
ODUflex->ODU2->ODU4
ODU0->ODU2->ODU4
3. TE-Link Representation
G.709 ODUk/OTUk links are represented as TE-Links in GMPLS Traffic
Engineering Topology for supporting ODUj layer switching. These TE-
Links can be modeled in multiple ways.
OTUk physical link(s) can be modeled as a TE-Link(s). Figure 1 below
provides an illustration of one-hop OTUk TE-Links.
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
|<-- TE-Link -->| |<-- TE-Link -->|
Figure 1: OTUk TE-Links
It is possible to create TE-Links that span more than one hop by
creating forwarding adjacencies (FAs) between non-adjacent nodes (see
Figure 2). As in the one-hop case, multiple-hop TE-Links advertise
the ODU Switching Capability.
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
ODUk Switched
|<------------- ODUk Link ------------->|
|<-------------- TE-Link--------------->|
Figure 2: Multiple-Hop TE-Link
4. ISCD Format Extensions
The ISCD describes the Switching Capability of an interface and is
defined in [RFC4203]. This document defines a new Switching
Capability value for OTN [G.709-2012] as follows:
Value Type
----- ----
110 OTN-TDM capable
When supporting the extensions defined in this document, for both
fixed and flexible ODUs, the Switching Capability and Encoding values
MUST be used as follows:
o Switching Capability = OTN-TDM
o Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
The same Switching Type and encoding values must be used for both
fixed and flexible ODUs. When Switching Capability and Encoding
fields are set to values as stated above, the Interface Switching
Capability Descriptor MUST be interpreted as defined in [RFC4203].
The MAX LSP Bandwidth field is used according to [RFC4203], i.e., 0
<= MAX LSP Bandwidth <= ODUk/OTUk, and intermediate values are those
on the branch of the OTN switching hierarchy supported by the
interface. For example, in the OTU4 link it could be possible to
have ODU4 as MAX LSP Bandwidth for some priorities, ODU3 for others,
ODU2 for some others, etc. The bandwidth unit is in bytes/second and
the encoding MUST be in IEEE floating point format. The discrete
values for various ODUs are shown in the table below (please note
that there are 1000 bits in a kilobit according to normal practices
in telecommunications).
+-------------------+-----------------------------+-----------------+
| ODU Type | ODU nominal bit rate |Value in Byte/Sec|
| | |(floating p. val)|
+-------------------+-----------------------------+-----------------+
| ODU0 | 1,244,160 kbps | 0x4D1450C0 |
| ODU1 | 239/238 x 2,488,320 kbps | 0x4D94F048 |
| ODU2 | 239/237 x 9,953,280 kbps | 0x4E959129 |
| ODU3 | 239/236 x 39,813,120 kbps | 0x4F963367 |
| ODU4 | 239/227 x 99,532,800 kbps | 0x504331E3 |
| ODU2e | 239/237 x 10,312,500 kbps | 0x4E9AF70A |
| | | |
| ODUflex for CBR | 239/238 x client signal | MAX LSP |
| Client signals | bit rate | Bandwidth |
| | | |
| ODUflex for GFP-F | | MAX LSP |
| Mapped client | Configured bit rate | Bandwidth |
| signal | | |
| | | |
| ODUflex | Configured bit rate | MAX LSP |
| resizable | | Bandwidth |
+-------------------+-----------------------------+-----------------+
A single ISCD MAY be used for the advertisement of unbundled or
bundled links supporting homogeneous multiplexing hierarchies and the
same TS (tributary slot) granularity. A different ISCD MUST be used
for each different muxing hierarchy (muxing tree in the following
examples) and different TS granularity supported within the TE-Link.
When a received LSA includes a sub-TLV not formatted accordingly to
the precise specifications in this document, the problem SHOULD be
logged and the wrongly formatted sub-TLV MUST NOT be used for path
computation.
4.1. Switching Capability Specific Information
The technology-specific part of the OTN-TDM ISCD may include a
variable number of sub-TLVs called Bandwidth sub-TLVs. Each sub-TLV
is encoded with the sub-TLV header as defined in [RFC3630],
Section 2.3.2. The muxing hierarchy tree MUST be encoded as an
order-independent list. Two types of Bandwidth sub-TLVs are defined
(TBA by IANA). Note that type values are defined in this document
and not in [RFC3630].
o Type 1 - Unreserved Bandwidth for fixed containers
o Type 2 - Unreserved/MAX LSP Bandwidth for flexible containers
The Switching Capability specific information (SCSI) MUST include one
Type 1 sub-TLV for each fixed container and one Type 2 sub-TLV for
each variable container. Each container type is identified by a
Signal Type. Signal Type values are defined in [RFC7139].
With respect to ODUflex, three different Signal Types are allowed:
o 20 - ODUflex(CBR) (i.e., 1.25*N Gbps)
o 21 - ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)
o 22 - ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
where CBR stands for Constant Bit Rate, and GFP-F stands for Generic
Framing Procedure - Framed.
Each MUST always be advertised in separate Type 2 sub-TLVs as each
uses different adaptation functions [G.805]. In the case that both
GFP-F resizable and non-resizable (i.e., 21 and 22) are supported,
only Signal Type 21 SHALL be advertised as this type also implies
support for Type 22 adaptation.
4.1.1. Switching Capability Specific Information for Fixed Containers
The format of the Bandwidth sub-TLV for fixed containers is depicted
in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 0 | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 7 | Unreserved Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bandwidth Sub-TLV -- Type 1
The values of the fields shown in Figure 3 are explained in
Section 4.1.3.
4.1.2. Switching Capability Specific Information for Variable
Containers
The format of the Bandwidth sub-TLV for variable containers is
depicted in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bandwidth Sub-TLV -- Type 2
The values of the fields shown in figure 4 are explained in
Section 4.1.3.
4.1.3. Switching Capability Specific Information -- Field Values and
Explanation
The fields in the Bandwidth sub-TLV MUST be filled as follows:
o Signal Type (8 bits): Indicates the ODU type being advertised.
Values are defined in [RFC7139].
o Num of stages (8 bits): This field indicates the number of
multiplexing stages used to transport the indicated Signal Type.
It MUST be set to the number of stages represented in the sub-TLV.
o Flags (8 bits):
* T Flag (bit 17): Indicates whether the advertised bandwidth can
be terminated. When the Signal Type can be terminated T MUST
be set, while when the Signal Type cannot be terminated T MUST
be cleared.
* S Flag (bit 18): Indicates whether the advertised bandwidth can
be switched. When the Signal Type can be switched, S MUST be
set; when the Signal Type cannot be switched, S MUST be
cleared.
* The value 0 in both the T bit and S bit MUST NOT be used.
o TSG (3 bits): Tributary Slot Granularity. Used for the
advertisement of the supported tributary slot granularity. The
following values MUST be used:
* 0 - Ignored
* 1 - 1.25 Gbps / 2.5 Gbps
* 2 - 2.5 Gbps only
* 3 - 1.25 Gbps only
* 4-7 - Reserved
A value of 1 MUST be used on interfaces that are configured to
support the fallback procedures defined in [G.798]. A value of 2
MUST be used on interfaces that only support 2.5 Gbps tributary
slots, such as [RFC4328] interfaces. A value of 3 MUST be used on
interfaces that are configured to only support 1.25 Gbps tributary
slots. A value of 0 MUST be used for non-multiplexed Signal Types
(i.e., a non-OTN client).
o Res (3 bits): Reserved bits. MUST be set to 0 and ignored on
receipt.
o Priority (8 bits): A bitmap used to indicate which priorities are
being advertised. The bitmap is in ascending order, with the
leftmost bit representing priority level 0 (i.e., the highest) and
the rightmost bit representing priority level 7 (i.e., the
lowest). A bit MUST be set (1) corresponding to each priority
represented in the sub-TLV and MUST NOT be set (0) when the
corresponding priority is not represented. At least one priority
level MUST be advertised that, unless overridden by local policy,
SHALL be at priority level 0.
o Stage (8 bits): Each Stage field indicates a Signal Type in the
multiplexing hierarchy used to transport the signal indicated in
the Signal Type field. The number of Stage fields included in a
sub-TLV MUST equal the value of the Num of stages field. The
Stage fields MUST be ordered to match the data plane in ascending
order (from the lowest order ODU to the highest order ODU). The
values of the Stage field are the same as those defined for the
Signal Type field. When the Num of stages field carries a 0, then
the Stage and Padding fields MUST be omitted.
* Example: For the ODU1->ODU2->OD3 hierarchy, the Signal Type
field is set to ODU1 and two Stage fields are present, the
first indicating ODU2 and the second ODU3 (server layer).
o Padding (variable): The Padding field is used to ensure the 32-bit
alignment of stage fields. The length of the Padding field is
always a multiple of 8 bits (1 byte). Its length can be
calculated, in bytes, as: 4 - ( "value of Num of stages field" %
4). The Padding field MUST be set to a zero (0) value on
transmission and MUST be ignored on receipt.
o Unreserved ODUj (16 bits): This field indicates the Unreserved
Bandwidth at a particular priority level. This field MUST be set
to the number of ODUs at the indicated the Signal Type for a
particular priority level. One field MUST be present for each bit
set in the Priority field, and the fields are ordered to match the
Priority field. Fields MUST NOT be present for priority levels
that are not indicated in the Priority field.
o Unreserved Padding (16 bits): The Padding field is used to ensure
the 32-bit alignment of the Unreserved ODUj fields. When present,
the Unreserved Padding field is 16 bits (2 bytes) long. When the
number of priorities is odd, the Unreserved Padding field MUST be
included. When the number of priorities is even, the Unreserved
Padding MUST be omitted.
o Unreserved Bandwidth (32 bits): This field indicates the
Unreserved Bandwidth at a particular priority level. This field
MUST be set to the bandwidth, in bytes/second in IEEE floating
point format, available at the indicated Signal Type for a
particular priority level. One field MUST be present for each bit
set in the Priority field, and the fields are ordered to match the
Priority field. Fields MUST NOT be present for priority levels
that are not indicated in the Priority field.
o Maximum LSP Bandwidth (32 bits): This field indicates the maximum
bandwidth that can be allocated for a single LSP at a particular
priority level. This field MUST be set to the maximum bandwidth,
in bytes/second in IEEE floating point format, available to a
single LSP at the indicated Signal Type for a particular priority
level. One field MUST be present for each bit set in the Priority
field, and the fields are ordered to match the Priority field.
Fields MUST NOT be present for priority levels that are not
indicated in the Priority field. The advertisement of the MAX LSP
Bandwidth MUST take into account HO OPUk bit rate tolerance and be
calculated according to the following formula:
* Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) *
(1-HO OPUk bit rate tolerance)
5. Examples
The examples in the following pages are not normative and are not
intended to imply or mandate any specific implementation.
5.1. MAX LSP Bandwidth Fields in the ISCD
This example shows how the MAX LSP Bandwidth fields of the ISCD are
filled according to the evolving of the TE-Link bandwidth occupancy.
In this example, an OTU4 link is considered, with supported
priorities 0,2,4,7 and muxing hierarchy ODU1->ODU2->ODU3->ODU4.
At time T0, with the link completely free, the advertisement would
be:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MAX LSP Bandwidth Fields in the ISCD at T0
At time T1, an ODU3 at priority 2 is set up, so for priority 0, the
MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for
priorities from 2 to 7 (excluding the non-supported ones), the MAX
LSP Bandwidth is equal to ODU3, as no more ODU4s are available and
the next supported ODUj in the hierarchy is ODU3. The advertisement
is updated as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MAX LSP Bandwidth Fields in the ISCD at T1
At time T2, an ODU2 at priority 4 is set up. The first ODU3 has not
been available since T1 as it was kept by the ODU3 LSP, while the
second is no longer available and just 3 ODU2s are left in it. ODU2
is now the MAX LSP Bandwidth for priorities higher than 4. The
advertisement is updated as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MAX LSP Bandwidth Fields in the ISCD at T2
5.2. Example of T, S, and TS Granularity Utilization
In this example, an interface with tributary slot type 1.25 Gbps and
fallback procedure enabled is considered (TS granularity=1). It
supports the simple ODU1->ODU2->ODU3 hierarchy and priorities 0 and
3. Suppose that in this interface, the ODU3 Signal Type can be both
switched or terminated, the ODU2 can only be terminated, and the ODU1
can only be switched. Please note that since the ODU1 is not being
advertised to support ODU0, the value of its TSG field is "ignored"
(TS granularity=0). For the advertisement of the capabilities of
such an interface, a single ISCD is used. Its format is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: T, S, and TS Granularity Utilization
5.2.1. Example of Different TS Granularities
In this example, two interfaces with homogeneous hierarchies but
different tributary slot types are considered. The first one
supports an [RFC4328] interface (TS granularity=2) while the second
one supports a G.709-2012 interface with fallback procedure disabled
(TS granularity=3). Both support the ODU1->ODU2->ODU3 hierarchy and
priorities 0 and 3. Suppose that in this interface, the ODU3 Signal
Type can be both switched or terminated, the ODU2 can only be
terminated, and the ODU1 can only be switched. For the advertisement
of the capabilities of such interfaces, two different ISCDs are used.
The format of their SCSIs is as follows:
SCSI of ISCD 1 -- TS granularity=2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 2 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Utilization of Different TS Granularities -- ISCD 1
SCSI of ISCD 2 -- TS granularity=3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 3 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Utilization of Different TS Granularities -- ISCD 2
Hierarchies with the same muxing tree but with different exported TS
granularity MUST be considered as non-homogenous hierarchies. This
is the case in which an H-LSP and the client LSP are terminated on
the same egress node. What can happen is that a loose Explicit Route
Object (ERO) is used at the hop where the signaled LSP is nested into
the Hierarchical-LSP (H-LSP) (penultimate hop of the LSP).
In the following figure, node C receives a loose ERO from A; the ERO
goes towards node E, and node C must choose between the ODU2 H-LSP on
if1 or the one on if2. In this case, the H-LSP on if1 exports a
TS=1.25 Gbps, and the H-LSP on if2 exports a TS=2.5 Gbps; because the
service LSP being signaled needs a 1.25 Gbps tributary slot, only the
H-LSP on if1 can be used to reach node E. For further details,
please see Section 3.2 of [RFC7096].
ODU0-LSP
..........................................................+
| |
| ODU2-H-LSP |
| +-------------------------------+
| | |
+--+--+ +-----+ +-----+ if1 +-----+ +-----+
| | OTU3 | | OTU3 | |---------| |---------| |
| A +------+ B +------+ C | if2 | D | | E |
| | | | | |---------| |---------| |
+-----+ +-----+ +-----+ +-----+ +-----+
... Service LSP
--- H-LSP
Figure 11: Example of Service LSP and H-LSP Terminating
on the Same Node
5.3. Example of ODUflex Advertisement
In this example, the advertisement of an ODUflex->ODU3 hierarchy is
shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth
needs to be advertised, and in some cases, information about the
Unreserved Bandwidth could also be useful. The amount of Unreserved
Bandwidth does not give a clear indication of how many ODUflex LSPs
can be set up either at the MAX LSP Bandwidth or at different rates,
as it gives no information about the spatial allocation of the free
TSs.
An indication of the amount of Unreserved Bandwidth could be useful
during the path computation process, as shown in the following
example. Suppose there are two TE-Links (A and B) with MAX LSP
Bandwidth equal to 10 Gbps each. In the case where 50 Gbps of
Unreserved Bandwidth are available on Link A, 10 Gbps on Link B, and
3 ODUflex LSPs of 10 Gbps each have to be restored, for sure only one
can be restored along Link B, and it is probable, but not certain,
that two of them can be restored along Link A. The T, S, and TSG
fields are not relevant to this example (filled with Xs).
In the case of ODUflex advertisement, the Type 2 Bandwidth sub-TLV is
used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0| Priority(8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ODUflex Advertisement
5.4. Example of Single-Stage Muxing
Suppose there is 1 OTU4 component link supporting single-stage muxing
of ODU1, ODU2, ODU3, and ODUflex, the supported hierarchy can be
summarized in a tree as in the following figure. For the sake of
simplicity, we also assume that only priorities 0 and 3 are
supported. The T, S, and TSG fields are not relevant to this example
(filled with Xs).
ODU1 ODU2 ODU3 ODUflex
\ \ / /
\ \ / /
\ \/ /
ODU4
The related SCSIs are as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 =40 | Unres ODU1 at Prio 3 =40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Single-Stage Muxing
5.5. Example of Multi-Stage Muxing -- Unbundled Link
Suppose there is 1 OTU4 component link with muxing capabilities as
shown in the following figure:
ODU2 ODU0 ODUflex ODU0
\ / \ /
| |
ODU3 ODU2
\ /
\ /
\ /
\ /
ODU4
Considering only supported priorities 0 and 3, the advertisement is
composed by the following Bandwidth sub-TLVs (T and S fields are not
relevant to this example and filled with Xs):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =8 | Unres ODU2 at Prio 3 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.type=ODUflex | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Multi-Stage Muxing -- Unbundled Link
5.6. Example of Multi-Stage Muxing -- Bundled Links
In this example, 2 OTU4 component links with the same supported TS
granularity and homogeneous muxing hierarchies are considered. The
following muxing capabilities trees are supported:
Component Link#1 Component Link#2
ODU2 ODU0 ODU2 ODU0
\ / \ /
| |
ODU3 ODU3
| |
ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement is
as follows (the T, S, and TSG fields are not relevant to this example
and filled with Xs):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =2 | Unres ODU4 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =4 | Unres ODU3 at Prio 3 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =16 | Unres ODU2 at Prio 3 =16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =128 | Unres ODU0 at Prio 3 =128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Multi-Stage Muxing -- Bundled Links
5.7. Example of Component Links with Non-Homogeneous Hierarchies
In this example, 2 OTU4 component links with the same supported TS
granularity and non-homogeneous muxing hierarchies are considered.
The following muxing capabilities trees are supported:
Component Link#1 Component Link#2
ODU2 ODU0 ODU1 ODU0
\ / \ /
| |
ODU3 ODU2
| |
ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement uses
two different ISCDs, one for each hierarchy (the T, S, and TSG fields
are not relevant to this example and filled with Xs). In the
following figure, the SCSI of each ISCD is shown:
SCSI of ISCD 1 -- Component Link#1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =8 | Unres ODU2 at Prio 3 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
ISCD 1
SCSI of ISCD 2 -- Component Link#2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 =40 | Unres ODU1 at Prio 3 =40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
ISCD 2
6. OSPFv2 Scalability
This document does not introduce OSPF scalability issues with respect
to existing GMPLS encoding and does not require any modification to
flooding frequency. Moreover, the design of the encoding has been
carried out taking into account bandwidth optimization, in
particular:
o Only unreserved and MAX LSP Bandwidth related to supported
priorities are advertised.
o For fixed containers, only the number of available containers is
advertised instead of the available bandwidth in order to use only
16 bits per container instead of 32 (as per former GMPLS
encoding).
In order to further reduce the amount of data advertised it is
RECOMMENDED to bundle component links with homogeneous hierarchies as
described in [RFC4201] and illustrated in Section 5.6.
7. Compatibility
All implementations of this document MAY also support advertisement
as defined in [RFC4203]. When nodes support both the advertisement
method in [RFC4203] and the one in this document, implementations
MUST support the configuration of which advertisement method is
followed. The choice of which is used is based on policy and beyond
the scope of this document. This enables nodes following each method
to identify similar supporting nodes and compute paths using only the
appropriate nodes.
8. Security Considerations
This document extends [RFC4203]. As with [RFC4203], it specifies the
contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for
Shortest Path First (SPF) computation or normal routing, the
extensions specified here have no direct effect on IP routing.
Tampering with GMPLS TE LSAs may have an effect on the underlying
transport (optical and/or Synchronous Optical Network - Synchronous
Digital Hierarchy (SONET-SDH) network. [RFC3630] notes that the
security mechanisms described in [RFC2328] apply to Opaque LSAs
carried in OSPFv2. An analysis of the security of OSPF is provided
in [RFC6863] and applies to the extensions to OSPF as described in
this document. Any new mechanisms developed to protect the
transmission of information carried in Opaque LSAs will also
automatically protect the extensions defined in this document.
Please refer to [RFC5920] for details on security threats; defensive
techniques; monitoring, detection, and reporting of security attacks;
and requirements.
9. IANA Considerations
9.1. Switching Types
IANA has made the following assignment in the "Switching Types"
section of the "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Parameters" registry located at
<http://www.iana.org/assignments/gmpls-sig-parameters>:
Value Name Reference
--------- -------------------------- ----------
110 OTN-TDM capable [RFC7138]
The same type of modification has been applied to the IANA-GMPLS-TC-
MIB at <https://www.iana.org/assignments/ianagmplstc-mib>, where the
value:
OTN-TDM (110), -- Time-Division-Multiplex OTN-TDM capable
has been added to the IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION
syntax list.
9.2. New Sub-TLVs
This document defines 2 new sub-TLVs that are carried in Interface
Switching Capability Descriptors [RFC4203] with the Signal Type OTN-
TDM. Each sub-TLV includes a 16-bit type identifier (the T-field).
The same T-field values are applicable to the new sub-TLV.
IANA has created and will maintain a new sub-registry, the "Types for
sub-TLVs of OTN-TDM SCSI (Switching Capability Specific Information)"
registry under the "Open Shortest Path First (OSPF) Traffic
Engineering TLVs" registry, see
<http://www.iana.org/assignments/ospf-traffic-eng-tlvs>, with the
sub-TLV types as follows:
Value Sub-TLV Reference
--------- -------------------------- ----------
0 Reserved [RFC7138]
1 Unreserved Bandwidth for [RFC7138]
fixed containers
2 Unreserved/MAX Bandwidth for [RFC7138]
flexible containers
3-65535 Unassigned
Types are to be assigned via Standards Action as defined in
[RFC5226].
10. Contributors
Diego Caviglia
Ericsson
Via E. Melen, 77
Genova
Italy
EMail: diego.caviglia@ericsson.com
Dan Li
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
EMail: danli@huawei.com
Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
EMail: pietro_vittorio.grandi@alcatel-lucent.com
Khuzema Pithewan
Infinera Corporation
140 Caspian CT.
Sunnyvale, CA
USA
EMail: kpithewan@infinera.com
Xiaobing Zi
Huawei Technologies
EMail: zixiaobing@huawei.com
Francesco Fondelli
Ericsson
EMail: francesco.fondelli@ericsson.com
Marco Corsi
EMail: corsi.marco@gmail.com
Eve Varma
Alcatel-Lucent
EMail: eve.varma@alcatel-lucent.com
Jonathan Sadler
Tellabs
EMail: jonathan.sadler@tellabs.com
Lyndon Ong
Ciena
EMail: lyong@ciena.com
Ashok Kunjidhapatham
EMail: akunjidhapatham@infinera.com
Snigdho Bardalai
EMail: sbardalai@infinera.com
Steve Balls
EMail: Steve.Balls@metaswitch.com
Jonathan Hardwick
EMail: Jonathan.Hardwick@metaswitch.com
Xihua Fu
EMail: fu.xihua@zte.com.cn
Cyril Margaria
EMail: cyril.margaria@nsn.com
Malcolm Betts
EMail: Malcolm.betts@zte.com.cn
11. Acknowledgements
The authors would like to thank Fred Gruman and Lou Berger for their
valuable comments and suggestions.
12. References
12.1. Normative References
[G.709-2012] ITU-T, "Interface for the optical transport network",
Recommendation G.709/Y.1331, February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
12.2. Informative References
[G.798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", Recommendation
G.798, December 2012.
[G.805] ITU-T, "Generic functional architecture of transport
networks", Recommendation G.805, March 2000.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163,
April 2011.
[RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A
Framework for the Control of Wavelength Switched Optical
Networks (WSONs) with Impairments", RFC 6566, March
2012.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC7062] Zhang, F., Li, D., Li, H., Belotti, S., and D.
Ceccarelli, "Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks", RFC 7062, November
2013.
[RFC7096] Belotti, S., Grandi, P., Ceccarelli, D., Ed., Caviglia,
D., and F. Zhang, "Evaluation of Existing GMPLS Encoding
against G.709v3 Optical Transport Networks (OTNs)", RFC
7096, January 2014.
[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, March 2014.
Authors' Addresses
Daniele Ceccarelli (editor)
Ericsson
Via E.Melen 77
Genova - Erzelli
Italy
EMail: daniele.ceccarelli@ericsson.com
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28972912
EMail: zhangfatai@huawei.com
Sergio Belotti
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
EMail: sergio.belotti@alcatel-lucent.com
Rajan Rao
Infinera Corporation
140, Caspian CT.
Sunnyvale, CA-94089
USA
EMail: rrao@infinera.com
John E. Drake
Juniper
EMail: jdrake@juniper.net
AI ELI5
On this page
PROBLEMG.709 (2012) optical networks added new fixed and flexible ODU containers, two sizes of tributary slot and several multiplexing layers. The existing GMPLS routing encoding in RFC 4203 could not describe all of that.
MECHANISMRFC 7138 defines a new switching capability value, OTN-TDM (110), and two Bandwidth sub-TLVs carried in the Interface Switching Capability Descriptor. They list each container type, its multiplexing stages, slot granularity and the bandwidth left at each priority.
WHY IT MATTERSOSPF-TE nodes can now advertise OTN capabilities in a compact form, and path computation can use them. The extension has no direct effect on IP routing.
§1Why OTN Needs New Routing Encoding
ITU-T G.709, the standard for the Optical Transport Network (OTN), was published in a 2012 edition that adds new fixed and flexible ODU (Optical channel Data Unit) containers. It includes two types of tributary slot (1.25 Gbps and 2.5 Gbps), supports several multiplexing relationships such as an ODUj multiplexed into an ODUk (j<k), and adds the ODUflex service type.
To advertise this information in routing, RFC 7138 provides an OTN-specific encoding for GMPLS OSPF-TE as defined in RFC 4203. The reader is expected to know RFC 7062 (OTN overview) and RFC 7096 (the information model). Routing for the optical channel (wavelength) layer is out of scope; RFC 6163 and RFC 6566 cover it.
Optical networks got new kinds of boxes and new ways of stacking them. The old announcements had no words for them, so this RFC adds the words.
§2Multiplexing Trees and Notation
In a GMPLS OTN network, each OTUk (Optical channel Transport Unit-k) can be seen as a component link, and each component link can carry one or more types of ODUj (j<k). OSPF-TE must be able to advertise the termination and switching capabilities of each ODUj and ODUk/OTUk, plus the related multiplexing capabilities.
The RFC calls a multiplexing hierarchy a multiplexing tree. Its root is always the server ODUk/OTUk, and every other supported container hangs below it with finer granularity down to the leaves. In the RFC's example, ODU4 is the root, ODU3 and ODU2 are multiplexed directly into it, ODU2 and ODU0 are leaves of the ODU3 branch, and ODUflex and ODU0 are leaves of the ODU2 branch. Each path from leaf to root, such as ODUflex->ODU2->ODU4, is one multiplexing capability.
Think of nesting dolls: small boxes go inside medium boxes, which go inside one big box. The tree is the picture of which boxes fit inside which.
- ODU4 server, root of the tree
- ODU3
- ODU2
- ODU0
- ODU2
- ODUflex
- ODU0
- ODU3
§3Representing OTN Links as TE-Links
G.709 ODUk/OTUk links are represented as TE-Links in the GMPLS traffic engineering topology so that ODUj layer switching can be supported. An OTUk physical link can be modeled as a TE-Link, giving one-hop TE-Links between OTN switches.
It is also possible to create TE-Links that span more than one hop by creating forwarding adjacencies (FAs) between non-adjacent nodes. As in the one-hop case, multiple-hop TE-Links advertise the ODU switching capability.
A TE-Link is a road on the planner's map. It can be one short road between neighbours, or a shortcut that skips the towns in between.
§4The OTN-TDM ISCD and Bandwidth Sub-TLVs
RFC 7138 adds a new Switching Capability value to the Interface Switching Capability Descriptor (ISCD) from RFC 4203: 110, OTN-TDM capable. Implementations MUST use Switching Capability = OTN-TDM and Encoding Type = G.709 ODUk (Digital Path) as defined in RFC 4328, for both fixed and flexible ODUs. The MAX LSP Bandwidth field is used as in RFC 4203, in bytes per second in IEEE floating point format.
The technology-specific part of the ISCD holds a variable number of Bandwidth sub-TLVs. Type 1 (Unreserved Bandwidth for fixed containers) MUST appear once per fixed container, and Type 2 (Unreserved/MAX LSP Bandwidth for flexible containers) once per variable container. Each is identified by a Signal Type defined in RFC 7139.
For ODUflex, three Signal Types are allowed: 20 for ODUflex(CBR), 21 for ODUflex(GFP-F) resizable and 22 for ODUflex(GFP-F) non-resizable. Each MUST be advertised in its own Type 2 sub-TLV, but if both 21 and 22 are supported, only 21 is advertised because it implies support for 22.
A single ISCD MAY cover bundled or unbundled links with homogeneous multiplexing hierarchies and the same tributary slot granularity. A different ISCD MUST be used for each different muxing tree and each different granularity in the TE-Link. A receiver that finds a badly formatted sub-TLV SHOULD log the problem and MUST NOT use that sub-TLV for path computation.
Each link posts a standard form. The form says what kinds of boxes it handles and, for each kind, how many it can still take.
| Type | Used for | Per priority carries |
|---|---|---|
| 1 | Fixed containers | 16-bit count of unreserved ODUj |
| 2 | Flexible containers (ODUflex) | 32-bit Unreserved Bandwidth and 32-bit MAX LSP Bandwidth |
§5Sub-TLV Fields in Detail
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 2 bytes | 1 for fixed containers, 2 for flexible containers. | |
LENGTH | Length | 2 bytes | Length of the sub-TLV. | |
SIGNAL-TYPE | Signal Type | 1 byte | The ODU type being advertised (values in RFC 7139). | |
STAGES | Num of stages | 1 byte | Number of multiplexing stages, matching the Stage fields. | |
T | T | 1 bits | Set if the signal type can be terminated. | |
S | S | 1 bits | Set if the signal type can be switched. | |
TSG | TSG | 3 bits | Tributary slot granularity. | |
RES | Res | 3 bits | Reserved, set to 0. | |
PRIORITY | Priority | 1 byte | Bitmap of advertised priorities, bit 0 leftmost. |
Both sub-TLV types start with a 16-bit Type and 16-bit Length, then Signal Type (8 bits) and Num of stages (8 bits), a flags byte, and a Priority bitmap (8 bits). The flags byte holds T (can be terminated), S (can be switched), a 3-bit TSG and 3 reserved bits. T and S cannot both be 0.
TSG (tributary slot granularity) takes these values: 0 ignored (used for non-multiplexed signal types), 1 for 1.25 Gbps or 2.5 Gbps (interfaces configured for the G.798 fallback procedures), 2 for 2.5 Gbps only (such as RFC 4328 interfaces), and 3 for 1.25 Gbps only. Values 4 to 7 are reserved.
The Priority bitmap marks which of the priority levels 0 (leftmost, highest) to 7 (rightmost, lowest) are advertised, and at least one MUST be, normally priority 0. After it come one Stage field (8 bits) per multiplexing stage, ordered from the lowest-order ODU to the highest, followed by padding to keep 32-bit alignment.
Type 1 then carries, for each advertised priority, a 16-bit count of unreserved ODUj containers, padded when the number of priorities is odd. Type 2 carries a 32-bit Unreserved Bandwidth and a 32-bit MAX LSP Bandwidth per priority, in bytes per second as IEEE floating point. MAX LSP Bandwidth MUST account for the HO OPUk bit rate tolerance: (# available TSs) x (ODTUk.ts nominal bit rate) x (1 - HO OPUk bit rate tolerance).
The form has tick boxes for what a link can do with each box type, a slot size, and a count of free boxes at each importance level. Counting boxes takes less room than writing out sizes.
- 0Ignored — Used for non-multiplexed signal types.
- 11.25 Gbps / 2.5 Gbps — Interfaces configured for the G.798 fallback procedures.
- 22.5 Gbps only — Interfaces that only support 2.5 Gbps slots, such as RFC 4328 interfaces.
- 31.25 Gbps only — Interfaces configured for 1.25 Gbps slots only.
- 4-7Reserved — Not assigned.
§6Worked Examples
The non-normative examples in Section 5 show the encoding at work. On an OTU4 link with priorities 0, 2, 4 and 7 and the hierarchy ODU1->ODU2->ODU3->ODU4, the MAX LSP Bandwidth at priority 2 starts at 100 Gbps. After an ODU3 is set up at priority 2 it drops to 40 Gbps, and after an ODU2 is set up at priority 4 the lower-priority levels drop to 10 Gbps.
Other examples cover different T, S and TSG settings, two interfaces with different slot granularities (which need two ISCDs), ODUflex advertisement, single-stage and multi-stage muxing, bundled links and component links with non-homogeneous hierarchies. For ODUflex, the RFC notes that unreserved bandwidth does not show how the free slots are laid out. With 50 Gbps unreserved on link A and 10 Gbps on link B, three 10 Gbps ODUflex LSPs are certain to fit only once on B, and probably, not certainly, twice on A.
The examples show the bandwidth number shrinking as bigger boxes get booked, like a bus showing fewer big seats the more groups sit down.
§7Scalability and Compatibility
The extension does not introduce OSPF scalability issues and does not change flooding frequency. Only unreserved and MAX LSP Bandwidth for supported priorities are advertised, and fixed containers advertise a count in 16 bits instead of a bandwidth in 32 bits. Bundling component links with homogeneous hierarchies, as in RFC 4201, is RECOMMENDED to cut the data further.
Implementations MAY also support the advertisement in RFC 4203. If a node supports both methods, it MUST allow configuring which one is followed. The choice is a matter of policy, and lets nodes find peers using the same method.
The new announcements are kept small so they do not clog the network. Old and new styles can live together, and the operator picks which to use.
§8Security and IANA Registrations
The extension travels in OSPFv2 Opaque LSAs, which are not used for SPF computation or normal routing, so it has no direct effect on IP routing. Tampering with GMPLS TE LSAs could still affect the underlying optical or SONET-SDH transport. The OSPF security mechanisms in RFC 2328 apply as noted in RFC 3630, RFC 6863 analyses OSPF security, and RFC 5920 covers threats.
IANA assigned value 110, OTN-TDM capable, in the GMPLS Signaling Parameters Switching Types registry, and created a new sub-registry for OTN-TDM SCSI sub-TLV types: 0 reserved, 1 fixed containers, 2 flexible containers, with 3 to 65535 unassigned and allocated by Standards Action.
If someone faked these announcements they could confuse the optical gear, so the usual OSPF protections matter. IANA also keeps the official list of the new numbers.
§9References
[RFC3630]RFC 3630Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.October 2003[RFC4201]RFC 4201Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.October 2005[RFC4203]RFC 4203Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.October 2005[RFC4328]RFC 4328Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.January 2006[RFC7062]RFC 7062Zhang, F., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, November 2013.November 2013[RFC7096]RFC 7096Belotti, S., Grandi, P., Ceccarelli, D., Ed., Caviglia, D., and F. Zhang, "Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)", RFC 7096, January 2014.January 2014[RFC7139]RFC 7139Zhang, 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, March 2014.March 2014
[G.709-2012]ITU-T, "Interface for the optical transport network", Recommendation G.709/Y.1331, February 2012.