Capability Service Need Intent Constraint Expressing Capability and

Capability, Service, Need, Intent, Constraint Expressing Capability and Needs Pruning and Refactoring Nigel Davis (Ciena) 20181205

Discussions • General discussion on terms § A step on a very long path to consistency • A bit more TOSCA • What ONF offer • Discussion on Expression of Capability 2

Capability, Service, Need, Intent etc. • Parties Advertise Capability/Need § Potential/Desired Outcomes-Experiences (from Activities) § Offers are of Capability to achieve specific Outcomes-Experiences • Capabilities are offered in terms of abstract functional Components with specified achievable Outcomes/Experiences § • • Hence the word “Service” is redundant Parties Negotiate to achieve agreement § Narrow options to acceptable intersection of Capability/Need § Agreement in terms of Intent/Expectation between the parties who now have clear roles of Provider/User • Intent is stated in terms of abstract functional Components with specified achievable outcomes/Experiences § • • E. g. , E-Line is a Component… Intent is in terms of constraints where the tightest constraint is a single value etc. Provider examines available Capabilities and determines an arrangement of these, i. e. , Systems of Components, to achieve the desired Outcome-Experience (probably during the negotiation as well as after the agreement) § Capabilities are examined in terms of abstract functional Components with specified achievable Outcomes-Experiences • § • E. g. , E-Line is a Component which achieves the Outcome of specific data transfer rates etc that give the Experience of Apparent Adjacency E. g. , E-Line is a Component… Hence the word “Resource” is redundant Interaction recurses through all layers and between all peers in this uniform way § Some will not negotiate, but instead there will be a simple demand. • This is as if pre-negotiation has taken place, and hence it is a sub-case of the above 3

TOSCA and ONF Core • Both OASIS TOSCA and ONF Core increasingly reflect the considerations on the previous slide • Both need a method for expression of Capability/Need in terms of Constraints (forming a volume of acceptable Outcomes) § Various considerations such as degree of acceptability • This points to need for a uniform and broadly applied: § § § Grammar and expression language for capabilities and need Noun set for each domain Approach to interaction that enables advertisement, negotiation and agreement • With necessary adjustments 4

What we have in ONF • • • Several Domain-specific Component definitions (related to expression of useful capability to achieve Outcomes-Experiences) § TR-512. 2 &. 4: Networking (FC, LTP, FD, Link). ONF fundamental domain of ownership. BUT part a broader multi-industry domain § TR-512. 5: Resilience (CASC). A key domain, focussing on Network aspects but more broadly applicable. And part a broader multi-industry domain § TR-512. 6: Physical (Equipment/Holder). A tip of somebody else’s iceberg, i. e. , a broader multi-industry domain in which we dip our toe § TR-512. 8: Control (CC, Cc. Port, Exposure. Context, View. Mapping). Another key domain of ownership. BUT part a broader multi-industry domain § TR-512. 11: PC (PC, CD). A generalized model that is a “super domain” like identity Spec (TR-512. 7), which is gradually moving to the necessary form § TOSCA could provide the meta-model for this (although more work is to be done as discussed on Monday) § ONF could provide specific constrained forms of the general meta-model for LTP etc. (i. e. , the work we are doing but more closely associated with TOSCA) Interaction pattern (TR-512. 10), which is very rough, but… § • This is currently rough and points towards a narrow grammar that needs a broader definition in the TOSCA context but may be sufficient for us Control (TR-512. 8) § This provides: • The port through which control interaction takes place (and therefore where all negotiation etc. happens) • A sketch of how the view of capabilities might be formed § • Using Exposure. Context and Constraint. Domain to select from the Domain specific Components The linkage to the Interaction patterns 5

Discussion… Expression of Capability • Details held in Spec “occurrences” (what words do I have left ) • Offers, agreements, instances reference the specs • Specs are held in separate repositories and accessed via reference • Specs state capability in terms of constraints (including invariants) • The assumption is that the receiver of the spec is able to “interpret” it and hence must have a Capability statement parser • We do not have a good rule language • We have not focussed on expression of need but it is essentially “the same” 6

