draft-ietf-ccamp-gmpls-ospf-g709v3-13.txt   rfc7138.txt 
CCAMP Working Group D. Ceccarelli, Ed. Internet Engineering Task Force (IETF) D. Ceccarelli, Ed.
Internet-Draft Ericsson Request for Comments: 7138 Ericsson
Intended status: Standards Track F. Zhang Category: Standards Track F. Zhang
Expires: June 14, 2014 Huawei Technologies ISSN: 2070-1721 Huawei Technologies
S. Belotti S. Belotti
Alcatel-Lucent Alcatel-Lucent
R. Rao R. Rao
Infinera Corporation Infinera Corporation
J. Drake J. Drake
Juniper Juniper
December 11, 2013 March 2014
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Traffic Engineering Extensions to OSPF
Control of Evolving G.709 OTN Networks for GMPLS Control of Evolving G.709 Optical Transport Networks
draft-ietf-ccamp-gmpls-ospf-g709v3-13
Abstract Abstract
This document describes Open Shortest Path First - Traffic This document describes Open Shortest Path First - Traffic
Engineering (OSPF-TE) routing protocol extensions to support Engineering (OSPF-TE) routing protocol extensions to support GMPLS
Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) control of Optical Transport Networks (OTNs) specified in ITU-T
specified in ITU-T Recommendation G.709 as published in 2012. It Recommendation G.709 as published in 2012. It extends mechanisms
extends mechanisms defined in RFC4203. defined in RFC 4203.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 14, 2014. 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 Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................4
2. OSPF-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 3 2. OSPF-TE Extensions ..............................................4
3. TE-Link Representation . . . . . . . . . . . . . . . . . . . . 5 3. TE-Link Representation ..........................................6
4. ISCD format extensions . . . . . . . . . . . . . . . . . . . . 5 4. ISCD Format Extensions ..........................................6
4.1. Switching Capability Specific Information . . . . . . . . 7 4.1. Switching Capability Specific Information ..................8
4.1.1. Switching Capability Specific Information for 4.1.1. Switching Capability Specific Information
fixed containers . . . . . . . . . . . . . . . . . . . 8 for Fixed Containers ................................9
4.1.2. Switching Capability Specific Information for 4.1.2. Switching Capability Specific Information
variable containers . . . . . . . . . . . . . . . . . 8 for Variable Containers ............................10
4.1.3. Switching Capability Specific Information - Field 4.1.3. Switching Capability Specific Information --
values and explanation . . . . . . . . . . . . . . . . 9 Field Values and Explanation .......................10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Examples .......................................................13
5.1. MAX LSP Bandwidth fields in the ISCD . . . . . . . . . . . 12 5.1. MAX LSP Bandwidth Fields in the ISCD ......................13
5.2. Example of T,S and TS granularity utilization . . . . . . 14 5.2. Example of T, S, and TS Granularity Utilization ...........17
5.2.1. Example of different TS Granularities . . . . . . . . 15 5.2.1. Example of Different TS Granularities ..............18
5.3. Example of ODUflex advertisement . . . . . . . . . . . . . 18 5.3. Example of ODUflex Advertisement ..........................20
5.4. Example of single stage muxing . . . . . . . . . . . . . . 20 5.4. Example of Single-Stage Muxing ............................22
5.5. Example of multi stage muxing - Unbundled link . . . . . . 22 5.5. Example of Multi-Stage Muxing -- Unbundled Link ...........23
5.6. Example of multi stage muxing - Bundled links . . . . . . 24 5.6. Example of Multi-Stage Muxing -- Bundled Links ............25
5.7. Example of component links with non-homogeneous 5.7. Example of Component Links with Non-Homogeneous
hierarchies . . . . . . . . . . . . . . . . . . . . . . . 25 Hierarchies ...............................................27
6. OSPFv2 scalability . . . . . . . . . . . . . . . . . . . . . . 28 6. OSPFv2 Scalability .............................................29
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Compatibility ..................................................30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations ........................................30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations ............................................31
9.1. Switching types . . . . . . . . . . . . . . . . . . . . . 30 9.1. Switching Types ...........................................31
9.2. New sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 30 9.2. New Sub-TLVs ..............................................31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Contributors ..................................................32
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 11. Acknowledgements ..............................................33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References ....................................................33
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References .....................................33
12.2. Informative References . . . . . . . . . . . . . . . . . . 34 12.2. Informative References ...................................34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
G.709 Optical Transport Network (OTN) [G.709-2012] includes new fixed G.709 ("Interfaces for the Optical Transport Network (OTN)")
and flexible ODU (Optical channel Data Unit) containers, two types of [G.709-2012] includes new fixed and flexible ODU (Optical channel
Tributary Slots (i.e., 1.25Gbps and 2.5Gbps), and supports various Data Unit) containers, includes two types of tributary slots (i.e.,
multiplexing relationships (e.g., ODUj multiplexed into ODUk (j<k)), 1.25 Gbps and 2.5 Gbps), and supports various multiplexing
two different tributary slots for ODUk (K=1, 2, 3) and ODUflex relationships (e.g., ODUj multiplexed into ODUk (j<k)), two different
service type. In order to present this information in routing, this tributary slots for ODUk (K=1, 2, 3), and the ODUflex service type.
document provides OTN technology specific encoding for use in GMPLS In order to advertise this information in routing, this document
OSPF-TE as defined in [RFC4203]. 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 For a short overview of OTN evolution and implications of OTN
requirements on GMPLS routing please refer to [OTN-FWK]. The requirements on GMPLS routing, please refer to [RFC7062]. The
information model and an evaluation against the current solution are information model and an evaluation against the current solution are
provided in [OTN-INFO]. The reader is supposed to be familiar with provided in [RFC7096]. The reader is supposed to be familiar with
both of these documents. both of these documents.
Routing information for Optical Channel Layer (OCh) (i.e., Routing information for Optical Channel (OCh) layer (i.e.,
wavelength) is beyond the scope of this document. Please refer to wavelength) is beyond the scope of this document. Please refer to
[RFC6163] and [RFC6566] for further information. [RFC6163] and [RFC6566] for further information.
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. OSPF-TE Extensions 2. OSPF-TE Extensions
In terms of GMPLS based OTN networks, each OTUk can be viewed as a In terms of GMPLS-based OTN networks, each Optical channel Transport
component link, and each component link can carry one or more types Unit-k (OTUk) can be viewed as a component link, and each component
of ODUj (j<k). link can carry one or more types of ODUj (j<k).
Each TE Link State Advertisement (LSA) can carry a top-level link Each TE-Link State Advertisement (LSA) can carry a top-level link TLV
Type Length Value (TLV) with several nested sub-TLVs to describe with several nested sub-TLVs to describe different attributes of a
different attributes of a TE link. Two top-level TLVs are defined in TE-Link. Two top-level TLVs are defined in [RFC3630]: (1) The Router
[RFC3630]. (1) The Router Address TLV (referred to as the Node TLV) Address TLV (referred to as the Node TLV) and (2) the TE-Link TLV.
and (2) the TE link TLV. One or more sub-TLVs can be nested into the One or more sub-TLVs can be nested into the two top-level TLVs. The
two top-level TLVs. The sub-TLV set for the two top-level TLVs are sub-TLV set for the two top-level TLVs are also defined in [RFC3630]
also defined in [RFC3630] and [RFC4203]. and [RFC4203].
As discussed in [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended to As discussed in [RFC7062] and [RFC7096], OSPF-TE must be extended to
be able to advertise the termination and switching capabilities of be able to advertise the termination and Switching Capabilities of
each different ODUj and ODUk/OTUk (Optical Transport Unit) and the each different ODUj and ODUk/OTUk (Optical Transport Unit) and the
advertisement of related multiplexing capabilities. These advertisement of related multiplexing capabilities. These
capabilities are carried in the Interface Switching Capability capabilities are carried in the Switching Capability specific
Descriptor (ISCD) Switching Capability-specific information field information field of the Interface Switching Capability Descriptor
using formats defined in this document. As discussed in [SWCAP- (ISCD) using formats defined in this document. As discussed in
UPDT], the use of a technology specific Switching Capability-specific [RFC7062], the use of a technology-specific Switching Capability
information field necessitates the definition of a new Switching specific information field necessitates the definition of a new
Capability value and associated new Switching Capability. Switching Capability value and associated new Switching Capability.
In the following, we will use ODUj to indicate a service type that is In the following, we will use ODUj to indicate a service type that is
multiplexed into a higher order ODU, ODUk to indicate a higher order multiplexed into a higher-order (HO) ODU, ODUk to indicate a higher-
ODU including an ODUj and ODUk/OTUk to indicate the layer mapped into order ODU including an ODUj, and ODUk/OTUk to indicate the layer
the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate ODUj mapped into the OTUk. Moreover, ODUj(S) and ODUk(S) are used to
and ODUk supporting switching capability only, and the ODUj->ODUk indicate the ODUj and ODUk supporting Switching Capability only, and
format is used to indicate the ODUj into ODUk multiplexing the ODUj->ODUk format is used to indicate the ODUj-into-ODUk
capability. multiplexing capability.
This notation can be repeated as needed depending on the number of This notation can be repeated as needed depending on the number of
multiplexing levels. In the following, the term "multiplexing tree" multiplexing levels. In the following, the term "multiplexing tree"
is used to identify a multiplexing hierarchy where the root is always is used to identify a multiplexing hierarchy where the root is always
a server ODUk/OTUk and any other supported multiplexed container is a server ODUk/OTUk and any other supported multiplexed container is
represented with increasing granularity until reaching the leaf of represented with increasing granularity until reaching the leaf of
the tree. The tree can be structured with more than one branch if the tree. The tree can be structured with more than one branch if
the server ODUk/OTUk supports more than one hierarchy. the server ODUk/OTUk supports more than one hierarchy.
For example, if a multiplexing hierarchy like the following one is For example, if a multiplexing hierarchy like the following one is
skipping to change at page 4, line 38 skipping to change at page 5, line 38
ODU2 ODU0 ODUflex ODU0 ODU2 ODU0 ODUflex ODU0
\ / \ / \ / \ /
| | | |
ODU3 ODU2 ODU3 ODU2
\ / \ /
\ / \ /
\ / \ /
\ / \ /
ODU4 ODU4
The ODU4 is the root of the muxing tree, ODU3 and ODU2 are containers the ODU4 is the root of the muxing tree; ODU3 and ODU2 are containers
directly multiplexed into the server and then ODU2, ODU0 are the directly multiplexed into the server; and ODU2 and ODU0 are the
leaves of the ODU3 branch, while ODUflex and ODU0 are the leaves of 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 the ODU2 one. This means that it is possible to have the following
multiplexing capabilities: multiplexing capabilities:
ODU2->ODU3->ODU4 ODU2->ODU3->ODU4
ODU0->ODU3->ODU4 ODU0->ODU3->ODU4
ODUflex->ODU2->ODU4 ODUflex->ODU2->ODU4
ODU0->ODU2->ODU4 ODU0->ODU2->ODU4
3. TE-Link Representation 3. TE-Link Representation
G.709 ODUk/OTUk Links are represented as TE-Links in GMPLS Traffic G.709 ODUk/OTUk links are represented as TE-Links in GMPLS Traffic
Engineering Topology for supporting ODUj layer switching. These TE- Engineering Topology for supporting ODUj layer switching. These TE-
Links can be modeled in multiple ways. Links can be modeled in multiple ways.
OTUk physical Link(s) can be modeled as a TE-Link(s). Figure 1 below OTUk physical link(s) can be modeled as a TE-Link(s). Figure 1 below
provides an illustration of one hop OTUk TE-links. provides an illustration of one-hop OTUk TE-Links.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| OTN | | OTN | | OTN | | OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch | |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C | | A | | B | | C |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|<-- TE-Link -->| |<-- TE-Link -->| |<-- TE-Link -->| |<-- TE-Link -->|
Figure 1: OTUk TE-Links Figure 1: OTUk TE-Links
It is possible to create TE-Links that span more than one hop by It is possible to create TE-Links that span more than one hop by
creating FAs between non-adjacent nodes (see Figure 2). As in the creating forwarding adjacencies (FAs) between non-adjacent nodes (see
one hop case, multiple hop TE-links advertise ODU switching capacity. Figure 2). As in the one-hop case, multiple-hop TE-Links advertise
the ODU Switching Capability.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| OTN | | OTN | | OTN | | OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch | |Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C | | A | | B | | C |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
ODUk Switched ODUk Switched
|<------------- ODUk Link ------------->| |<------------- ODUk Link ------------->|
|<-------------- TE-Link--------------->| |<-------------- TE-Link--------------->|
Figure 2: Multiple hop TE-Link Figure 2: Multiple-Hop TE-Link
4. ISCD format extensions 4. ISCD Format Extensions
The ISCD describes the switching capability of an interface and is The ISCD describes the Switching Capability of an interface and is
defined in [RFC4203]. This document defines a new Switching defined in [RFC4203]. This document defines a new Switching
Capability value for OTN [G.709-2012] as follows: Capability value for OTN [G.709-2012] as follows:
Value Type Value Type
----- ---- ----- ----
110 (TBA by IANA) OTN-TDM capable (OTN-TDM) 110 OTN-TDM capable
When supporting the extensions defined in this document, for both When supporting the extensions defined in this document, for both
fixed and flexible ODUs, the Switching Capability and Encoding values fixed and flexible ODUs, the Switching Capability and Encoding values
MUST be used as follows: MUST be used as follows:
- Switching Capability = OTN-TDM o Switching Capability = OTN-TDM
- Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
The same switching type and encoding values must be used for both 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 fixed and flexible ODUs. When Switching Capability and Encoding
fields are set to values as stated above, the Interface Switching fields are set to values as stated above, the Interface Switching
Capability Descriptor MUST be interpreted as defined in [RFC4203]. Capability Descriptor MUST be interpreted as defined in [RFC4203].
Maximum LSP Bandwidth The MAX LSP Bandwidth field is used according to [RFC4203], i.e., 0
The MAX LSP Bandwidth field is used according to [RFC4203]: i.e., 0
<= MAX LSP Bandwidth <= ODUk/OTUk, and intermediate values are those <= MAX LSP Bandwidth <= ODUk/OTUk, and intermediate values are those
on the branch of OTN switching hierarchy supported by the interface. on the branch of the OTN switching hierarchy supported by the
For example, in the OTU4 link it could be possible to have ODU4 as interface. For example, in the OTU4 link it could be possible to
MAX LSP Bandwidth for some priorities, ODU3 for others, ODU2 for some have ODU4 as MAX LSP Bandwidth for some priorities, ODU3 for others,
others, etc. The bandwidth unit is in bytes per second and the ODU2 for some others, etc. The bandwidth unit is in bytes/second and
encoding MUST be in Institute of Electrical and Electronic Engineers the encoding MUST be in IEEE floating point format. The discrete
(IEEE) floating point format. The discrete values for various ODUs values for various ODUs are shown in the table below (please note
are shown in the table below (please note that there are 1000 bits in that there are 1000 bits in a kilobit according to normal practices
a kbit according to normal practices in telecommunications). in telecommunications).
+---------------------+------------------------------+-----------------+
| ODU Type | ODU nominal bit rate |Value in Byte/Sec|
| | |(floating p. val)|
+---------------------+------------------------------+-----------------+
| ODU0 | 1,244,160 kbit/s | 0x4D1450C0 |
| ODU1 | 239/238 x 2,488,320 kbit/s | 0x4D94F048 |
| ODU2 | 239/237 x 9,953,280 kbit/s | 0x4E959129 |
| ODU3 | 239/236 x 39,813,120 kbit/s | 0x4F963367 |
| ODU4 | 239/227 x 99,532,800 kbit/s | 0x504331E3 |
| ODU2e | 239/237 x 10,312,500 kbit/s | 0x4E9AF70A |
| | | |
| ODUflex for CBR | 239/238 x client signal | MAX LSP |
| Client signals | bit rate | BANDWIDTH |
| | | |
| ODUflex for GFP-F | | MAX LSP |
|Mapped client signal | Configured bit rate | BANDWIDTH |
| | | |
| | | |
|ODU flex resizable | Configured bit rate | MAX LSP |
| | | BANDWIDTH |
+---------------------+------------------------------+-----------------+
+-------------------+-----------------------------+-----------------+
| 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 A single ISCD MAY be used for the advertisement of unbundled or
bundled links supporting homogeneous multiplexing hierarchies and the bundled links supporting homogeneous multiplexing hierarchies and the
same TS (Tributary Slot) granularity. A different ISCD MUST be used same TS (tributary slot) granularity. A different ISCD MUST be used
for each different muxing hierarchy (muxing tree in the following for each different muxing hierarchy (muxing tree in the following
examples) and different TS granularity supported within the TE Link. examples) and different TS granularity supported within the TE-Link.
When a received LSA includes a sub-TLV not formatted accordingly to When a received LSA includes a sub-TLV not formatted accordingly to
the precise specifications in this document, the problem SHOULD be the precise specifications in this document, the problem SHOULD be
logged and the wrongly formatted sub-TLV MUST NOT be used for path logged and the wrongly formatted sub-TLV MUST NOT be used for path
computation. computation.
4.1. Switching Capability Specific Information 4.1. Switching Capability Specific Information
The technology specific part of the OTN-TDM ISCD may include a The technology-specific part of the OTN-TDM ISCD may include a
variable number of sub-TLVs called Bandwidth sub-TLVs. Each sub-TLV variable number of sub-TLVs called Bandwidth sub-TLVs. Each sub-TLV
is encoded with the sub-TLV header as defined in [RFC3630] section is encoded with the sub-TLV header as defined in [RFC3630],
2.3.2. The muxing hierarchy tree MUST be encoded as an order Section 2.3.2. The muxing hierarchy tree MUST be encoded as an
independent list. Two types of Bandwidth sub-TLV are defined (TBA by order-independent list. Two types of Bandwidth sub-TLVs are defined
IANA). Note that type values are defined in this document and not in (TBA by IANA). Note that type values are defined in this document
[RFC3630]. and not in [RFC3630].
- Type 1 - Unreserved Bandwidth for fixed containers o Type 1 - Unreserved Bandwidth for fixed containers
- Type 2 - Unreserved/MAX LSP Bandwidth for flexible containers o Type 2 - Unreserved/MAX LSP Bandwidth for flexible containers
The Switching Capability-Specific Information (SCSI) MUST include one The Switching Capability specific information (SCSI) MUST include one
Type 1 sub-TLV for each fixed container and one Type 2 sub-TLV for 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 each variable container. Each container type is identified by a
Signal Type. Signal Type values are defined in [OTN-SIG]. Signal Type. Signal Type values are defined in [RFC7139].
With respect to ODUflex, three different signal types are allowed: 20 With respect to ODUflex, three different Signal Types are allowed:
- ODUflex Constant Bit Rate (CBR), 21 - ODUflex Generic Framing
Procedure-Frame mapped (GFP-F) resizable and 22 - ODUflex (GFP-F)
non-resizable. 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 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 The format of the Bandwidth sub-TLV for fixed containers is depicted
in the following figure: in the following figure:
0 1 2 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 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 | | Type = 1 (Unres-fix) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal type | Num of stages |T|S| TSG | Res | Priority | | Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding | | Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 0 | ..... | | Unreserved ODUj at Prio 0 | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 7 | Unreserved Padding | | Unreserved ODUj at Prio 7 | Unreserved Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bandwidth sub-TLV - Type 1 - Figure 3: Bandwidth Sub-TLV -- Type 1
The values of the fields shown in figure 3 are explained in section The values of the fields shown in Figure 3 are explained in
4.1.3. Section 4.1.3.
4.1.2. Switching Capability Specific Information for variable 4.1.2. Switching Capability Specific Information for Variable
containers Containers
The format of the Bandwidth sub-TLV for variable containers is The format of the Bandwidth sub-TLV for variable containers is
depicted in the following figure: depicted in the following figure:
0 1 2 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 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 | | Type = 2 (Unres/MAX-var) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal type | Num of stages |T|S| TSG | Res | Priority | | Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding | | Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 | | Unreserved Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 7 | | Unreserved Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 | | MAX LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 | | MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bandwidth sub-TLV - Type 2 - Figure 4: Bandwidth Sub-TLV -- Type 2
The values of the fields shown in figure 4 are explained in section The values of the fields shown in figure 4 are explained in
4.1.3. Section 4.1.3.
4.1.3. Switching Capability Specific Information - Field values and 4.1.3. Switching Capability Specific Information -- Field Values and
explanation Explanation
The fields in the Bandwidth sub-TLV MUST be filled as follows: The fields in the Bandwidth sub-TLV MUST be filled as follows:
- Signal Type (8 bits): Indicates the ODU type being advertised. o Signal Type (8 bits): Indicates the ODU type being advertised.
Values are defined in [OTN-SIG]. Values are defined in [RFC7139].
- Number of stages (8 bits): This field indicates the number of o Num of stages (8 bits): This field indicates the number of
multiplexing stages used to transport the indicated signal type. multiplexing stages used to transport the indicated Signal Type.
It MUST be set to the number of stages represented in the sub-TLV. It MUST be set to the number of stages represented in the sub-TLV.
- Flags (8 bits): o Flags (8 bits):
- T Flag (bit 17): Indicates whether the advertised bandwidth * T Flag (bit 17): Indicates whether the advertised bandwidth can
can be terminated. When the signal type can be terminated T be terminated. When the Signal Type can be terminated T MUST
MUST be set, while when the signal type cannot be terminated T be set, while when the Signal Type cannot be terminated T MUST
MUST be cleared. be cleared.
- S Flag (bit 18): Indicates whether the advertised bandwidth * S Flag (bit 18): Indicates whether the advertised bandwidth can
can be switched. When the signal type can be switched S MUST be switched. When the Signal Type can be switched, S MUST be
be set, while when the signal type cannot be switched S MUST be set; when the Signal Type cannot be switched, S MUST be
cleared. cleared.
The value 0 in both T and S bits MUST NOT be used. * The value 0 in both the T bit and S bit MUST NOT be used.
- TS Granularity: Tributary Slot Granularity (3 bits): Used for o TSG (3 bits): Tributary Slot Granularity. Used for the
the advertisement of the supported Tributary Slot granularity. advertisement of the supported tributary slot granularity. The
The following values MUST be used: following values MUST be used:
- 0 - Ignored * 0 - Ignored
- 1 - 1.25Gbps/2.5Gbps * 1 - 1.25 Gbps / 2.5 Gbps
- 2 - 2.5Gbps only * 2 - 2.5 Gbps only
- 3 - 1.25Gbps only * 3 - 1.25 Gbps only
- 4-7 - Reserved * 4-7 - Reserved
A value of 1 MUST be used on interfaces which are configured to A value of 1 MUST be used on interfaces that are configured to
support the fall back procedures defined in [G.798-a2]. A value support the fallback procedures defined in [G.798]. A value of 2
of 2 MUST be used on interfaces that only support 2.5Gbps time 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 slots, such as [RFC4328] interfaces. A value of 3 MUST be used on
interfaces that are configured to only support 1.25Gbps time interfaces that are configured to only support 1.25 Gbps tributary
slots. A value of 0 MUST be used for non-multiplexed signal types slots. A value of 0 MUST be used for non-multiplexed Signal Types
(i.e., a non-OTN client). (i.e., a non-OTN client).
- Res (3 bits): reserved bits. MUST be set to 0 and ignored on o Res (3 bits): Reserved bits. MUST be set to 0 and ignored on
receipt. receipt.
- Priority (8 bits): A bitmap used to indicate which priorities o Priority (8 bits): A bitmap used to indicate which priorities are
are being advertised. The bitmap is in ascending order, with the being advertised. The bitmap is in ascending order, with the
leftmost bit representing priority level 0 (i.e., the highest) and leftmost bit representing priority level 0 (i.e., the highest) and
the rightmost bit representing priority level 7 (i.e., the the rightmost bit representing priority level 7 (i.e., the
lowest). A bit MUST be set (1) corresponding to each priority lowest). A bit MUST be set (1) corresponding to each priority
represented in the sub-TLV, and MUST NOT be set (0) when the represented in the sub-TLV and MUST NOT be set (0) when the
corresponding priority is not represented. At least one priority corresponding priority is not represented. At least one priority
level MUST be advertised that, unless overridden by local policy, level MUST be advertised that, unless overridden by local policy,
SHALL be at priority level 0. SHALL be at priority level 0.
- Stage (8 bits): Each Stage field indicates a signal type in the o Stage (8 bits): Each Stage field indicates a Signal Type in the
multiplexing hierarchy used to transport the signal indicated in multiplexing hierarchy used to transport the signal indicated in
the Signal Type field. The number of Stage fields included in a the Signal Type field. The number of Stage fields included in a
sub-TLV MUST equal the value of the Number of Stages field. The 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 Stage fields MUST be ordered to match the data plane in ascending
order (from the lowest order ODU to the highest order ODU). The 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 values of the Stage field are the same as those defined for the
Signal Type field. When the Number of stage field carries a 0, Signal Type field. When the Num of stages field carries a 0, then
then the Stage and Padding fields MUST be omitted. the Stage and Padding fields MUST be omitted.
- Padding (variable): The Padding field is used to ensure the 32 * Example: For the ODU1->ODU2->OD3 hierarchy, the Signal Type
bit alignment of stage fields. The length of the Padding field is 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 always a multiple of 8 bits (1 byte). Its length can be
calculated, in bytes, as: 4 - ( "value of Number of Stages field" calculated, in bytes, as: 4 - ( "value of Num of stages field" %
% 4). The Padding field MUST be set to a zero (0) value on 4). The Padding field MUST be set to a zero (0) value on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
- Unreserved ODUj (16 bits): This field indicates the Unreserved o Unreserved ODUj (16 bits): This field indicates the Unreserved
Bandwidth at a particular priority level. This field MUST be set Bandwidth at a particular priority level. This field MUST be set
to the number of ODUs at the indicated the Signal Type for a to the number of ODUs at the indicated the Signal Type for a
particular priority level. One field MUST be present for each bit particular priority level. One field MUST be present for each bit
set in the Priority field, and is ordered to match the Priority set in the Priority field, and the fields are ordered to match the
field. Fields MUST NOT be present for priority levels that are Priority field. Fields MUST NOT be present for priority levels
not indicated in the Priority field. that are not indicated in the Priority field.
- Unreserved Padding (16 bits): The Padding field is used to o Unreserved Padding (16 bits): The Padding field is used to ensure
ensure the 32 bit alignment of Unreserved ODUj fields. When the 32-bit alignment of the Unreserved ODUj fields. When present,
present the Unreserved Padding field is 16 bits (2 byte) long. the Unreserved Padding field is 16 bits (2 bytes) long. When the
When the number of priorities is odd, the Unreserved Padding field number of priorities is odd, the Unreserved Padding field MUST be
MUST be included. When the number of priorities is even, the included. When the number of priorities is even, the Unreserved
Unreserved Padding MUST be omitted. Padding MUST be omitted.
- Unreserved Bandwidth (32 bits): This field indicates the o Unreserved Bandwidth (32 bits): This field indicates the
Unreserved Bandwidth at a particular priority level. This field Unreserved Bandwidth at a particular priority level. This field
MUST be set to the bandwidth, in Bytes/sec in IEEE floating point MUST be set to the bandwidth, in bytes/second in IEEE floating
format, available at the indicated Signal Type for a particular point format, available at the indicated Signal Type for a
priority level. One field MUST be present for each bit set in the particular priority level. One field MUST be present for each bit
Priority field, and is ordered to match the Priority field. set in the Priority field, and the fields are ordered to match the
Fields MUST NOT be present for priority levels that are not Priority field. Fields MUST NOT be present for priority levels
indicated in the Priority field. that are not indicated in the Priority field.
- Maximum LSP Bandwidth (32 bit): This field indicates the maximum o Maximum LSP Bandwidth (32 bits): This field indicates the maximum
bandwidth that can be allocated for a single LSP at a particular bandwidth that can be allocated for a single LSP at a particular
priority level. This field MUST be set to the maximum bandwidth, priority level. This field MUST be set to the maximum bandwidth,
in Bytes/sec in IEEE floating point format, available to a single in bytes/second in IEEE floating point format, available to a
LSP at the indicated Signal Type for a particular priority level. single LSP at the indicated Signal Type for a particular priority
One field MUST be present for each bit set in the Priority field, level. One field MUST be present for each bit set in the Priority
and is ordered to match the Priority field. Fields MUST NOT be field, and the fields are ordered to match the Priority field.
present for priority levels that are not indicated in the Priority Fields MUST NOT be present for priority levels that are not
field. The advertisement of the MAX LSP Bandwidth MUST take into indicated in the Priority field. The advertisement of the MAX LSP
account HO OPUk bit rate tolerance and be calculated according to Bandwidth MUST take into account HO OPUk bit rate tolerance and be
the following formula: calculated according to the following formula:
Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) * * Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) *
(1-HO OPUk bit rate tolerance) (1-HO OPUk bit rate tolerance)
5. Examples 5. Examples
The examples in the following pages are not normative and are not The examples in the following pages are not normative and are not
intended to imply or mandate any specific implementation. intended to imply or mandate any specific implementation.
5.1. MAX LSP Bandwidth fields in the ISCD 5.1. MAX LSP Bandwidth Fields in the ISCD
This example shows how the MAX LSP Bandwidth fields of the ISCD are This example shows how the MAX LSP Bandwidth fields of the ISCD are
filled accordingly to the evolving of the TE-link bandwidth filled according to the evolving of the TE-Link bandwidth occupancy.
occupancy. In the example an OTU4 link is considered, with supported In this example, an OTU4 link is considered, with supported
priorities 0,2,4,7 and muxing hierarchy ODU1->ODU2->ODU3->ODU4. priorities 0,2,4,7 and muxing hierarchy ODU1->ODU2->ODU3->ODU4.
At time T0, with the link completely free, the advertisement would At time T0, with the link completely free, the advertisement would
be: be:
0 1 2 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 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) | | SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100Gbps | | MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 | | MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 100Gbps | | MAX LSP Bandwidth at priority 2 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 | | MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 100Gbps | | MAX LSP Bandwidth at priority 4 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 | | MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 | | MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 100Gbps | | MAX LSP Bandwidth at priority 7 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information | | Switching Capability Specific Information |
| (variable length) | | (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD at T0 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 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 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 priorities from 2 to 7 (excluding the non-supported ones), the MAX
Bandwidth is equal to ODU3, as no more ODU4s are available and the LSP Bandwidth is equal to ODU3, as no more ODU4s are available and
next supported ODUj in the hierarchy is ODU3. The advertisement is the next supported ODUj in the hierarchy is ODU3. The advertisement
updated as follows: is updated as follows:
0 1 2 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 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) | | SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100Gbps | | MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 | | MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40Gbps | | MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 | | MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 40Gbps | | MAX LSP Bandwidth at priority 4 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 | | MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 | | MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 40Gbps | | MAX LSP Bandwidth at priority 7 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information | | Switching Capability Specific Information |
| (variable length) | | (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD at T1 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 is no At time T2, an ODU2 at priority 4 is set up. The first ODU3 has not
longer available since T1, as it was kept by the ODU3 LSP, while the been available since T1 as it was kept by the ODU3 LSP, while the
second is no more available and just 3 ODU2 are left in it. ODU2 is second is no longer available and just 3 ODU2s are left in it. ODU2
now the MAX LSP Bandwidth for priorities higher than 4. The is now the MAX LSP Bandwidth for priorities higher than 4. The
advertisement is updated as follows: advertisement is updated as follows:
0 1 2 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 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) | | SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100Gbps | | MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 | | MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40Gbps | | MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 | | MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 10Gbps | | MAX LSP Bandwidth at priority 4 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 | | MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 | | MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 10Gbps | | MAX LSP Bandwidth at priority 7 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information | | Switching Capability Specific Information |
| (variable length) | | (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD at T2 Figure 7: MAX LSP Bandwidth Fields in the ISCD at T2
5.2. Example of T,S and TS granularity utilization 5.2. Example of T, S, and TS Granularity Utilization
In this example, an interface with Tributary Slot Type 1.25Gbps and In this example, an interface with tributary slot type 1.25 Gbps and
fallback procedure enabled is considered (TS granularity=1). It fallback procedure enabled is considered (TS granularity=1). It
supports the simple ODU1->ODU2->ODU3 hierarchy and priorities 0 and supports the simple ODU1->ODU2->ODU3 hierarchy and priorities 0 and
3. Suppose that in this interface the ODU3 signal type can be both 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 switched or terminated, the ODU2 can only be terminated, and the ODU1
switched only. Please note that since the ODU1 is not being can only be switched. Please note that since the ODU1 is not being
advertised to support ODU0, the value of is "ignored" (TS advertised to support ODU0, the value of its TSG field is "ignored"
granularity=0). For the advertisement of the capabilities of such (TS granularity=0). For the advertisement of the capabilities of
interface, a single ISCD is used and its format is as follows: such an interface, a single ISCD is used. Its format is as follows:
0 1 2 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 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 | | 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| |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) | | Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 31 skipping to change at page 17, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 | | Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 | | 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| |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 | | Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Example 2 - TS granularity, T and S utilization Figure 8: T, S, and TS Granularity Utilization
5.2.1. Example of different TS Granularities 5.2.1. Example of Different TS Granularities
In this example, two interfaces with homogeneous hierarchies but In this example, two interfaces with homogeneous hierarchies but
different Tributary Slot Types are considered. The first one different tributary slot types are considered. The first one
supports a [RFC4328] interface (TS granularity=2) while the second supports an [RFC4328] interface (TS granularity=2) while the second
one supports G.709-2012 interface with fallback procedure disabled one supports a G.709-2012 interface with fallback procedure disabled
(TS granularity=3). Both of them support ODU1->ODU2->ODU3 hierarchy (TS granularity=3). Both support the ODU1->ODU2->ODU3 hierarchy and
and priorities 0 and 3. Suppose that in this interface the ODU3 priorities 0 and 3. Suppose that in this interface, the ODU3 Signal
signal type can be both switched or terminated, the ODU2 can only be Type can be both switched or terminated, the ODU2 can only be
terminated, and the ODU1 switched only. For the advertisement of the terminated, and the ODU1 can only be switched. For the advertisement
capabilities of such interfaces, two different ISCDs are used and the of the capabilities of such interfaces, two different ISCDs are used.
format of their SCSIs is as follows: The format of their SCSIs is as follows:
SCSI of ISCD 1 -- TS granularity=2
SCSI of ISCD 1 - TS granularity=2
0 1 2 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 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 | | 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| |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) | | Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 | | Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
skipping to change at page 16, line 32 skipping to change at page 18, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 | | Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 | | 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| |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 | | Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Example 2.1 - Different TS Granularities utilization - ISCD Figure 9: Utilization of Different TS Granularities -- ISCD 1
1
SCSI of ISCD 2 -- TS granularity=3
SCSI of ISCD 2 - TS granularity=3
0 1 2 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 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 | | 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| |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) | | Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 | | Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
skipping to change at page 17, line 32 skipping to change at page 19, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 | | Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 | | 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| |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 | | Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Example 2.1 - Different TS Granularities utilization - Figure 10: Utilization of Different TS Granularities -- ISCD 2
ISCD 2
A particular case in which hierarchies with the same muxing tree but Hierarchies with the same muxing tree but with different exported TS
with different exported TS granularity MUST be considered as non- granularity MUST be considered as non-homogenous hierarchies. This
homogenous hierarchies. This is the case in which an H-LPS and the is the case in which an H-LSP and the client LSP are terminated on
client LSP are terminated on the same egress node. What can happen the same egress node. What can happen is that a loose Explicit Route
is that a loose Explicit Route Object (ERO) is used at the hop where Object (ERO) is used at the hop where the signaled LSP is nested into
the signaled LSP is nested into the Hierarchical-LSP (H-LSP) the Hierarchical-LSP (H-LSP) (penultimate hop of the LSP).
(penultimate hop of the LSP).
In the following figure, node C receives from A a loose ERO towards In the following figure, node C receives a loose ERO from A; the ERO
node E and must choose between the ODU2 H-LSP on if1 or the one on goes towards node E, and node C must choose between the ODU2 H-LSP on
if2. In this case, the H-LSP on if1 exports a TS=1.25Gbps, and if2 a if1 or the one on if2. In this case, the H-LSP on if1 exports a
TS=2.5Gbps, the service LSP being signaled needs a 1.25Gbps tributary TS=1.25 Gbps, and the H-LSP on if2 exports a TS=2.5 Gbps; because the
slot, only the H-LSP on if1 can be used to reach node E. For further service LSP being signaled needs a 1.25 Gbps tributary slot, only the
details, please see section 4.1 of the [OTN-INFO]. H-LSP on if1 can be used to reach node E. For further details,
please see Section 3.2 of [RFC7096].
ODU0-LSP ODU0-LSP
..........................................................+ ..........................................................+
| | | |
| ODU2-H-LSP | | ODU2-H-LSP |
| +-------------------------------+ | +-------------------------------+
| | | | | |
+--+--+ +-----+ +-----+ if1 +-----+ +-----+ +--+--+ +-----+ +-----+ if1 +-----+ +-----+
| | OTU3 | | OTU3 | |---------| |---------| | | | OTU3 | | OTU3 | |---------| |---------| |
| A +------+ B +------+ C | if2 | D | | E | | A +------+ B +------+ C | if2 | D | | E |
| | | | | |---------| |---------| | | | | | | |---------| |---------| |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
... Service LSP ... Service LSP
--- H-LSP --- H-LSP
Figure 11: Example - Service LSP and H-LSP terminating on the same Figure 11: Example of Service LSP and H-LSP Terminating
node on the Same Node
5.3. Example of ODUflex advertisement 5.3. Example of ODUflex Advertisement
In this example, the advertisement of an ODUflex->ODU3 hierarchy is In this example, the advertisement of an ODUflex->ODU3 hierarchy is
shown. In case of ODUflex advertisement, the MAX LSP Bandwidth needs shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth
to be advertised and, in some cases, information about the Unreserved needs to be advertised, and in some cases, information about the
bandwidth could also be useful. The amount of Unreserved bandwidth Unreserved Bandwidth could also be useful. The amount of Unreserved
does not give a clear indication of how many ODUflex LSP can be set Bandwidth does not give a clear indication of how many ODUflex LSPs
up either at the MAX LSP Bandwidth or at different rates, as it gives can be set up either at the MAX LSP Bandwidth or at different rates,
no information about the spatial allocation of the free TSs. as it gives no information about the spatial allocation of the free
TSs.
An indication of the amount of Unreserved bandwidth could be useful An indication of the amount of Unreserved Bandwidth could be useful
during the path computation process, as shown in the following during the path computation process, as shown in the following
example. Supposing there are two TE-links (A and B) with MAX LSP example. Suppose there are two TE-Links (A and B) with MAX LSP
Bandwidth equal to 10 Gbps each. In the case where 50Gbps of Bandwidth equal to 10 Gbps each. In the case where 50 Gbps of
Unreserved Bandwidth are available on Link A, 10Gbps on Link B, and 3 Unreserved Bandwidth are available on Link A, 10 Gbps on Link B, and
ODUflex LSPs of 10 GBps each have to be restored, for sure only one 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, can be restored along Link B, and it is probable, but not certain,
that two of them can be restored along Link A. T, S and TS that two of them can be restored along Link A. The T, S, and TSG
granularity fields are not relevant to this example (filled with Xs). fields are not relevant to this example (filled with Xs).
In the case of ODUflex advertisement, the Type 2 Bandwidth sub-TLV is In the case of ODUflex advertisement, the Type 2 Bandwidth sub-TLV is
used. used.
0 1 2 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 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 | | Type = 2 (Unres/MAX-var) | Length = 72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0| Priority(8) | |S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0| Priority(8) |
skipping to change at page 19, line 47 skipping to change at page 21, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 | | MAX LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 | | MAX LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 | | MAX LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 | | MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Example 3 - ODUflex advertisement Figure 12: ODUflex Advertisement
5.4. Example of single stage muxing 5.4. Example of Single-Stage Muxing
Supposing there is 1 OTU4 component link supporting single stage Suppose there is 1 OTU4 component link supporting single-stage muxing
muxing of ODU1, ODU2, ODU3 and ODUflex, the supported hierarchy can of ODU1, ODU2, ODU3, and ODUflex, the supported hierarchy can be
be summarized in a tree as in the following figure. For sake of summarized in a tree as in the following figure. For the sake of
simplicity, we also assume that only priorities 0 and 3 are simplicity, we also assume that only priorities 0 and 3 are
supported. T, S and TS granularity fields are not relevant to this supported. The T, S, and TSG fields are not relevant to this example
example(filled with Xs). (filled with Xs).
ODU1 ODU2 ODU3 ODUflex ODU1 ODU2 ODU3 ODUflex
\ \ / / \ \ / /
\ \ / / \ \ / /
\ \/ / \ \/ /
ODU4 ODU4
and the related SCSIs as follows: The related SCSIs are as follows:
0 1 2 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 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 | | 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| |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 | | Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 44 skipping to change at page 23, line 13
| Stage#1=ODU4 | Padding (all zeros) | | Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 | | Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 | | 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| |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) | | Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100Gbps | | Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100Gbps | | Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =100Gbps | | MAX LSP Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =100Gbps | | MAX LSP Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Example 4 - Single stage muxing
5.5. Example of multi stage muxing - Unbundled link Figure 13: Single-Stage Muxing
Supposing there is 1 OTU4 component link with muxing capabilities as 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: shown in the following figure:
ODU2 ODU0 ODUflex ODU0 ODU2 ODU0 ODUflex ODU0
\ / \ / \ / \ /
| | | |
ODU3 ODU2 ODU3 ODU2
\ / \ /
\ / \ /
\ / \ /
\ / \ /
ODU4 ODU4
and supported priorities 0 and 3, the advertisement is composed by Considering only supported priorities 0 and 3, the advertisement is
the following Bandwidth sub-TLVs (T and S fields are not relevant to composed by the following Bandwidth sub-TLVs (T and S fields are not
this example and filled with Xs): relevant to this example and filled with Xs):
0 1 2 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 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 | | 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| |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 | | Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 11 skipping to change at page 25, line 11
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) | | Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 | | Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 | | 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| |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) | | Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100Gbps | | Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100Gbps | | Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =10Gbps | | MAX LSP Bandwidth at priority 0 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =10Gbps | | MAX LSP Bandwidth at priority 3 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Example 5 - Multi stage muxing - Unbundled link Figure 14: Multi-Stage Muxing -- Unbundled Link
5.6. Example of multi stage muxing - Bundled links 5.6. Example of Multi-Stage Muxing -- Bundled Links
In this example, 2 OTU4 component links with the same supported TS In this example, 2 OTU4 component links with the same supported TS
granularity and homogeneous muxing hierarchies are considered. The granularity and homogeneous muxing hierarchies are considered. The
following muxing capabilities trees are supported: following muxing capabilities trees are supported:
Component Link#1 Component Link#2 Component Link#1 Component Link#2
ODU2 ODU0 ODU2 ODU0 ODU2 ODU0 ODU2 ODU0
\ / \ / \ / \ /
| | | |
ODU3 ODU3 ODU3 ODU3
| | | |
ODU4 ODU4 ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement is Considering only supported priorities 0 and 3, the advertisement is
as follows (T, S and TS granularity fields are not relevant to this as follows (the T, S, and TSG fields are not relevant to this example
example and filled with Xs): and filled with Xs):
0 1 2 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 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 | | 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| |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 | | Unres ODU4 at Prio 0 =2 | Unres ODU4 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 25, line 39 skipping to change at page 26, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 | | 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| |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) | | Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =128 | Unres ODU0 at Prio 3 =128 | | Unres ODU0 at Prio 0 =128 | Unres ODU0 at Prio 3 =128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Example 6 - Multi stage muxing - Bundled links Figure 15: Multi-Stage Muxing -- Bundled Links
5.7. Example of component links with non-homogeneous hierarchies 5.7. Example of Component Links with Non-Homogeneous Hierarchies
In this example, 2 OTU4 component links with the same supported TS In this example, 2 OTU4 component links with the same supported TS
granularity and non-homogeneous muxing hierarchies are considered. granularity and non-homogeneous muxing hierarchies are considered.
The following muxing capabilities trees are supported: The following muxing capabilities trees are supported:
Component Link#1 Component Link#2 Component Link#1 Component Link#2
ODU2 ODU0 ODU1 ODU0 ODU2 ODU0 ODU1 ODU0
\ / \ / \ / \ /
| | | |
ODU3 ODU2 ODU3 ODU2
| | | |
ODU4 ODU4 ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement uses Considering only supported priorities 0 and 3, the advertisement uses
two different ISCDs, one for each hierarchy (T, S and TS granularity two different ISCDs, one for each hierarchy (the T, S, and TSG fields
fields are not relevant to this example and filled with Xs). In the are not relevant to this example and filled with Xs). In the
following figure, the SCSI of each ISCD is shown: following figure, the SCSI of each ISCD is shown:
SCSI of ISCD 1 - Component Link#1 SCSI of ISCD 1 -- Component Link#1
0 1 2 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 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 | | 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| |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 | | Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 27, line 41 skipping to change at page 28, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 | | 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| |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) | | Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 | | Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Example 7 - Multi stage muxing - Non-homogeneous Figure 16: Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
hierarchies - ISCD 1 ISCD 1
SCSI of ISCD 2 - Component Link#2 SCSI of ISCD 2 -- Component Link#2
0 1 2 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 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 | | 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| |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 | | Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 41 skipping to change at page 29, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 | | 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| |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) | | Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 | | Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Example 7 - Multi stage muxing - Non-homogeneous Figure 17: Multi-Stage Muxing -- Non-Homogeneous Hierarchies --
hierarchies - ISCD 2 ISCD 2
6. OSPFv2 scalability 6. OSPFv2 Scalability
This document does not introduce OSPF scalability issues with respect This document does not introduce OSPF scalability issues with respect
to existing GMPLS encoding and does not require any modification to to existing GMPLS encoding and does not require any modification to
flooding frequency. Moreover, the design of the encoding has been flooding frequency. Moreover, the design of the encoding has been
carried out taking into account bandwidth optimization, and in carried out taking into account bandwidth optimization, in
particular: particular:
- Only unreserved and MAX LSP Bandwidth related to supported o Only unreserved and MAX LSP Bandwidth related to supported
priorities are advertised priorities are advertised.
- With respect of fixed containers, only the number of available o For fixed containers, only the number of available containers is
containers is advertised instead of available bandwidth so to use advertised instead of the available bandwidth in order to use only
only 16 bits per container instead of 32 (as per former GMPLS 16 bits per container instead of 32 (as per former GMPLS
encoding encoding).
In order to further reduce the amount of data advertised it is In order to further reduce the amount of data advertised it is
RECOMMENDED to bundle component links with homogeneous hierarchies as RECOMMENDED to bundle component links with homogeneous hierarchies as
described in [RFC4201] and illustrated in Section 5.6. described in [RFC4201] and illustrated in Section 5.6.
7. Compatibility 7. Compatibility
All implementations of this document MAY also support advertisement All implementations of this document MAY also support advertisement
as defined in [RFC4328]. When nodes support both advertisement as defined in [RFC4203]. When nodes support both the advertisement
methods, implementations MUST support the configuration of which method in [RFC4203] and the one in this document, implementations
advertisement method is followed. The choice of which is used is MUST support the configuration of which advertisement method is
based on policy and beyond the scope of this document. This enables followed. The choice of which is used is based on policy and beyond
nodes following each method to identify similar supporting nodes and the scope of this document. This enables nodes following each method
compute paths using only the appropriate nodes. to identify similar supporting nodes and compute paths using only the
appropriate nodes.
8. Security Considerations 8. Security Considerations
This document extends [RFC4203]. As with[RFC4203], it specifies the This document extends [RFC4203]. As with [RFC4203], it specifies the
contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for
SPF computation or normal routing, the extensions specified here have Shortest Path First (SPF) computation or normal routing, the
no direct effect on IP routing. Tampering with GMPLS TE LSAs may extensions specified here have no direct effect on IP routing.
have an effect on the underlying transport (optical and/or SONET-SDH) Tampering with GMPLS TE LSAs may have an effect on the underlying
network. [RFC3630] notes that the security mechanisms described in transport (optical and/or Synchronous Optical Network - Synchronous
[RFC2328] apply to Opaque LSAs carried in OSPFv2. An analysis of the Digital Hierarchy (SONET-SDH) network. [RFC3630] notes that the
security of OSPF is provided in [RFC6863] and applies to the security mechanisms described in [RFC2328] apply to Opaque LSAs
extensions to OSPF as described in this document. Any new mechanisms carried in OSPFv2. An analysis of the security of OSPF is provided
developed to protect the transmission of information carried in in [RFC6863] and applies to the extensions to OSPF as described in
Opaque LSAs will also automatically protect the extensions defined in this document. Any new mechanisms developed to protect the
this document. transmission of information carried in Opaque LSAs will also
automatically protect the extensions defined in this document.
For security threats, defensive techniques, monitoring/detection/ Please refer to [RFC5920] for details on security threats; defensive
reporting of security attacks and requirements please refer to techniques; monitoring, detection, and reporting of security attacks;
[RFC5920]. and requirements.
9. IANA Considerations 9. IANA Considerations
9.1. Switching types
Upon approval of this document, IANA will make the assignment in the 9.1. Switching Types
"Switching Types" section of the "GMPLS Signaling Parameters"
registry located at IANA has made the following assignment in the "Switching Types"
http://www.iana.org/assignments/gmpls-sig-parameters: 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 Value Name Reference
--------- -------------------------- ---------- --------- -------------------------- ----------
110 (*) OTN-TDM capable (OTN-TDM) [This.I-D] 110 OTN-TDM capable [RFC7138]
(*) Suggested value
Same type of modification needs to applied to the IANA-GMPLS-TC-MIB The same type of modification has been applied to the IANA-GMPLS-TC-
at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib, MIB at <https://www.iana.org/assignments/ianagmplstc-mib>, where the
where the value: value:
OTN-TDM (110), -- Time-Division-Multiplex OTN-TDM capable OTN-TDM (110), -- Time-Division-Multiplex OTN-TDM capable
Will be added to the IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION has been added to the IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION
syntax list. syntax list.
9.2. New sub-TLVs 9.2. New Sub-TLVs
This document defines 2 new sub-TLVs that are carried in Interface This document defines 2 new sub-TLVs that are carried in Interface
Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM. Switching Capability Descriptors [RFC4203] with the Signal Type OTN-
Each sub-TLV includes a 16-bit type identifier (the T-field). The TDM. Each sub-TLV includes a 16-bit type identifier (the T-field).
same T-field values are applicable to the new sub-TLV. The same T-field values are applicable to the new sub-TLV.
Upon approval of this document, IANA will create and maintain a new
sub-registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switch
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/
ospf-traffic-eng-tlvs.xml, with the sub-TLV types as follows:
This document defines new sub-TLV types as follows: 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 Value Sub-TLV Reference
--------- -------------------------- ---------- --------- -------------------------- ----------
0 Reserved [This.I-D] 0 Reserved [RFC7138]
1 Unreserved Bandwidth for [This.I-D] 1 Unreserved Bandwidth for [RFC7138]
fixed containers fixed containers
2 Unreserved/MAX Bandwidth for [This.I-D] 2 Unreserved/MAX Bandwidth for [RFC7138]
flexible containers flexible containers
3-65535 Unassigned 3-65535 Unassigned
Types are to be assigned via Standards Action as defined in Types are to be assigned via Standards Action as defined in
[RFC5226]. [RFC5226].
10. Contributors 10. Contributors
Diego Caviglia, Ericsson Diego Caviglia
Ericsson
Via E.Melen, 77 - Genova - Italy Via E. Melen, 77
Genova
Email: diego.caviglia@ericsson.com 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 Dan Li
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
EMail: danli@huawei.com
EMail: lyong@ciena.com Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
EMail: pietro_vittorio.grandi@alcatel-lucent.com
Ashok Kunjidhapatham Khuzema Pithewan
Infinera Corporation
140 Caspian CT.
Sunnyvale, CA
USA
EMail: kpithewan@infinera.com
akunjidhapatham@infinera.com Xiaobing Zi
Huawei Technologies
EMail: zixiaobing@huawei.com
Snigdho Bardalai Francesco Fondelli
Ericsson
EMail: francesco.fondelli@ericsson.com
sbardalai@infinera.com Marco Corsi
EMail: corsi.marco@gmail.com
Steve Balls Eve Varma
Alcatel-Lucent
EMail: eve.varma@alcatel-lucent.com
Steve.Balls@metaswitch.com Jonathan Sadler
Tellabs
EMail: jonathan.sadler@tellabs.com
Lyndon Ong
Ciena
EMail: lyong@ciena.com
Jonathan Hardwick Ashok Kunjidhapatham
Jonathan.Hardwick@metaswitch.com EMail: akunjidhapatham@infinera.com
Xihua Fu Snigdho Bardalai
EMail: sbardalai@infinera.com
fu.xihua@zte.com.cn Steve Balls
EMail: Steve.Balls@metaswitch.com
Cyril Margaria Jonathan Hardwick
EMail: Jonathan.Hardwick@metaswitch.com
cyril.margaria@nsn.com Xihua Fu
EMail: fu.xihua@zte.com.cn
Malcolm Betts Cyril Margaria
EMail: cyril.margaria@nsn.com
Malcolm.betts@zte.com.cn Malcolm Betts
EMail: Malcolm.betts@zte.com.cn
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Fred Gruman and Lou Berger for the The authors would like to thank Fred Gruman and Lou Berger for their
precious comments and suggestions. valuable comments and suggestions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [G.709-2012] ITU-T, "Interface for the optical transport network",
Requirement Levels", BCP 14, RFC 2119, March 1997. Recommendation G.709/Y.1331, February 2012.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
(TE) Extensions to OSPF Version 2", RFC 3630, Requirement Levels", BCP 14, RFC 2119, March 1997.
September 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
of Generalized Multi-Protocol Label Switching (GMPLS)", in MPLS Traffic Engineering (TE)", RFC 4201, October
RFC 4203, October 2005. 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
Switching (GMPLS) Signaling Extensions for G.709 Optical of Generalized Multi-Protocol Label Switching (GMPLS)",
Transport Networks Control", RFC 4328, January 2006. 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 12.2. Informative References
[OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework [G.798] ITU-T, "Characteristics of optical transport network
for GMPLS and PCE Control of G.709 Optical Transport hierarchy equipment functional blocks", Recommendation
networks, work in progress G.798, December 2012.
draft-ietf-ccamp-gmpls-g709-framework-13", June 2013.
[OTN-INFO] [G.805] ITU-T, "Generic functional architecture of transport
S.Belotti, P.Grandi, D.Ceccarelli, D.Caviglia, F.Zhang, networks", Recommendation G.805, March 2000.
D.Li, "Information model for G.709 Optical Transport
Networks (OTN), work in progress
draft-ietf-ccamp-otn-g709-info-model-09", June 2013.
[OTN-SIG] F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
"Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Extensions for the evolving G.709 Optical
Transport Networks Control, work in progress
draft-ietf-ccamp-gmpls-signaling-g709v3-11", June 2013.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Networks", RFC 5920, July 2010.
May 2008.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
Networks", RFC 5920, July 2010. GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163,
April 2011.
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for [RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A
GMPLS and Path Computation Element (PCE) Control of Framework for the Control of Wavelength Switched Optical
Wavelength Switched Optical Networks (WSONs)", RFC 6163, Networks (WSONs) with Impairments", RFC 6566, March
April 2011. 2012.
[RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
Framework for the Control of Wavelength Switched Optical According to the Keying and Authentication for Routing
Networks (WSONs) with Impairments", RFC 6566, March 2012. Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security [RFC7062] Zhang, F., Li, D., Li, H., Belotti, S., and D.
According to the Keying and Authentication for Routing Ceccarelli, "Framework for GMPLS and PCE Control of
Protocols (KARP) Design Guide", RFC 6863, March 2013. G.709 Optical Transport Networks", RFC 7062, November
2013.
[SWCAP-UPDT] [RFC7096] Belotti, S., Grandi, P., Ceccarelli, D., Ed., Caviglia,
F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework D., and F. Zhang, "Evaluation of Existing GMPLS Encoding
for GMPLS and PCE Control of G.709 Optical Transport against G.709v3 Optical Transport Networks (OTNs)", RFC
networks, work in progress 7096, January 2014.
draft-ietf-ccamp-gmpls-g709-framework-13", June 2013.
[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 Authors' Addresses
Daniele Ceccarelli (editor) Daniele Ceccarelli (editor)
Ericsson Ericsson
Via E.Melen 77 Via E.Melen 77
Genova - Erzelli Genova - Erzelli
Italy Italy
Email: daniele.ceccarelli@ericsson.com EMail: daniele.ceccarelli@ericsson.com
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District Bantian, Longgang District
Phone: +86-755-28972912 Shenzhen 518129
P.R. China
Email: zhangfatai@huawei.com Phone: +86-755-28972912
EMail: zhangfatai@huawei.com
Sergio Belotti Sergio Belotti
Alcatel-Lucent Alcatel-Lucent
Via Trento, 30 Via Trento, 30
Vimercate Vimercate
Italy Italy
Email: sergio.belotti@alcatel-lucent.com EMail: sergio.belotti@alcatel-lucent.com
Rajan Rao Rajan Rao
Infinera Corporation Infinera Corporation
140, Caspian CT. 140, Caspian CT.
Sunnyvale, CA-94089 Sunnyvale, CA-94089
USA USA
Email: rrao@infinera.com EMail: rrao@infinera.com
John E Drake John E. Drake
Juniper Juniper
Email: jdrake@juniper.net EMail: jdrake@juniper.net
 End of changes. 204 change blocks. 
537 lines changed or deleted 546 lines changed or added

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