CCAMP Working Group D. Ceccarelli
Internet-Draft D. Caviglia
Intended status: Standards Track Ericsson
Expires: March 4, 2011 F. Zhang
D. Li
Huawei Technologies
Y. Xu
CATR
S. Belotti
P. Grandi
Alcatel-Lucent
J. Drake
Juniper
August 31, 2010
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS)
Control of Evolving G.709 OTN Networks
draft-ceccarelli-ccamp-gmpls-ospf-g709-03
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 March 4, 2011.
Ceccarelli, et al. Expires March 4, 2011 [Page 1]
Internet-Draft OSPF-TE extensions for OTN support August 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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Generalized Interface Switching Capability Descriptor . . 4
2.2. Example using Generalized-ISCD . . . . . . . . . . . . . . 8
3. Scalability Improvement . . . . . . . . . . . . . . . . . . . 14
4. Compatibility Considerations . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Ceccarelli, et al. Expires March 4, 2011 [Page 2]
Internet-Draft OSPF-TE extensions for OTN support August 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 service 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 March 4, 2011 [Page 3]
Internet-Draft OSPF-TE extensions for OTN support August 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 Generalized-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 a Generalized-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. Generalized Interface Switching Capability Descriptor
The Generalized Interface Switching Capability Descriptor has a so
generic format that it can be used for the advertisement of any type
of technology, from SDH/SONET to OTN, from L2SC to PSC etc. The main
difference from the ISCD defined in [RFC4202] is the fact that
unreserved bandwidth is advertised per service type per priority.
The format of the Generalized-ISCD is illustrated in Figure 1.
Ceccarelli, et al. Expires March 4, 2011 [Page 4]
Internet-Draft OSPF-TE extensions for OTN support August 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type |M|T|S| Reserved |Prior|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type |M|T|S| Reserved |Prior|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type |M|T|S| Reserved |Prior|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type |M|T|S| Reserved |Prior|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Generalized-ISCD format
Where:
o Switching Capability (8 bits): the values for this field are
defined in [RFC4203] section 1.4.
o Encoding (8 bits): the values for this field are defined in
[RFC3471] section 3.1.1 and [RFC4328] section 3.1.1 o Data Blaocks:
Data blocks are composed by 64 bits and contain Service Type, Flags,
Priority and Bandwidth. For the definition of each field refer
below.
The number of data blocks depends on the number of service types and
priority supported. Blocks declared in the LSA MUST contain a
supported service type. Blocks declaring bandwidth at priority Pi,
MUST NOT be declared in case priority Pi is not supported by the
network element.
Data blocks SHOULD be ordered from the highest to the lowest
priority. If no priority is supported, just the 0 priority MUST be
advertised.
Ceccarelli, et al. Expires March 4, 2011 [Page 5]
Internet-Draft OSPF-TE extensions for OTN support August 2010
Please see the Example section for further details.
o Service Type (8 bits): Indicates the type of ODU supported by TE
link. Possible values are:
o 0 - ODU0
o 1 - ODU1
o 2 - ODU2
o 3 - ODU3
o 4 - ODU4
o 5 - ODU2e
o 6 - ODUflex non resizable
o 7 - ODUflex resizable
Each ODUk in a TE-link can be advertised only once for each supported
priority.
o Flags (3 bits):
* M flag : This flag defines the meaning of the Bandwidth field.
In case the bit is clear, it indicates that the Bandwidth field is
indicating resource availability, while if it set, it indicates
ODUFlex max LSP bandwidth (espressed in Bytes/s):
0 - Unreserved bandwidth at priority Pi expressed in number of
TS
1 - Max LSP bandwidth at priority Pi expressed in number of TS
In case an ODUFlex service types is advertised, two data block per
priority MUST be advertised, the first one with M bit clear
(indicating the unreserved bandwidth available for such
combination of service type and priority) and the second one with
the M bit set (indicating the max LSP bandiwidth). Please see
Figure 2 for further clarification.
Ceccarelli, et al. Expires March 4, 2011 [Page 6]
Internet-Draft OSPF-TE extensions for OTN support August 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service Type(7)|0|T|S| Reserved | P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth @ P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service Type(7)|1|T|S| Reserved | P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth @ P1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service Type(7)|0|T|S| Reserved | P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth @ P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service Type(7)|1|T|S| Reserved | P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth @ P5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Generalized-ISCD for ODUFlex
* T flag : When the flag is set, the node is advertising its
capability of terminating the related service type.
0 - Advertised service type cannot be terminated
1 - Advertised service type can be terminated
* S flag : When the flag is set, the node is advertising its
capability of switching the related service type.
0 - Advertised service type cannot be switched
1 - Advertised service type can be switched
In case a service type can be switched or terminated, both bits
MUST be set.
o Priority (3 bits): Indicates the priority related to the advertised
service type. Only supported priorities MUST be advertised.
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
Ceccarelli, et al. Expires March 4, 2011 [Page 7]
Internet-Draft OSPF-TE extensions for OTN support August 2010
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 TSs, not 44 TSs.
All the reserved fields MUST be set to zero and SHOULD be ignored
when received.
2.2. Example using Generalized-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.
+------+ 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.
All the service types can be switched and only the ODU3 can be both
switched and terminated. 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:
Ceccarelli, et al. Expires March 4, 2011 [Page 8]
Internet-Draft OSPF-TE extensions for OTN support August 2010
< G.709 Digital Link > ::= < Link Type > < Link ID > < Link
Local/Remote Identifiers > < Generalized-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 Generalized-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 Generalized-ISCD sub-TLV would be advertised 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SC = TDM | Enc = G709 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
Ceccarelli, et al. Expires March 4, 2011 [Page 9]
Internet-Draft OSPF-TE extensions for OTN support August 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example - Generalized-ISCD sub-TLV(to)
Suppose that at time t1 an ODUflex LSP is created allocating 35 Gbps
at priority 3. The Generalized-ISCD sub-TLV will be modified 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
Ceccarelli, et al. Expires March 4, 2011 [Page 10]
Internet-Draft OSPF-TE extensions for OTN support August 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SC = TDM | Enc = G709 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+4=12 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+4=12 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 0 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 0 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P3 |
Ceccarelli, et al. Expires March 4, 2011 [Page 11]
Internet-Draft OSPF-TE extensions for OTN support August 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+4=12 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+4=12 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example - Generalized-ISCD sub-TLV(t1)
The last example shows how the prehemption is managed. In
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
Generalized-ISCD sub-TLV is updated accordingly to Figure 6:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU0) |0|0|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+20=28 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P3 |
Ceccarelli, et al. Expires March 4, 2011 [Page 12]
Internet-Draft OSPF-TE extensions for OTN support August 2010
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+20=28 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU1) |0|0|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+20=28 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S.Type(ODU3) |0|1|1| Reserved | P7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|0|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth 8+32=40 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.Type(ODUFlex)|1|0|1| Reserved | P3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max LSP Bandwidth 32 TS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example - Generalized-ISCD (t2)
Ceccarelli, et al. Expires March 4, 2011 [Page 13]
Internet-Draft OSPF-TE extensions for OTN support August 2010
3. Scalability Improvement
TBD
4. 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 a Generalized-ISCD sub-TLV. They will continue to flood
the LSA to other neighbors, but will not use the information carried
in this LSA.
5. 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.
6. IANA Considerations
TBD
7. Contributors
Xiaobing Zi, Huawei Technologies
Email: zixiaobing@huawei.com
Francesco Fondelli, Ericsson
Email: francesco.fondelli@ericsson.com
Marco Corsi, Altran Italia
Ceccarelli, et al. Expires March 4, 2011 [Page 14]
Internet-Draft OSPF-TE extensions for OTN support August 2010
EMail: marco.corsi@altran.it
Eve Varma, Alcatel-Lucent
EMail: eve.varma@alcatel-lucent.com
Jonathan Sadler, Tellabs
EMail: Jonathan.Sadler@tellabs.com
8. Acknowledgements
The authors would like to thank Eric Gray for his precious comments
and advices.
9. References
9.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.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
Ceccarelli, et al. Expires March 4, 2011 [Page 15]
Internet-Draft OSPF-TE extensions for OTN support August 2010
[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.
9.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.
Authors' Addresses
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
Ceccarelli, et al. Expires March 4, 2011 [Page 16]
Internet-Draft OSPF-TE extensions for OTN support August 2010
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
Sergio Belotti
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: sergio.belotti@alcatel-lucent.com
Ceccarelli, et al. Expires March 4, 2011 [Page 17]
Internet-Draft OSPF-TE extensions for OTN support August 2010
Pietro Vittorio Grandi
Alcatel-Lucent
Via Trento, 30
Vimercate
Italy
Email: pietro_vittorio.grandi@alcatel-lucent.com
John E Drake
Juniper
Email: jdrake@juniper.net
Ceccarelli, et al. Expires March 4, 2011 [Page 18]
