TOC 
Network Working GroupX. Fu
Internet-DraftM. Ke
Intended status: Standards TrackY. Bao
Expires: January 7, 2010ZTE Corporation
 July 06, 2009


Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Amendment3 and G.sup43 Optical Transport Networks Control
draft-fuxh-ccamp-gmpls-extension-for-evolutive-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 January 7, 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.

Abstract

This document updates the "draft-ke-ccamp-gmpls-odu0-00.txt". It describes the extensions of GMPLS signaling to control Optical Transport Networks (OTN) including ODU0, ODU1, ODU2, ODU2e, ODU3, ODU3e1, ODU3e2, ODU4 and ODUflex. It also covers the interworking of control plane between pre-G.709 controlling and G.709 Amendment3 controlling.



Table of Contents

1.  Introduction
    1.1.  Conventions Used in This Document
2.  GMPLS Extension for G.709 Amendment3 and G.sup43-Overview
3.  Generalized Label Request
    3.1.  Traffic Parameters
        3.1.1.  Signal Type (ST)
        3.1.2.  Number of Multiplexed Components (NMC)
4.  Backward Compatibility Considerations
5.  Generalized Label
    5.1.  Label Space
    5.2.  Label Distribution Rules
    5.3.  Calculation of Label Number for ODUflex
    5.4.  Example of Generalized Label
6.  Interworking Considerations
7.  Control of ODUflex resizing
8.  Contributors
9.  Security Considerations
10.  IANA Considerations
11.  Acknowledgments
12.  Normative References
§  Authors' Addresses




 TOC 

1.  Introduction

This document describes the extensions of GMPLS signaling to control Optical Transport Networks (OTN) including ODU0, ODU1, ODU2, ODU2e, ODU3, ODU3e1, ODU3e2, ODU4 and ODUflex. It also covers the interworking of control plane between pre-G.709 controlling and G.709 Amendment3 controlling. The control of ODUflex resizing is for further study.



 TOC 

1.1.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

2.  GMPLS Extension for G.709 Amendment3 and G.sup43-Overview

The concept of Lower Order (LO) ODUk and High Order (HO) ODUk in the G.709 Amendment3 multiplex hierarchy is introduced as same information structures but with different client signals. LO-ODUk can be considered as the service layer and the HO-ODUk can be considered as the Tunnel Layer. LO-ODUk can be multiplexed into the HO-ODUk or can be mapped directly to OTUk layer.

The LO-ODUk into HO-ODUk multiplexing and OCh into OMSn multiplexing provide a two stage multiplexing capability. ODU0 are to be transported over ODUk (k=1,2,3,4) and ODU2e are to be transported over ODUk ( k=3,3e1,3e2,4).

The ability to accommodate any client bit rate into a variable bit rate LO-ODU and map into any number of Tributary Slots of HO-ODU i.e. being agnostic to the service bit rate and provide flexibility to the mapping process creates a future proof multi service OTN evolution. ODUflex is a LO-ODU that enhances bit transparent transport over OTN. It can be of any rate of ODU0 rate or higher and has a generic capacity.

GMPLS signaling extensions for pre-G.709 has been described in [RFC4328]. It extended the Generalized Label Request, the Generalized Label and Traffic Parameter. This document give more extension for the G.709 Amendment3 and G.sup43. It covers the Generalized Label, Traffic Parameters. It also give some consideration about the interworking of control plane between pre-G.709 controlling and G.709 Amendment3 controlling.

To support the application of ODU0, ODU1, ODU2, ODU2e, ODU3, ODU3e1, ODU3e2 and ODU4, the extensions based on [RFC4328] are needed. The first extension defines signal Type of these ODUk in G.709 Traffic Parameters. The second extension provides the compatible definition of ODUk Label.

ODUflex should be more further study in the future (e.g., Control of ODUflex resizing).



 TOC 

3.  Generalized Label Request

[RFC4328] extends the LSP Encoding Type, the Switching Type, and G-PID (Generalized-PID) values to accommodate G.709 Recommendation [ITUT-G.709]. Signaling of ODU0, ODU1, ODU2e, ODU4, ODUflex, ODU3e1 and ODU3e2 LSP must comply with these extensions. Additional LSP Encoding Type code-point for the OTN Digital Path layer must be used for these new ODUk types LSP and their switching types belong to the TDM class.

