GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt )

1. GMPLS Signaling Extensions for G.709-v3 (draft-khuzema-ccamp-gmpls-signaling-g709-00.txt ) Rajan Rao ( rrao@infinera.com ) Khuzema Pithewan (kpithewan@infinera.com ) Ashok Kunjidhapatham (akunjidhapatham@infinera.com ) Mohit Misra (mmisra@infinera.com )

2. Outline • Goals • Proposal • Discussion items • Advantages & Comparison • Backup

3. Goals A model to support signaling for: • Fixed size ODU containers (G.709-v1 & v3) • Flexible ODU containers • Different Time-Slot granularities (1.25G & 2.5G) • Complete muxing hierarchy of G.709-v3 • VCAT services • Potential evolution of OTN standards

4. Proposal New Label Format defined to: • Encode TSs as bit map • Allow specification of complete muxing hierarchy (G.709-v3) • Support TS-Granularities & TPN Extensions to RFC-4328: G.709 traffic params redefined • Tolerance encoded in NMC field • Bit-rate encoded in reserved field

5. New Label Format for OTN Generalized Label Format

6. Proposed Extensions to RFC-4328 G.709 Traffic Parameters (TSPEC) NMC/Tolerance : • NMC is Used only with the Old Label Format (Backwards Compatibility) • For ODUflex SignalType, this field is interpreted as Tolerance Bit_Rate: • Used only for ODUflex SignalType • For other signal types it is set to zero and not interpreted on the receiving nodes

7. Example • Simple network with varying muxing levels • Link A-B: ODU0 directly supported over ODU2 • Link B-C: ODU0 supported over ODU3 over ODU4 • Link C-D: ODU0 directly supported over ODU2 • There is no ODU3-LSP (FA) created between B-C

8. Example cont’d • ODU0 service requested from node-A to node-D • Nodes B & C know they need ODU3 layer to support ODU0 (local matter) • B & C advertise ODU0 BW as per - draft-ashok-ccamp-gmpls-ospf-g709-02.txt • Labels exchange as follows: • A-B: Label for ODU0 • B-C: Label with complete info for ODU3 and ODU0 • C-D: Label for ODU0 • There is no ODU3-LSP (FA) created as a result of the above service

9. Discussion Items (1) • Question-1: Multi-stage is not present at all as requirement/feature in G.709. Our intention to postpone technical solution regarding multi-stage multiplexing is justified by on going ITU-T SG15 progress (Fatai’s comment) • Authors didn’t agreed to the comment • Our interpretation of G.709-v3 is full hierarchy support is required (ref Fig-7-1A) • We agree with Deborah’s comments on NOT restricting GMPLS solution to a single stage • Question-2: Generalized Label Request cannot be changed during signaling path (Fatai’s comment) • Clarified that it doesn’t change and only the labels that change on a hop by hop basis • It is fully consistent with RFC-3471, RFC-4328 • Question-3: …One or more ODU2 LSPs need to be created between B and D in order to support the A-E ODU0 LSP. where are the parameters associated with establishing the ODU2 carried? (John’s comment) • Clarified with an example that the model is not based on FA approach • Clarified that intermediate LSPs are NOT created to support service at different muxing levels

10. Discussion Items (2) • Question-4: An amazing "idea", but it will totally destroy the basic principle of GMPLS (RSVP-TE) (Fatai’s comment) • Authors don’t believe there is any violation of GMPLS • Requested for clarification on what is broken • Question-5: You are advertising ODU0 services on ODU3s that do not support them.   That isn’t consistent with the GMPLs architecture (John’s comment) • Authors don’t believe there is any violation of GMPLS • Muxing hierarchy can be addressed without MLN • like Sonet/SDH label as per RFC-3946. E.g muxing VT into STS-n doesn’t mandate FA • This model doesn’t prevent use of MLN

11. Advantages & Comparison Advantages: • Addresses complete muxing hierarchy (G.709-v3) • Doesn’t require intermediate LSPs when OTN muxing levels are involved • Highly scalable solution (no FAs, smaller TE-DB) • Allows varying muxing levels on each segment seamlessly • Doesn’t prevent MLN deployments • Compact encoding scheme Comparison: • Doesn’t address G.709-v3 muxing levels • Assumes MLN to support muxing hierarchy (FA approach) • Not scalable

12. Backup Slides

13. Limitations of RFC-4328 • G.709 Traffic Parameters (TSPEC) • No support for new SignalTypes defined in G.709v3 – ODU0, ODU4, ODU2e and ODUflex. • ODUflexneeds Bit-Rate and Tolerance to be signaled instead of number of TSs. • NMC parameter is not valid for end-to-end Traffic Specification as number of TS required for ODUj could vary on different ODUks along the LSP path. • Eg: ODU2e requires 9 TS on ODU3 and 8 TS on ODU4. • Generalized Label Format • Not scalable for specifying large number of Timeslots (ODU4 requires 80 1.25G TSs and ODU3 requires 32 1.25G TSs). • Multi-stage multiplexing enforces hierarchical label format which is not supported in the current Label format. • No support for multiple TS Granularities (1.25G and 2.5G).

14. Backwards compatibility Node-A Node-B Node-C Link A-B: • G.709-v1 version (2001) based OTUk link • TSG=2.5G; • Label format as per RFC 4328 Link B-C: • G.709-v3 version based OTUk link (12/09) • TSG=1.25G; • Used New label format proposed Example: For an ODU2 connection going from A-C: • On link A-B : NMC=4 is applicable • On link B-C : NMC is not used; • # of TSs used is 8 • Could involve multi-stage multiplexing – i.e. label for each mux layer

15. Backwards compatibilityInteroperability with Older version of signaling stack • Neighbors should exchange their signaling stack version information ahead of service creation. • On a given span, if one of the neighbor is found to be running older version of signaling stack, Label format defined in RFC-4328 must be used. • If both the neighbors are running newer version of signaling stack, new Label format must be used.