Need to align FEC identities

[italobusi]

The following identities were defined in layer0-types and removed from layer0-types during WG LC with the intention to further develop their definitions in the layer0-types-ext:

  identity fec-type {
    description
      "FEC (Forward Error Correction) type";
    reference
      "ITU-T G.709: Interfaces for the Optical Transport Network";
  }

  identity g-fec {
    base fec-type;
    description
      "G-FEC (Generic-FEC)";
  }
  identity e-fec {
    base fec-type;
    description
      "E-FEC (Enhanced-FEC)";
  }
  identity no-fec {
    base fec-type;
    description
      "No FEC";
  }

It seems that the identity fec-type may complement the the identity FEC already defined in the layer0-types-ext.

These two definitions need to be reconciled.

Co-authored-by: sergiobelotti sergio.belotti@nokia.com

[italobusi]

This fec-type identity is used in the WSON tunnel and Flexi-Grid Media Channel models

[italobusi]

@sergiobelotti @italobusi : update the name of layer0-bandwidth-type as otu-type @ggalimba56 @egriseri : to provide a list of needed FEC type @sergiobelotti @italobusi : based on the list provided in the previous AP, update YANG accordingly

Originally posted by @italobusi in https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/issues/17#issuecomment-775929831

[sergiobelotti]

This is the direct translation into YANG code of the list coming from Enrico/Gabriele proposal identity fec-type { description "Base identity from which specific FEC (Forward Error Correction) type identities are derived."; } identity rs-255-239-fec { base fec-type; description "Reed-Solomon FEC. See RFC5510 for the definition of 255 and 239"; reference "ITU-T G.709 v6.0 (06/2020):Interfaces for the Optical Transport Network (OTN)

  ITU-T G.975 v2.0 (10/2000):Forward error correction for
  submarine systems

  IETF RFC5510";  

} identity rs-528-514-fec { base fec-type; description "Reed-Solomon FEC"; } identity sc-fec { base fec-type; description "Staircase FEC"; reference "ITU-T G.709.2 v1.1 (09/2020):OTU4 long-reach interface"; }

identity o-fec { base fec-type; description "Open FEC as defined by OpenROADM forum"; }

identity c-fec { base fec-type; description "Concatenated FEC (C-FEC) that combines a HDFEC (255,239) outer code and an inner double-extended SD-FEC (128,119) Hamming code"; }

Comments:

• c-fec: it is coming form OIF ZR/ZR+ IA , and we need to make reference the correct document and version
• o-fec: it is coming from OpenROADM forum. Since the forum is a "closed" forum and not all the vendors have access in the documentation, do we need to find a standard reference for that or leave out of our model ?

[egriseri]

Hi all, reference for rs-255-239-fec may be ITU-T G.709/Y.1331 (06/2020) Annex A. reference for c-FEC may be OIF-400ZR-01.0 - not sure description above is complete OIF doc reports:

The 400ZR Forward Error Correction (FEC) algorithm is a Concatenated FEC (C-FEC) that combines a HDFEC (255,239) outer code and an inner double-extended SD-FEC (128,119) Hamming code resulting in ~10.8dB of NCG with ~14.8% overhead (e.g. BER_in = 1.25E-2 results in BER_out = 1.0E-15). The HD-FEC is a (512-bit × 510-bit) generalized staircase code that works in conjunction with an error decorrelator. The error de-correlator function randomizes the position of the symbols to reduce the impact of correlated errors on the FEC performance.

I have no idea if o-FEC as defined in OpenROADM is standardized somewhere else.

[italobusi]

I have checked with Maarten the current FEC definitions in ITU-T and found that:

• SC-FEC is defined in Annex A/G.709.2
• oFEC is defined in clause 16.4.4/G.709.3 and reuses the BCH FEC defined in Annex E/G.709.3
• C-FEC is defined as the concatenation of an outer SC-FEC, defined in Annex A/G.709.2, with an inner Hamming SD-FEC, defined in Annex D/G.709.3. More details are provided in clause 15/G.709.3 where it is called DSH instead of concatenated FEC
• RS (255, 239) is defined in Annex A/G.709, with 16-byte interleaved codecs:
  • 16 sub-rows using byte-interleaving
  • it is applicable only for OTUk