G.709 Amendment3 clarifies that the layer stack of the OTN contains a Lover Order ODU layer in which each LO-ODU signal carries a customer service instance, and a Higher Order ODU layer in which each HO-ODU signal carries a multiplex of LO-ODU signals. But the Encoding Types of LO and HO layer are aslo G.709 ODUk (Digital Path) which is defined in [RFC4328].

When the client payload is transported over the Optical Channel layer, [RFC4328] defines the Generalized-PID with respect to the LSP Encoding Type for G.709 OTUk at 2.5, 10, 40 Gbps. This G-PID type should be extended to support the transport of Digital Section at 100G Gbps.



 TOC 

3.1.  Traffic Parameters

G.709 traffic parameters has been defined in [RFC4328]. The backwards compatibility must be considered. Backwards compatibility considerations for each feature will be covered in this document. The definition of Number of Virtual Components (NVC) and Multiplier (MT) is same as [RFC4328]



 TOC 

3.1.1.  Signal Type (ST)

Pre-G.709 defines the OPU2 and OPU3 with 2.5G tributary slots multiplex structure. G.709 Amendment3 defines the OPU1, OPU2, OPU3, OPU4 with 1.25G tributary slots multiplex structure. G.sup43 defines the OPU3e1 with 2.5G tributary slots multiplex structure and OPU3e2 with 1.25G tributary slots multiplex structure.

Following is the Signal Type extended for G.709 Amendment3 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. Other new Signal Types are extended for G.709 Amendment3 and G.sup43.


Value  Type
-----  ----
0      Not significant
1      ODU1 (i.e., 2.5 Gbps)
2      ODU2 (i.e., 10  Gbps) /*The size of OPU2 TS is 2.5G*/
3      ODU3 (i.e., 40  Gbps) /*The size of OPU3 TS is 2.5G*/
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     ODU1    /*The size of OPU1 TS is 1.25G*/
12     ODU2    /*The size of OPU2 TS is 1.25G*/
13     ODU3    /*The size of OPU3 TS is 1.25G*/
14     ODU4    /*The size of OPU4 TS is 1.25G*/
15     ODU2e   /*10Gbps for FC1200 and GE LAN */
16     ODU3e1  /*The size of OPU3e1 TS is 2.5G */
17     ODU3e2  /*The size of OPU3e2 TS is 1.25G */
18     ODUflex /*The size of OPU2/OPU3/OPU4 TS is 1.25G */
19     ODUflex /*The size of OPU2/OPU3 TS is 2.5G */
20-255 Reserved (for future use)


 TOC 

3.1.2.  Number of Multiplexed Components (NMC)

The NMC values difined for G.709 Amendment3 and G.sup43 are as follows:

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.
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.
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 OPU3e2.
8    ODU2e is mapped into 1.25G tributary slots of OPU4.
32   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.

1    ODU1 is mapped into 2.5G tributary slots of OPU2.
1    ODU1 is mapped into 2.5G tributary slots of OPU3.
4    ODU2 is mapped into 2.5G tributary slots of OPU3.
5    ODU2e is mapped into 2.5G tributary slots of OPU3.
4    ODU2e is mapped into 2.5G tributary slots of OPU3e1.
1-4  ODUflex is mapped into 2.5G tributary slots of OPU2.
1-16 ODUflex is mapped into 2.5G tributary slots of OPU3.


 TOC 

4.  Backward Compatibility Considerations

Equipment supporting a 1.25G TS structure for OPU2 or OPU3 must be backward compatible with equipment which supports only the 2.5G TS structure. Also, the extension defined in this document is backward compatible with [RFC4328] for ODU1, ODU2 and ODU3. So the extension defined in this document is a supplement and extension of [RFC4328].

