Mapper Pattern IPR Declaration Is there any IPR

Mapper Pattern

• IPR Declaration • Is there any IPR associated with this presentation NO • NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on Cisco or any other company. The requirements are subject to change in form and numerical value after more study. Cisco specifically reserves the right to add to, amend, or withdraw statements contained herein. • THE INFORMATION HEREIN IS PROVIDED “AS IS, ” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Mapper Pattern • Pool. Entry instances (orange) decorate onto the existing classes (perhaps adding an attribute or two). They could also link into a Request. • Note that the output classes are normal classes and can be mapped by another pool if required • A given pool should not allow recursive behavior (an output as an input) and we should also be careful not to form multi-pool loops ! • Pool. Entries can do various mappings, perhaps using expressions for more complex cases • Could allow Pool. Entries to be mutable by adding splits or adding more to combine, but limiting mutability make sense • May also allow a more general split & combine option or allow mappings to be chained (combine then split • Map. Entry avoids needing N*(N-1)/2 assocs if there a lot of possible mappings • Also Map. Entry allows for attributes in the mapping – need to consider Event message support too • Can map functions or capacity as required – mapping both could be tricky – need to investigate further provided. From. Pool: bool Instances ! Consumer Pool out split Pool / Mapper <<Decorates>> combine 1: 1 Provider Pool in allocated. To. Pool: bool

Apply to ONF model • Assume that an input ‘network’ can comprise FD, Link, FC, Eq, Phy. Link, LTP, PC (+their ports) • Not sure if we should wrap in a CD or not – on in / out / both ? - make available to Pool • Perhaps each pool has an input CD and an output CD – it places the created network in the output CD • To simplify, an input is either mapped or not to a single pool entry, no partials, no shared inputs – can share via an intermediate layer !

Mapper Pattern • Because we will have the same type on the input an output side, we need to have input and output maps (see last slide “Mapping Using an Expression DSL”) • It may also be possible to add ‘protection’ mapping functions 1+1, mirror, 1: 1, 1: n provided. From. Pool: bool Instances ! Consumer Pool out Pool / Mapper out <<Decorates>> out split combine 1: 1 in in in Provider Pool in allocated. To. Pool: bool in

Removing the operator from the entry hierarchy simplifies the hierarchy. What it prevents though is ‘nested expressions’ where we could build a DAG from the inputs to the outputs.

Mapper Lifecycle • Pool / Mapper is created Pool / Mapper

Mapper Lifecycle Requests • Network functions are added to the pool Pool / Mapper in Provider Pool in in

Mapper Lifecycle • As requests come in, pool inputs are allocated /mapped /transformed to pool outputs and the corresponding output ‘virtual network’ is created + Consumer Pool out Pool / Mapper out + + <<Decorates>> out split combine 1: 1 in Provider Pool in + in in in

Mapper Lifecycle Requests • As requests are sent to remove mappings, the ‘virtual network’ is removed also Pool / Mapper in Provider Pool in in

Model Instance Diagram – FC partition Now can be input to another pool

Other Similar Models

Disk Storage Model Disk Partition Volume Group Logical Volume Supports mapping between storage layers Note that storage has only one output type ! And it’s a different class from the inputs The only ‘operator’ is to link a pool output to a pool input It is really pooling and mapping storage capacity only

Mapping Expression Copied from Name Mapper ppt

Go. F Expression Pattern

Temporal Expression (see onf 2015. 473) Note that here we have temporal constants and operators that we can nest into expressions of the form T = !((a-b) U (c ∩ d))

Name Mapping Using an Association • OK for 1 -1, 1 -many, many-1 mappings, but not many-many • Can chain • No ‘metadata’ • Static • Adds 0 instances

Name Mapping Using an Entity • OK for 1 -1, 1 -many, many-1, many-many mappings • Can chain • Can record ‘metadata’ • Static • Adds M instances Compare with Network Model patterns

Name Mapping Using an Expression DSL • OK for 1 -1, 1 -many, many-1, many-many mappings • Can chain • Can record ‘metadata’ • Records the mapping rule, so a change in the input can update the output • Can subclass operator if needed • Adds M + I instances

Name Mapping Using an Expression DSL • Could have a separate Name. Map. Entry subclass Name. Map. To. Entry, but we can note that the output will always be the result of an operation (including a null operation) so we can simplify this case • Removing Name. Map. From. Entry is harder without restricting the applicability of the model (e. g. allowing for operations on operation results)

Mapping Using an Expression DSL • Adding back Name. Map. To. Entry would allow us to have a more general mapping pattern as we could then have subclasses for each network function class (but adds one instance per output) • • Pc. Name. Map. To. Entry Fc. Name. Map. To. Entry as well as Fc. Name. Map. From. Entry … • Adds M + I + O instances • Note that we could also add conditionals as another sort of operator Could remove the operators from under map entry and have a separate composed assoc from Name Map, but this would limit the generality of the mapping expressions because then we can’t mix inputs with operator results Name = upper$(left$(a, 2) + “Ethernet” + right$(b, 6)) +”Port”