Skip to main content

Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes
RFC 5170

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from rmt-chairs@ietf.org, draft-ietf-rmt-bb-fec-ldpc@ietf.org to (None)
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2012-04-05
(System) Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to RFC 5170
2010-03-18
(System) Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to RFC 5170
2009-09-08
(System) Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to RFC 5170
2008-06-12
08 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2008-06-12
08 Amy Vezza [Note]: 'RFC 5170' added by Amy Vezza
2008-06-11
08 (System) RFC published
2008-03-12
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-02-29
08 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2008-02-29
08 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2008-02-29
08 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-02-28
08 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-02-28
08 (System) IANA Action state changed to In Progress
2008-02-28
08 Amy Vezza IESG state changed to Approved-announcement sent
2008-02-28
08 Amy Vezza IESG has approved the document
2008-02-28
08 Amy Vezza Closed "Approve" ballot
2008-02-28
08 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2008-01-28
08 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2008-01-23
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-01-23
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-01-23
08 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-08.txt
2007-12-14
(System) Posted related IPR disclosure: Digital Fountain, Inc.'s Statement about IPR related to draft-ietf-rmt-bb-fec-ldpc-07
2007-11-30
08 (System) Removed from agenda for telechat - 2007-11-29
2007-11-29
08 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2007-11-29
08 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2007-11-29
08 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman
2007-11-29
08 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-11-29
08 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-11-29
08 Chris Newman
[Ballot comment]
I'm not happy publishing code that fails to check the return
value of malloc() in a standard.  I recommend either explicitly stating
such …
[Ballot comment]
I'm not happy publishing code that fails to check the return
value of malloc() in a standard.  I recommend either explicitly stating
such checks are omitted for clarity of examples, or put them in.
2007-11-29
08 Chris Newman
[Ballot discuss]
The document needs a normative reference for base64 as used in section 4.2.4.2.

It could be to the XML schema document, or to …
[Ballot discuss]
The document needs a normative reference for base64 as used in section 4.2.4.2.

It could be to the XML schema document, or to RFC 4648.
2007-11-29
08 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2007-11-29
08 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-11-28
08 Tim Polk
[Ballot comment]
The authors should be commended for the great improvement in the Security Considerations
section between draft -06 and -07.  The current text is …
[Ballot comment]
The authors should be commended for the great improvement in the Security Considerations
section between draft -06 and -07.  The current text is probably *too* prescriptive, given that
the broad applicability of the LDPC staircase and triangle FECs.  I can not in good conscience
block this document for being too perscriptive, since the changes were a vigorous response to
a secdir review of the fec-rs draft, but I do believe that the points Steve Kent raised in his
re-review of that document should be addressed.  I have appended his re-review comments
below.

--- re-review comments on fec-rs section 9 (security considerations), which are identical to
section 8 of this draft  ---

I appreciate the efforts of the authors to make this section more precise and technically accurate.  However, in retrospect, I wonder if a document that is so broad in its scope of applicability (it contains no normative references to ANY specific protocols for multicast content distribution) ought to make statements about requirements for specific security mechanisms. I think it might be appropriate to remove the MAYs and SHOULDs from this section, and just cite examples of relevant IETF standards that are probably appropriate for use in this context. Also, the authors need not assume the burden of making security recommendations for all multicast content distribution schemes.  They should focus only on the need for such security relative to use of FEC. This is what they sate in the intro to section 9, but the text that follows tends to ignore this statement in most instances.

Section 9.2.1

        IPsec is misspelled.

        The use of "access control" here seems a bit odd.  We usually say that encryption is employed to provide confidentiality for objects during transmission (or in storage).  We say that access control is afforded to objects in storage, or to machines or networks. Finally, since the focus of this document is use of FEC in a multicast context, this section should refer to MSEC documents that describe use of IPsec confidentiality in that context, not just RFC 4303, if the section is retained.

        I think this subsection should be removed, or substantially reduced in size, since the authors note that there appear to be no confidentiality implications of using FEC in this context.

Section 9.2.2

        the discussion of object-level integrity and authentication discusses PKCS #1. I think that a reference to RFC 3852 (CMS) would be more appropriate, as it is standards track while PKCS #1 is Informational.  Also I question the use of MAY here, given the overall flavor of this document, and the lack of a similar requirements statement for any of the other alternatives presented in this subsection.

        The discussion of ECC use needs to be improved. First, it is not clear that ECC is fast enough and imposes low enough overhead to make it an acceptable per-packet solution in all contexts, contrary to what the text here suggests.  Also, the comments about ECC patent claims should be softened (and the phrase "proprietary patents" is poor English).

        TESLA may be fine in some contexts, but here too the authors seem to endorse it too broadly, given the very general nature of the multicast content distribution contexts where the FEC technology might be employed. Soften the text a bit here as well.

        The very brief discussion of key management here is probably not worth including, since it is bereft of any citations to relevant IETF standards.

        Since IETF specs like this are oriented toward protocol developers, the following statement seems odd: "It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate."  Just refer to the content distribution  protocol developers, not users or "deployers."

