CCAMP WG, IETF 76th, Hiroshima, Japan draft-zhang-ccamp-gmpls-evolving-g txt Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli GMPLS Signaling Extensions for the Evolving G.709 OTN Control

RSVP-TE Extensions for OTN To extend GMPLS signaling to support the new features of OTN (ODU0, ODU4, ODUflex, new TS(1.25 Gbps)…) Make it more flexible for Green-field (i.e., directly deploy new OTN equipments [G.709-V3] ) and Hybrid- field (i.e., interworking old OTN equipments [RFC4328] and new OTN equipments) Make it future-proof (i.e., able to handle future extensions and changes to G.709 without requiring another complete change)

Changes from version 01,02 Modify the [Introduction] Section and add some notes in this document to indicate ODUflex resizing and TPN allocation are for further study, because they are under discussion in ITU-T and not standardized Add a note to explain that Traffic Parameters may be update to support ODUflex connection request Add a section to describe Backward Compatibility Considerations

To support ODUflex ODUflex A BC ODUflex(BR, BRT) = (2.5Gbps,+-20ppm) …… OTU2 linkOTU4 link It needs three tributary slots in a HO OPU2, because a HO OPU2 TS is a maximum of Gbps It only needs two tributary slots in a HO OPU4, because a HO OPU4 TS is a maximum of Gbps How many tributary slots need for an ODUflex connection along each link depends on Bit Rate and Bit Rate Tolerance (BR, BRT) Therefore, (BR, BRT) information of an ODUflex conn should be included in the signaling End-to-End Need three TSs Need two TSs

Backward Compatibility (1) A (new) B (new) C (old) D (old) E (new) Path Resv (new label)(old label) For the old node, it always generates and sends old label to its upstream node, no matter the upstream node is new or old, as described in [RFC4328]. For the new node, it will generate and send old label if its upstream node is an old one, and generate and send new label if its upstream node is a new one. We can distinguish a node is new or old through manual configuration or automatic discovery.

Backward Compatibility (2) Problems for other method Can we use the following way to determine label format (i.e., new label or RFC4328)? NO!!! Signal Type NMC Label Format ODU0 * [New Label Format] ODU2e * [New Label Format] ODUflex * [New Label Format] ODU4 * [New Label Format] ODU >[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] How the upstream knows how much NMC should be included before sending Path msg in the case of ODU1 and ODU2 conn request? You can only guess blindly. So it needs crankback and crankback… Really ineffectively and unacceptably!!! So, to resolve the backward compatibility (maybe not exist), it should know the capability of the neighbor node (i.e., to distinguish old equipment or new equipment).

Summary: Better choice for you Simple and efficient label format –Bitmap mechanism –No troublesome [ti] like RFC4328 Flexible and scalable label format –Single label format for the Green-field –Good solution for the backward compatibility (interworking old OTN equipments [RFC4328] and new OTN equipments) –Extensible for future specifications if they happen

Next Steps Adopt it as a WG document To include property of ODUflex (i.e., Bit Rate and Bit Rate Tolerance) in the signaling to support ODUflex connection request Remove non-normative things like ODU3ex Refine it according to the feedback from the meeting or mailing list Continue to monitor developments in ITU-T Q11/15