FLUTE v1 (RFC 3926) and MBMS Download Profile conformance, plus assorted correctness fixes

[jordijoangimenez]

Closes #70, closes #71, closes #72, closes #73, closes #74, closes #75, closes #76, closes #82, closes #83, closes #85, closes #96, closes #97, closes #109, closes #27.

For reviewers: what changed since you last looked

Ignore the branch name. It is a historical artifact and describes nothing in this pull request. It
reads feature/wave3-rfc6726-compliance-fixes: "wave3" was internal shorthand that means nothing outside
our own notes, and RFC 6726 is FLUTE version 2, which this branch does not implement and never should
have claimed. What is actually here is FLUTE version 1 (RFC 3926) and the MBMS Download Profile of
TS 26.346 annex L, which is what the title and the sections below describe. The name stays only because
renaming the head branch of an open pull request closes it, and closing this one would discard the review
history on it. It will be renamed after merge.

The review comments on this pull request have all been acted on:

• @davidjwbbc, "this library needs to support FLUTE v1 for compliance with 3GPP specifications. Please
  do not make changes that remove FLUTE v1 compliance." Done. All FLUTE version 2 material is out of this
  branch and lives in FLUTE version 2 (RFC 6726) signalling, off by default: step one of three, no conformance claimed #65, which is deliberately non-default and claims no conformance. TS 26.517
  clause 6.2.1 points at TS 26.346 annex L, which is scoped to RFC 3926 throughout, so version 1 is the
  only thing this branch implements.
• @rjb1000, "the RFC references should be RFC 3926 and, for the corresponding LCT v1, RFC 3451." Done,
  and more thoroughly than at the time: fourteen citations in the code were corrected from the
  RFC 6726/5651/5775 generation to RFC 3926/3450/3451, and two commit messages that still named the wrong
  generation were corrected since. Where a rule genuinely exists only in the later document, the commit now
  says so rather than implying a version 1 obligation: RFC 3926 states no constraint on reusing an FDT
  Instance ID, so that rule is cited to RFC 6726 and adopted as sound practice, not as a requirement.
• @rjb1000, "it would be better to integrate the correct scope into the main issue description to avoid
  confusing future readers." Done. The scope is in the title and in this description, not in a trailing
  comment.
• @rjb1000 on Tunnel-mode reception, and five object-handling fixes (compression, partitioning, transfer length) #68, "PR Feature/end to end test tunneled mode #56 and PR Fix unbounded FDT growth (same-TOI resend, and content-change cases) #60 are merged now, so this PR needs to be rebased." Done here too:
  this branch is rebased onto current development, which includes Feature/end to end test tunneled mode #56, Fix unbounded FDT growth (same-TOI resend, and content-change cases) #60 and Bug-fix: Fix incorrect function call during FLUTE object compression #69.
• @dsilhavy, "can you convert them to draft pull requests" and "can you recommend an order in which we
  should review the pull requests." All five are drafts, and the order is at the end of this description.

What was checked before asking you to look again

• Every defect claimed here was verified present on development by reading the code, not inferred from
  a report or a note.
• Every quotation in the commits was checked verbatim against the specification text, and every clause
  number was checked separately by finding the quoted sentence and reading back to its enclosing heading.
  The clause number is the part a quotation checker cannot verify, and two locators were wrong until that
  pass caught them.
• The tier and evidence are stated per claim: T1 with case counts, T2 with wire captures taken by a
  sniffer that links none of this library's code.

Four commits added after the review comments above

These are later than everything described above, so they carry no review history yet.

Commit	What
f7c9cf5	Comment only. The Transfer-Length suppression was justified by a comment claiming "Nothing is lost on the wire either: the receive path falls back to Content-Length when the attribute is absent". That holds only for an object with no content encoding, so it asserted a safety property the code did not have.
151484c	File::adopt_fdt_metadata() now takes content_encoding and content_length from the FDT entry. Without them an object whose reception was bootstrapped from a content packet's own EXT_FTI was delivered still encoded, and where the FDT carried Content-MD5 the digest was compared against the encoded buffer, failed, reset every symbol and never completed. This completes the adoption path of #74.
c21ecb5	With a UDP tunnel endpoint configured, both send sites issued a plain datagram to the announced destination as well as the encapsulated copy, so every packet left twice. Closes #109.
50cd7ec	Transmitter::send() declines content encoding under either 3GPP profile rather than emit an object whose transfer length cannot be stated.