Section 9.3

        The recommendation for use of an XML signature to protect FEC OTI when it is carried in an FDT Instance makes sense, given that this data structure is an XML construct. If FEC OTI is sent out-of-band, then the corresponding recommendation should be more specific, e.g., to use CMS, rather than just saying "digitally signing it."
2007-11-28
08 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2007-11-28
08 Russ Housley
[Ballot discuss]
The document Introduction says:
  >
  > A publicly available reference implementation of these codes is
  > available and distributed under …
[Ballot discuss]
The document Introduction says:
  >
  > A publicly available reference implementation of these codes is
  > available and distributed under a GNU/LGPL license [LDPC-codec].
  > Besides, the code extracts included in this document (except
  > Appendix A that is only provided as an example) are directly
  > contributed to the IETF process by the authors of this document and
  > by Radford M. Neal.
  >
  However, the code in Appendix A mentions another author, Robin Whittle.
  We either need a similar contribution from this author or we need to
  remove the code that was written by this author.
2007-11-28
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to Discuss from No Objection by Russ Housley
2007-11-28
08 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2007-11-27
08 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-11-27
08 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2007-11-27
08 Jari Arkko
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, …
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place. The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts. I would have included the type declarations for the loop variables or complete functions, however. Or added an explicit warning where this is not convenient.

Finally, code appears within the text and its hard to determine whether it is normative or informative, except for the appendix which is informative.
2007-11-27
08 Jari Arkko
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, …
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place. The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts, perhaps even some simplification that the authors did to the code. I would have included the type declarations for the loop variables.

Finally, code appears within the text and its hard to determine whether it is normative or informative, except for the appendix which is informative.
2007-11-27
08 Jari Arkko
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, …
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place.
The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts, perhaps even some simplification that the authors did to the code. I would have included the type declarations for the loop variables.

