GMPLS Signaling Extensions for Evolutive OTNs control draftfuxhccampgmplsextensionforevolutiveotn03

GMPLS Signaling Extensions for Evolutive OTNs control draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-03. txt Xihua Fu Ming Ke Yuanlin Bao ZTE Corporation Page - 1 IETF 76, Hiroshima, November 8 -13, 2009

Changes from 00. txt • Signal Type is only extended for ODU 0, ODU 2 e, ODUflex and ODU 4. • NMC is redefined in terms of the current G. 709 Amendment 3. • Interworking between RFC 4328 and new extension could be an automatic adaptation. Page - 2 IETF 76, Hiroshima, November 8 -13, 2009

Extension of Signal Type Value Type ----- ---0 Not significant 1 ODU 1 (i. e. , 2. 5 Gbps) 2 ODU 2 (i. e. , 10 Gbps) 3 ODU 3 (i. e. , 40 Gbps) 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 ODU 0 11 ODU 2 e 12 ODUflex 13 ODU 4 14 -255 Reserved (for future use) Page - 3 IETF 76, Hiroshima, November 8 -13, 2009

Extension of NMC Description ----------1 ODU 0 is mapped into 1. 25 G tributary slots of OPU 1. 1 ODU 0 is mapped into 1. 25 G tributary slots of OPU 2. 1 ODU 0 is mapped into 1. 25 G tributary slots of OPU 3. 1 ODU 0 is mapped into 1. 25 G tributary slots of OPU 4. 1 1 2 2 2 ODU 1 is mapped into 2. 5 G tributary slots of OPU 2. ODU 1 is mapped into 2. 5 G tributary slots of OPU 3. ODU 1 is mapped into 1. 25 G tributary slots of OPU 2. ODU 1 is mapped into 1. 25 G tributary slots of OPU 3. ODU 1 is mapped into 1. 25 G tributary slots of OPU 4. 4 8 8 ODU 2 is mapped into 2. 5 G tributary slots of OPU 3. ODU 2 is mapped into 1. 25 G tributary slots of OPU 4. 9 8 8 4 ODU 2 e is mapped into 1. 25 G tributary slots of OPU 3. ODU 2 e is mapped into 1. 25 G tributary slots of OPU 4. ODU 2 e is mapped into 1. 25 G tributary slots of OPU 3 e 2. [Non Normative] ODU 2 e is mapped into 2. 5 G tributary slots of OPU 3 e 1. [Non Normative] 31 ODU 3 is mapped into 1. 25 G tributary slots of OPU 4. 1 -8 ODUflex is mapped into 1. 25 G tributary slots of OPU 2. 1 -32 ODUflex is mapped into 1. 25 G tributary slots of OPU 3. 1 -80 ODUflex is mapped into 1. 25 G tributary slots of OPU 4. Page - 4 IETF 76, Hiroshima, November 8 -13, 2009

Extension of Generalized Label • New Generalized Label format is just defined for the new ODUk application (i. e. , ODU 0, 1. 25 G ODU 1, 1. 25 G ODU 2, 1. 25 G ODU 3, ODU 2 e, ODUflex and ODU 4) • It is a supplement and extension of RFC 4328. Page - 5 IETF 76, Hiroshima, November 8 -13, 2009

Problem for other label format • In case of multiplication (all the Composed Signals must be part of the same LSP), the explicit ordered of all labels is very important for the cross-connection configuration. Each label indicates a component (ODUj tributary slot) of the multiplexed signal. • The timeslots order can not be represented in terms of the bitmap label format. Otherwise there must be more bytes for label representation. Page - 6 IETF 76, Hiroshima, November 8 -13, 2009

Interworking with RFC 4328 • When a new Path (Resv) message is to be received on a upstream (downstream) TE link, the Generalized Label format is identified by the Signal Type and NMC pair in Traffic Parameters. • Signal Type NMC Page - 7 ODU 0 ODU 2 e ODUflex ODU 4 ODU 1 ODU 2 ODU 3 * * 2 8 31 1 4 0 0 0 Label Format [New Label Format] [New Label Format] [RFC 4328] [RFC 4328] IETF 76, Hiroshima, November 8 -13, 2009

Interworking with RFC 4328 • When a new Path (Resv) message is to be sent for a downstream (upstream) TE link, the format of Generalized Label is determined by the Signal Type and/or multiplex structure of the interface port. – If the Signal Type is ODU 1, ODU 2 or ODU 3 and the port is operated only in 2. 5 G TS mode or directly mapping into OTU 1, OTU 2 or OTU 3, the format of Generalized Label must be based on RFC 4328. Page - 8 IETF 76, Hiroshima, November 8 -13, 2009

Interworking with RFC 4328 – If the Signal Type is ODU 1, ODU 2 or ODU 3 and the port is operated only in 1. 25 G TS or 2. 5 G TS and 1. 25 G TS mode, the format of Generalized Label is bases on the operated mode of far-end interface port of this link. • The tributary slot size can be carried in the Interface Switching Capability Descriptor(s) and one LSR can use its TED to determine the ISCD of far-end. Then it can know the tributary slot size of far-end. It shoud not depend on any configuration and discovery function. Page - 9 IETF 76, Hiroshima, November 8 -13, 2009

Interworking with RFC 4328 • If the LSR could not know the tributary slot size of farend, it should try 1. 25 G TS mode firstly and the format of Generalized Label is based on new format. • When a LSR receives a Generalized Label Request and could not support the requested Signal Type and/or NMC values. It must generate a Path. Err including the crankback information with a "Traffic Control Error/Service unsupported" indication. • Then the ingress node will attemp to singal again with the same routing. So this node will try 2. 5 G TS operated mode and the format of Generalized Label is based on RFC 4328. Page - 10 IETF 76, Hiroshima, November 8 -13, 2009

Problem for other method • According to G. 709 Amd 3, an automatic adaptation for interworking between 1. 25 G and 2. 5 G capable equipment is foreseen. • Interworking between RFC 4328 and new extension could be also an automatic adaptation. • There is no necessary coordination for the tributary slot size between two ends of one link by using automatic discovery. • Otherwise we have to introduce a new discovery function and maintain the tributary size relationship for each link. • Furthermore we can know the tirbutary size of far-end by IGP database. • We don’t need a new automatic discovery function for interworking! Page - 11 IETF 76, Hiroshima, November 8 -13, 2009

Next Step… • Further discussion must be needed for one general solution in the long term. Page - 12 IETF 76, Hiroshima, November 8 -13, 2009