GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5775

Internet Engineering Task Force (IETF) M. Luby Request for Comments: 5775 M. Watson Obsoletes: 3450 L. Vicisano Category: Standards Track Qualcomm, Inc. ISSN: 2070-1721 April 2010

      Asynchronous Layered Coding (ALC) Protocol Instantiation

Abstract

 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 RFC 3450.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5775.

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Luby, et al. Standards Track [Page 1] RFC 5775 ALC Protocol Instantiation April 2010

 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1.  Delivery Service Models  . . . . . . . . . . . . . . . . .  4
   1.2.  Scalability  . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3.  Environmental Requirements and Considerations  . . . . . .  5
 2.  Architecture Definition  . . . . . . . . . . . . . . . . . . .  5
   2.1.  LCT Building Block . . . . . . . . . . . . . . . . . . . .  7
   2.2.  Multiple Rate Congestion Control Building Block  . . . . .  9
   2.3.  FEC Building Block . . . . . . . . . . . . . . . . . . . . 10
   2.4.  Session Description  . . . . . . . . . . . . . . . . . . . 11
   2.5.  Packet Authentication Building Block . . . . . . . . . . . 12
 3.  Conformance Statement  . . . . . . . . . . . . . . . . . . . . 12
 4.  Functionality Definition . . . . . . . . . . . . . . . . . . . 13
   4.1.  Packet Format Used by ALC  . . . . . . . . . . . . . . . . 13
   4.2.  LCT Header Extension Fields  . . . . . . . . . . . . . . . 14
   4.3.  Sender Operation . . . . . . . . . . . . . . . . . . . . . 15
   4.4.  Receiver Operation . . . . . . . . . . . . . . . . . . . . 15
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   5.1.  Baseline Secure ALC Operation  . . . . . . . . . . . . . . 18
     5.1.1.  IPsec Approach . . . . . . . . . . . . . . . . . . . . 18
     5.1.2.  IPsec Requirements . . . . . . . . . . . . . . . . . . 19
 6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
 7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
 8.  Changes from RFC 3450  . . . . . . . . . . . . . . . . . . . . 21
 9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
   9.2.  Informative References . . . . . . . . . . . . . . . . . . 23

Luby, et al. Standards Track [Page 2] RFC 5775 ALC Protocol Instantiation April 2010

1. Introduction

 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.
 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.
 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.
 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.
 This document is a product of the IETF RMT WG and follows the general
 guidelines provided in [RFC3269].

Luby, et al. Standards Track [Page 3] RFC 5775 ALC Protocol Instantiation April 2010

 A previous version of this document was published in the
 "Experimental" category as [RFC3450] and is obsoleted by this
 document.
 This Proposed Standard specification is thus based on and backwards
 compatible with the protocol defined in [RFC3450] 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.
 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, [RFC2119].

1.1. Delivery Service Models

 ALC can support several different reliable content delivery service
 models as described in [RFC5651].

1.2. Scalability

 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:
 o  To each receiver, it appears as if 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.
 o  To the sender, there is no difference in load or outgoing rate if
    one receiver or a million (or any number of) receivers are joined
    to the session, independent of when the receivers join and leave.
 o  No feedback packets are required from receivers to the sender.
 o  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.
 Thus, ALC provides a massively scalable content delivery transport
 that is network friendly.

Luby, et al. Standards Track [Page 4] RFC 5775 ALC Protocol Instantiation April 2010

 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.

1.3. Environmental Requirements and Considerations

 All of the environmental requirements and considerations that apply
 to the LCT building block [RFC5651], the FEC building block
 [RFC5052], the multiple rate congestion control building block, and
 to any additional building blocks that ALC uses also apply to ALC.
 The IP multicast model defined in [RFC1112] is commonly known as Any-
 Source Multicast (ASM), in contrast to Source-Specific Multicast
 (SSM) which is defined in [RFC3569].  One issue 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) [RFC3618] 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.

2. Architecture Definition

 ALC uses the LCT building block [RFC5651] to provide in-band session
 management functionality.  ALC uses a multiple rate congestion
 control building block that is compliant with [RFC2357] 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
 [RFC5052] 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