Finally, code appears within the text and its hard to determine whether it is normative or informative.
2007-11-27
08 Jari Arkko
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, …
[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place.
The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts, perhaps even some simplification that the authors did to the code.

Finally, code appears within the text and its hard to determine whether it is normative or informative.
2007-11-27
08 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2007-11-27
08 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2007-11-27
08 Russ Housley
[Ballot discuss]
Based on the Gen-ART Review by Brian Carpenter.

  Section 4.2.3 includes the following:
  >
  > o  PRNG seed: the seed …
[Ballot discuss]
Based on the Gen-ART Review by Brian Carpenter.

  Section 4.2.3 includes the following:
  >
  > o  PRNG seed: the seed is a 32 bit unsigned integer between 1 and
  >    0x7FFFFFFE (i.e. 2^^31-2) inclusive.  This value is used to
  >    initialize the Pseudo Random Number Generator (Section 5.6).  This
  >    element is optional.  Whether or not it is present in the FEC OTI
  >    is signaled in the associated encoding format through an
  >    appropriate mechanism (Section 4.2.4).  When the PRNG seed is not
  >    carried within the FEC OTI, it is assumed that encoder and
  >    decoders use another way to communicate the information, or use a
  >    fixed, predefined value.
  >
  I understand the desire for optional transmission of the seed to save
  32 bits when this FEC OTI is carried within an EXT_FTI header extension.
  There is a risk that independent developers use different seed values
  when the value is carried out-of-band.  Solving this concern requires
  a "MUST implement and MUST configure" (rather than "MUST implement and
  MAY configure").  A default value is another possible consideration.

  There are code extracts in the document, and the Introduction says:
  >
  > A publicly available reference implementation of these codes is
  > available and distributed under a GNU/LGPL license [8].
  >
  It would be desirable to add an explicit statement that the code
  extracts in the document are directly contributed to the IETF process
  by their authors (i.e., they are are not subject to LGPL).  To this
  end, the authors have proposed:
  >
  > The code extracts in this document are directly contributed to the
  > IETF process by their authors, unless otherwise mentionned.
  >
  The document authors don't own the copyright of all of the source code,
  and therefore cannot contribute it to the IETF process. This is the
  case for Pseudo Random Number Generator in Section 5.6 and the Parity
  Check Matrix Creation in Section 6.2.  The origin of this source code
  is clearly stated.  There has been a huge amount of discussion about
  source code in RFCs, and it is not clear that the rights offered are
  adequate for a standards track RFC.
2007-11-27
08 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2007-11-27
08 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-11-20
08 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2007-11-20
08 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2007-11-20
08 Magnus Westerlund Created "Approve" ballot
2007-11-20
08 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Magnus Westerlund
2007-11-20
08 Magnus Westerlund Placed on agenda for telechat - 2007-11-29 by Magnus Westerlund
2007-11-16
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-11-16
07 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-07.txt
2007-10-23
08 Magnus Westerlund State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Magnus Westerlund
2007-10-22
08 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2007-10-18
08 Amanda Baber
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Reliable Multicast Transport (RMT) FEC
Encoding IDs …
IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Reliable Multicast Transport (RMT) FEC
Encoding IDs and FEC Instance IDs - per [RFC5052]" registry located
at
http://www.iana.org/assignments/rmt-fec-parameters
sub-registry "ietf:rmt:fec:encoding"

Value| Description | Reference
-----+ ---------------------------+---------
3 | LDPC Staircase Codes | [RFC-rmt-bb-fec-ldpc-06]
4 | LDPC Triangle Codes | [RFC-rmt-bb-fec-ldpc-06]

We understand the above to be the only IANA Action for this document.
2007-10-09
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Nicolas Williams
2007-10-09
08 Samuel Weiler Request for Last Call review by SECDIR is assigned to Nicolas Williams
2007-10-08
08 Amy Vezza Last call sent
2007-10-08
08 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-10-08
08 Magnus Westerlund State Changes to Last Call Requested from Publication Requested by Magnus Westerlund
2007-10-08
08 Magnus Westerlund Last Call was requested by Magnus Westerlund
2007-10-08
08 (System) Ballot writeup text was added
2007-10-08
08 (System) Last call text was added
2007-10-08
08 (System) Ballot approval text was added
2007-10-08
08 Magnus Westerlund State Changes to Publication Requested from AD is watching by Magnus Westerlund
2007-10-08
08 Magnus Westerlund Intended Status has been changed to Proposed Standard from Experimental
2007-09-21
08 Magnus Westerlund State Changes to AD is watching from AD Evaluation by Magnus Westerlund
2007-09-21
08 Magnus Westerlund Review and ready for WG last call, however awaiting resolution on intended status before progressing.
2007-09-20
08 Magnus Westerlund State Changes to AD Evaluation from Publication Requested by Magnus Westerlund
2007-09-10
08 Magnus Westerlund
Technical Summary

    This document is an optional Building Block usable to fully define
    an RMT Transport Protocol.  It fully-specifies Low Density …
Technical Summary

    This document is an optional Building Block usable to fully define
    an RMT Transport Protocol.  It fully-specifies Low Density Parity
    Check (LDPC) Forward Error Correction (FEC) Codes within the guidelines
    of draft-ietf-rmt-fec-bb-revised. It also specifies procedures and
    packet-header fields, as required by draft-ietf-rmt-fec-bb-revised.

    The combination of this document and draft-ietf-rmt-fec-bb-revised
    allows the implementation of an interoperable Forward Error Correction
    scheme usable in the context of an RMT transport protocol (e.g.
    LCT/ALC or NORM).
   
    LDPC FEC codes generate parity symbols using a sparse set of source
    symbols.  The LDPC codes described in this document belong to the class of
    large block codes, which means they can easily operate on blocks that are
    composed of a huge number of source symbols.  For bulky information content,
    this is a great advantage over similar small-block FEC codes, like the popular
    Reed-Solomon codes, that can also work over a packet erasure channel.
Working Group Summary

    There is consensus in the WG to publish these documents.

Document Quality

    The authors have a working, open source implementation of the FEC algorithms
    this document describes.  The FEC implementation has been used in working
    RMT protocol code.

Brian Adamson is the Document Shepherd.
Magnus Westerlund is the Responsible Area Director.
2007-09-10
08 Magnus Westerlund Draft Added by Magnus Westerlund in state Publication Requested
2007-05-07
06 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-06.txt
2007-03-29
05 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-05.txt
2006-12-27
04 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-04.txt
2006-07-18
03 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-03.txt
2006-06-22
02 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-02.txt
2006-03-02
01 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-01.txt
2005-10-12
(System) Posted related IPR disclosure: Digital Fountain, Inc.'s statement about IPR claimed in draft-ietf-rmt-bb-fec-ldpc-00.txt
2005-10-11
00 (System) New version available: draft-ietf-rmt-bb-fec-ldpc-00.txt