On the last two, the authority.

TS 23.247 V18.8.0, clause 7.3.1, step 13: "The AF starts transmitting the DL media stream to MB-UPF using the N6mb Tunnel, or optionally un-tunnelled i.e. as an IP multicast stream using the HL MC address."

One carriage or the other, so the direct copy had no consumer: the announced destination is reached by decapsulation at the far end. A receiver that wants to join it directly is served by not configuring a tunnel.

For 50cd7ec, both carriers for an encoded object's transfer length are closed to a profiled sender. Annex L.4.4 forbids the FDT attribute, listing Transfer-Length first under "The following attributes shall not be carried in the FDT sent by the FLUTE sender:", and the in-band route is closed by

TS 26.346 V18.2.0, clause 7.2.8: "FLUTE packets carrying symbols of files (not FDT Instances) shall not include an EXT_FTI."

Content-Length cannot substitute for an encoded object, per RFC 3926 clause 3.4.2. Declining to encode is conformant because annex L.4.2 leaves the encoding to the sender, and the sender refuses rather than silently sending the object uncompressed, so a caller is not left believing the encoding was applied. The contradiction between that permission and the two prohibitions is not resolved here. It is 3GPP's to make and is raised as 5G-MAG/Standards#212.

That guard previously existed only on #68. Without it here, this branch on its own had a reachable path that emits an object no conformant receiver can size, which would have reached development ahead of its fix.

Verification. Suite 79 cases, all passing, three of them added by these commits. Each new case was checked against the previous behaviour and fails there: the adoption case reports a decoded length of 38 against the 4096 expected, the carriage case sees the direct datagram arrive immediately, and the refusal case sees the send accepted. No T2 evidence for the carriage change: it rests on counting what leaves the Transmitter through two real sockets, and a live re-measure against a broadcast run is offered but not yet done.

Consequence for the branches stacked on this one. #68 carries its own copies of the adopt_fdt_metadata change and of the content-encoding guard. Both will conflict or go empty when it rebases onto this branch; resolve in favour of the copies here, the defects being introduced at this layer.

Dependencies and issues

Depends on: nothing in this repository. This is the base of the set and merges first.
Blocks: #61, #64, #65, #68 and #98, all of which build on it.
Closes on merge: #70, #71, #72, #73, #74, #75, #76, #82, #83, #85, #96, #97, #109, #27.

Cross-repository impact. Four repositories in the organisation vendor rt-libflute. None of them
is source-broken by this, which I checked rather than assumed after first claiming otherwise.

Paired with: nothing. No other repository has to change for this to merge.

rt-mbs-transport-function: compiles unchanged, one redundancy left behind. It passes
FileDeliveryTable::FDT_NS_3GPP_CONSOLIDATED_V2 explicitly in ObjectCarouselPackager.cc and
ObjectListPackager.cc, and references no Profile:: value anywhere. That enum constant still exists,
and the default profile Profile::Ts26517 now derives the same schema, so the argument is overridden
to exactly the value it already asked for. Behaviour is identical. The argument and the comment above
it are now redundant, and the comment is mildly misleading because it implies the caller chooses the
schema.

Do not simplify them before this merges. Dropping the argument to FDT_NS_NONE is only correct
against a library that has this change. Against the version MBSTF's subproject currently pins, which
predates it, FDT_NS_NONE means no namespace at all, so the tidy-up would make the MBSTF emit a
namespace-less FDT. I tried it, found exactly that, and reverted. Leaving the explicit argument is
safe against both versions: the old library honours it and this one overrides it to the same value.
Worth doing once MBSTF's submodule has moved, not before.

rt-mbms-mw: compiles unchanged, behaviour changes. It constructs only the five-argument
LibFlute::Receiver. But this branch makes the receiver stop using an expired FDT Instance, per
TS 26.346 clause 7.2.9, where it previously kept using one indefinitely. A deployment whose sender
emits short Expires values will see reception behave differently. It tracks branch main, so nothing
reaches it until main is updated.