Luby, et al. Standards Track [Page 5] RFC 5775 ALC Protocol Instantiation April 2010

 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.
 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 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.
 ALC is a protocol instantiation as defined in [RFC3048].  This
 document describes version 1 of ALC, which MUST use version 1 of LCT
 described in [RFC5651].  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 [RFC0768] that supports the IP
 multicast delivery of packets.
 The ALC packet format is illustrated in Figure 1.  An ALC packet
 header immediately follows the IP/UDP header and consists of the
 default LCT header that is described in [RFC5651] followed by the FEC
 Payload ID that is described in [RFC5052].  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
 [RFC2357].  The packet payload that follows the ALC packet header
 consists of encoding symbols that are identified by the FEC Payload
 ID as described in [RFC5052].

Luby, et al. Standards Track [Page 6] RFC 5775 ALC Protocol Instantiation April 2010

             +----------------------------------------+
             |               IP Header                |
             +----------------------------------------+
             |              UDP Header                |
             +----------------------------------------+
             |              LCT Header                |
             +----------------------------------------+
             |            FEC Payload Id              |
             +----------------------------------------+
             |           Encoding Symbols             |
             +----------------------------------------+
                      Figure 1: ALC Packet Format
 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
 [RFC5052] 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.

2.1. LCT Building Block

 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.
 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.
 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

Luby, et al. Standards Track [Page 7] RFC 5775 ALC Protocol Instantiation April 2010

 Information, as specified in the FEC building block [RFC5052], 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.
 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.
 If only one object is carried within a session, then the TOI MAY be
 omitted from the LCT header.
 The LCT header from version 1 of the LCT building block [RFC5651]
 MUST be used.
 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:
     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|...
                +-+-+
                 Figure 2: PSI Bits within LCT Header
    PSI bit X - Source Packet Indicator (SPI)
    PSI bit Y - Reserved
 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, 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 packets containing repair data is used.  In the case of FEC

Luby, et al. Standards Track [Page 8] RFC 5775 ALC Protocol Instantiation April 2010

 Schemes that define only a single FEC Payload ID format, the SPI MUST
 be set to zero by the sender and MUST be ignored by the receiver.
 Support of two FEC Payload ID formats allows FEC Payload ID
 information that 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 that do not perform FEC decoding (either because no FEC
 decoding is required or because the receiver does not support FEC
 decoding).

2.2. Multiple Rate Congestion Control Building Block

 At a minimum, implementations of ALC MUST support [RFC3738].  Note
 that [RFC3738] 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.
 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.  [RFC3738] specifies in-band
 Congestion Control Information (CCI) that MUST be carried in the CCI
 field of the LCT header.
 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 Section 2.4).  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.
 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 to which set of channels
 they are joined at each point in time depending on the available
 bandwidth between the receiver and the sender, but independent of
 other receivers.

Luby, et al. Standards Track [Page 9] RFC 5775 ALC Protocol Instantiation April 2010

2.3. FEC Building Block

 The FEC building block [RFC5052] provides reliable object delivery
 within an ALC session.  Each object sent in the session is
 independently encoded using FEC codes as described in [RFC3453],
 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.
 As described in [RFC5052], 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:
 o  The FEC Encoding ID.
 o  If an Under-Specified FEC Encoding ID is used, then the FEC
    Instance ID associated with the FEC Encoding ID.
 o  For each object in the session, the transfer length of the object
    in bytes.
 Additional FEC Object Transmission Information may be required
 depending on the FEC Scheme that is used (identified by the FEC
 Encoding ID).
 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.
 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

Luby, et al. Standards Track [Page 10] RFC 5775 ALC Protocol Instantiation April 2010

 times, the objects may not know when the session begins, 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 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.

2.4. Session Description

 Before a receiver can join an ALC session, the receiver needs to
 obtain a Session Description that contains the following information:
 o  The multiple rate congestion control building block to be used for
    the session;
 o  The sender IP address;
 o  The number of channels in the session;
 o  The address and port number used for each channel in the session;
 o  The Transport Session ID (TSI) to be used for the session;
 o  An indication of whether or not the session carries packets for
    more than one object;
 o  If Header Extensions are to be used, the format of these Header
    Extensions.
 o  Enough information to determine the packet authentication scheme
    being used, if one is being used.
 How the Session Description is communicated to receivers is outside
 the scope of this document.
 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

