Page - 1IETF 76, Hiroshima, November 8-13, 2009 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 - 2IETF 76, Hiroshima, November 8-13, 2009 Changes from 00.txt Signal Type is only extended for ODU0, ODU2e, ODUflex and ODU4. NMC is redefined in terms of the current G.709 Amendment 3. Interworking between RFC4328 and new extension could be an automatic adaptation.RFC4328

Page - 3IETF 76, Hiroshima, November 8-13, 2009 Extension of Signal Type Value Type Not significant 1 ODU1 (i.e., 2.5 Gbps) 2 ODU2 (i.e., 10 Gbps) 3 ODU3 (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 ODU0 11 ODU2e 12 ODUflex 13 ODU Reserved (for future use)

Page - 4IETF 76, Hiroshima, November 8-13, 2009 Extension of NMC NMC Description 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. 1 ODU1 is mapped into 2.5G tributary slots of OPU2. 1 ODU1 is mapped into 2.5G tributary slots of OPU3. 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. 4 ODU2 is mapped into 2.5G tributary slots of OPU3. 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 OPU4. 8 ODU2e is mapped into 1.25G tributary slots of OPU3e2. [Non Normative] 4 ODU2e is mapped into 2.5G tributary slots of OPU3e1. [Non Normative] 31 ODU3 is mapped into 1.25G tributary slots of OPU ODUflex is mapped into 1.25G tributary slots of OPU ODUflex is mapped into 1.25G tributary slots of OPU ODUflex is mapped into 1.25G tributary slots of OPU4.

Page - 5IETF 76, Hiroshima, November 8-13, 2009 Extension of Generalized Label New Generalized Label format is just defined for the new ODUk application (i.e., ODU0, 1.25G ODU1, 1.25G ODU2, 1.25G ODU3, ODU2e, ODUflex and ODU4) It is a supplement and extension of RFC4328.RFC4328

Page - 6IETF 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 - 7IETF 76, Hiroshima, November 8-13, 2009 Interworking with RFC4328 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 Label Format ODU0 * [New Label Format] ODU2e * [New Label Format] ODUflex * [New Label Format] ODU4 * [New Label Format] ODU1 2 [New Label Format] ODU2 8 [New Label Format] ODU3 31 [New Label Format] ODU1 1 [RFC4328] ODU2 4 [RFC4328] ODU1 0 [RFC4328] ODU2 0 [RFC4328] ODU3 0 [RFC4328]

Page - 8IETF 76, Hiroshima, November 8-13, 2009 Interworking with RFC4328 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 ODU1, ODU2 or ODU3 and the port is operated only in 2.5G TS mode or directly mapping into OTU1, OTU2 or OTU3, the format of Generalized Label must be based on RFC4328.RFC4328

Page - 9IETF 76, Hiroshima, November 8-13, 2009 Interworking with RFC4328 –If the Signal Type is ODU1, ODU2 or ODU3 and the port is operated only in 1.25G TS or 2.5G TS and 1.25G 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 - 10IETF 76, Hiroshima, November 8-13, 2009 Interworking with RFC4328 If the LSR could not know the tributary slot size of far-end, it should try 1.25G 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 PathErr 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.5G TS operated mode and the format of Generalized Label is based on RFC4328.RFC4328

Page - 11IETF 76, Hiroshima, November 8-13, 2009 According to G.709 Amd 3, an automatic adaptation for interworking between 1.25G and 2.5G capable equipment is foreseen. Interworking between RFC4328 and new extension could be also an automatic adaptation.RFC4328 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 dont need a new automatic discovery function for interworking! Problem for other method

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