Relationship between OTSiG and tunnel identifiers

[sergiobelotti]

How is the relationship between OTSi group identifier and tunnel identifiers ? The optical tributary signal group (OTSiG) is a management/control abstraction that represents a group of one or more OTSi that carry the characteristic information (CI) of one client. This management control entity is used to group the modulated signal represented by OTSi as co-routed. OTSiG identifier is an output of path computation and tunnel setup and need to have a reference to related tunnel identifier supporting the connection used to carry the client mapped onto 1 or more OTSi .

Imported from https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/87

[danielkinguk]

Need to provide a section on OTSiG, which includes:

• OTSIG usage (maybe references as needed)
• Relationship with Media Channel
• Path Computation requirements, referring to PC model

[agva123]

New text proposal:

OTSiG is a management construct that represents a group of optical tributary signals (OTSi) each characterized by their central frequency and an application identifier. When present, the frequency slots of the OTSis within an OTSiG are allocated and are usually co-routed to the destination.

An OTSiG may be configured by management operations or automatic operations through control plane or SDN controller. When configurating a flex-grid tunnel from an SDN controller, the controller shall be responsible for driving the creation of the corresponding OTSiGs in the management system.

When computing path for a flex-grid tunnel, a path computation server may assign an appropriate network-unique OTSiG identifier along with local OTSi identifiers (unique within the scope of the OTSiG) and return this information as part of the computed path properties. <<

[danielkinguk]

Dan to review text and include in main document.

[aguoietf]

2023-12-14: There is one OTSiG per direction between the transmitter and receiver. For an e2e tunnel without regenerators, there will be two OTSiGs (one per direction) For a tunnel with N regenerators, there will be a total of 2*(N+1) OTSiGs

Both OTSi and OTSiG identifiers are needed to navigate between tunnel and OI topology. We need to report both OTSi and OTSiG identifiers in the tunnel model.

[aguoietf]

Modeling the relationship between an LSP and OTSi/OTSiG/MC/MCG:

//Q: Are MCs / MCGs preconfigured or created along with TE LSP? //Q: Do we use the same MCs / MCGs configuration on each hop end to end? //What about label-hop?

  augment /te:te/te:lsps/te:lsp/te:lsp-actual-route-information:
    +--ro wdm-path-state
    |  +--ro gsnr?   l0-types:snr
    ***
    //LSP --1:N-- E2E-MC-Path
    +--ro e2e-mc-path-id*    uint16
    ***

  augment /te:te/te:lsps/te:lsp/te:lsp-actual-route-information
            /te:lsp-actual-route-information/te:type
            /te:numbered-node-hop/te:numbered-node-hop:
    +--ro path-in-transceiver
    |  +--ro transponder-id?   uint32
    |  +--ro transceivers* [lane-id]
    |     +--ro lane-id             uint8
    |     +--ro transceiver-id?     uint32
    |     +--ro rx-channel-power?   power-dbm-or-null
    |     +--ro rx-total-power?     power-dbm-or-null
    *** 
    |     +--ro otsi-group-id?    string
    |     +--ro otsi-carrier-id?  uint16
    ***     
    +--ro path-out-transceiver
    |  +--ro transponder-id?   uint32
    |  +--ro transceivers* [lane-id]
    |     +--ro lane-id             uint8
    |     +--ro transceiver-id?     uint32
    |     +--ro rx-channel-power?   power-dbm-or-null
    |     +--ro rx-total-power?     power-dbm-or-null
    *** 
    |     +--ro otsi-group-id?    string
    |     +--ro otsi-carrier-id?  uint16
    ***     

  ***
  augment /te:te/te:lsps/te:lsp/te:lsp-actual-route-information
            /te:lsp-actual-route-information/te:type
            /te:numbered-link-hop/te:numbered-link-hop:
    +--ro media-channel-group
       +--ro media-channels* []
          +--ro flexi-n?          l0-types:flexi-n
          +--ro flexi-m?          l0-types:flexi-m
          +--ro otsi* []
             +--ro otsi-group-id?     string
             +--ro otsi-carrier-id?   uint16

  augment /te:te/te:lsps/te:lsp/te:lsp-actual-route-information
            /te:lsp-actual-route-information/te:type
            /te:unnumbered-link-hop/te:unnumbered-link-hop:
    +--ro media-channel-group
       +--ro media-channels* []
          +--ro flexi-n?          l0-types:flexi-n
          +--ro flexi-m?          l0-types:flexi-m
          +--ro otsi* []
             +--ro otsi-group-id?     string
             +--ro otsi-carrier-id?   uint16
  ***

[aguoietf]

Meeting minutes on 2024-05-16:

We discussed the relationship between the lsp-id and e2e-mc-path-id.

It was shown that in the existence of 3R regens on none of the path, only on one (working/protection) path, or on both working and protection paths, there are 2, 3 or 4 e2e-mc-path-ids, respectively, and there are also 1, 1, 2 OTSis, respectively.

It was shown that the number of LSPs per WDM tunnel is implementation specific depending on whether the LSP is contiguous or stitching based on RFC5150 and RFC5151.

Therefore, it was agreed that therefore there does not exist a single 1:1 mapping between the lsp-id and e2e-mc-path-id. The best way to move forward is to add a mapping of lsp-id to e2e-mc-path-id on the LSP reporting in the WDM tunnel model.

It was agreed that the mapping should be contained within each link hop of an lsp. One LSP link hop can be mapped to more than one e2e-mc-path-id. The YANG model should be updated accordingly.