One document matched: draft-khuzema-ccamp-gmpls-signaling-g709-02.txt
Differences from draft-khuzema-ccamp-gmpls-signaling-g709-01.txt
CCAMP Working Group Khuzema Pithewan
Internet-Draft Rajan Rao
Intended status: Proposed Standard Ashok Kunjidhapatham
Expires: December 31, 2011 Biao Lu
Mohit Misra
Infinera
Lyndon Ong
Ciena
Igor Bryskin
Adva
June 29, 2011
Signaling Extensions for Generalized MPLS (GMPLS) Control of
G.709 Optical Transport Networks
draft-khuzema-ccamp-gmpls-signaling-g709-02.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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Khuzema, et al. Expires December 31, 2011 [Page 1]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
As OTN network capabilities continue to evolve, there is an increased
need to support GMPLS control for the same. [RFC4328] introduced
GMPLS signaling extensions for supporting early version of G.709
[G.709-v1].The basic routing considerations from signaling
perspective is also specified in [RFC4328].
The recent revision of ITU-T Recommendation G.709 [G.709-v3] and
[GSUP.43] have introduced new ODU containers (both fixed and
flexible) and additional ODU multiplexing capabilities, enabling
support for optimal service aggregation.
This document extends [RFC4328] to provide GMPLS signaling support
for the new OTN capabilities defined in [G.709-v3] and [GSUP.43]. The
signaling extensions described in this document caters to ODU layer
switching only. Optical Channel Layer switching considerations in
[RFC4328] are not modified in this document.
Khuzema, et al. Expires December 31, 2011 [Page 2]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . . 5
3. Requirements for supporting services over hierarchical OTN
network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of GMPLS Signaling Extensions for supporting
hierarchical OTN networks . . . . . . . . . . . . . . . . . . . 6
5. Extensions to G.709 Traffic Parameters . . . . . . . . . . . . . 7
5.1. Usage of Bit_Rate and Tolerance for ODUflex Service . . . . 9
6. New Generalized Label Format . . . . . . . . . . . . . . . . . . 9
6.1 Multi-stage Label . . . . . . . . . . . . . . . . . . . . . 9
6.2. Label format for NVC or Multiplier > 1 . . . . . . . . . 11
7. Usage of Multi-stage Label . . . . . . . . . . . . . . . . . . 11
8. Label Distribution Rules . . . . . . . . . . . . . . . . . . . 13
9. Interoperability Considerations . . . . . . . . . . . . . . . 14
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . 19
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B : RFC4328 and G.709v3 . . . . . . . . . . . . . . . . 23
Khuzema, et al. Expires December 31, 2011 [Page 3]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
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].
ITU-T Recommendations G.709 and G.872 provide specifications for OTN
interface and network architecture respectively. As OTN network
capabilities continue to evolve; there is an increased need to
support GMPLS control for the same.
GMPLS signaling extensions to support [G.709-v1] OTN interfaces are
specified in [RFC4328]. Further extensions are required to support
the new capabilities introduced since [G.709-v1]. Following are the
features added in OTN since the first version [G.709-v1].
(a) OTU Containers:
Pre-existing Containers: OTU1, OTU2 and OTU3
New Containers introduced in [G.709-v3]: OTU2e and OTU4
New Containers introduced in [GSUP.43]: OTU1e, OTU3e1 and OTU3e2
(b) Fixed ODU Containers:
Pre-existing Containers: ODU1, ODU2 and ODU3
New Containers introduced in [G.709-v3]: ODU0, ODU2e and ODU4
New Containers introduced in [GSUP.43]: ODU1e, ODU3e1 and ODU3e2
(c) Flexible ODU Containers:
ODUflex for CBR and GFP-F mapped services. ODUflex uses 'n'
number of OPU Tributary Slots where 'n' is different from the
number of OPU Tributary Slots used by the Fixed ODU Containers.
(d) Tributary Slot Granularity:
OPU2 and OPU3 support two Tributary Slot Granularities: (i)
1.25Gbps and (ii) 2.5Gbps.
(e) ODU Multiplexing Hierarchy:
Multi-stage multiplexing of LO-ODUs into HO-ODU is supported.
Also, multiplexing could be heterogeneous (meaning LO-ODUs of
different rates can be multiplexed into the same HO-ODU).
OTN networks support switching at two layers: (i) ODU Layer - TDM
Switching and (ii) OCH Layer - Lambda (LSC) Switching. The nodes on
the network may support one or both the switching types. When
Khuzema, et al. Expires December 31, 2011 [Page 4]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
multiple switching types are supported MLN based routing [RFC5339] is
assumed.
This document extends [RFC4328] to provide GMPLS signaling support
for the new OTN capabilities defined in [G.709-v3] and [GSUP.43].
This complies with the requirements outlined in the framework
document [G.709-FRAME]. The signaling extensions described in this
document caters to ODU layer switching only. Optical Channel Layer
switching considerations in [RFC4328] are not modified in this
document.
Following are the extensions described in this document:
(i) G.709 Traffic Parameters defined in [RFC4328] is extended to
include Bit Rate (in bytes/second) and Tolerance (in ppm) fields for
supporting ODUflex service.
(ii) New Generalized Label Format is introduced to provide compact
encoding of Tributary Slot information and support multi-stage ODU
multiplexing.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document is to be interpreted as described in RFC-2119 [RFC2119].
In addition, the reader is assumed to be familiar with the
terminology used in ITU-T [G.709-v3], [G.872] and [GSUP.43], as well
as [RFC4201] and [RFC4203].
3. Requirements for supporting services over hierarchical OTN network
R1. Support signaling mechanism to instantiate ODUj service layer on
a ODUk link via single stage muxing.
A ODUj LSP could involve zero (j=k) or one stage (j<k)
multiplexing on a given ODUk link. Here both Contorl-plane and
Data-plane entities are created for the ODUj service layer.
ODUk link could be a point-to-point OTUk link or a H-LSP.
R2. Support signaling mechanism to instantiate one or more
intermediate layers on a ODUk link in order to support the ODUj
service layer.
Khuzema, et al. Expires December 31, 2011 [Page 5]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
A ODUj LSP could involve two or more stage multiplexing on a
given ODUk link. These intermediate layers can be implicitly
created as a part of ODUj service LSP creation. In this case,
both controlplane and dataplane entities will be created for the
ODUj service layer. However, intermediate ODU layer(s)
(implicitly created) will have dataplane representation only.
R3. Support signaling mechanism to instantiate ODUj service layer on
a ODUk link where one or more intermediate ODU layers may be pre-
existing.
A ODUj LSP could involve two or more stage multiplexing on a
given ODUk link. These intermediate layers may be pre-existing
as a result of another LSP creation on the same ODU hierarchy or
explicitly configured through management interface.
R4. Support signaling mechanism where ODUj service LSP creation may
involve varying mux hierarchies on each hop
An end-to-end ODUj service LSP creation may involve zero or more
stage ODU multiplexing on every hop in the path. Basically,the
scenarios discussed in R1 to R3 could be associated with any of
the hops involved.
R5. Support signaling mechanism for egress control of OTN interfaces
An egress interface of a ODUj LSP could involve single or
multiple stage multiplexing. Egress Label sub-object defined in
[RFC-4003] must be used to signal hierarchical multiplexing
information pertaining to the egress interface of the LSP.
R6. Support signaling mechanism when ODUj service LSP creation
requires induced or manually created H-LSP.
4. Overview of GMPLS Signaling Extensions for supporting hierarchical
OTN networks
The GMPLS signaling extensions introduced in [RFC4328] cover OTN
switching requirement pertaining to [G.709-v1]. The signaling
objects defined in [RFC4328] need to be further extended to cover
the new capabilities added to OTN since the first version of
G.709 [G.709-v1]. A brief overview of the extensions required are
captured below:
(a) Support for the new ODU containers
The new ODU containers added since [G.709-v1] are listed in the
section-1. SignalType attribute defined in [RFC4328] need to be
extended to cover the new signal types. This is captured in
Khuzema, et al. Expires December 31, 2011 [Page 6]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
[OSPF-EXTN-FOR-OTN].
(b) Support for ODUflex
Unlike the other ODUj signal types, ODUflex requires an user
specified bit-rate (together with a Tolerance value) to be mapped
to 'n' TSs of an higher-order container. Even within the same
Tributary Slot Granularity, the Tributary Slot size varies among
the ODU container of different rate. This results in ODUflex
service of certain bit-rate and tolerance requiring different
number of TSs on different higher order ODU containers. The
present way of specifying bandwidth requirement (via NMC field in
G.709 Traffic Parameters) will not work for ODUflex. G.709
Traffic Parameters object need to be extended to include Bit-Rate
(in bytes/sec) and Tolerance (in ppm) fields as well.
(c) Support for ODU multiplexing hierarchy
The G.709 Traffic Parameter and Generalized Label Format defined
in [RFC4328] supports single stage multiplexing only. A new
Generalized Label Format need to be introduced to support
specification of multi-stage label.
ODUk-------------------ODUj-------------------ODUh
TS/TPN for stage-1 TS/TPN for stage-2
Figure-1: Multi-stage Label
(d) Support for different OPU Tributary Slot Granularities
The G.709 Traffic Parameters and Generalized Label Format defined
in [RFC4328] supports 2.5Gbps Tributary Slot Granularity only.
With [G.709-v3], two types of tributary slots are supported -
viz., 1.25Gbps and 2.5Gbps. The Generalized Label Format need to
be equipped with Tributary Slot Type indicator to facilitate
interpretation of the encoded TS information.
(e) Exchange of Tributary Port Number
A Tributary Port Number (TPN) in MSI field of OPU-OH is used to
correlate the TSs used for mapping a LO-ODU on a HO-ODU. This
needs to be exchanged along with the Label such that each
neighbor on a span knows the TPN value to expect for a given ODUj
mapping. This applies to each stage associated with a multi-stage
label. The Generalized Label Format needs to be extended to
include TPN value for each stage of multiplexing.
5. Extensions to G.709 Traffic Parameters
Khuzema, et al. Expires December 31, 2011 [Page 7]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
G.709 Traffic Parameters defined in [RFC4328] is extended to
include additional fields in support of ODUflex service as
explained in the previous section. The modified object format is
captured below:
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/Tolerance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit_Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type
As explained in the previous section, Signal Type attribute needs
to be extended to cover the new ODU containers defined in more
recent G.709 specification [G.709-v3].
Value Type
----- ----
4 ODU4 (100Gbps)
5 ODU0 (1.25Gbps)
10 ODUflex
11 ODU1e (10Gbps Ethernet [GSUP.43])
12 ODU2e (10Gbps Ethernet)
13 ODU3e1 (40Gbps Ethernet [GSUP.43])
14 ODU3e2 (40Gbps Ethernet [GSUP.43])
15-255 Reserved (for future)
NMC/Tolerance
This field is redefined from the original definition in
[RFC4328]. NMC field defined in [RFC4328] can not be fixed value
for an end-to-end circuit involving dissimilar OTN link types.
For example, ODU2e requires 9 TS on ODU3 and 8 TS on ODU4. Usage
of NMC field is deprecated and should be used only with [RFC4328]
generalized label format for backwards compatibility reasons.
For the new generalized label format as defined in this document
this field is interpreted as Tolerance. The unit of tolerance is
ppm and is encoded as unsigned integer. For signal types other
than ODUflex, Tolerance field should be coded as 0.
Bit_Rate
Khuzema, et al. Expires December 31, 2011 [Page 8]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
Bit_Rate is used when signal Type is ODUFlex. For all the other
signal types, this field should be coded as zero.
5.1. Usage of Bit_Rate and Tolerance for ODUflex Service
Bit_Rate and Tolerance are used together to compute number of
Tributary slots required for ODUFlex(CBR) traffic on a given
higher order ODU container. The computation of Number of
Tributary Slot (n) is as follows.
Ceiling of Bit_Rate * (1 + Tolerance)
n = --------------------------------------------------
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
6. New Generalized Label Format
As explained in section 3, the Generalized Label format defined
in [RFC4328] can not accommodate the new features added in
[G.709v3]. Further the label format as defined in [RFC4328] is
not scalable for large number of Tributary Slots (at 1.25G
granularity) associated with bigger containers such as ODU3 and
ODU4.
The Generalized Label for G.709 may contain one or more multi-
stage Label.
6.1 Multi-stage Label
A multi-stage label includes TS and TPN information for all the
stages of a multi-stage multiplexing hierarchy.
The format of a multi-stage label is explained below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num MUX Stages| OD(T)Uk (ST) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tributary Slot Info (Stage-1) |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tributary Slot Info (Stage-n) |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Khuzema, et al. Expires December 31, 2011 [Page 9]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
Num MUX Stages
This field indicates the number of multiplexing stages specified
by the label.
OD(T)Uk
This field encodes the signal type of HO OD(T)Uk container.
Tributary Slot Info
Tributary Slot Information for a single stage is encoded as
follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ODUj (ST) | T | Length | Tributary Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Length Bit Map (4-byte boundary aligned) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ODUj
This field indicates the signal type of a LO-ODU being
multiplexed into its immediate HO-ODU.
T
This is a 2 bit field, which defines the granularity of tributary
slots for this multiplexing stage. It can take following values
T field TS Granularity type
------- -------------------
0 1.25Gbps
1 2.5Gbps
2-3 Reserved (for future use)
Length
This field indicates the number of valid Bits in the of Bit Map
excluding the filler bits.
Tributary Port Number(TPN)
This field is encoded with TPN value assigned for a ODTUjk or
Khuzema, et al. Expires December 31, 2011 [Page 10]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
ODTUk.ts on a OPUk. TPN assignment could be fixed or flexible.
For fixed TPN assignment scheme, TPN value need not be specified.
In this case, TPN value should be coded as 0xFFFFFFFF.
For flexible TPN assignment scheme, TPN value should contain the
assigned logical value. Not all the bits of TPN are used. Only a
subset of bits are used depending on the ODTU type.
Bit Map
This is a multi-byte bit map field. The length of this field
varies depending on the number of TSs associated with the
immediate HO-ODU pertaining to the stage. Each bit represents one
TS. Bit values are interpreted as follows
Bit Value Meaning
--------- -------
0 Not Used
1 Used
This field must be 4 byte aligned using filler bytes.
6.2. Label format for NVC or Multiplier > 1
For NVC or Multiplier field value > 1, the label format defined
in section 5 needs to be repeated NVC/multiplier times.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Instance #1 |
| (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Instance #n |
| (n = NVC/Multiplier) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Usage of Multi-stage Label
Multi-stage Label is needed when switching of an ODU Layer
requires termination of more than one HO-ODUs on a given OTU/ODU
Link. This eliminates the need for creating H-LSPs whose span
matches its parent TE-Link.
Khuzema, et al. Expires December 31, 2011 [Page 11]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
Example-1:
Assume on an OTU3 Link, a restrictive MUX hierarchy (as shown in
figure below) is supported on the associated interfaces. In order
to switch ODU1 on this Link, ODU3 and ODU2 need to be terminated
on the same span as the OTU3 link. If multi-stage Label is not
supported, H-LSP need to be created for ODU3 and ODU2 layers (or
just ODU2 layer at the minimum) inorder to support ODU1 LSP.
Creation of ODU3 and ODU2 H-LSP on top of OTU3 Link on the same
span is not really required as bandwidth management for all ODU
layers can still be managed on the OTU3 Link itself.
Multi-stage Label helps in implicit creation of ODU3 and ODU2
layers as part of ODU1 LSP setup and thus eliminates the need for
the creation of the H-LSP on every hop.
ODU0
|
ODU1 ODU0
\ /
ODU2
|
---------- ODU3 ----------
| | | | |
| Node | OTU3 | Node |
| |-----------------------------| |
| A | | B |
| | | |
---------- ----------
|<----- OTU3 TE-Link ------->|
Label Format:
Stage-1: ODU3<-ODU2/TPN/Trib Slots
Stage-2: ODU2<-ODU1/TPN/Trib Slots
Figure-2: Multi-stage Label on OTUk Link
Example-2:
Assume on an ODU3 H-LSP (B-C-D), signaling of ODU1 LSP requires
termination of ODU2. Multi-stage Label helps in implicit creation
of ODU2 layer as part of ODU1 LSP setup (A-B-D-E).
Khuzema, et al. Expires December 31, 2011 [Page 12]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
ODU1 ODU1
| |
ODU2 ODU2
| |
ODU3 ODU3
| |
OTU3 OTU3
/ \
------ -----/ ------ \------ ------
| | | | | | | | | |
|Node| |Node| |Node| |Node| |Node|
| |--------| |--------| |--------| |--------| |
| A | | B | | C | | D | | E |
| | | | | | | | | |
------ ------ ------ ------ ------
|<-OTU2->| |<-OTU3->| |<-OTU3->| |<-OTU2->|
| |
|<-----ODU3 H-LSP----->|
Figure-3: Multi-stage Label on ODUk Link
Note: Multi-stage Label is NOT intended to facilitate the
creation of H-LSP or Hierarchical LSP. It is basically used to
eliminate the need for H-LSP in some obvious scenarios.
8. Label Distribution Rules
This document does not change the existing label distribution
procedures defined in [RFC4328] except that the new ODU label
should be processed as follows.
A. Sending Side
When Generalized Label Request is received on given node for
setting up an ODU LSP from its upstream neighbor, it reserves the
bandwidth required for the ODU Layer being switched and also the
terminating HO-ODUs layers involved. It sends upstream label and
suggested label (if applicable) to the downstream node and
downstream label via PATH Message and downstream label to the
upstream node via RESV Message.
Note that Label can also be explicitly specified by source node.
The encoding of Generalized Label is as follows:
Khuzema, et al. Expires December 31, 2011 [Page 13]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
Case-1: ODUk mapping into OTUk
Number of MUX stages = 0
Tributary Slot information is not included.
Case-2: ODUj mux into ODUk
Number of MUX Stages = 1.
Stage-1: Length = <number of TSs on ODUk>.
TPN = <specified as per Section 5>
TS BitMap = <TSs reserved for ODUj are set to 1>
Case-3 ODUh mux into ODUj into ODUk
Number of MUX Stages = 2.
Stage-1: Length = <number of TSs on ODUk>.
TPN = <specified as per Section 5>
TS BitMap = <TSs reserved for ODUj are set to 1>
Stage-2: Length = <number of TSs on ODUj>.
TPN = <specified as per Section 5>
TS BitMap = <TSs reserved for ODUh are set to 1>
B. Receiving Side
The decoding of the Generalized Label is as follows:
Case-1: ODUk mapping into OTUk
For ODUk to OTUk mapping, the Tributary Slot Information is not
expected.
Case-2: ODUj mux into ODUk
For ODUj to ODUk multiplexing, one MUX stage Label is expected.
The node extracts the Bit Map field in Tributary Slot Info using
the Length field. The position of Bit in the Bitmap interpreted
as the Tributary Slot Number. The value stored in the bit
indicates if it is reserved for the ODUj.
Case-3: ODUh mux into ODUj into ODUk
For ODUh mux into ODUj into ODUk, two MUX stage Label is
expected. Each stage is further decoded as explained in case-2
above.
9. Interoperability Considerations
The neighbor nodes on a TE-Link span should exchange the
signaling stack versions (via some link discovery mechanism) in
order to determine the Generalized Label Format to use.
In the following example, Switch B and C are running the newer
version of signaling stack (that support the new G.709 Traffic
Parameters and Generalized Label Format) while Switch A is
Khuzema, et al. Expires December 31, 2011 [Page 14]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
running the older version.
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
|<-- Legacy -->| |<-- New TE-Link -->|
Figure-4: OTUk TE-Link
Link A-B: G.709-v1 version (2001) based OTUk link
TSG: 2.5G;
Label format: as per RFC 4328
Link B-C: G.709-v3 version based OTUk link (12/09)
TSG: 1.25G;
Label format: new label format proposed in this draft.
For an ODU2 connection going from A-C,
On link A-B : NMC is set to 4 & [RFC4328] label format is used.
On link B-C : NMC is not used & new label format is used.
10. Examples
Example-1 : ODUj LSP over OTUk Links
Consider the network topology shown in the Figure-5 below:
+-----+ +-----+ +-----+ +-----+
| OTN | | OTN | | OTN | | OTN |
| SW |<-OTU2 Link->| SW |<-OTU3 Link->| SW |<-OTU2 Link->| SW |
| A | | B | | C | | D |
+-----+ +-----+ +-----+ +-----+
Figure-5: OTN Signaling Example
Assumptions:
(1) ODU2 links between OTN-Switches A & B and C & D support
1.25Gbps TS Granularity.
(2) ODU3 link between OTN-Switches B & C supports TS Granularity
of 2.5Gbps only. Hence, ODU0 switching on this link is possible
only through ODU3-ODU2-ODU0 or ODU3-ODU1-ODU0 multiplexing
hierarchies.
Khuzema, et al. Expires December 31, 2011 [Page 15]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
G.709 Traffic Parameters and Generalized Label for ODU0 LSP from
node A to D is captured below:
A. G.709 Traffic Parameters
Signal Type = ODU0
NMC/Tolerance = 0 // NMC is not used.
NVC = 0
Multiplier (MT) = 1
Bit_Rate = 0
Khuzema, et al. Expires December 31, 2011 [Page 16]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
B. Generalized Label Format:
+=============+==============+==============+==============+
| | A to B | B to C | C to D |
+=============+==============+==============+==============+
| # of Stages | 1 | 2 | 1 |
+-------------+--------------+--------------+--------------+
| Stage-1 | ODU2<--ODU0 | ODU3<--ODU2 | ODU2<--ODU0 |
| | TSG = 1.25G | TSG = 2.5G | TSG = 1.25G |
| | #TSs = 8 | #TSs = 16 | #TSs = 8 |
| | TPN = <1..8> | TPN = <1..4> | TPN = <1..8> |
| | BMap = 4bytes| BMap = 4bytes| BMap = 4bytes|
+-------------+--------------+--------------+--------------+
| Stage-2 | N/A | ODU2<--ODU0 | N/A |
| | | TSG = 1.25G | |
| | | #TSs = 8 | |
| | | TPN = <1..8> | |
| | | BMap = 4bytes| |
+-------------+--------------+--------------+--------------+
Example 2: ODUj LSP over ODUk H-LSP
Refer to Figure-3 in section 6. The G.709 Traffic Parameters and
Generalized Label for ODU1 LSP from Node A to E is captured below:
A. G.709 Traffic Parameters:
Signal Type = ODU1
NMC/Tolerance = 0 // NMC is not used.
NVC = 0
Multiplier (MT) = 1
Bit_Rate = 0
B. Generalized Label Format:
+=============+==============+==============+==============+
| | A to B | B to D | D to E |
+=============+==============+==============+==============+
| # of Stages | 1 | 2 | 1 |
+-------------+--------------+--------------+--------------+
| Stage-1 | ODU2<--ODU1 | ODU3<--ODU2 | ODU2<--ODU1 |
| | TSG = 1.25G | TSG = 2.5G | TSG = 1.25G |
| | #TSs = 8 | #TSs = 16 | #TSs = 8 |
| | TPN = <1..4> | TPN = <1..4> | TPN = <1..4> |
| | BMap = 4bytes| BMap = 4bytes| BMap = 4bytes|
+-------------+--------------+--------------+--------------+
| Stage-2 | N/A | ODU2<--ODU1 | N/A |
| | | TSG = 1.25G | |
| | | #TSs = 8 | |
| | | TPN = <1..4> | |
| | | BMap = 4bytes| |
+-------------+--------------+--------------+--------------+
Khuzema, et al. Expires December 31, 2011 [Page 17]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
11. Security Considerations
There are no additional security implications to Signaling
protocol due to the extensions captured in this document.
12. IANA Considerations
TBD
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels".
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
MPLS Traffic Engineering (TE)"
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)"
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
[RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of
Existing GMPLS Protocols against Multi-Layer and
Multi-Region Networks (MLN/MRN)", RFC 5339, September
2008.
[VCAT-LCAS] G. Bernstein (ed.), D. Caviglia, R. Rabbat and H. van
Helvoort, "Operating Virtual Concatenation (VCAT) and
the Link Capacity Adjustment Scheme (LCAS) with
Generalized Multi-Protocol Label Switching (GMPLS)",
draft-bernstein-ccamp-gmpls-vcat-lcas-11.txt,
March 09, 2011
Khuzema, et al. Expires December 31, 2011 [Page 18]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
[G.709-v3] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709 Recommendation, December 2009.
13.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[G.709-v1] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation (and Amendment 1), February
2001 (October 2001).
[G.872] ITU-T, "Architecture of optical transport networks",
November 2001 (11 2001).
[G.709-FRAME] F. Zhang, D. Li, H. Li, S. Belotti, "Framework for
GMPLS and PCE Control of G.709 Optical Transport
Networks", draft-zhang-ccamp-gmpls-g709-framework-02,
work in progress.
[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.
[OSPF-EXTN-FOR-OTN] S. Bardalai, R. Rao, A. Kunjidhapatham,
K. Pithewan, "OSPF TE Extensions for GMPLS
Control of G.709 Optical Transport Networks",
draft-ashok-ccamp-gmpls-ospf-g709-02,
work in progress.
14. Acknowledgements
Authors would like to thank Lou Berger, Steve Balls and Radhakrishna
Valiveti for review comments and suggestions.
Author's Addresses
Khuzema Pithewan
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089, USA
Email: kpithewan@infinera.com
Mohit Misra
Infinera Corporation
169, Java Drive
Khuzema, et al. Expires December 31, 2011 [Page 19]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
Sunnyvale, CA-94089, USA
Email: mmisra@infinera.com
Rajan Rao
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089, USA
Email: rrao@infinera.com
Ashok Kunjidhapatham
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089, USA
Email: akunjidhapatham@infinera.com
Biao Lu
Infinera Corporation
169, Java Drive
Sunnyvale, CA-94089, USA
Email: blu@infinera.com
Lyndon Ong
Ciena
10480 Ridgeview Court
Cupertino, CA 95014, USA
EMail: lyong@ciena.com
Igor Bryskin
Adva Optical
EMail: IBryskin@advaoptical.com
Appendix A: Abbreviations & Terminology
A.1 Abbreviations:
CBR Constant Bit Rate
GFP Generic Framing Procedure
HO-ODU Higher Order ODU
LSC Lambda Switch Capable
LSP Label Switched Path
LO-ODU Lower Order ODU
ISCD Interface Switch Capability Descriptor
OCC Optical Channel Carrier
Khuzema, et al. Expires December 31, 2011 [Page 20]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
OCG Optical Carrier Group
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
ODTUG Optical Date Tributary Unit Group
ODU Optical Channel Data Unit
OMS Optical Multiplex Section
OMU Optical Multiplex Unit
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OSC Optical Supervisory Channel
OTH Optical Transport Hierarchy
OTM Optical Transport Module
OTN Optical Transport Network
OTS Optical Transmission Section
OTU Optical Channel Transport Unit
OTUkV Functionally Standardized OTUk
SCSI Switch Capability Specific Information
TDM Time Division Multiplex
TPN Tributary Port Number
TS Tributary Slot or Time Slot
A.2 Terminology
1. ODUk and ODUj
ODUk refers to the ODU container that is directly mapped to an OTU
container. ODUj refers to the lower order ODU container that is
mapped to an higher order ODU container via multiplexing.
2. LO-ODU and HO-ODU
LO-ODU refers to the ODU client layer of lower rate that is mapped to
an ODU server layer of higher rate via multiplexing. HO-ODU refers to
the ODU server layer of higher rate that supports mapping of one or
more ODU client layers of lower rate.
In multi-stage multiplexing case, a given ODU layer can be a client
for one stage (interpreted as LO-ODU) and at the same time server for
another stage (interpreted as HO-ODU). In this case, the notion of
LO-ODU and HO-ODU needs to be interpreted in a recursive manner.
Khuzema, et al. Expires December 31, 2011 [Page 21]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
ODU3 | (HO-ODU)
^ |
| | Stage #1
| |
(HO-ODU) | ODU2 | (LO-ODU)
| ^
Stage #2 | |
| |
(LO-ODU) | ODU1 | (HO-ODU)
^ |
| | Stage #3
| |
ODU0 | (LO-ODU)
Figure-6 : LO-ODU and HO-ODU
3. Single Stage Multiplexing When ODU multiplexing hierarchy involves
only two levels (ODUk and ODUj), it is referred as single stage
multiplexing.
ODU3 | Level-1
^ |
| |
| |
ODU1 | Level-2
Figure-7: Single Stage Multiplexing
4. Multi Stage Multiplexing When ODU multiplexing hierarchy involves
more than two levels, it is referred as multi-stage multiplexing. Two
adjoining levels form a multiplexing stage.
ODU3 | Level-1
^ |
| | Stage #1
| |
Level-2 | ODU2 | Level-2
| ^
Stage #2 | |
| |
Level-3 | ODU1 | Level-3
^ |
| | Stage #3
| |
ODU0 | Level-4
Figure-8 : Multi Stage Multiplexing
Khuzema, et al. Expires December 31, 2011 [Page 22]
Internet-Draft draft-khuzema-ccamp-gmpls-sig-g709-02.txt June 29, 2011
Appendix B : RFC4328 and G.709v3
B.1 G.709 Traffic Parameters
The G.709 Traffic Parameters defined in [RFC4328] does not work well
for the new features introduced in [G.709-v3]. The basic draw-backs
are:
(a) NMC attribute defined in G.709 Traffic Parameters does not apply
end-to-end especially when links with different TSG are involved in
the path of a LSP.
(b) ODUflex needs absolute nominal rate and tolerance to be
specified.
B.2 Label Format
The Label format defined in [RFC4328] is not scalable/extensible to
cover the new ODU rates defined in [G.709-v3]. Some of the
limitations are captured below:
(a) The bit-fields defined to represent TSs for specific ODU rates
are not future proof. The reserved bits are not sufficient to cover
the future ODU types.
(b) The label format assumes 2.5G Tributary Slot Granularity. It
needs to be redefined for 1.25G Tributary Slot Granularity.
(c) One Tributary Slot information is coded in 4 bytes. ODU3 and ODU4
requires 32 and 80 TSs respectively. This would dramatically increase
the label size and thus impact the scalability.
Khuzema, et al. Expires December 31, 2011 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 09:11:07 |