CCAMP Working Group Snigdho Bardalai
Internet-Draft Rajan Rao
Intended status: Proposed Standard Ashok Kunjidhapatham
Expires: May 12, 2011 Khuzema Pithewan
Infinera Corp
November 8, 2010
OSPF TE Extensions for Generalized MPLS (GMPLS) Control of
G.709 Optical Transport Networks
draft-ashok-ccamp-gmpls-ospf-g709-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2010 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.
Ashok, et al. Expires May 12, 2011 [Page 1]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
Abstract
As OTN network capabilities continue to evolve, there is an increased
need to support GMPLS control for the same. [RFC4328] introduced
GMPLS signaling extensions for supporting the early version of G.709
[G.709-v1]. The basic routing considerations from signaling
perspective is also specified in [RFC4328].
The recent revision of ITU-T Recommendation G.709 [G.709-v3] and
[GSUP.43] have introduced new ODU containers (both fixed and
flexible) and additional ODU multiplexing capabilities, enabling
support for optimal service aggregation.
This document describes OSPF protocol extensions to support
Generalized MPLS (GMPLS) control for routing services over the
standardized OTU/ODU containers in support of ODU based TDM
switching. Routing support for Optical Channel Layer switching
(Lambda switching) is not covered in this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . . 5
3. OTU/ODU Link Representation . . . . . . . . . . . . . . . . . . 5
3.1. OTUk TE-Link . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. ODUk TE-Link . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. ODUj TE-Link . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Bundled TE-Link . . . . . . . . . . . . . . . . . . . . . . 7
3.5. OTU/ODU Link Property Agreement . . . . . . . . . . . . . . 7
4. OTU/ODU Link Bandwidth Model . . . . . . . . . . . . . . . . . . 8
5. OSPF TE-LSA Extension . . . . . . . . . . . . . . . . . . . . . 9
5.1. Maximum Bandwidth . . . . . . . . . . . . . . . . . . . . . 9
5.2. Maximum Reservable Bandwidth . . . . . . . . . . . . . . . 9
5.3. Unreserved Bandwidth . . . . . . . . . . . . . . . . . . . 9
5.4. Interface Switch Capability Descriptor . . . . . . . . . . 9
5.4.1. TDM - Switch Capability Specific Information . . . . 10
5.4.2. ODUk Switch Capability Specific Information . . . . 11
5.4.2.1 PER-SIGNALTYPE-BW-TLV . . . . . . . . . . . . . 12
5.4.2.2 ODUFLEX-BW-TLV . . . . . . . . . . . . . . . . . 14
6. Backward Compatibility consideration . . . . . . . . . . . . . 15
7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Links supporting line rate service only . . . . . . . . . 16
7.2. Multi-stage multiplexing . . . . . . . . . . . . . . . . 16
7.3. Link bundle with dissimilar OTU/ODU interfaces . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
Ashok, et al. Expires May 12, 2011 [Page 2]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Ashok, et al. Expires May 12, 2011 [Page 3]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends
MPLS from supporting Packet Switching Capable (PSC) interfaces and
switching to include support of four new classes of interfaces and
switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM),
Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional
description of the extensions to MPLS signaling that are needed to
support these new classes of interfaces and switching is provided in
[RFC3471]. OSPF extensions for supporting GMPLS are defined in
[RFC4203].
ITU-T Recommendations G.709 and G.872 provide specifications for OTN
interface and network architecture respectively. As OTN network
capabilities continue to evolve; there is an increased need to
support GMPLS control for the same.
GMPLS signaling extensions to support G.709 OTN interfaces are
specified in [RFC4328]. The basic routing considerations from
signaling perspective is specified. G.709 specifications evolved
rapidly over the last few years. Following are the features added
in OTN since the first version [G.709-v1].
(a) OTU Containers:
Pre-existing Containers: OTU1, OTU2 and OTU3
New Containers introduced in [G.709-v3]: OTU2e and OTU4
New Containers introduced in [GSUP.43]: OTU1e, OTU3e1 and OTU3e2
(b) Fixed ODU Containers:
Pre-existing Containers: ODU1, ODU2 and ODU3
New Containers introduced in [G.709-v3]: ODU0, ODU2e and ODU4
New Containers introduced in [GSUP.43]: ODU1e, ODU3e1 and ODU3e2
(c) Flexible ODU Containers:
ODUflex for CBR and GFP-F mapped services. ODUflex uses 'n'
number of OPU Tributary Slots where 'n' is different from the
number of OPU Tributary Slots used by the Fixed ODU Containers.
(d) Tributary Slot Granularity:
OPU2 and OPU3 support two Tributary Slot Granularities:
(i) 1.25Gbps and (ii) 2.5Gbps.
(e) Multi-stage ODU Multiplexing:
Multi-stage multiplexing of LO-ODUs into HO-ODU is supported.
Also, multiplexing could be heterogeneous (meaning LO-ODUs of
different rates can be multiplexed into a HO-ODU).
Ashok, et al. Expires May 12, 2011 [Page 4]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
OTN networks support switching at two layers: (i) ODU Layer - TDM
Switching and (ii) OCH Layer - Lambda (LSC) Switching. The nodes on
the network may support one or both the switching types. When
multiple switching types are supported MLN based routing [RFC5339]
is assumed.
This document covers OSPF extensions to support routing over the
standardized OTU/ODU containers in support of ODU Layer based TDM
switching as outlined in the framework document [G.709-FRAME].
The Interface Switch Capability Descriptor extensions for ODU Layer
switching and bandwidth representation for ODU containers are defined
in this document.
Routing support for Optical Channel Layer switching (LSC) is beyond
the scope of this document. Refer to [WSON-FRAME] for further
details.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document is to be interpreted as described in RFC-2119 [RFC2119].
In addition, the reader is assumed to be familiar with the
terminology used in ITU-T [G.709-v3], [G.872] and [GSUP.43], as
well as [RFC4201] and [RFC4203]. Abbreviations used in this
document is detailed in Appendix A.
3. OTU/ODU Link Representation
G.709 OTU/ODU Links are represented as TE-Links in GMPLS Traffic
Engineering Topology for supporting ODU layer switching. These
TE-Links can be modeled in multiple ways. Some of the prominent
representations are captured below.
3.1. OTUk TE-Link
OTUk Link can be modeled as a TE-Link. Switching at ODUk layer
and ODUj layer (including multi-stage multiplexing) can be managed on
OTUk TE-Link. Figure-1 below provides an illustration of this link
type.
When a LO-ODU layer being switched on an OTUk interface involves
multi-stage multiplexing, all the HO-ODU layer(s) should
necessarily terminate between the same pair of nodes as the OTUk
layer in this case. For example, if ODU1 layer switching is
Ashok, et al. Expires May 12, 2011 [Page 5]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
configured on a OTU3 link via multiplexing hierarchy
ODU3<-ODU2<-ODU1, HO-ODUs (namely ODU3 & ODU2) should terminate
between the same pair of nodes as OTU3 layer.
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
|<-- TE-Link -->| |<-- TE-Link -->|
Figure-1: OTUk TE-Link
3.2. ODUk TE-Link
When ODUk layer does not terminate on the same pair of nodes
as OTUk layer, ODUk link should be modeled as a TE-Link. As
bandwidth is directly managed on the ODUk link, associated OTUk
links are not significant in this case. Switching at ODUj layer
(including multi-stage multiplexing) can be managed on ODUk TE-Link.
Figure-2 below provides an illustration of this link type.
When a LO-ODU layer being switched on the ODUk interface involves
multi-stage multiplexing, all the HO-ODU layer(s) should necessarily
terminate between the same pair of nodes as ODUk in this case. For
example, if ODU1 layer switching is configured on an ODU3 link via
multiplexing hierarchy ODU3<-ODU2<-ODU1, HO-ODU (namely ODU2)
should terminate between the same pair of nodes as ODU3.
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
ODUk Switched
|<------------- ODUk Link ------------->|
|<-------------- TE-Link--------------->|
Figure-2: ODUk TE-Link
3.3. ODUj TE-Link
When a LO-ODUj within a HO-ODUk does not terminate on the same
pair of nodes as HO-ODUk layer, Separate TE-Links needs to be
modeled for ODUk link and ODUj link. Also, ODUk link shall
no longer manage the bandwidth associated with the ODUj link.
Ashok, et al. Expires May 12, 2011 [Page 6]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
Switching at sub-ODUj layer (including multi-stage multiplexing)
can be supported on this ODUj TE-Link. Figure-3 below provides
an illustration of this link type.
When a LO-ODU layer being switched on an ODUj interface involves
multi-stage multiplexing, all the HO-ODU layer(s) should necessarily
terminate between the same pair of nodes as ODUj in this case. For
example, if ODU0 layer switching is configured on an ODU2 link via
multiplexing hierarchy ODU2<-ODU1<-ODU0, HO-ODU (namely ODU1)
should terminate between the same pair of nodes as ODU2.
+-----+ +-----+ +-----+ +-----+
| OTN | | OTN | | OTN | | OTN |
| SW |<-OTUk Link->| SW |<-OTUk Link->| SW |<-OTUk Link->| SW |
| A | | B | | C | | D |
+-----+ +-----+ +-----+ +-----+
ODUj Switched ODUk Switched
|<--------- ODUk Link ---------->|
|<--------- TE-Link #1 --------->|
|<-------------------- ODUj Link ------------------->|
|<-------------------- TE-Link #2 ------------------>|
Figure-3: ODUj TE-Link
3.4. Bundled TE-Link
Any mix of OTU and ODU links of dissimilar rates that terminates on
same pair of nodes and meets the entire bundling criterion specified in
TE-Link Bundling specification [RFC4201] can be pulled together to
form a Bundle TE-Link. This is required for better scalability.
3.5. OTU/ODU Link Property Agreement
The OTN interfaces (associated with peer nodes) participating in a
TE-Link may not be fully compatible in terms of OTN interface
properties. The lowest common denominator between the two links
endpoints need to be used for forming the TE link. Some of OTN
specific link properties that need to be agreed upon between
the two link endpoints (on peer nodes) are:
(a) OPU Tributary Slot Granularity for OPU2 and OPU3.
(b) Multiplexing hierarchies supported - both number of stages and
specific LO-ODUs supported in each stage. This includes both
Fixed and Flexible ODU containers.
Ashok, et al. Expires May 12, 2011 [Page 7]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
These link properties either can be configured or discovered through
Link discovery mechanism. The details of such mechanism is beyond the
scope of this document.
4. OTU/ODU Link Bandwidth Model
Bandwidth allocation/management on OTU/ODU links is done in terms
of discrete units called OPU Tributary Slots. OPU Tributary Slots
occurs in two granularities (1.25Gbps and 2.5Gbps) and the actual
bit-rate of the OPU Tributary Slot slightly varies for different
ODU container types (i.e., ODU1, ODU2, ODU3 and ODU4). As a result
of this disparity, number of Tributary Slots required to map a
LO-ODU on different HO-ODU container types could vary. For example,
ODU2e requires 9 OPU TSs on ODU3 and 8 OPU TSs on ODU4.
The basic objectives of OTN interface bandwidth model are as
follows:
(a) Support ODU multi-stage multiplexing hierarchy and yet not
require advertisement of complete hierarchy tree.
(b) Account for bandwidth fragmentation that can result due to
the restricted multiplexing hierarchy supported on an OTN
interface. For example, assume that an ODU3 interface
supports direct multiplexing of ODU2 only. Here, mapping
of ODU1 and ODU0 is possible only through second stage
multiplexing underneath ODU2. If two ODU1 are created under
two different ODU2, only two ODU2 can be created further on
the interface although 28 Tributary Slots (1.25Gbps) are
available on the interface (ODU hierarchy).
(c) Hide the complexities in Tributary Slot Granularities (1.25Gbps
and 2.5Gbps) from bandwidth model and thereby simplify the
end-to-end path computation. As explained in the previous
section, this needs to be negotiated as a part of link
discovery or pre-configured locally on the either ends.
(d) Hide the complexities in Tributary Slot Size disparities (among
ODU containers) and number of Tributary Slots required to map
a LO-ODU. This can be achieved by advertising the number of
LO-ODU containers that can be mapped on an OTN interface rather
than number of Tributary Slots or absolute bandwidth in
bytes/sec.
(e) For ODU-Flex service, Absolute bandwidth required (for CBR
or GFP mapped service) needs to be mapped to 'n' Tributary
Slots of certain bit rate. This needs Tributary Slot bit-rate
and number of Tributary slots to be advertised.
Ashok, et al. Expires May 12, 2011 [Page 8]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
5. OSPF TE-LSA Extension
This section describes the OSPF TE-LSA Extensions to support
bandwidth encoding for OTU/ODU TE-Links.
5.1. Maximum Bandwidth
The format and interpretation of this attribute must be consistent
with OSPF-TE Extension [RFC3630] and TE-Link Bundling Support
[RFC4201] specifications. The OPUk payload nominal rate (in bytes
per sec) as specified in [G.709-v3] shall be encoded in this
attribute.
5.2. Maximum Reservable Bandwidth
The format and interpretation of this attribute must be consistent
with OSPF-TE Extension [RFC3630] and TE-Link Bundling Support
[RFC4201] specifications.
5.3. Unreserved Bandwidth
The format and interpretation of this attribute must be consistent
with OSPF-TE Extension [RFC3630] and TE-Link Bundling Support
[RFC4201] specifications.
Unreserved Bandwidth in bytes per second is not of much value for
OTU/ODU interfaces. Unreserved Bandwidth per ODU rate is more
appropriate and useful in this case. Implementations may choose to
ignore this attribute and consider per ODU-rate Unreserved Bandwidth
defined in Interface Switch Capability Descriptor for "G.709 ODUk"
encoding type. See section 5.4.2.
5.4. Interface Switch Capability Descriptor
As specified in GMPLS Signaling Extensions for OTN [RFC4328],
following are the Switching and Encoding Types that needs to be
used for OTU/ODU interface supporting ODU switching.
Switching Type = TDM [defined in RFC3471]
Encoding Type = G.709 ODUk (Digital Path) [defined in RFC4328]
Interface Switching Capability Descriptor for TDM is defined in
[RFC4203]. The current definition needs to be extended to cover the
bandwidth specification for ODU layer(s). When Encoding Type is
"G.709 ODUk", Interface switching Capability Descriptor should be
interpreted as follows:
Ashok, et al. Expires May 12, 2011 [Page 9]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TDM - Switch Capability Specific Information |
| (8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODUk - Switch Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Max LSP Bandwidth
Format and interpretation of this attribute must be consistent with
specification in GMPLS Routing Extension [RFC4202] and TE-Link
Bundling Support [RFC4201].
For ODU Encoding type, this should be coded with the maximum
bandwidth available on a single ODUk/ODUj container associated
with the given OTN interface. If OTU/ODU interface is composed of
multiple ODU containers (through multi-stage multiplexing), the
ODU container with the highest unreserved capacity shall be chosen
for encoding this attribute.
When link bundling is involved, the encoding and interpretation of
this attribute must be consistent with TE-Link Bundling Support
[RFC4201].
5.4.1. TDM - Switch Capability Specific Information
The format and interpretation of TDM - Switch Capability Specific
Ashok, et al. Expires May 12, 2011 [Page 10]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
Information must be as per OSPF GMPLS Extension [RFC4203].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum LSP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indication | Reserved (not Padding!) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Minimum LSP Bandwidth
The Minimum LSP Bandwidth specifies the minimum bandwidth an LSP
could reserve on an ODU container. The format and interpretation
of this attribute must be as defined in OSPF GMPLS Extension
[RFC4203].
Indication
This attribute is not applicable for this encoding type.
It is important to note that Padding bytes defined in [RFC4203]
should be interpreted as "Reserved". That means - TLV length of
Interface Switch Capability Descriptor includes these bytes as well.
5.4.2. ODUk Switch Capability Specific Information
This is the new sub-TLV added for supporting ODUk switching. This
must be included when encoding type is "G.709 ODUk". TLV type of
ODUk-SCSI-TLV shall be coded as 1. This Sub-TLV should contain one
or more PER-SIGNALTYPE-BW-TLV sub-TLVs and/or ODUFLEX-BW-TLV
sub-TLV (if applicable).
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) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PER-SIGNALTYPE-BW-TLV #1 |
| (TLV Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
Ashok, et al. Expires May 12, 2011 [Page 11]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PER-SIGNALTYPE-BW-TLV #n |
| (TLV Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODUFLEX-BW-TLV (if applicable) |
| (TLV Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.4.2.1 PER-SIGNALTYPE-BW-TLV
PER-SIGNALTYPE-BW-TLV shall be included for each Signal Type that
can be switched on the TE-Link with an exception of ODUflex for
which a separate TLV type is defined. The TLV type of
PER-SIGNALTYPE-BW-TLV shall be coded as 1. The format of this
sub-TLV 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) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |Bw Type| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available ODUs at Prio 0 | Available ODUs at Prio 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available ODUs at Prio 2 | Available ODUs at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available ODUs at Prio 4 | Available ODUs at Prio 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available ODUs at Prio 6 | Available ODUs at Prio 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optimization Note:
It is possible to optimize this bandwidth information by including
the available bandwidth for the supported priority levels only. A
bitmap (8 bits) can be added in place of reserved bytes to
indicate the priority values(8) for which available bandwidth is
advertised.
Signal Type
This field (8 bits) must be coded as specified in OTN Signaling
Extension [RFC4328]. The values defined in [RFC4328] pertains to
[G.709-v1]. This needs to be extended to support additional ODU
containers defined in more recent G.709 specifications [G.709-v3].
Ashok, et al. Expires May 12, 2011 [Page 12]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
Value Type
----- ----
4 ODU4 (100Gbps)
5 ODU0 (1.25Gbps)
10 ODUflex
11 ODU1e (10Gbps Ethernet [GSUP.43])
12 ODU2e (10Gbps Ethernet)
13 ODU3e1 (40Gbps Ethernet [GSUP.43])
14 ODU3e2 (40Gbps Ethernet [GSUP.43])
15-39 Reserved (for future)
40 ODU0_ANY (ODU0 and future 1.25Gbps ODU variants)
41 ODU1_ANY (ODU1 and future 2.5Gbps ODU variants )
42 ODU2_ANY (ODU2, ODU1e, ODU2e and future 10Gbps ODU variants)
43 ODU3_ANY (ODU3, ODU3e1, ODU3e2 and future 40Gbps ODU variants)
44 ODU4_ANY (ODU4 and future 100Gbps ODU variants)
45-255 Reserved (for future)
Signal Types 40 to 44 can be used for further optimizing the
bandwidth encoding by advertising a single bandwidth entry for all
the ODU types (of almost same rate) switchable on a given interface.
For instance, assume an OTU interface that can be configured as
OTU2 or OTU2e or OTU1e. Though the interface can potentially
switch ODU2 or ODU2e or ODU1e, it is wasteful to advertise
separate PER-SIGNALTYPE-BW-TLV for each ODU2 variants namely
ODU1e, ODU2e and ODU2. In such cases, ODU2_ANY can be used. It is
important to note that when ODUj_ANY bandwidth entry is included,
no separate bandwidth entry for individual ODUj variants must be
present. The route computation engine should treat ODUj_ANY as
a wildcard entry for all the ODUj variants of the same rate.
Bandwidth Type
This field (4 bits) indicates the bandwidth (BW) type pertaining to
"Available ODUs" field. The values supported are as follows:
Value Type
----- ----
0 Max LSP Bandwidth
1 Unreserved Bandwidth
2-15 Reserved (for future)
Flags
This field (4 bits) should be interpreted as a bitmap. The bits are
reserved for future use. This should be coded as 0x0. The receiving
node should discard this field.
Ashok, et al. Expires May 12, 2011 [Page 13]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
Available ODUs
This field (16 bits) indicates the maximum number of ODU Containers
of a given Signal-Type available on this TE-Link.
When Bw-Type (=0) is "Max-Lsp-Bandwidth", The "Available ODUs" of
a bundled link at priority p is defined to be the maximum of the
"Available ODUs" at priority p of all of its component links.
When Bw-Type (=1) is "Unreserved-Bandwidth", The "Available ODUs" of a
bundled link at priority p is defined to be the sum of the
"Available ODUs" at priority p of all of its component links.
Bw-Type of 1 (Unreserved Bandwidth) is not applicable when there is
no link bundling.
5.4.2.2 ODUFLEX-BW-TLV
ODUFLEX-BW-TLV shall be included if ODUflex signal type is
supported on the TE-Link. The TLV type of ODUFLEX-BW-TLV shall be
coded as 2. The format of this sub-TLV 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) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |Bw Type| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available BW in byes/sec at Prio 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optimization Note:
It is possible to optimize this bandwidth information by including
Ashok, et al. Expires May 12, 2011 [Page 14]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
the available bandwidth for the supported priority levels only. A
bitmap (8 bits) can be added in place of reserved bytes to
indicate the priority values(8) for which available bandwidth is
advertised.
Fields of ODUFLEX-BW-TLV
All the fields of ODUFLEX-BW-TLV are same as that of
PER-SIGNALTYPE-BW-TLV except that "Available ODUs" in
PER-SIGNALTYPE-BW-TLV is replaced by "Available BW in bytes/second"
in ODUFLEX-BW-TLV.
Available BW (in bytes/sec)
Available BW (in bytes/sec) is represented in IEEE float-point
format similar to Max-Lsp-Bandwidth in ISCD. Maximum bandwidth
available for ODUflex on the OTN interface is coded in this
attribute. If OTU/ODU interface is composed of multiple ODU
containers (through multi-stage multiplexing), the ODU container
with the highest unreserved capacity for ODUflex shall be chosen
for encoding this attribute.
Available Bw (at Pi) = Max-Unreserved-TS-Count x TS-Nominal-Rate
where,
Max-Unreserved-TS-Count: Maximum OPU Tributary Slots available for
ODUflex service on a single ODU container.
TS-Nominal-Rate: Nominal rate of an OPU Trib Slot on the ODU
Container in Bytes per second.
When Bw-Type (=0) is "Max-Lsp-Bandwidth", The "Available Bw" of a
bundled link at priority p is defined to be the maximum of the
"Available Bw" at priority p of all of its component links.
When Bw-Type (=1) is "Unreserved-Bandwidth", The "Available Bw"
of a bundled link at priority p is defined to be the sum of the
"Available Bw" at priority p of all of its component links.
Bw-Type of 1 (Unreserved Bandwidth) is not of much value for
ODUflex signale type. It is not mandatory to include this
bandwidth type even for bundled links.
6. Backward Compatibility consideration
As the definition of the pre-existing BW TLVs are not modified,
this draft is fully backward compatible for all the legacy
services supported in [RFC4328]. For supporting the OTN
Ashok, et al. Expires May 12, 2011 [Page 15]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
capabilities added since the first version of G.709 [G.709-v1],
ODUk SCSI TLV encoding and interpretation is required.
7. Use Cases
This sections presents some use-cases for bandwidth encoding
and usage.
7.1. Links supporting line rate service only
Assume OTU2 interface that supports ODU2 switching only. Interface
Switching Capability Descriptor should be coded as follows:
Max Lsp Bw = <ODU2 rate> // Nominal rate of ODU2 in bytes per
// second.
Min Lsp Bw = <ODU2 rate> // Nominal rate of ODU2 in bytes per
// second.
ODUk Switching Capability Specific Information:
+===============+================+===========================+
| Signal Type | Bandwidth Type | Available ODUs at Prio P |
+===============+================+===========================+
| 2 (ODU2) | 0 (Max-Lsp-Bw) | 1 |
+---------------+----------------+---------------------------+
ODUFLEX-BW-TLV will not be included as the ODUflex rate is not
supported on the interface.
7.2. Multi-stage multiplexing
Assume OTU3 interface that supports switching at line rate ODU3
and lower rates - ODU0, ODU1, ODU2, ODU2e & ODUflex via
multiplexing.
Max Lsp Bw = <ODU3 rate> // Nominal rate of ODU3 in bytes
// per second.
Min Lsp Bw = <ODU0 rate> // Nominal rate of ODU0 in bytes
// per second.
ODUk Switching Capability Specific Information:
+===============+================+===========================+
| Signal Type | Bandwidth Type | Available ODUs at Prio P |
+===============+================+===========================+
| 3 (ODU3) | 0 (Max-Lsp-Bw) | 1 |
+---------------+----------------+---------------------------+
| 5 (ODU0) | 0 (Max-Lsp-Bw) | 32 |
+---------------+----------------+---------------------------+
Ashok, et al. Expires May 12, 2011 [Page 16]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
| 1 (ODU1) | 0 (Max-Lsp-Bw | 16 |
+---------------+----------------+---------------------------+
| 2 (ODU2) | 0 (Max-Lsp-Bw) | 4 |
+---------------+----------------+---------------------------+
| 12 (ODU2e) | 0 (Max-Lsp-Bw) | 3 |
+---------------+----------------+---------------------------+
+===============+================+===========================+
| Signal Type | Bandwidth Type | Available Bw at Prio P |
+===============+================+===========================+
| 10 (ODUflex) | 0 (Max-Lsp-Bw) | (32 * 1,254,703)/8 |
+===============+================+===========================+
7.3. Link bundle with dissimilar OTU/ODU interfaces
Assume a link bundle involving OTU3, OTU2 and OTU2e interfaces
that support switching at all standard LO-ODUs.
Max Lsp Bw = <ODU3 rate> // Nominal rate of ODU3 in bytes
// per second.
Min Lsp Bw = <ODU0 rate> // Nominal rate of ODU0 in bytes
// per second.
ODUk Switching Capability Specific Information:
+===============+================+===========================+
| Signal Type | Bandwidth Type | Available ODUs at Prio P |
+===============+================+===========================+
| 3 (ODU3) | 0 (Max-Lsp-Bw) | 1 |
+---------------+----------------+---------------------------+
| 5 (ODU0) | 0 (Max-Lsp-Bw) | 32 (i.e. Max of 32 and 8) |
+---------------+----------------+---------------------------+
| 1 (ODU1) | 0 (Max-Lsp-Bw | 16 (i.e. Max of 16 and 4) |
+---------------+----------------+---------------------------+
| 2 (ODU2) | 0 (Max-Lsp-Bw) | 4 (i.e. Max of 4 and 1) |
+---------------+----------------+---------------------------+
| 12 (ODU2e) | 0 (Max-Lsp-Bw) | 3 (i.e. Max of 3 and 1) |
+---------------+----------------+---------------------------+
| 3 (ODU3) | 1 (Unres-Bw) | 1 |
+---------------+----------------+---------------------------+
| 5 (ODU0) | 1 (Unres-Bw) | 40 (i.e. 32 + 8) |
+---------------+----------------+---------------------------+
| 1 (ODU1) | 1 (Unres-Bw) | 20 (i.e. 16 + 4) |
+---------------+----------------+---------------------------+
| 2 (ODU2) | 1 (Unres-Bw) | 5 (i.e. 4 + 1) |
+---------------+----------------+---------------------------+
| 12 (ODU2e) | 1 (Unres-Bw) | 4 (i.e. 3 + 1) |
+---------------+----------------+---------------------------+
Ashok, et al. Expires May 12, 2011 [Page 17]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
+===============+================+===========================+
| Signal Type | Bandwidth Type | Available Bw at Prio P |
+===============+================+===========================+
| 10 (ODUflex) | 0 (Max-Lsp-Bw) | (32 * 1,254,703)/8 |
+===============+================+===========================+
8. Security Considerations
There are no additional security implications to OSPF routing
protocol due to the extensions captured in this document.
9. IANA Considerations
The memo introduces two new sub-TLVs of the Interface Switch Capability
Descriptor Sub-TLV of TE-LSA. [RFC3630] says that the sub-TLVs of the
TE Link TLV in the range 10-32767 must be assigned by Expert Review,
and must be registered with IANA.
The memo has three suggested values for the three sub-TLVs of the
Interface Switch Capability Descriptor Sub-TLV; it is strongly
recommended that the suggested values be granted, as there are
interoperable implementations using these values.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels".
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
MPLS Traffic Engineering (TE)"
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)"
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Ashok, et al. Expires May 12, 2011 [Page 18]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
Transport Networks Control", RFC 4328, January 2006.
[RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing
GMPLS Protocols against Multi-Layer and Multi-Region
Networks (MLN/MRN)", RFC 5339, September 2008.
[G.709-v3] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709 Recommendation, December 2009.
[GSUP.43] ITU-T, "Proposed revision of G.sup43 (for agreement)",
December 2008.
10.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[G.709-v1] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation (and Amendment 1), February
2001 (October 2001).
[G.872] ITU-T, "Architecture of optical transport networks",
November 2001 (11 2001).
[G.709-FRAME] F. Zhang, D. Li, H. Li, S. Belotti, "Framework for
GMPLS and PCE Control of G.709 Optical Transport
Networks", draft-zhang-ccamp-gmpls-g709-framework-02,
work in progress.
[WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks
(WSON)", draft-ietf-ccamp-rwa-wson-framework, work in
progress.
11. Acknowledgements
Authors would like to thank Lou Berger, Biao Lu, Ping Pan, Radhakrishna
Valiveti and Mohit Misra for review comments and suggestions.
Author's Addresses
Snigdho Bardalai
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: sbardalai@infinera.com
Ashok, et al. Expires May 12, 2011 [Page 19]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
Rajan Rao
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: rrao@infinera.com
Ashok Kunjidhapatham
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: akunjidhapatham@infinera.com
Khuzema Pithewan
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089
USA
Email: kpithewan@infinera.com
Appendix A
A. Abbreviations:
CBR Constant Bit Rate
GFP Generic Framing Procedure
HO-ODU Higher Order ODU
LSC Lambda Switch Capable
LSP Label Switched Path
LO-ODU Lower Order ODU
ISCD Interface Switch Capability Descriptor
OCC Optical Channel Carrier
OCG Optical Carrier Group
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
ODTUG Optical Date Tributary Unit Group
ODU Optical Channel Data Unit
OMS Optical Multiplex Section
OMU Optical Multiplex Unit
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OSC Optical Supervisory Channel
OTH Optical Transport Hierarchy
Ashok, et al. Expires May 12, 2011 [Page 20]
Internet-Draft draft-ashok-ccamp-gmpls-ospf-g709-02.txtNovember 8, 2010
OTM Optical Transport Module
OTN Optical Transport Network
OTS Optical Transmission Section
OTU Optical Channel Transport Unit
OTUkV Functionally Standardized OTUk
SCSI Switch Capability Specific Information
TDM Time Division Multiplex
B. Terminology
1. ODUk and ODUj
ODUk refers to the ODU container that is directly mapped to an
OTU container. ODUj refers to the lower order ODU container that
is mapped to an higher order ODU container via multiplexing.
2. LO-ODU and HO-ODU
LO-ODU refers to the ODU client layer of lower rate that is mapped
to an ODU server layer of higher rate via multiplexing. HO-ODU
refers to the ODU server layer of higher rate that supports
mapping of one or more ODU client layers of lower rate.
In multi-stage multiplexing case, a given ODU layer can be a
client for one stage (interpreted as LO-ODU) and at the same
time server for another stage (interpreted as HO-ODU). In this
case, the notion of LO-ODU and HO-ODU needs to be interpreted in a
recursive manner.
ODU0 | (LO-ODU)
| |
| | Stage #1
V |
(LO-ODU) | ODU1 | (HO-ODU)
| |
Stage #2 | |
| V
(HO-ODU) | ODU2 | (LO-ODU)
| |
| | Stage #3
V |
ODU3 | (HO-ODU)
Figure-4 : LO-ODU and HO-ODU
Ashok, et al. Expires May 12, 2011 [Page 21]