Focus on harmonization • Currently, capability is expressed via specific spec structures, one for each the key class, LTP, FC etc. , in the model • A spec may include several Occurrences (cases) of use of one of the spec elements • In addition, there are scheme/system specs that express the capability of systems of key classes • As discussed, it would seem that scheme/system specs and key class spec should be of the same structure and hence the structure should be unified § § We should be able to form a guiding meta-model with TOSCA It would seem that the Component-System pattern should be a basis for the unified structure • This is a longer term goal as, more importantly, we need examples of use of the mechanism (in terms of running code) 7

Some terminology • Component-System pattern and TOSCA metamodel § • Spec pattern (meta-model) § • • General form explaining how a Component is “specialized” Class Spec (e. g. , Ltp. Spec) § As some specialization is done via classification these are just dedicated specs in terms of specific classes § If there was to be no classification, then layer upon layer of Types would replace this • E. g. , LTP would be a Component type (where a Spec (referenced directly by the type value) explaines how the generalized Component was P&R’d into LTP • As TOSCA has no classification beyond the general pattern, this is how the classes in the ONF model will need to be represented “Type” Spec (e. g. , Ethernet. Variant. XSpec) [horrible term ] § • General underpinning model Just as is the case for TOSCA, “Type” specs can be further refined by another “layer” of “Type” specs Instance 8

Progression… Spec for class X Class Spec Type S of class X Type Spec Instance 1 of case S of class X Instance P&R Part Type A Part Type B Part Type A. c Part Type B. w Part Type A. (c) Part Type B. 1 (w) Part Type A. d Part Type B. y Part Type A. 1 (d) Part Type B. 1 (y) • The spec pattern is expanded for each Type to have the necessary occurrences of each part, interconnected within the constraints of the Spec structure • The Spec case is then instantiated for each occurrence of the case • The expansion is as defined for Core to TAPI as classed are Cloned and pruned etc. § Both the class spec and the type spec are Class models in that they have property definitions § The Type Spec is a “semi-instance” in that it has some invariant values • BUT the same is true for a Class structure derived from the Component-System pattern… the Class just happens to embed the invariant stuff in a specific way 9 Instance 2 of case S of class X Part Type A. 2 (c) Part Type B. 2 (w) Part Type A. 2 (d) Part Type B. 2 (y)

Further thoughts (and a challenge) • The detailed capability of a thing is expressed by decorating with parts that themselves have constrained semantics that fit within the definition of the thing § How is this policed? • The capabilities may be expressed in terms of apparent subordinate parts where these parts can be positioned on the constrained semantic map • An LTP may have controllers within it but those controllers only emerges when the LTP is dismantled or its behaviour is expressed.

Spec approach • Defines the decoration that details, for a particular case, part of the semantic space covered by the class § This allows for a dynamic extension/reduction of exposed capability which interplays with intent • The scheme spec describes a system structure in terms of classes of the model and in terms of constraints § § The same grammar for systems of constraints would appear to apply here The scheme spec provides the constraints on what outcomes can be requested

But… • An approach is to develop a generalized Component spec using the Component-System pattern where a particular usage is developed by P&R of the pattern to give necessary constrained parts § § § This method would allow the generation of a scheme/system spec structure and an LTP spec structure But as noted earlier, the LTP can be derived from the Component-System pattern by appropriate application of P&R The challenge is what are the classes and what are the constraints, or, as noted earlier, can we simply consider a class as a representation of constraints • This would appear to be an activity we will need to share with OASIS 12

Proposal • Construct a generalized Component-System spec as a collaboration with OASIS TOSCA • Apply this via repeated P&R to yield a refined LTP and System/Scheme spec etc • Explore restarting the P&R tooling and use of it to assist this work, especially in the 2. 0 time frame. 13

Further discussion 14