GMPLS Signaling Extensions for G 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 )

Outline Goals Proposal Discussion items Advantages & Comparison Backup

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 Signal type ODUflex in bundled link case

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

New Label Format for OTN Generalized Label Format   

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

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

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

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

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) 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

Advantages & Comparison 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

Backup Slides

Limitations of RFC-4328 G.709 Traffic Parameters (TSPEC) No support for new SignalTypes defined in G.709v3 – ODU0, ODU4, ODU2e and ODUflex. ODUflex needs 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).

Backwards compatibility 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 Node-A Node-B Node-C

Backwards compatibility Interoperability 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.