Luby, et al. Standards Track [Page 11] RFC 5775 ALC Protocol Instantiation April 2010

 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.
 The Session Description could also include, but is not limited to:
 o  The mappings between combinations of settings and Codepoint
    values;
 o  The data rates used for each channel;
 o  The length of the packet payload;
 o  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.
 The Session Description could be in a form such as the Session
 Description Protocol (SDP) as defined in [RFC4566], XML metadata as
 defined in [RFC3023], or HTTP/MIME headers as defined in [RFC2616],
 etc.  It might be carried in a session announcement protocol such as
 SAP as defined in [RFC2974], obtained using a proprietary session
 control protocol, located on a web page with scheduling information,
 or conveyed via email 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.

2.5. Packet Authentication Building Block

 It is RECOMMENDED that implementors of ALC use some packet
 authentication scheme to protect the protocol from attacks.  Suitable
 schemes are described in [RFC5776] and [RMT-SIMPLE].

3. Conformance Statement

 This Protocol Instantiation document, in conjunction with the LCT
 building block [RFC5651], the FEC building block [RFC5052], and
 [RFC3738] completely specifies a working reliable multicast transport
 protocol that conforms to the requirements described in [RFC2357].

Luby, et al. Standards Track [Page 12] RFC 5775 ALC Protocol Instantiation April 2010

4. Functionality Definition

 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.

4.1. Packet Format Used by ALC

 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 [RFC5651] and the
 FEC Payload ID is described in the FEC building block [RFC5052].  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 from
 which object the encoding symbols are generated.  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.
 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 [RFC5651].
 The overall ALC packet format is depicted in Figure 3.  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.

Luby, et al. Standards Track [Page 13] RFC 5775 ALC Protocol Instantiation April 2010

      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)                        |
     |                           ...                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 3: Overall ALC Packet Format
 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.
 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.

4.2. LCT Header Extension Fields

 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.
 The Header Extension Content (HEC) field of the EXT_FTI LCT Header
 Extension contains the encoded FEC Object Transmission Information as
 defined in [RFC5052].  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.

Luby, et al. Standards Track [Page 14] RFC 5775 ALC Protocol Instantiation April 2010

4.3. Sender Operation

 The sender operation, when using ALC, includes all the points made
 about the sender operation when using the LCT building block
 [RFC5651], the FEC building block [RFC5052], and the multiple rate
 congestion control building block.
 A sender using ALC should make available the required Session
 Description as described in Section 2.4.  A sender should also 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 it 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.  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.
 It is RECOMMENDED that packet authentication be used.  If packet
 authentication is used, then the Header Extensions described in
 Section 4.2 MAY be used to carry the authentication.

4.4. Receiver Operation

 The receiver operation, when using ALC, includes all the points made
 about the receiver operation when using the LCT building block
 [RFC5651], the FEC building block [RFC5052], and the multiple rate
 congestion control building block.
 To be able to participate in a session, a receiver needs to obtain
 the required Session Description as listed in Section 2.4.  How
 receivers obtain a Session Description is outside the scope of this
 document.
 As described in Section 2.3, a receiver needs to obtain the required
 FEC Object Transmission Information for each object for which the
 receiver receives and processes packets.

Luby, et al. Standards Track [Page 15] RFC 5775 ALC Protocol Instantiation April 2010

 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.
 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 to which the receiver is currently joined.  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.
 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 silently discard the packet.

5. Security Considerations

 The same security considerations that apply to the LCT, FEC, and the
 multiple rate congestion control building blocks also apply to ALC.
 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.

Luby, et al. Standards Track [Page 16] RFC 5775 ALC Protocol Instantiation April 2010

 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 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.
 [RMT-SIMPLE]and [RFC5776] described packet level authentication
 schemes that can be used with the ALC protocol.
 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.  Timed Efficient Stream Loss-Tolerant
 Authentication (TESLA) [RFC5776] 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.
 Some packet authentication schemes such as TESLA [RFC5776] do not
 allow an immediate authenticity check.  In this case, the receiver

