object. The mapping of TOI field values to objects is outside
the scope of this document and is to be done out-of-band. The
TOI field MUST be used in all packets if more than one object
is to be transmitted in a session, i.e., the TOI field is
either present in all the packets of a session or is never
present.
The length of the TOI field is 32*O + 16*H bits. Note that the
aggregate lengths of the TSI field plus the TOI field is a
multiple of 32 bits.
In the example the TOI is 32 bits in length.
Sender Current Time (SCT): 0 or 32 bits
This field represents the current clock of the sender at the
time this packet was transmitted, measured in units of 1ms and
computed modulo 2^32 units from the start of the session.
This field MUST NOT be present if T=0 and MUST be present if
T=1.
In this example the SCT is present.
Expected Residual Time (ERT): 0 or 32 bits
This field represents the sender expected residual transmission
time of packets for either the single object carried in the
session or for the object identified by the TOI if there are
multiple objects carried in the session.
This field MUST NOT be present if R=0 and MUST be present if
R=1.
In this example the ERT is not present.
FEC Payload ID: X bits
The length and format of the FEC Payload ID depends on the FEC
Encoding ID as described in the FEC building block [10]. The
FEC Payload ID format is determined by the FEC Encoding ID that
MUST be communicated in the Session Description. The Session
Description MAY specify that more than one FEC Encoding ID is
used in the session, in which case the Session Description MUST
contain a mapping that identifies which Codepoint values
correspond to which FEC Encoding IDs. This mapping, if used,
is outside the scope of this document.
The example packet format corresponds to the format for "Small
Block, Large Block and Expandable FEC Codes" as described in
the FEC building block, for which the associated FEC Encoding
ID 128. For FEC Encoding ID 128, the FEC Payload ID consists
of the following two fields that in total are X = 64 bits in
length:
Source Block Number (SBN): 32 bits
The Source Block Number identifies from which source block
of the object the encoding symbol(s) in the payload are
generated. These blocks are numbered consecutively from
0 to N-1, where N is the number of source blocks in the
object.
Encoding Symbol ID (ESI): 32 bits
The Encoding Symbol ID identifies which specific encoding
symbol(s) generated from the source block are carried in the
packet payload. The exact details of the correspondence
between Encoding Symbol IDs and the encoding symbol(s) in
the packet payload are dependent on the particular encoding
algorithm used as identified by the FEC Encoding ID and by
the FEC Instance ID.
Encoding Symbol(s): Y bits
The encoding symbols are what the receiver uses to reconstruct
an object. The total length Y of the encoding symbol(s) in the
packet can be determined by the receiver of the packet by
computing the total length of the received packet and
subtracting off the length of the headers.
4.3 Header-Extension Fields
Header Extensions can be used to extend the LCT header portion of the
ALC header to accommodate optional header fields that are not always
used or have variable size. Header Extensions are not used in the
example ALC packet format shown in the previous subsection. Examples
of the use of Header Extensions include:
o Extended-size versions of already existing header fields.
o Sender and Receiver authentication information.
The presence of Header Extensions can be inferred by the LCT header
length (HDR_LEN): if HDR_LEN is larger than the length of the
standard header then the remaining header space is taken by Header
Extension fields.
If present, Header Extensions MUST be processed to ensure that 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. This allows the future
introduction of backward-compatible enhancements to ALC without
changing the ALC version number. Non backward-compatible Header
Extensions CANNOT be introduced without changing the ALC version
number.
There are two formats for Header Extension fields, as depicted below.
The first format is used for variable-length extensions, with Header
Extension Type (HET) values between 0 and 127. The second format is
used for fixed length (one 32-bit word) extensions, using HET values
from 127 to 255.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (<=127) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HET (>=128) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - Format of additional headers
The explanation of each sub-field is the following.
Header Extension Type (HET): 8 bits
The type of the Header Extension. This document defines a
number of possible types. Additional types may be defined in
future versions of this specification. HET values from 0 to
127 are used for variable-length Header Extensions. HET values
from 128 to 255 are used for fixed-length 32-bit Header
Extensions.
Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 127) and MUST NOT
be present for fixed-length extensions (HET between 128 and
255).
Header Extension Content (HEC): variable length
The content of the Header Extension. The format of this sub-
field depends on the Header Extension type. For fixed-length
Header Extensions, the HEC is 24 bits. For variable-length
Header Extensions, the HEC field has variable size, as
specified by the HEL field. Note that the length of each
Header Extension field MUST be a multiple of 32 bits. Also
note that the total size of the LCT header, including all
Header Extensions and all optional header fields, cannot exceed
255 32-bit words.
Header Extensions are further divided between general LCT extensions
and Protocol Instantiation specific extensions (PI-specific).
General LCT extensions have HET in the ranges 0:63 and 128:191
inclusive. PI-specific extensions have HET in the ranges 64:127 and
192:255 inclusive.
General LCT extensions are intended to allow the introduction of
backward-compatible enhancements to LCT without changing the LCT
version number. Non backward-compatible Header Extensions CANNOT be
introduced without changing the LCT version number.
PI-specific extensions are reserved for PI-specific use with semantic
and default parsing actions defined by the PI.
The following general LCT Header Extension types are defined:
EXT_NOP=0 No-Operation extension.
The information present in this extension field MUST be
ignored by receivers.
EXT_AUTH=1 Packet authentication extension
Information used to authenticate the sender of the
packet. The format of this Header Extension and its
processing is outside the scope of this document and is
to be communicated out-of-band as part of the Session
Description.
It is RECOMMENDED that senders provide some form of
packet authentication. If EXT_AUTH is present,
whatever packet authentication checks that can be
performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and
performing any congestion control-related action on it.
Some packet authentication schemes impose a delay of
several seconds between when a packet is received and
when the packet is fully authenticated. Any congestion
control related action that is appropriate MUST NOT be
postponed by any such full packet authentication.
All senders and receivers implementing ALC MUST support the EXT_NOP
Header Extension and MUST recognize EXT_AUTH, but MAY NOT be able to
parse its content.
For this version of ALC, the following PI-specific extension is
defined:
EXT_FTI=64 FEC Object Transmission Information extension
The purpose of this extension is to carry in-band the
FEC Object Transmission Information for an object. The
format of this Header Extension and its processing is
outside the scope of this document and is to be
communicated out-of-band as part of the Session
Description.
4.4 Sender Operation
The sender operation when using ALC includes all the points made
about the sender operation when using the LCT building block [11],
the FEC building block [10] and the multiple rate congestion control
building block.
A sender using ALC MUST make available the required Session
Description as described in Section 2.4. A sender also MUST make
available the required FEC Object Transmission Information as
described in Section 2.3.
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.
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.
Objects MAY be transmitted sequentially within a session, and they
MAY be transmitted concurrently. However, it is good practice to
only send objects concurrently in the same session if the receivers
that participate in that portion of the session have interest in
receiving all the objects. The reason for this is that it wastes
bandwidth and networking resources to have receivers receive data for
objects that they have no interest in. However, there are no rules
with respect to mixing packets for different objects carried within
the session. Although this issue affects the efficiency of the
protocol, it does not affect the correctness nor the inter-
operability of ALC between senders and receivers.
Typically, the sender(s) continues to send packets in a session until
the transmission is considered complete. The transmission may be
considered complete when some time has expired, a certain number of
packets have been sent, or some out-of-band signal (possibly from a
higher level protocol) has indicated completion by a sufficient
number of receivers.
It is RECOMMENDED that packet authentication be used. If packet
authentication is used then the Header Extensions described in
Section 4.3 MUST be used to carry the authentication.
This document does not pose any restriction on packet sizes.
However, network efficiency considerations recommend that the sender
uses as large as possible packet payload size, but in such a way that
packets do not exceed the network's maximum transmission unit size
(MTU), or fragmentation coupled with packet loss might introduce
severe inefficiency in the transmission. It is RECOMMENDED that all
packets have the same or very similar sizes, as this can have a
severe impact on the effectiveness of the multiple rate congestion
control building block.
4.5 Receiver Operation
The receiver operation when using ALC includes all the points made
about the receiver operation when using the LCT building block [11],
the FEC building block [10] and the multiple rate congestion control
building block.
To be able to participate in a session, a receiver MUST obtain the
REQUIRED Session Description as listed in Section 2.4. How receivers
obtain a Session Description is outside the scope of this document.
To be able to be a receiver in a session, the receiver MUST be able
to process the ALC header. The receiver MUST be able to discard,
forward, store or process the other headers and the packet payload.
If a receiver is not able to process the ALC header, it MUST drop
from the session.
To be able to participate in a session, a receiver MUST implement the
multiple rate congestion control building block using the Congestion
Control Information field provided in the LCT header. If a receiver
is not able to implement the multiple rate congestion control
building block it MUST NOT join the session.
Several objects can be carried either sequentially or concurrently
within the same session. In this case, each object is identified by
a unique TOI. Note that even if a sender stops sending packets for
an old object before starting to transmit packets for a new object,
both the network and the underlying protocol layers can cause some
reordering of packets, especially when sent over different channels,
and thus receivers SHOULD NOT assume that the reception of a packet
for a new object means that there are no more packets in transit for
the previous one, at least for some amount of time.
As described in Section 2.3, a receiver MUST obtain the required FEC
Object Transmission Information for each object for which the
receiver receives and processes packets.
A receiver MAY concurrently join multiple ALC sessions from one or
more senders. The receiver MUST perform congestion control on each
such session. The receiver MAY make choices to optimize the packet
flow performance across multiple sessions, as long as the receiver
still adheres to the multiple rate congestion control building block
for each session individually.
Upon receipt of each packet the receiver proceeds with the following
steps in the order listed.
(1) 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. If multiple packets are
received that cannot be parsed then the receiver SHOULD leave the
session.
(2) 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 discarded without further
processing. If multiple packets are received with non-matching
(sender IP address, TSI) values then the receiver SHOULD leave
the session. If the receiver is joined to multiple ALC sessions
then the remainder of the steps are performed within the scope of
the (sender IP address, TSI) session of the received packet.
(3) The receiver MUST process and act on the CCI field in accordance
with the multiple rate congestion control building block.
(4) 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.
(5) 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.
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 discard the packet and reduce
its reception rate to a minimum before continuing to regulate its
reception rate using the multiple rate congestion control.
Some packet authentication schemes such as TESLA [14] 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 discarded before step (5) above and
reduce its reception rate to a minimum before continuing to regulate
its reception rate using the multiple rate congestion control.
5. Security Considerations
The same security consideration that apply to the LCT, FEC and the
multiple rate congestion control building blocks also apply to ALC.
Because of the use of FEC, 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.
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.
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 FEC 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. Although
there is currently no IETF standard that specifies how to do
multicast packet level authentication, TESLA [14] is a known
multicast packet authentication scheme that would work.
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 [14] 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.
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.
A receiver with an incorrect or corrupted implementation of the
multiple rate congestion control building block may affect health of
the network in the path between the sender and the receiver, and may
also affect the reception rates of other receivers joined to the
session. It is therefore RECOMMENDED that receivers be required to
identify themselves as legitimate before they receive the Session
Description needed to join the session. How receivers identify
themselves as legitimate is outside the scope of this document.
Another vulnerability of ALC is the potential of receivers obtaining
an incorrect Session Description for the session. The consequences
of this could be that legitimate receivers with the wrong Session
Description are unable to correctly receive the session content, or
that receivers inadvertently try to receive at a much higher rate
than they are capable of, thereby disrupting traffic in portions of
the network. To avoid these problems, it is RECOMMENDED that
measures be taken to prevent receivers from accepting incorrect
Session Descriptions, e.g., by using source authentication to ensure
that receivers only accept legitimate Session Descriptions from
authorized senders. How this is done is outside the scope of this
document.
6. IANA Considerations
No information in this specification is directly subject to IANA
registration. However, building blocks components used by ALC may
introduce additional IANA considerations. In particular, the FEC
building block used by ALC does require IANA registration of the FEC
codecs used.
7. Intellectual Property Issues
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
8. Acknowledgments
Thanks to Vincent Roca, Justin Chapweske and Roger Kermode for their
detailed comments on this document.
9. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2616, January 1997.
[5] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement
Protocol", RFC2974, October 2000.
[7] Holbrook, H. W., "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer
Science, Stanford, California, August 2001.
[8] Kermode, R., Vicisano, L., "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol
Instantiation documents", RFC3269, April 2002.
[9] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M. and
J. Crowcroft, "The Use of Forward Error Correction (FEC) in
Reliable Multicast", RFC3453, December 2002.
[10] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and
J. Crowcroft, "Forward Error Correction (FEC) Building Block",
RFC3452, December 2002.
[11] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
RFC3451 December 2002.
[12] Mankin, A., Romanow, A., Bradner, S. and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC2357, June 1998.
[13] Murata, M., St.Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[14] Perrig, A., Canetti, R., Song, D. and J.D. Tygar, "Efficient and
Secure Source Authentication for Multicast", Network and
Distributed System Security Symposium, NDSS 2001, pp. 35-46,
February 2001.
[15] Postel, J., "User Datagram Protocol", STD 6, RFC768, August
1980.
[16] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.
and M. Luby, "Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer", RFC3048, January 2001.
Authors' Addresses
Michael Luby
Digital Fountain
39141 Civic Center Dr.
Suite 300
Fremont, CA, USA, 94538
EMail: luby@digitalfountain.com
Jim Gemmell
Microsoft Research
455 Market St. #1690
San Francisco, CA, 94105
EMail: jgemmell@microsoft.com
Lorenzo Vicisano
cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA, USA, 95134
EMail: lorenzo@cisco.com
Luigi Rizzo
Dip. Ing. dell'Informazione,
Univ. di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
EMail: luigi@iet.unipi.it
Jon Crowcroft
Marconi Professor of Communications Systems
University of Cambridge
Computer Laboratory
William Gates Building
J J Thomson Avenue
Cambridge CB3 0FD, UK
EMail: Jon.Crowcroft@cl.cam.ac.uk
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.