In terms of G.709 Amendment3, a one-byte payload type signal is defined in the PSI[0] byte of the payload structure identifier to indicate the composition of the OPUk signal. The code points can differentiate whether the ODU multiplex structure supports 2.5G tributary slots or 1.25G tributary slots. Also, in order to be backward compatible with [RFC4328] for ODU1, ODU2 and ODU3, it needs the Signal Type charactering the ODU multiplex structure to differentiate the size of tributary slots and the Generalized Label format.

When a downstream (upstream)node receive Path (Resv) message in which Signal Type (i.e., ODU1, ODU2 or ODU3) characters ODU multiplex structure supporting 2.5G tributary slots, it must identifies the Generalized Label format based on [RFC4328].

When a downstream (upstream) node receive Path (Resv) message in which Signal Type (i.e., ODU1, ODU2 or ODU3) characters ODU multiplex structure supporting 1.25G tributary slots, it must identifies the Generalized Label format based on this document.

Following is a example of backward compatibility for ODU1, ODU2 and ODU3. For instance, we need to setup a ODU1 (2.5G bandwidth) LSP between node 1 and nodes 3. Node 2 must identify the Generalized Label format based on [RFC4328] after receiving the Path message. Node 2 must identify the Generalized Label format based on this document after receiving the Resv message. In other hand, node 3 must identify the Generalized Label format based on this document.





   +---+    OTU3 (16*2.5G)    +---+     OTU3(32*1.25G)   +---+
---| 1 |----------------------| 2 |----------------------| 3 |---
   +---+                      +---+                      +---+
        --------------------->     ---------------------->
      Path(Signal Type=1)          Path(Signal Type=11)

        <---------------------     <----------------------
      Resv(Signal type=1)          Resv(Signal type=11)



   +---+    OTU2 (4*2.5G)     +---+     OTU2(8*1.25G)    +---+
---| 1 |----------------------| 2 |----------------------| 3 |---
   +---+                      +---+                      +---+
        --------------------->     ---------------------->
      Path(Signal Type=1)          Path(Signal Type=11)

        <---------------------    <----------------------
      Resv(Signal type=1)          Resv(Signal type=11)


   +---+      OTU1 (2.5G)     +---+      OTU1(2*1.25G)   +---+
---| 1 |----------------------| 2 |----------------------| 3 |---
   +---+                      +---+                      +---+
        --------------------->     ---------------------->
      Path(Signal Type=1)          Path(Signal Type=11)

        <---------------------     <----------------------
      Resv(Signal type=1)          Resv(Signal type=11)
 Backward Compatibility Scenario 

Control plane designed for G.709 Amendment3 and G.sup43 should have the ability to synchronously process the different Generalized Label format of ODU2 and ODU3 defined in [RFC4328] and this document. The Generalized Label format is identified by the Signal Type in Traffic Parameters.

When a downstream node receive Path message in which Signal Type is ODU0, ODU2e, ODUflex, ODU4, ODU3e1 or ODU3e2, it must identifies the Generalized Label format based on this document.

If one node receives a Path message in which the Signal Type characters the ODU multiplex structure, it must check the local mapping capability. If it can not support this ODU multiplex structure, the Path message will be terminated, and a PathErr message with a "Traffic Control Error/Service unsupported" indication will be generated.



 TOC 

5.  Generalized Label



 TOC 

5.1.  Label Space

G.709 Amendment3 has been added many different client payload bit rates which are mainly based on Gigabit Ethernet. 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.2G Gbps which is sepecially introduced for GE client signal), 1 (for 2.5 Gbps CBR), 2 (for 10 Gbps including CBR and GE LAN), 2e (also for 10 Gbps which is sepecially introduced for FC1200 and GE LAN client signal), 3 (for 40 Gbps including CBR and GE) or 4 (for 100 Gbps which is sepecially introduced for GE client signal). ODU0 can be mapped into ODU1, ODU2, ODU3, ODU4. ODU1, ODU2 and ODU3 can be mapped into ODU4. ODU2e can be mapped into ODU3, ODU3e1, ODU3e2 and ODU4. ODU1 can be is mapped into 1.25G tributary slots of OPU2 and OPU3. ODU2 can be is mapped into 1.25G tributary slots of OPU3.

