Task 34 Scope – LTP Port (L=Nigel Davis) Purpose – To investigate the addition of a Port class for LTP Specifically – Includes – Producing a slide pack and/or white paper for discussion in the December F2F Excludes – Updating any existing TRs External Dependencies – none Assumptions – none Risks – none

IPR Declaration Is there any IPR associated with this presentation NO NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on Cisco or any other company. The requirements are subject to change in form and numerical value after more study. Cisco specifically reserves the right to add to, amend, or withdraw statements contained herein. THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

TMF TR-225 doesn’t need LTP Port (Not a fundamental concept) TPE == ONF LTP LT == ONF LP The protocol stack was intended to be done at the LT level, so no ambiguity requiring LTP Port In effect TPE was a grouping only

TMF TR-225 LTP are just LP groups Target TMF Architecture CTP Current TMF CP CP FIP LR z ‘ ’ AC AP AP AP Termination Logical Interface ITU TTP TCP FEP TCP SNFR TMF CTP CP FIP ITU CTP CTP LR y AS ’ AP TPE Fixed (degenerate) Media Interface SNFRE Fig 17 TCP LT LR x AP TMF PTP TCP PTP LR w Expanded Format Compact format (as used in TR-215) Expanded G.805 Rationalized G.805 & ITU-T G.774 & SID SID SID TIP PTP/CTP Representation Information Architecture Managed Transmission Device Interface

Current ONF CIM Model, LP doesn’t participate in any structure Note there are 2 types of assoc to LTP 1 – (Asymmetric Component) Port – LTP 2 – (Symmetric) Component - LTP

Current ONF CIM Model Issues The diagrams and the model don’t match (see later slides) LTP needs ports if it is asymmetric (which it is, so it does) LP needs ports if it is asymmetric (which it is, so it does)

LTP Port types Client Port ’ Currently we expect to have 3 types of LTP ports and they could be modelled as shown Coding this in the model structure would limit other future cases (but is worth recording in this investigation) Coding the role in an Enumerated attribute is a reasonable, more flexible alternative Server Port Client Port ’ Server Port Peer Port

The ONF model doesn’t actually match the diagrams we use Simplified Diagram form Further simplified Diagram form Actual Model Form (ignoring Spec) LP are an ordered array from bottom to top LP1 LP1 LTP3 Note that the LP ordering implies that the first LP in the list is connected to any lower LTP connection and the last LP in the list is connected to any upper LTP connection. There is no way to represent a connection into the ‘middle’ of a LTP ‘ ’ ’ ’ LP2 LTP2 LP2 ’ ’ List index value LP3 0 1 2 LTP1 LP5 LP4 LP4 LP3 We will use this simplified form to help in understanding the current model issues only as a convenience in this document LP5

Addition of LTP Port is not enough on its own Simplified Diagram form Further simplified Diagram form Actual Model Form (ignoring Spec) LP are an ordered array - from bottom to top LP1 LP1 LTP3 ‘ Client Port ’ ’ ’ We are still missing the LP to port bindings. Since the LTP are of standardised types, we need not repeat this binding in every instance, but can do it once per type in the Spec layer Server Port LP2 LTP2 LP2 Client Port ’ ’ Server Port LP3 List index value 0 1 2 LTP1 LP5 LP4 LP4 LP3 Peer Port LP5

Adding LtpPortSpec completes the picture Instance model has LTP and LP config info + external linkages Spec model has LTP and LP structural info (internal linkages) LP1 LTP3 LP1 LP-T6 ‘ ‘ LTP-T6 Client Port ’ ’ ’ ’ Server Port LP2 LP2 LP-T2 LTP2 LTP-T7 Client Port ’ ’ ’ Server Port LP3 List index value LTP1 0 1 2 0 1 2 LTP-T8 LP4 LP5 LP4 LP3 LP-T1 LP-T2 LP-T2 Peer Port Peer Port LP5

On the asymmetry of LP Spec model has LTP and LP structural info (internal linkages) In our example, the LP are clearly asymmetric, so LpSpec should really have ports too It is implied that in the LP list in the LTP, the server side of LP entry n links to the client side of LP entry n+1 (as shown in red in the diagram). Note that this limits is to only representing a simple layering of LP in a LTP Also, it is implied that the server side of the LP connects to the LTP server port and the client side of the LP connects to the LTP client port When we have a peer LTP (port), we need to say which side of the LTP is connects to ! (the centre in this case ???) LP Server Side LP-T6 ‘ LTP-T6 LP Client Side Client Port ’ LP Server Side Server Port LP-T2 LTP-T7 LP Client Side Client Port Server Port 0 1 2 LTP-T8 LP Server Side LP-T1 LP-T2 LP-T2 LP Client Side

? ? ? ? = move to LTP ? Proposed ONF CIM Model Note there are 2 types of assoc to LTP Port 1 – (Asymmetric Component) Port – LTP Port 2 – (Symmetric) Component – LTP Port Proposed ONF CIM Model ? ? ? ? = move to LTP ?

Proposed LTP, LP Spec Model – Client-Server Cases Only LtpSpecLpEntry is critical to get the result we need

Instance Diagram For Slide 11

Proposed LTP, LP Spec Model – Wrong ! – LP connections are per LTP spec LpPortSpec LtpSpecLpEntry is critical to get the result we need

Proposed LTP, LP Spec Model – General Case LtpSpecLpEntry is critical to get the result we need 1..* 1 LP Spec Reference in LTP Spec LP Spec Reference in LTP Spec Refer also Network Graph Patterns Revisited.pptx

Proposed LTP, LP Spec Model – Note the recursion / layering LP type definition – black box + access ports LP Spec Reference in LTP Spec LTP type definition – internals – the LP types and how they connect within the LTP 1..* 1 LTP type definition – externals - black box + access ports LTP Spec Reference in LTP LTP and its external connections (+ config of LTP type)

We can also add another layer on top – Layer Protocol ‘Part’ Note the similarity to 1..* 1

We need a better name than ‘Entry’ It’s sort of like a class instance relationship – an ‘instantiation’ of the spec LtpSpecLpSpecInstantiation – instantiation of LP spec in LTP spec Also it’s sort of a reference and a sort of a copy and sort of a placeholder – but really neither ! Manifestation Token Surrogate Delegate Broker Intermediary Mediator

Abstracting LpSpecEntry

Implementation Specific Options Name + Description plus Subclass Decorate Use soft properties Attached constraints

FC Spec Complex

We start with the standard pattern Type = P-way Protected Pp Rr all = r1 uscp C&SC uscp=Pp ucp=Pp ucp p=2..n r=1 P = protecting R = Resilient FC spec instance FC instance (showing LTPs) FC Spec Reference in FC

And now we explode the FC spec This is just a FD Spec + a FC Spec ?? C&SC Type = P-way Protected uscp C&SC ucp FC spec instance # = FC Spec Reference in FC Spec # #

Comparing the LTP and FC models

Comparing the LTP and FC models

Next Steps Need to do the other Key classes FD Link PC ControlConstruct Equipment & EqHolder

PC Spec Complex

Pc Spec Composite

Other Slides

Side note – this could lead to a general instance to spec mapping pattern “Prototypical” Chassis It seems to make sense when mapping composite associations into the Spec layer to do this The general pattern of changing assoc end multiplicities from one to many can give odd results

Equipment Model Instance Diagram

Proposed ONF CIM Model The change makes Symmetric and Asymmetric cases more consistent (both boundaries are ports) AsymmetricXxHasBoundaryPorts SymmetricXxIsBoundedByLtpPorts Need to determine what the LtpPort identifier is – can a LTP have many ports playing the same role ?

Working Notes