Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Amendment3 Optical Transport Networks Control
draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-00

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 December 28, 2009.

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 describe the interworking between pre-G.709 and G.709 Amendment3.

Table of Contents

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

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 describe the interworking between pre-G.709 and G.709 Amendment3. The control of ODUflex resizing is for further study.

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.).

2.  GMPLS Extension for G.709 Amendment3-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 High Order ODU signals of a carrier can also be transported over Low Order links provided in a carrier-carrier network domain. This external HO-ODUk can be multiplexed together with the equivalent LO-ODUk into the HO-ODUk tunnel 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 extensional for the G.709 Amendment3. It also covers the Generalized Label, Traffic Parameters. It also give some consideration about the interworking between pre-G.709 and G.709 Amendment3.

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

[RFC4328] extends GMPLS to support G.709 Optical Transport Networks Control. 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.

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 G.709 Digital Path layer must be used in these new ODUk types LSP and their switching types belong to the TDM class.

3.1.  Extension of Traffic Parameters for G.709 Amendment3

G.709 traffic parameters has been defined in rfc4328. The backwards compatibility must be considered. Backwards compatibility considerations for each feature is covered in this section.

This document extends this Traffic Parameters including adding one bit for the different G.709 version.

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  |V|  Reserved   |              NMC              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              NVC              |        Multiplier (MT)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V (G.709 Version): 1 bit

  0 - In the case of a pre-G.709 implementation, it must set to
      zero in every Path and Resv message.

  1 - In the case of a G.709 Amendment3 implementation, it must be
      set to 1 in every Path and Resv message.

3.1.1.  Signal Type Extension

Signal Type is extended for G.709 Amendment3 as follow:

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
19-255 Reserved (for future use)

4.  Backward Compatibility Considerations

If one G.709 Amendment3 implementation node receives a Path message from pre-G.709 implementation node with V bit set to zero in Traffic Parameters, it must check the local mapping capability. if it can not support the pre-G.709 payload mapping into the link that are attached to the G.709 Amentment3 equipment or pre-G.709 equipment, the Path message will be terminated, and a PathErr message with a "Traffic Control Error/Service unsupported" indication will be generated. There are several interworking scenarios as following:

1. If the one G.709 Amendment3 implementation node receives a Path message with V bit set to zero in Traffic Parameters and it can support the pre-G.709 payload mapping into the link that are attached to the G.709 Amentment3 equipment, it should generated a path message with V bit set to 1.

    +-----+            +-----+             +-----+
----| old |------------| new |-------------| new |----
    +-----+            +-----+             +-----+
           ----------->       ----------->
            Path(V=0)          Path(V=1)

2. If one G.709 Amendment3 implementation node receives a Path message from pre-G.709 implementation node with V bit set to zero in Traffic Parameters and it can support the pre-G.709 payload mapping into the link that are attached to the pre-G.709 equipment, it should generated a path message with V bit set to zero.

    +-----+            +-----+             +-----+
----| old |------------| new |-------------| old |----
    +-----+            +-----+             +-----+
           ----------->       ----------->
            Path(V=0)          Path(V=0)

3. When a upstream node implemented with G.709 Amendment3 generates a path message to the donwstream node implemented with pre-G.709, V bit should be always set to zero. If the one pre-G.709 implementation node receives a Path message from G.709 Amendment3 implementation node with V bit set to 1 in Traffic Parameters and the Signal Type represents that the size of tributary slot in OPUk is 2.5G, it should generated a path message with V bit set to zero. Otherwise the Path message will be terminated, and a PathErr message with a "Traffic Control Error/Service unsupported" indication will be generated.

    +-----+            +-----+             +-----+
----| new |------------| old |-------------| old |----
    +-----+            +-----+             +-----+
           ----------->   |   ----------->
            Path(V=1)     |    Path(V=0)
                          |
                          |
                          |
                       +-----+
       |---------------| old |----------------|
       |               +-----+                |
       |                  |                   |
       |                  |                   |
       |                  |                   |
    +-----+            +-----+             +-----+
