From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7138.txt | 2019 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2019 insertions(+) create mode 100644 doc/rfc/rfc7138.txt (limited to 'doc/rfc/rfc7138.txt') 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 (jODUk 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 + : + + Value Name Reference + --------- -------------------------- ---------- + 110 OTN-TDM capable [RFC7138] + + The same type of modification has been applied to the IANA-GMPLS-TC- + MIB at , 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 + , 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] + -- cgit v1.2.3