CCAMP WG, IETF 75th, Stockholm, Sweden draft-zhang-ccamp-gmpls-evolving-g txt Fatai Zhang Guoying GMPLS Extensions for the Evolving G.709 OTN Control

Motivations RFC4328 describes the control technology for OTN as specified in the ITU-T G.709 Recommendation (Amd1) With the evolution of OTN, there are some new features introduced in ITU-T –ODU0, ODU2e, ODU4 are described in [G709-Amd3] –One new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) is described in [G709-Amd3] –ODU3e1, ODU3e2 are described in [Gsup43] –ODUflex is being developed in [G709draft-v3] RFC4328 does not support these new features Objective: to extend GMPLS signaling to support the new features of OTN

New Features of OTN (1) New Optical Channel Transport Unit (OTUk): –OTU4 –OTU2e –OTU3e1 –OTU3e2 New Optical Channel Data Unit (ODUk): –ODU0 –ODU2e –ODU3e1 –ODU3e2 –ODU4 –ODUflex New Tributary Slot (TS) granularity: 1.25 Gbps

New Features of OTN (2) For the evolving OTN, the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k > j) signal is as follows: –ODU0 into ODU1 multiplexing –ODU0, ODU1, ODUflex into ODU2 multiplexing (1.25Gbps TS) –ODU1 into ODU2 multiplexing (2.5Gbps TS) –ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (1.25Gbps TS) –ODU1, ODU2 into ODU3 multiplexing (2.5Gbps TS) –ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing (1.25Gbps TS) –ODU2e into ODU3e1 multiplexing (2.5Gbps TS) –ODU2e into ODU3e2 multiplexing (1.25Gbps TS)

Extensions to the Traffic Parameters | Signal Type | Reserved | NMC | | NVC | Multiplier (MT) | | Reserved | Value Type 0 Not significant 1 ODU1 (i.e., 2.5 Gbps) 2 ODU2 (i.e., 10 Gbps) 3 ODU3 (i.e., 40 Gbps) 4 ODU4 (i.e., 100 Gbps) 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 Value Type 10~19 Reserved (for future use) 20 ODU0 (i.e., 1.25 Gbps) 21~30 Reserved (for future use) 31 ODU2e 32 ODU3e1 33 ODU3e2 34 ODUflex 35~255 Reserved (for future use)

Redefinition to the ODUk Label The ODUk label defined in RFC4328 does not support the new features of OTN The ODUk label extended like RFC4328 (call it the post-RFC4328 label) has some difficulties for efficiency and extensibility –When ODU3 multiplexing into ODU4 with 1.25G tributary slots, it will need 32 labels (32*4*8=1024 bits) –When ODUflex multiplexing into ODU4, it may need 80 labels (80*4*8=2560 bits)! –It is difficult to be extensible Our purpose: –To define a new ODUk label that is extensible, efficient and understandable –Backward compatibility is discussed later

New ODUk Label Format | ODUj |OD(T)Uk| T | Reserved | Bit Map | | | ODUj & OD(T)Uk: Integer values of j and k indicate that ODUj is multiplexed into ODUk (k>j), or ODUj is mapped into OTUk (j=k) T (TS Type): indicates the granularity of the TS of OD(T)Uk –T=0 means the TS is 1.25G –T=1 means the TS is 2.5G –Other values reserved for future Bit Map: Indicates which TS in ODUk the ODUj will be multiplexed into –The ODUk & T determine the length of the Bit Map, i.e., the total number of TS of the ODUk

Examples (1) | | |0 1| Reserved | Padded Bits (0) | Example 1: ODU1 mapping into OTU1 ODU1OTU1 The label indicates an ODU1 mapped into OTU1 with 2.5Gbps TS granularity. 2.5G

Examples (2) Example 2: ODU1 multiplexing into OTU2 (with 1.25G TS) | | |0 0| Reserved | |Padded Bits (0)| ODU1 ODU21.25GODU1 multiplexing into the 1st & 4th TS of ODU2 Node A Node B ODU1 ODU2

Open Discussions(1) Signal Type Do not need to differentiate ODU1,ODU2,ODU3 according to the different size of TS (i.e., 1.25G and 2.5G), Signal Type is a kind of basic property which should be non-modifiable We can differentiate TS through “TS Type” in the Label format (label can be switched and changed) NMC NMC can be determined automatically by the node itself (i.e., the number of NMC is equal to the size of the bitmap; e.g., it needs 4 labels when ODU2 is multiplexed into ODU3 with 2.5G TS) Suggest to remove NMC from the Traffic Parameters In this way, Traffic Parameters (including Signal Type and NMC) can not be changed along the connection

Open Discussions(2) Extensibility The label in this draft is very extensible and efficient. However, the post-RFC4328 label:  Needs up to 80 labels (2560 bits) when multiplexing ODUflex into ODU4  It is difficult for extensibility. (e.g., if there is ODUx introduced later, need another new label)

Open Discussions(3) Backward Compatibility The label in this draft and the post-RFC4328 label are both totally new labels which are different from the label in RFC4328 (although the post-RFC4328 label looks like RFC4328’s) How many implementations for RFC4328? If none, we really need an extensible and efficient label for the green-field (we absolutely don’t need two labels for the green- field) If there are a few implementations, backward compatibility should be considered The extensions in this draft can also coexist with RFC4328 (we don't need to upgrade the existing nodes, we can just do some translation or mapping in the new nodes, which means that the new nodes can be aware of both the new label and old label – the same as post-RFC4328 ).

Next Steps Refine it according to the feedback from the meeting or mailing list Add backward compatibility considerations if needed Discuss with authors of other OTN drafts and try to reach a single solution Comments are always appreciated