----| new |------------| old |-------------| new |----
    +-----+            +-----+             +-----+
       |   ----------->   |   ----------->    |
       |    Path(V=1)     |    Path(V=0)      |
       |                  |                   |
       |               +-----+                |
       |---------------| old |----------------
                       +-----+
                          |
                          |
                          |

5.  Generalized Label

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), 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.

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 (n should be between 1 and 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. Just as there is no OTU0 nor OTU2e in the next G.709 revision.

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

 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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):
   • t1=1 indicates an ODU1 signal that is not further sub-divided. It is same as the definition in rfc4328.
   • t1=[2..3] indicates the tributary slot (t1th-1) used by the ODU0 in an ODTUG1 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 indicates an ODU2 signal that is not further sub-divided. It is same as the definition in rfc4328.
   • t2=[2..5] indicates the tributary slot (t2th-1) used by the ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). It is same as the definition in rfc4328. ODU1 is mapped into 2.5G tributary slots of OPU2.
   • t2=[6..13] indicates the tributary slot (t2th-5) used by the ODU0 in an ODTUG2 mapped into an ODU2 (via OPU2). ODU0 is mapped into 1.25G tributary slots of OPU2.
   • t2=[14..21] indicates the tributary slot (t2th-13) used by the ODUflex in an ODTUG2 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. They may be continuous or non-continuous.
   • t2=[22..25] indicates the tributary slot (t2th-21) used by the ODUflex in an ODTUG2 mapped into an ODU2 (via OPU2). ODUflex is mapped into 2.5G tributary slots of OPU2. How many labels needs to be allocated for one ODUflex connection is based on transport of a particular physical layer client. They may be continuous or non-continuous.
   • t2 is not significant for the other ODUk signal types (i.e., t2 value MUST be set to 0 and ignored).
3. t3 (8-bit):
   • t3=1 indicates an ODU3 signal that is not further sub-divided. It is same as the definition in rfc4328.
   • t3=[2..17] indicates the tributary slot (t3th-1) used by the ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). It is same as the definition in rfc4328. ODU1 is mapped into 2.5G tributary slots of OPU3.
   • t3=[18..33] indicates the tributary slot (t3th-17) used by the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). It is same as the definition in rfc4328. ODU2 is mapped into 2.5G tributary slots of OPU3. Four labels need to be allocated for one ODU2 connection. They may be continuous or non-continuous.
   • t3=[34..65] indicates the tributary slot (t3th-33) used by the ODU0 in an ODTUG3 mapped into an ODU3 (via OPU3). ODU0 is mapped into 1.25G tributary slots of OPU3.
   • t3=[66..97] indicates the tributary slot (t3th-65) used by the ODU2e in an ODTUG3 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=[98..129] indicates the tributary slot (t3th-97) used by the ODUflex in an ODTUG3 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. They may be continuous or non-continuous.
   • t3=[130..145] indicates the tributary slot (t3th-129) used by the ODUflex in an ODTUG3 mapped into an ODU3 (via OPU3). ODUflex is mapped into 2.5G 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. They may be continuous or non-continuous.
   • t3=[146..161] indicates the tributary slot (t3th-145) used by the ODU2e in an ODTUG3 mapped into an ODU3 (via OPU3). ODU2e is mapped into 2.5G tributary slots of OPU3. Five labels need to be allocated for one ODU2e connection. They may be continuous or non-continuous.
     
     The option of mapping clients into 2.5G tributary slots of ODU3 using GMP would be removed from consideration and from the draft revised G.709 (resulting in the mapping for ODU2e into five 2.5G tributary slots would not be supported in favour of using GMP mapping into nine 1.25G tributary slots). So this label definition may be removed in the future.
   • t3=[162..177] indicates the tributary slot (t5th-161) used by the ODU2e in an ODTUG3e1 mapped into an ODU3e1 (via OPU3e1). ODU2e is mapped into 2.5G tributary slots of OPU3e1. Four labels need to be allocated for one ODU3e1 connection. They may be continuous or non-continuous.
     
     The mapping of ODU2e into four 2.5G tributary slots is defined in the non normative G.sup43. Two pre-G.sup43 network elements which will be interworked should be based on G.sup43.
   • t3=[178..209] indicates the tributary slot (t5th-177) used by the ODU2e in an ODTUG3e2 mapped into an ODU3e2 (via OPU3e2). ODU2e is mapped into 1.25G tributary slots of OPU3e2. Eight labels need to be allocated for one ODU3e2 connection. The mapping of ODU2e into eight 1.25G tributary slots is defined in the non normative G.sup43. Two pre-G.sup43 network elements which will be interworked should be based on G.sup43.
   • t3=210 indicates an ODU2e sinal that is not further sub-divided. The mapping of ODU2e into OTU2e is defined in the non normative G.sup43.
   • 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 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 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 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). ODUflex 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 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. They may be continuous or non-continuous.
   • t4=[402..481] indicates the tributary slot (t4th-401) used by the ODU3 in an ODTUG4 mapped into an ODU4 (via OPU4). ODU3 is mapped into 1.25G tributary slots of OPU4. Tirty-two labels need to be allocated for one ODU3 connection. They may be continuous or non-continuous.
   • t4 is not significant for the other ODUk signal types (i.e., t4 value MUST be set to 0 and ignored).