Luby, et al. Standards Track [Page 17] RFC 5775 ALC Protocol Instantiation April 2010

 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 that fail authentication checks within a session, 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.
 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.

5.1. Baseline Secure ALC Operation

 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 of an
 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 [RFC3550] and as preserved in the
 specification for Secure Real Time Protocol (SRTP) [RFC3711].
 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.

5.1.1. IPsec Approach

 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.
 The ALC sender SHALL use an IPsec SA configured for Encapsulating
 Security Payload (ESP) protocol [RFC4303] 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

Luby, et al. Standards Track [Page 18] RFC 5775 ALC Protocol Instantiation April 2010

 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.
 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.
 In early deployments of this baseline approach to ALC security, it is
 anticipated 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.  An 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.

5.1.2. IPsec Requirements

 In order to implement this secure mode of ALC protocol operation, the
 following IPsec capabilities are required.

5.1.2.1. Selectors

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

Luby, et al. Standards Track [Page 19] RFC 5775 ALC Protocol Instantiation April 2010

5.1.2.2. Mode

 IPsec in transport mode MUST be supported.  The use of IPsec
 [RFC4301] processing for secure ALC traffic SHOULD also be REQUIRED
 such that unauthenticated packets are not received by the ALC
 protocol implementation.

5.1.2.3. Key Management

 An automated key management scheme for group key distribution and
 rekeying such as the Group Domain of Interpretation (GDOI) [RFC3547],
 Group Secure Association Key Management Protocol (GSAKMP) [RFC4535],
 or Multimedia Internet KEYing (MIKEY) [RFC3830] 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) [RFC4303] 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.

5.1.2.4. Security Policy

 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.

5.1.2.5. Authentication and Encryption

 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.

5.1.2.6. Availability

 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 allow the
 needed system IPsec configuration.

Luby, et al. Standards Track [Page 20] RFC 5775 ALC Protocol Instantiation April 2010

6. IANA Considerations

 This specification registers one value in the LCT Header Extensions
 Types namespace as follows:
               +-------+---------+--------------------+
               | Value | Name    | Reference          |
               +-------+---------+--------------------+
               | 64    | EXT_FTI | This specification |
               +-------+---------+--------------------+

7. Acknowledgments

 This specification is substantially based on RFC 3450 [RFC3450] and
 thus credit for the authorship of this document is primarily due to
 the authors of RFC 3450: Mike Luby, Jim Gemmel, Lorenzo Vicisano,
 Luigi Rizzo, and Jon Crowcroft.  Vincent Roca, Justin Chapweske, and
 Roger Kermode also contributed to RFC 3450.  Additional thanks are
 due to Vincent Roca and Rod Walsh for contributions to this update to
 Proposed Standard.

8. Changes from RFC 3450

 This section summarizes the changes that were made from the
 "Experimental" version of this specification published as RFC 3450
 [RFC3450]:
 o  Updated all references to the obsoleted RFC 2068 to RFC 2616.
 o  Removed the 'Statement of Intent' from the introduction.  (The
    Statement of Intent was meant to clarify the "Experimental" status
    of RFC 3450.)
 o  Removed the 'Intellectual Property Issues' Section and replaced
    with a standard IPR Statement.
 o  Removed material duplicated in LCT.
 o  Updated references in this document to new versions of the LCT
    Building Block and the FEC Building Block, and aligned this
    document with changes in the new version of the FEC Building
    Block.
 o  Split normative and informative references.
 o  Material applicable in a general LCT context, not just for ALC has
    been moved to LCT.

Luby, et al. Standards Track [Page 21] RFC 5775 ALC Protocol Instantiation April 2010

 o  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 that
    can be processed by receivers that do not support FEC Decoding.
 o  Definition and IANA registration of the EXT_FTI LCT Header
    Extension.

9. References

