CCAMP Working Group D. Ceccarelli
Internet-Draft D. Caviglia
Intended status: Standards Track Ericsson
Expires: January 10, 2011 F. Zhang
D. Li
Huawei Technologies
Y. Xu
CATR
S. Belotti
P. Grandi
Alcatel-Lucent
July 9, 2010
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS)
Control of Evolving G.709 OTN Networks
draft-ceccarelli-ccamp-gmpls-ospf-g709-02
Abstract
The recent revision of ITU-T Recommendation G.709 [G709-V3] has
introduced new fixed and flexible ODU containers, enabling optimized
support for an increasingly abundant service mix.
This document describes OSPF 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."
This Internet-Draft will expire on January 10, 2011.
Copyright Notice
Ceccarelli, et al. Expires January 10, 2011 [Page 1]
Internet-Draft OSPF-TE extensions for OTN support July 2010
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. OTN Interface Switching Capability Descriptor . . . . . . 4
2.2. Example using OTN-ISCD . . . . . . . . . . . . . . . . . . 9
3. Compatibility Considerations . . . . . . . . . . . . . . . . . 16
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Ceccarelli, et al. Expires January 10, 2011 [Page 2]
Internet-Draft OSPF-TE extensions for OTN support July 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 purposes. 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 GMPLS enabled G.709 Optical Transport Networks (OTNs), routing
serves as the foundation for automatically establishing ODUk
connections through GMPLS RSVP-TE signaling.
G.709 OTN [G709-V3] 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 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.
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].
This document describes OSPF LSA extensions to support the G.709v3
OTNs under the control of GMPLS.
The routing information for Optical Channel Layer (OCh) (i.e.,
wavelength) is out of the scope of this document. Please refer to
Ceccarelli, et al. Expires January 10, 2011 [Page 3]
Internet-Draft OSPF-TE extensions for OTN support July 2010
[WSON-Frame] for further information.
2. OSPF 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 LSA can carry a top-level link TLV with several nested sub-
TLVs to describe different attributes of a TE link. Two top-level
TLVs are defined in [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].
This document defines a new link sub-TLV, called OTN ISCD sub-TLV
(Sub-tlv value TBA by IANA, suggested 26).
One or more component links can be bundled as a TE link. In case of
link bundling an OTN-ISCD will be used to describe several component
links.
As discussed in [OTN-FWK]and [OTN-INFO], usage of multi-stage
multiplexing implies the advertisement of cascaded adaptation
capabilities together with matrix access constraints. Modifications
to ISCD/IACD [RFC4202][RFC5339] and [MLN-EXT], if needed, are for
further study.
2.1. OTN Interface Switching Capability Descriptor
The format of the OTN Interface Switching Capability Descriptor is
defined in Figure 1.
Ceccarelli, et al. Expires January 10, 2011 [Page 4]
Internet-Draft OSPF-TE extensions for OTN support July 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|7| T | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... ... ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type |F| Bandwidth @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: OTN-ISCD format
Where:
Ceccarelli, et al. Expires January 10, 2011 [Page 5]
Internet-Draft OSPF-TE extensions for OTN support July 2010
o Switching Capability (8 bits): the values for this field are
defined in [RFC4203] section 1.4. The only valid value is 100 (TDM).
o Encoding (8 bits): the values for this field are defined in
[RFC3471] section 3.1.1 and [RFC4328] section 3.1.1 and the only
possible ones are:
o 7 - Digital Wrapper
o 8 - Lambda (Photonic)
o 12 - G.709 ODUk (Digital Path)
o 13 - G.709 Optical Channel
o Priority flags (8 bits): Indicate the priorities supported on the
advertised link. When the flag is set, the corresponding priority is
supported. As per IETF definition the highest priority is 0 and the
lowest is 7.
o T (3 bits): Indicates the type of the Tributary Slot of the
advertised TE link. Possible values are:
o 0 - 1.25 Gbps
o 1 - 2.5 Gbps
o 2-7 for future uses
o Data Rows: Data rows contain Signal type, Field Qualifier(F) and
bandwidth at priority Pi. For the definition of each field refer
below.
The number of data rows depends on the number of signal types and
priority supported. Rows declared in the LSA MUST contain a
supported signal type. Rows declaring bandwidth at priority Pi, MUST
NOT be declared in case the flag associated to priority Pi is set to
0.
Data "rows" are ordered from the highest to the lowest priority. If
no priority is supported, just the 0 priority MUST be advertised.
Please see the Example section for further details.
o Signal Type (8 bits): Indicates the type of ODU/OTU supported by TE
link. Different Signal Types are defined for full lambda and sub-
lambda capabilities. Possible values are:
Ceccarelli, et al. Expires January 10, 2011 [Page 6]
Internet-Draft OSPF-TE extensions for OTN support July 2010
o 0 - ODU0 (sub-lambda)
o 1 - ODU1 (sub-lambda)
o 2 - ODU2 (sub-lambda)
o 3 - ODU3 (sub-lambda)
o 4 - ODU4 (sub-lambda)
o 5 - ODU2e 8TSs (sub-lambda)
o 6 - ODU2e 9TSs (sub-lambda)
o 7 - ODUflex inside ODU1 (sub-lambda)
o 8 - ODUflex inside ODU2 (sub-lambda)
o 9 - ODUflex inside ODU3 (sub-lambda)
o 10 - ODUflex inside ODU4 (sub-lambda)
o 11 - ODUflex*
o 12 - ODUflex resizable inside ODU1 (sub-lambda)
o 13 - ODUflex resizable inside ODU2 (sub-lambda)
o 14 - ODUflex resizable inside ODU3 (sub-lambda)
o 15 - ODUflex resizable inside ODU4 (sub-lambda)
o 16 - ODUflex resizable*
o 20 - ODU1 (Full Lambda)
o 21 - ODU2 (Full Lambda)
o 22 - ODU3 (Full Lambda)
o 23 - ODU4 (Full Lambda)
o 24 - ODU2e (Full Lambda)
* Please note that a distinction between different ODUflex signal
types is needed, for path computation scopes, when optimizing the
number of TS used depending on the server layer (i.e. OTUk). If
such distinction is not needed, the value 11 must be used for non
Ceccarelli, et al. Expires January 10, 2011 [Page 7]
Internet-Draft OSPF-TE extensions for OTN support July 2010
resizable ODU-flex and the value 16 must be used for ODU-flex
resizable.
Each ODUk in a component link can be advertised only once, either as
sub-lambda bandwidth or full lambda bandwidth.
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.
In the GMPLS based OTN networks, the Unreserved Bandwidth of a
(bundled) TE link is the sum of the unreserved bandwidths of all the
component links in the (bundled) TE-link.
o Flag F (1 bits): This flag defines the meaning of the following
field. It can assume the following values:
0 - Unreserved bandwidth at priority Pi expressed in number of TS
1 - Max LSP bandwidth at priority Pi expressed in number of TS
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 in 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.
In case of non flexible signal type (i.e. non ODUflex) the bit MUST
be ignored and set to 0. In case of flexible signal type both
records MUST be included: Unreserved resources per priority and MAX
LSP bandwidth per priority.
Ceccarelli, et al. Expires January 10, 2011 [Page 8]
Internet-Draft OSPF-TE extensions for OTN support July 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |0| Unreserved resources per signal type @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7<=ST<=12 |1| Max LSP Bandwidth (ODUflex) @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: OTN-ISCD for ODUFlex
All the reserved fields MUST be set to zero and SHOULD be ignored
when received.
2.2. Example using OTN-ISCD
The examples in the following pages are not normative and are not
intended to infer or mandate any specific implementation. Figure 3
shows the case of a TE-link composed of two component links.
Ceccarelli, et al. Expires January 10, 2011 [Page 9]
Internet-Draft OSPF-TE extensions for OTN support July 2010
+------+ component link 1 +------+
| +------------------+ |
| N1 +------------------+ N2 |
| | component link 2 | |
+--+---+ +---+--+
Figure 3: Example
The link type of the two component links are OTU2 and OTU3
respectively. The former has the capability of carrying ODU0, ODU1
and ODUflex client signals, while the latter, ODU1, ODU3 and ODUflex.
The TS type is 1.25Gbps and the supported priorities are:0, 3 and 7.
In this example the two component links are bundled as a TE link but
it could also be 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 can get the link
remote ID automatically or manually.
N1 can generate an LSA to describe the above attributes of the TE
link. If we 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 ISCD >
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.
o OTN ISCD 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 OTN ISCD sub-TLV would be advertised as follows:
Ceccarelli, et al. Expires January 10, 2011 [Page 10]
Internet-Draft OSPF-TE extensions for OTN support July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SC = TDM | Enc = G709 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0|1|0|0|1|T1.25| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0(0) |0| 8 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0(0) |0| 8 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0(0) |0| 8 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1(1) |0| 8+32 = 40 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1(1) |0| 8+32 = 40 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1(1) |0| 8+32 = 40 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU3(22)|0| 32 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU3(22)|0| 32 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU3(22)|0| 32 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU2(21)|0| 8 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU2(21)|0| 8 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU2(21)|0| 8 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |0| 8+32 = 40 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |0| 8+32 = 40 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |0| 8+32 = 40 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|1| 32 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|1| 32 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|1| 32 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example - OTN-ISCD sub-TLV(to)
Suppose that at time t1 an ODUflex LSP is created allocating 35 Gbps
Ceccarelli, et al. Expires January 10, 2011 [Page 11]
Internet-Draft OSPF-TE extensions for OTN support July 2010
at priority 3. The OTN ISCD sub-TLV will be modified as follows:
Ceccarelli, et al. Expires January 10, 2011 [Page 12]
Internet-Draft OSPF-TE extensions for OTN support July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SC = TDM | Enc = G709 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0|1|0|0|1|T1.25| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0(0) |0| 8 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0(0) |0| 8 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0(0) |0| 8 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1(1) |0| 8+32 = 40 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1(1) |0| 8+4 = 12 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1(1) |0| 8+4 = 12 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU3(22)|0| 32 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU3(22)|0| 0 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU3(22)|0| 0 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU2(21)|0| 8 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU2(21)|0| 8 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU2(21)|0| 8 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |0| 8+32 = 40 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |0| 8+4 = 12 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |0| 8+4 = 12 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |1| 32 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |1| 8 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex |1| 8 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example - OTN-ISCD sub-TLV(t1)
The last example shows how the prehemption is managed. In
Ceccarelli, et al. Expires January 10, 2011 [Page 13]
Internet-Draft OSPF-TE extensions for OTN support July 2010
particular, if at time t2 a new 15 GBps ODUflex LSP with priority 0
is created, the LSP with priority 3 is pre-empted and its resources
(or part of them) are allocated to the LSP with higher priority. The
OTN ISCD sub-TLV is updated accordingly to Figure 6:
Ceccarelli, et al. Expires January 10, 2011 [Page 14]
Internet-Draft OSPF-TE extensions for OTN support July 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SC = TDM | Enc = G709 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|0|1|0|0|1|T1.25| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0 |0| 8 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0 |0| 8 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU0 |0| 8 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1 |0| 8+20 = 28 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1 |0| 8+20 = 28 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODU1 |0| 8+20 = 28 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=OTU3 |0| 0 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=OTU3 |0| 0 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=OTU3 |0| 0 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=OTU2 |0| 8 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=OTU2 |0| 8 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=OTU2 |0| 8 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|0| 8+20 = 28 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|0| 8+20 = 28 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|0| 8+20 = 28 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|1| 20 TS @ P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|1| 20 TS @ P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SType=ODUflex|1| 20 TS @ P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example - OTN-ISCD (t2)
Ceccarelli, et al. Expires January 10, 2011 [Page 15]
Internet-Draft OSPF-TE extensions for OTN support July 2010
3. Compatibility Considerations
The legacy nodes that do not implement the extensions defined in this
document are able, per [RFC3630] section 4, 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.
4. 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.
5. IANA Considerations
TBD
6. Contributors
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
Ceccarelli, et al. Expires January 10, 2011 [Page 16]
Internet-Draft OSPF-TE extensions for OTN support July 2010
Genova - 16145
Email: francesco.fondelli@ericsson.com
Marco Corsi
Altran Italia
Via Negrone 1/A
Genova - 16145
EMail: marco.corsi@altran.it
7. Acknowledgements
The authors would like to thank Eric Gray for his precious comments
and advices.
8. References
8.1. Normative References
[MLN-EXT] D.Papadimitriou, M.Vigoureux, K.Shiomoto, D.Brungard, J.Le
Roux, "Generalized Multi-Protocol Extensions for Multi-
Layer and Multi-Region Network (MLN/MRN)", February 2010.
[OTN-FWK] F.Zhang, D.Li, H.LI, S.Belotti, "Framework for GMPLS and
PCE Control of G.709 Optical Transport networks, work in
progress draft-ietf-ccamp-gmpls-g709-framework-02",
July 2010.
[OTN-INFO]
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-bddg-ccamp-otn-g709-info-model-01", July 2010.
[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.
Ceccarelli, et al. Expires January 10, 2011 [Page 17]
Internet-Draft OSPF-TE extensions for OTN support July 2010
[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.
[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.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
[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.
8.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 January 10, 2011 [Page 18]
Internet-Draft OSPF-TE extensions for OTN support July 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 January 10, 2011 [Page 19]
Internet-Draft OSPF-TE extensions for OTN support July 2010
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
Ceccarelli, et al. Expires January 10, 2011 [Page 20]