Skip to end of metadata
Go to start of metadata




Agreed Items & Priority

  • Below the list of the agreed items and related priority for the next TAPI & RIA versions.
    • An item is blocking when its resolution is necessary precondition for the next delivery.
  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (blocking, 1)
    1. 3R
    2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs.
  2. OTS and OMS model (blocking, 2)
  3. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (blocking, 3)
    1. Lifecycle management of single ConnectivityService, necessary to identify UCs
  4. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 4)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  5. Elementary alarm (e.g. ITU-T cZZZ fault causes), including TCA related notif), current and history (blocking, 5)
  6. Photonic model capability (blocking, 6)
  7. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  8. RESTCONF Response codes for use cases (not blocking)
  9. TAPI OAS, action points to be assigned (not blocking)
  10. Routing Constraints (not blocking)
  11. Physical Route (not blocking)

Discussion items

5 minsAdministrative

 TAPI Call: 2 hours

10 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

"name" : [
"name" : " plug-id-inter-domain-sapi",
"name-value" : "USATELCORuapc2"
"name" : " plug-id-inter-domain-dapi",
"name-value" : "USATELCOSuapc5”
  • With the following specification:

The access point identifier (SAPI, DAPI) shall consist of a three-character international segment and a twelve-character national segment (NS) (see Figure 15-5). These characters shall be coded according to [ITU-T  T.50] (International Reference Alphabet – 7-bit coded character set for information exchange)

The international segment field provides a three-character ISO 3166 geographic/political country code (G/PCC). The country code shall be based on the three-character uppercase alphabetic ISO 3166 country code (e.g., USA, FRA). The national segment field consists of two subfields: the ITU carrier code (ICC) followed by a unique access point code (UAPC). The ITU carrier code is a code assigned to a network operator/service provider, maintained by the ITU-T Telecommunication Standardization Bureau (TSB) as per [ITU-T M.1400]. This code shall consist of 1-6 left-justified characters, alphabetic, or leading alphabetic with trailing numeric.

50 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • Use case 1g: Unconstrained PHOTONIC_MEDIA/OTSiMC over MC Service Provisioning
  • Ramon Casellas has not found any example of more distinct roots in the same POST.
  • The use case 1g is discussed again, below the reached agreements:
    1. TAPI 2.1.3, the use case 1g is supported but without the creation of any subordinate ConnectivityService.
      1. This because the creation of server MCA ConnectivityService leads to many issues in TAPI 2.1.3 (conflict/redundancy between MCA CSEPs, provisioning of MCA ConnectivityService UUID, missing relationship between ConnectivityServices).
      2. The server layer constraints are specified through "option 2" model, i.e. the OTSiMCA ConnectivityService is provisioned together with contained/composed 4 CSEPs, two of them with MCA related constraints (MC spectrum(s)). These two server MCA CSEPs are referred by their client OTSiMCA CSEPs through server-connectivity-service-end-point, with connectivity-service-uuid = the UUID of creating OTSiMCA ConnectivityService and connectivity-service-end-point-local-id = local id of creating server MCA CSEPs:
        | | +--rw server-connectivity-service-end-point
        | | | +--rw connectivity-service-uuid? -> /tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/uuid
        | | | +--rw connectivity-service-end-point-local-id? -> /tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/end-point/local-id
      3. Note that TAPI 2.1.3 does not support OTSiMCA specific class augmenting CSEP. It is so reused the McaConnectivityServiceEndPointSpec, augmenting the CSEP with layerProtocolQualifier = OTSiMCA. It is so possible to specify the OTSiMC spectrum(s), through MediaChannelConfigPac(s).
    2. TAPI 2.1.3, the MCA ConnectivityService appears only in bottom-up provisioning, i.e. when explicitly created before of any possible future client OTSiMCA ConnectivityService.
      1. Recalled that the automatic creation of server ConnectivityServices has been discussed (and foreseen) during the development of R!A 1.0 - but without any specific input constraint regarding its layer.
  • Initial scenario:

  • Final scenario:

80 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • Use case 1h: Unconstrained asymmetric DSR Service Provisioning, UNI DSR E-NNI OTUk grey interface
  • Discussion on the ENNI, preliminary agreement that it is ODU, represented by an ODU SIP.
    • This SIP has "ODU" as server-most layer ("OTN" would be a better term than "ODU"), and a list of potentially supported client layers, local ones (ODU4) and network ones (ODU2, DSR 10GE, etc.)
    • To be agreed a better convention to associate layers to NEPs and CEPs in the pictures. Currently there is a mix between Layer Protocol Name and Layer Protocol Qualifier.
  • Discussion on the ENNI CSEP, whether it is DSR OTU or ODU.
    • Andrea Mazzinito provide figures spanning initial to final states of the DSR asymmetric provisioning scenario.