rt-mbs-client, rt-mbms-examples: no affected API found. Both vendor the library; neither references
the profile, the FDT namespace or the Transmitter constructor in the source scanned. That scan covered
the first sixty source files of each repository rather than the whole tree, so it is good evidence, not
proof.

What this is

The correctness and conformance baseline every other pull request in this set sits on, and the branch
each of them is based on. 32 commits, 19 files, 2,005 added lines. Three parts:

Part one, conformance. The library could not be operated so that its FDT conformed to the profile its
primary consumers are bound by, and its receive-side packet parse had four defects, two of them reachable
from a single unauthenticated datagram.

Issue	What it covers
#70	FDT emission under the profile: Transfer-Length withheld, Content-Encoding restricted to gzip, the profiled schema's mandatory schemaVersion emitted, the File Expires attribute separated from the Cache-Control directive
#71	FEC-OTI-FEC-Instance-ID no longer emitted for a Fully-Specified FEC scheme, guarded on the scheme rather than the profile, because it is equally wrong outside the profile
#72	header parse bounded by the datagram; a zero-length extension rejected instead of looping forever; Sender Current Time and Expected Residual Time counted in the header length instead of being walked as extensions; only FLUTE version 1 accepted in EXT_FDT
#73	TSI widened to the field RFC 3451 defines, refusing rather than truncating a value that will not fit; FDT Instance ID kept inside its 20-bit field, wrapping to zero as RFC 3926 clause 3.4.1 defines the sequence
#74	reception starts from a packet's own EXT_FTI when the FDT describing it has not arrived, instead of discarding the packet, and the file so started survives until the FDT gives it its metadata
#75	the FDT Complete attribute and the LCT Close Session and Close Object flags, on both sides, with a callback
#76	testing enabled in the top-level CMake file, so ctest runs the suite instead of reporting success having found nothing

Part two, correctness fixes that are not FEC and not tunnelling. These were buried inside the Raptor
branch and belong here, with general library correctness.

Issue	What it covers
#82	the send socket binds to the configured source address even when a tunnel is set, so the untunnelled copy a tunnelled session also sends leaves from the announced source and a receiver filtering on it sees the traffic
#83	the IPsec netlink socket is released instead of leaking a socket and descriptor on every call
#85	IPsec handles an IPv6 destination instead of mistranslating it into a nonsense IPv4 address, and IpSec.h gains the <cstdint> it had been getting transitively
#96	the ESP association carries an authentication algorithm as well as an encryption one, so a receiver can tell a sender's packet from a forged one
#97	the UDP tunnel send path builds an IPv6 header for an IPv6 destination instead of throwing, and the payload budget accounts for the header it writes
#27	the receiver example confines received files to the output directory, so a sender's Content-Location cannot decide where they are written

It also adds regression coverage for the FDT growth fixes merged in #60, which had none, and the read-only
Transmitter::fdt() accessor those tests need.

A profile flag decides which obligations apply, so a general FLUTE session keeps its previous behaviour
wherever plain RFC 3926 permits it. That flag is the mechanism the rest depends on, not a fix of its own.

Baseline

TS 26.346 V18.2.0, TS 26.517 V18.6.0, RFC 3926, RFC 3450, RFC 3451, RFC 5052, and RFC 6726 only where it
is the sole source for a rule. Each commit quotes the sentence it rests on. Note for reviewers who saw the
earlier version: the citations were corrected from the RFC 6726/5651/5775 generation to RFC 3926/3450/3451,
per @rjb1000's review.

Part three: the profile model, and the 3GPP mandatory sweep

Added after a clause-by-clause read of TS 26.346 clause 7.2, TS 26.346 annex L and TS 26.517 clause 6.2.
Scope was set deliberately at mandatory obligations of the 3GPP profiles only; "should" and "may"
items were assessed and left unimplemented, and the general-FLUTE RFC layer was not swept.

Profile now has three values, named after the governing documents. Only one of the three profiles
has a name in the specifications at all: annex L.4 is titled "MBMS Download Profile", TS 26.517's variant
is described in clause 6.2.1 only as that profile "with the additional requirements in clause 6.2 of the
present document", and plain FLUTE has no name because it is the absence of a profile. So the enum names
documents rather than inventing profile names.

