| Day | Period | Topic & Contributions | TAPI Version | Discussion - pls add link to contributions | Notes |
|---|
| All | All | General Items, Planning | All | - Enhance modularity of delivery process, e.g. on single module base
- Process to be described and agreed
- Avoid version 2.1.4
- RIA 1.1 can define some name-value pairs to fulfil Use Cases with still TAPI 2.1.3
- Alarm/TCA, keep version 2.3 substantially backward compatible with 2.1.3
|
|
| Mon 12 | P1.1 | Intro, Agenda review |
| Agenda agreed. Ramon Casellas is reviewing the minutes of past TAPI calls: some of the new Use Cases of draft RIA 1.1 need further review, to be planned in the next TAPI calls. |
|
| P1.2 | Path Computation / Planning / Check Service Feasibility (providing an Explicit Route Object) Fully Explicit Route indication | 2.1.3 2.3 --> | Ramon Casellas presents otcc2021.RC.001_TAPI-PathComputation.pptx - Learning from IETF PCE
- Issue of UUIDs instead of object ref:
- Karthik Sethuraman this is likely only historical, we can amend with usual object references, e.g.
grouping path-ref {
leaf path-uuid {
type leafref {
path '/tapi-common:context/tapi-path-computation:path-computation-context/tapi-path-computation:path/tapi-path-computation:uuid';
}
description "none";
}
description "none";
} - Ramon Casellas proposes to specify in the RIA 1.1 two name-value pairs which allow to group PathComputationService concurrent provisioning:
- It is possible to define an agreement between client and server that the Path Computation task is composed by N distinct Paths, implemented through N PathComputationService requests with a common group id and the index.
- This solution does not conform to the protocol, but is doable in TAPI 2.1.3
- Nigel Davis will present the PathSet concept as more generic mechanism to group Paths, see next P2 slot.
- Karthik Sethuraman In MEF and TMF there is the concept of Order, which purpose is to track the provisioning activity.
- ERO Provisioning:
- Proposed the solution to specify the ConnectivityService / Path constraints as an
- ordered set of NEPs (referenced by name),
- per each NEP a new data structure (allocation) which includes technology specific constraints, e.g. wavelength, amplifier gain/tilt, etc:
- Andrea Mazzini we should try to avoid model duplications, because the detailed path/route constraints can be specified through a subset of current (technology specific) CEP attributes. Ideally we should split the CEP object between intent and state attributes. Nigel Davis we also need to consider intents expressed as ranges., e.g. route the connection using a choice between three time-slots. Ramon Casellas in GMPLS works we started some study considering ranges, but we concluded that it was too complex with respect to actual requirements, where ranges are not required but only exact single time-slot / wavelength. Karthik Sethuraman outlines a Use Case where Orchestrator provisions an end-to-end connectivity spanning three distinct managed domains:
- First domain, the Orchestrator requests all the available wavelengths between UNI1 and ENNI1.
- Second domain, the Orchestrator requests the subset of available wavelengths between ENNI1 and ENNI2 among the ones available in the first domain.
- Third domain, the Orchestrator requests the subset of available wavelengths between ENNI2 and UNI2 among the ones available in the second domain.
- Ramon Casellas suggests a simpler scenario, where Orchestrator asks to each domain all the available wavelengths and then enforces the one common to all three domains.
- Nigel Davis we also need to consider multi-layer constraints, where not-yet-existing-client NEPs could be part of the constraints.
- Ramon Casellas notes that PathComputationService already foresees 1-to-many Paths, hence using the diversityPolicy attribute of RoutingConstraint object it seems possible to implement some grouping provisioning.
Preliminary list of Path Computation Use Cases emerged during the discussion: - Client requests Server to calculate more Paths between same end points, each Path with different constraints (e.g. focus on delay or focus on cost, etc.). One of these Paths will be used as routing constraint for ConnectivityService provisioning. Note that a variable degree of routing diversity could be required between the group of Paths. To be considered also the multiplicity between PathComputationService and its Paths.
- ERO provisioning, Client requests more detailed constraints, e.g. the exact label / time-slot / wavelength of a Path. Single layer only.
- Stateless PCE, the calculated Path is not created at Server side, i.e. is seen at the management interface only in the reply of Path provisioning Post/RPC (Post could inherently not support a stateless provisioning). (Lower priority UC).
- Concurrent computation of multiple Paths/ConnectivityServices (i.e. not be sequential computation) with specific rules for the set (e.g. degree of diversity).
|
|
| P2 | Path Computation / Planning / Check Service Feasibility (providing an Explicit Route Object) Fully Explicit Route indication | 2.1.3 2.3 | Nigel Davis presents otcc2020.ND.010_TAPI-ConnectivityServiceComputationService.pptx - There is an error in the current UML definition, the correct association between Path and Link is [* → 1..*] (rather than 1→ 1..*) because more Paths can share same Link.
- Consider the static and dynamic cost of a Link, more in general it is required a dynamic planning (or on-line planning), where planned paths can change during their lifecycle to follow network changes (evolution, faults) while respecting the originally specified constraints (but there is only one RoutingConstraint instance per PathComputationService instance).
- Karthik Sethuraman recalls that Path Computation was introduced for architectural purposes, and stateful. Nigel Davis presents the PathSet concept:
- Predefined PathSets:
- Set provides alternative Link Chains
- Different PathSets may be used for different services
- PathSets may be constructed for future cases that require different routing to current
- PathSets are not provisioned
- Agreed that PathSet is a generalization of the grouping solution proposed by Ramon Casellas in previous slot P1.2
- Nigel Davisnoted that there is a distinction between a path and a connection in a connection oriented context where the connection has explicit network edge points but a path only sets out intermediate links.
- It was noted that a PathComputationService is defined in terms of PathServiceEndPoints which are SIPs and hence is edge to edge.
Editor's note (ND): So a Path that is chosen as a constraint in a ConnectivityService request should belong to a PathComputationService that has the same SIPs as the requested ConnectivityService (as other Paths, even those that go between the right NEs may not be viable for the SIPs - of course a path may not have capacity anyway as it was precomputed intentionally with no analysis of capacity) - Nigel Davis we should explore whether to collapse Path Computation into ConnectivityService provisioning, given that the Path is essentially a pre-computed intent for the Route.
- Also consider the provisioning of multiple ConnectivityServices with intra-constraints.
- The stateful paths may be known by a Control Plane and used for preplanned restoration etc.
Editor's note (ND): The distinction between a stateful Path and a ConnectivityService is that the Path is not activated to carry traffic and cannot be activated to carry traffic until used by a ConnectivityService and the connections are provisioned and activated. Editor's note (ND): There are several dimensions here which need to be considered in any convergence/collapse, - s
tatefulness stateful: Path/ConnectivityService are retained by the provider systems (controller and potentially a control plane or the underlying devices)stateless: The path/ConnectivityService is not retained by the provider systems
specificity (there may be other forms of specificity in addition to the two listed... it could be argued that elements of viability are actually also elements of specificity)path: Just a description of a way to get across the network for some purposes without details of the channel etc.connection: A specific way across the network with details of the channels etc. sufficient to carry traffic assuming viable
viabilityviable: proven to have available potential capacity etc. at the point of calculation. It is questionable whether a path can be considered as viable.
reservation:reserved (must be stateful, ought to be viable, ought to be complete, i.e., a full connection statement): all necessary resources have been allocated and are not available to others (in a timeframe etc.)
deployment:deployed (essentially is reserved and stateful, ought to be viable, ought to be complete): all necessary resources are in place in the network and are setup for the purpose of supporting the ConnectivityService
operation:operating (essentially is reserved, stateful, viable, complete): resources are operating and providing the necessary ConnectivityService
Editor's note (ND): There is a corner case of a serial compound link that appears as a link but is supported by serial connections within the span of the link where those connections are of the same layer/qualifier as the connection and where that necessary capacity can be reserved etc.
- Andrea Mazzini considers that the Path could also be infrastructure, i.e. a virtual network to be used for future end-to-end ConnectivityService provisioning.
- E.g. the ODUk Serial Compound Link Connection which interconnects the transponders.
Editor's note (ND): A virtual network is more than just paths. We need to study this in detail, I think it will end up being Node/Link construction with some viability considerations etc. as per discussion in the core. The current TAPI VN is lacking.
- Some further considerations done on 15 April session:
- Nigel Davis Could same Path refers to different SIPs?
- Nigel Davis Can we combine ConnectivityService and PathComputationService into a single service?
- Ramon Casellas To be considered the intra-Node constraints in WDM routing of IETF
- Andrea Mazzini Reachability from line port to line port (e.g. Serial Compound Link Connection), in addition to reachability from UNI/ENNI to UNI/ENNI.
|
|
| P3 | Consolidation of ODU OAM | 2.3 | Nigel Davis indicates that the CurrentData is not associated to the MEP/MIP/CEP instance providing the measurement (the oam-job, that contains the current-data, can relate to more than one oam-service-point). - Note that in Ethernet OAM the association is likely inherently defined by OAM job types.
- Agreed that CurrentData shall include a reference to the MEP/MIP/CEP instance providing the measurement.
Editor's note: There may also be an issue with oam-profile (0..1) where there are multiple mep/mip/cep instances related to an oam-job
Discussion on PM data collection, there could be a degree of variations between the two extreme cases where PM data storage is either exclusively maintained on Server or on Client Controller side. These architectural differences can require different PM data structures. - Nigel Davis there is the need to represent policies like zero suppression and repetition suppression, by e.g. a new dedicated object, distinct but maybe related to OamProfile object.
Agreed that FEC parameters shall augment CurrentData and HistoryData rather than OTU CEP. - The FEC related measurements can be triggered automatically when OTU MEP (pac of OTU CEP) is provisioned.
The ODUCn contains n instances of the ODU PM overhead, numbered 1 to n (PM #1 to PM #n). - Agreed to model this multiplicity by a 1..n packages of ODU MEP, and analogously by an array of measurements for CurrentData/HistoryData.
- Andrea Mazzini list the OTN related questions still open.
- Nigel Davis explore various pm information density improvement policies such as zero suppression.
|
|
| Tue 13 | P1 | Physical Route and Optical impairments GNPy | 2.4 | Nigel Davis do we have specific requirements on Physical Topology model? - Ramon Casellas UC for the physical impairment validation of a pre-calculated OCh/OTSi trail path.
- Andrea Mazzini UC for the physical diverse route in an equipment.
- Andrea Mazzini note that draft-ietf-ccamp-optical-impairment-topology-yang abstracts the internal ROADM topology through path categories of the Media Channels inside the ROADM:
Express path: MC path between two line ports of the ROADM Add path: MC path from an Add port to a line port of the ROADM Drop path: MC path from a line port to a Drop port of the ROADM
- Ramon Casellas to get the clear picture of the optical impairments it is necessary a detailed logical view.
- Karthik Sethuraman underlines that there is also a communication issue, TAPI abstract concepts could be difficult to be understood by WDM folks, they use a different terminology.
- Ramon Casellas GNPy Json modules are manually built and in general the focus is on amplifiers, e.g. 96 vector values for the advanced amplifier model.
- Noted that it is assumed full load for the simulations, no partial load simulations so far.
- Noted that many parameters are not fully described.
- Maybe is not necessary to represent 96 TAPI Connections for the amplifier model.
- Nigel Davis in fact the amplifier has typically one single Connection between its ports.
- In the core model work TR-512.A.4 (TR-512_v1.4_OnfCoreIm-info.zip) provides various degrees of modeling of components right into the depths of the amplifier including models of pump lasers, circulators etc. During this modeling work it was clear that the core FC (TAPI connection) can be used to represent all channels (in a laser, the fiber in an amplifier etc. (which is why the photonic CEPs are yellow, the color or a connection). Hence it would be possible to show a decomposition of the single connection into any subordinate connections necessary to represent the flows through the amplifier.
Karthik Sethuraman shows https://github.com/Telecominfraproject/oopt-gnpy - In elements.py we can find the managed objects:
- Node, with types: ROADM, Amplifier, Transceiver, Fiber.
- Link: pure association between Nodes, note that the "Fiber" is a Node type.
- It seems there are no "Ports" of e.g. a ROADM Node, looking at CORONET_Global_Topology.xls example.
- In excel.rst some more descriptions:
<-- east cable from a to z -->
NodeA ; NodeZ ; Distance km ; Fiber type ; Lineic att ; Con_in ; Con_out ; PMD ; Cable Id ;
<-- west from z to a -->
Distance km ; Fiber type ; Lineic att ; Con_in ; Con_out ; PMD ; Cable Id - GNPy documentation refers to draft-ietf-teas-yang-path-computation (YANG Data Model for requesting Path Computation).
- Karthik Sethuraman the question is how to retrieve the amplifier properties through TAPI?
- After some discussion, a possible approach could be a recursive forwarding topology, where the higher partitioning level shows the Connections spanning the Node (e.g. ROADM Node) and the lower partitioning level shows an abstraction of the internal topology of the ROADM, with "cross connection" view only where useful for management.
- Alternatively, chains of connections, with no real intermediate points and ignoring the full physical model, could be constructed to deal with the flow through adjacent channels in the device (as per the core model where the core has an FcPort to FcPort association) and hence provide a detailed logical/virtual representation of the functional flow.
Ramon Casellas in OOPT there is the MUST (Mandatory Use Case Requirements for SDN for Transport) working group, which published OpticalSDN ControllerNBITechnical Requirements - "Within MUST, all member operators have agreed on a first prioritization about the different use cases already defined and available through [ONF TR-547]".
Ramon Casellas ODTN uses TAPI for the provisioning of:
- DSR ConnectivityService and
- OT to OT ConnectivityService.
Ramon Casellas ODTN and ONOS are being extended with GNPy related parameters, we need to understand how TAPI can support GNPy input parameters.
- It is necessary a clear agreement on the ROADM model.
Ramon Casellas proposes to wait few weeks and see if GNPy/Impairments Use Cases will mature. |
|
| P2 | Physical Route and Optical impairments GNPy | 2.4 | - There are three distinct requirements:
- Intra device diversity validation (two or more connection routes through the device can be compared to validate diversity)
- Which traffic hit in case of a piece of equipment fails or is removed (all connections shown to be dependent on an FRU can be identified)
- Internal cabling alarms (alarms that are related to pins/connectors internal to the device can be understood in terms of potential impact on connections)
- For these requirements the AccessPorts and Strands are not necessary, focus is on Equipment and Connector Pins.
- Note that some equipment are of "physical support" only, i.e. although the signal does not pass directly through the equipment it supports equipment on the signal path, for a more complete modeling of fault propagation and path diversity.
- The EquipmentPortPair is the association between input and output ports within an equipment (i.e., demarking the flow through the equipment)
- This is an "afterwards" model, i.e. it describes the physical route of a provisioned connectivity. It is not describing the equipment topology. The routing is assumed vendor specific.
- It validates the internal diversity.
- Equipment resiliency aspects can be represented through e.g. 4 UnidirPhysicalRoutes, combining direction and redundancy. Concept of equivalent routes.
Ramon Casellas agrees that this proposed extension is necessary. - Nigel Davis to document some Use Cases to further clarify the model usage.
There was a brief discussion on also allowing for internal AccessPorts. This will also be considered in addition to the purely equipment model. |
|
| P3 | European H2020 PASSION Project https://www.passion-project.eu/ Politecnico di Milano and SM-Optics Liaisons: LiaisonONF-PASSION.pdf and ONF liaison response to H2020 PASSION project.pdf | 2.3 ? | Prof. Pierpaolo Boffi (Politecnico di Milano) presents the EU Passion Project PASSION_Project ONF.pdf
- 8.5M € budget
- End of May 2021 conclusion of the project
- The main goal of PASSION project is the development of application driven photonic technologies supporting an innovative transceiver and node featuring different levels of aggregation (in spectrum, polarization and space) for an envisaged network architecture able to match the growing traffic demand in metro connections.
Germano Gasparini presents PASSION_TAPI_Liasion Draft2.pptx - The viewpoint from SDN for the management of Media layer.
One of the key advantages of the SBV-T technology is the capability for dynamically add/remove bandwidth to a DSR service operating directly at optical layer - Switching on/off each single VCSEL (Vertical Cavity Surface Emitting Laser), where O/E conversion is performed
This capability can be abstracted by managing the optical resources of the SBV-T transmitter and receiver nodes as “OTSi pools”.
The Muxponder Model: 
In terms of TAPI model: 
- Nigel Davis shall the spectrum be contiguous? Germano Gasparini replies that while in theory a free spectrum management would improve the network usage, at least for metro networks the measured improvement was not meaningful, so for now it is considered only the contiguous mode.
- Discussion on possible generalization to more line ports. A single OTSi SIP instance could represent the whole SBV-T capability, referencing more OTSi NEPs where the 40 OTSi could be routed.
- Note that is possible either to add/remove bandwidth (quantitative) or to add/remove one or more given OTSi (qualitative).
- This hardware moves the boundary of WDM network nearer to the client/UNI side.
- Agreed that OTSiCoordinatesPac is not strictly necessary, but useful to identify hardware.
- Agreed that groupId is redundant.
- The considered service is DSR, directly adapted on optical carrier(s). For further study the OTN/Flex-O.
|
|
| Thu 15 | P1 | Consolidation of Alarm/TCA | 2.3 | - Nigel Davis questioned the raise-time, change-time and clear-time. For a problem model, this would not be sufficient as all changes need to be tracked etc. As this is an alarm model focussed on reporting change, there is only one necessary time, event-time where that time corresponds the the occurrence of the specific state being reported. As the client will have received the previous events for the alarm if any (perhaps raise or change) then it can build full history.
- Karthik Sethuraman we shall define the invariant information of alarms, the Alarm Catalog (or Specification), which could be
- vendor specific,
- configurable (populated - Onboard API) or at least retrievable.
- For example the Alarm notification includes an AlarmId which is the entry of Alarm Catalog, where to find the invariant associated information like "probable cause aliases".
- This to avoid the unnecessary communication of invariant data at every alarm notification.
- Nigel Davis There are three strategies for Specifications:
- available at management i/f
- device based
- external catalog
Agreed that TAPI 2.3 will keep similar/same content as TAPI 2.1.3 regarding alarm/TCA parameters: - To maintain backward compatibility
- Keeping the distinct TapiAlarm module
- Possibly fulfilling RIA 1.1 UC16a, 16b
|
|
| P2 | OTS and OMS model | 2.1.3 ? | Andrea Mazzinipresents otcc2019.AM.005_Photonic-OMS-OTS.pptx - Nigel Davis these layers are often modeled as unidirectional, there is no strong reason - as every transmission function is inherently unidirectional - but the model shall include the unidirectional representation.
- OTSiA could theoretically use a mix of C and L band spectrums.
- After some discussion, agreed that there are no strong criteria to steer the model hence:
- OTS and OMS can be represented by a single CEP instance with the new OTS_OMS layer protocol qualifier (instead of UNSPECIFIED qualifier).
- OTS and OMS can be represented by distinct CEP instances with resp. OTS and OMS layer protocol qualifier.
- OTS and OMS layers can be represented either unidirectionally or bidirectionally.
- OTS, OMS, MC are essentially different aggregations of Media Channels, agreed to keep only MediaChannelConnectionEndPointSpec class, with OTS/OMS/MC specific packages.
- E.g. the MC pac will have a single spectrum info, while the OTS/OMS pacs can list more non-contiguous spectrums.
- A single OTS/OMS/MC CEP instance can represent both C and L (and other future) bands.
- A single OTS/OMS/MC CEP instance can represent only a single band.
- In this case some parameters, e.g. related to OSC or amplifier, shall be common for more CEP instances.
- Agreed to represent these parameters through an additional, dedicated CEP instance
- with PHOTONIC_MEDIA layer protocol name and UNSPECIFIED qualifier,
- client of PHOTONIC_MEDIA/UNSPECIFIED NEP,
- likely without client NEP.
- Ramon Casellas why TAPI defines OTSiMC while G.807 defines NMC - Network Media Channel?
- Karthik Sethuraman there were many discussions and eventually on ITU-T side it was agreed that OTSiMC would have been a better definition, but the NMC term was kept for historical reasons.
- Karthik Sethuraman we should improve the tracing of discussions.
|
|
| P3 | DSR/ODU multiplexing over ODU | 2.3 ? | Ramon Casellas presents otcc2021.RC.001_TAPI-ODU-UseCase.pptx - Preliminary agreement on the pattern of SIP availability:
- SIP on the line side of the OT, for the provisioning of the Serial Compound Link Connection (OT to OT) ConnectivityService.
- SIP on the floating TP NEP, for the provisionig of the Infrastructure Trail (which terminates the Serial Compound Link) ConnectivityService.
- SIP on client NEP of the Infrastructure Trail, for the provisioning of the Serial Compound Link Connection (OT to OT) ConnectivityService.
- And so on.
- Agreed that the RIA can specify simplifications, e.g. the DSR ConnectivityService provisioning can include:
- The creation of server ODU connection (as there is 1:1 relationship between client signal and ODU container).
- The creation of the Infrastructure Trail terminating the already existing Serial Compound Link Connection (OT to OT)
- Contraints on the server ODU shall include:
- Selection of ODU time slot.
- Selection of the server ODU Connection.
- The analysis of the scenarios will be continued in next meetings with high priority.
|
|