One document matched: draft-zhang-ccamp-gmpls-g709-framework-01.txt
Differences from draft-zhang-ccamp-gmpls-g709-framework-00.txt
Network Working Group Fatai Zhang
Internet Draft Dan Li
Category: Standards Track Huawei
Han Li
CMCC
S.Belotti
Alcatel-Lucent
Expires: June 2010 December 18, 2009
Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks
draft-zhang-ccamp-gmpls-g709-framework-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 17, 2010.
Abstract
This document provides a framework to allow the development of
protocol extensions to support Generalized Mulit-Protocol Label
Switching (GMPLS) and Path Computation Element (PCE) control of
Optical Transport Networks (OTN) as specified in ITU-T Recommendation
G.709.
zhang Expires June 2010 [Page 1]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
[Note: including the enhanced functionality in the version consented
10/2009.]
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 [RFC2119].
Table of Contents
1. Introduction.................................................2
2. Terminology..................................................3
3. G.709 Optical Transport Network (OTN)........................4
3.1. OTN Layer Network.......................................4
4. Connection management in OTN.................................9
4.1. Connection management of OCh...........................10
4.2. Connection management of the ODU.......................10
5. GMPLS/PCE Implications......................................12
5.1. Implications for LSP Hierarchy with GMPLS TE...........12
5.2. Implications for GMPLS Signaling.......................12
5.2.1. Identifying OTN signals...........................13
5.2.2. Tributary Port Number.............................14
5.3. Implications for GMPLS Routing.........................14
5.3.1. Requirement for conveying Interface Switching
Capability specific information...................14
5.4. Implications for Link Management Protocol (LMP)........15
5.4.1. Correlating the Granularity of the TS.............15
5.4.2. Correlating the Supported LO ODU Signal Types.....15
5.5. Implications for Path Computation Elements.............16
6. Security Considerations.....................................16
7. IANA Considerations.........................................16
8. Acknowledgments.............................................16
APPENDIX A: Description of LO ODU terminology and ODU connection
examples...........................................17
9. References..................................................19
9.1. Normative References...................................19
9.2. Informative References.................................20
10. Author's Addresses.........................................20
1. Introduction
OTN has become a mainstream layer 1 technology for the transport
network. It is desirable for operators to be able to introduce
control plane capabilities based on Generalized Multi-Protocol Label
zhang Expires June 2010 [Page 2]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
Switching (GMPLS) to OTN networks, so as to realize its associated
benefits (e.g., improved network resiliency, resource usage
efficiency, etc.).
GMPLS extends MPLS to encompass time division multiplexing (TDM)
networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda
switching optical networks, and spatial switching (e.g., incoming
port or fiber to outgoing port or fiber). The GMPLS architecture is
provided in[RFC3945], signaling function and Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) extensions are described in
[RFC3471] and [RFC3473], routing and OSPF extensions are described in
[RFC4202] and [RFC4203], and the link management protocol is
described in [RFC4204].
The existing GMPLS protocol suite provides the mechanisms for basic
GMPLS control of OTN networks, using ITU-T G.709 interfaces as
specified in 2003 [ITU-T-G.709]. It should be noted that there are
some differences between SDH/SONET TDM networks and OTN networks
resulting from some new features recently introduced in ITU-T; for
example, various multiplexing structures, two types of Tributary
Slots (i.e., 1.25Gbps and 2.5Gbps), and extension of the ODUj
definition to include the ODUflex function.
This document reviews relevant aspects of OTN technology evolution
affecting GMPLS control plane protocols, including PCE implications,
and provides a framework for the control of OTN networks.
For the purposes of the control plane the OTN can be considered as
being comprised of sub-wavelength (ODU) and wavelength (OCh) layers.
This document focuses on the control of the sub-wavelength layer,
with control of the wavelength layer considered out of the scope.
Please refer to [WSON-Frame] for further information.
[Note: It is intended to align this draft with G.709 (consented in
10/2009), G.872 and G.8080 (planned for consent in 6/2010)]
2. Terminology
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 [RFC2119].
zhang Expires June 2010 [Page 3]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
3. G.709 Optical Transport Network (OTN)
This section provides an informative overview of those aspects of the
OTN impacting control plane protocols. This overview is based on the
ITU-T Recommendations that contain the normative definition of the
OTN. Technical details regarding OTN architecture and interfaces are
provided in the relevant ITU-T Recommendations.
Specifically, [ITU-T-G.872] describes the functional architecture of
optical transport networks providing optical signal transmission,
multiplexing, routing, supervision, performance assessment, and
network survivability. [ITU-T-G.709] defines the interfaces of the
optical transport network to be used within and between subnetworks
of the optical network. With the evolution and deployment of OTN
technology many new features have been specified in ITU-T
recommendations, including for example, new ODU0, ODU2e, ODU4 and
ODUflex containers as described in [G709-V3].
3.1. OTN Layer Network
The simplified structure of OTN is shown in Figure 1, which
illustrates the layers that are of interest to the control plane.
Other layers below OCh (e.g. OTS) are not included in this Figure.
The full signal structure is provided in G.709.
Client signal
|
ODUj
|
OTU/OCh
OMS
Figure 1 Basic OTN signal structure
Client signals are mapped into the appropriate ODUj containers.
These ODUj containers are multiplexed onto the OTU/OCh. The
individual OTU/OCh signals are combined in the OMS (using WDM
multiplexing), and this aggregated signal provides the link between
the nodes.
zhang Expires June 2010 [Page 4]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
3.1.1 Client signal mapping
The client signals are mapped into a Low Order (LO) ODUj. Appendix A
gives more information about LO ODU.
The current values of j are: 0, 1, 2, 2e, 3, 4, Flex. The
approximate bit rates of these signals are defined in 2 [G709-V3] and
are reproduced in Tables 1 and 2.
+-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+
| ODU0 | 1 244 160 kbits/s |
| ODU1 | 239/238 x 2 488 320 kbit/s |
| ODU2 | 239/237 x 9 953 280 kbit/s |
| ODU3 | 239/236 x 39 813 120 kbit/s |
| ODU4 | 239/227 x 99 532 800 kbit/s |
| ODU2e | 239/237 x 10 312 500 kbit/s |
| ODUflex for CBR | |
| Client signals | 239/238 x client signal bit rate |
| ODUflex for GFP-F | |
| Mapped client signal | Configured bit rate |
+-----------------------+-----------------------------------+
Table 1 ODU types and bit rates
NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s
(ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3),
104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e).
zhang Expires June 2010 [Page 5]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
+-------------------+--------------------------------------+
| ODU Type | ODU bit-rate tolerance |
+-------------------+--------------------------------------+
| ODU0 | +- 20 ppm |
| ODU1 | +- 20 ppm |
| ODU2 | +- 20 ppm |
| ODU3 | +- 20 ppm |
| ODU4 | +- 20 ppm |
| ODU2e | +- 100 ppm |
| ODUflex for CBR | |
| Client signals | client signal bit rate tolerance, |
| | with a maximum of+-100 ppm |
| ODUflex for GFP-F | |
| Mapped client | +- 20 ppm |
| signal | |
+-------------------+--------------------------------------+
Table 2 ODU types and tolerance
The ODUflex uses one of two mapping options depending on the client
signal type:
- Circuit clients: are proportionally wrapped, thus the bit rate and
tolerance are defined by the client signal.
- Packet clients are GFP mapped: G.709 recommends that the bit rate
is set to an integer multiplier of HO OPUk TS rate, the tolerance is
+/- 20ppm and the bit rate is determined by the node that performs
the mapping.
3.1.1.1 ODUj types and parameters
Some information needs to be provided when ODUj connections are setup.
We have two types of information that should be conveyed in a
connection request:
(a)End to end:
Client payload type (e.g. STM64; Ethernet etc.)
Bit rate and tolerance: Note for j = 0, 1, 2, 2e, 3, 4 this
information may be carried as an enumerated type. For the ODUflex
the actual bit rate and tolerance must be provided.
(b)Link by link:
zhang Expires June 2010 [Page 6]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
TS assignment and port number (carried by the MSI bytes) as described
in section 3.1.2.
3.1.2 Multiplexing ODUj onto Links
The links between the switching nodes are provided by one or more
wavelengths. Each wavelength carries one OCh, which carries one OTU,
which carries one OPU. Since all of these signals have a 1:1:1
relationship, we only refer to the OTU for clarity. The ODUjs are
mapped into the Tributary Slots (TS) of the OTUk. Note that in the
case where j=k the ODUj is mapped into the OTU/OCh without
multiplexing.
The initial versions of G.709 only provided a single TS granularity,
nominally 2.5Gb/s. Amendment 3, approved in 2009, added an
additional TS granularity, nominally 1.25Gb/s. The number and type of
TSs provided by each of the currently identified OTUk is provided
below:
2.5Gb/s 1.25Gb/s Nominal Bit rate
OTU1 1 2 2.5Gb/s
OTU2 4 8 10Gb/s
OTU3 16 32 40Gb/s
OTU4 -- 80 100Gb/s
To maintain backwards compatibility while providing the ability to
interconnect nodes that support 1.25Gb/s TS at one end of a link and
2.5Gb/s TS at the other, the ''new'' equipment will fall back to the
use of a 2.5Gb/s TS if connected to legacy equipment. This
information is carried in band by the payload type.
[Note: Automatic negotiation may be added in a future version of
G.798, otherwise the discovery extensions described below will be
required].
The actual bit rate of the TS in an OTUk depends on the value of k.
Thus the number of TS occupied by an ODUj may vary depending on the
values of j and k. For example an ODU2e uses 9TS in an OTU3 but only
8 in an OTU4. Examples of the number of TS used for various cases are
provided below:
zhang Expires June 2010 [Page 7]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
- ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity
o ODU0 occupies 1 of the 2, 8, 32or 80 TS for ODU1, ODU2, ODU3 or
ODU4
- ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity
o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4
- ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity
o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3
- ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4
- ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity
o ODU2 occupies 4 of the 16 TS for ODU3
- ODU3 into ODU4 multiplexing with 1.25Gbps TS granularity
o ODU3 occupies 31 of the 80 TS for ODU4
- ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS
granularity
o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4
(n <= Total TS numbers of ODUk)
- ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for
ODU4
An ODUj must be carried by a single OTU. The available capacity
between nodes is the sum of the available capacity on the OTUs that
interconnect the nodes. This total capacity is represented as a link
bundle. Note that the available capacity will typically be
distributed across multiple OTUs, thus the maximum payload size (i.e.
the maximum number of TS on the bundled link which is determined by a
single OTU with the maximum number of TS) should also be provided.
A (local) Tributary Port Number (TPN) for the TS to be used to carry
an ODUj must be provided when an ODUj connection is set up. This
zhang Expires June 2010 [Page 8]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
information is mapped into the MSI bytes. The control plane must
convey the TPN information to the receiving end of the link. The TPN
is used (by the hardware) at the receiving end of the link to verify
the configuration.
In general the mapping of an ODUj (including ODUflex) into the OTUk
TSs is determined locally, and it can also be explicitly allocated by
a specific entity (e.g., head end, NMS) through Explicit Label
Control [RFC3473].
The allocation of the fixed and variable stuff bytes is dependent on
the bit rate and bit rate tolerance of the payload being mapped and
the TS capacity of the (local) OTUk link that has been selected.
3.1.2.1 Link Parameters
The critical parameters that need to be provided (for the purposes of
routing) are:
- Number of TS
- Maximum number of TS available for a LSP (i.e., Maximum LSP
Bandwidth)
- Bit rate of the TS. (Note: This may be efficiently encoded as a
two integers representing the value of k and the granularity.)
4. Connection management in OTN
As [ITU-T-G.872] described, OTN-based transport network equipment is
concerned with control of connectivity of ODU paths and optical
channels and not with control of connectivity of the client layer.
This document focuses on the connection management of ODU paths. The
management of OCh paths is described in [WSON-FRAME].
[Note: Work is currently in progress in Q.12/15 to update G.872 to
describe the ODU layer as a single layer network with the bit rate as
a parameter. This allows the links and nodes to be viewed in a
single topology as a common set of resources that are available to
provide ODUj connects (independent of the value of j). Optionally the
OCh layer may also be visible within this routing topology.
zhang Expires June 2010 [Page 9]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
4.1. Connection management of OCh
An OCh connection request needs a light path from source to
destination. This path computation is known as the Routing and
Wavelength Assignment (RWA) problem [HZang00]. In the case of full
wavelength converters at each node, OCh path computation is
equivalent to a circuit-switch TDM network with full time slot
interchange capability. The control of connectivity of optical
channels is within the scope of WSON (Wavelength Switched Optical
Networks) ongoing working in CCAMP Working Group in IETF.
OCh connections are managed as part of the ODU connection set up. OCh
connections do not exist outside the scope of a ODU in the OTN.
4.2. Connection management of the ODU
LO ODUj can be either mapped into the OTUk signal (j = k), or
multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
mapped into an OCh. See Appendix A for more information.
From the perspective of routing for the case where j < k (i.e. ODUjs
are multiplexed onto an OTUk) the topology may be viewed as
illustrated below. In the case of LO ODUj mapping into OTUk (k = j),
Figure 2 give an example of this kind of LO ODU connection.
Link #5 +--+---+--+ Link #4
+--------------------------| |--------------------------+
| | ODXC | |
| +---------+ |
| Node E |
| |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | |
| |--------| |--------| |--------| |
| ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D
Figure 2 Example Topology for connection LO ODU connection management
If an ODUj connection is requested (for example) between Node C and Node
E routing/path computation must select a path that has the required
number of TS available and that offers the lowest cost. Signaling is
then invoked to set up the path and to provide the information required
by each transit node to allow the configuration of the ODUj to OTUk
multiplexing and demultiplexing. At each node at the ingress end of the
zhang Expires June 2010 [Page 10]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
link the TS to be used are selected and the fixed and variable stuffing
bytes are selected using the ODUj parameters described above.
If the ODUj is an ODU1, ODU2, ODU3 or ODU4 it may be mapped directly on
to a corresponding OTUk (j = k). An operator may choose to allow this
option to be visible to the ODU routing/path computation process in
which case the topology would be as shown below in figure 4
Node E
Link #5 +---------+ Link #4
+--------------------------| |-------------------------+
| ------ |
| // \\ |
| || || |
| | RWA domain | |
+-+-------+ +----+- || || ------+ +-------+-+
| | | \\ // | | |
| |Link #1 | -------- |Link #3 | |
| +--------+ | | +--------+ +
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+---------+ +---------+Link #2 +---------+ +---------+
Node A Node B Node C Node D
Figure 3 RWA Hidden Topology for connection LO ODU connection management
In Figure 3 , a cloud representing OCH capable switching nodes is
represented. In this case the operator choice is to hide the real RWA
network topology.
Link #5 +---------+ Link #4
+--------------------------| |-------------------------+
| +----+ ODXC |----+ |
| +-++ +---------+ ++-+ |
| Node f + + Node E + + Node g |
| +-++ ++-+ |
| | +--+ | |
+-+-------+ +----+----+--| +--+-----+---+ +-------+-+
| |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ +
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+---------+ +---------+ Link #2+---------+ +---------+
Node A Node B Node C Node D
Figure 4 RWA Visible Topology for LO ODUj (with direct mapping on OTUk
K=j) connection management.
zhang Expires June 2010 [Page 11]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
In Figure 4, the cloud of previous figure is substitute by the real
topology. The nodes f,g,h are nodes with OCH switching capability. LO
ODU j mapping over OTU k=J is represented by the alternative links
between nodes C, node g, node E, node f, node B and node h.
In this case the ODU routing/path selection process will request an OCh
connection between node C to node E from the RWA domain. The connection
will appear at ODU level as a Forwarding adjacency. The ODU routing/path
selection will compare the cost of this connection (FA) to the cost of
using the (visible) links used in case of j<K (multiplexing case).
5. GMPLS/PCE Implications
The purpose of this section is to provide a framework for extensions of
the current GMPLS protocol suite and the PCE applications and protocols
to encompass OTN enhancements and connection management.
5.1. Implications for LSP Hierarchy with GMPLS TE
The path computation for LO ODU connection request is based on the
topology of ODU layer, including OCh layer visibility.
The OTN path computation can be divided into two layers. One layer is
OCh/OTUk, the other is LO ODUj. [RFC4206] defines the mechanisms to
accomplish creating the hierarchy of LSPs. The LSP management of
multiple layers in OTN can follow the procedures defined in [RFC4206]
and related MLN drafts.
As discussed in section 4, the route path computation for OCh is in
the scope of WSON [WSON-Frame]. Therefore, this document only
considers ODU layer for LO ODU connection request since the OCh layer
is being discussed in the WSON scope [WSON-Frame].
5.2. Implications for GMPLS Signaling
The signaling function and Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC
3473]. For OTN-specific control, [RFC4328] defines signaling
extensions to support G.709 Optical Transport Networks Control.
The evolution of OTN in ITU-T has introduced some new features,
including, for example, new ODU0, ODU2e, ODU4 and ODUflex containers.
Support for relevant associated multiplexing capabilities has also
becomes essential with this technology evolution.
It is obvious that [RFC4328] cannot support such new OTN features and
networking flexibility from a control plane perspective. Thus, a new
zhang Expires June 2010 [Page 12]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
RFC is needed to define the extensions that are required to support
the evolution of OTN.
5.2.1. Identifying OTN signals
[RFC4328] defines the LSP Encoding Type, the Switching Type and the
Generalized Protocol Identifier (Generalized-PID) constituting the
common part of the Generalized Label Request. The G.709 Traffic
Parameters are also defined in [RFC4328]. The following new signal
types have been added since [RFC4328] was published:
(1)New signal types of sub-lambda layer
Optical Channel Data Unit (ODUj):
ODU0
ODU2e
ODU4
ODUflex
(2)A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps)
(3)Signal type with variable bandwidth:
ODUflex has a variable bandwidth/bit rate BR and a bit rate
tolerance T. As described above the (node local) mapping process
must be aware of the bit rate and tolerance of the ODUj being
multiplexed in order to select the correct number of TS and the
fixed/variable stuffing bytes. Therefore, bit rate and bit rate
tolerance should be carried in the Traffic Parameter in the
signaling of connection setup request.
(4)Extended multiplexing hierarchy (For example, ODU0 into OTU2
multiplexing (with 1,25Gbps TS granularity).)
So the encoding provided in [RFC4328] needs to be extended to support
all the signal types and related mapping and multiplexing with all
kinds of tributary slots. Moreover, the extensions should consider
the extensibility to match future evolvement of OTN.
For item (1) and (3), new traffic parameters may need to be extended
in signaling message;
zhang Expires June 2010 [Page 13]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
For item (2) and (4), new label should be defined to carry the exact
TS allocation information related to the extended multiplexing
hierarchy.
5.2.2. Tributary Port Number
The tributary port number may be assigned locally by the node at the
(traffic) ingress end of the link and in this case as described above
must be conveyed to the far end of the link as a ''transparent''
parameter i.e. the control plane does not need to understand this
information. The TPN may also be assigned by the control plane as a
part of path computation.
5.3. Implications for GMPLS Routing
The path computation process should select a suitable route for a
ODUj connection request. In order to compute the lowest cost path it
must evaluate the number (and availability) of tributary slots on
each candidate link. The routing protocol should be extended to
convey some information to represent ODU TE topology. As described
above the number of tributary slots (on a link bundle), the bandwidth
of the TS and the maximum number that are available to convey a
single ODUj must be provided.
GMPLS Routing [RFC4202] defines Interface Switching Capability
Descriptor of TDM which can be used for ODU. However, some other
issues should also be considered which are discussed below.
5.3.1. Requirement for conveying Interface Switching Capability specific
information
Interface Switching Capability Descriptors present a new constraint
for LSP path computation. [RFC4203] defines the switching capability
and related Maximum LSP Bandwidth and the Switching Capability
specific information. When the Switching Capability field is TDM the
Switching Capability specific information field includes Minimum LSP
Bandwidth, an indication whether the interface supports Standard or
Arbitrary SONET/SDH, and padding. So routing protocol should be
extended when TDM is ODU type to support representation of ODU
switching information.
As discussed in section 3.1.2, many different types of ODUj can be
multiplexed into the same OTUk. For example, both ODU0 and ODU1 may
be multiplexed into ODU2. An OTU link may support one or more types
of ODUj signals. The routing protocol should be extended to carry
this multiplexing capability. Furthermore, one type of ODUj can be
multiplexed to an OTUk using different tributary slot granularity.
zhang Expires June 2010 [Page 14]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
For example, ODU1 can be multiplexed into ODU2 with either 2.5Gbps TS
granularity or 1.25G TS granularity. The routing protocol should be
extended to carry which TS granularity supported by the ODU interface.
Moreover, the bit rate (i.e., bandwidth) of TS can be determined by
the TS granularity and link type of the TE link. For example, the
bandwidth of a 1.25G TS without NJO (Negative Justification
Opportunity) in an OTU2 is about 1.249409620 Gbps, while the
bandwidth of a 1.25G TS without NJO in an OTU3 is about 1.254703729
Gbps. So The routing protocol should be extended to carry the TE link
type (OTUk/HO ODUk).
In OTN networks, it is simpler to use the number of Tributary Slots
for the bandwidth accounting. For example, Total bandwidth of the TE
link, Unreserved Bandwidth of the TE link and the Maximum LSP
Bandwidth can be accounted through the number of Tributary Slots
(e.g., the total number of the Tributary Slots of the TE link, the
unreserved Tributary Slots of the TE link, Maximum Tributary Slots
for an LSP). Thus, the routing protocol should be extended to carry
the Tributary Slots information related to bandwidth of the TE link.
5.4. Implications for Link Management Protocol (LMP)
As discussed in section 5.3, Path computation needs to know the
interface switching capability of links. The switching capability of
two ends of the link may be different, so the link capability of two
ends should be correlated.
5.4.1. Correlating the Granularity of the TS
As discussed in section 3.1.2, the two ends of a link may support
different TS granularity. In order to allow interconnection the node
with 1.25Gb/s granularity must fall back to 2.5Gb/s granularity.
Therefore, it is necessary for the two ends of a link to correlate
the granularity of the TS. This ensures that both ends of the link
advertise consistent capabilities (for routing) and ensures that
viable connections are established.
[Note: Work in Q.9/15 on an auto negotiation mechanism may eliminate
the need for discovery by the control plane since both ends of the
link will be aware of the capability].
5.4.2. Correlating the Supported LO ODU Signal Types
Many new ODU signal types have been introduced [G709-V3], such as
ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not
zhang Expires June 2010 [Page 15]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
support all the LO ODU signal types introduced by those new standards
or drafts. If one end of a link can not support a certain LO ODU
signal type, the link cannot be selected to carry such type of LO ODU
connection.
Therefore, it is necessary for the two ends of an HO ODU link to
correlate which types of LO ODU can be supported by the link. After
correlating, the capability information can be flooded by IGP, so
that the correct path for an ODU connection can be calculated.
5.5. Implications for Path Computation Elements
[PCE-APS] describes the requirements for GMPLS applications of PCE in
order to establish GMPLS LSP. PCE needs to consider the GMPLS TE
attributes appropriately once a PCC or another PCE requests a path
computation. The TE attributes which can be contained in the path
calculation request message from the PCC or the PCE defined in [PCECP]
includes switching capability, encoding type, signal type, etc.
As described in section 5.2.1, new signal types and new signals with
variable bandwidth information need to be carried in the extended
signaling message of path setup. For the same consideration, PCECP
also has a desire to be extended to carry the new signal type and
related variable bandwidth information when a PCC requests a path
computation.
6. Security Considerations
TBD.
7. IANA Considerations
TBD.
8. Acknowledgments
We would like to thank Maarten Vissers for his review and useful
comments.
zhang Expires June 2010 [Page 16]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
APPENDIX A: Description of LO ODU terminology and ODU connection
examples.
This appendix provides a description of LO ODU terminology and ODU
connection examples. This section is not normative which is just a
reference in order to facilitate quicker understanding of text.
In order to transmit client signal, the LO ODU connection must be
created first. From the perspective of [G709-V3], there are two types
of LO ODU:
(1) A LO ODUj mapped into an OTUk. In this case, the server layer of
this LO ODU is an OTUk. For example, if a STM-16 signal is
encapsulated into ODU1, and then ODU1 is mapped into OTU1, the ODU1
is a LO ODU.
(2) A LO ODUj multiplexed into a HO (Higher Order) ODUk (j < k)
occupying several TSs. In this case, the server layer of this LO ODU
is a HO ODUk. For example, if ODU1 is multiplexed into ODU2, and ODU2
is mapped into OTU2, the ODU1 is LO ODU and ODU2 is HO ODU.
The LO ODUj represents the container transporting a client of the OTN
that is either directly mapped into an OTUk (k = j) or multiplexed
into a server HO ODUk (k > j)container. Consequently, the HO ODUk
represents the entity transporting a multiplex of LO ODUj tributary
signals in its OPUk area.
In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5
give an example of this kind of LO ODU connection.
In Figure 5, The LO ODUj is switched at the intermediate ODXC node.
OCh and OTUk are associated with each other. From the viewpoint of
connection management, the management of OTUk is similar with OCh. LO
ODUj and OCh/OTUk have client/server relationships.
For example, one LO ODU1 connection can be setup between Node A and
Node C. This LO ODU1 connection is to be supported by OCh/OTU1
connections, which are to be set up between Node A and Node B and
between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A,
demapped from it in Node B, switched at Node B, and then mapped into
the next OTU1 and demapped from this OTU1 at Node C.
zhang Expires June 2010 [Page 17]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
| LO ODUj |
+------------------------------(b)---------------------------+
| | OCh/OTUk | | OCh/OTUk | |
| +--------(a)---------+ +--------(a)---------+ |
| | | | | |
+------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+
Node A Node B Node C
Figure 5 Connection of LO ODUj (1)
In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an
example of this kind of LO ODU connection.
In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The
LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each
ODXC node and switched at each ODXC node (i.e. trib port to line port,
line card to line port, line port to trib port). From the viewpoint
of connection management, the management of these HO ODUk and OTUk
are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server
relationships. when a LO ODU connection is setup, it will be using
the existing HO ODUk (/OTUk/OCh) connections which have been set up.
Those HO ODUk connections provide LO ODU links, of which the LO ODU
connection manager requests a link connection to support the LO ODU
connection.
For example, one HO ODU2 (/OTU2/OCh) connection can be setup between
Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be
setup between Node B and Node C. LO ODU1 can be generated at Node A,
switched to one of the 10G line ports and multiplexed into a HO ODU2
at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node
B to one of the 40G line ports and multiplexed into HO ODU3 at Node B,
demultiplexed from HO ODU3 at Node C and switched to its LO ODU1
terminating port at Node C.
zhang Expires June 2010 [Page 18]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
| LO ODUj |
+----------------------------(b)-----------------------------+
| | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | |
| +--------(c)---------+ +---------(c)--------+ |
| | | | | |
+------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+
Node A Node B Node C
Figure 6 Connection of LO ODUj (2)
9. References
9.1. Normative References
[RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, Jan 2006.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4202] K. Kompella, Y. Rekhter, Ed., " Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
zhang Expires June 2010 [Page 19]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
9.2. Informative References
[ITU-T-G.709] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation, March 2003.
[ITU-T-G.872] ITU-T, "Architecture of optical transport networks",
November 2001 (11 2001).
[Gsup43] ITU-T, "Transport of IEEE 10GBASE-R in optical transport
networks (OTN)", December 2008.
[G709-V3] ITU-T, "Draft revised G.709, version 3,", consented by
ITU-T Oct 2009.
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
and wavelength assignment approaches for wavelength-
routed optical WDM networks", Optical Networks Magazine,
January 2000.
[WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks
(WSON)", draft-ietf-ccamp-rwa-wson-framework, work in
progress.
[PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai
Zhang, "Requirements for GMPLS applications of PCE",
draft-ietf-pce-gmpls-aps-req-01.txt, July 2009.
10. Authors' Addresses
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Dan Li
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
zhang Expires June 2010 [Page 20]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
Phone: +86-755-28973237
Email: danli@huawei.com
Han Li
China Mobile Communications Corporation
53 A Xibianmennei Ave. Xuanwu District
Beijing 100053 P.R. China
Phone: +86-10-66006688
Email: lihan@chinamobile.com
Sergio Belotti
Alcatel-Lucent
Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6863033
Email: sergio.belotti@alcatel-lucent.it
11. Contributors
Jianrui Han
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972913
Email: hanjianrui@huawei.com
Malcolm Betts
Huawei Technologies Co., Ltd.
Email: malcolm.betts@huawei.com
Pietro Grandi
Alcatel-Lucent
Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6864930
zhang Expires June 2010 [Page 21]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
Email: pietro_vittorio.grandi@alcatel-lucent.it
Eve Varma
Alcatel-Lucent
1A-261, 600-700 Mountain Av
PO Box 636
Murray Hill, NJ 07974-0636
USA
Email: eve.varma@alcatel-lucent.com
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
zhang Expires June 2010 [Page 22]
draft-zhang-ccamp-gmpls-g709-framework-01.txt December 2009
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
zhang Expires June 2010 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 12:17:31 |