One document matched: draft-ietf-rmt-pi-alc-revised-10.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc5052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml">
<!ENTITY tesla SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-msec-tesla-for-alc-norm.xml">
<!ENTITY rfc5651 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5651.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc1112 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml">
<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc2974 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml">
<!ENTITY rfc2357 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2357.xml">
<!ENTITY rfc3023 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3023.xml">
<!ENTITY rfc0768 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml">
<!ENTITY rfc3269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3269.xml">
<!ENTITY rfc3450 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3450.xml">
<!ENTITY rfc3453 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3453.xml">
<!ENTITY rfc3048 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3048.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3738 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3738.xml">
<!ENTITY rfc3618 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3618.xml">
<!ENTITY rfc3569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3569.xml">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<!--<?rfc strict="yes" ?>-->
<rfc category="std" docName="draft-ietf-rmt-pi-alc-revised-10"
ipr="pre5378Trust200902" obsoletes="3450">
<front>
<title abbrev="ALC Protocol Instantiation">Asynchronous Layered Coding
(ALC) Protocol Instantiation</title>
<author fullname="Michael Luby" surname="Luby">
<organization>Qualcomm Inc.</organization>
<address>
<postal>
<street>3165 Kifer Road</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>
<email>luby@qualcomm.com</email>
</address>
</author>
<author fullname="Mark Watson" surname="Watson">
<organization>Qualcomm Inc.</organization>
<address>
<postal>
<street>3165 Kifer Road</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>
<email>watson@qualcomm.com</email>
</address>
</author>
<author fullname="Lorenzo Vicisano" surname="Vicisano">
<organization>Qualcomm Inc.</organization>
<address>
<postal>
<street>3165 Kifer Road</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>
<email>vicisano@qualcomm.com</email>
</address>
</author>
<date day="9" month="November" year="2009" />
<area>Transport</area>
<workgroup>Reliable Multicast Transport (RMT) Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This document describes the Asynchronous Layered Coding (ALC)
protocol, a massively scalable reliable content delivery protocol.
Asynchronous Layered Coding combines the Layered Coding Transport (LCT)
building block, a multiple rate congestion control building block and
the Forward Error Correction (FEC) building block to provide congestion
controlled reliable asynchronous delivery of content to an unlimited
number of concurrent receivers from a single sender. This document
obsoletes RFC3450.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes a massively scalable reliable content
delivery protocol, Asynchronous Layered Coding (ALC), for multiple rate
congestion controlled reliable content delivery. The protocol is
specifically designed to provide massive scalability using IP multicast
as the underlying network service. Massive scalability in this context
means the number of concurrent receivers for an object is potentially in
the millions, the aggregate size of objects to be delivered in a session
ranges from hundreds of kilobytes to hundreds of gigabytes, each
receiver can initiate reception of an object asynchronously, the
reception rate of each receiver in the session is the maximum fair
bandwidth available between that receiver and the sender, and all of
this can be supported using a single sender.</t>
<t>Because ALC is focused on reliable content delivery, the goal is to
deliver objects as quickly as possible to each receiver while at the
same time remaining network friendly to competing traffic. Thus, the
congestion control used in conjunction with ALC should strive to
maximize use of available bandwidth between receivers and the sender
while at the same time backing off aggressively in the face of competing
traffic.</t>
<t>The sender side of ALC consists of generating packets based on
objects to be delivered within the session and sending the appropriately
formatted packets at the appropriate rates to the channels associated
with the session. The receiver side of ALC consists of joining
appropriate channels associated with the session, performing congestion
control by adjusting the set of joined channels associated with the
session in response to detected congestion, and using the packets to
reliably reconstruct objects. All information flow in an ALC session is
in the form of data packets sent by a single sender to channels that
receivers join to receive data.</t>
<t>ALC does specify the Session Description needed by receivers before
they join a session, but the mechanisms by which receivers obtain this
required information is outside the scope of ALC. An application that
uses ALC may require that receivers report statistics on their reception
experience back to the sender, but the mechanisms by which receivers
report back statistics is outside the scope of ALC. In general, ALC is
designed to be a minimal protocol instantiation that provides reliable
content delivery without unnecessary limitations to the scalability of
the basic protocol.</t>
<t>This document is a product of the IETF RMT WG and follows the general
guidelines provided in <xref target="RFC3269"></xref>.</t>
<t>A previous version of this document was published in the
"Experimental" category as <xref target="RFC3450"></xref> and is
obsoleted by this document.</t>
<t>This Proposed Standard specification is thus based on and backwards
compatible with the protocol defined in <xref target="RFC3450"></xref>
updated according to accumulated experience and growing protocol
maturity since its original publication. Said experience applies both to
this specification itself and to congestion control strategies related
to the use of this specification.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, <xref
target="RFC2119"></xref>.</t>
<section title="Delivery service models">
<t>ALC can support several different reliable content delivery service
models as described in <xref target="RFC5651"></xref>.</t>
</section>
<section title="Scalability">
<t>Massive scalability is a primary design goal for ALC. IP multicast
is inherently massively scalable, but the best effort service that it
provides does not provide session management functionality, congestion
control or reliability. ALC provides all of this on top of IP
multicast without sacrificing any of the inherent scalability of IP
multicast. ALC has the following properties:</t>
<t><list style="symbols">
<t>To each receiver, it appears as if though there is a dedicated
session from the sender to the receiver, where the reception rate
adjusts to congestion along the path from sender to receiver.</t>
<t>To the sender, there is no difference in load or outgoing rate
if one receiver is joined to the session or a million (or any
number of) receivers are joined to the session, independent of
when the receivers join and leave.</t>
<t>No feedback packets are required from receivers to the
sender.</t>
<t>Almost all packets in the session that pass through a
bottleneck link are utilized by downstream receivers, and the
session shares the link with competing flows fairly in proportion
to their utility.</t>
</list></t>
<t>Thus, ALC provides a massively scalable content delivery transport
that is network friendly.</t>
<t>ALC intentionally omits any application specific features that
could potentially limit its scalability. By doing so, ALC provides a
minimal protocol that is massively scalable. Applications may be built
on top of ALC to provide additional features that may limit the
scalability of the application. Such applications are outside the
scope of this document.</t>
</section>
<section title="Environmental Requirements and Considerations">
<t>All of the environmental requirements and considerations that apply
to the LCT building block <xref target="RFC5651"></xref>, the FEC
building block <xref target="RFC5052"></xref>, the multiple rate
congestion control building block and to any additional building
blocks that ALC uses also apply to ALC.</t>
<t>The IP multicast model defined in <xref target="RFC1112"></xref> is
commonly known as Any-Source Multicast (ASM), in contrast to
Source-Specific Multicast (SSM) which is defined in <xref
target="RFC3569"></xref>. One issues that is specific to ALC with
respect to ASM is the way the multiple rate congestion control
building block interacts with ASM. The congestion control building
block may use the measured difference in time between when a join to a
channel is sent and when the first packet from the channel arrives in
determining the receiver reception rate. The congestion control
building block may also use packet sequence numbers per channel to
measure losses, and this is also used to determine the receiver
reception rate. These features raise two concerns with respect to ASM:
The time difference between when the join to a channel is sent and
when the first packet arrives can be significant due to the use of
Rendezvous Points (RPs) and the Multicast Source Discovery Protocol
(MSDP) <xref target="RFC3618"></xref> protocol, and packets can be
lost in the switch over from the (*,G) join to the RP and the (S,G)
join directly to the sender. Both of these issues could potentially
substantially degrade the reception rate of receivers. To ameliorate
these concerns, it is recommended during deployment to ensure that the
RP be as close to the sender as possible. SSM does not share these
same concerns. For a fuller consideration of these issues, consult the
multiple rate congestion control building block.</t>
</section>
</section>
<section title="Architecture Definition">
<t>ALC uses the LCT building block <xref target="RFC5651"></xref> to
provide in-band session management functionality. ALC uses a multiple
rate congestion control building block that is compliant with <xref
target="RFC2357"></xref> to provide congestion control that is feedback
free. Receivers adjust their reception rates individually by joining and
leaving channels associated with the session. ALC uses the FEC building
block <xref target="RFC5052"></xref> to provide reliability. The sender
generates encoding symbols based on the object to be delivered using FEC
codes and sends them in packets to channels associated with the session.
Receivers simply wait for enough packets to arrive in order to reliably
reconstruct the object. Thus, there is no request for retransmission of
individual packets from receivers that miss packets in order to assure
reliable reception of an object, and the packets and their rate of
transmission out of the sender can be independent of the number and the
individual reception experiences of the receivers.</t>
<t>The definition of a session for ALC is the same as it is for LCT. An
ALC session comprises multiple channels originating at a single sender
that are used for some period of time to carry packets pertaining to the
transmission of one or more objects that can be of interest to
receivers. Congestion control is performed over the aggregate of packets
sent to channels belonging to a session. The fact that an ALC session is
restricted to a single sender does not preclude the possibility of
receiving packets for the same objects from multiple senders. However,
each sender would be sending packets to a a different session to which
congestion control is individually applied. Although receiving
concurrently from multiple sessions is allowed, how this is done at the
application level is outside the scope of this document.</t>
<t>ALC is a protocol instantiation as defined in <xref
target="RFC3048"></xref>. This document describes version 1 of ALC which
MUST use version 1 of LCT described in <xref target="RFC5651"></xref>.
Like LCT, ALC is designed to be used with the IP multicast network
service. This specification defines ALC as payload of the UDP transport
protocol <xref target="RFC0768"></xref> that supports IP multicast
delivery of packets.</t>
<t>The ALC packet format is illustrated in <xref
target="packetformat"></xref>. An ALC packet header immediately follows
the IP/UDP header and consists of the default LCT header that is
described in <xref target="RFC5651"></xref> followed by the FEC Payload
ID that is described in <xref target="RFC5052"></xref>. The Congestion
Control Information field within the LCT header carries the required
Congestion Control Information that is described in the multiple rate
congestion control building block specified that is compliant with <xref
target="RFC2357"></xref>. The packet payload that follows the ALC packet
header consists of encoding symbols that are identified by the FEC
Payload ID as described in <xref target="RFC5052"></xref>.</t>
<t><figure anchor="packetformat" title="ALC Packet Format">
<artwork><![CDATA[
+----------------------------------------+
| IP Header |
+----------------------------------------+
| UDP Header |
+----------------------------------------+
| LCT Header |
+----------------------------------------+
| FEC Payload Id |
+----------------------------------------+
| Encoding Symbols |
+----------------------------------------+]]></artwork>
</figure></t>
<t></t>
<t>Each receiver is required to obtain a Session Description before
joining an ALC session. As described later, the Session Description
includes out-of-band information required for the LCT, FEC and the
multiple rate congestion control building blocks. The FEC Object
Transmission Information specified in the FEC building block <xref
target="RFC5052"></xref> required for each object to be received by a
receiver can be communicated to a receiver either out-of-band or in-band
using a Header Extension. The means for communicating the Session
Description and the FEC Object Transmission Information to a receiver is
outside the scope of this document.</t>
<section title="LCT building block">
<t>LCT requires receivers to be able to uniquely identify and
demultiplex packets associated with an LCT session, and ALC inherits
and strengthens this requirement. A Transport Session Identifier (TSI)
MUST be associated with each session and MUST be carried in the LCT
header of each ALC packet. The TSI is scoped by the sender IP address,
and the (sender IP address, TSI) pair MUST uniquely identify the
session.</t>
<t>The LCT header contains a Congestion Control Information (CCI)
field that MUST be used to carry the Congestion Control Information
from the specified multiple rate congestion control protocol. There is
a field in the LCT header that specifies the length of the CCI field,
and the multiple rate congestion control building block MUST uniquely
identify a format of the CCI field that corresponds to this
length.</t>
<t>The LCT header contains a Codepoint field that MAY be used to
communicate to a receiver the settings for information that may vary
during a session. If used, the mapping between settings and Codepoint
values is to be communicated in the Session Description, and this
mapping is outside the scope of this document. For example, the FEC
Encoding ID that is part of the FEC Object Transmission Information as
specified in the FEC building block <xref target="RFC5052"></xref>
could vary for each object carried in the session, and the Codepoint
value could be used to communicate the FEC Encoding ID to be used for
each object. The mapping between FEC Encoding IDs and Codepoints could
be, for example, the identity mapping.</t>
<t>If more than one object is to be carried within a session then the
Transmission Object Identifier (TOI) MUST be used in the LCT header to
identify which packets are to be associated with which objects. In
this case the receiver MUST use the TOI to associate received packets
with objects. The TOI is scoped by the IP address of the sender and
the TSI, i.e., the TOI is scoped by the session. The TOI for each
object is REQUIRED to be unique within a session, but is not required
be unique across sessions. Furthermore, the same object MAY have a
different TOI in different sessions. The mapping between TOIs and
objects carried in a session is outside the scope of this
document.</t>
<t>If only one object is carried within a session then the TOI MAY be
omitted from the LCT header.</t>
<t>The LCT header from version 1 of the LCT building block <xref
target="RFC5651"></xref> MUST be used.</t>
<t>The LCT Header includes a two-bit Protocol Specific Indication
(PSI) field in bits 6 and 7 of the first word of the LCT header. These
two bits are used by ALC as follows: <figure anchor="psibitsfig"
title="PSI bits within LCT Headder">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+
...|X|Y|...
+-+-+
]]></artwork>
</figure> <list style="empty">
<t>PSI bit X - Source Packet Indicator (SPI)</t>
<t>PSI bit Y - Reserved</t>
</list></t>
<t>The Source Packet Indicator is used with systematic FEC Schemes
which define a different FEC Payload ID format for packets containing
only source data compared to the FEC Payload ID format for packets
containing repair data. For such FEC Schemes, then the SPI MUST be set
to 1 when the FEC Payload ID format for packets containing only source
data is used and the SPI MUST be set to zero, when the FEC Payload ID
for packerts containing repair data is used. In the case of FEC
Schemes which define only a single FEC Payload ID format, then the SPI
MUST be set to zero by the sender and MUST be ignored by the
receiver.</t>
<t>Support of two FEC Payload ID formats allows FEC Payload ID
information which is only of relevance when FEC decoding is to be
performed to be provided in the FEC Payload ID format for packets
containing repair data. This information need not be processed by
receivers which do not perform FEC decoding (either because no FEC
decoding is required or because the receiver does not support FEC
decoding).</t>
</section>
<section title="Multiple rate congestion control building block">
<t>At a minimum, implementions of ALC MUST support <xref
target="RFC3738"></xref>. Note that <xref target="RFC3738"></xref> has
been published in the "Experimental" category and thus has lower
maturity level than the present document. Caution should be used since
it may be less stable than this document.</t>
<t>Congestion control MUST be applied to all packets within a session
independently of which information about which object is carried in
each packet. Multiple rate congestion control is specified because of
its suitability to scale massively and because of its suitability for
reliable content delivery. <xref target="RFC3738"></xref> specifies
in-band Congestion Control Information (CCI) that MUST be carried in
the CCI field of the LCT header.</t>
<t>Alternative multiple rate congestion control building blocks MAY be
supported, but only a single congestion control building block may be
used in a given ALC session. The congestion control building block to
be used in an ALC session is specified in the Session Description (see
<xref target="SeSessDes"></xref>). A multiple rate congestion control
building block MAY specify more than one format for the CCI field, but
it MUST specify at most one format for each of the possible lengths
32, 64, 96 or 128 bits. The value of C in the LCT header that
determines the length of the CCI field MUST correspond to one of the
lengths for the CCI defined in the multiple rate congestion control
building block, this length MUST be the same for all packets sent to a
session, and the CCI format that corresponds to the length as
specified in the multiple rate congestion control building block MUST
be the format used for the CCI field in the LCT header.</t>
<t>When using a multiple rate congestion control building block a
sender sends packets in the session to several channels at potentially
different rates. Then, individual receivers adjust their reception
rate within a session by adjusting which set of channels they are
joined to at each point in time depending on the available bandwidth
between the receiver and the sender, but independent of other
receivers.</t>
</section>
<section anchor="SeFECBB" title="FEC building block">
<t>The FEC building block <xref target="RFC5052"></xref> provides
reliable object delivery within an ALC session. Each object sent in
the session is independently encoded using FEC codes as described in
<xref target="RFC3453"></xref>, which provide a more in-depth
description of the use of FEC codes in reliable content delivery
protocols. All packets in an ALC session MUST contain an FEC Payload
ID in a format that is compliant with the FEC Scheme in use. The FEC
Payload ID uniquely identifies the encoding symbols that constitute
the payload of each packet, and the receiver MUST use the FEC Payload
ID to determine how the encoding symbols carried in the payload of the
packet were generated from the object as described in the FEC building
block.</t>
<t>As described in <xref target="RFC5052"></xref>, a receiver is
REQUIRED to obtain the FEC Object Transmission Information for each
object for which data packets are received from the session. In the
context of ALC, the FEC Object Transmission Information includes:</t>
<t><list style="symbols">
<t>The FEC Encoding ID.</t>
<t>If an Under-Specified FEC Encoding ID is used then the FEC
Instance ID associated with the FEC Encoding ID.</t>
<t>For each object in the session, the transfer length of the
object in bytes.</t>
</list></t>
<t>Additional FEC Object Transmission Information may be required
depending on the FEC Scheme that is used (identified by the FEC
Encoding ID).</t>
<t>Some of the FEC Object Transmission Information MAY be implicit
based on the FEC Scheme and/or implementation. As an example, source
block lengths may be derived by a fixed algorithm from the object
length. As another example, it may be that all source blocks are the
same length and this is what is passed out-of-band to the receiver. As
another example, it could be that the full sized source block length
is provided and this is the length used for all but the last source
block, which is calculated based on the full source block length and
the object length. As another example, it could be that the same FEC
Encoding ID and FEC Instance ID are always used for a particular
application and thus the FEC Encoding ID and FEC Instance ID are
implicitly defined.</t>
<t>Sometimes the objects that will be sent in a session are completely
known before the receiver joins the session, in which case the FEC
Object Transmission Information for all objects in the session can be
communicated to receivers before they join the session. At other times
the objects may not know when the session begins, or receivers may
join a session in progress and may not be interested in some objects
for which transmission has finished, or receivers may leave a session
before some objects are even available within the session. In these
cases, the FEC Object Transmission Information for each object may be
dynamically communicated to receivers at or before the time packets
for the object are received from the session. This may be accomplished
using either an out-of-band mechanism, in-band using the Codepoint
field or a Header Extension, or any combination of these methods. How
the FEC Object Transmission Information is communicated to receivers
is outside the scope of this document.</t>
</section>
<section anchor="SeSessDes" title="Session Description">
<t>Before a receiver can join an ALC session, the receiver needs to
obtain a session description that contains the following
information:</t>
<t><list style="symbols">
<t>The multiple rate congestion control building block to be used
for the session;</t>
<t>The sender IP address;</t>
<t>The number of channels in the session;</t>
<t>The address and port number used for each channel in the
session;</t>
<t>The Transport Session ID (TSI) to be used for the session;</t>
<t>An indication of whether or not the session carries packets for
more than one object;</t>
<t>If Header Extensions are to be used, the format of these Header
Extensions.</t>
<t>Enough information to determine the packet authentication
scheme being used, if it is being used.</t>
</list></t>
<t>How the Session Description is communicated to receivers is outside
the scope of this document.</t>
<t>The Codepoint field within the LCT portion of the header CAN be
used to communicate in-band some of the dynamically changing
information within a session. To do this, a mapping between Codepoint
values and the different dynamic settings MUST be included within the
Session Description, and then settings to be used are communicated via
the Codepoint value placed into each packet. For example, it is
possible that multiple objects are delivered within the same session
and that a different FEC encoding algorithm is used for different
types of objects. Then the Session Description could contain the
mapping between Codepoint values and FEC Encoding IDs. As another
example, it is possible that a different packet authentication scheme
is used for different packets sent to the session. In this case, the
mapping between the packet authentication scheme and Codepoint values
could be provided in the Session Description. Combinations of settings
can be mapped to Codepoint values as well. For example, a particular
combination of a FEC Encoding ID and a packet authentication scheme
could be associated with a Codepoint value.</t>
<t>The Session Description could also include, but is not limited
to:</t>
<t><list style="symbols">
<t>The mappings between combinations of settings and Codepoint
values;</t>
<t>The data rates used for each channel;</t>
<t>The length of the packet payload;</t>
<t>Any information that is relevant to each object being
transported, such as the Object Transmission Information for each
object, when the object will be available within the session and
for how long.</t>
</list></t>
<t>The Session Description could be in a form such as SDP as defined
in <xref target="RFC4566"></xref>, or XML metadata as defined in <xref
target="RFC3023"></xref>, or HTTP/Mime headers as defined in <xref
target="RFC2616"></xref>, etc. It might be carried in a session
announcement protocol such as SAP as defined in <xref
target="RFC2974"></xref>, obtained using a proprietary session control
protocol, located on a web page with scheduling information, or
conveyed via E-mail or other out-of-band methods. Discussion of
Session Description formats and methods for communication of Session
Descriptions to receivers is beyond the scope of this document.</t>
</section>
<section title="Packet authentication building block">
<t>It is RECOMMENDED that implementors of ALC use some packet
authentication scheme to protect the protocol from attacks. Suitable
schemes are described in <xref
target="I-D.ietf-msec-tesla-for-alc-norm"></xref> and <xref
target="I-D.ietf-rmt-simple-auth-for-alc-norm"></xref>.</t>
</section>
</section>
<section title="Conformance Statement">
<t>This Protocol Instantiation document, in conjunction with the LCT
building block <xref target="RFC5651"></xref>, the FEC building block
<xref target="RFC5052"></xref> and <xref target="RFC3738"></xref>
completely specifies a working reliable multicast transport protocol
that conforms to the requirements described in <xref
target="RFC2357"></xref>.</t>
</section>
<section title="Functionality Definition">
<t>This section describes the format and functionality of the data
packets carried in an ALC session as well as the sender and receiver
operations for a session.</t>
<section title="Packet format used by ALC">
<t>The packet format used by ALC is the UDP header followed by the LCT
header followed by the FEC Payload ID followed by the packet payload.
The LCT header is defined in the LCT building block <xref
target="RFC5651"></xref> and the FEC Payload ID is described in the
FEC building block <xref target="RFC5052"></xref>. The Congestion
Control Information field in the LCT header contains the required
Congestion Control Information that is described in the multiple rate
congestion control building block used. The packet payload contains
encoding symbols generated from an object. If more than one object is
carried in the session then the Transmission Object ID (TOI) within
the LCT header MUST be used to identify which object the encoding
symbols are generated from. Within the scope of an object, encoding
symbols carried in the payload of the packet are identified by the FEC
Payload ID as described in the FEC building block.</t>
<t>The version number of ALC specified in this document is 1. The
version number field of the LCT header MUST be interpreted as the ALC
version number field. This version of ALC implicitly makes use of
version 1 of the LCT building block defined in <xref
target="RFC5651"></xref>.</t>
<t>The overall ALC packet format is depicted in <xref
target="ALCpfmt"></xref>. The packet is an IP packet, either IPv4 or
IPv6, and the IP header precedes the UDP header. The ALC packet format
has no dependencies on the IP version number.</t>
<figure anchor="ALCpfmt" title="Overall ALC packet format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoding Symbol(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>In some special cases an ALC sender may need to produce ALC packets
that do not contain any payload. This may be required, for example, to
signal the end of a session or to convey congestion control
information. These data-less packets do not contain the FEC Payload ID
either, but only the LCT header fields. 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.</t>
<t>For ALC the length of the TSI field within the LCT header is
REQUIRED to be non-zero. This implies that the sender MUST NOT set
both the LCT flags S and H to zero.</t>
</section>
<section anchor="SeHeHex" title="LCT Header-Extension Fields">
<t>This specification defines a new LCT Header Extension, "EXT_FTI",
for the purpose of communicating the FEC Object Transmission
Information in association with data packets of an object. The LCT
Header Extension Type for EXT_FTI is 64.</t>
<t>The Header Extension Content (HEC) field of the EXT_FTI LCT Header
Extension contains the encoded FEC Object Transmission Information as
defined in <xref target="RFC5052"></xref>. The format of the encoded
FEC Object Transmission Information is dependent on the FEC Scheme in
use and so is outside the scope of this document.</t>
</section>
<section title="Sender Operation">
<t>The sender operation when using ALC includes all the points made
about the sender operation when using the LCT building block <xref
target="RFC5651"></xref>, the FEC building block <xref
target="RFC5052"></xref> and the multiple rate congestion control
building block.</t>
<t>A sender using ALC should make available the required Session
Description as described in <xref target="SeSessDes"></xref>. A sender
should also make available the required FEC Object Transmission
Information as described in <xref target="SeFECBB"></xref>.</t>
<t>Within a session a sender transmits a sequence of packets to the
channels associated with the session. The ALC sender MUST obey the
rules for filling in the CCI field in the packet headers and MUST send
packets at the appropriate rates to the channels associated with the
session as dictated by the multiple rate congestion control building
block.</t>
<t>The ALC sender MUST use the same TSI for all packets in the
session. Several objects MAY be delivered within the same ALC session.
If more than one object is to be delivered within a session then the
sender MUST use the TOI field and each object MUST be identified by a
unique TOI within the session, and the sender MUST use corresponding
TOI for all packets pertaining to the same object. The FEC Payload ID
MUST correspond to the encoding symbol(s) for the object carried in
the payload of the packet.</t>
<t>It is RECOMMENDED that packet authentication be used. If packet
authentication is used then the Header Extensions described in <xref
target="SeHeHex"></xref> MAY be used to carry the authentication.</t>
</section>
<section title="Receiver Operation">
<t>The receiver operation when using ALC includes all the points made
about the receiver operation when using the LCT building block <xref
target="RFC5651"></xref>, the FEC building block <xref
target="RFC5052"></xref> and the multiple rate congestion control
building block.</t>
<t>To be able to participate in a session, a receiver needs to obtain
the required Session Description as listed in <xref
target="SeSessDes"></xref>. How receivers obtain a Session Description
is outside the scope of this document.</t>
<t>As described in <xref target="SeFECBB"></xref>, a receiver needs to
obtain the required FEC Object Transmission Information for each
object for which the receiver receives and processes packets.</t>
<t>Upon receipt of each packet the receiver proceeds with the
following steps in the order listed.</t>
<t><list style="numbers">
<t>The receiver MUST parse the packet header and verify that it is
a valid header. If it is not valid then the packet MUST be
discarded without further processing.</t>
<t>The receiver MUST verify that the sender IP address together
with the TSI carried in the header matches one of the (sender IP
address, TSI) pairs that was received in a Session Description and
that the receiver is currently joined to. If there is not a match
then the packet MUST be silently discarded without further
processing. The remaining steps are performed within the scope of
the (sender IP address, TSI) session of the received packet.</t>
<t>The receiver MUST process and act on the CCI field in
accordance with the multiple rate congestion control building
block.</t>
<t>If more than one object is carried in the session, the receiver
MUST verify that the TOI carried in the LCT header is valid. If
the TOI is not valid, the packet MUST be discarded without further
processing.</t>
<t>The receiver SHOULD process the remainder of the packet,
including interpreting the other header fields appropriately, and
using the FEC Payload ID and the encoding symbol(s) in the payload
to reconstruct the corresponding object.</t>
</list></t>
<t>It is RECOMMENDED that packet authentication be used. If packet
authentication is used then it is RECOMMENDED that the receiver
immediately check the authenticity of a packet before proceeding with
step (3) above. If immediate checking is possible and if the packet
fails the check then the receiver MUST silently discard the
packet.</t>
</section>
</section>
<section title="Security Considerations">
<t>The same security consideration that apply to the LCT, FEC and the
multiple rate congestion control building blocks also apply to ALC.</t>
<t>ALC is especially vulnerable to denial- of-service attacks by
attackers that try to send forged packets to the session which would
prevent successful reconstruction or cause inaccurate reconstruction of
large portions of the object by receivers. ALC is also particularly
affected by such an attack because many receivers may receive the same
forged packet. There are two ways to protect against such attacks, one
at the application level and one at the packet level. It is RECOMMENDED
that prevention be provided at both levels.</t>
<t>At the application level, it is RECOMMENDED that an integrity check
on the entire received object be done once the object is reconstructed
to ensure it is the same as the sent object. Moreover, in order to
obtain strong cryptographic integrity protection a digital signature
verifiable by the receiver SHOULD be used to provide this application
level integrity check. However, if even one corrupted or forged packet
is used to reconstruct the object, it is likely that the received object
will be reconstructed incorrectly. This will appropriately cause the
integrity check to fail and in this case the inaccurately reconstructed
object SHOULD be discarded. Thus, the acceptance of a single forged
packet can be an effective denial of service attack for distributing
objects, but an object integrity check at least prevents inadvertent use
of inaccurately reconstructed objects. The specification of an
application level integrity check of the received object is outside the
scope of this document.</t>
<t>At the packet level, it is RECOMMENDED that a packet level
authentication be used to ensure that each received packet is an
authentic and uncorrupted packet containing data for the object arriving
from the specified sender. Packet level authentication has the advantage
that corrupt or forged packets can be discarded individually and the
received authenticated packets can be used to accurately reconstruct the
object. Thus, the effect of a denial of service attack that injects
forged packets is proportional only to the number of forged packets, and
not to the object size. <xref
target="I-D.ietf-rmt-simple-auth-for-alc-norm"></xref><xref
target="I-D.ietf-msec-tesla-for-alc-norm"> and</xref> described packet
level authentication schemes which can be used with the ALC
protocol.</t>
<t>In addition to providing protection against reconstruction of
inaccurate objects, packet level authentication can also provide some
protection against denial of service attacks on the multiple rate
congestion control. Attackers can try to inject forged packets with
incorrect congestion control information into the multicast stream,
thereby potentially adversely affecting network elements and receivers
downstream of the attack, and much less significantly the rest of the
network and other receivers. Thus, it is also RECOMMENDED that packet
level authentication be used to protect against such attacks. TESLA
<xref target="I-D.ietf-msec-tesla-for-alc-norm"></xref> can also be used
to some extent to limit the damage caused by such attacks. However, with
TESLA a receiver can only determine if a packet is authentic several
seconds after it is received, and thus an attack against the congestion
control protocol can be effective for several seconds before the
receiver can react to slow down the session reception rate.</t>
<t>Some packet authentication schemes such as TESLA <xref
target="I-D.ietf-msec-tesla-for-alc-norm"></xref> do not allow an
immediate authenticity check. In this case the receiver SHOULD check the
authenticity of a packet as soon as possible, and if the packet fails
the check then it MUST be silently discarded before step (5) above. It
is RECOMMENDED that if receivers detect many packets which fail
authentication checks within a session then the above procedure should
be modified for this session so that Step 3 is delayed until after the
authentication check and only performed if the check succeeds.</t>
<t>Reverse Path Forwarding checks SHOULD be enabled in all network
routers and switches along the path from the sender to receivers to
limit the possibility of a bad agent injecting forged packets into the
multicast tree data path.</t>
<section title="Baseline Secure ALC Operation">
<t>This section describes a baseline mode of secure ALC protocol
operation based on application of the IPsec security protocol. This
approach is documented here to provide a reference, interoperable
secure mode of operation. However, additional approaches to ALC
security, including other forms of IPsec application, MAY be specified
in the future. For example, the use of the EXT_AUTH header extension
could enable ALC-specific authentication or security encapsulation
headers similar to those of IPsec to be specified and inserted into
the ALC/LCT protocol message headers. This would allow header
compression techniques to be applied to IP and ALC protocol headers
when needed in a similar fashion to that of RTP <xref
target="RFC3550"></xref> and as preserved in the specification for
Secure Real Time Protocol (SRTP) <xref target="RFC3711"></xref>.</t>
<t>The baseline approach described is applicable to ALC operation
configured for SSM (or SSM-like) operation where there is a single
sender. The receiver set would maintain a single IPSec Security
Association (SA) for each ALC sender.</t>
<section title="IPsec Approach">
<t>To support this baseline form of secure ALC one-to-many SSM
operation, each node SHALL be configured with a transport mode IPsec
Security Association and corresponding Security Policy Database
(SPD) entry. This entry will be used for sender-to-group multicast
packet authentication and optionally encryption.</t>
<t>The ALC sender SHALL use an IPsec SA configured for ESP protocol
<xref target="RFC4303"></xref> operation with the option for data
origination authentication enabled. It is also RECOMMENDED that this
IPsec ESP SA be also configured to provide confidentiality
protection for IP packets containing ALC protocol messages. This is
suggested to make the realization of complex replay attacks much
more difficult. The encryption key for this SA SHALL be preplaced at
the sender and receiver(s) prior to ALC protocol operation. Use of
automated key management is RECOMMENDED as a rekey SHALL be required
prior to expiration of the sequence space for the SA. This is
necessary so that receivers may use the built-in IPsec replay attack
protection possible for an IPsec SA with a single source (the ALC
sender). Thus the receivers SHALL enable replay attack protection
for this SA used to secure ALC sender traffic. 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.</t>
<t>The ALC receiver(s) MUST be configured with the SA and SPD entry
to properly process the IPsec-secured packets from the sender. Note
that use of ESP confidentiality, as RECOMMENDED, for secure ALC
protocol operation makes it more difficult for adversaries to
conduct effective replay attacks that may mislead receivers on
content reception. This baseline approach can be used for ALC
protocol sessions with multiple senders if a distinct SA is
established for each sender.</t>
<t>It is anticipated in early deployments of this baseline approach
to ALC security that key management will be conducted out-of-band
with respect to ALC protocol operation. For ALC unidirectional
operation, it is possible that receivers may retrieve keying
information from a central server via out-of-band (with respect to
ALC) communication as needed or otherwise conduct group key updates
with a similar centralized approach. However, it may be possible
with some key management schemes for rekey messages to be
transmitted to the group as a message or transport object within the
ALC reliable transfer session. Additional specification is necessary
to define an in-band key management scheme for ALC sessions perhaps
using the mechanisms of the automated group key management
specifications cited in this document.</t>
</section>
<section title="IPsec Requirements">
<t>In order to implement this secure mode of ALC protocol operation,
the following IPsec capabilities are required.</t>
<section title="Selectors">
<t>The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as
selectors in the SPD.</t>
</section>
<section title="Mode">
<t>IPsec in transport mode MUST be supported. The use of IPsec
<xref target="RFC4301"></xref> processing for secure ALC traffic
SHOULD also be REQUIRED such that unauthenticated packets are not
received by the ALC protocol implementation.</t>
</section>
<section title="Key Management">
<t>An automated key management scheme for group key distribution
and rekeying such as GDOI <xref target="RFC3547"></xref>, GSAKMP
<xref target="RFC4535"></xref>, or MIKEY <xref
target="RFC3830"></xref> SHOULD be used. Relatively short-lived
ALC sessions MAY be able to use Manual Keying with a single,
preplaced key, particularly if Extended Sequence Numbering (ESN)
<xref target="RFC4303"></xref> is available in the IPsec
implementation used. It should also be noted that it may be
possible for key update messages (e.g., the GDOI GROUPKEY-PUSH
message) to be included in the ALC application reliable data
transmission as transport objects if appropriate interfaces were
available between the ALC application and the key management
daemon.</t>
</section>
<section title="Security Policy">
<t>Receivers SHOULD accept connections only from the designated,
authorized sender(s). It is expected that appropriate key
management will provide encryption keys only to receivers
authorized to participate in a designated session. The approach
outlined here allows receiver sets to be controlled on a
per-sender basis.</t>
</section>
<section title="Authentication and Encryption">
<t>Large ALC group sizes may necessitate some form of key
management that does rely upon shared secrets. The GDOI and GSAKMP
protocols mentioned here allow for certificate-based
authentication. These certificates SHOULD use IP addresses for
authentication. However, it is likely that available group key
management implementations will not be ALC-specific.</t>
</section>
<section title="Availability">
<t>The IPsec requirements profile outlined here is commonly
available on many potential ALC hosts. The principal issue is that
configuration and operation of IPsec typically requires privileged
user authorization. Automated key management implementations are
typically configured with the privileges necessary to effect
system IPsec configuration needed.</t>
</section>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>This specification registers the following LCT Header Extensions
Types in namespace ietf:rmt:lct:headerExtensionTypes:variableLength:</t>
<texttable>
<ttcol>Value</ttcol>
<ttcol>Name</ttcol>
<ttcol>Reference</ttcol>
<c>64</c>
<c>EXT_FTI</c>
<c>This specification</c>
</texttable>
</section>
<section title="Acknowledgments">
<t>This specification is substantially based on RFC3450 <xref
target="RFC3450"></xref> and thus credit for the authorship of this
document is primarily due to the authors of RFC3450: Mike Luby, Jim
Gemmel, Lorenzo Vicisano, Luigi Rizzo and Jon Crowcroft. Vincent Roca,
Justin Chapweske and Roger Kermode also contributed to RFC3450.
Additional thanks are due to Vincent Roca and Rod Walsh for
contributions to this update to Proposed Standard.</t>
</section>
<section anchor="changes" title="Changes from RFC3450">
<t>This section summarises the changes that were made from the
Experimental version of this specification published as RFC3450 <xref
target="RFC3450"></xref>: <list style="symbols">
<t>Update all references to the obsoleted RFC 2068 to RFC 2616</t>
<t>Removed the 'Statement of Intent' from the introduction (The
statement of intent was meant to clarify the "Experimental" status
of RFC3450.)</t>
<t>Removed the 'Intellectual Property Issues' Section and replaced
with a standard IPR Statement</t>
<t>Remove material duplicated in LCT</t>
<t>Update references for LCT and FEC Building Block to new versions
and align with changes in the FEC Building Block.</t>
<t>Split normative and informative references</t>
<t>Material applicable in a general LCT context, not just for ALC
has been moved to LCT</t>
<t>The first bit of the "Protocol Specific Indication" in the LCT
Header is defined as a "Source Packet Indication". This is used in
the case that an FEC Scheme defines two FEC Payload ID formats, one
of which is for packets containing only source symbols which can be
processed by receivers that do not support FEC Decoding.</t>
<t>Definition and IANA registration of the EXT_FTI LCT Header
Extension</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative references">
&rfc5052;
&rfc5651;
&rfc2119;
&rfc1112;
&rfc2616;
&rfc4566;
&rfc3023;
&rfc0768;
&rfc3738;
<?rfc include="reference.RFC.4301"?>
<?rfc include="reference.RFC.4303"?>
</references>
<references title="Informative references">
&rfc3569;
&rfc2974;
&rfc2357;
&rfc3269;
&rfc3450;
&rfc3453;
&rfc3048;
&tesla;
&rfc3550;
&rfc3618;
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.I-D.ietf-rmt-simple-auth-for-alc-norm"?>
<?rfc include="reference.RFC.3547"?>
<?rfc include="reference.RFC.4535"?>
<?rfc include="reference.RFC.3830"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:04:18 |