Value	Governing clauses	FDT schema	schemaVersion
Ts26517 (default)	TS 26.517 cl.6.2, on TS 26.346 cl.7.2 + annex L.4	urn:3GPP:metadata:2022:FLUTE:FDT	2
Ts26346	TS 26.346 cl.7.2 + annex L.4	urn:IETF:metadata:2005:FLUTE:FDT	4
Unprofiled	RFC 3926 and the ALC/LCT documents beneath it	caller's choice	none

The profile now derives the FDT schema. It used to be an independent argument that could contradict
the profile, and a default-constructed 3GPP session emitted an FDT with no namespace at all,
conforming to neither schema.

Gaps closed by the sweep, each with its clause quoted at the code:

Clause	Was
7.2.10.1	schemaVersion 4 never emitted for the clause 7.2.10.1 schema
7.2.7	a TSI above 65535 widened rather than refused under a 3GPP profile
7.2.9	no ceiling enforced on FEC-OTI-Maximum-Source-Block-Length for Compact No-Code
7.2.9	an expired FDT Instance still used to interpret arriving packets, which is a shall not here where RFC 3926 says only SHOULD NOT
annex L	File@Expires not taking precedence over FDT@Expires
annex L.4	3GPP restrictions tested one profile where the clauses bind both

The profile is now a hard boundary. gzip, RaptorQ and FLUTE version 2 are each refused under a 3GPP
profile, naming the clause, and each remains available under Unprofiled. The gzip refusal is in #68 and
carries a specification contradiction; see that pull request and 5G-MAG/Standards#212.

Verification

T1: 67 cases passing on this branch. T2: the FDT captured off the wire by a sniffer that links no library code confirms
Transfer-Length and FEC-OTI-FEC-Instance-ID absent, File@Expires present and distinct from
FDT-Instance@Expires, and <schemaVersion>2</schemaVersion> correctly positioned for the profiled schema.

Where this leaves conformance

A clause-by-clause sweep was done alongside this work: TS 26.346 clause 7.2, TS 26.346 annex L and
TS 26.517 clause 6.2 read as prose, and RFC 3926, RFC 3450 and RFC 3451 swept by extracting all 182
MUST and SHALL statements with their clause. With this pull request and the four built on it:

Profile	Mandatory status
Ts26517	Complete
Ts26346	Complete
Unprofiled	Complete except congestion control, which is in #98 and unverified

Congestion control has been split out into #98 and is not in this pull request. It is the last
mandatory item for Unprofiled, it is written but unverified, and it closes no issue. Keeping it
here would have made this pull request 22 files and 3,417 lines, and would have forced a reviewer to
accept an unverified congestion controller alongside conformance fixes that are ready.

It does not affect the two 3GPP profiles either way: TS 26.346 clause 7.2.4 excludes congestion
control for MBMS download, which is exactly why this library's single channel with C=0 and a zero
CCI is conformant there.

Two limits on how far that sweep should be trusted. The RFCs were swept by extracting MUST and SHALL
rather than read as prose, so an obligation carried only in prose could have been missed. And "should"
and "may" items were assessed but deliberately not implemented. Both are recorded in the conformance
record rather than glossed over.

Merge order

This one first. Every other pull request in the set is based on this branch
(feature/wave3-rfc6726-compliance-fixes) rather than on development, so each of their diffs shows only
its own commits and no fix in this set is presented for review twice. GitHub retargets them to
development automatically as this merges.

Full order: this, then #61, then #64. #65 and #68 need only this one and can go in any order after it.

Known overlap

PR #84 fixes the same defect as #76, ctest at the build root discovering nothing. The commit here
(build: enable testing in the top-level list file so ctest sees the suite) predates it by five days and
sits in the base of this whole stack, so removing it means rewriting all five branches. #84's
include(CTest) is the more idiomatic one-liner. One of the two should be closed; whichever is kept,
please close the other rather than merging both, since they touch the same lines and will conflict. A note
to that effect has been left on #84.

Later additions

