CCAMP Working Group S. Belotti
Internet-Draft P. Grandi
Intended status: Informational Alcatel-Lucent
Expires: December 16, 2010 D. Ceccarelli
D. Caviglia
Ericsson
F. Zhang
D. Li
Huawei Technologies
June 14, 2010
Information model for G.709 Optical Transport Networks (OTN)
draft-bccg-ccamp-otn-g709-info-model-00
Abstract
The recent revision of ITU-T recommendation G.709 [G.709-v3] has
introduced new fixed and flexible ODU containers in Optical Transport
Networks (OTNs), enabling optimized support for an increasingly
abundant service mix.
This document provides a model of information needed by the routing
process in OTNs to support Generalized Multiprotocol Label Switching
(GMPLS) control of all currently defined ODU containers both at sub-
lambdas and lambda level 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 December 16, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Belotti, et al. Expires December 16, 2010 [Page 1]
Internet-Draft Information model for G.709 OTN June 2010
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 requirements overview . . . . . . . . . . . . . . . . . . 3
3. G.709 Digital Layer TE Information and Requirement Analysis . 5
3.1. Tributary Slot type . . . . . . . . . . . . . . . . . . . 7
3.2. Sygnal type . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Unreserved Resources . . . . . . . . . . . . . . . . . . . 8
3.4. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 9
3.5. Distinction between multiplexing and line rate capacity . 9
3.6. Priority Support . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Belotti, et al. Expires December 16, 2010 [Page 2]
Internet-Draft Information model for G.709 OTN June 2010
1. Introduction
An Opaque OSPF (Open Shortest Path First) LSA (Link State
Advertisements) carrying application-specific information can be
generated and advertised to other nodes following the flooding
procedures defined in [RFC5250]. Three types of opaque LSA are
defined, i.e. type 9 - link-local flooding scope, type 10 - area-
local flooding scope, type 11 - AS flooding scope.
Traffic Engineering(TE) LSA using type 10 opaque LSA is defined in
[RFC3630] for TE purpose. This type of LSA is composed of a standard
LSA header and a payload including one top-level TLV 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 provides a model of information needed by the routing
process in OTNs to support Generalized Multiprotocol Label Switching
(GMPLS) control of all currently defined ODU containers both at sub-
lambdas and lambda level granularity.
OSPF requirements are defined in [OTN-FWK], while protocol extensions
are defined in [OTN-OSPF].
2. OSPF requirements overview
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
such a case OTN allows aggregation (and recovery) of traffic to
Belotti, et al. Expires December 16, 2010 [Page 3]
Internet-Draft Information model for G.709 OTN June 2010
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).
[Ed note] (could be part of Framework but for the moment can provide
introduction to the overview)
In this scope, Section 5.3 of the [draft-fwk] provides a set of
functional routing requirements. These requirements are summarized
below :
- Support for link multiplexing capability advertisement: The
routing protocol has to be able to carry information regarding the
capability of an OTU link to support different type of ODUs
- Support for TS granularity advertisement: Each ODUj can be
multiplexed into an OTUk using different TS granularities. For
example, ODU1 can be multiplexed into ODU2 with either 2.5Gbps TS
granularity or 1.25G TS granularity. The routing protocol should
be capable of carrying the TS granularity supported by the ODU
interface.
- Support of any ODUk and ODUflex: The routing protocol must be
capable of carrying the required link bandwidth information for
performing accurate route computation for any of the fixed rate
ODUs as well as ODUflex.
- Support for differentiation between link multiplexing capacity
and link rate capacity
- Support different priorities for resource reservation. How many
priorities levels should be supported depends on operator
policies. Therefore, the routing protocol should be capable of
supporting either no priorities or up to 8 priority levels as
defined in [RFC4202].
- Support link bundling 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.
Belotti, et al. Expires December 16, 2010 [Page 4]
Internet-Draft Information model for G.709 OTN June 2010
3. G.709 Digital Layer TE Information and Requirement Analysis
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. ITU-T G.872 amendment 2 provides two tables definig mapping
and multiplexing capabilities of OTNs. Such tables are shown
hereinafter.
+--------------------+--------------------+
| ODU client | OTU server |
+--------------------+--------------------+
| ODU 0 | - |
+--------------------+--------------------+
| ODU 1 | OTU 1 |
+--------------------+--------------------+
| ODU 2 | OTU 2 |
+--------------------+--------------------+
| ODU 2e | - |
+--------------------+--------------------+
| ODU 3 | OTU 3 |
+--------------------+--------------------+
| ODU 4 | OTU 4 |
+--------------------+--------------------+
| ODU flex | - |
+--------------------+--------------------+
Figure 1: OTN mapping capability
Belotti, et al. Expires December 16, 2010 [Page 5]
Internet-Draft Information model for G.709 OTN June 2010
+=================================+=========================+
| ODU client | ODU server |
+---------------------------------+-------------------------+
| 1,25 Gbps client | |
+---------------------------------+ ODU 0 |
| - | |
+=================================+=========================+
| 2,5 Gbps client | |
+---------------------------------+ ODU 1 |
| ODU 0 | |
+=================================+=========================+
| 10 Gbps client | |
+---------------------------------+ ODU 2 |
| ODU0,ODU1,ODUflex | |
+=================================+=========================+
| 10,3125 Gbps client | |
+---------------------------------+ ODU 2e |
| - | |
+=================================+=========================+
| 40 Gbps client | |
+---------------------------------+ ODU 3 |
| ODU0,ODU1,ODU2,ODU2e,ODUflex | |
+=================================+=========================+
| 100 Gbps client | |
+---------------------------------+ ODU 4 |
|ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| |
+=================================+=========================+
Figure 2: OTN multiplexing capability
An ODUk mapped directly into an OTUk server in a particular
networking domain, 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.
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.
In other words, ODUs serving various roles may change in traversing a
Belotti, et al. Expires December 16, 2010 [Page 6]
Internet-Draft Information model for G.709 OTN June 2010
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 detailed in [OTN-FWK], 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.
3.1. Tributary Slot type
ITU-T recommendations define two types of TS but, each link can only
work under one of them. The rules to be followed when selecting the
TS to be used are:
- if both ends of a link can support both 2.5Gbps TS and 1.25Gbps
TS, then the link will work under 1.25Gbps TS.
- If one end can support the 1.25Gbps TS, and another end the
2.5Gbps TS, the link will work under 2.5Gbps TS
In addition, the bandwidth accounting depends on the type of TS.
Therefore, the type of the TS should be known during LO ODU path
computation. Currently such information is not provided by the
routing protocol.
3.2. Sygnal type
[RFC 4328] allows advertising G.709 foundation (single TS) without
the capability of providing precise information about bandwidth
special allocation. For example, in case of link bundling, dividing
the unreserved bandwidth by the max LSP bandwidth it is not possible
to know the exact number of LSPs at max LSP bandwidth size that can
be set up.
The lack of spatial allocation heavily impacts the restoration
process, because the lack of information of free resources highly
increases the number of crank-backs affecting network convergence
Belotti, et al. Expires December 16, 2010 [Page 7]
Internet-Draft Information model for G.709 OTN June 2010
time.
Moreover actual tools provided by OSPF-TE only allow advertising
signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/
SONET networks) or variable bandwidth with no hierarchy (e.g. packet
switching networks) but do not provide the means for advertising
networks with mixed approach (e.g. ODUflex CBR and ODUflex packet).
For example, advertising ODU0 as MIN LSP bandwith and ODU4 as MAX LSP
bandwidth it is not possible to state whether the advertised link
supports ODU4 and ODUFlex or ODU4, ODU3, ODU2, ODU1, ODU0 and
ODUFlex. Such ambiguity is not present in SDH networks where the
hierarchy is implicit and flexible containers like ODUFlex do not
exist. Moreover with the current IETF solutions, ([RFC4202],
[RFC4203]) as soon as no bandwidth is available for a certain signal
type it is not advertised into the related ISCD, losing also the
related capability until bandwidth is freed.
Supposing for example to have an equivalent ODU-2 unreserved
bandwidth in a TE-link (with bundling capability) distributed on 4
ODU-1, it would be advertised via the ISCD in this way:
Max LSP Bw: ODU1
Min LSP Bw: ODU1
- Maximum Reservable Bandwidth (of the bundle) set to ODU2
- Unreserved Bandwidth (of the bundle) set to ODU2
In conclusion, the OSPF-TE extensions defined in [RFC4203] require a
different ISCD per signal type in order to advertise each supported
container. With respect to link bundling, the utilization of the
ISCD as it is, would not allow precise advertising of spatial
bandwidth allocation information unless using only one component link
per TE link.
3.3. Unreserved Resources
Unreserved resources need to be advertised per priority and per
signal type in order to allow the correct functioning of the
restoration process. [RFC4203] only allows advertising unreserved
resources per priority, this leads not to know how many LSPs of a
specific signal type can be restored. As example it is possible to
consider the scenario depicted in the following figure.
Belotti, et al. Expires December 16, 2010 [Page 8]
Internet-Draft Information model for G.709 OTN June 2010
+------+ component link 1 +------+
| +------------------+ |
| | component link 2 | |
| N1 +------------------+ N2 |
| | component link 3 | |
| +------------------+ |
+------+ +---+--+
Figure 3: Concurrent path computation
Suppose to have a TE link comprising 3 ODU3 component links with
32TSs available on the first one, 24TSs on the second, 24TSs on the
third and supporting ODU2 and ODU3 signal types. The node would
advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX
LSP bandwidth equal to 32 TSs. In case of restoration the network
could try to restore 2 ODU3 (64TSs) in such TE-link while only a
single ODU3 can be set up and a crank-back would be originated. In
more complex network scenarios the number of crank-backs can be much
higher.
3.4. Maximum LSP Bandwidth
Maximum LSP bandwidth is currently advertised in the common part of
the ISCD and advertised per priority, while in OTN networks it is
only required for ODUflex advertising. This leads to a significant
waste of bits inside each LSA.
3.5. Distinction between multiplexing and line rate capacity
The distinction between line rate and multiplexing capacity is a
requirement as per [OTN-FWK]. [RFC4203] could achieve this
distinction advertising different bandwidths for OTUk and ODUk signal
types. This approach implies the usage of multiple ISCDs and
therefore it is not efficient. For example a link with line rate
capacity OTU3 and multiplexing capacity ODU1, ODU2 and ODU3,
[RFC4203] would require the utilization of four different ISCDs, one
for each capability.
3.6. Priority Support
The IETF foresees that up to eight priorities must be supported and
that all of them have to be advertised independently on the number of
priorities supported by the implementation. Considering that the
advertisement of all the different supported signal types will
originate large LSAs, it is advised to advertise only the information
related to the really supported priorities.
Belotti, et al. Expires December 16, 2010 [Page 9]
Internet-Draft Information model for G.709 OTN June 2010
4. Security Considerations
TBD
5. IANA Considerations
TBD
6. Acknowledgements
TBD
7. References
7.1. Normative References
[OTN-OSPF]
D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot
ti, "Traffic Engineering Extensions to OSPF for
Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN
Networks", consented by ITU-T on Oct 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[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.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
Belotti, et al. Expires December 16, 2010 [Page 10]
Internet-Draft Information model for G.709 OTN June 2010
7.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.872-am2]
ITU-T, "Amendment 2 of G.872 Architecture of optical
transport networks for consent", consented by ITU-T on Oct
2009.
[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-00, April
2010.
Authors' Addresses
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
Belotti, et al. Expires December 16, 2010 [Page 11]
Internet-Draft Information model for G.709 OTN June 2010
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
Belotti, et al. Expires December 16, 2010 [Page 12]