Asynchronous Layered Coding (ALC) Protocol Instantiation
obsoletes
- rfc-3450 — Asynchronous Layered Coding (ALC) Protocol Instantiation
Extracted elements (26)
ALC intentionally omits application-specific features that could limit scalability, providing a minimal protocol that applications can build upon. The sender's transmission can be independent of the number and individual reception experiences of receivers because FEC-based reliability eliminates the need for individual retransmission requests.
ALC is designed for massive scalability by using IP multicast as the underlying network service, supporting millions of concurrent receivers with a single sender. The sender's load is independent of the number of receivers, and no feedback packets are required from receivers to the sender.
When using Any-Source Multicast (ASM), the congestion control building block may be adversely affected by delays due to Rendezvous Points (RPs) and MSDP, and by packet loss during switchover from (*,G) to (S,G) joins. To ameliorate these concerns, it is recommended to ensure the RP is as close to the sender as possible; Source-Specific Multicast (SSM) does not share these issues.
A receiver is REQUIRED to obtain the FEC Object Transmission Information for each object for which data packets are received from the session, including the FEC Encoding ID, FEC Instance ID (if applicable), and the transfer length of the object in bytes.
A Transport Session Identifier (TSI) MUST be associated with each ALC session and MUST be carried in the LCT header of each ALC packet. The (sender IP address, TSI) pair MUST uniquely identify the session, and the TSI field length is REQUIRED to be non-zero.
All packets in an ALC session MUST contain an FEC Payload ID in a format compliant with the FEC Scheme in use. The receiver MUST use the FEC Payload ID to determine how encoding symbols in the packet payload were generated from the object.
For baseline secure ALC, IPsec transport mode MUST be supported, and the use of IPsec processing for secure ALC traffic SHOULD also be REQUIRED such that unauthenticated packets are not received by the ALC protocol implementation.
For baseline secure ALC key management, an automated key management scheme such as GDOI (RFC 3547), GSAKMP (RFC 4535), or MIKEY (RFC 3830) SHOULD be used. Short-lived ALC sessions MAY use Manual Keying if Extended Sequence Numbering (ESN) is available.
For baseline secure ALC, the sender IPsec SPD entry MUST be configured to process outbound packets to the destination address and UDP port of the applicable ALC session. The ALC receiver(s) MUST be configured with the SA and SPD entry to properly process IPsec-secured packets from the sender.
For systematic FEC Schemes defining separate FEC Payload ID formats for source vs. repair packets, the SPI bit MUST be set to 1 for source-data format and MUST be set to 0 for repair-data format. For FEC Schemes with only a single FEC Payload ID format, SPI MUST be set to 0 by sender and MUST be ignored by receiver.
If more than one object is carried in a session, the Transmission Object Identifier (TOI) MUST be used in the LCT header to identify which packets are associated with which objects. The TOI for each object is REQUIRED to be unique within a session.
Implementations of ALC MUST support RFC 3738 (WEBRC) as the minimum multiple rate congestion control building block. Congestion control MUST be applied to all packets within a session independently of which object information is carried.
It is RECOMMENDED that implementors of ALC use some packet authentication scheme to protect the protocol from attacks. Suitable schemes are described in RFC 5776 (TESLA) and RMT-SIMPLE.
The ALC sender MUST obey the rules for filling in the CCI field in packet headers and MUST send packets at rates dictated by the multiple rate congestion control building block. The sender MUST use the same TSI for all packets in the session.
The LCT header CCI field MUST be used to carry the Congestion Control Information from the specified multiple rate congestion control protocol. The CCI format and length MUST be consistent across all packets sent to a session.
An ALC packet consists of: IP Header, UDP Header, LCT Header, FEC Payload ID, and Encoding Symbols. The LCT header carries the Congestion Control Information (CCI) field and the FEC Payload ID uniquely identifies the encoding symbols in the payload.
The EXT_FTI LCT Header Extension (type value 64) is defined for communicating FEC Object Transmission Information in association with data packets of an object. The HEC field contains the encoded FEC Object Transmission Information as defined in RFC 5052.
The LCT Header's Protocol Specific Indication (PSI) bits 6 and 7 are used by ALC: bit X is the Source Packet Indicator (SPI) distinguishing source-data packets from repair-data packets in systematic FEC schemes, and bit Y is reserved.
The Session Description required before joining an ALC session must include: the congestion control building block, sender IP address, number of channels and their addresses/ports, TSI, indication of single vs. multiple objects, Header Extension formats, and packet authentication scheme information.
This specification registers one value in the LCT Header Extensions Types namespace: value 64 is assigned the name EXT_FTI, used to carry FEC Object Transmission Information in-band with data packets.
ALC is especially vulnerable to denial-of-service attacks via forged packets, which can prevent or corrupt object reconstruction at scale since many receivers may receive the same forged packet. Two layers of protection are RECOMMENDED: application-level object integrity checking (using digital signatures) and packet-level authentication to discard forged packets individually.
Attackers can inject forged packets with incorrect congestion control information into the multicast stream, potentially adversely affecting network elements and downstream receivers. Packet-level authentication (e.g., TESLA) is RECOMMENDED to protect against such attacks, though TESLA-based checks may only take effect several seconds after receipt.
Baseline secure ALC operation is defined using IPsec in transport mode with ESP providing data origination authentication and optionally confidentiality. Each node is configured with a transport mode IPsec SA; the encryption key SHALL be preplaced at sender and receiver(s), and automated key management is RECOMMENDED with rekey required before SA sequence space expiration.
Reverse Path Forwarding checks SHOULD be enabled in all network routers and switches along the path from sender to receivers to limit the possibility of forged packet injection into the multicast tree data path.
Upon receipt of each ALC packet, the receiver must: (1) parse and validate the header, discarding invalid packets; (2) verify the (sender IP, TSI) pair matches a joined session, silently discarding mismatches; (3) process the CCI field per congestion control; (4) verify TOI validity if multi-object session; (5) process remaining header fields and reconstruct the object using FEC.
The overall ALC packet format is: UDP Header | LCT Header | FEC Payload ID | Encoding Symbol(s). Data-less packets (used to signal session end or carry congestion control info) contain only the LCT header with no FEC Payload ID or payload; their absence is detected via the total datagram length in outer protocol headers.