The ODUflex can be used for CBR clients and for packet clients. The existing G.709 mappings for CBR clients into ODU0, 1, 2, 3 will continue to be used. New ODUflex mappings will not be defined for these clients. The CBR ODUflex rate should be 239/238*client bit rate. The Packet ODUflex bit rate is based on an incremental number of tributary slots of the ODUk (k=2, 3, 4) expected to carry the ODUflex. The Packet ODUflex rate should be n*1.24416 Gbps+/-20ppm (1<=n<=80). CBR ODUflex and Packet ODUflex are transported by mapping into an integer number of TS of an OPUk (of a High Order ODUk) for k>1. There is no OTUflex.

Most Lower Order ODUk signals have the same number of tributary slots in all High Order ODUk(i.e. HO OPUk signals). There are however a few exceptions; the most well known is LO ODU2e (i.e. LO ODU 10.399G). ODU2e fits into 5*2.5G tributary slots of OPU3, 9*1.25G tributary slots of OPU3, or 8*1.25G tributary slots of OPU4.

Following is the ODUk label format for the G.709 Amendment3 and G.sup43.




 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 Amendment3 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, t4, t5 and t6 fields is defined as follows:

  1. t1 (2-bit):
  2. t2 (5-bit):
  3. t3 (8-bit):
  4. t4 (9-bit):



 TOC 

5.2.  Label Distribution Rules

It was noted that VCAT is only defined currently for ODU1, ODU2, and ODU3. The draft revision of G.709 Amendment3 will not define VCAT for ODU1, ODU2e and ODU4. So there is no any necessary extension for the new ODUk signal. The label distribution rules must be same as [RFC4328].



 TOC 

5.3.  Calculation of Label Number for ODUflex

For an ODUflex that is based on transport of a particular physical layer client (e.g., ODU2e) the size of the ODUflex depends on that client. In general, it is a bit-synchronous mapping of the client with the ODUflex bit-rate being 239/238 times the bit-rate of the client. for this type of ODUflex, the number of tributary slots is chosen to fit.

For example, ODU2e fits into 5*2.5G tributary slots of OPU3 (i.e., Five labels need to be allocated for one ODUflex connection when ODUflex is mapped into 2.5G tributary slots of ODU3), 9*1.25G tributary slots of OPU3 (i.e., Nine labels need to be allocated for one ODUflex connection when ODUflex is mapped into 1.25G tributary slots of OPU3), or 8*1.25G tributary slots of OPU4 (i.e., Eight labels need to be allocated for one ODUflex connection when ODUflex is mapped into 1.25G tributary slots of OPU4).

For an ODUflex to provide flexibly sized trunks for packet transport, the granularity is selected to provide a reasonably efficient mapping into tributary slots of high order OPU2, OPU3, and OPU4. A good choice here seems to be to allow these trunks to be provisioned in sizes of n*1.24416G+/-20ppm (1<=n<=80). The number of labels is from 1 to 80.



 TOC 

