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.
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).
Provisioning of a group of ConnectivityServices, with specific rules for the group (e.g. degree of diversity).
Path Computation / Planning / Check Service Feasibility (providing an Explicit Route Object)
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:
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,
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
viable: proven to have available potential capacity etc. at the point of calculation. It is questionable whether a path can be considered as viable.
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.)
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
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.
Consolidation of ODU OAM
Nigel Davis indicates that the CurrentData is not associated to the MEP/MIP/CEP instance providing the measurement.
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.
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.
<-- 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
After some discussion, a possible approach could be a recursive 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.
Meeting ID: 865 4645 5131 Passcode: 791838 One tap mobile +13017158592,,86546455131#,,,,*791838# US (Washington DC) +13126266799,,86546455131#,,,,*791838# US (Chicago)
Dial by your location +1 301 715 8592 US (Washington DC) +1 312 626 6799 US (Chicago) +1 929 205 6099 US (New York) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 669 900 6833 US (San Jose) Meeting ID: 865 4645 5131 Passcode: 791838 Find your local number: https://us02web.zoom.us/u/k44fY92Xn