5.2.  Label Distribution Rules

The label distribution rules must be same as rfc4328. But 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. ODUflex was expected to support clients with new bit rates that do not fit efficiently into ODU2, ODU3, or ODU4. It was also noted that VCAT supports client signals that require more than the capacity supported on a single wavelength, which is not supported using ODUflex.

5.3.  Calculation of Tributary Slot 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. Due to the fixed stuff columns, the bit-rate of the ODU2e is 239/237 times the bit-rate of the 10GBASE-R 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.

5.4.  Example of Generalized Label

TBD

6.  G.709 Amendment3 Interworking with pre-G.709

There must be some considerations on interworking between current and new OTN equipment. Following figure is a interworking example between pre-G.709 and G.709 Amendment3.

      4*2.5G TS   16*2.5G TS  80*1.25G TS  16*2.5G TS   8*1.25G TS
         |            |           |           |            |
         |            |           |           |            |
        \|/          \|/         \|/         \|/          \|/
 +----+ OTU2 +----+ OTU3 +----+ OTU4 +----+ OTU3  +----+  OTU2  +----+
-|DXC1|------|DXC2|------|DXC3|------|DXC4|-------|DXC5|--------|DXC6|-
 +----+      +----+      +----+      +----+       +----+        +----+
  |                       |             |             |             |
  |<------ODU1 LSP1------>|<-ODU1 LSP2->|<-ODU1 LSP3->|<-ODU1 LSP4->|

Interworking can probably be accomplished by requiring the new equipment to support the current payload mappings onto link that are attached to current 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 DXC3, DXC4 and DXC5 should have the interworking capability.

With the introduction of many new LO 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. TED should be compose of the following TE link in 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 (2.5G)
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 ODU2e bandwidth in an G.709 network.

In the case of a contiguous TE LSP, the setup of a end-to-end connection must be based on the section "Backward Compatibility Considerations" in this document.

The end-to-end connection also can be setuped with Stitching LSP technology. This end-to-end connection is stitched to several segment LSPs (i.e., ODU1 LSP1, ODU1 LSP2, ODU1 LSP3, ODU1 LSP4). The segment lsp is created and prepaired for stitching by signaling. 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. 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  12        ODU1 /*The size of OPU4 TS is 1.25G*/
ODU1 LSP3  1         ODU1 (i.e., 2.5 Gbps is not further sub-divided)
ODU1 LSP2  12        ODU1 /*The size of OPU2 TS is 1.25G*/

7.  Control of ODUflex resizing

TBD

8.  Security Considerations

TBD.

9.  IANA Considerations

TBD.

10.  Acknowledgments

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

11. Normative References

Authors' Addresses