• RS (544, 514) in multiple ways: 1) Annex A/G.709.1 as well as in clause 119 of IEEE 802.3bs, with 10-bit interleaved codes:
  • 2 sub-rows using 10-bit interleaving
  • the G.709.1 definition is applicable only to FlexO-x-RS (x = 2,4)
  • the IEEE 802.3bs definition is applicable only to 200GBASE-R and 400GBASE-R interfaces 2) clause 11.5/G.709.1 as well as in Annex A/G.709.4 as well as in clause 91.5.2.7 of IEEE 802.3, without interleaving
  • one row of 544 10-bit blocks
  • the G.709.1 definition is applicable only to FlexO-1-RS
  • the G.709.4 definition is applicable only to OTU-RS
  • the IEEE 802.3 definition is applicable only to <<to be checked in IEEE specification (100GBASE-KP4)>>
• RS (528, 514) is defined in Annex C/G.709.4 as well as in clause 91.5.2.7 of IEEE 802.3, without interleaving
  • one row of 528 10-bit blocks
  • the G.709.4 definition is applicable only to OTU-RS
  • the IEEE 802.3 definition is applicable only to <>

It seems to me that:

• there is some relationship between the FEC definition and the digital client signal, how to model it?
• RS fec types need more than two parameters to be distinguished:
  • should we distinguish the length of the codeword (byte versus 10-bit) or keep it implicit in the definition?
  • how to model the different interleaving, especially for RS (544, 514)?

For the RS (n, k) convention, there is a good description of n and k also in clause 11.5/G.709.1:

• n represents the total number of symbols in a FEC row

• k represent the number of data information symbols in a FEC row

[egriseri]

Sergio, Dieter and me met together and we propose to focus only on FEC definition that are actually used for line transmission. Some of codes above reported above look as they are used only for client connection, that are out of the scope of the current model. For sure the following ones are used in line interfaces:

• SC-FEC
• oFEC
• C-FEC We need to investigate further what's the application of the other ones.

[sergiobelotti]

02-05-23 weekly call there is agreement to use just the FEC listed above but we need to check YANG before to close the issue

Sergio, Dieter and me met together and we propose to focus only on FEC definition that are actually used for line transmission. Some of codes above reported above look as they are used only for client connection, that are out of the scope of the current model. For sure the following ones are used in line interfaces:

• SC-FEC
• oFEC
• C-FEC We need to investigate further what's the application of the other ones.

weekly call 02-05-23

There is agreement to use these FEC types only , but before to close the issue we need to verify YANG if these FEC types are already there.

[sergiobelotti]

@all I checked the YANG file and I can confirm that the definitions of these type of FEC are not yet there so we need to add these definition in YANG. My proposal is considered close the issue and put the label that the issue will be offically cloese with the new YANG update (next PR). Do you agree?

[sergiobelotti]

weekly call 06-06-23

To close the issue, in addition to the introduction of the new FEC:

• SC-FEC

• identity sc-fec { base fec-type; description "Staircase FEC"; reference "ITU-T Annex A/G.709.2 v1.1 (09/2020):OTU4 long-reach interface"; }

• oFEC identity o-fec { base fec-type; description "Open FEC as defined by OpenROADM forum"; reference "ITU-T clause 16.4.4/G.709.3 and reuses the BCH FEC defined in ITU-T Annex E/G.709.3"; }

• C-FEC identity c-fec { base fec-type; description "Concatenated FEC (C-FEC) that combines an outer SC-FEC outer code and an inner double-extended SD-FEC (128,119) Hamming code"; reference "outer SC-FEC, defined in Annex A/G.709.2, with an inner Hamming SD-FEC, defined in Annex D/G.709.3. More details are provided in clause 15/G.709.3 where it is called DSH instead of concatenated FEC }

we need to change enhanced-FEC with Super-FEC, and add the reference to ITU- Rec. :

identity g-fec { base fec-type; description "G-FEC (Generic-FEC)"; reference "ITU-T G.975"; } identity super-fec { base fec-type; description "S-FEC (Super-FEC)"; reference "ITU-T G.975.1"; }

[egriseri]

Agree!