Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
    • Plan for dedicated RIA 1.2 / 2.0 review calls (ONF TAPI RIA)
  • Continue the development of Optical Impairment UML model
  • Updates on OAM model

Agreed Items & Priority

Discussion items

5 minsAdministrative

All



TAPI RIA 1.2/2.0:

  • Scheduled two additional, official, dedicated TAPI calls:
  • Added a third non-official call on Thu 10:00-12:00 CET
    • Andrea Mazzini will send the invitation to anyone who wants to participate.


TAPI weeky call

Preliminary agenda:

  • Continue the development of Optical Impairment UML model
  • Continue the discussion on layering recommendations
10 mins

Plan for dedicated RIA 1.2 / 2.0 review calls (ONF TAPI RIA)

Ramon Casellas highlights that these weeks the RIA review process is focused on OAM Use Cases.

90 minsDraft of Optical Impairment UML modelAll

Andrea Mazzini shows the updated draft model.


Discussion on modulation types:

  • Andrea Mazzini found some types listed in ITU-T G.sup39 (02/2016)
  • Arturo points out that OpenConfig is commenting the CCAMP list, will provide update on the eventual agreement.

Discussion on TransceiverProfile:

  • Agreed to promote ItutStandardMode, OrganizationalMode and ExplicitMode as independent profiles. This allows that:
    • OTSiMC NEP/SIP references one or more supported profiles,
    • OTSiMC CEP references the configured profile.

Discussion on SIP/NEP and Profiles:

  • Arturo proposes to keep the SIP as the point where the capabilities are shown. In fact, the Profile information is useful for the CSEP provisioning. Agreed.
    • Leave also the TotalPowerThresholdPac on the SIP.
    • Arturo recalls that this TotalPowerThresholdPac was introduced long ago, maybe version 2.0/2.1, and now we can consider to move this threshold model to OAM.
      • For further analysis.


Discussion on Fibers:

  • Esther Le Rouzic clarifies that the relative position of OtsConcentratedLoss and OtsImpairments is a necessary information.
    • Agreed to add identifiers and references.
  • Discussion on Fiber Profile, whether it is useful or not.
    • Esther Le Rouzic, even the same fiber type can have different loss coefficients.
    • Ramon Casellas how many loss coefficients can exist for a single fiber type?
    • Esther Le Rouzic, in the networks there are many loss coefficients, practically per each deployed fiber.
    • Andrea Mazzini so we have a preliminary agreement to remove the profile for the fiber?
    • Huy Tran GNPy defines fixed parameters for the fiber type, but are different from the ones currently defined by CCAMP.
      • Esther Le Rouzic, it seems difficult that the equipment provides these values.
      • For further analysis.


Discussion on Amplifiers:

Andrea Mazzini asks whether the Amplifier profile is useful or not.

  • Esther Le Rouzic proposes to model the three types of GNPy (EDFA) amplifiers, similarly to the three types of transceiver modes. From https://gnpy.readthedocs.io/en/master/json.html#edfa:
    1. 'type_def': 'fixed_gain' is a fixed gain model. NF == Cte == nf0 if gain_min < gain < gain_flatmax
    2. 'type_def': 'variable_gain' is a simplified model simulating a 2-coil EDFA with internal, input and output VOAs. The NF vs gain response is calculated accordingly based on the input parameters: nf_min, nf_max, and gain_flatmax. It is not a simple interpolation but a 2-stage NF calculation.
    3. 'type_def': 'advanced_model' is an advanced model. A detailed JSON configuration file is required (by default gnpy/example-data/std_medium_gain_advanced_config.json). It uses a 3rd order polynomial where NF = f(gain), NF_ripple = f(frequency), gain_ripple = f(frequency), N-array dgt = f(frequency). Compared to the previous models, NF ripple and gain ripple are modelled.
  • Esther Le Rouzic clarifies that also the PowerParams (either nominalCarrierPower or nominalPowerSpectralDensity) are configurable.
    • Andrea Mazzini likely we will not include amplifier configuration in the next release. However, we can begin to outline the model.
  • Agreed to remove the OmsProfile, promoting AmplifierElementParams and ROADM Paths as independent profiles.
20 mins

Review of OAM technology agnostic model

All

Andrea Mazzini briefly recalls that the model allows two distinct provisioning modes of OAM:

  1. Independent, through the creation of OamService (which leads to the creation of Meg and its Mep/Mip instances) and OamJob (which will include the Current and History Data PM).
  2. Embedded in the ConnectivityService, i.e. all OAM Service and OAM Job parameters are provisioned as direct augments of CSEP.

The building of the OAM Use Cases made evident some issues regarding the "embedded" provisioning.

The picture below shows an example of independent provisioning. Note that an OamServicePoint provides the configuration for one Mep or Mip instance:


The embedded provisioning for the Digital OTN technology may lead to the creation of two MIPs on the same CEP (codir and contradir):


The embedded provisioning for the Digital OTN technology may also lead to the creation of two MEPs on the same CEP (OTU and ODUCn):

Considering that the OamServicePoint can configure only one MEP or MIP, also in case of embedded provisioning we shall follow the same approach, hence now more ConnectivityOamServicePoints can augment a CSEP. This solution allows only simple scenarios, as the OamJob in the embedded provisioning refers to CSEPs, not to OamServicePoints.

The following amendments were made:

  1. The OamProfile is no longer composed by OamContext, now is augmenting the generic Profile. Doing so, e.g. a NEP may refer to OamProfiles to show its OAM capabilities.
  2. Corrected the Odu OAM Service model, reducing all multiplicities to 0..1, as in all cases an OamServicePoint is driving only one MEP/MIP. It’s the CEP which may refer to e.g. several TCM MEP instances for different TCM levels. Regarding the case of MEP/MIP directly composed by the CEP, this is foreseen for NIM and in case of encapsulation (see slide above with OTU+ODUCn CEP).

  • An index shall be added to the Odu MEP/MIP augments, to allow PmCurrent/HistoryData instances to refer to the correct monitoring point composed in the same CEP instance.
  • Post meeting note: to be discussed whether to collapse CurrentData and HistoryData in a single object, CollectedData, which is "history" when periodEndTime is filled.