Task xx Scope – Connector Pin Strand Purpose – To re-look at this to see if it can be simplified Specifically –Includes – Excludes – none External Dependencies – none Assumptions – none Risks – none

Team Members Leader - Members ???

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.

Physical vs Logical On the physical side we have Connectors with ‘pins’ Everything else is logical

Cablesets are a simple way to represent simple cables We will define a SimpleCableset as a special case that Has two identical ends Each end uses all of the connector In a similar manner, a jumper wire would warrant a special solution

Copper pair / Fibre Strand etc. termination Option 1 A cable end may have a Connector or strand ends A piece of Equipment may have connectors A connector may connect to other connectors or terminate strand ends – we will call the first type a PlugSocketConnector and the second type a TerminationConnector A PlugSocketConnector has ‘pins’, a TerminationConnector has terminationPins Cable strandEnds are the equivalent of connector pins For copper pairs we may decide to fudge things a little and refer to a pair of pins as a pin and a pair of strand ends as a strand end If the connections are entirely 1-1 then use the high level connections, else use the pin-by-pin connections

Options Shown Pictorially

Copper pair / Fibre Strand etc. termination with Ranges Option 2 This allows us to connect contiguous ranges which can reduce the number of instances required compared to pin-by-pin interconnection If the connections are entire 1-1 then use the high level connections, else if there are useful contiguous range connections use the range option, else use the pin-by-pin connections Note that CableEndHasConnectors can only be used if the cable strand to connector pin mapping is not to be recorded (e.g. for pre-made standard cables)

Now use the item – range union datatype to simplify Option 3 This allows us to simplify the model by abstracting contiguous ranges and pin-by-pin interconnections If the connections are entire 1-1 then use the high level connections, else use the pin/range option Note that if the terminations need to also be managed they should be converted from associations to classes (as was done in the TMF Outside Plant model). <<Union>>

Comparing the options with a contrived example Conn-A:7-9 to Conn-B:1-3 plus Conn-A:12 to Conn-B:4 Option 3 has the class model simplicity of Option 1 with a similar instance efficiency to Option 2. Which model is the best depends on the situation. Option 1 degrades quickly for every case that’s not 1-1 connectors. Option 2 is better than Option 3 if there are large numbers of individual pin connections. Option 1 Option 2 Option 3

How it compares to the TMF outside plant one Define a range owned by each end and then associate them mTOP Outside Plant Submission Telstra-Cisco 1-2.doc , written around 2007 Define a termination that owns the ranges involved at each end. Then decorate the ranges onto the connectors.

Adopting a TMF outside plant style would invert the dependencies This model does allow some nonsense options but also provides a lot more flexibility (such as one-many terminations). It also normalizes the self joins. The names here may be a bit wonky – are they ends or parts ?

Termination Example