Two commits were added after the first review round, both from re-checking this branch against the
issues it closes rather than from new review comments.

• fdt: wrap the FDT Instance ID to 0, as RFC 3926 defines the sequence. The branch had implemented
  RFC 6726's rule, reusing the smallest expired identifier and throwing when none had expired. RFC 3926
  clause 3.4.1 states the sequence unconditionally and gives it no failure case, so a sender could refuse
  to continue in a situation the specification it implements does not treat as an error. Issue TSI is truncated to 16 bits, and the FDT Instance ID never wraps #73 and
  its description have been corrected the same way.
• receiver: keep a file bootstrapped from EXT_FTI when the FDT completes. The bootstrap Packets for a TOI are discarded when they arrive before the FDT that describes them #74 asks for
  was being undone: the replacement sweep that de-duplicates by Content-Location compared the
  bootstrapped file's empty placeholder against the FDT's own, and erased the bootstrapped file every
  time the FDT completed. Found by adding the coverage Packets for a TOI are discarded when they arrive before the FDT that describes them #74 had none of.
• ipsec: authenticate the ESP association as well as encrypting it, closing IPsec sets up an encryption-only ESP association, with no packet authentication #96. The association
  installed by enable_ipsec() carried XFRMA_ALG_CRYPT and nothing else, so it offered
  confidentiality without integrity.
• transmitter: build an IPv6 header on the tunnel path, and budget for it, closing The UDP tunnel send path is IPv4-only and throws on an IPv6 destination #97. The tunnel
  path took its addresses with to_v4(), which throws for a v6 address, and budgeted a 20-byte IP
  header regardless of the family in use.
• transmitter: send to the announced destination as well as through the tunnel. No issue: this
  change was already written, but it was sitting inside RFC 5053 Raptor FEC scheme: codec, FLUTE integration, and the missing-symbol accessor #61's Raptor integration commit, which is
  not where a change to the send path belongs and meant the tunnel send path was being altered by
  two pull requests at once. It is moved here, where The send socket is not bound to the configured source address when a tunnel is set #82 and The UDP tunnel send path is IPv4-only and throws on an IPv6 destination #97 already live, and removed from
  RFC 5053 Raptor FEC scheme: codec, FLUTE integration, and the missing-symbol accessor #61. With a tunnel configured the announced destination now receives the plain copy as well, so
  a receiver joining that address directly is no longer left with nothing. This is also the
  behaviour the The send socket is not bound to the configured source address when a tunnel is set #82 commit above was written for: binding the source address matters because a
  tunnelled session also emits an untunnelled copy, which until this commit it did not.

Four further commits, from reading RFC 5651 and RFC 5775

These came out of a prose read of the version 2 building blocks, RFC 5775 (ALC) and RFC 5651 (LCT),
undertaken to scope #81's second step. All three turned out to belong here rather than on the version 2
branch, because the provisions they rest on are in the version 1 documents too, or because this library
has one code path for both versions.

• receiver: a packet carrying no payload is not an FDT packet. A packet with no payload restarted FDT
  reception and reassembled a zero-length object from it: a header with no TOI decodes to TOI 0, so such
  a packet entered the TOI 0 branch. One datagram from a conformant peer ending its session does this,
  and RFC 3926 clause 3.1 is what makes such a peer send one.

  RFC 3450 clause 4.1:

  In some special cases an ALC sender may need to produce ALC packets that do not contain any payload.

  RFC 3450 clause 4.1, on how a receiver tells:

  The total datagram length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the ALC payload and FEC Payload ID.

  RFC 3926 clause 3.1, on the shape a FLUTE sender uses:

  the exception that ALC packets sent in a FLUTE session with the Close Session (A) flag set to 1 (signaling the end of the session) and that contain no payload (carrying no information for any file or FDT) SHALL NOT carry the TOI

  Removing the guards makes the new test fail on the stray TOI 0 entry, so it tests the fix rather than
  passing regardless.

