1. Control for 1.4
Nigel Davis (Ciena)

2. Purpose To provide Some context for the ControlConstruct work
An overview of TR to assist the review for version 1.4 delivery
Further direction for 1.5

3. Context

4. Management-Control Continuum
Experience/Outcome Expectation
ContractIntent
Experience/Outcome Opinion
Achievement Compliance
Controller
View
Recursion of control levels
Essentially the same at all levels
Including the device 
Automated management is control
A “layer” of control revolves round a model of the controlled things
A control layer will have a repository reflecting:
Intent to support a contract/agreement with or request from a client
Expected and current state of the controlled things in the context of the chosen realization
A control “layer” will present, to its clients, in client terminology, an abstracted view of what it controls where that view aligns with the current contract in terms of:
Potential for providing capability
Actual provided capability
The provided capability will be in terms of constraints
Transform/
Mapping
Transform
Transform
Comms (Through)
Request
Inform
Controller (To)
View
Transform
Transform/
Mapping
Transform
Controlled stuff (About)

5. The model

6. The model

7. Mapping to the traditional view

8. The pattern

9. Showing the Controlled things

10. The document up to section 5

11. Section 5

12. Purpose To link the Control model to the Operations pattern
To enhance the Control model to expose the effects of interaction
Illustration of the relationship between the SDN architecture and the Core IM

13. Current fragment related to Events
Assumption in the model is that the goal is subgraph related requests, responses and notifications
A minimum subgraph may be a single entity
A subgraph may be:
All elements supporting a service
All elements supporting a service that are known to be faulty
The topology of a problem …

14. Section 5

15. More background

16. Outcome-oriented constraint-based interaction
Consider the following states and activities:
Potential Client needs and potential provider capabilities intersect
Both have shared understanding of some semantics in a space where the provider has capabilities and the client needs
Both have (or agree) a common representation of the semantics (which may be a mapping from their preferred internal views)
The potential provider does not expose all aspects of all capabilities (e.g., “how” may be vague or opaque)
The potential client does not expose all aspects of the need (e.g., “why” may be vague or opaque)
Potential client and provider negotiate
This process may increase the semantic intersection and may refine the representation

17. Outcome-oriented constraint-based interaction
Consider the following states and activities (continued):
An agreement is reached (provider intention and client expectation)
The agreement will be expressed in terms of what will be achieved and not how it will be achieved
Where the client and provider have limited semantic overlap the agreement may be in terms of experience (e.g., apparent adjacency experience) where many of the parameters will be in client terms and potentially as a client oriented profile (e.g., performance). The service is the experience (and the experience is the outcome)
Where the client and provider have an extensive overlap, e.g., as the provider is sub-contracting, then the agreement may be more in terms of an abstract realization outcome (e.g., an Ethernet Connection). The service is the realizing (delivery) of the connection, the connection is a resource
The agreement should never have elements of “how”
There may be elements of “with what” (i.e., subordinate piece parts) rather than by doing what (i.e., not in terms of activity).
The “with what” will be abstract constraints
Note: the client should never be interested in the activity required to achieve the outcome, however, it does seem that there is an expectation that there will be an activity based instruction, e.g., “set up the connection” and then perhaps an expectation that the client will observe the activity, in the example connection being set up. There is no clear purpose for such a observation
This does not exclude the possibility of updating the client on progress and of allowing the client to suspend activity
In all cases the agreement is in terms of achieving some state (e.g., apparent adjacency, connectivity) where that state is specified in terms of constraints
It is not necessary to impose the process used to achieve the Outcome/Experience (as this is the responsibility of the provider), so verbs such as “Create” and “Set” are not necessary/relevant

18. Making changes (intent-style at all levels)
Request in terms of desired outcome/experience
Entities of the controlled system are not acted on directly
For example, an LTP (Logical Termination Point) does not provide operations for control
Entities provided in the view are not acted on directly
For example, a NodeEdgePoint does not provide operations for control
“Superior” controller requests desired outcome from “overseeing” controller where the outcome is in terms of a structure of the system of components, exposed by the “overseeing” controller, and the state of those components forming that system
This is purely in terms of data, for example, LTP-123 associated to FcPort-1092 etc
The components, represented as objects, do not offer any operations. Instead the desired outcome infers operations for the underlying systems.
If the desired outcome indicates that traffic should flow between two points it is clear that those points need to exist. If those points do not exist then it can be inferred that the points will need to be created. There is no need to explicitly ask for creation and other terminology may be used in the domain to convey the “creation” semantics.

