Internet DRAFT - draft-belgra-ccamp-gmpls-ospf-g709
draft-belgra-ccamp-gmpls-ospf-g709
CCAMP Working Group S.Belotti
Internet Draft P.Grandi
Intended status: Standards Track Alcatel-Lucent
Expires: September 2010 March 22, 2010
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS)
Control of Evolving G.709 OTN Networks
draft-belgra-ccamp-gmpls-ospf-g709-00
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), 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 22, 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
Belotti & Grandi Expires September 22, 2010 [Page 1]
Internet-Draft OSPF-TE extensions for OTN support March 2010
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.
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.
Table of Contents
1. Introduction.................................................2
2. Conventions used in this document............................3
3. OSPF Requirements............................................4
4. Overview of G.709............................................4
5. G.709 Digital Layer TE Information...........................6
5.1. Tributary Slot type.....................................7
5.2. Signal type.............................................8
5.3. Unassigned Resources....................................9
5.4. Maximum LSP Bandwidth...................................9
5.5. Total number of resources..............................10
6. OSPF Extensions.............................................10
6.1. OTN Interface Switching Capability Descriptor..........10
7. Compatibility Considerations................................13
8. Example.....................................................13
9. Security Considerations.....................................19
10. IANA Considerations........................................19
11. Contributors...............................................19
12. References.................................................19
12.1. Normative References..................................19
12.2. Informative References................................20
13. Acknowledgments............................................20
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
Belotti & Grandi Expires September 22, 2010 [Page 2]
Internet-Draft OSPF-TE extensions for OTN support March 2010
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 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 a GMPLS enabled G.709 Optical Transport Networks (OTN), routing is
fundamental in order to allow automatic calculation of routes for
ODUk LSPs signaled via RSVP-TE protocol.
The recent revision of ITU-T Recommendation G.709 [G709-V3] has
introduced new fixed and flexible ODU containers that augment those
specified in foundation OTN. As a result, it is necessary to provide
OSPF routing protocol extensions to allow Generalized MPLS (GMPLS)
control of all currently defined ODU containers, in support of sub-
lambda and lambda level routing granularity. This document describes
these OSPF routing protocol extensions. 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. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
Belotti & Grandi Expires September 22, 2010 [Page 3]
Internet-Draft OSPF-TE extensions for OTN support March 2010
3. 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 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.
Thus, it is necessary to define a 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:
o Support all standard fixed and flexible ODUs; i.e., all G.709 ODUs
including ODUflex. As opposed to fixed size containers, for
ODUflex it is necessary to declare the maximum LSP bandwidth.
o 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).
Recommendation G.872 suggests to limit electrical multiplexing
stages at one per domain. The distinction between service and line
rate capacity allows drawing ODU LSPs that cannot be further
nested in other ODU LSPs
[Note from the authors: an example will be inserted in next
release]
o 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.
o Support priority for restoration.
4. Overview of G.709
The foundation 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 TS (Tributary Slots) with granularity of
2.5Gbps) of OPUk (Optical Channel Payload Unit-k) where j<k. The
Belotti & Grandi Expires September 22, 2010 [Page 4]
Internet-Draft OSPF-TE extensions for OTN support March 2010
ODUj can also be mapped into OTUj (Optical Channel Transport Unit-
j,j=1, 2 or 3)directly.
Foundation OTN structures and formats were designed to provide an
easily evolvable modular approach, enabling its smooth evolution to
include new ODU containers. Examples of new fixed containers include
the ODU0 that was optimized to support 1 GbE client signals, and the
ODU4 that was optimized to support transport of emerging new 100 GbE
services (and also designed to be a server capable of carrying all
current and future OTN services). In addition, distinct from these
fixed size containers, the new ODUflex enables service providers to
allocate bandwidth as needed by each logical connection within a
physical interface.
Client signals are mapped into lower order ODUs, and these lower
order ODUs are either mapped directly into an OTU, or multiplexed
into a higher order ODU that has a 1:1:1 relationship with the OTU
and OCh. This results in the introduction of two digital layer
networks, the ODU and OTU.
Tables 1 and 2 [G.872Am2-draft] describes ODU clients, as well as
relevant client/server roles and relationships.
Table 1 - Set of ODU clients and their ODU servers
[Table provided in pdf version]
Belotti & Grandi Expires September 22, 2010 [Page 5]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Table 2 -ODU clients and their OTU server
[Table provided in pdf version]
Each higher order ODU has a defined number of TSs at either a bit-
rate of nominally 1.25Gbit/s or 2.5Gbit/s. Lower order ODUs that are
mapped into higher order ODUs are mapped into the required number of
TSs.
Links can only work using one TS type. For example, if both ends (or
interfaces) of a link support both 2.5Gbps TS and 1.25Gbps TS, then
one of the two TS types MUST be adopted by both link ends as link TS
type. The choice can be either operated manually or automatically 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.
5. G.709 Digital Layer TE Information
As may be seen from Tables 1 and 2, some types of ODUs (i.e., ODU1,
ODU2, ODU3, ODU4) may assume either a client or server role within
the context of a particular networking domain.
An ODU mapped directly into an OTU server in a particular networking
domain, as per Table 2, only uses the line rate capacity (OTUk
capacity) and cannot be further electrically multiplexed. Within
this draft, the term "line rate LSP" refers to the role of an ODU
that has been mapped directly into an OTU server (e.g., a line rate
10Gbit/s can only traverse OTU2 links). A line rate LSP always has a
capacity equivalent to a single lambda and may be carried over one or
more wavelength sub-networks connected by optical links. A line rate
LSP cannot be further multiplexed into a larger electrical container.
Within a particular networking domain, ODUs that are further
electrically multiplexed into higher order ODUs may be carried over
various types of links. The term "service rate LSP" may be used for
describing the role of an ODU that will be further multiplexed within
the networking domain (reinforcing the distinction between the
service rate and 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.
Belotti & Grandi Expires September 22, 2010 [Page 6]
Internet-Draft OSPF-TE extensions for OTN support March 2010
To summarize, you can think of ODUs serving various roles that may
change in traversing a network; i.e., "service rate" LSP roles (used
to carry client traffic) and "line rate" LSP roles (used to build
infrastructure). These roles must be considered and distinguished
from a path computation perspective. As a conclusion we have to
advertise multiplexed and line-rate ODU resources separately.
As detailed in [FWRK-OTN],client ODUs can be carried over:
o Case A) one or more wavelength sub-networks connected by optical
links or
o Case B) a line rate LSP or
o Case C) a mix of line rate LSPs and wavelength sub-networks.
This document only considers the TE information needed for ODU path
computation, considering both service and line rate LSP roles.
The following sections list and analyze each type of data that needs
to be advertised in order to support path computation.
The data structure format and the possible values are shown in
section 6.
Routing in wavelength sub-networks is outside the scope of this
document. Please refer to [WSON-OSPF] for more information about WSON
routing information.
Coordination of path set-up in hybrid cases (like case C) is out of
the scope of this document being already covered by Multi-region
networks RFCs. [RFC5212] [RFC5339] [MLN-EXT]
5.1. Tributary Slot type
ITU-T recommendations define two types of TS but links can only work
using one TS type. For example, if both ends (or interfaces) of a
link support both 2.5Gbps TS and 1.25Gbps TS, then one of the two TS
types MUST be adopted by both link ends as link TS type. The choice
can be either operated manually or automatically (using LMP).
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.
In addition, the bandwidth accounting depends on the type of TS.
Therefore, the type of the TS should be known during path
computation.
Belotti & Grandi Expires September 22, 2010 [Page 7]
Internet-Draft OSPF-TE extensions for OTN support March 2010
5.2. Signal type
It is possible that some equipments cannot support all the signal
types.
When a path computation procedure for an LSP is performed, it is
needed to check whether a link has the capability to carry a specific
type of signal or not.
In case of line rate LSPs, in addition, it is also needed to check
whether a link has enough available bandwidth at the line rate.
It is thus required that resources at the line rate are distinguished
with respect to resources that can be multiplexed.
If a link does not support the requested signal, it should be
excluded from path computation. Only the links with the capability of
carrying the requested type of signal 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).
Belotti & Grandi Expires September 22, 2010 [Page 8]
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 : Signal type
5.3. Unassigned Resources
In the GMPLS based OTN networks, the unassigned resources of a TE
link indicates the number of resources of a certain signal type that
are free to be assigned.
It is the sum of all the unassigned resources associated to the same
signal type on all component links.
Unassigned resources are accounted per signal type and priority.
This information is mandatory.
5.4. 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, in a TE-Link composed by a 10 G component link and one
40 G component link, the maximum LSP bandwidth when no LSP has yet
been instantiated is equivalent to 32 tributary slots.
The maximum LSP bandwidth is meaningful only for resources like
ODUflex whose size is not known in advance.
The maximum LSP bandwidth is accounted per signal type and priority.
This information is mandatory
Belotti & Grandi Expires September 22, 2010 [Page 9]
Internet-Draft OSPF-TE extensions for OTN support March 2010
5.5. Total number of resources
In the GMPLS based OTN networks, the total number of resources of a
TE link indicates the number of resources of a certain signal type
that are present in a TE-Link.
The total number of resource depends only from the signal types
supported by the component links and does not change in time.
In restoration scenarios, this information together with the
unassigned resources information allows to calculate how many
resources could be pre-empted. It is possible to use this information
in order to minimize crank-backs.
This information is not mandatory.
6. OSPF Extensions
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 6.1.
One or more component links can be bundled as a TE link.
One or more TE-links can be bundled in a bundled TE-link
6.1. OTN Interface Switching Capability Descriptor
The format of the new OTN-Interface Switching Capability Descriptor
is defined in Figure 2.
Belotti & Grandi Expires September 22, 2010 [Page 10]
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Signal Type| Reserved | TNR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |Signal Type| P |Res | UR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |Signal Type| P |Res | Max LSP bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Reserved (30 bits): For future use. Must be set to zero when sent
and should be ignored when received.
o RT = record type (2 bits) : Indicates the format of the entry. The
following values are defined :
0: third raw in figure 2, entry indicates "signal type" and the
"total number of resources per signal type" provided by TE-link,
no priority
1: fourth raw in figure 2, entry indicates "signal type",
"priority" and "unassigned resources per signal type"
2: fifth raw in figure 2, entry indicates "signal type",
"priority" and "Max LSP bandwidth"
o Signal Type (6 bits): Indicates the type of signal. Type of signal
are split in 2 different categories :
. Line rate capacity --> used to declare the bandwidth coupled to
the line rate capacity (OTUk capacity). These are the values
associated :
0: reserved
Belotti & Grandi Expires September 22, 2010 [Page 11]
Internet-Draft OSPF-TE extensions for OTN support March 2010
1: LR-ODU-1
2: LR-ODU-2
3: LR-ODU-3
4: LR-ODU-4
. Multiplexed capacity --> used to declare the bandwidth coupled
to containers that can be multiplexed and carried by an higher
order ODU (HO-ODU). These are the values associated :
10: ODU-0
11: ODU-1
12: ODU-2
13: ODU-3
14: ODU-4
15: ODU2e (to be used as alternative to 16 and 17 when it is
not required to differentiate per number of used TS)
16: ODU2e-8TS (to be used when servers require 8 TS)
17: ODU2e-9TS (to be used when servers require 9 TS)
18: ODUflex (used for non resizable ODU-flex)
19: ODUflex-R (used for resizable ODU-flex)
o TNR = Total number of resources (18 bits): Indicates the number of
resources per signal type provided by TE link independently per
priority. The measurement unit is "number of ODUs" for all signal
type but "ODU-flex" and "ODU-flex resizable" for which the
measurement unit is "number of TS".
o P = Priority (3 bits): Indicates a number between 0 and 7 (usual
IETF priorities). Note that only effectively supported priorities
have to be declared.
o UR = Unassigned resources: Indicates the number of resources of a
certain signal type that are free to be assigned. The measurement
unit is "number of ODUs" for all signal type but "ODUflex" and
"ODUflex-R" for which the measurement unit is "number of TS".
Belotti & Grandi Expires September 22, 2010 [Page 12]
Internet-Draft OSPF-TE extensions for OTN support March 2010
o Max LSP bandwidth (18 bits): It is related to ODUflex and
indicates the maximum bandwidth that an ODUflex can occupy in a TE
link. It is expressed in number of TS.
7. 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.
8. Example
Based on the sub-TLVs defined in [RFC 3630], [RFC 4203] a G.709
digital TE link is represented as a set of component links.
+------+ component link 1 +------+
| +------------------+ |
| N1 +------------------+ N2 |
| | component link 2 | |
+--+---+ +---+--+
Figure 3 : Example
Figure 3 shows two network elements N1 and N2 connected by two
component links.
Component link 1 is a 10G link and as such it has the capability of
carrying ODU-2 signal at line rate. ODU-1 or ODU-flex resizable
signals can be multiplexed in the line rate ODU-2.
Component link 2 is a 40G link and as such it has the capability of
carrying ODU-3 signal at line rate. ODU-1, ODU-2 or ODU-flex
resizable signals can be multiplexed in the line rate ODU-3.
The Tributary Slot type is 1.25Gbps
Only priorities 0 and 7 are supported.
In this example the two component links are bundled together and
advertised as a single TE-Link using a single ISCD.
Nodes N1 and N2 should assign a link local ID to the TE link. N1 and
N2 then may obtain the link remote ID automatically or manually.
Belotti & Grandi Expires September 22, 2010 [Page 13]
Internet-Draft OSPF-TE extensions for OTN support March 2010
N1 and N2 generate an LSA carrying a link TLV with at least the
following information: Link Type, Link ID, Link Local/Remote
Identifier and OTN ISCD.
OTN Interface Switching Capability Descriptor sub-TLV: Defined in
this document, carries the characteristic of this G.709 digital TE
link.
The following examples will show how the ISCD evolve since the
creation of the TE-Link.
It is examined a sequence of events consisting of:
o ODU-1 LSP set-up at priority 7 with allocation of resources on
component link 1
o ODU-flex resizable LSP set up at priority 0 with allocation of
resources on component link 2
o ODU-2 LSP at priority 0 that preempts the ODU-1 LSP
The examples in the following pages are not NORMATIVE and are not
intended to mandate or discuss any specific implementation.
Belotti & Grandi Expires September 22, 2010 [Page 14]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Just after the creation of the TE Link comprising the two component
links the ISCD is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|00 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-2 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-3 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-1 | Reserved | Total number of resources = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-2 | Reserved | Total number of resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODUflex-R | Reserved | Total number of resources = 40(TS)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=0| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=0| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=0| Res | Unassigned resources = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=0| Res | Unassigned resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=0| Res | Max LSP Bandwidth = 32 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=0| Res | Unassigned resources = 40 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=7| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=7| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=7| Res | Unassigned resources = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=7| Res | Unassigned resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=7| Res | Unassigned resources = 40 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=7| Res | Max LSP Bandwidth = 32 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Belotti & Grandi Expires September 22, 2010 [Page 15]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Suppose now that due to a new LSP signaling N1 and N2 decide to
allocate an ODU-1 at priority 7 subtracting resources at the 10G
link. The ISCD changes 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|00 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-2 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-3 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-1 | Reserved | Total number of resources = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-2 | Reserved | Total number of resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODUflex-R | Reserved | Total number of resources = 40(TS)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=0| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=7| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=0| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=7| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=0| Res | Unassigned resources = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=7| Res | Unassigned resources = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=0| Res | Unassigned resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=7| Res | Unassigned resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=0| Res | Unassigned resources = 40 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=7| Res | Unassigned resources = 38 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=0| Res | Max LSP Bandwidth = 32 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=7| Res | Max LSP Bandwidth = 32 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Belotti & Grandi Expires September 22, 2010 [Page 16]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Suppose now that due to another LSP signaling N1 and N2 decide to
allocate an ODU-flex resizable that uses 25 TS at priority 0
subtracting resources at the 40G link. The ISCD changes 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|00 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-2 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-3 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-1 | Reserved | Total number of resources = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-2 | Reserved | Total number of resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODUflex-R | Reserved | Total number of resources = 40(TS)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=0| Res | Unassigned resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=7| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=0| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=7| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=0| Res | Unassigned resources = 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=7| Res | Unassigned resources = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=0| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=7| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=0| Res | Unassigned resources = 15 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=7| Res | Unassigned resources = 13 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=0| Res | Max LSP Bandwidth = 8 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=7| Res | Max LSP Bandwidth = 7 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Belotti & Grandi Expires September 22, 2010 [Page 17]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Suppose now that due to another LSP signaling N1 and N2 decide to
allocate an ODU-2 at priority 0 subtracting resources at the 10G
link. The line rate capacity is used. The ODU-1 previously allocated
at priority 4 is preempted. The ISCD changes 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|00 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-2 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | LR-ODU-3 | Reserved | Total number of resources = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-1 | Reserved | Total number of resources = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODU-2 | Reserved | Total number of resources = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T0 | ODUflex-R | Reserved | Total number of resources = 40(TS)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=0| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-2 |Pri=4| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=0| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | LR-ODU-3 |Pri=4| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=0| Res | Unassigned resources = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-1 |Pri=4| Res | Unassigned resources = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=0| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODU-2 |Pri=4| Res | Unassigned resources = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=0| Res | Unassigned resources = 7 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T1 | ODUflex-R |Pri=4| Res | Unassigned resources = 7 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=0| Res | Max LSP Bandwidth = 7 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T2 | ODUflex-R |Pri=4| Res | Max LSP Bandwidth = 7 (TS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Belotti & Grandi Expires September 22, 2010 [Page 18]
Internet-Draft OSPF-TE extensions for OTN support March 2010
9. 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.
10. IANA Considerations
TBD
A new Sub_TLV for the OTH-ISCD has to be requested to IANA
11. Contributors
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels".
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures"
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option"
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
MPLS Traffic Engineering (TE)"
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)"
Belotti & Grandi Expires September 22, 2010 [Page 19]
Internet-Draft OSPF-TE extensions for OTN support March 2010
[RFC5212] Shiomoto K., Papadimitriou D., Vigoureux M., Brungard D.,
"Requirements for GMPLS-Based Multi-Region and Multi-Layer
Networks (MRN/MLN)"
[RFC5339] LeRoux JL., Papadimitriou D., "Evaluation of Existing GMPLS
Protocols against Multi-Layer and Multi-Region Networks
(MLN/MRN)"
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option"
[MLN-EXT] Shiomoto K., Papadimitriou D., Vigoureux M., Brungard D.,
LeRoux JL., "Generalized Multi-Protocol Label Switching
(GMPLS) Protocol Extensions for Multi-Layer and Multi-
Region Networks (MLN/MRN)"
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.
[G.872Am2-draft] ITU-T, Draft "Amendment 2 to G.872 OTN architecture",
https://datatracker.ietf.org/liaison/844/
13. Acknowledgments
TBD
Belotti & Grandi Expires September 22, 2010 [Page 20]
Internet-Draft OSPF-TE extensions for OTN support March 2010
Authors' Addresses
Sergio Belotti
Alcatel-Lucent
Via Trento 30, Vimercate (Italy)
Phone: +39 039 6863033
Email: sergio.belotti@alcatel-lucent.com
Pietro Grandi
Alcatel-Lucent
Via Trento 30, Vimercate (Italy)
Phone: +39 039 6864930
Email: pietro_vittorio.grandi@alcatel-lucent.com
Belotti & Grandi Expires September 22, 2010 [Page 21]