• alc: send the data-less Close Session packet the specification provides for. close_session() sets a
  flag on packets sent from that point on, so on a session with an empty queue it signalled nothing at
  all: once the file set empties, send_fdt() returns early and no further packet is ever built. The
  packet RFC 3450 clause 4.1 provides for is now sent, in the shape RFC 3926 clause 3.1 requires. A TSI
  wider than 32 bits cannot express it, since dropping the TOI drops the half-word the two fields share;
  that is refused and logged rather than emitting the TOI the clause forbids.

• ipsec: select the session's traffic by protocol and port, not the destination alone. The policy
  selector named only the destination address, so it captured every datagram addressed to that group
  whatever it was for.

  RFC 5775 clause 5.1.1:

  The sender IPsec SPD entry MUST be configured to process outbound packets to the destination address and UDP port number of the applicable ALC session.

  RFC 5775 clause 5.1.2.1:

  The implementation MUST be able to use the source address, destination address, protocol (UDP), and UDP port numbers as selectors in the SPD.

  This one is strictly a version 2 obligation and it still lands here. RFC 3450 contains no IPsec
  baseline at all; the baseline arrives with RFC 5775 and reaches FLUTE through RFC 6726 clause 7.5. But
  this library has one enable_ipsec() and no per-version IPsec path, so the over-broad selector was
  over-broad for both versions. For version 1 this is a defect fix; for version 2 it is also a
  conformance fix. enable_esp() gains a port parameter and both callers pass the port they already
  hold.

  T2, since installing a policy needs CAP_NET_ADMIN and so has no test scaffolding. Built against the
  running kernel and read back:

  $ sudo ip xfrm policy show
  src 0.0.0.0/0 dst 239.255.42.7/32 proto udp dport 40085
      dir out priority 0
      tmpl src 0.0.0.0 dst 239.255.42.7
          proto esp spi 0x00001234 reqid 4660 mode transport
  

  Reproducible with a three-line program calling
  LibFlute::IpSec::enable_esp(0x1234, "239.255.42.7", 40085, Direction::Out, key, auth_key). Test
  policies and states were flushed afterwards.

• tests: quote the field definition the IPv6 header test checks against. Comment and test-message
  only, no assertion changed. tests/test_transmitter.cpp named RFC 8200 clause 3 in a comment and
  then asserted against it with an unquoted gtest failure message on the next line, which
  tools/verify-citations.py reads as the clause's text and cannot confirm. It now sets out the
  sentence:

  RFC 8200 clause 3:

  Version 4-bit Internet Protocol version number = 6.

  Found by running the checker over every source file on every branch rather than only the files each
  change touched. It was reporting one unconfirmed citation on all six branches, and had been for as
  long as that test has existed.

---

Issues closed by this pull request

Closes #27, #70, #71, #72, #73, #74, #75, #76, #82, #83, #85, #96, #97, #100, #101.

Newly added since the list above was first written:

• FDT Instance expiry is read before it is set #100 FDT Instance expiry is read before it is set. Commit fdt: initialise the FDT Instance expiry.
• An unrecognised FEC Encoding ID from the network is accepted #101 An unrecognised FEC Encoding ID from the network is accepted. Commit fdt: refuse an FEC Encoding ID naming no scheme this library implements.

Not closed by this pull request, and not claimed: #103, which is fixed on #64 where the additional FEC schemes are defined.

One commit here closes no issue and is not a fix: tests: exercise each profile end to end, which adds a transmit-and-reconstruct case per profile through one unmodified Receiver.

[jordijoangimenez]

Spec-compliance verification

Each item below was checked directly against the primary RFC text (not inferred from existing code comments or secondary sources):

Item	RFC	Verified against primary text
FLUTE version 2	RFC 6726 §3.1/3.4.1	Yes — exact wording match ("MUST use FLUTE version 2")
TSI widening (16/48-bit)	RFC 5651 §5.1	Yes — exact formula match ("TSI field is 32×S + 16×H bits")
FDT Instance ID wraparound	RFC 6726 §3.4.1	Yes — "MUST NOT reuse [a] non-expired [FDT Instance ID]", reuse starts from smallest expired ID
FDT Complete attribute	RFC 6726 §3.4.2	Yes — exact semantics match
Close Session/Object flags	RFC 5651 §5.1	Yes — semantics match, plus the "SHOULD set... in all subsequent packets until termination" persistence rule
EXT_FTI for TOI>0	RFC 6726 §5	Yes — "receiver MUST support both methods [EXT_FTI and FDT]"

