One document matched: draft-zhang-ccamp-gmpls-g709-framework-00.txt
Network Working Group Fatai Zhang
Internet Draft Dan Li
Category: Standards Track JIanrui Han
Huawei
Han Li
CMCC
Expires: April 2010 October 16, 2009
Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks
draft-zhang-ccamp-gmpls-g709-framework-00.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 April 16, 2010.
Abstract
This document provides a framework for applying Generalized Mulit-
Protocol Label Switching (GMPLS) and the Path Computation Element
(PCE) architecture to the control of G.709 Optical Transport Networks
(OTN) as specified in the ITU-T G.709 recommendation, including the
enhanced functionality in the recently consented revision.
zhang Expires April 2010 [Page 1]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 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...................................................3
2. Terminology....................................................4
3. G.709 Optical Transport Network (OTN)..........................4
3.1. OTN Layer Network.........................................4
3.1.1. Analogue Layer.......................................6
3.1.1.1. Optical channel Layer network (OCh).............6
3.1.1.2. Optical multiplex section layer network (OMS)...6
3.1.1.3. Optical transmission section layer network (OTS)7
3.1.2. Digital layer........................................7
3.1.2.1. Optical channel transport unit (OTU)............7
3.1.2.2. Optical channel data unit (ODUk)................7
3.1.2.3. Optical channel payload unit (OPUk).............8
3.2. Mapping/Multiplexing......................................8
3.2.1. Mapping..............................................9
3.2.1.1. Mapping of client signals.......................9
3.2.1.2. Other mapping relationships.....................9
3.2.2. Multiplexing.........................................9
3.2.2.1. ODUk Time-Division Multiplex....................9
3.2.2.1.1. Tributary Slot introduction...............10
3.2.2.1.2. Multiplexing Hierarchy....................11
3.2.2.1.3. Tributary Slot allocation.................11
3.2.2.1.4. Tributary Port Number assignment..........13
3.2.2.2. ODUflex........................................13
3.2.2.3. Wavelength division multiplex..................13
4. Connection management in OTN..................................13
4.1. Connection management of OCh.............................14
4.2. Connection management of ODU.............................14
5. GMPLS/PCE Implications........................................19
5.1. Implications for LSP Hierarchy with GMPLS TE.............19
5.2. Implications for GMPLS Signaling.........................19
5.2.1. Identifying OTN signals.............................20
5.2.2. Tributary Port Number assignment....................21
5.3. Implications for GMPLS Routing...........................21
5.3.1. Requirement for conveying Interface Switching
Capability specific information.....................21
5.4. Implications for Auto-discovery..........................22
5.4.1. Discovering the Granularity of the TS...............22
5.4.2. Discovering the Supported LO ODU Signal Types.......23
zhang Expires April 2010 [Page 2]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
5.5. Implications for PCE.....................................23
6. Security Considerations.......................................23
7. IANA Considerations...........................................23
8. Acknowledgments...............................................23
9. References....................................................24
9.1. Normative References.....................................24
9.2. Informative References...................................24
10. Author's Addresses...........................................25
1. Introduction
OTN is becoming a mainstream support technology for the backbone
transport network and the metropolitan core transport layer. It is
desirable for operators to introduce control plane such as
Generalized Multi-Protocol Label Switching (GMPLS) to the OTN
networks, because GMPLS can improve the network reliability through
restoration mechanisms (e.g., resist multiple failures) and resource
usage efficiency through mesh-shared.
GMPLS extends MPLS to encompass time division multiplexing (TDM)
networks (e.g., SONET/SDH, PDH, and G.709 digital wrapper), lambda
switching optical networks, and spatial switching (e.g., incoming
port or fiber to outgoing port or fiber). [RFC3945] provides the
architecture of GMPLS. For GMPLS networks, signaling, routing and
link management are the basic modules. The signaling function and
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
extensions are described in [RFC3471] and [RFC3473]. The routing
extensions and OSPF extensions are described in [RFC4202] and
[RFC4203]. The link management protocol is described in [RFC4204].
The existing GMPLS protocol suite can provide the basic principle for
GMPLS control of OTN networks. However, there is some difference
between normal TDM networks (e.g., SDH/Sonet) and OTN networks
(especially for OTN digital wrapper), because some new features are
introduce recently in ITU-T, for example, various multiplexed
structure, two types of Tributary Slot (i.e., 1.25Gbps and 2.5Gbps)
and the ODUk definition has been extended to include the ODUflex
function.
Therefore, this document reviews the OTN technology and provides a
framework for applying GMPLS and PCE architecture to the control of
OTN networks.
Note that G.709 OTN can be divided into two layers roughly, which are
digital wrapper layer and wavelength layer, in this document, it only
zhang Expires April 2010 [Page 3]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
focuses on digital wrapper layer and wavelength layer is out of the
scope. Please refer to [WSON-Frame] for further information.
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].
3. G.709 Optical Transport Network (OTN)
This section provides an overview of G.709 Optical Transport Network
based on ITU-T G.709 related recommendations. [ITUT-G872] describes
the functional architecture of optical transport networks providing
optical signal transmission, multiplexing, routing, supervision,
performance assessment, and network survivability. [ITUT-G709]
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 G.709 technology many new features are
defined in ITU-T recommendations. For example, ODU0, ODU2e, ODU4
containers and ODUflex are described in [G709-V3], ODU3e1, ODU3e2 are
described in [Gsup43].
The purpose of this section is to provide some background and basic
reference about OTN technology and then determine how the current
GMPLS protocol suit and the PCE architecture can be accommodated to
encompass the OTN. For the detailed OTN related technical information
please refers to the ITU-T recommendations.
3.1. OTN Layer Network
The basic structure of OTN is shown in Figure 1. Three layer networks
are illustrated which include optical channel layer (OCh), section
layers: OMSn (Optical Multiplex section) and OTNn (Optical
Transmission Section), and single channel section layer: OPSn
(optical physical section).
OCh substructure indicated by Figure 1 consists of
- Analogue layer (OCh/OChr): The optical channel with full (OCh) or
reduced functionality (OChr), which provides transparent network
connections between 3R regeneration points in the OTN.
- Digital layer (OTU): The completely or functionally standardized
optical channel transport unit (OTUk/OTUkV) which provides
zhang Expires April 2010 [Page 4]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
supervision and conditions the signal for transport between 3R
regeneration points in the OTN.
- Digital layer (ODU/OPU): The optical channel data unit (ODUk)
which provides:
o tandem connection monitoring (ODUkT);
o end-to-end path supervision (ODUkP); and
o adaptation of client signals via the Optical Channel Payload
Unit (OPUk)
Client (e.g., STM-N, ATM, IP, Ethenet, MPLS, ...)
| | | |
+-------+------+-----+-----+-----+------+--------+..........
| | LO OPUk | | ^
| +- - - - - - - - - - - - - - - -+ | |
| / ODUkP | |
| LO ODUk< - - - - - - - - - - - - - - - - - - - + |
| \ ODUkT |
+-------+-------------------------------+--------+ OCh
| | HO OPUk | |
| +- - - - - - - - - - - - - - - -+ | Sub-
| / ODUkP | structure
| HO ODUk< - - - - - - - - - - - - - - - - - - - +
| \ ODUkT | |
+-------+-------+---+-------+-------+---+--------+ |
| OTUkV | OTUk | | OTUkV | OTUk | | OTUk | |
+-------+-------+ +-------+-------+ .+--------+.....V....
| OCh | | OChr | . | |
+---------------+...+---------------+. | |
| OMSn | | | | OPSMnk |
+---------------+ | OPSn | | |
| OTSn | | | | |
+-------+-------+ +-------+-------+ +---+----+
| | |
OTM-n.m OTM-0.m, OTM-0.mvm
OTM-nr.m
Full Reduced Multi Lane,
functionality functionality Reduced
OTM interface OTM interface functionality
OTM interface
zhang Expires April 2010 [Page 5]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
Client (e.g., STM-N, ATM, IP, Ethenet, MPLS, ...)
| | | |
+-------+------+-----+-----+-----+------+--------+..........
| | LO OPUk | | ^
| +- - - - - - - - - - - - - - - -+ | |
| / ODUkP | OCh
| LO ODUk< - - - - - - - - - - - - - - - - - - - + Sub-
| \ ODUkT | structure
+-------+-------+---+-------+-------+---+--------+ |
| OTUkV | OTUk | | OTUkV | OTUk | | OTUk | |
+-------+-------+ +-------+-------+ .+--------+.....V....
| OCh | | OChr | . | |
+---------------+...+---------------+. | |
| OMSn | | | | OPSMnk |
+---------------+ | OPSn | | |
| OTSn | | | | |
+-------+-------+ +-------+-------+ +---+----+
| | |
OTM-n.m OTM-0.m, OTM-0.mvm
OTM-nr.m
Full Reduced Multi Lane,
functionality functionality Reduced
OTM interface OTM interface functionality
OTM interface
Figure 1 OTN layers
3.1.1. Analogue Layer
3.1.1.1. Optical channel Layer network (OCh)
The OCh transports a digital client signal between 3R regeneration
points. The OCh client signals defined in [ITUT-G709] are the OTUk
signals. Optical Transport Module (OTM-n.m, OTM-nr.m, OTM-0.m, OTM-
0.mvn) is described in [ITUT-G709] in detail.
3.1.1.2. Optical multiplex section layer network (OMS)
The OMS provides the transport of optical channels through an optical
multiplex section trail between access points.
zhang Expires April 2010 [Page 6]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
3.1.1.3. Optical transmission section layer network (OTS)
The optical transmission section layer network provides for the
transport of an optical multiplex section through an optical
transmission section trail between access points.
3.1.2. Digital layer
3.1.2.1. Optical channel transport unit (OTU)
The OTUk conditions the ODUk for transport over an optical channel
network connection.
Currently, the following OTUk types are defined: OTU1, OTU2, OTU3,
OTU4, OTU2e, OTU3e1, OTU3e2. OTUk has a bandwidth/bit rate BR and a
bit rate tolerance T i.e. OTU(BR,T). The detailed bit rates and
tolerance of the OTUk signals are defined in [ITUT-G709], [Gsup43]
and [G709-V3].
3.1.2.2. Optical channel data unit (ODUk)
The optical channel data unit (ODUk) provides adaptation of client
signals via the Optical Channel Payload Unit (OPUk) LO ODU (Lower
order ODU) can be multiplexed into HO ODU (higher order ODU), which
is described in section 3.2.2.
Currently, the following ODUk types are defined: ODU0, ODU1, ODU2,
ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit
rate BR and a bit rate tolerance T i.e. ODU(BR,T). The detailed bit
rates and tolerance of the ODUk signals (except ODUflex) are defined
in [ITUT-G709], [Gsup43] and [G709-V3]. The bitrate and tolerance of
the ODUflex is dependent on the client signal.
HO ODUk types are: ODU1, ODU2, ODU3, ODU4, ODU3e1, ODU3e2.
LO ODUk types are: ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex.
ODU3e1 and ODU3e2 can be treated as LO ODU signals outside the domain
in which these signals terminate.
zhang Expires April 2010 [Page 7]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
3.1.2.3. Optical channel payload unit (OPUk)
The OPUk encapsulates the Client signal (e.g. SONET/SDH, Ethernet
bit/codeword streams, Ethernet VLANs) and fulfils any rate
justification that is needed. It is mapped at the source, demapped at
the sink, and not modified by the network.
Currently, the following OPUk types are defined: OPU0, OPU1, OPU2,
OPU3, OPU4, OPU2e, OPUflex, OPU3e1, OPU3e2. OPUk has a bandwidth/bit
rate BR and a bit rate tolerance T i.e. OPU(BR,T). The detailed bit
rates and tolerance of the OPUk signals are defined in [ITUT-G709],
[Gsup43] and [G709-V3].
3.2. Mapping/Multiplexing
From the perspective of digital and analogue layers, there are two
processes for the mapping and multiplexing.
One process is that a (non-OTN) client signal is mapped into a lower
order OPU, which will be mapped into the associated LO ODU. The LO
ODU signal can be either mapped into the associated OTU[V] signal, or
into an ODTU, which will be multiplexed into an ODTU Group (ODTUG).
The ODTUG signal is mapped into a higher order OPU, and the HO OPU
signal is then mapped into the associated HO ODU, which will be
mapped into the associated OTU[V]. Therefore a LO ODU may be carried
either directly over an OCh or over a HO ODU.
A HO ODU may be treated in a second domain as a LO ODU, and be mapped
in that domain in to an ODTU. For interworking with OTN networks
based on the 2003 version of G.709, this mapping of a HO ODU into
another HO ODU may occur within one domain for the cases of ODU0 ->
ODU1 -> ODU2, ODU0 -> ODU1 -> ODU3, ODU0 -> ODU2 -> ODU3 and ODUflex
-> ODU2 -> ODU3.
The other process is that an OTU[V] signal is mapped either into an
Optical Channel signal (i.e., OCh and OChr), or into an OTLk.n. The
OCh/OChr signal is mapped into an Optical Channel Carrier (i.e., OCC
and OCCr). The OCC/OCCr signal is multiplexed into an OCC Group,
identified as OCG-n.m and OCG-nr.m. The OCG-n.m signal is mapped into
an OMSn. The OMSn signal is mapped into an OTSn. The OTSn signal is
presented at the OTM-n.m interface. The OCG-nr.m signal is mapped
into an OPSn. The OPSn signal is presented at the OTM-nr.m interface.
A single OCCr signal is mapped into an OPS0. The OPS0 signal is
presented at the OTM-0.m interface. The OTLk.n signal is mapped into
an Optical Transport Lane Carrier, identified as OTLC. The OTLC
zhang Expires April 2010 [Page 8]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
signal is multiplexed into an OTLC Group, identified as OTLCG. The
OTLCG signal is mapped into an OPSMnk. The OPSMnk signal is presented
at the OTM-0.mvn interface.
The detailed multiplexing and mapping structures are described in
[ITUT-G709], [Gsup43] and [G709-V3].
3.2.1. Mapping
There are several kinds of mapping. For example, the client signal or
an Optical channel Data Tributary Unit Group (ODTUGk) is mapped into
the OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into
an OTUk[V]. The OTUk[V] is mapped into an OCh[r] and the OCh[r] is
then modulated onto an OCC[r].
3.2.1.1. Mapping of client signals
OPUk supports mapping of various of client signals like CBR2G5,
CBR10G, CBR10G3, CBR10G3 and CBR40G signals, ATM cell stream, GFP
encapsulated IP, MPLS, Ethernet packet/frame streams, test signal,
fibre channel, etc, which are described in [ITUT-G709] in more detail.
3.2.1.2. Other mapping relationships
OTN supports other mapping like ODUj into ODTUjk or ODTUk.ts, ODTU
into OPUk, etc. which are described in [ITUT-G709] and [G709-V3] in
more detail.
3.2.2. Multiplexing
OTN has a multi stage multiplexing capability including one or more
TDM stages and one WDM stage which are introduced in the following
sections.
3.2.2.1. ODUk Time-Division Multiplex
LO ODU can be multiplexed into HO ODU, the process is as follows: LO
ODU signal is mapped into an ODTU, which will be multiplexed into an
ODTU Group (ODTUG). And then the ODTUG signal is mapped into a higher
order OPU, which then is mapped into the associated HO ODU.
In this process, multiplexing an ODTU into an OPU is realized by
means of the mapping of the ODTU signal in one or several OPU
Tributary Slots. This section is only concerned about multiplexing
zhang Expires April 2010 [Page 9]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
process not mapping process. This section describes the means of
Tributary Slot allocation when multiplexing LO ODU into HO ODU.
3.2.2.1.1. Tributary Slot introduction
The OPUk is divided in a number of Tributary Slots (TS) and these
Tributary Slots are interleaved within the OPUk. There are two types
of Tributary Slots:
1. Tributary Slot with a bandwidth of approximately 2.5 Gbps
introduced in [ITUT-G709]; an OPUk is divided in n Tributary Slots,
numbered 1 to n.
2. Tributary Slot with a bandwidth of approximately 1.25 Gbps
introduced in [G709-V3]; an OPUk is divided in 2n Tributary Slots,
numbered 1 to 2n.
Equipment supporting a 1.25Gbps TS structure for OPU2 or OPU3 must be
backward compatible with equipment which supports only the 2.5G TS
structure. Specific Tributary Slots must be combined together (e.g.,
combination of TS#i and TS#i+4 on an HO ODU2 link) for the LO ODU at
one end of the HO ODU link which supports the 1.25Gbps TS structure,
so that the LO ODU can be carried on the HO ODU link correctly.
In the following example, suppose that the two ends of an ODU2 or
ODU3 link support different TS structure, where node A supports the
1.25Gbps TS structure, while node B supports the 2.5Gbps TS, as shown
in the figure below:
+-----+ +-----+
| | | |
| A +-------ODU2/ODU3 link-------+ B |
| | | |
+-----+ +-----+
(Support 1.25G TS) (Support 2.5G TS)
o In case of ODU1 multiplexing into ODU2, node A maps the ODU1 into
the TS#i and TS#i+4 (where i<=4) (with the granularity of 1.25Gbps)
of OPU2, so that node B can retrieve the ODU1 from the TS#i (with
the granularity of 2.5Gbps) of the OPU2, and vice versa.
o In case of ODU1 multiplexing into ODU3, node A maps the ODU1 into
the TS#i and TS#i+16 (where i<=16) (with the granularity of
zhang Expires April 2010 [Page 10]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
1.25Gbps) of OPU3, so that node B can retrieve the ODU1 from the
TS#i (with the granularity of 2.5Gbps) of the OPU3, and vice versa.
o In case of ODU2 multiplexing into ODU3, node A maps the ODU2 into
the TS#a/TS#a+16, TS#b/TS#b+16, TS#c/TS#c+16 and TS#d/TS#d+16
(where a<b<c<d<=16) (with the granularity of 1.25Gbps) of OPU3, so
that node B can retrieve the ODU2 from the TS#a, TS#b, TS#c and
TS#d (with the granularity of 2.5Gbps) of the OPU3, and vice versa.
3.2.2.1.2. Multiplexing Hierarchy
The multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k >
j) signal can be depicted as follows:
- ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity)
- ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS
granularity)
- ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity)
- ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with
1.25Gbps TS granularity)
- ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity)
- ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing
(with 1.25Gbps TS granularity)
- ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity)
- ODU0, ODU1, ODU2, ODU2e, ODUflex into ODU3e2 multiplexing (with
1.25Gbps TS granularity)
3.2.2.1.3. Tributary Slot allocation
When LO ODUj (e.g., ODU0, ODU1, ODU2, ODU3, etc.) at different rate
is multiplexed into HO ODUk, it will need different amount of
tributary slots to be allocated in OPUk. And when LO ODUj at a
certain rate is multiplexed into HO ODUk, it will also need different
amount of tributary slots with different TS granularity to be
allocated in OPUk. Allocations of TS numbers for different cases are
show as follows:
zhang Expires April 2010 [Page 11]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
- ODU0 into ODU1, ODU2, ODU3, ODU3e2 or ODU4 multiplexing with
1,25Gbps TS granularity
o ODU0 occupies 1 of the 2, 8, 32, 32 or 80 TS for ODU1, ODU2,
ODU3, ODU3e2 or ODU4
- ODU1 into ODU2, ODU3, ODU3e2 or ODU4 multiplexing with 1,25Gbps
TS granularity
o ODU1 occupies 2 of the 8, 32, 32 or 80 TS for ODU2, ODU3,
ODU3e2 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, ODU3e2 or ODU4 multiplexing with 1.25Gbps TS
granularity
o ODU2 occupies 8 of the 32, 32 or 80 TS for ODU3, ODU3e2 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 32 of the 80 TS for ODU4
- ODUflex into ODU2, ODU3, ODU3e2 or ODU4 multiplexing with 1.25Gbps
TS granularity
o ODUflex occupies n of the 8, 32, 32 or 80 TS for
ODU2, ODU3, ODU3e2 or ODU4 (n <= Total TS numbers of ODUk)
- ODU2e into ODU3, ODU3e2 or ODU4 multiplexing with 1.25Gbps TS
granularity
o ODU2e occupies 9 of the 32 TS for ODU3, 8 of the 80 TS for
ODU3e2, or 8 of the 32 TS for ODU4
- ODU2e into ODU3e1 multiplexing with 2.5Gbps TS granularity
o ODU2e occupies 8 of the 32 TS for ODU3e1
zhang Expires April 2010 [Page 12]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
3.2.2.1.4. Tributary Port Number assignment
TBD.
3.2.2.2. ODUflex
ODUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e.
ODU(BR,T). Compared with ODU0, ODU1, ODU2, ODU3, ODU4 and ODU2e,
ODUflex has a bandwidth which is locked to the CBR client signal's
bandwidth or which is configurable for case of GFP encapsulated
packet/frame streams. This is a new feature of OTN specified in
[G709-V3]. That is, for ODUflex, BR and T are not predefined.
ODUflex is transported by mapping into n (n <= Total TS numbers of
OPUk) tributary slots of an OPUk (of a HO ODUk) for k>=1. The value
of n depends on the BR, T of ODUflex and the BR, T of the
ODU2/ODU3/ODU3e2/ODU4 which ODUflex will be multiplexed into. For
example, for multiplexing the ODUflex at a certain rate like ODUflex
(2.5G, +/-20ppm), it will need 3 of the 8 TS into ODU2, but it will
only need 2 of the 32 TS into ODU3.
3.2.2.3. Wavelength division multiplex
Up to n (n>=1) OCC[r] are multiplexed into an OCG-n[r].m using
wavelength division multiplexing. The OCG-n[r].m is transported via
the OTM-n[r].m. For the case of the full functionality OTM-n.m
interfaces the OSC is multiplexed into the OTM-n.m using wavelength
division multiplexing.
4. Connection management in OTN
There are four main layers in OTN: (1) OMSn/OTSn and OPSn layers (2)
OCh layer (3) HO ODU layer, (4) LO ODU layer.
As [ITUT-G872] 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. So
this document focuses on the connection management of LO and HO ODU
paths and optical channel paths.
This section provides the overview of management of two layers: OCh
and ODU (both LO and HO).
zhang Expires April 2010 [Page 13]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
4.1. Connection management of OCh
In the general case of limited or no wavelength converters, 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 LO and HO ODU connection
set up. OCh connections do not exist outside the scope of a LO or HO
ODU in the OTN.
4.2. Connection management of ODU
As described above, LO ODUj can be either mapped into the associated
OTUk signal (k = j), or multiplexed to HO ODUk (k > j), and HO ODUk
is mapped into an OTUk, and the OTUk is mapped into an OCh.
In the case of LO ODUj mapping into OTUk (k = j), Figure 2 give an
example of this kind of LO ODU connection.
In Figure 2, The LO ODUj is switched at the intermediate ODXC node.
From the viewpoint of connection management, when a LO ODU connection
is setup, the OTUk and OCh connections are setup correspondingly; i.e.
the OTU/OCh connection set up is slaved to the LO ODU connection set
up. The management of this OTUk is similar to ODU. LO ODUj and
OCh/OTUk have client/server relationships.
For example, one LO ODU1 connection can be setup between Node A and
Node C. When there is no HO ODU supported ODU1 links available, 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 April 2010 [Page 14]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
| LO ODUj |
+------------------------------(b)---------------------------+
| | OCh/OTUk | | OCh/OTUk | |
| +--------(a)---------+ +--------(a)---------+ |
| | | | | |
+------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+
Node A Node B Node C
Figure 2 Connection of LO ODUk (1)
In the case of LO ODUj multiplexing into HO ODUk, Figure 3 gives an
example of this kind of LO ODU connection.
In Figure 3, 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, when a LO ODU connection is setup, it will
be using the existing HO ODUk (/OTUk/OCh) connections which have been
set up prior to the LO ODU service request. 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. LO ODUj and
OCh/OTUk/HO ODUk have client/server relationships.
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 prior to any LO ODU service requests.
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 April 2010 [Page 15]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
| LO ODUj |
+----------------------------(b)-----------------------------+
| | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | |
| +--------(a)---------+ +---------(a)--------+ |
| | | | | |
+------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+
Node A Node B Node C
Figure 3 Connection of LO ODUk (2)
Figure 4 gives another example which is kind of a hybrid case. In
this case, a LO ODUj is set up via an OTUk/OCh (k = j) connection
between Node A and Node B and via one or more tributary slots in an
existing HO ODUk (/OTUk/OCh)(k > j) connection between Node B and
Node C. The OTUk/OCh connection between Node A and Node B must be set
up as part of the LO ODUj connection set up. A LO ODUj link
connection must be instantiated within the HO ODUk between Node B and
Node C.
A LO ODU2 can be generated at Node A, switched to one of the 10G line
ports and mapped into an OTU2/OCh at Node A, demapped from the OTU2
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 ODU2 terminating port at Node C.
| LO ODUj |
+----------------------------(b)-----------------------------+
| | OCh/OTUj | | OCh/OTUk/HO ODUk | |
| +--------(c)---------+ +--------(a)---------+ |
| | | | | |
+------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+
Node A Node B Node C
Figure 4 Connection of LO ODUk (3)
The LO ODUj connection request (b) in Figure 2 generates OTUk/OCh
connection requests (a) as a consequence.
zhang Expires April 2010 [Page 16]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
Prior to any LO ODUj connection request, network planning/engineering
will generate connection requests (a) in figure 3 for the creation of
HO ODUk/OTUk/OCh connections. Afterwards a LO ODUj connection request
(b) will make use of the LO ODU link bandwidth provided by those HO
ODUk connections.
Prior to any LO ODUj connection request, network planning/engineering
will generate connection request (a) in figure 4 for the creation of
the HO ODUk/OTUk/OCh connection. Afterwards a LO ODUj connection
request (b) will make use of the LO ODU link bandwidth provided by
this HO ODUk connection. In addition, the LO ODUj connection request
(b) generates an OTUk/OCh connection request (c) to cross the OCh
subnetwork between nodes A and B.
So Connection Management should consider how to manage these
different LO ODU, HO ODU, OTU and OCh connections within the OTN. As
agreed in Q.12/15 each ODU layer (LO ODU, HO ODU) will have
visibility into the OCh layer to enable ODU connection set up through
a mix of subwavelength and wavelength links and matrices.
For the connection indicated by (b) in Figure 2-4, this LO ODUk is a
client of the connections indicated by (a) and (c). There are many
Levels at different rates for LO ODUk (e.g., ODUflex, ODU0, ODU1,
ODU2, ODU3, etc.). Each LO ODUk may share the same server Higher ODUk.
For example, in Figure 5, LO ODU1 and LO ODU2 share the same server
Higher ODU3. From the viewpoint of layer connection, a simpler
representation is to describe the LO ODU as a single layer network,
in which the bit rate of a client is a parameter. This
representation shows a single topology containing (OTUk/OCh/OMSn/OTSn,
OTUk/OChr/OPSn and HO ODUk/OTUk/OCh supported) LO ODU links and
subnetworks (i.e. resources) that is shared by all client ODU signals.
| LO ODU2 |
<-----------------(b)----------------->
| LO ODU1 | | |
<---------------(b)-|------------------> |
| |OCh/OTU1| ||OCh/OTU3/HO ODU3 | |OCh/OTU2| |
| +---(a)--+ |+-----(a)-------+ | +---(a)--+ |
| | | || | | | | |
+-++-+ +--+---+-++ +-++---+--+ +-++-+
| |3R| |3R| |3R| |3R| |3R| |3R| |
| +--+--------+--+ +--+---------------+--+ +--+--------+--+ |
|ODXC| | ODXC | | ODXC | |ODXC|
+----+ +---------+ +---------+ +----+
Node A Node B Node C Node D
Figure 5 Connection of LO ODUk (4)
zhang Expires April 2010 [Page 17]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
The path computation for LO ODU is to select a suitable route through
the network using available LO wavelength and sub-wavelength ODU
links and matrices, allocate on sub-wavelength LO ODU links one or
more tributary slots of the Higher Order OPU to the LO ODU link
connection and allocate on wavelength LO ODU links one wavelength to
the LO ODU link connection.
The path computation for HO ODU is to select a suitable route through
the network using available HO wavelength and sub-wavelength ODU
links and matrices, allocate on sub-wavelength HO ODU links one or
more tributary slots to the HO ODU link connection and allocate on
wavelength HO ODU links one wavelength to the HO ODU link connection.
OTM-0.m and OTM-0.mvn connections support a single OTUk and a single
ODUk link connection. LO ODU or HO ODU path computation can select
such OTM-0 support LO ODU or HO ODU link, in which case the full
capacity is allocated to the LO or HO ODU link connection.
Take the following Figure 6 as an example, the single topology
containing links and matrices can be illustrated as follows:
LO ODU Link #1: HO ODU2, support transport of ODU0, ODU1, ODU2;
LO ODU Link #2: HO ODU3, support transport of ODU0, ODU1, ODU2, ODU3;
LO ODU Link #3: HO ODU2, support transport of ODU0, ODU1, ODU2;
LO ODU Link #4: HO ODU1, support transport of ODU0;
LO ODU Link #5: HO ODU1, support transport of ODU0;
LO ODU Matrix A
LO ODU Matrix B
LO ODU Matrix C
LO ODU Matrix D
LO ODU Matrix E
If the LO ODUk (k = 0) connection from A to D is requested, two paths
may be feasible. One alternative is A-> Link #1 -> B -> Link #2 -> C
-> Link #3 -> D. Along this path, LO ODU0 is multiplexed into HO ODU2,
and then transported along Link #1 to Node B where it is
zhang Expires April 2010 [Page 18]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
demultiplexed from the HO ODU, switched through LO ODU Matrix B and
then multiplexed onto Link #2 to go to Node C. At Node C the LO ODU0
is demultiplexed, switched through LO ODU Matrix C and then
multiplexed onto Link #3 to go to Node D. At Node D the LO ODU0 is
demultiplexed from the HO ODU, switched through LO ODU Matrix D and
then terminated.
Link #5 +--+---+--+ Link #4
+--------------------------+3R| |3R+--------------------------+
| +--+ +--+ |
| | ODXC | |
| +---------+ |
| Node E |
| |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
|3R| |3R|Link #1 |3R| |3R|Link #2 |3R| |3R|Link #3 |3R| |3R|
+--+ +--+--------+--+ +--+--------+--+ +--+--------+--+ +--+
| ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D
Figure 6 Example of connection LO ODU
5. GMPLS/PCE Implications
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 as described
in section 4. One layer is OCh/OTUk/ODUk, the other is LO ODU.
[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 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.
zhang Expires April 2010 [Page 19]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
However, with the evolution of OTN, there are some new features
introduced in ITU-T, for example, ODU0, ODU2e, ODU4 and ODUflex.
Therefore, it is obvious that [RFC4328] can not support these new
features of OTN from control plane perspective, and it should be
updated or replaced 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. And the G.709 Traffic
Parameters are also defined in [RFC4328]. But some new features for
the evolving OTN has been introduced since [RFC4328] released. This
new features are summarized as follows:
(1) New signal types of digital wrapper layer
a) Optical Channel Transport Unit (OTUk)
- OTU4
- OTU2e
- OTU3e1
- OTU3e2
b) Optical Channel Data Unit (ODUk):
- ODU0
- ODU2e
- ODU3e1
- ODU3e2
- ODU4
- ODUflex
(2) A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps)
(3) Signal type with variable bandwidth:
zhang Expires April 2010 [Page 20]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
ODUflex has a variable bandwidth/bit rate BR and a bit rate
tolerance T. Different bandwidth may need different numbers of
tributary slots allocation when this kind of connection setup.
Therefore, bit rate and bit rate tolerance should be carried in
the Traffic Parameter in the signaling of connection setup request.
(4) New multiplexing hierarchy (For example, ODU0 into ODU1
multiplexing (with 1,25Gbps TS granularity).)
So [RFC4328] needs to be updated to support all the signal types and
related mapping and multiplexing with all kinds of tributary slots.
Moreover, the extensions should consider the scalability to match
future evolvement of OTN.
For item (1) and (3), new traffic parameters may need to be extended
in signaling message;
For item (2) and (4), new label should be defined to carry the exact
label allocation information.
5.2.2. Tributary Port Number assignment
TBD.
5.3. Implications for GMPLS Routing
As discussed in section 4.2.2, path computation element should select
a suitable route for LO ODU connection request and then allocate one
or more Higher Order OPU tributary slots. In order to compute the
suitable path (including tributary slots allocation) correctly,
routing protocol should be extended to convey some information to
represent ODU TE topology.
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
zhang Expires April 2010 [Page 21]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
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.2.2.1.3, many types of ODUj can be
multiplexed the same ODUk. For example, both ODU0 and ODU1 can be
multiplexed into ODU2. One ODU link may support one or more types of
ODU signals multiplexing. The routing protocol should be extended to
carry this multiplexing capability.
As discussed in section 3.2.2.1.4, one type of ODUj can be
multiplexed to one ODUk by different tributary slots. 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, Total bandwidth of the TE link, Unreserved Bandwidth of the
TE link, Maximum LSP Bandwidth, Min LSP Bandwidth, etc., which are
Switching Capability specific information for OTN should be carried
by routing protocol extensions for allocation of tributary slots.
5.4. Implications for Auto-discovery
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 discovered.
[RFC4204] defines the link management protocol which is part of the
Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering
(TE) links. [RFC4204] can be a good candidate to be extended to
implement the auto-discovery of link capability for OTN networks.
5.4.1. Discovering the Granularity of the TS
As discussed in section 3.2.2.1.1, the two ends of an ODU link may
support different TS structure. In that case, the LO ODU must be
mapped into specific combined Tributary Slots in the end of link with
TS of 1.25Gbps. For example, if the local end can support 1.25Gbps
and the remote end can support 2.5Gbps, and then the local end should
imitate 2.5Gbps.
In order to reserve TS resources correctly for a LO ODU connection,
the control plane of the two ends MUST know which granularity the
other end can support before creating the LO ODU connection.
zhang Expires April 2010 [Page 22]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
Therefore, it is necessary for the two ends of a link to discover the
granularity of the TS.
5.4.2. Discovering the Supported LO ODU Signal Types
Many new ODU signal types are introduced by [Gsup43] and [G709-V3],
such as ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. It is possible
that equipment does not always support all the LO ODU signal types
introduced by those new standards or drafts. If one end of an HO ODU
link can not support a certain LO ODU signal type, the HO ODU link
can not be selected to carry such type of LO ODU connection.
Therefore, it is necessary for the two ends of an HO ODU link to
discover which types of LO ODU can be supported by the HO ODU link.
After discovering, the capability information can be flooded by IGP,
so that the correct path for an ODU connection can be calculated.
5.5. Implications for PCE
[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 type and new signal 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 and Malcolm Betts for their
review and useful comments.
zhang Expires April 2010 [Page 23]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
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.
9.2. Informative References
[ITUT-G709] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation, March 2003.
[ITUT-G872] ITU-T, "Architecture of optical transport networks",
November 2001 (11 2001).
[Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement),",
December 2008.
[G709-V3] ITU-T, "Draft revised G.709, version 3,", consented by
ITU-T on 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.
zhang Expires April 2010 [Page 24]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
[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. Author's 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
Phone: +86-755-28973237
Email: danli@huawei.com
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
Han Li
China Mobile Communications Corporation
53 A Xibianmennei Ave. Xuanwu District
Beijing 100053 P.R. China
zhang Expires April 2010 [Page 25]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
Phone: +86-10-66006688
Email: lihan@chinamobile.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.
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.
zhang Expires April 2010 [Page 26]
draft-zhang-ccamp-gmpls-g709-framework-00.txt October 2009
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 April 2010 [Page 27]
| PAFTECH AB 2003-2026 | 2026-04-24 12:18:08 |