1. 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

2. Team Members
Leader - Members
???

3. 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.

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

5. 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

6. 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

7. Options Shown Pictorially

8. 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)

9. 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>>

10. 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

11. 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.

12. 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 ?

13. Termination Example