Skip to content

Discussion ‐ Transceiver Model

Jump to bottom
amazzini edited this page Jul 24, 2024 · 13 revisions

2024‐02‐06 TAPI Meeting Minutes

Andrea shows the related UML diagrams of version 2.5.0

  • After some discussion, it was agreed that:

    • The purpose of the transceiver profile (aka template or spec) is to provide the library of capabilities.
      • Hence the proper SIP/NEP shall include a list of one or more supported profiles, representing the supported transceiver modes.
      • This capability information is normally available at server controller.
    • The transceiver profile is read-only.
    • The main use case of the transceiver provisioning is by specifying
      • the central frequency and other info which are orthogonal to the transceiver mode,
      • the reference to the chosen profile instance (transceiver mode).
    • To be further explored the explicit provisioning of some "capability" parameters
      • with or without specifying a profile.
      • Arturo confirms that some legacy transceivers required some parameters "on the fly".

  • Esther indicates that TAPI needs an alignment to the more recent versions of OpenConfig and IETF specifications.

  • Esther also clarifies that the transceiver standard profile needs also the line-coding-rate parameter to be fully defined.

    • ITU-T it was decided to not include this parameter to improve flexibility.

2024‐02‐20 TAPI Meeting Minutes

Andrea shows the IETF drafts he is parsing to update TAPI

2024‐02‐27 TAPI Meeting Minutes

Andrea shows the updated UML diagrams

  • Andrea asks for a clarification regarding the comment of in-band-osnr "measured at reference point Ss"
    • Esther and Gabriele indicate that
      • "measured at reference point Ss" is to be intended as
      • "measured at transmission point", reference being G.698.2
      • It is the quality of the transceiver regarding the inserted noise, in trasmission
  • Andrea asks for clarification regarding OSNR and Penalty unit of measurements
    • Esther confirms that, as defined by the IETF draft
      • the OSNR is "measured over 0.1 nm resolution bandwidth"
      • the Penalty is measured in pure dB, as it is a ratio applied to the OSNR
  • Ronald suggests to consider the provisioning of the frequency offset, or drift
    • indicated the reference: IA OIF-C-CMIS-01.1 Table 7
    • for further discussion

2024‐03‐05 TAPI Meeting Minutes

Andrea shows the updated UML diagrams

  • Esther clarifies that the transceiver profile models both capabilities and configuration

    • no need of further tuning at configuration time, the selected profile instance tells it all
    • in other words, the profile instance constrains the provisioning

  • Nigel suggests that a more generic model should be the target, where each parameter can be expressed for

    • capability, intent/setting, state/threshold

  • Esther clarifies that minOsnrMargin and totalChannelOutputPower are PM metrics

    • hence shall be removed from the Explicit Profile
    • Also _powerManagementConfigPac to be removed

  • Esther provides the list of OpenConfig PM metrics: https://github.com/Open-Network-Models-and-Interfaces-ONMI/TAPI/tree/tapi-team-activities/TAPI-TEAM-ACTIVITIES/Contributions/openconfig-pms.txt

    • Andrea will review and map/add to TAPI
      • Purpose is the correct mapping of PM metrics detected on OpenConfig side and then passed to TAPI i/f

2024‐03‐12 TAPI Meeting Minutes

Discussed the https://datatracker.ietf.org/doc/draft-ietf-ccamp-optical-impairment-topology-yang

  • Nigel asks clarification regarding the standard mode, where only G.698.2 is mentioned, while TAPI currently lists:
    • G.698.1 : Multichannel DWDM applications with single ...
    • G.698.2 : Amplified multichannel dense wavelength ...
    • G.695 : Optical interfaces for coarse wavelength division ...
    • G.696.1 : Longitudinally compatible intra-domain DWDM ...
    • G.959.1 : Optical transport network physical layer interfaces
  • Gabriele replies that G.698.2 is the only one specifying application identifiers
    • Three fundamental types of photonics: CWDM, DWDM, Flex Grid.
    • Gabriele will verify if the other ITU-T recommendations may be included as further references for standard modes
  • Discussion for clarification of table 8-1 of G.698.2 11/2018
  • Nigel asks why some parameters shall be specified in addition to the reference to a standard mode
  • Further investigation is necessary on draft-ietf-ccamp-optical-impairment-topology before to complete the mapping to TAPI

2024‐03‐19 TAPI Meeting Minutes

Andrea is editing a document including the OpenConfig and CCAMP PM metrics

2024‐03‐26 TAPI Meeting Minutes

Andrea asks if there are news/progresses in https://datatracker.ietf.org/doc/draft-ietf-ccamp-optical-impairment-topology-yang/

  • No news, hence agreed that Andrea will adapt TAPI transceiver model according to currently available definitions

2024‐04‐02 TAPI Meeting Minutes

Andrea shows slides regarding the model of transceiver

  • capabilities
  • provisioning (intent)
  • configuration (result of the intent)

