1. Pages
2. …
3. Open Transport Configuration and Control Home
4. TAPI
5. TAPI Call-in Details and Notes
6. 2022-08-30 TAPI Meeting Notes

Page History

All

Preliminary agenda:

• Presentation of Cisco implementation
• Progress the review of the Reference Implementation Agreement 2.0

Continued the discussion on the spectrum model.

• Description of capabilityCapability model, provided by NEP and SIP objects.
  • Agreed that the current datatype provides all the necessary information regarding the port capability:
    • upper and lower frequency
      
    • adjustment granularity
    • grid type
  • Where:
    • The upper and lower frequency values may not necessarily fit the ITU-T fixed and flexible DWDM grid constraints.
    • The upper and lower frequency values may include spectrum portions which cannot be used to support services.
    • The combination of adjustment granularity and grid type informs about either ITU-T fixed or flexible grid capability.
      • E.g. if grid type = DWDM then the adjustment granularity informs about the fixed slot width.
      • E.g. if grid type = FLEX then the adjustment granularity informs about the minimum slot width (two times the adjustment granularity value).
  • Clarified that a given NEP (or SIP) may inform about more than one spectrum portion, e.g. [f1 to f2] and [f3 to f4]frequencies.

• Provisioning model, the CSEP is augmented by OTSi (transponder), MC and OTSiMC (ROADM) specific data structures.
  • Discussion on pros and cons of N, M , N notation for service provisioning.
    • Gabriele Galimberti confirms that their implementation already performs the translation from TAPI spectrum to N, M , N notation, in other words the TAPI model is already providing all the necessary information.
  • Eventually agreed that the current TAPI provisioning model is more generic than N, M notation. In other words, the Client Controller can specify the frequency range either fulfilling the N, M , N constraints or not.
    • Ramon Casellas doing so we do not move the responsibility of ITU-T compliance to the Client Controller.
    • This genericity may become useful e.g. for future gridless implementations.
  • Agreed to clearly specify in the TAPI comments that the Client Controller shall not provision data which does not fulfil the capability described by NEP/SIP and in the case the Server Controller shall reject that provisioning. In other words, the upper and lower frequency values must be well formed according to described capability.
    • E.g. if grid type = FLEX and adjustment granularity = G_6_25GHZ, then the Client Controller shall not provision MC/OTSiMC which upper and lower frequency values do not respect such constraints.
  •  Gabriele Galimberti points out that provisioning exceptions shall be coded, e.g. "not supported grid constraints" or "bandwidth (partially) in use".
    
    • General agreement, this is a planned improvement of Reference Implementation Agreement, likely for version > 2.0

After a brief discussion, it is agreed to move to Hz unit, given the dimension of the uint64 number.

• Ramon Casellas clarifies that the JSON encodes the YANG uint64 as a string type, which is anyway not an issue.
• Gabriele Galimberti highlights that the central frequency value of a transceiver may be specified with greater precision (finer than MHz) with respect to the supported adjustment granularity.