[davidjwbbc]

3GPP TS 26.517 (v18.5.1)

• Clause 6.2.1 states:

  If FLUTE [12] is used to realise the Object Distribution Method, the MBS Distribution Session shall conform to the MBMS Download Profile as defined in clause L.4 of TS 26.346 [7] with the additional requirements in clause 6.2 of the present document.

3GPP TS 26.346 (v18.1.0)

• Clause L.4 states:

  The Download Profile constrains the large set of FDT parameters specified in clause 7.2 of the present document, which includes both the FDT elements and attributes defined by the IETF FLUTE standard, RFC 3926 [9] and various 3GPP-defined FDT extensions for MBMS.

• Clause 7.2.0 states:

  MBMS Clients and servers supporting MBMS download shall implement the FLUTE specification (RFC 3926 [9]), as well as ALC (RFC 3450 [10]) and LCT (RFC 3451 [11]) features that FLUTE inherits. In addition, several optional and extended aspects of FLUTE ,as described in the following clauses, shall be supported.

• Clause 7.2.7 states:

  FLUTE and ALC mandatory header fields shall be as specified in [9, 10] with the following additional specializations

• References:

  [9] IETF RFC 3926 (October 2004): "FLUTE - File Delivery over Unidirectional Transport", T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh.
  [10] IETF RFC 3450 (December 2002): "Asynchronous Layered Coding (ALC) Protocol Instantiation", M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft.

Therefore the FLUTE session for 3GPP applications is based on RFC3926, which is the FLUTE v1 specification, and states:

This document specifies FLUTE version 1. Hence in any ALC packet that carries FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '1'.

Since we use this library with 3GPP applications it needs to support version 1 of FLUTE. It could support version 2 as well, but changes to make this version 2 only will break 3GPP based applications.

[davidjwbbc]

I have no problem with FLUET v2 being added, but this library needs to support FLUTE v1 for compliance with 3GPP specifications. Please do not make changes that remove FLUTE v1 compliance.

[jordijoangimenez]

Thanks @davidjwbbc. Having discussed this now wth @dsilhavy, I'm going to defer v2 to another branch and leave that code out of this PR. Then I will check that all v1 is consistent with 3GPP and update this PR accordingly.

[jordijoangimenez]

Pushed a corrected version, per this thread:

• Dropped the FLUTE version-2 change entirely. @davidjwbbc is right — TS 26.517 cl.6.2.1 → TS 26.346 Annex L mandates the RFC 3926 (v1) profile for MBMS/MBS applications, which are this library's primary consumers. Kept it on a separate future/flute-v2-support branch in case genuine (non-3GPP) FLUTE v2 support is wanted later.
• Re-verified the other four fixes directly against TS 26.346 v18.2.0 (not just the IETF RFCs) before re-pushing:
  • TSI widening: cl.7.2.7 mandates TSI shall be exactly 16 bits for MBMS. The fix only adds a wider on-wire encoding when a value actually exceeds 16 bits — a compliant MBMS session's TSI never does, so no compliant packet's wire format changes. Flagging the mandate here for visibility, not because the fix violates it.
  • FDT Instance ID wraparound, Complete attribute, Close Session/Object flags: all explicitly present in 3GPP's own FDT schema/clause 7.2.7, not v2-only additions — confirmed compliant.
  • EXT_FTI bootstrap: receiver-side only; the transmitter still only emits EXT_FTI on TOI=0 packets per cl.7.2.8's mandate, unchanged.

Tests/build unaffected — only the one line (FLUTE version nibble) and its commit message changed; the other three commits are untouched.

[rjb1000]

@jordijoangimenez: Now the scope of this PR has changed to be compliance with TS 26.517 and TS 26.346, the title should also be changed accordingly. Given that the target is now compliance with FLUTE v1, we are talking about RFC 3986 rather than RFC 6726.

Rather than burying the update in a supplementary comment, it would be better to integrate the correct scope into the main issue description to avoid confusing future readers.

[jordijoangimenez]

Suggestions applied, @rjb1000