Nigel Davis presents some clarifications regarding:
TAPI general properties / assumptions
The client has one or more representations of the semantics (models) of the network
The client maintains a view of the instances of things in the network in each of its representational forms
The client has mapping rules to derive each of its representation of semantics from the TAPI interface representation
As a consequence the TAPI server aims to optimise the process of maintaining alignment for the client
What the TAPI server is not:
A database supporting random queries and joins
A GUI server
The definition of Top Level Connection of a ConnectivityService
Brief discussion on "Infrastructure Trail". Agreed that it can be a Top Connection in case SIPs are available to provision the related ConnectivityService (Infrastructure As A Service). If SIPs are not available, the Infrastructure Trail is a Connection (e.g. ODUk) created as result of the provisioning of client layer ConnectivityService (e.g. DSR).
Nigel Davis presents a generalization of the relationship between AccessPort, Connector and Pin.
Currently AccessPort provides relates to one or more pins. The relationship is via connectorPin which is of type ConnectorPinAddress. Through this the AccessPort can relate to multiple connectors/pins.
Currently ConnectorPinAddress provides an opportunity to reference one whole connector or a single pin in a connector. If a whole connector is referenced, then it is assumed that all pins are used. If several but not all pins from a connector are used then the structure repeats the connector name and equipment UUID. The pin is referenced by a single pinIdentification.
An enhancement to ConnectorPinAddress to add an attribute “pinAndRole” (a list) is proposed for TAPI 2.3
The proposed change allows a single connectorPin property in an access port to reference a list of pins. This means that if several pins are used in the same connector, they can be collected in the same connectorPin reference.
The new attribute is of type PinAndRole. PinAndRole offers greater clarity in terms of pin properties. The key properties are:
locationInConnector: Providing clear pin referencing so as to relate to the name of the actual pin in the physical connector.
pinName: Where the pin in the connector has a distinct name not merged into the location identifier
pinRole: Which allows the referenced pin to be tied to a specific functional detail in the NEP referencing the AccessPort. As noted in the description, there may be several pinRoles.
OMS model, the management of unidirectional and bidirectional OMS entities
Arturo Mayoral presents the figures related to unidir/bidir OMS model:
Agreed that path computation shall manage the co-routing of the two directions, i.e. in general the "unidirectional" model delegates the bidirectional management aspects to client controller.
Fully Unidirectional: Unidirectional SIPs (4-ended bidirectional ConnectivityService, i.e. also CSEPs are unidir)
All internal NEPs and Links are unidirectional
Supporting Top Level Connections are unidirectional
Mixed: Bidirectional SIP and unidirectional internal NEPs and Links
Supporting Top Level Connection is bidirectional
Fullly Bidirectional
Agreed that the fully unidirectional model applies only for disaggregated scenario.
This implies that the Link between Transponder and OLP/ROADM is locally managed by orchestrator and there is no need to provide a model for it - which would be a three ended Link, connecting the bidir NEP of the Transponder with the two unidir NEPs of OLP/ROADM.
In other words, the integrated scenario always foresees either the fully bidir or the mixed case.
60 mins
18
OLP model
OLP protection between Transponder and ROADM:
Agreed that OLP model is fully unidirectional if ROADM model is fully unidirectional (case 1. above)
Even if due to its function, the bidirectionality should clearly emerge
Agreed that "Mixed scenario" (case 2. above) does not apply to OLP itself:
Bidir OLP NEPs are connected by a bidirectional Link to bidir ROADM NEPs
ROADM can be either fully bidir or mixed
Unidir OLP NEPs are connected by unidirectional Links to unidir ROADM NEPs
ROADM is fully unidir
Agreed that NEP, CEP and Connection of the OLP are at PHOTONIC_MEDIA layer, with no qualifier (former OMS/OTS, see below) or NMC qualifier.
OLP protection between ROADM ("section" protection):
Fully unidir or bidir model, according to ROADM model
Agreed to represent the NMC "reliable" Link and the OMS "protected" Connection.
OLP protection external to managed network (client side OLP): agreed to remove the scenario from the document.
60 mins
19
OMS, OTS
After long and detailed discussion, agreed that OMS and OTS terms relate to monitoring scope, hence the topological model can be simplified using only NEP and CEP at PHOTONIC_MEDIA layer protocol name, without specifying (post meeting note, we need to add "UNSPECIFIED" value to LayerProtocolQualifier) the layer protocol qualifier. OTS and OMS monitoring capabilities will be modeled by two dedicated packages of photonic CEP. The presence of these packages will indicate the OTS / OMS monitoring span (and the presence of amplifier).
post meeting note 1: monitoring direction is assumed only "co-directional".
post meeting note 2: in case of unidirectional CEP, evaluate whether to split packages into "sink" and "source" parts.
90 mins
20
Photonic forwarding model (NMC, SMC etc.)
Long and detailed discussion on Transitional Link between "electrical" and "photonic" Nodes.
Eventually agreed that Transitional Link in TAPI adds complexity rather than value. Agreed that Transitional Link is useful only for Path Computation.
Andrea Mazzini shows this slide to help discussion, but no agreement e.g. whether the Transitional Links shall include adaptation functions.
Malcolm Bettssuggests that even in integrated scenario, the OTSiMCA ConnectivityService should be explicitly provisioned. This to avoid overloading OTSiA ConnectivityService request with parameters of OTSiMCA.
Transponder and ROADM model related discussion will continue on next call.
