Discussion ‐ Digital payload of photonic media ‐ Model enhancements and generalizations

Nigel recalls that a generalization of the transponder to transponder connectivity was asked by Ramon a while ago
So far the transponder to transponder connectivity design is centered on supporting digital OTN payload
- ODUk or ODUCn Connectivity Service, which provisioning params include all photonic provisioning (transceiver mode, central freq. etc.)
Discussed to which degree the transponder to transponder connectivity shall include digital payolad details
Preliminary agreed that the model shall be designed to encompass more flavours / scenarios

Andrea indicates that so far the TAPI RIA has foreseen transponder to transponder connectivities in strict conformance to G.709 OTN payload.

This could be a limitation, given the variety of existing solutions, e.g.
- OTN but not G.709
- Non OTN
Andrea shows some figures with a different organization of NEP/CEP stack:
1. Introducing a new OTSiMCA CEP.
2. Either encapsulate the OTU parameters in the ODU CEP (given the fixed 1:1 relationship), or keep the OTU CEP separated.
Preliminary agreed that the OTSiMCA could or could not be terminated on the regenerators.
- In case it is terminated, then the OTSiMCA Connectivity Service will list - in case of regens - more OTSiMCA Top Connections.
  - Hence no end to end Top connection for the OTSiMCA Connectivity Service.
- In case it is not terminated (the regens manage the pass-through) then the OTSiMCA Connectivity Service will have only one e2e Top Connection.
To be explored whether the new OTSiMCA CS model will be added to or will replace the current one.

Andrea recalls that so far the TAPI RIA has foreseen transponder to transponder connectivity config/state model optimized to G.709 OTN payload.

This could be a limitation, given the variety of existing solutions, e.g.
- OTN but not G.709
- Non OTN
Andrea shows the slide with the requirements for "transponder to transponder" Connectivity Service
- Text amended according to suggestions from the team
Discussion to be continued.

Andrea shows some new figures regarding the transponder to transponder connectivity

General agreement on the approach
The management of inverse multiplexing can be attached to the
- OTU/ODU or OTSiMCA CEP instance, unique client of the NEP which represents the digital payload supported by one or more optical carriers
Use dash-dot line for alternative choices in the functional stack
Agreed that descriptions - of even multiple cases - anyway reduce the variety of implementations

Andrea presents the usage of OTSiMCA layer protocol qualifier to enhance the decoupling of L0 and L1 models.

Ramon proposes to simplify the DSR over OTSiMC model, by skipping OTSiMCA layer in case there is no multiplexing at L1, i.e. only one DSR CEP client of DSR NEP client of OTSiMC CEP(s). Agreed.
Roshan agrees the general approach but suggests to add more explanation
Ramon, Arturo: the "backward compatible" in the picture are uncorrect, change in "aligned with". Agreed.
- In fact, everything is backward compatible, as the OTSiMCA layer management is an addition wrt current RIA 3.1

Below the amended pictures:

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

Gabriele, Ramon and Roshan consider the usage of OTSiMCA layer protocol qualifier as potentially misleading
- after some discussion, agreed to consider a better term if proposed
Some clarifications and corrections to the slides, which are essentially agreed
- Andrea will update the RIA accordingly

Provide feedback