[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 draft-ietf-rmt-flute-sdp

RMT                                                             H. Mehta
Internet-Draft                                                  R. Walsh
Expires: January 10, 2005                                          Nokia
                                                            J. Peltotalo
                                                            S. Peltotalo
                                        Tampere University of Technology
                                                           July 12, 2004


                       SDP Descriptors for FLUTE
                    draft-mehta-rmt-flute-sdp-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 January 10, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document specifies the use of SDP to describe the parameters
   required to begin, join, receive data from, and end FLUTE sessions.










Mehta, et al.           Expires January 10, 2005                [Page 1]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Conventions Used in This Document  . . . . . . . . . . . . .  4
   3.    FLUTE Descriptors  . . . . . . . . . . . . . . . . . . . . .  5
   3.1   FLUTE Protocol ID  . . . . . . . . . . . . . . . . . . . . .  5
   3.2   IP Source Address  . . . . . . . . . . . . . . . . . . . . .  6
   3.3   Transport Session Identifier . . . . . . . . . . . . . . . .  6
   3.4   Session Timing Parameters  . . . . . . . . . . . . . . . . .  7
   3.5   Channelisation Descriptors . . . . . . . . . . . . . . . . .  7
   3.5.1 Number of channels . . . . . . . . . . . . . . . . . . . . .  7
   3.5.2 Destination IP address and port number for channels  . . . .  8
   3.6   Content Description  . . . . . . . . . . . . . . . . . . . .  9
   3.6.1 Content Description Pointer  . . . . . . . . . . . . . . . .  9
   4.    SDP Syntax Example . . . . . . . . . . . . . . . . . . . . . 10
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 11
   6.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
         References . . . . . . . . . . . . . . . . . . . . . . . . . 13
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
         Intellectual Property and Copyright Statements . . . . . . . 15































Mehta, et al.           Expires January 10, 2005                [Page 2]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


1. Introduction

   The Session Description Protocol [5] provides a general-purpose
   format for describing multimedia sessions in announcements or
   invitations. SDP uses an entirely textual data format (the US-ASCII
   subset of UTF-8 [8]) to maximize portability among transports. SDP
   does not define a protocol, but only the syntax to describe a
   multimedia session with sufficient information to participate in that
   session. Session descriptions may be sent using arbitrary existing
   application protocols for transport (e.g. FLUTE [1], SAP [9], SIP
   [10], email, HTTP [11] etc.).

   SDP [5] defines two protocol identifiers that represent unreliable
   connectionless protocols. These are RTP/AVP and UDP. These are
   appropriate choices for multimedia streams.
   draft-ietf-mmusic-sdp-comedia-07.txt [12] defines protocol
   identifiers for connection-oriented reliable transports: TCP and TCP/
   TLS. RFC 3266 [6] describes SDP support for IPV6.

   This document defines a new protocol identifier for FLUTE and other
   required descriptors for initiating a FLUTE session. The formal ABNF
   syntax [4] is used for the descriptors.





























Mehta, et al.           Expires January 10, 2005                [Page 3]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


2. 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 [2].














































Mehta, et al.           Expires January 10, 2005                [Page 4]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


3. FLUTE Descriptors

   The FLUTE specification [1] describes the optional and required
   parameters for a FLUTE session. This document specifies the SDP
   parameters for FLUTE sessions that can be used for the discovery of
   FLUTE download and service announcement sessions.

   The required parameters are:

   o  The sender IP address

   o  The number of channels in the session

   o  The destination IP address and port number for each channel in the
      session

   o  The Transport Session Identifier (TSI) of the session

   Optionally, the following parameters may be associated with the
   session:

   o  The start and end time of the session

   o  FEC Encoding ID and FEC Instance ID

   o  Some information that tells the receiver in the first place, that
      the session contains files that are of interest

   The description of these parameters in SDP is presented in the
   following sections.

3.1 FLUTE Protocol ID

   The following is the ABNF syntax for an m= line, as specified by RFC
   2327 [5]:

            media-field =       "m=" media space port ["/" integer]
                            space proto 1*(space fmt) CRLF

   We define a new value for the proto field: FLUTE/UDP. The FLUTE/UDP
   descriptor specifies that the session being described will use the
   File Delivery over Unidirectional Transport (FLUTE) protocol on top
   of a UDP connection. All media with this protocol ID belong to the
   same FLUTE session.

   An m= line that contains the FLUTE/UDP protocol identifier MUST
   further qualify the protocol using an 'fmt' [5] identifier.




Mehta, et al.           Expires January 10, 2005                [Page 5]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


   Each complete SDP session description will describe only one FLUTE
   session. This arises from the limitation of SDP that no session level
   details can be specified after the "m=" line.

3.2 IP Source Address

   The LCT specification [3] requires that all the channels of a single
   LCT session are from the same source IP address. Hence, there MUST be
   exactly one IP sender address per FLUTE session, and therefore one IP
   address per each complete SDP description of a FLUTE session.

   The IP source address shall be defined according to the source-filter
   attribute ("a=source-filter") [5, 7], with the following exceptions:

   o  Exactly one source address may be specified by this attribute such
      that exclusive-mode shall not be used and inclusive-mode shall use
      exactly one source address in the 'src-list'.

   o  There shall be exactly one source-filter attribute per complete
      FLUTE session SDP description, and this shall be in the session
      part of the session description (i.e. not per media).

   o  The * value shall be used for the 'dest-address' subfield, even
      when the FLUTE session employs only a single LCT (multicast)
      channel.

   An example of the use of this attribute is:

            a=source-filter: incl IN IP6 *
             2001:210:1:2:240:96FF:FE25:8EC9


   This example uses the source-filter attribute to describe an IPv6
   source address.

3.3 Transport Session Identifier

   The combination of the TSI and the IP source address identifies the
   session. Each TSI MUST uniquely identify a FLUTE session for a given
   IP source address during the time that the session is active and also
   for a large time before and after the active session time. This
   requirement is also specified by [3]. There MUST be exactly one
   occurence of the TSI SDP descriptor in a complete SDP FLUTE session
   description and it MUST appear at the session level.

   The ABNF syntax for the TSI descriptor is given below:

           sdp-flute-tsi-line = "a=flute-tsi:" value CRLF



Mehta, et al.           Expires January 10, 2005                [Page 6]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


           where value = %d


3.4 Session Timing Parameters

   The SDP timing field "t=" [5] may be optionally used to indicate the
   FLUTE session start and end times.

3.5 Channelisation Descriptors

   This section specifies the description of the channel(s) used within
   a FLUTE session. The required parameters for channel description are:

   o  Number of channels

   o  Destination IP address and port number for channels


3.5.1 Number of channels

   The FLUTE specification allows for the use of multiple LCT channels
   (multicast groups) to transport the files of a single FLUTE session.
   This is referred to as FLUTE session channelisation in this document.
   FLUTE session channelisation is defined according to a new SDP
   attribute at session level as specified in this document. Details of
   each channel are defined by SDP media level information also
   described in this document.

   The multiple channel attribute describes the number of channels used
   by the sender to transmit. It may also be used to check the number of
   channels against the SDP "m=" lines.

   The syntax for the attribute in ABNF is as follows:

           sdp-flute-channel-line = "a=flute-ch:" value CRLF
           where value = %d,
           value is the number of channels used by the sender to
           transmit data in a FLUTE session.

   This parameter indicates to the receiver that the sender is using
   multiple channels in the FLUTE session to transmit data. This also
   indicates the number of channels used by the sender. The value
   specified by this descriptor can be used by the receiver to check
   that it has received all the m-lines describing the destinations. For
   example, if the value of this parameter is 2, then there should be 2
   channels specified by the m-lines. An example is given in section 4.

   In the absence of this descriptor, a receiver shall understand that



Mehta, et al.           Expires January 10, 2005                [Page 7]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


   exactly one FLUTE channel is used for the FLUTE session.

3.5.2 Destination IP address and port number for channels

   One or more channels MUST be described by the media-level channel
   descriptors. The number of channels shall be inferred from the
   channel parameters. These channel parameters shall be per channel:

   o  IP destination address

   o  Destination port number

   The IP destination address shall be defined according to the
   connection data field ("c=") of SDP [5]. The destination port number
   shall be defined according to the "port" sub-field of the media
   announcement field ("m=") of SDP [5].

   Although it is generally recommended that multiple channels are
   differentiated by IP destination address, in the case that the same
   destination IP address is used for all the channels of a session and
   only the destination port number differentiates channels, the IP
   destination address may be given by the connection data field at
   session-level for all channels (if so, the connection data field
   shall not be used at media-level).

   Exactly one destination port MUST be used per FLUTE channel. When
   more than one session channel is used, it is recommended that the
   channels are differentiated based on destination/group IP address
   (other parameters may vary too, but channel differentiation based on
   destination port with the same destination address is considered
   unnecessary, complex and potentially harmful). Thus, it is
   recommended that the "number of ports" option in the SDP "m" line is
   not used (or used only with a value of 1). If the value is greater
   than 1, this indicates that number of FLUTE channels.

   For per channel description of the IP destination address, IP
   destination address values must be given at media-level, i.e.
   following an "m=" descriptor.

   The sequence of multiple channels shall be determined by the order in
   which their media descriptions are defined in the session description
   (i.e. the first media description gives the first channel in the
   sequence). In the case of the slash notation usage for specifying
   multiple destination addresses or ports, the order of the channel
   sequence shall be lowest value first and highest last; and in the
   case of slash notation for both destination address and port of a
   media-level description the channel sequence will be from the lowest
   address value and incremented through the range.



Mehta, et al.           Expires January 10, 2005                [Page 8]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


   Also we need to indicate the presence of a FLUTE session on a certain
   channel. This is done by using the "m=" line in the SDP description
   as shown in the following example:

           m=application 12345 FLUTE/UDP 0
           c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1

   In the above SDP attributes, the "m" line indicates the media used
   and the c-line indicates the corresponding channel. Thus, in the
   above example, the m-line indicates that the media is transported on
   a channel that uses FLUTE over UDP. Further, the c-line indicates the
   channel address, which, in this case, is an IPv6 address.

3.6 Content Description

   In the context of a FLUTE session, two forms of content description
   are important:

   o  The out-of-band URI or content description pointer that may signal
      to the receiver that the FLUTE session is transmitting something
      of interest, and,

   o  The media type(s) of the files being transmitted during the FLUTE
      session.


3.6.1 Content Description Pointer

   The syntax of the information that tells receiver, in the first
   place, that the session contains files that are of interest is out of
   scope of this document. However, the SDP may include a Content
   description pointer to enable efficient linkage to such information.

   The content descriptor pointer attribute describes how the sender
   indicates to the receiver the URI where the content description is
   stored. The content descriptor pointer shall be defined according to
   the following SDP descriptor.

   The syntax in ABNF is given below:

           sdp-content-desc-line = "a=content-desc:" URI-reference CRLF
           where URI-reference = as defined in RFC 2396

   URI is a valid URI for the Content Description.  The URI may be of an
   XML definition, such as one defined according to the FDT Instance
   schema (as described in [1]).





Mehta, et al.           Expires January 10, 2005                [Page 9]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


4. SDP Syntax Example

   This section gives an example of the use of SDP attributes to
   describe a FLUTE session.

           v=0
           o=user123 2890844526 2890842807 IN IP6
            2201:056D::112E:144A:1E24
           s=File delivery session example
           i=More information
           t=2873397496 2873404696
           a=source-filter: incl IN IP6 *
            2001:210:1:2:240:96FF:FE25:8EC9
           a=flute-tsi: 3
           a=flute-ch: 2
           m=data 12345 FLUTE/UDP 0
           c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1
           m=data 12346 FLUTE/UDP 0
           c=IN IP6 FF1E:03AD::7F2E:172A:1E30/1

   The sender indicates in the above example that it will transmit data
   in the FLUTE session on two channels (a=flute-ch:2). The sender then
   specifies the channels.

   These channels are indicated in the line c=IN IP6
   FF1E:03AD::7F2E:172A:1E30/1. This also shows to the receivers that
   the channels are two (maybe more in other cases) consecutive
   channels.

   The attribute TSI defined in the line a=flute-tsi:3 describes the TSI
   (Transmission Session Identifier) for the session.

   The line m=data 12345 FLUTE/UDP indicates the media used for the
   channel. In this example, there are two 'm' lines for the two
   channels described. The a ttribute defined in the line
   a=source-filter: incl IN IP6 * 2001:210:1:2:240:96FF:FE25:8EC9
   describes a source filter. In this example the sender indicates that
   the receivers should include the given IP address
   (2001:210:1:2:240:96FF:FE25:8EC9) into the session. This pair of the
   (source IP address, TSI) together uniquely identifies a session. It
   should be noted that although other possibilities may be used, in
   this case only the incl and * attributes may be used in the above
   descriptor.

   The line m=data 12345 FLUTE/UDP indicates the media used for the
   channel. In this example, there are two 'm' lines for the two
   channels described.




Mehta, et al.           Expires January 10, 2005               [Page 10]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


5. Security Considerations

   FLUTE implementations are subject to security considerations
   mentioned in [1]. There are no additional security considerations
   resulting from the testing guidelines mentioned in this draft.














































Mehta, et al.           Expires January 10, 2005               [Page 11]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


6. Acknowledgements

   The authors would like to thank Juha-Pekka Luoma for his
   contributions and feedback on this document.















































Mehta, et al.           Expires January 10, 2005               [Page 12]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


References

   [1]   Paila, T., Luby, M., Lehtonen, R. and V. Roca, "FLUTE - File
         Delivery over Unidirectional Transport",
         draft-ietf-rmt-flute-08 (work in progress), June 2004.

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, BCD 14, March 1997.

   [3]   Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M. and
         J. Crowcroft, "Layered Coding Transport (LCT) Building Block",
         RFC 3451, December 2002.

   [4]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.

   [5]   Handley, M. and V. Jacobson, "SDP: Session Description
         Protocol", RFC 2327, April 1998.

   [6]   Olson, S., Camarillo, G. and A. Roach, "Support for IPv6 in
         Session Description Protocol (SDP)", RFC 3266, June 2002.

   [7]   Quinn, B. and R. Finlayson, "Session Description Protocol (SDP)
         Source Filters", draft-ietf-mmusic-sdp-srcfilter-05 (work in
         progress), May 2003.

   [8]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         3629, November 2003.

   [9]   Handley, M., Perkins, C. and E. Whelan, "Session Announcement
         Protocol", RFC 2974, October 2000.

   [10]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "Session
         Initiation Protocol", RFC 3261, June 2002.

   [11]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., Berners-Lee, T. and E. Schooler, "Hypertext Tansfer
         Protocol -- HTTP/1.1", RFC 3261, June 2002.

   [12]  Yon, D. and G. Camarillo, "Connection-Oriented Media Transport
         in the Session Descript Protocol (SDP)",
         draft-ietf-mmusic-sdp-comedia-07.txt (work in progress),
         December 2004.







Mehta, et al.           Expires January 10, 2005               [Page 13]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


Authors' Addresses

   Harsh Mehta
   Nokia
   P.O. Box 100 (Visiokatu 1)
   Tampere  FIN-33721
   Finland

   EMail: harsh.mehta@nokia.com


   Rod Walsh
   Nokia
   P.O. Box 100 (Visiokatu 1)
   Tampere  FIN-33721
   Finland

   EMail: rod.walsh@nokia.com


   Jani Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere  FIN-33101
   Finland

   EMail: jani.peltotalo@tut.fi


   Sami Peltotalo
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere  FIN-33101
   Finland

   EMail: sami.peltotalo@tut.fi















Mehta, et al.           Expires January 10, 2005               [Page 14]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). 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 assignees.

   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



Mehta, et al.           Expires January 10, 2005               [Page 15]

Internet-Draft         SDP Descriptors for FLUTE               July 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Mehta, et al.           Expires January 10, 2005               [Page 16]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/