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