CCAMP Working Group D. Ceccarelli
Internet-Draft D. Caviglia
Intended status: Standards Track Ericsson
Expires: September 9, 2010 F. Zhang
D. Li
Huawei Technologies
Y. Xu
CATR
March 8, 2010
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS)
Control of Evolutive G.709 OTN Networks
draft-ceccarelli-ccamp-gmpls-ospf-g709-01
Abstract
Recent revisions of ITU-T Recommendation G.709 have introduced new
features for OTNs:ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. The
new features for the evolutive OTNs are described in separate ITU-T
documents. ODU0, ODU2e and ODU4 ODUflex are described in [G709-V3].
ODU3e1 and ODU3e2 are described in [Gsup43]. This document describes
OSPF routing protocol extensions to support the evolutive Optical
Transport Networks (OTN) under the control of Generalized MPLS
(GMPLS).
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Ceccarelli, et al. Expires September 9, 2010 [Page 1]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Copyright 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 BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OSPF Requirements . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the Evolutive G.709 . . . . . . . . . . . . . . . 4
4. G.709 Digital Layer TE Information . . . . . . . . . . . . . . 6
4.1. Tributary Slot type . . . . . . . . . . . . . . . . . . . 6
4.2. TE link type . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. LO ODU signal type . . . . . . . . . . . . . . . . . . . . 7
4.4. TE link Unreserved Bandwidth . . . . . . . . . . . . . . . 8
4.5. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 8
5. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. OTN Interface Switching Capability Descriptor . . . . . . 9
6. Compatibility Considerations . . . . . . . . . . . . . . . . . 11
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Ceccarelli, et al. Expires September 9, 2010 [Page 2]
Internet-Draft OSPF-TE extensions for OTN support March 2010
1. Introduction
An Opaque OSPF (Open Shortest Path First) LSA (Link State
Advertisements) carrying application-specific information can be
generated and advertised to other nodes following the flooding
procedures defined in [RFC5250]. Three types of opaque LSA are
defined, i.e. type 9 - link-local flooding scope, type 10 - area-
local flooding scope, type 11 - AS flooding scope.
Traffic Engineering (TE) LSA using type 10 opaque LSA is defined in
[RFC3630] for TE purpose. This type of LSA is composed of a standard
LSA header and a payload including one top-level TLV (Type/Length/
Value triplet) and possible several nested sub-TLVs. [RFC3630]
defines two top-level TLVs: Router Address TLV and Link TLV; and nine
possible sub-TLVs for the Link TLV, used to carry link related TE
information.
The Link type sub-TLVs are enhanced by [RFC4203] in order to support
GMPLS networks and related specific link information.
In GMPLS networks each node generates TE LSAs to advertise its TE
information and capabilities (link-specific or node-specific),
through the network. The TE information carried in the LSAs are
collected by the other nodes of the network and stored into their
local Traffic Engineering Databases (TED).
In the GMPLS based G.709 Optical Transport Networks (OTNs), in order
to automatically establish ODUk connections through GMPLS RSVP-TE
signaling, routing is the foundation.
OTN networks provide flexible and various multiplexing relationships
(e.g., ODUj multiplexed into ODUk (j<k)), two different tributary
slots for ODUk (K=1, 2, 3) and ODUflex signal type, which is being
standardized in ITU-T. In order to present this information in the
routing process, the OSPF protocol needs to be extended.
This document describes OSPF routing protocol extensions to support
the evolutive OTNs under the control of GMPLS. Please note that the
routing information for Optical Channel Layer (OCh) (i.e.,
wavelength) is out of the scope of this document. Please refer to
[WSON-Frame] for further information.
2. OSPF Requirements
ITU-T has introduced in the recently approved G.709 [2009] new fixed
size ODU containers and a new variable size ODUflex container that
can be used to transport either CBR signals or packets. OTN serves
Ceccarelli, et al. Expires September 9, 2010 [Page 3]
Internet-Draft OSPF-TE extensions for OTN support March 2010
as the convergence layer for transporting a wide range of services,
including those whose bit rates do not allow efficient usage of the
entire bandwidth associated with a single lambda. In the latter
case, OTN allows aggregation (and protection) of traffic to support
optimization of overall network bandwidth allocation; i.e., OTN
allows the aggregate service rate to be decoupled from the OTN line
system capacity.
For example, within a given networking domain, you can think of LSPs
(ODUs) serving different roles (service and line). A line rate LSP
only uses the line rate capacity (OTUk capacity) and cannot be
further electrically multiplexed (e.g., a line rate 10Gbit/s can only
traverse OTU2 links). On the other hand, a service LSP may be
electrically multiplexed and it is able to cross any kind of link
regardless of the line rate. From a routing scalability perspective,
it is also necessary to have the possibility to group/map information
about certain physical resources (e.g., links) and their properties.
Thus, it is necessary to define a maximally scalable control plane
solution that is able to fully exploit OTN flexibility (both in terms
of aggregation and survivability). This leads the authors to view it
as critical to fulfill the following requirements:
- Support G.709 ODUs including ODUflex. As opposed to fixed size
containers, for ODUflex it is necessary to declare the maximum LSP
bandwidth. Support all standard (fixed and flexible) ODUs.
- Be able to differentiate multiplexed capacity from line rate
capacity. This allows support of the scenarios in the OTN
framework draft (in particular, the hybrid scenario).
- Be capable of bundling links either at the same line rate or
different line rates (e.g. 40G and 10G). Bundling links at
different rates makes the control plane more scalable and permits
better networking flexibility.
- Support priority for restoration.
3. Overview of the Evolutive G.709
The traditional OTN specification [G709] describes the Optical
Transport Hierarchy (OTH) and introduces three types of ODU (Optical
Channel Data Unit) signal (i.e. ODU1, ODU2 and ODU3). The ODUj can
be mapped into one or more Tributary Slots (with granularity of
2.5Gbps) of OPUk (Optical Channel Payload Unit-k) where j<k. The
ODUj can also be mapped into OTUj (Optical Channel Transport Unit-j,
j=1, 2 or 3) directly.
Ceccarelli, et al. Expires September 9, 2010 [Page 4]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Recent revisions of ITU-T Recommendation G.709 have introduced new
features for OTNs:ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. The
new features for the evolutive OTNs are described in separate ITU-T
documents. ODU0, ODU2e and ODU4 ODUflex are described in [G709-V3].
ODU3e1 and ODU3e2 are described in [Gsup43].
The ITU-T documents also define the new multiplexing hierarchy for
the evolutive OTN. In this multiplexing hierarchy, LO (Lower Order)
ODUj can be mapped into an OTUj, or multiplexed into an HO (Higher
Order) ODUk (where j<k) occupying several TSs (Tributary Slots).
In the case of LO ODUj mapping into OTUj, the following mappings are
defined:
- ODU1 into OTU1 mapping
- ODU2 into OTU2 mapping
- ODU3 into OTU3 mapping
- ODU4 into OTU4 mapping
- ODU2e into OTU2e mapping
In the case of LO ODUj multiplexing into HO ODUk, a new Tributary
Slot granularity (i.e. 1.25Gbps) is introduced in [G709-V3]. For the
evolutive OTN, the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex)
into an ODUk (k > j) signal can be depicted as follows:
- ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity)
- ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS
granularity)
- ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity)
- ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with
1.25Gbps TS granularity)
- ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity)
- ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing
(with 1.25Gbps TS granularity)
- ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity)
- ODU2e into ODU3e2 multiplexing (with 1.25Gbps TS granularity)
Ceccarelli, et al. Expires September 9, 2010 [Page 5]
Internet-Draft OSPF-TE extensions for OTN support March 2010
In order to be backward compatible with the 2.5Gbps TS defined in
[G709-V3], both the 2.5Gbps TS and the 1.25Gbps TS can be used in the
two cases listed below:
o ODU1 into ODU2 multiplexing
o ODU1 and ODU2 into ODU3 multiplexing
From the link perspective, it can only work under one TS type. For
example, if the both ends (or interfaces) of the link can support
2.5Gbps TS and 1.25Gbps TS, then it can work under 2.5Gbps TS or
1.25Gbps TS. If one end can support 1.25Gbps TS, and another end can
support 2.5Gbps TS, the end with 1.25Gbps TS MUST adopt a 2.5Gbps
TS).
4. G.709 Digital Layer TE Information
This document only considers the TE information needed for LO ODU
path computation. WSON TE information is out of scope. Please refer
to [WSON-OSPF] for more information about WSON routing information.
From the perspective of [G709-V3], there are two different cases for
LO ODU:
(1) A LO ODUk mapped into an OTUk. In this case, the server layer of
this LO ODU is an OTUk. For example, if a STM-16 signal is
encapsulated into an ODU1 and then mapped into OTU1, the ODU1 is a LO
ODU.
(2) A LO ODUj multiplexed into a HO (Higher Order) ODUk (j < k)
occupying several TSs. In this case, the server layer of this LO ODU
is a HO ODUk. For example, if an ODU1 is multiplexed into ODU2 and
then mapped into an OTU2, the ODU1 is a LO ODU and the ODU2 is a HO
ODU.
In order to compute a suitable path the PCE (centralized or
distributed) needs a set of data that should be advertised by the
routing protocol. In the following sections each type of data is
listed and analyzed, while the possible values are shown in section
5.
4.1. Tributary Slot type
ITU-T recommendations define two types of TS but, from the link
perspective, it can only work under one of them. For example, if the
both ends (or interfaces) of a link can support 2.5Gbps TS or
1.25Gbps TS, then the link will work under 2.5Gbps TS or 1.25Gbps TS.
Ceccarelli, et al. Expires September 9, 2010 [Page 6]
Internet-Draft OSPF-TE extensions for OTN support March 2010
If one end can support the 1.25Gbps TS, and another end the 2.5Gbps
TS, the former end SHOULD adopt the 2.5Gbps TS.
In addition, the bandwidth accounting depends on the type of TS.
Therefore, the type of the TS should be known during LO ODU path
computation.
4.2. TE link type
The link type indicates the OTUk/HO ODUk type of the TE link.
The TS bandwidth of different types of OTUk is different; it
increases along with the increasing of k (see [G709-V3]). The
bandwidth of a TS in a TE link can be deduced from the TS type and
link type of the TE link. For example, the bandwidth of a 1.25G TS
without NJO (Negative Justification Opportunity) in an OTU2 is about
1.249409620 Gbps, while the bandwidth of a 1.25G TS without NJO in an
OTU3 is about 1.254703729 Gbps.
The actual TS bandwidth of a TE link is useful to determine the
number of TSs needed by an ODUflex service. And the actual TS
bandwidth of a TE link can be deduced by the TE link type and TS
type.
4.3. LO ODU signal type
It is possible that some equipments can not support all the LO ODU
signal types. When a path computation procedure for a LO ODU is
performed, it needs to check whether a link has the capability to
carry a specific type of LO ODU or not. If a link can not carry this
type of LO ODU, it should be excluded during the path computation.
Only the links with the capability of carrying this type of LO ODU
can be the candidates.
For example, in the following figure, the interfaces IF1, IF2, IF8,
IF7, IF5 and IF6 can support ODUflex signals, while the interfaces
IF3 and IF4 cannot. In this case, if one ODUflex connection from A
to C is requested, link #1 and #2 are excluded and link #3 and link
#4 are the candidates (the possible path could be A-D-C through link
#3 and link #4).
Ceccarelli, et al. Expires September 9, 2010 [Page 7]
Internet-Draft OSPF-TE extensions for OTN support March 2010
+-----+
link #3 | | link #4
+-----------------+ D +-----------------+
| IF8| |IF7 |
| +-----+ |
| |
|IF1 IF6|
+--+--+ +-----+ +--+--+
| | link #1 | | link #2 | |
| A +--------------+ B +--------------+ C |
| |IF2 IF3| |IF4 IF5| |
+-----+ +-----+ +-----+
Figure 1: LO ODU signal type
Therefore, it is necessary to advertise the LO ODU types that the OTU
or HO ODU TE link can support.
4.4. TE link Unreserved Bandwidth
In the GMPLS based OTN networks, the Unreserved Bandwidth of a TE
link is the sum of the unreserved bandwidths of all the component
links associated with the bundled link.
The unreserved bandwidth can be accounted through the unallocated
Tributary Slots of the TE link.
4.5. Maximum LSP Bandwidth
The Maximum Bandwidth that an LSP can occupy in a TE link is
determined by the component link with the maximum unreserved
bandwidth in such TE link.
For example, if two OTU3 component links are bundled to a TE link,
the unreserved bandwidth of the first component link is 20*1.25G TSs,
and the unreserved bandwidth of the second component link is 24*1.25G
TSs. Then the unreserved bandwidth of this TE link is 44*1.25G TSs,
but the maximum TSs that a LSP can occupy in this TE link is 24, not
44.
5. OSPF Extensions
In terms of GMPLS based OTN networks, each OTUk/HO ODUk can be viewed
as a component link, and each component link can carry one or more
types of LO ODU.
Ceccarelli, et al. Expires September 9, 2010 [Page 8]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Each TE LSA can carry a top-level TLV with several nested sub-TLVs to
describe different attributes of a TE link. Two top-level TLVs are
defined in [RFC 3630]. (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 [RFC 3630] and [RFC 4203].
A general Interface Switching Capability Descriptor (ISCD) sub-TLV is
defined In [RFC 4203]. The bandwidth accounting is encoded in a 4
octets field in the IEEE floating point format. Max LSP Bandwidth is
accounted at each priority X (0~7).
This document defines a new sub-TLV of the Link TLV, called OTN
Interface Switching Capability Descriptor (OTN-ISCD) with value TBD
by IANA. The OTN-ISCD format is described in Section 5.1.
One or more component links can be bundled as a TE link. In case of
link bundling an OTN-ISCD will be used for each component link.
5.1. OTN Interface Switching Capability Descriptor
The format of the new OTN-Interface Switching Capability Descriptor
is defined in Figure 2.
Ceccarelli, et al. Expires September 9, 2010 [Page 9]
Internet-Draft OSPF-TE extensions for OTN support March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| T |OD(T)Uk| Reserved | Signal Flags |G|F|E|D|C|B|A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P0 | Unreserved TS at p0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P1 | Unreserved TS at p1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P2 | Unreserved TS at p2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P3 | Unreserved TS at p3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P4 | Unreserved TS at p4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P5 | Unreserved TS at p5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P6 | Unreserved TS at p6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P7 | Unreserved TS at p7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: OTN-Interface Switching Capability Descriptor
Where:
o T (2 bits): Indicates the type of the Tributary Slot of this TE
link, value 0 means the TS type is 1.25Gbps, value 1 means the TS
type is 2.5Gbps.
o OD(T)Uk (4 bits): Indicates the type of the TE link, i.e. the
server layer signal that the LO ODUs can be mapped or multiplexed
into. The following values are defined:
0: Reserved (for future use)
1: OTU1/HO ODU1
2: OTU2/HO ODU2
3: OTU3/HO ODU3
4: OTU4/HO ODU4
Ceccarelli, et al. Expires September 9, 2010 [Page 10]
Internet-Draft OSPF-TE extensions for OTN support March 2010
5: OTU2e/HO ODU2e
6-15: Reserved (for future use)
The bandwidth of a TS in this TE link can be deduced from T bit and
OD(T)Uk field.
o Signal Flags (16 bits): This field indicates the LO ODU type
supported by the TE link. A flag set to 1 indicates that the TE link
supports the corresponding LO ODU signal. Currently the following
flags are defined:
Flag A: indicates whether LO ODU0 is supported.
Flag B: indicates whether LO ODU1 is supported.
Flag C: indicates whether LO ODU2 is supported.
Flag D: indicates whether LO ODU3 is supported.
Flag E: indicates whether LO ODU4 is supported.
Flag F: indicates whether LO ODU2e is supported.
Flag G: indicates whether LO ODUflex is supported.
Other bits are reserved and must be set to zero when sent and should
be ignored when received.
o Max lsp TS at Pi (16 bits): Indicates the maximum number of
unreserved TS at priority Pi of all of the component links of the TE
link.
o Unreserved TS at Pi (12 bits): Indicates the number of unreserved
TSs at priority Pi inside all the component links of the TE link.
All the reserved fields must be set to zero and should be ignored
when received.
6. Compatibility Considerations
The legacy nodes that do not implement the extensions defined in this
document are able to ignore the LSA containing an OTN-ISCD sub-TLV.
They will continue to flood the LSA to other neighbors, but will not
use the information carried in this LSA.
Ceccarelli, et al. Expires September 9, 2010 [Page 11]
Internet-Draft OSPF-TE extensions for OTN support March 2010
7. Example
Based on the sub-TLVs defined in [RFC 3630], [RFC 4203] and this
document, a G.709 digital TE link can be described as follows.
+------+ component link 1 +------+
| +------------------+ |
| N1 +------------------+ N2 |
| | component link 2 | |
+--+---+ +---+--+
Figure 3: Example
This picture shows a simple example of an OTN network. The link type
of the two component links are OTU2 and OTU3 respectively. The
former have the capability of carrying ODU0, ODU1 and ODUflex client
signals, while the latter, ODU1, ODU2, ODU3 and ODUflex. The TS type
is 1.25Gbps and all the possible priorities are supported (0~7).
The two component links can be bundled as a TE link but it is also
possible to consider each of them as a separate TE link.
If the two component links are bundled together, N1 and N2 should
assign a link local ID to the TE link and then N1 get the link remote
ID automatically or manually.
N1 can generate an LSA to describe the above attributes of the TE
link. Suppose the link IDs are unnumbered, the LSA should carry a
link TLV with the following nested minimal sub-TLVs:
< G.709 Digital Link > ::= < Link Type > < Link ID > < Link
Local/Remote Identifiers > < OTN Interface Switching Capability Descriptor >
o Link Type sub-TLV: Defined in [RFC 3630], G.709 digital links are
always type 1 - Point-to-point link.
o Link ID sub-TLV: Defined in [RFC 3630], for point-to-point link,
indicates the remote router ID.
o Link Local/Remote Identifiers sub-TLV: Defined in [RFC 4203],
indicates the local link ID and the remote link ID.
Ceccarelli, et al. Expires September 9, 2010 [Page 12]
Internet-Draft OSPF-TE extensions for OTN support March 2010
o OTN Interface Switching Capability Descriptor sub-TLV: Defined in
this document, carries the characteristic of this G.709 digital TE
link.
Just after the creation of the TE Link comprising the two component
links, the two ISCDs would be 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|T=0|OTk =2 | Reserved | Signal Flags |1|0|0|0|0|1|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P0 =8 | Unreserved TS at p0 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P1 =8 | Unreserved TS at p1 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P2 =8 | Unreserved TS at p2 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P3 =8 | Unreserved TS at p3 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P4 =8 | Unreserved TS at p4 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P5 =8 | Unreserved TS at p5 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P6 =8 | Unreserved TS at p6 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P7 =8 | Unreserved TS at p7 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example - OTN-ISCD OTU2 LC (to)
Ceccarelli, et al. Expires September 9, 2010 [Page 13]
Internet-Draft OSPF-TE extensions for OTN support March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P0 =32 | Unreserved TS at p0 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P1 =32 | Unreserved TS at p1 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P2 =32 | Unreserved TS at p2 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P3 =32 | Unreserved TS at p3 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P4 =32 | Unreserved TS at p4 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P5 =32 | Unreserved TS at p5 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P6 =32 | Unreserved TS at p6 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P7 =32 | Unreserved TS at p7 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example - OTN-ISCD OTU3 LC (to)
Suppose that at time t1 an LSP is created allocating 35 Gbps at
priority 3. The OTN-ISCD referring to the OTU2 component link is
unmodified (Figure 4 and the OTN-ISCD referring to the OTU3 component
link is modified as illustrated in Figure 6):
Ceccarelli, et al. Expires September 9, 2010 [Page 14]
Internet-Draft OSPF-TE extensions for OTN support March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P0 =32 | Unreserved TS at p0 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P1 =32 | Unreserved TS at p1 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P2 =32 | Unreserved TS at p2 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P3 =4 | Unreserved TS at p3 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P4 =4 | Unreserved TS at p4 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P5 =4 | Unreserved TS at p5 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P6 =4 | Unreserved TS at p6 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P7 =4 | Unreserved TS at p7 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example - OTN-ISCD OTU3 LC (t1)
The last example shows how the prehemption is managed. In
particular, if a time t2 a new 15 GBps LSP with priority 1 is
created, the LSP with priority 3 is prehempted and its resouces (or
part of them) are allocated to the LSP with higher priority. The
OTN-ISCD sub-TLV related to component link 2 is updated accordingly
to Figure 7:
Ceccarelli, et al. Expires September 9, 2010 [Page 15]
Internet-Draft OSPF-TE extensions for OTN support March 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P0 =32 | Unreserved TS at p0 =32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P1 =20 | Unreserved TS at p1 =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P2 =20 | Unreserved TS at p2 =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P3 =20 | Unreserved TS at p3 =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P4 =20 | Unreserved TS at p4 =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P5 =20 | Unreserved TS at p5 =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P6 =20 | Unreserved TS at p6 =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max lsp TS at P7 =20 | Unreserved TS at p7 =20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Example - OTN-ISCD OTU3 LC (t2)
8. Security Considerations
This document 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.
9. IANA Considerations
TBD
10. Contributors
Ceccarelli, et al. Expires September 9, 2010 [Page 16]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Xiaobing Zi
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Email: zixiaobing@huawei.com
Francesco Fondelli
Ericsson
Via Negrone 1/A
Genova - 16145
Email: francesco.fondelli@ericsson.com
Marco Corsi
Altran Italia
Via Negrone 1/A
Genova - 16145
EMail: marco.corsi@altran.it
11. Acknowledgements
The authors would like to thank Eric Gray for his precious comments
and advices.
12. References
Ceccarelli, et al. Expires September 9, 2010 [Page 17]
Internet-Draft OSPF-TE extensions for OTN support March 2010
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
12.2. Informative References
[G.709] ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation (and Amendment 1),
February 2001.
[G.709-v3]
ITU-T, "Draft revised G.709, version 3", consented
by ITU-T on Oct 2009.
[Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement)",
December 2008.
Ceccarelli, et al. Expires September 9, 2010 [Page 18]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Authors' Addresses
Daniele Ceccarelli
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
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
Yunbin Xu
CATR
11 Yue Tan Nan Jie
Beijing
P.R.China
Email: xuyunbin@mail.ritt.com.cn
Ceccarelli, et al. Expires September 9, 2010 [Page 19]
