Skip to end of metadata
Go to start of metadata




  • Admin
  • Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx
    • New use cases: 0d, 1g, 1h, 2a, 2b, 2c, 3d, 3e, 3f, 5d, 11a, 11b, 13b, 13c, 16a, 16b.
      • Continue the discussion on DSR/ODU multiplexing over ODU
      • Consolidation of Alarm/TCA
      • Review agreements on OTS and OMS model
      • Link model, agree a general rule
      • Optical Impairments and Topology

Agreed Items & Priority

  • Below the list of the agreed items and related priority.
  • An item is blocking when its resolution is necessary precondition for the delivery.

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 (blocking, 2)
  5. Path Computation Use Cases (blocking, 3)

TAPI 2.3 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 1)
    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

10 minsAdministrative


Nigel Davis will set up an additional separate call for clarification regarding TR-548 scope, involving Jack Pugaczewski (MEF and TMF).

  TAPI Call: canceled - week of Q2 MEF Meeting

TAPI Call: 2 hours

10 mins

Other Admin

Huy Tran

Huy Tran and Dominique Verchere have been working with GNPy and now are interested in the possible mapping with TAPI.

  • From SDN perspective the provisioning of a service shall include the optical impairment parameters required by GNPy. We need to understand the necessary TAPI augmentations.
  • Huy Tran offers to present the GNPy ad-hoc model at next TAPI call.
80 mins

Continue the discussion on DSR/ODU multiplexing over ODU


Ramon Casellas presents otcc2021.RC.001_TAPI-ODU-UseCase.pptx

  • Andrea Mazzini recalls that the usage of CSEPHasServerCSEP association is to allow the provisioning of server layer contraints in TAPI 2.1.3.
    • This to say that we may move to a more appropriate model in next TAPI versions.
  • After some discussion, agreed that the ODU CSEP (2.1) will refer to DSR SIP (2), to indicate that the CSEP instance is used only to specify layer protocol constraints.
    • Routing constraints can be specified through e.g., include Link or ConnectivityService/Connection coroute inclusion.
    • Use case 2b: "Unconstrained service provisioning with ODU selection" will be accordingly updated.
    • Agreement that the usage of CSEPHasServerCSEP association is applicable only when
      • there is 1:1 relationship between ConnectivityService characteristic information / bandwidth and the immediate server layer, i.e. no multiplexing
        • inverse multiplexing case is supportable in TAPI 2.1.3 only in case of single SIP, otherwise the CSEPHasAssembledCSEPs association is necessary. For further review.
      • there is only one server layer Connection supporting the client layer ConnectivityService, i.e. the adaptation functions are only at the managed network edges.
  • Agreed that the selection of wavelength is unlikely to occur at client ConnectivityService provisioning phase.

Ramon Casellas asks for clarification regarding the asymmetry between transponder and ROADM concerning respectively OTSi and (OTSi)MC layer protocol qualifiers.

  • This asymmetry is due to the requirements of disaggregated architecture/management, where on the trasponder side the focus is on the signal (OTSi), while on the ROADM/OLS side the focus is on the spectrum (MC, OTSiMC).

Agreed to centralize the slides (e.g. of otcc2019.AM.005_Photonic-OMS-OTS.pptx and otcc2020.AM.005_TAPI_Enhancements.pptx) in otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx

40 mins

Consolidation of Alarm/TCA


Andrea Mazzini shows the draft model of TapiAlarm for TAPI version 2.3

  • Preliminary agreement to keep feature parity between TAPI 2.1.3 and 2.3 concerning alarm/TCA parameters.
  • UC16a and 16b need further review.

Karthik Sethuraman proposes to change the name of TapiAlarm module to TapiFm. Agreed.

Nigel Davis proposes to remove the alarm/tca Raised Time parameter, as belonging to the wider Problem management model.

  • The Problem management is at another level with respect to Alarm management.
  • The notifications related to a Problem inform about the Problem lifecycle evolution.
  • A given Problem could be cleared/closed by administrator.
  • A given Problem can list more correlated alarm probable causes, affected services, etc.
  • Nigel Davisto provide a proposal for the problem model.