Network Working Group X. Fu, Ed.
Internet-Draft ZTE
Intended status: Standards Track D. Ceccarelli, Ed.
Expires: April 29, 2010 Ericsson
M. Corsi, Ed.
Altran
October 26, 2009
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions
for evolutive OTNs control
draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-01
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 29, 2010.
Copyright Notice
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.
Fu, Ed., et al. Expires April 29, 2010 [Page 1]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
Abstract
This document is a companion to the Generalized Multi-Protocol Label
Switching (GMPLS) signaling documents. It describes the technology-
specific information needed to extend GMPLS signaling to control
Optical Transport Networks (OTN) based on ITU-T G.709 Amendment 3
reccomandation. References also to G.sup43 are provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. GMPLS Extension for G.709 Amendment 3 . . . . . . . . . . . . 3
4. GMPLS Extensions for G.Sup43 . . . . . . . . . . . . . . . . . 4
5. Generalized Label Request . . . . . . . . . . . . . . . . . . 4
5.1. Traffic Parameters . . . . . . . . . . . . . . . . . . . . 4
5.1.1. Signal Type (ST) . . . . . . . . . . . . . . . . . . . 5
5.1.2. Number of Multiplexed Components (NMC) . . . . . . . . 6
6. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Label Space . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Label Distribution Rules . . . . . . . . . . . . . . . . . 11
7. RSVP-TE Signaling Protocol Extensions . . . . . . . . . . . . 11
8. Interworking Considerations . . . . . . . . . . . . . . . . . 11
9. Example of Generalized Label . . . . . . . . . . . . . . . . . 14
10. Acknoledgments . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 20
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
15. Normative References . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Fu, Ed., et al. Expires April 29, 2010 [Page 2]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends
MPLS from supporting Packet Switching Capable (PSC) interfaces and
switching to include support of four new classes of interfaces and
switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM),
Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional
description of the extensions to MPLS signaling that are needed to
support these new classes of interfaces and switching is provided in
[RFC3471]. [RFC3473] describes the RSVP-TE-specific formats and
mechanisms needed to support all four classes of interfaces.
[RFC4328] describes the technology details that are specific to G.709
Optical Transport Networks (OTN) as defined in ITU-T G.709
recommendation [ITUT-G709].
This document extends the concepts presented in [RFC4328] with the
technology details introduced by ITU-T G.709 Amendment 3 and G.sup43
supplement.
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. GMPLS Extension for G.709 Amendment 3
G.709 Amendment 3 and G.sup43 introduce new signal types in the two
layers constituting the digital transport hierarchy:
- Optical Channel Transport Unit (OTUk):
. OTU4
- Optical Channel Data Unit (ODUk):
. ODU0
. ODU2e
. ODU3e1
. ODU3e2
. ODU4
. ODUflex
It also adds a new 1,25 Gbps Tributary Slot (TS) granularity for both
the new and the old ODUk signals.
[ITUT-G709-AMD3] introduces ODU4 mapping into OTU4 (and its related
Fu, Ed., et al. Expires April 29, 2010 [Page 3]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
100Gbps optical channel), and new ODUk multiplexing. It refers to
the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, and flex) into an ODUk
(k > j) signal, in particular:
o ODU0 into ODU1 multiplexing
o ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS
granularity)
o ODU0, ODU1, ODUflex, ODU2 and ODU2e into ODU3 multiplexing (with
1.25Gbps TS granularity)
o ODU0, ODU1, ODU2, ODU3, ODU2e, ODUflex into ODU4 multiplexing
(with 1.25Gbps TS granularity)
o ODU2e into ODU3e1 multiplexing (with 2,5Gbps TS granularity)
o ODU2e into ODU3e2 multiplexing (with 1,25Gbps TS granularity)
4. GMPLS Extensions for G.Sup43
G.Sup43 introduces two new types of signal: ODU3e1 and ODU3e2. These
extension are not normative with respect the ITU-T standardization
process. IETF needs to decide if these non normative ITU-T
extensions need to be included in the scope of IETF works. In the
rest of this ID we will highlight what is normative and what is not
with respect to ITU-T process. What is referred to G.Sup43 will be
indicated with [NN] tag in the text.
5. Generalized Label Request
The Generalized Label Request as defined in [RFC3471], includes a
common part (i.e. used for any switching technology) and a technology
dependent part (i.e. the traffic parameters). Both parts have been
extended by [RFC4328] in order to accommodate GMPLS signaling to the
G.709 transport plane recommendation (see [ITUT-G.709])
All these extensions are still valid for G.709 Amendment 3 and
G.Sup43 and only the technology dependent part is further extended to
accommodate GMPLS signaling to the new signals introduced by G.709
Amendment 3 and G.Sup43.
5.1. Traffic Parameters
The G.709 traffic parameters are defined as follows in [RFC4328]
Section 3.2:
Fu, Ed., et al. Expires April 29, 2010 [Page 4]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Reserved | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Generalized label request and traffic parameters
In this frame, NMC stands for Number of Multiplexed Components, NVC
for Number of Virtual Components and MT for Multiplier. Each of
these fields is tailored to support G.709 LSP requests.
The RSVP-TE encoding of the G.709 traffic-parameters is detailed in
[RFC4328] Section 6. [ITUT-G709-AMD3] defines new signals and
Digital Path layer multiplexing combinations, therefore, the Signal
Type and Number of Multiplexed Components fields need to be extended.
5.1.1. Signal Type (ST)
This field (8 bits) indicates the type of G.709 Elementary Signal
that comprises the requested LSP. Since G.709 Amendment 3 and
G.Sup43 defines new ODUk and OCh layers, additional Signal Type code-
points for G.709 Amendment 3 are defined to enlarge the existing ST
code-point defined in [RFC4328].
Following is the Signal Type extended for G.709 Amendment 3 and
G.sup43. Values from 0 to 8 are defined in [RFC4328]. The size of
OPU2 and OPU3 tributary slots which are define in [RFC4328] is 2.5G.
Fu, Ed., et al. Expires April 29, 2010 [Page 5]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
Value Type
----- ----
0 Not significant
1 ODU1 (i.e., 2.5 Gbps)
2 ODU2 (i.e., 10 Gbps)
3 ODU3 (i.e., 40 Gbps)
4 Reserved (for future use)
5 Reserved (for future use)
6 OCh at 2.5 Gbps
7 OCh at 10 Gbps
8 OCh at 40 Gbps
9 OCh at 100 Gbps
10 ODU0
11 ODU2e
12 ODUflex
13 ODU4
14-255 Reserved (for future use)
5.1.2. Number of Multiplexed Components (NMC)
The NMC values difined for G.709 Amendment 3 and G.sup43 are as
follows:
Fu, Ed., et al. Expires April 29, 2010 [Page 6]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
NMC Description
--- -----------
1 ODU0 is mapped into 1.25G tributary slots of OPU1.
1 ODU0 is mapped into 1.25G tributary slots of OPU2.
1 ODU0 is mapped into 1.25G tributary slots of OPU3.
1 ODU0 is mapped into 1.25G tributary slots of OPU4.
1 ODU1 is mapped into 2.5G tributary slots of OPU2.
1 ODU1 is mapped into 2.5G tributary slots of OPU3.
2 ODU1 is mapped into 1.25G tributary slots of OPU2.
2 ODU1 is mapped into 1.25G tributary slots of OPU3.
2 ODU1 is mapped into 1.25G tributary slots of OPU4.
4 ODU2 is mapped into 2.5G tributary slots of OPU3.
8 ODU2 is mapped into 1.25G tributary slots of OPU3.
8 ODU2 is mapped into 1.25G tributary slots of OPU4.
9 ODU2e is mapped into 1.25G tributary slots of OPU3.
8 ODU2e is mapped into 1.25G tributary slots of OPU4.
8 ODU2e is mapped into 1.25G tributary slots of OPU3e2.
4 ODU2e is mapped into 2.5G tributary slots of OPU3e1.
31 ODU3 is mapped into 1.25G tributary slots of OPU4.
1-8 ODUflex is mapped into 1.25G tributary slots of OPU2.
1-32 ODUflex is mapped into 1.25G tributary slots of OPU3.
1-80 ODUflex is mapped into 1.25G tributary slots of OPU4.
6. Generalized Label
6.1. Label Space
At the Digital Path layer (i.e. ODUk layers), G.709, G.709 Amendment
3 and G.sup43 define seven different client payload bit rates. An
Optical Data Unit (ODU) frame has been defined for each of these bit
rates. ODUk refers to the frame at bit rate k, where k =0 (for 1.25
Gpbs), k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), 2e for (10.25 Gbps), 3
(for 40 Gbps), 4 (for 100 Gbps) or flex (for 1.25*ts).
In addition to the support of ODUk mapping into OTUk, the G.709 label
space supports the sub-levels of ODUk multiplexing. ODUk
multiplexing refers to multiplexing of ODUj (j = 0, 1, 2, 2e, 3,
3e1,3e2 and flex) into an ODUk (k > j).
Following is the ODUk label format for the G.709 Amendment 3 and
G.sup43.
Fu, Ed., et al. Expires April 29, 2010 [Page 7]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserve | t4 | t3 | t2 |t1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Label Format for G.709 Amendment 3 and G.sup43
The specification of the fields t1, t2, t3 and t4 self-consistently
characterizes the ODUk label space. The value space for the t1, t2,
t3 and t4 fields is defined as follows:
1. t1 (2-bit):
* t1=[1..2] indicates the tributary slot (t1th) used by the ODU0
in an ODTUG1 (via ODTU01) mapped into an ODU1 (via OPU1).
ODU0 is mapped into 1.25G tributary slots of OPU1.
* t1 is not significant for the other ODUk signal types (i.e.,
t1 value MUST be set to 0 and ignored).
2. t2 (5-bit):
* t2=[1..8] indicates the tributary slot (t2th) used by the ODU0
in an ODTUG2 (via ODTU02) mapped into an ODU2 (via OPU2).
ODU0 is mapped into 1.25G tributary slots of OPU2.
* t2=[9..16] indicates the tributary slot (t2th-8) used by the
ODU1 in an ODTUG2 (via ODTU12) mapped into an ODU2 (via OPU2).
ODU1 is mapped into 1.25G tributary slots of OPU2. Two labels
need to be allocated for one ODU1 connection. They may be
continuous or non-continuous.
* t2=[17..24] indicates the tributary slot (t2th-16) used by the
ODUflex in an ODTUG2 (via ODTU2.ts) mapped into an ODU2 (via
OPU2). ODUflex is mapped into 1.25G tributary slots of OPU2.
How many labels need to be allocated for one ODUflex
connection is based on transport of a particular physical
layer client. The number of label is determined by the NMC
value. They may be continuous or non-continuous.
* t3=31 indicates an ODU2e sinal that is not further sub-
divided. Two control planes controlling G.sup43 network
elements which will be interworked should base on this
Generalized Label format.
* t2 is not significant for the other ODUk signal types (i.e.,
t2 value MUST be set to 0 and ignored).
Fu, Ed., et al. Expires April 29, 2010 [Page 8]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
3. t3 (8-bit):
* t3=[1..32] indicates the tributary slot (t3th) used by the
ODU0 in an ODTUG3 (via ODTU03) mapped into an ODU3 (via OPU3).
ODU0 is mapped into 1.25G tributary slots of OPU3.
* t3=[33..64] indicates the tributary slot (t3th-32) used by the
ODU1 in an ODTUG3 (via ODTU13) mapped into an ODU3 (via OPU3).
ODU1 is mapped into 1.25G tributary slots of OPU3. Two labels
need to be allocated for one ODU1 connection. They may be
continuous or non-continuous.
* t3=[65..96] indicates the tributary slot (t3th-64) used by the
ODU2 in an ODTUG3 (via ODTU23) mapped into an ODU3 (via OPU3).
ODU2 is mapped into 1.25G tributary slots of OPU3. Eight
labels need to be allocated for one ODU2 connection. They may
be continuous or non-continuous.
* t3=[97..128] indicates the tributary slot (t3th-96) used by
the ODU2e in an ODTUG3 (via ODTU3.ts) mapped into an ODU3 (via
OPU3). ODU2e is mapped into 1.25G tributary slots of OPU3.
Nine labels need to be allocated for one ODU2e connection.
They may be continuous or non-continuous.
* t3=[129..160] indicates the tributary slot (t3th-128) used by
the ODUflex in an ODTUG3 (via ODTU3.ts) mapped into an ODU3
(via OPU3). ODUflex is mapped into 1.25G tributary slots of
OPU3. How many labels needs to be allocated for one ODUflex
connection is based on transport of a particular physical
layer client. The number of label is determined by the NMC
value. They may be continuous or non-continuous.
* t3=[161..176] indicates the tributary slot (t5th-160) used by
the ODU2e in an ODTUG3e1 (via ODTU2e3e1) mapped into an ODU3e1
(via OPU3e1). ODU2e is mapped into 2.5G tributary slots of
OPU3e1. Four labels need to be allocated for one ODU2e
connection. They may be continuous or non-continuous. [NN]
The mapping of ODU2e into four 2.5G tributary slots is defined
in the non normative G.sup43. Two control planes controlling
G.sup43 network elements which will be interworked should base
on this Generalized Label format.
* t3=[177..208] indicates the tributary slot (t5th-176) used by
the ODU2e in an ODTUG3e2 (via ODTU2e3e2) mapped into an ODU3e2
(via OPU3e2). ODU2e is mapped into 1.25G tributary slots of
OPU3e2. Eight labels need to be allocated for one ODU2e
connection.[NN]
Fu, Ed., et al. Expires April 29, 2010 [Page 9]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
The mapping of ODU2e into eight 1.25G tributary slots is
defined in the non normative G.sup43. Two control planes
controlling G.sup43 network elements which will be interworked
should base on this Generalized Label format.
* t3 is not significant for the other ODUk signal types (i.e.,
t3 value MUST be set to 0 and ignored).
4. t4 (9-bit):
* t4=1 indicates an ODU4 signal that is not further sub-divided.
* t4=[2..81] indicates the tributary slot (t4th-1) used by the
ODU0 in an ODTUG4 (via ODTU4.1) mapped into an ODU4 (via
OPU4). ODU0 is mapped into 1.25G tributary slots of OPU4.
* t4=[82..161] indicates the tributary slot (t4th-81) used by
the ODU1 in an ODTUG4 (via ODTU4.2) mapped into an ODU4 (via
OPU4). ODU1 is mapped into 1.25G tributary slots of OPU4.
Two labels need to be allocated for one ODU1 connection. They
may be continuous or non-continuous.
* t4=[162..241] indicates the tributary slot (t4th-161) used by
the ODU2 in an ODTUG4 (via ODTU4.8) mapped into an ODU4 (via
OPU4). ODU2 is mapped into 1.25G tributary slots of OPU4.
Eight labels need to be allocated for one ODU2 connection.
They may be continuous or non-continuous.
* t4=[242..321] indicates the tributary slot (t4th-241) used by
the ODU2e in an ODTUG4 mapped into an ODU4 (via OPU4). ODU2e
is mapped into 1.25G tributary slots of OPU4. Eight labels
need to be allocated for one ODU2e connection. They may be
continuous or non-continuous.
* t4=[322..401] indicates the tributary slot (t4th-321) used by
the ODUflex (via ODTU4.ts) in an ODTUG4 mapped into an ODU4
(via OPU4). ODUflex is mapped into 1.25G tributary slots of
OPU4. How many labels needs to be allocated for one ODUflex
connection is based on transport of a particular physical
layer client. The number of label is determined by the NMC
value. They may be continuous or non-continuous.
* t4=[402..481] indicates the tributary slot (t4th-401) used by
the ODU3 (via ODTU4.32) in an ODTUG4 mapped into an ODU4 (via
OPU4). ODU3 is mapped into 1.25G tributary slots of OPU4.
Tirty-one labels need to be allocated for one ODU3 connection.
They may be continuous or non-continuous.
Fu, Ed., et al. Expires April 29, 2010 [Page 10]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
* t4 is not significant for the other ODUk signal types (i.e.,
t4 value MUST be set to 0 and ignored).
6.2. Label Distribution Rules
Label distribution rules are defined in [RFC4328] Section 4.2.
7. RSVP-TE Signaling Protocol Extensions
RSVP-TE will reuse the protocol extensions defined in [RFC4328]
Section 6 and does not need to be further extended. When a node
receives a Generalized Label Request, it can infer the label format
from the Signal Type and NMC pair. It don't need to depend on any
other means (e.g., management configuration or auto-discocvery).
Following is the example how to infer label format.
Signal Type NMC Label Format
ODU0 * [New Label Format]
ODU2e * [New Label Format]
ODUflex * [New Label Format]
ODU4 * [New Label Format]
ODU1 2 ----->[New Label Format]
ODU2 8 [New Label Format]
ODU3 31 [New Label Format]
ODU1 1 [RFC4328]
ODU2 4 [RFC4328]
ODU1 0 [RFC4328]
ODU2 0 [RFC4328]
ODU3 0 [RFC4328]
Instead when a non G.709 Amendment 3 aware node receives a
Generalized Label Request for a signals introduced in [ITUT-G709-
AMD3], it will not support the requested Signal Type and/or NMC
values. Then the receiver node MUST generate a PathErr message with
a "Traffic Control Error/Service unsupported" indication (see
[RFC2205]) as specified in [RFC4328].
8. Interworking Considerations
ODU multiplex structure of G.709(200303) only supports 2.5G TS. ODU
multiplex structure of G.709 Amd3 can support 1.25G TS or 2.5G TS and
1.25G TS. In terms of G.709 Amd 3, HO OPU2 and HO OPU3 interface
ports supporting 1.25 TS must also support the 2.5 TS mode for
interworking with interface ports supporting only the 2.5G TS mode.
When a 1.25G TS capable equipment receive the OPUk signal whose
Payload Type is 2.5G TS multiplex structure from the far end, it
Fu, Ed., et al. Expires April 29, 2010 [Page 11]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
shall operate in 2.5G TS mode. It should be an automatic adaptataion
process.
There must be some considerations on interworking between
G.709(200303) and G.709 Amd3 in the perspective of control plane.
Control plane designed for G.709 Amendment 3 should have the ability
to synchronously process the different Generalized Label format of
ODU1, ODU2 and ODU3 defined in [RFC4328] and this document. The
extension defined in this document is a supplement and extension of
[RFC4328].
1. When a new Path (Resv) message is to be sent for a downstream
(upstream) TE link, the format of Generalized Label is determined
by the Signal Type and/or multiplex structure of this port.
* If the Signal Type is ODU0, ODU2e, ODUflex or ODU4, the format
of Generalized Label must be based on this document.
* If the Signal Type is ODU1, ODU2 or ODU3 and the port is
operated only in 2.5G TS mode, the format of Generalized Label
must be based on [RFC4328].
* If the Signal Type is ODU1, ODU2 or ODU3 and the port supports
mapping directly into OTU1, OTU2 or OTU3, the format of
Generalized Label must be based on [RFC4328].
* If the Signal Type is ODU1, ODU2 or ODU3 and the port is
operated only in 1.25G TS or 2.5G TS and 1.25G TS mode, it
should try 1.25G TS mode firstly and the format of Generalized
Label must be based on this document.
If the interface port of downstream node can not support this
multiplex structure, the Path (Resv) message will be
terminated, and a PathErr message will be sent to the ingress,
or a ResvErr sent to the egress. The PathErr or ResvErr
including the IF_ID and ERROR_SPEC object should carry the
crankback information with a "Traffic Control Error/Service
unsupported" indication.
The ingress node will attemp to singal again with the same
routing. So this node will try 2.5G TS mode and the format of
Generalized Label must be based on [RFC4328].
2. When a new Path (Resv) message is to be received on a upstream
(downstream) TE link, the Generalized Label format is identified
by the Signal Type and NMC pair in Traffic Parameters.
Fu, Ed., et al. Expires April 29, 2010 [Page 12]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
* When the Signal Type and NMC pair is (ODU1, 2), (ODU2, 8) or
(ODU3, 31), the format of Generalized Label should be based on
this document, the node must check the interface port mode.
If it can not support 1.25G TS mode or the Signal Type, the
Path (Resv) message will be terminated, and a PathErr message
with a "Traffic Control Error/Service unsupported" indication
will be generated.
* When the Signal Type and NMC pair is (ODU1, 1), (ODU1, 0),
(ODU2, 4), (ODU2, 0), or (ODU3, 0), the format of Generalized
Label should be based on [RFC4328]. In this case the receiver
will always support this label format. If it can not support
this Signal Type, the Path (Resv) message will be terminated,
and a PathErr message with a "Traffic Control Error/Service
unsupported" indication will be generated.
* When a downstream (upstream) node receives Path (Resv) message
in which Signal Type is ODU0, ODU2e, ODUflex and ODU4, it must
identify the Generalized Label format based on this document.
If it can not support this Signal Type, the Path (Resv)
message will be terminated, and a PathErr message with a
"Traffic Control Error/Service unsupported" indication will be
generated.
Following figure is a interworking example between G.709(200303) and
G.709 Amd 3.
4*2.5G TS 32*1.25G TS 80*1.25G TS 16*2.5G TS 8*1.25G TS
| | | | |
| | | | |
\|/ \|/ \|/ \|/ \|/
+----+ OTU2 +----+ OTU3 +----+ OTU4 +----+ OTU3 +----+ OTU2 +----+
-|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|-
+----+ +----+ +----+ +----+ +----+ +----+
Figure 2: Interworking Scenario between G.709(200303) and G.709 Amd3
When we need to setup a ODU2 (10G bandwidth) LSP between DXC1 and
DXC6, the path computation entiy may computate an DXC1-DXC2-DXC3-
DXC4-DXC5-DXC6 route.
1. In the case of one end-to-end session, the NMC has to be changed
in node where the TE link supporting 1.25G TS and the TE link
supporting 2.5G TS are connected (i.e., DXC2, DXC4, and DXC5).
Fu, Ed., et al. Expires April 29, 2010 [Page 13]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
+----+ +----+ +----+ +----+ +----+ +----+
-|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|-
+----+ +----+ +----+ +----+ +----+ +----+
Path Path Path Path Path
-------> ------> ------> -------> ------->
ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2
NMC=4 NMC=8 NMC=8 NMC=4 NMC=8
Resv Resv Resv Resv Resv
<------- <------ <------ <------- <-------
ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2 ST=ODU2
NMC=4 NMC=8 NMC=8 NMC=4 NMC=8
Figure 3: Contiguous TE LSP
2. The end-to-end connection also can be setuped with multiple
segment session (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1
LSP4).
+----+ +----+ +----+ +----+ +----+ +----+
-|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|-
+----+ +----+ +----+ +----+ +----+ +----+
| | | | |
|<-ODU1 LSP1->|<-----ODU1 LSP2------>|<-ODU1 LSP3->|<-ODU1 LSP4->|
Figure 4: Stitching TE LSP
if the segment LSP can be created and prepaired for stitching by
signaling, the end-to-end connection is stitched to several
segment LSPs (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 LSP4).
The NMC in traffic parameters of this end-to-end session is no
meaning.
9. Example of Generalized Label
The following examples are given in order to illustrate the
processing described in this document.
1. ODU2e in OTU2e mapping or ODU4 in OTU4 mapping: when one ODU2e
(ODU4) signal is directly transported in an OTU2e (OTU4),the
upstream node requests results simply in an ODU2e (ODU4) signal
request.
In such conditions, the downstream node has to return a unique
label because the ODU2e (ODU4) is directly mapped into the
corresponding OTU2e (OTU4). Because a single ODUk signal is
requested, the downstream node has to return a single ODUk
Fu, Ed., et al. Expires April 29, 2010 [Page 14]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
label, which can be, for instance, one of the following:
- Signal type=ODU4, t4=1, t3=0, t2=0, t1=0;
indicates a single ODU4 mapped into an OTU4
- Signal type=ODU2e, t4=0, t3=0, t2=31, t1=0;
indicates a single ODU2e mapped into an OTU2e
2. ODU0 into ODUk multiplexing (k = 1, 2, 3 or 4): when one ODU0 is
multiplexed into the payload of a structured ODU1 (ODU2, ODU3 or
ODU4), the upstream node requests results simply in an ODU0
signal request.
In such conditions, the downstream node has to return a unique
label because the ODU0 is multiplexed into one ODTUG1 (ODTUG2,
ODTUG3 or OTDUG4). The latter is then mapped into the ODU1
(ODU2, ODU3 or ODU4) via OPU1 (OPU2, OPU3 or OPU4) and then
mapped into the corresponding OTU1 (OTU2, OTU3 or OTU4).
Because a single ODU0 multiplexed signal is requested (Signal
Type = ODU0 and NMC = 1), the downstream node has to return a
single ODU0 label, which can take, for instance, one of the
following values:
- t4=0, t3=0, t2=0, t1=1;
indicates the ODU0 in the 1st TS of the ODTUG1
- t4=0, t3=0, t2=4, t1=0;
indicates the ODU0 in the 4th TS of the ODTUG2
- t4=0, t3=26, t2=0, t1=0;
indicates the ODU0 in the 26th TS of the ODTUG3
- t4=69, t3=0, t2=0, t1=0;
indicates the ODU0 in the 68th TS of the ODTUG4
3. ODU1 into 1.25G tributary slots of OPUk (k = 2, 3, 4)
multiplexing: when one ODU1 is multiplexed into the payload of a
structured ODU2 (ODU3 or ODU4), the upstream node requests
results simply in an ODU1 signal request.
In such conditions, the downstream node has to return two labels
because the ODU1 is multiplexed into one ODTUG2 (ODTUG3 or
ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4)
via OPU2 (OPU3 or OPU4) and then mapped into the corresponding
OTU2 (OTU3 or OTU4). Because a single ODU1 multiplexed signal
is requested (Signal Type = ODU1 and NMC = 2), the downstream
node has to return two ODU1 labels, which can take, for
instance, the following values:
Fu, Ed., et al. Expires April 29, 2010 [Page 15]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
- t4=0, t3=0, t2=13, t1=0;
indicates the ODU1 in the 5th 1.25G TS of the ODTUG2
or
- t4=0, t3=58, t2=0, t1=0;
indicates the ODU1 in the 26th 1.25G TS of the ODTUG3
or
- t4=82, t3=0, t2=0, t1=0;
indicates the ODU1 in the 1st 1.25G TS of the ODTUG4
4. ODU2 into 1.25G tributary slots of OPU3: when one ODU2 is
multiplexed into the payload of a structured ODU3, the upstream
node requests results simply in an ODU2 signal request.
In such conditions, the downstream node has to return eight
labels because the ODU2 is multiplexed into one ODTUG3. The
latter is then mapped into the ODU3 via OPU3 and then mapped
into the corresponding OTU3. Because a single ODU1 multiplexed
signal is requested (Signal Type = ODU2 and NMC = 8), the
downstream node has to return eight ODU2 labels, which can take,
for instance, the following values:
- t4=0, t3=67, t2=0, t1=0;
indicates the ODU2 in the 3rd 1.25G TS of the ODTUG3
- t4=0, t3=73, t2=0, t1=0;
indicates the ODU2 in the 9th 1.25G TS of the ODTUG3
- t4=0, t3=82, t2=0, t1=0;
indicates the ODU2 in the 18th 1.25G TS of the ODTUG3
5. ODU2/ODU2e into ODU4 multiplexing: when one ODU2 (or ODU2e) is
multiplexed into the payload of a structured ODU4, the upstream
node requests results simply in an ODU2 (or ODU2e) signal
request.
In such conditions, the downstream node has to return eight
labels because the ODU2 (ODU2e) is multiplexed into one ODTUG4.
The latter is then mapped into the ODU4 via OPU4 and then mapped
into the corresponding OTU4. Because a single ODU2 (or ODU2e)
multiplexed signal is requested (Signal Type = ODU2 and NMC = 8
or Signal Type = ODU2e and NMC = 8), the downstream node has to
return eight ODU2 (or ODU2e) labels, one of which can take, for
instance, the following values:
Fu, Ed., et al. Expires April 29, 2010 [Page 16]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
- Signal type=ODU2, t4=182, t3=0, t2=0, t1=0;
indicates the ODU2 in the 21st TS of the ODTUG4
- Signal type=ODU2e, t4=320, t3=0, t2=0, t1=0;
indicates the ODU2e in the 79th TS of the ODTUG4
6. ODU3 into ODU4 multiplexing: when one ODU3 is multiplexed into
the payload of a structured ODU4, the upstream node requests
results simply in an ODU3 signal request.
In such conditions, the downstream node has to return thirty-two
labels because the ODU3 is multiplexed into one ODTUG4. The
latter is then mapped into the ODU4 via OPU4 and then mapped
into the corresponding OTU4. Because a single ODU3 multiplexed
signal is requested (Signal Type = ODU3 and NMC = 31), the
downstream node has to return thirty-one ODU3 labels, one of
which can take, for instance, the following values:
- t4=408, t3=0, t2=0, t1=0;
indicates the ODU3 in the 7th TS of the ODTUG4
- t4=449, t3=0, t2=0, t1=0;
indicates the ODU3 in the 48th TS of the ODTUG4
- t4=472, t3=0, t2=0, t1=0;
indicates the ODU3 in the 71st TS of the ODTUG4
7. ODU2e into 1.25G tributary slots of OPU3: when one ODU2e is
multiplexed into the payload of a structured ODU3, the upstream
node requests results simply in an ODU2e signal request.
In such conditions, the downstream node has to return nine
labels because the ODU2e is multiplexed into one ODTUG3. The
latter is then mapped into the ODU3 via OPU3 and then mapped
into the corresponding OTU3. Because a single ODU2e multiplexed
signal is requested (Signal Type = ODU2e and NMC = 9), the
downstream node has to return nine ODU2e labels, one of which
can take, for instance, the following values:
- t4=0, t3=100, t2=0, t1=0;
indicates the ODU2e in the 4th 1.25G TS of the ODTUG3
- t4=0, t3=112, t2=0, t1=0;
indicates the ODU2e in the 16th 1.25G TS of the ODTUG3
- t4=0, t3=120, t2=0, t1=0;
indicates the ODU2e in the 24th 1.25G TS of the ODTUG3
Fu, Ed., et al. Expires April 29, 2010 [Page 17]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
8. [NN]-ODU2e into ODU3e1 multiplexing: when one ODU2e is
multiplexed into the payload of a structured ODU3e1, the
upstream node requests results simply in an ODU2e signal
request.
In such conditions, the downstream node has to return four
labels because the ODU2e is multiplexed into one ODTUG3e1. The
latter is then mapped into the ODU3e1 via OPU3e1 and then mapped
into the corresponding OTU3e1. Because a single ODU2e
multiplexed signal is requested (Signal Type = ODU2e and NMC =
4), the downstream node has to return four ODU2e labels, which
can take, for instance, the following values:
- t4=0, t3=161, t2=0, t1=0;
indicates the ODU2e in the 1st TS of the ODTUG3e1
- t4=0, t3=166, t2=0, t1=0;
indicates the ODU2e in the 6th TS of the ODTUG3e1
- t4=0, t3=170, t2=0, t1=0;
indicates the ODU2e in the 10th TS of the ODTUG3e1
- t4=0, t3=175, t2=0, t1=0;
indicates the ODU2e in the 15th TS of the ODTUG3e1
9. [NN]-ODU2e into ODU3e2 multiplexing: when one ODU2e is
multiplexed into the payload of a structured ODU3e2, the
upstream node requests results simply in an ODU2e signal
request.
In such conditions, the downstream node has to return eight
labels because the ODU2e is multiplexed into one ODTUG3e2. The
latter is then mapped into the ODU3e2 via OPU3e2 and then mapped
into the corresponding OTU3e2. Because a single ODU2e
multiplexed signal is requested (Signal Type = ODU2e and NMC =
8), the downstream node has to return eight ODU2e labels, one of
which can take, for instance, the following values:
- t4=0, t3=181, t2=0, t1=0;
indicates the ODU2e in the 5th TS of the ODTUG3e2
- t4=0, t3=197, t2=0, t1=0;
indicates the ODU2e in the 21st TS of the ODTUG3e2
- t4=0, t3=207, t2=0, t1=0;
indicates the ODU2e in the 31st TS of the ODTUG3e2
Fu, Ed., et al. Expires April 29, 2010 [Page 18]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
10. ODUflex is mapped into 1.25G tributary slots of OPU2 (OPU3 or
OPU4). when one ODUflex is multiplexed into the payload of a
structured ODU2 (ODU3 or ODU4), the upstream node requests
results simply in an ODUflex signal request.
In such conditions, the downstream node has to return some
labels whose number is determined in terms of NMC value.
Because the ODUflex is multiplexed into one ODTUG2 (ODTUG3 or
ODTUG4). The latter is then mapped into the ODU2 (ODU3 or ODU4)
via OPU2 (OPU3 or OPU4) and then mapped into the corresponding
OTU2 (OTU3 or OTU4). Because a single ODUflex multiplexed
signal is requested (Signal Type = ODUflex), the downstream node
has to return some labels (i.e., the number of labels is NMC),
which can take, for instance, the following values:
- t4=0, t3=0, t2=21, t1=0;
indicates the ODUflex in the 5th 1.25G TS of the ODTUG2
or
- t4=0, t3=150, t2=0, t1=0;
indicates the ODUflex in the 22nd 1.25G TS of the ODTUG3
or
- t4=368, t3=0, t2=0, t1=0;
indicates the ODUflex in the 47th 1.25G TS of the ODTUG4
10. Acknoledgments
We wish to thank Attila Takacs and Andras Kern for their assistance
and precious advices to prepare this draft for publication.
Fu, Ed., et al. Expires April 29, 2010 [Page 19]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
11. Contributors
Diego Caviglia
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: diego.caviglia@ericsson.com
Francesco Fondelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: francesco.fondelli@ericsson.com
Ming Ke
ZTE Corporation
3F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road
Nanshan District,Shenzhen 518055
P.R.China
Email: ke.ming@zte.com.cn
Yuanlin Bao
ZTE Corporation
5F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road
Nanshan District,Shenzhen 518055
P.R.China
Email: bao.yuanlin@zte.com.cn
Lizhong Jin
Nokia Siemens Networks
Building 89, 1122 North QinZhou Road,
Shanghai, 200211
P.R.China
Email: lizhong.jin@nsn.com
12. Security Considerations
The procedures described in this document rely completely on RSVP-TE
messages and mechanism. The use of H bit set in Admin Status Object
Fu, Ed., et al. Expires April 29, 2010 [Page 20]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
basically informs the receiving entity that no operations are to be
done over Data Plane as consequence of such special signaling flow.
Using specially flagged signaling messages we want to limit the
function of setup and tear down messages to Control Plane, making
them not effective over related Data Plane resource usage. So, no
additional or special issues are arisen by adopting this procedure,
that aren't already brought up by the use of the same messages,
without H bit setting, for LSP control. For RSVP-TE Security please
refer to [RFC3473].
13. IANA Considerations
TBD.
14. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
15. Normative References
[ITUT-G709]
ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation (and Amendment 1) ,
October 2001.
[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.
[RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress
Control", RFC 4003, February 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Fu, Ed., et al. Expires April 29, 2010 [Page 21]
Internet-Draft GMPLS Extension for Evolutive OTN October 2009
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February 2008.
Authors' Addresses
Xihua Fu
ZTE
West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
Xi An 710065
P.R.China
Phone: +8613798412242
Email: fu.xihua@zte.com.cn
URI: http://wwwen.zte.com.cn/
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Phone:
Email: daniele.ceccarelli@ericsson.com
Marco Corsi
Altran
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Phone:
Email: marco.corsi@altran.it
Fu, Ed., et al. Expires April 29, 2010 [Page 22]