Old Dog Consulting Composite Labels In Flexi-Grid Adrian Farrel Old Dog Consulting

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

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

Input from ITU-T Liaison sent to CCAMP WG – 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

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

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

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

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

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

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

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

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 | Object Length (8 + 4r) | Class-Num (16)| C-Type (x) | |Grid | C.S. | Identifier | Reserved | | n | m | ~ | n | m |

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

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

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]}”