5.4.  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 label, which can be, for instance, one of the following:
        - Signal type=14, t4=1, t3=0, t2=0, t1=0;
          indicates a single ODU4 mapped into an OTU4
    
        - Signal type=15, 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 = 10 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=2;
          indicates the ODU0 in the 1st TS of the ODTUG1
    
        - t4=0, t3=0, t2=5, t1=0;
          indicates the ODU0 in the 4th TS of the ODTUG2
    
        - t4=0, t3=27, 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 = 11 and NMC = 2), the downstream node has to return two ODU1 labels, which can take, for instance, the following values:
        - t4=0, t3=0, t2=14, t1=0;
          indicates the ODU1 in the 5th 1.25G TS of the ODTUG2
    
          or
    
        - t4=0, t3=59, t2=0, t1=0;
          indicates the ODU1 in the 26th 1.25G TS of the ODTUG3
    
          or
    
        - t4=83, 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 = 12 and NMC = 8), the downstream node has to return eight ODU2 labels, which can take, for instance, the following values:
        - t4=0, t3=68, t2=0, t1=0;
          indicates the ODU1 in the 3rd 1.25G TS of the ODTUG3
    
        - t4=0, t3=74, t2=0, t1=0;
          indicates the ODU1 in the 9th 1.25G TS of the ODTUG3
    
        - t4=0, t3=83, t2=0, t1=0;
          indicates the ODU1 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 = 12 and NMC = 8 or Signal Type = 15 and NMC = 8), the downstream node has to return eight ODU2 (or ODU2e) labels, one of which can take, for instance, the following values:
        - Signal type=12, t4=183, t3=0, t2=0, t1=0;
          indicates the ODU2 in the 21st TS of the ODTUG4
    
        - Signal type=15, t4=321, 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 = 13 and NMC = 32), the downstream node has to return thirty-two ODU3 labels, one of which can take, for instance, the following values:
        - t4=409, t3=0, t2=0, t1=0;
          indicates the ODU3 in the 7th TS of the ODTUG4
    
        - t4=450, t3=0, t2=0, t1=0;
          indicates the ODU3 in the 48th TS of the ODTUG4
    
        - t4=473, 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 = 15 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=101, t2=0, t1=0;
          indicates the ODU2e in the 4th 1.25G TS of the ODTUG3
    
        - t4=0, t3=113, t2=0, t1=0;
          indicates the ODU2e in the 16th 1.25G TS of the ODTUG3
    
        - t4=0, t3=121, t2=0, t1=0;
          indicates the ODU2e in the 24th 1.25G TS of the ODTUG3
    
  8. 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 = 15 and NMC = 4), the downstream node has to return four ODU2e labels, which can take, for instance, the following values:
        - t4=0, t3=162, t2=0, t1=0;
          indicates the ODU2e in the 1st TS of the ODTUG3e1
    
        - t4=0, t3=167, t2=0, t1=0;
          indicates the ODU2e in the 6th TS of the ODTUG3e1
    
        - t4=0, t3=171, t2=0, t1=0;
          indicates the ODU2e in the 10th TS of the ODTUG3e1
    
        - t4=0, t3=176, t2=0, t1=0;
          indicates the ODU2e in the 15th TS of the ODTUG3e1
    
  9. 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 = 15 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=182, t2=0, t1=0;
          indicates the ODU2e in the 5th TS of the ODTUG3e2
    
        - t4=0, t3=198, t2=0, t1=0;
          indicates the ODU2e in the 21st TS of the ODTUG3e2
    
        - t4=0, t3=208, t2=0, t1=0;
          indicates the ODU2e in the 31st TS of the ODTUG3e2
    
  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 = 18), 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=22, t1=0;
          indicates the ODUflex in the 5th 1.25G TS of the ODTUG2
    
          or
    
        - t4=0, t3=151, t2=0, t1=0;
          indicates the ODUflex in the 22nd 1.25G TS of the ODTUG3
    
          or
    
        - t4=369, t3=0, t2=0, t1=0;
          indicates the ODUflex in the 47th 1.25G TS of the ODTUG4
    
  11. ODUflex is mapped into 2.5G tributary slots of OPU2 (or OPU3). when one ODUflex is multiplexed into the payload of a structured ODU2 (or ODU3), 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 valuce. Because the ODUflex is multiplexed into one ODTUG2 (or ODTUG3). The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or OPU3) and then mapped into the corresponding OTU2 (or OTU3). Because a single ODUflex multiplexed signal is requested (Signal Type = 19), 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=27, t1=0;
          indicates the ODUflex in the 2nd 2.5G TS of the ODTUG2
    
          or
    
        - t4=0, t3=215, t2=0, t1=0;
          indicates the ODUflex in the 12nd 2.5G TS of the ODTUG3
    



 TOC 

6.  Interworking Considerations

Equipment supporting a 1.25G TS structure for OPU2 or OPU3 must be backward compatible with equipment which supports only the 2.5G TS structure. There must be some considerations on interworking between pre-G.709 and new OTN equipment. Following figure is a interworking example between pre-G.709 and G.709 Amendment3.



      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 pre-G.709 and G.709 Amendment3 

Interworking can probably be accomplished by requiring the new equipment to support the pre-G.709 payload mappings onto link that are attached to another equipment. One approach that may satisfy this is to represent the capacity of a link in terms of the number of timeslots and the time slot bandwidth. This can be reflected in the Interface Switching Capability Descriptor. In the this scenario, node DXC2, DXC4 and DXC5 should have the interworking capability.

