CCAMP Working Group D. Ceccarelli, Ed.
Internet-Draft D. Caviglia
Intended status: Standards Track Ericsson
Expires: July 12, 2013 F. Zhang
D. Li
Huawei Technologies
S. Belotti
P. Grandi
Alcatel-Lucent
R. Rao
K. Pithewan
Infinera Corporation
J. Drake
Juniper
January 8, 2013
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS)
Control of Evolving G.709 OTN Networks
draft-ietf-ccamp-gmpls-ospf-g709v3-05
Abstract
ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and
flexible Optical Data Unit (ODU) containers, enabling optimized
support for an increasingly abundant service mix.
This document describes Open Shortest Path First - Traffic
Engineering (OSPF-TE) routing protocol extensions to support
Generalized MPLS (GMPLS) control of all currently defined ODU
containers, in support of both sub-lambda and lambda level routing
granularity.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Ceccarelli, et al. Expires July 12, 2013 [Page 1]
Internet-Draft OSPF-TE extensions for OTN support January 2013
This Internet-Draft will expire on July 12, 2013.
Copyright Notice
Copyright (c) 2013 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. Expires July 12, 2013 [Page 2]
Internet-Draft OSPF-TE extensions for OTN support January 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. OSPF-TE Extensions . . . . . . . . . . . . . . . . . . . . . . 4
3. TE-Link Representation . . . . . . . . . . . . . . . . . . . . 6
4. ISCD format extensions . . . . . . . . . . . . . . . . . . . . 7
4.1. Switch Capability Specific Information . . . . . . . . . . 8
4.1.1. Switch Capability Specific Information for fixed
containers . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Switch Capability Specific Information for
variable containers . . . . . . . . . . . . . . . . . 9
4.1.3. Switch Capability Specific Information - Field
values and explanation . . . . . . . . . . . . . . . . 10
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. MAX LSP Bandwidth fields in the ISCD . . . . . . . . . . . 13
5.2. Example of T,S and TSG utilization . . . . . . . . . . . . 15
5.2.1. Example of different TSGs . . . . . . . . . . . . . . 16
5.3. Example of ODUflex advertisement . . . . . . . . . . . . . 18
5.4. Example of single stage muxing . . . . . . . . . . . . . . 20
5.5. Example of multi stage muxing - Unbundled link . . . . . . 22
5.6. Example of multi stage muxing - Bundled links . . . . . . 24
5.7. Example of component links with non homogeneous
hierarchies . . . . . . . . . . . . . . . . . . . . . . . 25
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Ceccarelli, et al. Expires July 12, 2013 [Page 3]
Internet-Draft OSPF-TE extensions for OTN support January 2013
1. Introduction
G.709 Optican Transport Network (OTN) [G.709-2012] includes new fixed
and flexible ODU containers, two types of Tributary Slots (i.e.,
1.25Gbps and 2.5Gbps), and supports various multiplexing
relationships (e.g., ODUj multiplexed into ODUk (j<k)), two different
tributary slots for ODUk (K=1, 2, 3) and ODUflex service type, which
is being standardized in ITU-T. In order to present this information
in the routing process, this document provides OTN technology
specific encoding for OSPF-TE.
For a short overview of OTN evolution and implications of OTN
requirements on GMPLS routing please refer to [OTN-FWK]. The
information model and an evaluation against the current solution are
provided in [OTN-INFO].
The routing information for Optical Channel Layer (OCh) (i.e.,
wavelength) is out of 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 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
Type Lenght Value (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 [OTN-FWK] and [OTN-INFO], OSPF-TE must be extended so
to be able to advertise the termination and switching capabilites
related to each different ODUj and ODUk/OTUk (Optical Transport Unit)
and the advertisement of related multiplexing capabilities. This
leads to the need to define a new Switching Capability value and
associated new Switching Capability for the Interface Switching
Capability Descriptor (ISCD).
Ceccarelli, et al. Expires July 12, 2013 [Page 4]
Internet-Draft OSPF-TE extensions for OTN support January 2013
In the following we will use ODUj to indicate a service type that is
multiplexed into an higher order 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 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.
If for example 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 then ODU2, ODU0 are the
leaves of the ODU3 branch, while ODUflex and ODU0 are the leaves of
the ODU2 one. This means that on this traffic card it is possible to
have the following multiplexing capabilities:
ODU2->ODU3->ODU4
ODU0->ODU3->ODU4
ODUflex->ODU2->ODU4
ODU0->ODU2->ODU4
Ceccarelli, et al. Expires July 12, 2013 [Page 5]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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). The TE-Link is
refferd to as OTUk-TE-Link. The OTUk-TE-Link advertises ODUj
switching capacity. The advertised capacity could include ODUk
switching capacity. Figure-1 below provides an illustration of one
hop ODUk TE-links.
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
|<-- TE-Link -->| |<-- TE-Link -->|
Figure 1: ODUk TE-Links
It is possible to create TE-Links that span more than one hop by
creating FA between non-adjacent nodes. Such TE-Links are also
termed ODUk-TE-Links. As in the one hop case, these types of ODUk-
TE-Links also advertise ODUj switching capacity. The advertised
capacity could include ODUk switching capacity.
+-------+ +-------+ +-------+
| 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
Ceccarelli, et al. Expires July 12, 2013 [Page 6]
Internet-Draft OSPF-TE extensions for OTN support January 2013
4. ISCD format extensions
The ISCD describes the switching capability of an interface
[RFC4202]. This document defines a new Switching Capability value
for OTN [G.709-2012] as follows:
Value Type
----- ----
110 (TBA by IANA) OTN-TDM capable (OTN-TDM)
When supporting the extensions defined in this document, the
Switching Capability and Encoding values MUST be used as follows:
- Switching Capability = OTN-TDM
- Encoding Type = G.709 ODUk (Digital Path) [as defined in RFC4328]
Both for fixed and flexible ODUs the same switching type and encoding
values MUST be used. 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].
Maximum LSP Bandwidth
The MAX LSP bandwidth field MUST be used according to [RFC4203]: i.e.
0 <= Max LSP Bandwidth <= ODUk/OTUk and intermediate values are those
on the branch of OTN switching hierarchy supported by the interface.
E.g. 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 MUST be in bytes per second and the encoding
MUST be in Institute of Electrical and Electronic Engineers (IEEE)
floating point format. The discrete values for various ODUs is shown
in the table below.
Ceccarelli, et al. Expires July 12, 2013 [Page 7]
Internet-Draft OSPF-TE extensions for OTN support January 2013
+---------------------+------------------------------+-----------------+
| ODU Type | ODU nominal bit rate |Value in Byte/Sec|
+---------------------+------------------------------+-----------------+
| ODU0 | 1 244 160 kbits/s | 0x4D1450C0 |
| ODU1 | 239/238 x 2 488 320 kbit/s | 0x4D94F048 |
| ODU2 | 239/237 x 9 953 280 kbit/s | 0x4E959129 |
| ODU3 | 239/236 x 39 813 120 kbit/s | 0X4F963367 |
| ODU4 | 239/227 x 99 532 800 kbit/s | 0x504331E3 |
| ODU2e | 239/237 x 10 312 500 kbit/s | 0x4E9AF70A |
| | | |
| ODUflex for CBR | | MAX LSP |
| Client signals | 239/238 x client signal | BANDWIDTH |
| | bit rate | |
| ODUflex for GFP-F | | MAX LSP |
|Mapped client signal | Configured bit rate | BANDWIDTH |
| | | |
| | | |
|ODU flex resizable | Configured bit rate | MAX LSP |
| | | BANDWIDTH |
+---------------------+------------------------------+-----------------+
A single ISCD MAY be used for the advertisement of unbundled or
bundled links supporting homogeneous multiplexing hierarchies and the
same Tributary Slot Granularity (TSG). A different ISCD MUST be used
for each different muxing hierarchy (muxing tree in the following
examples) and different TSG supported within the TE Link.
Component links with different hierarchies or TSG MUST NOT be
bundled.
4.1. Switch Capability Specific Information
The technology specific part of the OTN ISCD may include a variable
number of sub-TLVs called Bandwidth sub-TLVs. Each sub-TLV is
encoded with the 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 TLV are defined (TBA by IANA):
- Type 1 - Unreserved Bandwidth for fixed containers
- Type 2 - Unreserved/MAX LSP Bandwidth for flexible containers
The SCSI MUST include one Type 1 sub-TLV for any fixed container and
one Type 2 sub-TLV for any variable container.
With respect to ODUflex, ODUflex Constant Bit Rate (CBR) and ODUflex
Generig Framing Procedure-Frame mapped (GFP-F) MUST always be
Ceccarelli, et al. Expires July 12, 2013 [Page 8]
Internet-Draft OSPF-TE extensions for OTN support January 2013
advertised in separate TLVs as they use different adaptation
functions [G.805]. In the case both GFP-F resizable and non
resizable (i.e. 21 and 22) are supported, Signal Type 21 implicitely
supports also signal Signal Type 22, so only Signal Type 21 MUST be
advertised. Signal Type 22 MUST be used only for non resizable
resources.
4.1.1. Switch Capability Specific Information for fixed containers
The format of the Bandwidth 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 TLV - Type 1 -
The values of the fields shown in figure 4 are explained in section
4.1.3.
4.1.2. Switch Capability Specific Information for variable containers
The format of the Bandwidth TLV for variable containers is depicted
in the following figure:
Ceccarelli, et al. Expires July 12, 2013 [Page 9]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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 TLV - Type 2 -
The values of the fields shown in figure 4 are explained in section
4.1.3.
4.1.3. Switch Capability Specific Information - Field values and
explanation
The fields in the Bandwidth TLV MUST be filled as follows:
- Signal Type (8 bits): Indicates the ODU type being advertised.
Values are defined in [OTN-SIG].
- Number 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 TLV.
- 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.
Ceccarelli, et al. Expires July 12, 2013 [Page 10]
Internet-Draft OSPF-TE extensions for OTN support January 2013
- S Flag (bit 18): Indicates whether the advertised bandwidth
can be switched. When the signal type can be switched S MUST
be set, while when the signal type cannot be switched S MUST be
cleared.
The value 0 in both T and S bits MUST NOT be used.
- TSG: Tributary Slot Granularity (3 bits): Used for the
advertisement of the supported Tributary Slot granularity. The
following values MUST be used:
- 0 - Ignored
- 1 - 1.25 Gbps/2.5Gbps
- 2 - 2.5 Gbps only
- 3 - 1.25 Gbps only
- 4-7 - Reserved
Value 1 MUST be used on those interfaces where the fallback
procedure is enabled and the default value of 1.25 Gbps can be
falled back to 2.5 if needed. Value 2 MUST be used on [RFC4328]
interfaces while value 3 MUST be used on [G.709-2012] interfaces
where the fallback procedure is unsupported/disabled. Value 0
MUST be used for non multiplexed signal (i.e. non OTN client).
- Res (3 bits): reserved bits. MUST be set to 0 and ignored on
receipt.
- Priority (8 bits): field with 1 flag for each priority. A bit
MUST be set (1) for each corresponding priority represented in the
TLV and MUST NOT be set (0) when the related priority is not
represented. At least one priority level MUST be advertised. A
value of zero (0) MUST be used when not overridden by local
policy.
- Stage (8 bits): Each Stage field indicates the signal type
beloning to the muxing branch used to transport the signal
indicated in the Signal Type field. The number of Stage fields
included in a TLV MUST equal the value of the Number 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 fields MUST be the same ones
defined for the Signal Type field. If the number of stages is 0,
then the Stage and Padding fields MUST be omitted.
Ceccarelli, et al. Expires July 12, 2013 [Page 11]
Internet-Draft OSPF-TE extensions for OTN support January 2013
- 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 Number of Stages field".
When present, the Padding field MUST be set to a zero (0) value on
transmission and MUST be ignored on receipt.
- 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 is ordered to match the Priority
field. Fields MUST not be present for priority levels that are
not indicated in the Priority field.This field is REQUIRED for
Type 1 (fixed container) TLVs, and MUST NOT be used for Type 2
TLVs.
Unreserved Padding (variable): The Padding field is used to ensure
the 32 bit alignment of Unreserved ODUj fields. The length of the
Unreserved Padding field is always a multiple of 16 bits (2 byte).
Its length can be calculated, in multiple of 2 bytes, as: "number
of priorities indicated in Priorities field" % 2 . When present,
the Unreserved Padding field MUST be set to a zero (0) value on
transmission and MUST be ignored on receipt.
- Maximum LSP Bandwidth (32 bit): 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 bits/s 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
is ordered to match the Priority field. Fields MUST not be
present for priority levels that are not indicated in the Priority
field. This field is REQUIRED for Type 2 (variable container)
TLVs, and MUST NOT be used for Type 1 TLVs. 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 TS) * (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.
Ceccarelli, et al. Expires July 12, 2013 [Page 12]
Internet-Draft OSPF-TE extensions for OTN support January 2013
5.1. MAX LSP Bandwidth fields in the ISCD
This example shows how the MAX LSP Bandwidth fields of the ISCD are
filled accordingly to the evolving of the TE-link bandwidth
occupancy. In the example an OTU4 link is considered, with supported
priorities 0,2,4,7 and muxing hierarchy ODU1->ODU2->ODU3->ODU4.
At time T0, with the link completely free, the advertisement would
be:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 0 = 100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 = 100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 = 100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 = 100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switch Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example 1 - MAX LSP Bandwidth fields in the ISCD @T0
At time T1 an ODU3 at priority 2 is set-up, so for priority 0 the MAX
LSP Bandwidth is still equal to the ODU4 bandwidth, while for
priorities from 2 to 7 (excluding the non supported ones) the MAX LSP
Bandwidth is equal to ODU3, as no more ODU4s are available and the
next supported ODUj in the hierarchy is ODU3.The advertisement is
updated as follows:
Ceccarelli, et al. Expires July 12, 2013 [Page 13]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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 = 100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 = 40Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 = 40Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 = 40Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switch Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example 1 - MAX LSP Bandwidth fields in the ISCD @T1
At time T2 an ODU2 at priority 4 is set-up. The first ODU3 is no
longer available since T1 as it was kept by the ODU3 LSP, while the
second is no more available and just 3 ODU2 are left in it. ODU2 is
now the MAX LSP bandwidth for priorities higher than 4. The
advertisement is updated as follows:
Ceccarelli, et al. Expires July 12, 2013 [Page 14]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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 = 100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 2 = 40Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 4 = 10Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth at priority 7 = 10Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switch Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Example 1 - MAX LSP Bandwidth fields in the ISCD @T2
5.2. Example of T,S and TSG utilization
In this example an interface with Tributary Slot Type 1.25 Gbps and
fallback procedure enabled is considered (TSG=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 switched
only. For the advertisement of the capabilities of such interface a
single ISCD is used and its format is as follows:
Ceccarelli, et al. Expires July 12, 2013 [Page 15]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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 |T0|S1|001| Res |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 |T1|S0|001| Res |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 |T1|S1|001| Res |1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Example 2 - TSG, T and S utilization
5.2.1. Example of different TSGs
In this example two interfaces with homogeneous hierarchies but
different Tributary Slot Types are considered. The first one
supports a [RFC4328] interface (TSG=2) while the second one a G.709-
2012 interface with fallback procedure disabled (TSG=3). Both of
them support ODU1->ODU2->ODU3 hierarchy and priorities 0 and 3. T
and S bits values are not relevant to this example. For the
advertisement of the capabilities of such interfaces two different
ISCDs are used and the format of their SCSIs is as follows:
Ceccarelli, et al. Expires July 12, 2013 [Page 16]
Internet-Draft OSPF-TE extensions for OTN support January 2013
SCSI of ISCD 1 - TSG=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 |T|S| 2 |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCSI of ISCD 2 - TSG=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 |T|S| 3 |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Example 2.1 - Different TSGs utilization
A particular case in which hierarchies with the same muxing tree but
with different exported TSG MUST be considered as non homogenous
hierarchies is the case in which an H-LPS 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 from A a loose ERO towards
node E and must choose between the ODU2 H-LSP on if1 or the one on
if2. In case the H-LSP on if1 exports a TS=1.25Gbps and if2 a
TS=2.5Gbps and the service LSP being signaled needs a 1.25Gbps
tributary slot, only the H-LSP on if1 can be used to reach node E.
For further details please see section 4.1 of the [OTN-INFO].
Ceccarelli, et al. Expires July 12, 2013 [Page 17]
Internet-Draft OSPF-TE extensions for OTN support January 2013
ODU0-LSP
..........................................................+
| |
| ODU2-H-LSP |
| +-------------------------------+
| | |
+--+--+ +-----+ +-----+ if1 +-----+ +-----+
| | OTU3 | | OTU3 | |---------| |---------| |
| A +------+ B +------+ C | if2 | D | | E |
| | | | | |---------| |---------| |
+-----+ +-----+ +-----+ +-----+ +-----+
... Service LSP
--- H-LSP
Figure 10: Example - 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 case of ODUflex advertisement the MAX LSP bandwidth needs
to be advertised and in some cases also information about the
Unreserved bandwidth could be useful. The amount of Unreserved
bandwidth does not give a clear indication of how many ODUflex LSP
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. Supposing there are two TE-links (A and B) with MAX LSP
Bandwidth equal to 10 Gbps each. In case 50Gbps of Unreserved
Bandwidth are available on Link A, 10Gbps 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 sure) that two of
them can be restored along Link A. T, S and TSG fields are not
relevant to this example.
In the case of ODUflex advertisement the Type 2 Bandwidth TLV is
used.
Ceccarelli, et al. Expires July 12, 2013 [Page 18]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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 |T|S| TSG |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 11: Example 3 - ODUflex advertisement
Ceccarelli, et al. Expires July 12, 2013 [Page 19]
Internet-Draft OSPF-TE extensions for OTN support January 2013
5.4. Example of single stage muxing
Supposing 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 sake of
simplicity we assume that also in this case only priorities 0 and 3
are supported. T, S and TSG fields are not relevant to this example.
ODU1 ODU2 ODU3 ODUflex
\ \ / /
\ \ / /
\ \/ /
ODU4
and the related SCSIs as follows:
Ceccarelli, et al. Expires July 12, 2013 [Page 20]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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 |T|S| TSG |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 |T|S| TSG |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 |T|S| TSG |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 |T|S| TSG |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |T|S| TSG |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ceccarelli, et al. Expires July 12, 2013 [Page 21]
Internet-Draft OSPF-TE extensions for OTN support January 2013
Figure 12: Example 4 - Single stage muxing
5.5. Example of multi stage muxing - Unbundled link
Supposing there is 1 OTU4 component link with muxing capabilities as
shown in the following figure:
ODU2 ODU0 ODUflex ODU0
\ / \ /
| |
ODU3 ODU2
\ /
\ /
\ /
\ /
ODU4
and supported pririties 0 and 3, the advertisement is composed by the
following Bandwidth TLVs (T, S and TSG fields are not relevant to
this example):
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 |T|S| TSG |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 |T|S| TSG | Res |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 |T|S|0 0 0| Res |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 |
Ceccarelli, et al. Expires July 12, 2013 [Page 22]
Internet-Draft OSPF-TE extensions for OTN support January 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |T|S|0 0 0| Res |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 |T|S| TSG |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 |T|S| TSG |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.type=ODUflex | #stages= 2 |T|S| TSG |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 =100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =10Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =10Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Example 5 - Multi stage muxing - Unbundled link
Ceccarelli, et al. Expires July 12, 2013 [Page 23]
Internet-Draft OSPF-TE extensions for OTN support January 2013
5.6. Example of multi stage muxing - Bundled links
In this example 2 OTU4 component links with the same supported TSG
and homogeneous muxing hierarchies are considered. The following
muxing capabilities trees are supported:
Component Link#1 Component Link#2
ODU2 ODU0 ODU2 ODU0
\ / \ /
| |
ODU3 ODU3
| |
ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement is
as follows (T, S and TSG fields are not relevant to this example):
Ceccarelli, et al. Expires July 12, 2013 [Page 24]
Internet-Draft OSPF-TE extensions for OTN support January 2013
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 |T|S| TSG |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 |T|S| TSG |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 |T|S| TSG |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 |T|S| TSG |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 14: Example 6 - Multi stage muxing - Bundled links
5.7. Example of component links with non homogeneous hierarchies
In this example 2 OTU4 component links with the same supported TSG
and non homogeneous muxing hierarchies are considered. The following
muxing capabilities trees are supported:
Ceccarelli, et al. Expires July 12, 2013 [Page 25]
Internet-Draft OSPF-TE extensions for OTN support January 2013
Component Link#1 Component Link#2
ODU2 ODU0 ODU1 ODU0
\ / \ /
| |
ODU3 ODU2
| |
ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement uses
two different ISCDs, one for each hierarchy (T, S and TSG fields are
not relevant to this example). 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 |T|S| TSG |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 |T|S| TSG |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 |T|S| TSG |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 |T|S| TSG |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ceccarelli, et al. Expires July 12, 2013 [Page 26]
Internet-Draft OSPF-TE extensions for OTN support January 2013
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |T|S| TSG |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 |T|S| TSG | Res |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 |T|S| TSG |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 |T|S| TSG |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 15: Example 7 - Multi stage muxing - Non homogeneous
hierarchies
6. Compatibility
All implementations of this document MAY support also advertisement
as defined in [RFC4328]. When nodes support both advertisement
Ceccarelli, et al. Expires July 12, 2013 [Page 27]
Internet-Draft OSPF-TE extensions for OTN support January 2013
methods, implementations MUST support the configuration of which
advertisement method is followed. The choice of which is used is
based on policy and is out of scope of the document. This enables
nodes following each method to identify similar supporting nodes and
compute paths using only the appropriate nodes.
7. Security Considerations
This document, as [RFC4203], specifies the contents of Opaque LSAs in
OSPFv2. As Opaque LSAs are not used for 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 SONET-SDH) network. [RFC3630]
suggests mechanisms such as [RFC2154] to protect the transmission of
this information, and those or other mechanisms should be used to
secure and/or authenticate the information carried in the Opaque
LSAs.
For security threats, defensive techniques, monitoring/detection/
reporting of security attacks and requirements please refer to
[RFC5920] .
8. IANA Considerations
Upon approval of this document, IANA will make the assignment in the
"Switching Types" section of the "GMPLS Signaling Parameters"
registry located at
http://www.iana.org/assignments/gmpls-sig-parameters:
Value Type Reference
--------- -------------------------- ----------
110 (*) OTN-TDM capable (OTN-TDM) [This.I-D]
(*) Suggested value
This document defines 2 new TLVs that are carried in Interface
Switching Capability Descriptors [RFC4203] with Signal Type OTN-TDM.
Each TLV includes a 16-bit type identifier (the T-field). The same
T-field values are applicable to the new sub-TLV.
Upon approval of this document, IANA will create and maintain a new
registry, the "sub-TLVs of the OTN-TDM Interface Switching Capability
Descriptor TLV" registry under the "Open Shortest Path First (OSPF)
Traffic Engineering TLVs" registry, see http://www.iana.org/
Ceccarelli, et al. Expires July 12, 2013 [Page 28]
Internet-Draft OSPF-TE extensions for OTN support January 2013
assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xml, with the
TLV types as follows:
- TLV Type (T-field value)
- TLV Name
- Whether allowed on ISCD sub-TLV
This document defines new TLV types as follows:
- TLV Type = 1
- TLV Name = Unreserved Bandwidth for fixed containers
- allowed on ISCD sub-TLV
- TLV Type = 2
- TLV Name = Unreserved Bandwidth for fixed containers
- allowed on ISCD sub-TLV
New TLV type values may be allocated only by an IETF Consensus
action. The request Registration Procedures are Standards Action.
9. Contributors
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
Ceccarelli, et al. Expires July 12, 2013 [Page 29]
Internet-Draft OSPF-TE extensions for OTN support January 2013
Jonathan Sadler, Tellabs
EMail: jonathan.sadler@tellabs.com
Lyndon Ong, Ciena
EMail: lyong@ciena.com
Ashok Kunjidhapatham
akunjidhapatham@infinera.com
Snigdho Bardalai
sbardalai@infinera.com
Steve Balls
Steve.Balls@metaswitch.com
Jonathan Hardwick
Jonathan.Hardwick@metaswitch.com
Xihua Fu
fu.xihua@zte.com.cn
Cyril Margaria
cyril.margaria@nsn.com
Ceccarelli, et al. Expires July 12, 2013 [Page 30]
Internet-Draft OSPF-TE extensions for OTN support January 2013
Malcolm Betts
Malcolm.betts@zte.com.cn
10. Acknowledgements
The authors would like to thank Fred Gruman and Lou Berger for the
precious comments and suggestions.
11. References
11.1. Normative References
[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.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
11.2. Informative References
[G.709-2012]
ITU-T, "Draft revised G.709, version 4", consented
by ITU-T in 2012.
[OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework
for GMPLS and PCE Control of G.709 Optical Transport
networks, work in progress
draft-ietf-ccamp-gmpls-g709-framework-11", November 2012.
[OTN-INFO]
Ceccarelli, et al. Expires July 12, 2013 [Page 31]
Internet-Draft OSPF-TE extensions for OTN support January 2013
S.Belotti, P.Grandi, D.Ceccarelli, D.Caviglia, F.Zhang,
D.Li, "Information model for G.709 Optical Transport
Networks (OTN), work in progress
draft-ietf-ccamp-otn-g709-info-model-05", November 2012.
[OTN-SIG] F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan,
"Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Extensions for the evolving G.709 Optical
Transport Networks Control, work in progress
draft-ietf-ccamp-gmpls-signaling-g709v3-05",
November 2012.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
[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.
Authors' Addresses
Daniele Ceccarelli (editor)
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: diego.caviglia@ericsson.com
Ceccarelli, et al. Expires July 12, 2013 [Page 32]
Internet-Draft OSPF-TE extensions for OTN support January 2013
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Dan Li
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Shenzhen 518129 P.R.China Bantian, Longgang District
Phone: +86-755-28973237
Email: danli@huawei.com
Sergio Belotti
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: sergio.belotti@alcatel-lucent.com
Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: pietro_vittorio.grandi@alcatel-lucent.com
Rajan Rao
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: rrao@infinera.com
Ceccarelli, et al. Expires July 12, 2013 [Page 33]
Internet-Draft OSPF-TE extensions for OTN support January 2013
Khuzema Pithewan
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: kpithewan@infinera.com
John E Drake
Juniper
Email: jdrake@juniper.net
Ceccarelli, et al. Expires July 12, 2013 [Page 34]