Layered Coding Transport (LCT) Building Block
obsoletes
- rfc-3451 — Layered Coding Transport (LCT) Building Block
Extracted elements (30)
LCT deliberately avoids any mechanism for receivers to send information back to senders in order to preserve massive scalability. Feedback from receivers to senders is one of the key bottlenecks for scalable reliable multicast delivery.
LCT does not specify which congestion control protocol to use because different applications (content delivery vs. streaming) have different congestion control requirements — content delivery strives to use all available bandwidth while streaming may maintain a constant rate. Mandating a specific scheme would limit applicability.
The 2 previously reserved bits in the LCT header were allocated as Protocol-Specific Indication (PSI) bits, allowing protocol instantiations to signal PI-specific state without requiring header extensions. A flat single namespace was also adopted for LCT Header Extension Types, replacing the previous split between PI-specific and general ranges.
The SCT and ERT header fields from RFC 3451 were removed from the fixed LCT header and replaced by the EXT_TIME Header Extension. This change provides a more flexible and extensible mechanism for timing information while keeping the base header compact.
LCT is compatible with both IPv4 and IPv6 because no part of the LCT packet header is IP-version-specific. LCT also works with both Any-Source Multicast (ASM, RFC 1112) and Source-Specific Multicast (SSM, RFC 4607) models, though SSM provides stronger security guarantees against DoS attacks since only the designated sender's packets are received.
When using ASM, receivers SHOULD use packet authentication mechanisms because all packets sent to multicast group G may be received regardless of sender. With SSM the receiver only gets packets from the specific sender S, which prevents injection attacks that are possible with ASM.
A congestion control building block that uses the CCI field within the LCT header MUST be used by any protocol instantiation using LCT. The congestion control MUST be applied to the LCT session as an entity, over the aggregate traffic of all LCT channels in the session.
A receiver MUST implement the congestion control protocol specified in the session description. If a receiver cannot implement it, it MUST NOT join the session. When using multiple LCT channels, receivers MUST initially join channels according to the specified startup behavior to prevent starting at high data rates.
A receiver that is concurrently joined to multiple LCT sessions MUST perform congestion control on each session individually. The receiver MAY optimize packet flow performance across sessions as long as it adheres to each session's congestion control rules.
All senders and receivers implementing LCT MUST support the EXT_NOP Header Extension and MUST recognize EXT_AUTH and EXT_TIME, though they are not required to be able to parse their content.
Before joining an LCT session, a receiver MUST obtain a session description that includes the sender IP address, number and addresses of LCT channels, TSI, and enough information to determine the congestion control and packet authentication schemes in use.
Congestion control MUST be used that conforms to RFC 2357 between receivers and the sender for each LCT session. The total flow of packets to each receiver MUST NOT compete unfairly with existing flow-adaptive protocols such as TCP.
If Header Extensions are present, they MUST be processed to ensure they are recognized before performing any congestion control procedure or otherwise accepting a packet. The default action for unrecognized Header Extensions is to ignore them.
Packets sent to an LCT session MUST include an LCT header. The position of the LCT header within a packet MUST be specified by any protocol instantiation that uses LCT.
There MUST be a Transport Session Identifier (TSI) associated with each LCT session, scoped by the sender IP address, and the two together MUST uniquely identify the session. If no underlying TSI is provided by the network or transport layer, the TSI MUST be included in the LCT header.
The Close Session flag (A) and Close Object flag (B) are 1-bit fields. The sender MAY set A=1 when session termination is imminent and SHOULD set it in all subsequent packets once set. Similarly B=1 signals imminent end of transmission for the object identified by the TOI field.
The Codepoint (CP) field is 8 bits and is an opaque identifier passed to the packet payload decoder to convey information on the codec being used. The mapping between codepoint and codec is defined per session and communicated out-of-band, analogous to the Payload Type field in RTP.
The Congestion Control Information (CCI) field is 32, 64, 96, or 128 bits in length as determined by the C flag (C=0 means 32 bits, C=3 means 128 bits). It is an opaque field used to carry congestion control information such as layer numbers, logical channel numbers, and sequence numbers.
The Expected Residual Time (ERT) is a 32-bit unsigned integer in seconds representing the sender's expected remaining transmission time for the current object (or session object if no TOI is present). The Session Last Changed (SLC) field records when the last Transport Object addition, modification, or removal occurred.
The Sender Current Time (SCT) provides the sender's wall clock at packet transmission time. SCT-High carries seconds as an unsigned 32-bit integer; SCT-Low carries sub-second precision as a multiple of 1/2^32 of a second. When SCT-Low is set, SCT-High MUST also be set.
The Transport Object Identifier (TOI) field is 0, 16, 32, 48, 64, 80, 96, or 112 bits long (32*O + 16*H bits). It identifies which object within the session the packet pertains to and MUST be present in all packets if more than one object is transmitted in a session.
The Transport Session Identifier (TSI) field is 0, 16, 32, or 48 bits long (32*S + 16*H bits). It uniquely identifies a session among all sessions from a particular sender; if the TSI value appears multiple times in a packet, all occurrences MUST be identical.
This document creates the 'LCT Header Extension Types' namespace for integer values 0–255. Values 0–63 (variable-length) and 128–191 (fixed-length) require IETF Review; values 64–127 (variable-length) and 192–255 (fixed-length) require Specification Required. Initial registrations: EXT_NOP=0, EXT_AUTH=1, EXT_TIME=2.
Incorrect or maliciously modified session description information may result in receivers being unable to correctly receive session content or may cause them to attempt reception at much higher rates than they are capable of. Protocol instantiations MUST authenticate and protect integrity of the session description and MUST allow receivers to verify the correspondence between session description and LCT data packets.
Modification of the Congestion Control field may cause receivers to receive at an incorrect rate, potentially worsening or causing congestion. Modification of the Codepoint or packet payload may prevent or corrupt reconstruction of objects. All data transport fields MUST be protected by source authentication and data integrity mechanisms.
Modification of TSI or TOI fields by an attacker can deprive sessions or objects of data or direct incorrect data to other sessions/objects. Injection of forged packets with fake TSI/TOI values may cause receivers to allocate resources for spurious sessions, effecting a DoS attack. These fields MUST be protected by protocol instantiation security mechanisms such as source authentication and data integrity.
The Close Session (A) and Close Object (B) flags can be manipulated to cause receivers to incorrectly terminate or continue receiving. The SCT and ERT time fields can be exploited to de-synchronize clients or mount DoS attacks. All these fields MUST be protected by protocol instantiation security mechanisms.
Header Extensions use two formats: variable-length extensions (HET 0–127) have an 8-bit HET, 8-bit HEL (length in 32-bit words), and variable HEC; fixed-length extensions (HET 128–255) have an 8-bit HET and a 24-bit HEC packed into one 32-bit word. HEL MUST be present for variable-length and MUST NOT be present for fixed-length extensions.
The default LCT header begins with a fixed first 32-bit word containing: V (4 bits, version), C (2 bits, CCI length flag), PSI (2 bits, protocol-specific), S (1 bit, TSI length flag), O (2 bits, TOI length flag), H (1 bit, half-word flag), Res (2 bits, reserved), A (1 bit, Close Session), B (1 bit, Close Object), HDR_LEN (8 bits, header length in 32-bit words), CP (8 bits, Codepoint). Variable-length CCI, TSI, and TOI fields follow.
The EXT_TIME Header Extension (HET=2) carries a 16-bit 'Use' bit field followed by one or more 32-bit time values. The Use field has 8 bits for general-purpose timing (SCT-High, SCT-Low, ERT, SLC flags plus 4 reserved bits) and 8 bits for PI-specific use. Time values MUST appear in Use-field flag order.