CCAMP WG, IETF 75th, Stockholm, Sweden

draft-zhang-ccamp-gmpls-evolving-g709-01.txt

Fatai Zhang (zhangfatai@huawei.com)

Guoying Zhang(zhangguoying@mail.ritt.com.cn)

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 Parameters0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Signal Type | Reserved | NMC |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| NVC | Multiplier (MT) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value Type

0 Not significant1 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 Gbps7 OCh at 10 Gbps8 OCh at 40 Gbps9 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 ODU2e32 ODU3e133 ODU3e234 ODUflex35~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 Format0 1 2 30 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 |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 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 0 1|0 0 0 1|0 1| Reserved | Padded Bits (0) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example 1: ODU1 mapping into OTU1

ODU1 OTU1

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 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|0 0 0 1|0 0 1 0|0 0| Reserved |1 0 0 1 0 0 0 0|Padded Bits (0)|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ODU1 ODU2 1.25G ODU1 multiplexing into the 1st & 4th TS of ODU2

Node A

Node B

ODU1 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