1. Spec model application
Nigel Davis

2. Considerations Spec Model recap Spec Model status
Also see TR-512.7
(in TR-512 V1.4)
Spec Model recap
Spec Model status
Implications – Emerging pattern
Tosca Node Type
Building the system
Tosca Topology Template
Specification of detail using a single mechanism
Deep specification

3. Spec Model Definition of a “Type” (as per TOSCA usage) of thing, e.g.,
An specific implementation of Ethernet LTP
A specific variant of circuit pack
Provides “all” invariant aspects for the Type, either directly or indirectly (by reference to another spec) in the definition
Invariant values (e.g., name of manufacturer of a specific variant of circuit pack) so as to unclutter the instance
That the circuit pack has a particular thermal rating is important but invariant across all instances (there are hundreds of properties like this)
That the realization of the function requires a particular memory is invariant across all instances
Variable Attributes not defined in the Core (providing full definition)
Includes ranges, defaults, interrelationships to other attributes etc.
The attribute will appear in the instance either directly or in some substructured part (depending upon the spec)
Invariant structure where the Core allows flexibility that is not present for the Type
Detailed invariant structure not included in the Core
Where the complexity of the structure would clutter the instance
Where the attributes scattered through that structure can be presented at the top level (as their true position is understood from the spec)
Definitions for an attribute that exists in the core model but for a particular Type is narrower than the core definition (e.g., a name string that cannot include “A” )
Provides a pattern for compact instantiation and interpretation of the instantiation as well as specific details

4. Spec model status Specific classes Current approach
LTP – rich dedicated structure (to be discussed tomorrow)
FC – rich dedicated structure (will also touch on tomorrow)
FD – FD is its own spec (roughly) and there is some structure related to this in the FD model
Scheme/System – Only set out in pictorial form
Equipment – No specific classes for spec but some clarity on what would be in the spec if we had classes
PC, CD – Only work via examples and via Scheme/System spec
CC, Casc, etc. – No specific work
Current approach
Dedicated per class specialized structure… BUT
The structure of the spec is essentially the structure of the finer grained model of the specific area
So an LP has formal sub-structuring of Termination etc., but this only appears in the Spec not the class
The FC has LPs in it and the LP has FCs in it
We cannot avoid the need to set out the structure
But we need to think carefully about what is spec what is inherent structure and how the two are related
The relationship may vary per case – in one case an item might be spec and in another the same item might be in the instance
Where an item lives depends upon its invariant aspects for the “Type” that the spec applies to

5. Implications – Emerging pattern
The functional classes are decomposed, at least in part, into other functional classes from the model
The decomposition may have several occurrence (uses) of each of the other classes – see
Scheme spec example on next slide
LTP and FC spec
The decomposition may be recursive, nested etc.
The effect of the assembly of the decomposed parts is the emergent behaviour of the specified class
So the emergent relevant behaviour of an FC, i.e., the effect of all of the parts, is simply forwarding
Appears to be generatable by particular model transformations that seem the same as those of P&R
Splits, pruned clones, merged models etc.
Appears to fit the TOSCA Type pattern, but to require emphasis over the general pool of random types (as it constrains new Types)

6. Scheme spec example

7. LTP spec V1.4

8. FC Spec V1.4

9. Moving structure from spec to class
Some of the structure of the LP spec is so fundamentally a part of the LP that it should be in the LP class model… perhaps…
But this would require us to deal with the occurrence challenge in the class model
In the general System Spec, the occurrence pattern appears to be P&R as the System Spec is an “independent” model from the class that has occurrences
In the core model, the occurrences appear in the same model as the class that has occurrences
The appearance of occurrences in the core model is about forming the governable pattern rather than to form the occurrence themselves where as in the Spec
However, this still requires distinct representations in some cases
Regardless, there is a need to keep the occurrences aligned with the class and hence a need for tooling
This tooling is similar in purpose to the Pruning & Refactoring tooling

10. Building the System (bucking the system )
The Scheme (System) Spec is intended to define the rules/constraints for the assembly of parts to form a particular system
E.g., 8032 ring node and then ring
This is exactly what the TOSCA topology templates are intending to do (although the approach appears incomplete)
As per discussion on Monday
The Component-System Spec application and the Service-Realization definition appear to be the same thing
It would appear that one approach focussing on TOSCA-ONF convergence would remove the need for any Service models and representations as the effect is the components
E-Line becomes a component (that happens to be a simple Component with emergent behaviour of the FC and hence is an FC).

11. Deep specification Somewhat speculative, but…
The same approach would appear to be applicable through a deep recursion such that the detailed functions of a protocol realization could be represented, from the perspective of control implications, in a System spec form (TOSCA-Template/ONF-Spec)
The deep specification would allow true reasoning about behaviour in the network and would enable a critical step towards automation
This is clearly a long way off… but perhaps working with Rina (John Day et al) towards a machine interpretable spec would help both initiatives

12. Background
From CordBuild 2017