Control for 1.4 Nigel Davis (Ciena) 20180614

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

Context

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)

The model

The model

Mapping to the traditional view

The pattern

Showing the Controlled things

The document up to section 5

Section 5

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

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 …

Section 5

More background

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

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

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.

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

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

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

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)

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

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

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

Questions? Thank you 