9.1. Normative References

 [RFC0768]     Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.
 [RFC1112]     Deering, S., "Host extensions for IP multicasting",
               STD 5, RFC 1112, August 1989.
 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
               Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
               Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 [RFC3023]     Murata, M., St. Laurent, S., and D. Kohn, "XML Media
               Types", RFC 3023, January 2001.
 [RFC3738]     Luby, M. and V. Goyal, "Wave and Equation Based Rate
               Control (WEBRC) Building Block", RFC 3738, April 2004.
 [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
               Internet Protocol", RFC 4301, December 2005.
 [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
               RFC 4303, December 2005.
 [RFC4566]     Handley, M., Jacobson, V., and C. Perkins, "SDP:
               Session Description Protocol", RFC 4566, July 2006.
 [RFC5052]     Watson, M., Luby, M., and L. Vicisano, "Forward Error
               Correction (FEC) Building Block", RFC 5052,
               August 2007.
 [RFC5651]     Luby, M., Watson, M., and L. Vicisano, "Layered Coding
               Transport (LCT) Building Block", RFC 5651,
               October 2009.

Luby, et al. Standards Track [Page 22] RFC 5775 ALC Protocol Instantiation April 2010

9.2. Informative References

 [RFC2357]     Mankin, A., Romanov, A., Bradner, S., and V. Paxson,
               "IETF Criteria for Evaluating Reliable Multicast
               Transport and Application Protocols", RFC 2357,
               June 1998.
 [RFC2974]     Handley, M., Perkins, C., and E. Whelan, "Session
               Announcement Protocol", RFC 2974, October 2000.
 [RFC3048]     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",
               RFC 3048, January 2001.
 [RFC3269]     Kermode, R. and L. Vicisano, "Author Guidelines for
               Reliable Multicast Transport (RMT) Building Blocks and
               Protocol Instantiation documents", RFC 3269,
               April 2002.
 [RFC3450]     Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
               Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
               Instantiation", RFC 3450, December 2002.
 [RFC3453]     Luby, M., Vicisano, L., Gemmell, J., Rizzo, L.,
               Handley, M., and J. Crowcroft, "The Use of Forward
               Error Correction (FEC) in Reliable Multicast",
               RFC 3453, December 2002.
 [RFC3547]     Baugher, M., Weis, B., Hardjono, T., and H. Harney,
               "The Group Domain of Interpretation", RFC 3547,
               July 2003.
 [RFC3550]     Schulzrinne, H., Casner, S., Frederick, R., and V.
               Jacobson, "RTP: A Transport Protocol for Real-Time
               Applications", STD 64, RFC 3550, July 2003.
 [RFC3569]     Bhattacharyya, S., "An Overview of Source-Specific
               Multicast (SSM)", RFC 3569, July 2003.
 [RFC3618]     Fenner, B. and D. Meyer, "Multicast Source Discovery
               Protocol (MSDP)", RFC 3618, October 2003.
 [RFC3711]     Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
               K. Norrman, "The Secure Real-time Transport Protocol
               (SRTP)", RFC 3711, March 2004.

Luby, et al. Standards Track [Page 23] RFC 5775 ALC Protocol Instantiation April 2010

 [RFC3830]     Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and
               K. Norrman, "MIKEY: Multimedia Internet KEYing",
               RFC 3830, August 2004.
 [RFC4535]     Harney, H., Meth, U., Colegrove, A., and G. Gross,
               "GSAKMP: Group Secure Association Key Management
               Protocol", RFC 4535, June 2006.
 [RFC5776]     Roca, V., Francillon, A., and S. Faurite, "Use of Timed
               Efficient Stream Loss-Tolerant Authentication (TESLA)
               in the Asynchronous Layered Coding (ALC) and NACK-
               Oriented Reliable Multicast (NORM) Protocols",
               RFC 5776, April 2010.
 [RMT-SIMPLE]  Roca, V., "Simple Authentication Schemes for the ALC
               and NORM Protocols", Work in Progress, October 2009.

Authors' Addresses

 Michael Luby
 Qualcomm, Inc.
 3165 Kifer Road
 Santa Clara, CA  95051
 US
 EMail: luby@qualcomm.com
 Mark Watson
 Qualcomm, Inc.
 3165 Kifer Road
 Santa Clara, CA  95051
 US
 EMail: watson@qualcomm.com
 Lorenzo Vicisano
 Qualcomm, Inc.
 3165 Kifer Road
 Santa Clara, CA  95051
 US
 EMail: vicisano@qualcomm.com

Luby, et al. Standards Track [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5775.txt · Last modified: 2010/04/06 16:14 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki