Date

Attendees

Goals

Agreed Items & Priority

TAPI 2.1.3 and RIA 1.1

  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (solved)
  2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs (solved)
  3. Alarm / TCA notification (blocking, 1)
    1. Subscription
    2. Notification contents
      • Probable Causes / Elementary alarms (e.g. ITU-T cZZZ fault causes), including TCA PM Parameters
  4. OTS and OMS model (solved)
  5. Path Computation Use Cases (blocking, 2)

TAPI 2.3 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (solved)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  2. Physical impairments (not blocking)
    • OFC is augmenting TAPI Link, others the AbstractStrand.
    • Type of amplifier, fibre attenuation, etc.
  3. Photonic model capability (not blocking)
  4. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (not blocking)
    • Lifecycle management of single ConnectivityService, necessary to identify UCs
  5. 3R (not blocking)
  6. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  7. RESTCONF Response codes for use cases (not blocking)
  8. TAPI OAS, action points to be assigned (not blocking)
  9. Routing Constraints (not blocking)
  10. Physical Route (not blocking)

Discussion items

5 minsAdministrative

All




Agreed to dedicate one week / 4 days / two hours per day for the review of TR-547: July 5,6,7,9 10-12 CEsT

  • Invited Ramon, Nigel, Ronald, Pedro. Please others interested to contact Andrea.


Next TAPI weeky call - 2 hours

10 minsInter-SDO updates

Ramon Casellas

Arturo

Nigel Davis

Ramon Casellas and Arturo presented the TAPI extensions for GNPY to TIP MUST, 40' high level overview.

  • Underlined that the target is the reuse of CCAMP definitions
  • Reception was positive
  • Static / read only augments are almost consolidated, more challenging the dynamic scenarios, e.g. the provisioning of amplifier parameters.

Arturo, apparently there is already an active liaison between ONF and TIP, we need to check internally to ONF.

Nigel Davis Nokia presented TAPI to O-RAN.

60 mins

Technical discussion on Integration of Streaming and Fault Management

Nigel Davis

Andrea Mazzini

Andrea Mazzini presents the proposal for common alarm/TCA data structure to be used in both Notification and Streaming contexts.

The AlarmInfo and TcaInfo are deprecated, their content is modeled by the DetectedCondition class, which will augment either Notification signal (picture above) or ConditionDetector (picture below).

  • Note that the detectedConditionName has ConditionName type, which is an extensible enum augmented by both AlarmConditionName and PmParameterName.

Nigel Davis keep exploring a formal way to model the "changed attributes", i.e. to avoid name-value pairs.

Andrea Mazzini presents a reorganization of Notification signal:

Ramon Casellas and Nigel Davis propose that ObjectCreation shall be augmented by all defined classes, like Streaming model does, e.g.

Agreed to keep only ALARM and TCA as ConditionType enumeration entries.

Agreed to add FLEETING to SimpleDetectorState enumeration. It is the delta function, e.g. when an event has a very short life (rapid Active-Clear cycling), hence is notified/streamed after its occurrence.

Noted that ACTIVE_NO_EXPLICIT_CLEAR applies to PM metrics which can only increase (counters), hence the "clear" criteria is conventionally the end of a measurement period.

Nigel Davis points out that the severity is always insufficient to address the problem, because:

  • Near to the equipment, there is not enough context knowledge to evaluate a meaningful severity degree.
  • Far from the equipment, a simple parameter like severity cannot help, as more articulated information is necessary, e.g. the business impact.

The overall approach is preliminary agreed:

  • No more redundancy between Alarm and TCA data types.
  • Data types common for both Notification and Streaming contexts.
45 mins

GNPy/CCAMP – TAPI alignment, presentation of candidate TAPI extensions – continued

All

Andrea Mazzini shows some updated pictures:

  • Agreed that OMS Element-Amplifier shall augment the OMS/OTS CEP.
  • Agreed that the OMS Element-Fiber is independent from spectrum bands.

Discussion on capability vs. operational model:

  • The Transceiver Modes augments the OTSi NEP, as it describes the transceiver capability
  • The Transceiver selected Mode augments the OTSi CSEP and CEP, as it describes respectively the intended configuration and the actual configuration.

An analogous approach shall be considered for amplifiers, i.e:

  • Amplifier capability - augments the NEP.
  • Amplifier selected configuration - augments the CEP.

Huy Tran clarifies that currently the GNPy process is considering only the operational values of amplifiers.

  • Planning is a different stage, where e.g. is evaluated how many and which types of amplifiers are necessary to support a transceiver-to-transceiver connection.

It is necessary to clarify which is the CCAMP model of amplifier capabilities. Similar consideration for transceiver, its capability and operational model.

Ramon Casellas it is assumed that a bidirectional NEP has symmetric spectrum support, otherwise the unidirectional model shall be implemented.

Huy Tran confirms that current GNPy application does not differentiate between different load conditions. For future consideration.

5 mins

Use Case 0d – clarification on SAPI/DAPI vs. TxTI/ExT

All

Andrea Mazzini asks for confirmation of last week agreement:

Model the NEP PlugId attribute as:

  • local-id
  • remote-id

Where:

  • NEP 1 local-id is how NEP of Domain 1 is naming itself
  • NEP 1 remote-id is how NEP of Domain 2 is naming itself

Considering OTN technology:

  • the local-id will be the content of TxTI
  • the remote-id will be the content of ExTi

The solution is confirmed.