19. Further context Various reasons to interact:
Demand a constrained outcome in a provider system
Considered above
Makes sense to confirm that the “demand” was received closing the loop
It does not seem to make sense to do a “fire and forget” in this case
Inform of the state of a system in terms of constraints
If information was requested then there is an natural response closing the loop
If the information is sent autonomously, it depends upon whether it is just what I have been asked to send or it is really a request for help.
The latter would seem to benefit from a response
Broadcast query
Has a natural response closing one of the loop.
The query may need to be cancelled once a response is received.
It appears that there are a number of sub cases

20. Dynamic demand pattern
One structure with grammar that is essentially extensible but over time stabilizes
Like human language grammar, it provides the “invariant” structure that enables a range of interaction sophistications
Expressed communication capability
i.e. how much of the grammar is understood
Infinitely extensible semantics
Noun set (simple extension by adding nouns
Interpretable constraint set (dynamic extension)
Expressed semantic coverage
Opportunity for sophisticated expression of delegated interdependent outcome structure
Per exchange-set encoding choices, negotiated and supported by the infrastructure (e.g., Apache Avro) allowing on-the-fly encoding optimization
I.e., dynamic encoding

21. Overview of Operations pattern
It is envisaged that a single compositional structure can describe all degrees of interaction from simple CRUD to complex multi-task constraint delegation
This single structure is designed such that 1of1 composed parts are folded into the parent on a case by case basis
This yields a message that is compact for a simple case but sophisticated for a complex case
A basic controller could offer a limited range of operational capability and provide a schema that is a sub-set of the full pattern (explicitly explaining what it can do (in terms of operations pattern schema) – not what it can’t)
An advanced controller could offer the full range
The advanced controller could communicate with the basic controlled without adjusting its full schema definition as it limits the usage to the narrower capability of the basic controller
As an analogy consider human language grammar where an adult talks to a child

22. Dynamic inform pattern
The approach sketched above can carry a the structure of a system of constraints.
There are clearly many cases where a structure of a system is required in a request but there are also obvious cases of response of structure and of notification of structure too
The intermittent state case, where dependent states are suppressed should perhaps be more explicit (not suppressed) and represented as a system of constraints
Take a state system A<->B<->C<->D. It may be toggling between States B and C being 20% C. We could report this as a constraint statement (either B or C with a preference is the “demand” equivalent)

23. Interface Architecture pattern
For TR-512 v 1.5 and/or v2.0

24. Architecture pattern Several approaches
Runtime Transformation
Replacement of inefficient element
Replacement of incompatible element
It would seem that runtime transformation would be most effective at the Semantic end and least at the comms end
Comms should be more stable than nouns/verbs
Transformation may be asymmetric, for example send in native form and translate on receipt
Communication path for request/receipt of transforms may also need transforms

25. Dynamic encoding
In a dynamic encoding scheme, the encoding choice varies depending upon how much has to be said (and the communication capacity)
Although there will be a rich set of opportunities in the overall noun set and grammar each case of deployment will only use a subset of all possible structures
In some cases the subset will be very small
The small subset may still require complex statements
For a thought experiment, let’s consider a case where there are two possible complex structures where one of the two needs to be in place at any time.
The complex structures take significant complex data to describe and the controller is remote from enactor of the structure
In this contrived and contorted case, this situation (i.e. only two possible complex structures) persists for a year but the swapping between the two is required on average once every 10ms
If the controller tells the recipient about the structures ahead of time and give one the names “0” and the other the name “1” and explains that the request will be encoded in binary, then a single bit is all that needs to be conveyed to cause the change.
Under other circumstances it may be necessary to send a verbose form.
The encoding choice could vary based upon the interface capacity and/or based upon the case constraints
The encoding form could be updated on the fly as the needs change

26. Questions?
Thank you 