Internet DRAFT - draft-bouazizi-rmt-alcframing
draft-bouazizi-rmt-alcframing
Transport Group I. Bouazizi
Internet Draft Nokia Research Center
Expires: April 2007 October 30, 2006
Framing ALC Packets over Connection-Oriented Transport
draft-bouazizi-rmt-alcframing-00
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 30, 2007.
Abstract
ALC and FLUTE are reliable content delivery protocols designed mainly
for scalable multicast distribution. However, this does not preclude
their deployment in the Unicast distribution mode over connectionless
or connection-oriented transport protocols. A method for framing ALC
and FLUTE packets onto connection-oriented transport is presented. A
definition of the descriptors of the framing method for those
protocols is also given.
Bouazizi Expires April 30, 2007 [Page 1]
Internet-Draft ALC over Connection-Oriented Transport October 2006
Conventions used in this document
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 RFC-2119 Error!
Reference source not found..
Table of Contents
1. Introduction ................................................ 2
2. The Framing Method .......................................... 3
3. Keep-Alive Mechanism......................................... 3
4. Further Considerations ....................................... 4
5. Session Descriptions for FLUTE over TCP ...................... 4
6. Example ..................................................... 4
7. Congestion Control .......................................... 5
8. Security Considerations...................................... 5
9. IANA Considerations ......................................... 5
10. Acknowledgments ............................................ 5
11. References ................................................. 6
11.1. Normative References ................................... 6
11.2. Informative References ................................. 6
Author's Addresses ............................................. 6
Intellectual Property Statement ................................. 6
Disclaimer of Validity ......................................... 7
Copyright Statement ............................................ 7
Acknowledgment ................................................. 7
1. Introduction
The Asynchronous Layered Coding protocol [RFC3450] describes a
massively scalable protocol for content delivery over multicast
networks. ALC is composed of several building blocks such as the
Layered Coding Transport building block [RFC3451] and the Forward
Error Correction building block [RFC3452]. FLUTE [RFC3926] has been
defined to allow for a specific delivery of files and is based on
ALC. FLUTE is being deployed for file delivery in 3GPP Multimedia
Broadcast/Multicast Services (MBMS) [3GPPTS26.346] and in IPDC over
DVB-H [ETSITS102472].
In some situations, multicast delivery might not be possible or
useful. This may happen e.g. in mobile multicast, when the receiver
is out of coverage of the broadcast/multicast network. In such case,
the delivery of the same content over Unicast reliably seems to be an
attractive solution. However, none of the above protocols defines
Bouazizi Expires April 30, 2007 [Page 2]
Internet-Draft ALC over Connection-Oriented Transport October 2006
appropriate measures to allow for transport over connection-oriented
protocols (e.g. TCP).
This memo defines a framing method to allow for transport of
ALC/FLUTE packets over connection-oriented transport protocols.
Additionally, a mechanism for signaling the framing method use in
session descriptions (SDP) is introduced. The memo follows the design
principles and logic of [RFC4571], which defines a framing method for
RTP and RTCP for connection-oriented transport.
2. The Framing Method
The framing method is depicted in Figure 1.
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
+---------------------------------------------------------------+
| LENGTH | ALC/FLUTE packet |
+---------------------------------------------------------------+
Figure 1 Bit field definition of the framing method.
The LENGTH field is a 16-bit field unsigned integer that is coded in
network byte order (big-endian). If the LENGTH field is a non-zero
value, an ALC or FLUTE packet follows the LENGTH field. The LENGTH
field indicates the length in octets of the ALC/FLUTE packet. If the
value of LENGTH is zero, a null packet is assumed.
To check the validity of a frame (i.e. LENGTH field and ALC/FLUTE
packet), receivers SHOULD monitor the LCT packet header that follows
the LENGTH field. The header has predictable and locatable fields
such as the version field, the Codepoint field, and the Transport
Session Identifier (TSI) field.
3. Keep-Alive Mechanism
This memo defines a keep-alive mechanism that MAY be used by the
sender and receiver to terminate an inactive connection. The sender
MAY indicate a keep-alive timeout interval that the receiver MAY use
to teardown the session if no frames have been received during that
interval.
The keep-alive interval is signaled by an out-of-band mechanism. The
usage of the session description to signal the keep-alive interval is
described in section 5.
Bouazizi Expires April 30, 2007 [Page 3]
Internet-Draft ALC over Connection-Oriented Transport October 2006
If a keep-alive interval is signaled by the sender, the receiver
SHOULD teardown the ALC/FLUTE session if no frames is received for a
continuous period of time no shorter than the keep-alive time. When
selecting the keep-alive time, the sender SHOULD account for all
possible delay factors such as retransmission delays.
The sender MAY use null-packets, as defined in section 2, to maintain
the session if it anticipates that data will still be available for
transmission to the receiver.
4. Further Considerations
The framing method defined in this memo may be applied in an end-to-
end system or at certain paths of the end-to-end system, where
tunneling over TCP is required. This has the following consequences:
o The order of the packets cannot be guaranteed.
o Packet loss may occur and SHOULD be detected based on the EXT FTI
header by detecting gaps in Source Block Number and Encoding
Symbol IDs.
5. Session Descriptions for FLUTE over TCP
This memo is based on the SDP descriptors for FLUTE [draft-mehta-rmt-
flute-sdp]. Additionally, it defines the value "FLUTE/TCP" for the
proto sub-field in the media description field. "FLUTE/TCP" refers to
the deployment of FLUTE over TCP.
This memo also defines a new session-level attribute "a=session-
timeout", which is used to indicate the keep-alive time interval in
seconds. The syntax of the attribute in ABNF format is as follows:
session-timeout="a=session-timeout:" keep-alive-time
keep-alive-time = 1*DIGIT
; value is the keep-alive time interval
6. Example
The SDP description in Figure 2 is an example of the usage of the
current memo to describe a FLUTE session over TCP along with a keep-
alive time indication.
v=0
o=user 17102006 524685645 IN IP6 120::42A:C1:7B64
s=FLUTE over TCP session
i=Example of the session description
Bouazizi Expires April 30, 2007 [Page 4]
Internet-Draft ALC over Connection-Oriented Transport October 2006
t=3371675545 3371680487
a=source-filter: incl IN IP6 * 120::42A:C1:7B64
a=flute-tsi:145
a=flute-ch:1
a=session-timeout:200
m=application 12345 FLUTE/TCP *
c=IN IP6 FF15::4040
Figure 2 Bit field definition of the framing method.
7. Congestion Control
ALC and FLUTE MAY make use of the congestion control building block.
Furthermore, the deployment over TCP ensures that the ALC/FLUTE
session competes fairly with other TCP connections.
8. Security Considerations
Implementers SHOULD pay attention to the security considerations that
apply for FLUTE, ALC and LCT. Additionally, applications SHOULD be
able to deal with any LENGTH field value from 0 to 2^^16-1, as
attackers may use this field for exploiting security holes in the
application.
9. IANA Considerations
In section 5, a new value for the <proto> sub-field of the <media-description>
field "FLUTE/TCP" is defined. Section 5 also defines a session-level attribute
<a=session-timeout>. Section 6 gives an example of the usage of the new
definitions in SDP.
10. Acknowledgments
Bouazizi Expires April 30, 2007 [Page 5]
Internet-Draft ALC over Connection-Oriented Transport October 2006
11. References
11.1. Normative References
[RFC3450] M. Luby et al., "Asynchronous Layered Coding (ALC) Protocol
Initiation", RFC 3450, December 2002.
[RFC3451] M. Luby et al., "Layered Coding Transport (LCT) Building
Block", RFC 3451, December 2002.
[RFC3452] M. Luby et al., "Forward Error Correction (FEC) Building
Block", RFC 3451, December 2002.
[RFC3926] T. Paila et al., "FLUTE – File Delivery over Unidirectional
Transport", RFC 3926, October 2004.
[draft-mehta-rmt-flute-sdp] R. Walsh et al., "SDP descriptors for
FLUTE", draft-meht-rmt-flute-sdp-05, January 2006.
11.2. Informative References
rd
[3GPPTS26.346] "3 Generation Partnership Project; Technical
Specification Group Services and System Aspects; Multimedia
Broadcast/Multicast Service (MBMS); Protocols and codecs
(Release 7) ", September 2006.
[ETSITS102472] "Digital Video Broadcasting; IP Datacast over DVB-H:
Content Delivery Protocols", ETSI TS 102472, June 2006.
[RFC4571] J. Lazzaro, "Framing Real-time Transport Protocol (RTP) and
RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", July 2006.
Author's Addresses
Imed Bouazizi
Nokia Research Center
Visiokatu 1, 33720, Tampere
Email: imed.bouazizi@nokia.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
Bouazizi Expires April 30, 2007 [Page 6]
Internet-Draft ALC over Connection-Oriented Transport October 2006
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bouazizi Expires April 30, 2007 [Page 7]