Esther and Gabriele provide some clarifications:

  • the instance related data structure is useful when the capabilities are context sensitive
    • e.g. the capabilitity of a pluggable (identified by a part number) may change depending on where it is installed
  • the capability description granularity is on single transceiver, which in CCAMP is defined as a topological item
    • while in TAPI the logical model item representing the transceiver function is the OTSiMC CEP
      • which does not exist until involved in a Connection
  • Andrea will adapt the model proposal according to the above clarifications.

Jonathan: the draft-ietf-ccamp-optical-impairment-topology-yang-15 is assuming a GOSNR (Generalized OSNR) approach, which is only valid to uncompensated coherent networks.

  • It does not allow for OOK interferers such as 10G or non-coherent 40G.
  • To accommodate those signals, the network needs to provide XPM/SPM/4WM parameters to compute the cross-talk.
  • Lets continue the discussion on next week’s call.

2024‐06‐04 TAPI Meeting Minutes

Andrea shows the updated slides regarding the model of transceiver modes, from the perspective of:

  • capability
  • provisioning (intent)
  • configuration (result of the intent)

Esther explains that in both IETF CCAMP and OpenConfig the transceiver function is described (instantiated) regardless it is configured or not, in other words it is described if the underlying equipment supports it.

  • Andrea recalls that TAPI model decouples the physical and logical models, and describes capabilities through dedicated structures referenced by NEP instances
    • Andrea will update the figures

2024‐06‐11 TAPI Meeting Minutes

Andrea shows the slides updated according to the discussion of last week.

  • There is a preliminary agreement on slide 3), to be further discussed with IETF representatives.

1) Capabilities fully contained in the NEP instance:

2) Capabilities partly contained in the NEP instance:

3) Capabilities not contained in the NEP instance:

2024‐07‐09 TAPI Meeting Minutes

Andrea shows the slides updated according to the discussions of last weeks

Roshan proposes that the transceiver-capability-pac shall be included by the SIP, rather than by the NEP

  • Arturo agrees
  • Nigel recalls that the role of the SIP is at a different abstraction level
    • e.g. potentially there could be one SIP for many NEPs, in case the choice among these NEP is not relevant for service provisioning
      • in general, the combinations of capability info would be more complex on the SIP wrt the NEP
    • while the NEP is more hardware oriented
    • These capabilities are useful
      • for path computation purposes, i.e. at planning time, where no service is present
      • at service creation time for detailed routing constraints - hence with a deeper knowledge of the network than the SIP is designed to provide

Preliminary agreement on keeping the transceiver-capability-pac on the NEP

  • To be evaluated whether to always consider the bottom most NEP

Andrea asks opinions regarding whether to centralize or to distribute the additional parameters:

image

  • Arturo recalls that in OpenConfig the model is more hardware oriented and these parameters are replicated per each instance of transceiver
  • According to Nigel, these parameters are more type based
    • E.g. the min-central-frequency is fixed per equipment type
  • Nigel adds that leaving these info distributed will open the door to further replications and hence less efficiency

After some discussion, the preliminary agreement is that these parameters are valid candidates for centralization.

Arturo, what about capabilities directly exposed by the equipment model?

  • Nigel recalls that in a very old implementation the equipment model showed also capabilities, to allow planning applications even before the hardware deployment

  • Also noted that the capabilities could depend on different combinations of same hardware components

  • Furthermore, the capabilities exposed by (vendor) equipment model could be later selected/restricted by (customer) equipment model

    • i.e. Customer X is using a subset of the capabilities as declared by Vendor Y

  • Andrea underlines that the capabilities under discussion are the transmission capabilities provided by the hardware

    • hence should appear at least in the topology model

Discussion to be continued.

2024‐07‐23 TAPI Meeting Minutes

Andrea presents the slides updated according to the agreements of last week.

  • Gabriele points out that the explicit mode is not useful to assess interoperability
    • the complexity of the technology makes difficult/impossible a priori estimate of the interoperability
      • all the parameters of the explicit mode are optional, hence different vendors may publish different, not overlapping sets
      • the right value combination is scarce and incomplete even in the CMIS model
    • exactly for this reason the standard and organizational modes were introduced
  • Arturo considers that the value of explicit mode is to add further details to the standard and organizational modes
    • useful to configure the interoperability tests

Andrea highlights the recursive usage of the Profile object

  • Roshan asks clarifications regarding the "hardware based profile"
    • as suggested by Nigel, to group together the references to the profiles supported by a given hardware
      • avoiding repetitions and providing a better organization of the centralized info
    • Agreed to define the recursive relationship as "grouping", moving it to the Tapi Common and leave it optional in the RIA
  • Gabriele: IETF models do not scale, the information is replicated on instance base
    • the parameters of the explicit mode are potentially replicated per each real transceiver of the network
    • centralization is necessary
Clone this wiki locally