With the introduction of many new Lower Order ODU bit rates, TE links should be represented by means of either their bandwidth or their number of tributary slots, the bandwidth per tributary slot and the set of client ODU signals supported. Traffic Engineering Database (TED) should be compose of the following TE link for this scenario.


               Max LSP Bandwidth  Minimum LSP Bandwidth
OTU2(DXC1-DXC2)     ODU2 (10G)       ODU1 (2.5G)
OTU2(DXC5-DXC6)     ODU2 (10G)       ODU0 (1.25G)
OTU3(DXC2-DXC3)     ODU3 (40G)       ODU1 (1.25G)
OTU3(DXC4-DXC5)     ODU3 (40G)       ODU1 (2.5G)
OTU4(DXC3-DXC4)     ODU4 (100G)      ODU0 (1.25G)

When we need to setup a ODU1 (2.5G) LSP between DXC1 node and DXC6 nodes, the path computation entiy may computate an DXC1-DXC2-DXC3-DXC4-DXC5-DXC6 route by the ODU1 bandwidth request in an G.709 network.

  1. In the case of one end-to-end session, the setup of a end-to-end connection must be based on the section "Backward Compatibility Considerations" in this document. The Traffic Parameters have to be changed in DXC2, DXC4, and DXC5 node.

     +----+      +----+      +----+      +----+       +----+       +----+
    -|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|-------|DXC6|-
     +----+      +----+      +----+      +----+       +----+       +----+
            Path        Path        Path         Path         Path
          ------->     ------>     ------>     ------->     ------->
            ST=1        ST=11       ST=11       ST=1         ST=11
           NMC=1       NMC=2       NMC=2       NMC=1        NMC=2
    
            Resv        Resv        Resv         Resv         Resv
          <-------     <------     <------     <-------     <-------
            ST=1        ST=11       ST=11       ST=1         ST=11
           NMC=1       NMC=2       NMC=2       NMC=1        NMC=2
    
     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 

    Druing setup of each segment lsp, tributary slot size should be known to control plane. One approach that may satisfy this is based on the Signal Type in Traffic Parameters. Signal Type and NMC in each segment LSP don't need to be changed any more. Following is the value of Signal Type for different segment LSP.
    
               Value     Type
    ODU1 LSP1  1         ODU1 (i.e., 2.5 Gbps is not further sub-divided)
    ODU1 LSP2  11        ODU1 /*The size of OPUk TS is 1.25G*/
    ODU1 LSP3  1         ODU1 (i.e., 2.5 Gbps is not further sub-divided)
    ODU1 LSP4  11        ODU1 /*The size of OPUk TS is 1.25G*/
    
    editor note: 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 traffic parameters of this end-to-end session is TBD.



 TOC 

7.  Control of ODUflex resizing

TBD



 TOC 

8.  Contributors



 TOC 

9.  Security Considerations

TBD.



 TOC 

10.  IANA Considerations

TBD.



 TOC 

11.  Acknowledgments

The RFC text was produced using Marshall Rose's xml2rfc tool.



 TOC 

12. 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 (TXT, HTML, XML).
[RFC3630] Katz, D., Kompella, K., and D. Yeung, “Traffic Engineering (TE) Extensions to OSPF Version 2,” RFC 3630, September 2003 (TXT).
[RFC4203] Kompella, K. and Y. Rekhter, “OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS),” RFC 4203, October 2005 (TXT).
[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 (TXT).
[RFC4328] Papadimitriou, D., “Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control,” RFC 4328, January 2006 (TXT).
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, “Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE),” RFC 5150, February 2008 (TXT).


 TOC 

Authors' Addresses

  Xihua Fu
  ZTE Corporation
  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/
  
  Ming Ke
  ZTE Corporation
  3F,R&D Building 3,ZTE Industrial Park,XiLi LiuXian Road
  Nanshan District,Shenzhen 518055
  P.R.China
Phone:  +86 755 26773914
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
Phone:  +86 755 26773731
Email:  bao.yuanlin@zte.com.cn