Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2022-04-26 TAPI Meeting Notes

Versions Compared

Old Version 1

changes.mady.by.user Andrea Mazzini

Saved on

compared with

New Version Current

changes.mady.by.user Andrea Mazzini

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Agreed Items & Priority

Discussion items

10 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.

Asked to ONF to extend the additional, official, dedicated TAPI calls till July 2022.


TAPI weeky call canceled

TAPI weeky call

Preliminary agenda:

  • Continue the discussion on potential CTPs/CEPs model (transmission capability)
  • SIP model, relationship with the Access Port
5 mins

pull request #519

All

No news.


85 mins

Presentation of the updated network models of RIA 2.0

All

Andrea Mazzini shows the diagrams which compose the chapter 5.2 TAPI overall network models.

  • The chapter includes two parts:
    • Scenario 1 : Optical Line System Controller
    • Scenario 2 : Integrated Management
  • Each part introduces one or more "time zero" scenarios, i.e. the model of logical resources made available by the server controller before any provisioning is performed by client controller, followed by examples of the possible provisioning scenarios.


  • Figure 5‑2 Scenario 1 : Optical Line System Controller, time zero:


  • Figure 5‑5 Scenario 1 : Optical Line System Controller, MC and OTSiMC CSs:

  • Clarified that the greyed OTSiMC CEPs may or may not be available depending on e.g. underlying monitoring capabilities.
    • There could be the case where only a subset of all potential OTSiMC CEP instances are made available; agreed that the route of the OTSiMC Connection shall include any visible CEP, and similarly the lower connection shall include any visible "cross connection" at OTSiMC layer. See also figure 5-17 below.
    • Also agreed that some implementations may prefer to systematically show the OTSiMC CEPs and XCs, regardless any actual monitoring function behind.


  • Figure 5‑10 Scenario 1 : Optical Line System Controller, multi-band:

  • Nigel Davis there could be hybrid cases where on ROADM1 the OMS CEP instances are separated per band (like in the picture above), while in ROADM2 there is only one OMS CEP instance for all bands.
    • The client controller / orchestrator shall be versatile enough to understand the different scenarios, without relying too much on fixed patterns.


  • Figure 5‑17 Scenario 2 : Integrated Management, MC and OTSiMC+ODU and DSR CSs, OTSiMC CEPs

Image RemovedImage Added

  • Nigel Davis indicates that it is possible to have a partially disaggregated network with integrated management, i.e. the controller sees all the resources but operates on them as they were separated.
  • Agreed that if no OTSiMC CEPs are available, then the route of the OTSiMC Connection is empty.
  • Ramon Casellas points out that the ODUk "unterminated" Connection opens a new paradigm, not explored before.
    • Nigel Davis the "unterminated" Connection is necessary in case of 3R, where intermediate ODUk XCs shall be represented.
    • Agreed that the paradigm can be extended/generalized, it is the case of Connections which are built separately, to be stitched together and/or terminated in a subsequent provisioning phase.
    • Andrea Mazzini will provide a more generic picture on "unterminated" Connections.
20 mins

Continue the discussion on potential CTPs/CEPs model (transmission capability)

    • SIP model, relationship with the Access Port
All

Andrea Mazzini presents some updates on the SIP and NEP regarding the description of transmission capability.

  • Agreed that SIP and NEP shall have same capability attributes and profile.
  • The transmission capability model is structured into:
    1. SimpleTransmissionCapabilityPac: A simple description of which layer protocol qualifiers are potentially supported, together with (optional) number of CEP instances.
    2. TransmissionCapabilityProfile: A centralized description which adds the information on multiplexing sequence, i.e. which stack of terminated CEPs supports the unterminated/connectable CEP.
    3. availablePayloadStructure: The subset of potentialPayloadStructure which is currently available.
      • Note that this dynamic information is typically bound to the scope of the server controller. In general, the client controller has a superior visibility of the dynamic availability state of network resources.
  • Below an example of Payload Structure:

  • In each multiplexing sequence, the first entry indicates the upper most client (non-terminated) CEP, the rest of entries indicate the server terminated CEPs (forming the mux path).
    • Nigel Davis proposes to revert the order, i.e. from server to client.
  • Agreed that in the RIA 2.0 version the transmission capability will be included as optional feature, open to further developments.

...