1. Old Dog Consulting Composite Labels In Flexi-Grid Adrian Farrel Old Dog Consulting adrian@olddog.co.uk

2. Why Composite Labels? Composite labels are a way to encode information about multiple quantities that are switched together and carry the same data flow Examples –Waveband –TDM VCAT –OTN VCAT

3. Do We Need Composite Labels? Need == Want to support Want <= Able to support –What does WP 2 Say? It is OK if this becomes a standardisation effort outside IDEALIST Composite means? –More than one slot Contiguous slots Non-contiguous slots

4. Input from ITU-T Liaison sent to CCAMP WG – https://datatracker.ietf.org/documents/LIAISON/liaison-2014-04-23-itu-t-sg-15-ccamp-lsr-on-flexible-grid- reply-to-ietf-ccamp-ls012-attachment-1.pdf Central frequency granularity pinned at 6.25 GHz Slot width granularity pinned at 12.5 GHz m <= 916 so 16 bits is adequate No need for in-service resizing of data channels Working assumption that “groups” of channels use the same fiber

5. What do we need to know? Are the slots the same type? CS will always be 5 Will all slots be on the same laser (Identifier value) NO! Could m be different for each slot? –If so, we will surely go mad –But do we need to prevent it? Don’t constrain it n varies per slot Is the compound slot dynamic? –Changed through signaling –Unlikely that data plane can handle this Note that contiguous is a special case of non-contiguous

6. The problem is only for signalling Routing is not an issue –Just operate as usual Signaling has been solved before –Label format –TSpec considerations All we have to do is pick our favourite

7. SONET/SDH VCAT RFC 4606 and RFC 6344 Contains two approaches –Compound Label is simply a concatenation of multiple labels TSpec gets a bit messy Need to request specific slot sizes –LSP is a group of LSPs Easier for dynamic changes No need for composite labels Easy for TSpec Needs external management process In both cases contiguity and ordering are issues

8. OTN ( G. 709 v 3 ) RFC 7139 Just like SONET/SDH –Single LSP or –Multi-LSP Considerably complicated by OTN over- engineering Contiguity and ordering are still issues

9. Data Channel Set RFC 6002 Fully flexible –Works for Label_Set, etc., etc. Overly-complex for our needs? No discussion of TSpec

10. Waveband RFC 3471 and RFC 3473 Assumes contiguous lambdas Only needs to encode top and bottom lambda

11. Proposal (abstract form) Require all slots of same type –CS is identical –Not all use the same laser (Identifier) Allow different slot widths? Allow non-contiguous slots –TSpec should say what is wanted –IGP should say what is supported Use composite labels Other features can be achieved using multiple LSP –ASSOCIATION object –A higher-level function

12. Label Encoding Option 1 We only need to give CS and Identifier once per composite label We can use different values of n and m for each slot Maybe use a new C-Type 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Length (8 + 4r) | Class-Num (16)| C-Type (x) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n | m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n | m | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

13. Label Encoding Option 2 Repeat whole label format each time Easier to parse No new CNum or C-Type needed Needs more bytes on the wire Better future-proofing 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Object Length (4 + 8r) | Class-Num (16)| C-Type (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Identifier | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Grid | C.S. | Identifier | n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | m | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option was chosen in the plenary

14. Label Set etc. Assertion… There is no change needed to –Label Set –Acceptable Label Set Assertion… Other objects just follow the Label object –Suggested Label –Upstream Label –Recovery Label –Label ERO subobject –Label RRO subobject

15. TSpec It’s complicated Are we asking for bandwidth or for slots? If asking or b/w –Do we need to say that we will accept specific “chopping” The simplest is… “I would like r slots of type {CH, m, [Identifier]}”