LTP Port and Spec enhancements for “2.0” Preparing to make the change Nigel Davis (Ciena) 20181205

Adding port to LTP The LTP represents the effects of functionality related to termination and adaptation of signal protocols and to control of that functionality The functionality represented is of significant variety and complexity The LTP encapsulates/abstracts that complexity and exposes the effects via its attributes and associations (as do all classes that represent functionality) The representation is spread across the LTP/LP classes which provide mainly structure and association to other things the LTP/LP spec classes which provides detailed structure the specific “filled out” specs which provide detailed attributes etc. per Type of LTP The LTP is asymmetric from a Component-Port pattern perspective Hence it should have ports Current LTP ports are not explicitly modelled and the asymmetry is modelled using associations to represent different port roles A port role may be represented by two associations Some associations do not unambiguously represent the role Some potential port roles are not supported by the current association set The LTP ports and LP ports are “wired up” for a particular “case” using the “filled out” spec Hence the model needs to correctly support the wiring – this will take some validation It may be correct to move some of the structure to the LP class from spec and to consider the blur of type and class But this does not change the need to add port

LTP shown as a system of Components

Strengthening the Component-Port This provides a sketch of the LTP and LP ports The LTP is a Component that is a System of Components, LPs. The LTP and LP ports are not exposed directly There appear to be several cases that would benefit from LTP/LP port exposure However, exposure of a generalized Port appear to complicate the model It is proposed that: The LTP class and the LP class have LtpPort and LpPort added The Spec model be further enhanced to deal with ports Changes to add Ports be considered as a 2.0 release considering the significance of the change We work to make 1.n and 2.n compatible 

LTP with ports New model sketch

Actions (high level) Core classes (see next slide for options for LTP work) LTP  LogicalTerminationPoint + LtpPort LP  LayerProtocol + LpPort Spec class Refine port models that have already been added to LP/LTP Diagrams Refine all diagrams (probably in conjunction with a move to Photon (as I have to tackle most diagrams then too) Definitions Refine definitions of the two classes

Approach and activities – LTP options Add LtpPort, keep old associations as deprecated and add new associations to LtpPort. Update all diagrams. This appears a reasonably correct way of doing the work as the semantics are not changed and the LtpPort provides a new alternative approach to representation of the existing semantics. This maintains backward compatibility in that the associations are still present. But the attributes will clutter the classes. We could delete all the old associations (but then (2) seems a better option) This will take significant work Add LtpPort and move associations etc. from LtpPort. Update all diagrams Association end semantics change. This means we have xmiIds with changed semantics. In a purist world we should not do this… but… This forces a move to the LtpPort as there is no alternative This will take a little less work than (1) Convert LogicalTerminationPoint into LtpPort and add new LogicalTerminationPoint. Move associations as appropriate. Further semantic change issues This forces a move to LtpPort as there is no alternative Add two new classes replacing LogicalTerminationPoint and rebuild the model From a pure semantic perspective this could be argued as correct as the LTP semantics have changed, although I would argue that the composition that is the LTP is unchanged. This is the most complicated and heaviest option from a work perspective

LtpPort role and adding rules The LtpPort is added due to asymmetry and hence there is a “ltpPortRole” FORWARDING…. More complex as there is LP attachment point “to TCP” “to CP” (which may have associated monitors) Inward or outward facing CLIENT PROVIDER CONTROL… More complex The ltpPortRole should really be as the FcPort role which is defined by the spec In the case of FcPort this is essentially always a sub-role of FORWARDING In the case of LTP, CLIENT, PROVIDER and CONTROL are perhaps more fundament – we do not want to leave these freeform. Perhaps ltpPortRole has two elements (fixed role and fluid role) Would also make sense for CONTROL which is potentially complex Perhaps all port role attributes should have a fixed element and a fluid element (as an FcPort could be for CONTROL!) We could take the opportunity to strengthen the model with rules that correctly restrict the use of port with respect to port role Perhaps there is a general pattern to this where there are some formally defined aspects and some freeform aspects Need to be careful here

First cut LTP with Port (showing primary context) Note that the view mapping function should describe the inter-view relationship. It can be argued that this is a CONTROL port… Provider Discussed in Ottawa. Key challenges highlighted

Dealing with port role complexity… suggestion for self-joins The associations vary by role of port The sketch shows a possible mechanism to support port role variety for the self joins Only one rule is shown (in free hand) Note that the “abstract” inheritance is to depict that the classes are NOT to be instantiated

LTP spec V1.4

Further discussion