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

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

RMT                                                             R. Walsh
Internet-Draft                                     Nokia Research Center
Expires: July 31, 2006                                      J. Peltotalo
                                                            S. Peltotalo
                                        Tampere University of Technology
                                                                H. Mehta
                                                               I. Curcio
                                                                   Nokia
                                                        January 27, 2006


                       SDP Descriptors for FLUTE
                      draft-mehta-rmt-flute-sdp-05

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 July 31, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies the use of SDP to describe the parameters
   required to begin, join, receive data from, and/or end FLUTE
   sessions.  It also provides a Composite Session SDP media grouping



Walsh, et al.             Expires July 31, 2006                 [Page 1]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   semantic for grouping media streams into protocol-specific sessions,
   such as multiple-channel FLUTE sessions.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  FLUTE Descriptors  . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  FLUTE Protocol Identifier  . . . . . . . . . . . . . . . .  5
     3.2.  Composite Session Semantics  . . . . . . . . . . . . . . .  6
       3.2.1.  Composite Session Semantics for FLUTE Sessions . . . .  7
     3.3.  Source IP Address  . . . . . . . . . . . . . . . . . . . .  8
     3.4.  Transport Session Identifier . . . . . . . . . . . . . . .  9
     3.5.  Session Timing Parameters  . . . . . . . . . . . . . . . . 10
     3.6.  Channelisation Descriptors . . . . . . . . . . . . . . . . 10
       3.6.1.  Number of Channels . . . . . . . . . . . . . . . . . . 10
       3.6.2.  Destination IP Address and Port Number for Channels  . 11
     3.7.  FEC Object Transmission Information  . . . . . . . . . . . 13
     3.8.  Content Description Pointer  . . . . . . . . . . . . . . . 15
     3.9.  Bandwidth Specification  . . . . . . . . . . . . . . . . . 15
       3.9.1.  Bandwidth Specification for Composite Sessions . . . . 16
   4.  SDP Syntax Examples  . . . . . . . . . . . . . . . . . . . . . 17
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
     6.1.  Transport Protocol . . . . . . . . . . . . . . . . . . . . 21
       6.1.1.  Media formats ("fmt")  . . . . . . . . . . . . . . . . 21
     6.2.  Attribute Names  . . . . . . . . . . . . . . . . . . . . . 21
     6.3.  Composite Session Token to Differentiate FLUTE Sessions  . 22
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Use of FEC attributes with RTP sessions
                (informative) . . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 30













Walsh, et al.             Expires July 31, 2006                 [Page 2]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


1.  Introduction

   The Session Description Protocol (SDP) [6] 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 [9]) 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 [15], SIP
   [16], RTSP [20], HTTP [17], email etc.).

   SDP defines two protocol identifiers that represent unreliable
   connectionless protocols.  These are RTP/AVP and UDP.  These are
   appropriate choices for multimedia streams. [18] defines protocol
   identifiers for connection-oriented reliable transports: TCP and TCP/
   TLS.  RFC 3266 [7] describes SDP support for IPv6.

   This document defines a new protocol identifier for File Delivery
   over Unidirectional Transport (FLUTE) protocol [1] and other required
   SDP attributes for initiating a FLUTE session.  The formal ABNF
   syntax [5] is used for the attributes.  This SDP syntax is
   independent of Any Source Multicast (ASM) or Source Specific
   Multicast (SSM) is used to route the media.



























Walsh, et al.             Expires July 31, 2006                 [Page 3]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


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














































Walsh, et al.             Expires July 31, 2006                 [Page 4]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


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/or service announcement sessions.

   The required parameters are:

   o  The source 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

   o  The start time and end time of the session

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

   o  FEC Object Transmission Information

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

   o  Bandwidth specification

   The description of these parameters in SDP is presented in the
   following sections.  Note also that "v=", "o=" and "s=" lines are
   mandatory for SDP descriptions [6].

   The semantics of a FLUTE session within an SDP description differ
   slightly from that of the well-establish RTP session descriptions.  A
   FLUTE session includes one or more FLUTE channels which are each a
   distinct media flow.  Generally, each RTP media is recognised as a
   distinct RTP media session.  Hence, to preserve harmony with RTP
   media sessions within SDP descriptions, the optional Composite
   Session mechanism is specified, using the grouping framework [13].

3.1.  FLUTE Protocol Identifier

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

      media-field = "m=" media SP port ["/" integer] SP



Walsh, et al.             Expires July 31, 2006                 [Page 5]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


                    proto 1*(SP fmt) CRLF

   We define a new value for the "proto" sub-field: FLUTE/UDP.  The
   FLUTE/UDP protocol identifier specifies that the session being
   described will use the FLUTE [1] protocol on top of a UDP connection.

   As described below, more than one FLUTE session may be described by a
   single SDP using the Composite Session mechanism.

   The fmt (format) list may be ignored for FLUTE.  The fmt list of
   FLUTE "m=" lines MAY contain a single "*" character to indicate that
   miscellaneous and unspecified MIME types (file formats) are contained
   in the FLUTE session.  Use of any other values (MIME types) in a
   FLUTE fmt list is out of scope of this specification. "0" is known to
   be used in the fmt list to represent the same as "*", in a non
   standard way, and so implementers may take this into account.  An
   example of FLUTE/UDP protocol identifier is shown in section 4.

   FLUTE is a general file delivery protocol and so it is not considered
   necessary to identify a list of media types per FLUTE session or
   channel in the session description.

3.2.  Composite Session Semantics

   The Composite Session mechanism enables the grouping of media lines
   in to distinct sessions.  The complete Composite Session semantics
   are protocol-specific - as determined by the protocol id of the
   grouped media lines.  This section defines the Composite Session
   semantic generically and protocol id independently.  The following
   subsection defines the FLUTE/UDP protocol id specific semantic.

   The Composite Session mechanism inherits the "group" and "mid"
   attributes from the SDP grouping framework [13] and introduces the
   "CS" (Composite Session) token.  When a complete SDP description
   specifies only one FLUTE session, using the Composite Session
   mechanism is OPTIONAL.  When a complete SDP description specifies
   more than one FLUTE session, using the Composite Session mechanism is
   REQUIRED.

   When the Composite Session mechanism is used: the SDP grouping
   framework [13] MUST be used (and requirements from that are
   inherited); and the "CS" token MUST be used with the "group"
   attribute to indicate a Composite Session grouping.  The SDP grouping
   framework declares groups at session-level and labels media (with the
   "mid" attribute) at media-level.  Hence, all media identified by
   their "mid" values by an "a=group:CS" line belong to the same
   Composite Session group and inherit the grouping specified for that
   value at session-level.



Walsh, et al.             Expires July 31, 2006                 [Page 6]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   The first media line declared for a Composite Session group is the
   Primary Media.  Just as session-level attributes are inherited to
   media-level declarations (unless specifically overwritten by an
   additional media-level attribute), Primary Media attributes SHALL be
   inherited to all media of a particular Composite Session group and
   these MAY be overwritten these where an attribute syntax allows.

3.2.1.  Composite Session Semantics for FLUTE Sessions

   The Composite Session provides an unambiguous way to define multiple
   FLUTE sessions as distinct from multiple the media-sessions semantics
   of RTP.  It is useful for describing more than one FLUTE session in
   an SDP instance and so its use and support are OPTIONAL.  For SDP
   instances which describe multiple FLUTE sessions, the Composite
   Session semantics MUST be used.  Whenever an SDP describes just one
   FLUTE session with more than a single media stream of FLUTE protocol
   id, use of Composite Session semantics is RECOMMENDED.

   To support simple applications, as well as ensure harmony with FLUTE
   SDP standards outside of the IETF [21], when the Composite Session
   mechanism is not used for media of the UDP/FLUTE protocol, exactly
   one FLUTE session is specified within the SDP description and all
   UDP/FLUTE media that SDP description belong to the same FLUTE session
   (this is known as the Restricted Behaviour).

   The Composite Session mechanism SHOULD NOT be used where the target
   clients are expected to include simpler FLUTE SDP parsers, such as in
   3GPP MBMS [21].  In this Restricted Behaviour only UDP/FLUTE media
   SHALL be described.

   A partial example of using the Composite Session mechanism for FLUTE
   is shown below.

      <other session-level attributes>
      a=group:CS 1 2
      a=group:CS 3
      m=application 12345 FLUTE/UDP *
      a=mid:1
      <other media-level attributes>
      m=application 12346 FLUTE/UDP *
      a=mid:2
      <other media-level attributes>
      m=application 56789 FLUTE/UDP *
      a=mid:3
      <other media-level attributes>

   The example shows two groups with the 1st and 3rd media ("m=") lines
   (mid values 1 and 3) being the Primary Media for each group



Walsh, et al.             Expires July 31, 2006                 [Page 7]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   respectively.  In the example, the media with mid value "2" inherits
   attributes of the media with mid value "1".)  Each of these groups
   identifies a separate FLUTE Session.  Several of the attributes
   subsequently specified in this document use this feature of Primary
   Media inheritance to all media of a Composite Session.

   The Composite Session mechanism solves the problem of describing
   multiple FLUTE sessions in a single SDP instance.  However, this does
   not place any restrictions on the use of the Composite Session
   mechanism with transport protocols other than FLUTE/UDP, nor on
   whether a complete SDP would include media of other transport
   protocols too.  Specification of semantics beyond the use of FLUTE
   sessions is outside the scope of this document.

3.3.  Source IP Address

   The Asynchronous Layered Coding (ALC) [3] and the Layered Coding
   Transport (LCT) [4] specifications require that all the channels of a
   single ALC/LCT session are from the same source IP address.  Hence,
   there MUST be exactly one source IP address per FLUTE session, and
   therefore one source IP address per each description of a FLUTE
   session description.  Restricted behaviour is one source IP address
   per each complete SDP.  Where multiple FLUTE sessions are described
   within one SDP instance this means one source IP address per each
   Composite Session.

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

   o  The source-filter attribute MUST be included in any SDP describing
      FLUTE per FLUTE session described.

   o  The number of source-filter attributes in any SDP describing FLUTE
      must be exactly equal to the number of FLUTE sessions described in
      that SDP.

   o  In the restricted behaviour of only one FLUTE session description
      in an SDP and no use of the Composite Session mechanism: The
      source-filter attribute MUST be in the session part of the session
      description and MUST NOT be given per media.  Note, the
      requirement that there must not be more than a single source-
      filter attribute in the session part is inherited from [8].

   o  Where the Composite Session mechanism is used: The source-filter
      attribute MUST be in the media part of Primary Media of each
      distinct FLUTE session, and MUST NOT be given in other media
      declarations but these, nor in the session-level part of the SDP.




Walsh, et al.             Expires July 31, 2006                 [Page 8]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   o  Exactly one source address is specified by any instance of this
      attribute.  Exactly one source address MUST be given in an
      inclusive-mode "src-list".  Exclusive-mode MUST NOT be used.

   o  The "*" value MUST be used for the "dest-address" sub-field, even
      when the FLUTE session employs only a single channel (e.g. a
      multicast group).

   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.4.  Transport Session Identifier

   Without additional grouping of media lines, the restricted behaviour
   of a host is to group all media of a single SDP with the FLUTE/UDP
   protocol identifier as belonging to the same single FLUTE session.

   The combination of the TSI and the source IP address identifies a
   FLUTE session.  Each TSI MUST uniquely identify a FLUTE session for a
   given source IP 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 [4].  The TSI MUST be described
   by the "flute-tsi" attribute.

   There MUST be exactly one occurrence of the "flute-tsi" attribute per
   FLUTE session description of a SDP description.

   o  The number of "flute-tsi" attributes in any SDP describing FLUTE
      must be exactly equal to the number of FLUTE sessions described in
      that SDP.

   o  In the restricted behaviour of only one FLUTE session description
      in an SDP and no use of the Composite Session mechanism: The
      "flute-tsi" attribute MUST be in the session part of the session
      description and MUST NOT be given per media.  A "flute-tsi"
      attribute in the session-part SHALL be used to identify restricted
      behaviour.

   o  Where the Composite Session mechanism is used: The "flute-tsi"
      attribute MUST be in the media part of Primary Media of each
      distinct FLUTE session, and MUST NOT be given in other media
      declarations but these, and MUST NOT be given in the session-level
      part of the SDP.




Walsh, et al.             Expires July 31, 2006                 [Page 9]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   The syntax for the attribute in ABNF is given below:

      flute-tsi-line = "a=flute-tsi:" tsi CRLF
      tsi = 1*DIGIT

3.5.  Session Timing Parameters

   The SDP timing field "t=" [6] MUST be used to indicate the FLUTE
   session start and end times.  This value applies to all FLUTE and
   transport sessions defined in a single SDP instance and, thus, FLUTE
   sessions of different timing values need to be declared in different
   SDP instances.

3.6.  Channelisation Descriptors

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

   o  Number of channels

   o  Destination IP address and port number for channels

3.6.1.  Number of Channels

   The FLUTE specification allows the use of multiple channels (e.g.
   multicast groups) to transport the files of a single FLUTE session.
   This is referred to as FLUTE session channelisation in this document.
   A FLUTE channel is equivalent to an ALC/LCT channel.  An ALC/LCT
   channel is defined by the combination of a sender and an address
   associated with the channel by the sender.  Details of each channel
   are defined by SDP media-level information also described in this
   document.  The number of channels is calculated by summing the number
   of unique destination IP address and port number pairs for a certain
   FLUTE session (assignment of media to FLUTE sessions is done with
   presence of absence of the Composite Session grouping).

   The OPTIONAL "flute-ch" attribute describes the number of channels
   used by the source to transmit the FLUTE session.  When present, it
   is used to validate the channel number calculation based on the
   number of destination address/port pairs, and it is expected to be
   used where SDP proxies and other automatic and manual editing that
   introduces errors would cause bad failure conditions at the client.

   When the "flute-ch" attribute is used:

   o  The number of "flute-ch" attributes in any SDP describing FLUTE
      MUST be exactly equal to the number of FLUTE sessions described in



Walsh, et al.             Expires July 31, 2006                [Page 10]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


      that SDP.  A client SHOULD discard all of an SDP instance if this
      condition is not met.  Alternative behaviour, such as retries at
      delivery, error reporting and partial use of SDP instances known
      to include errors, are allowed but beyond the scope of this
      document.

   o  In the restricted behaviour of only one FLUTE session description
      in an SDP and no use of the Composite Session mechanism: The
      "flute-ch" attribute MUST be in the session part of the session
      description and MUST NOT be given per media.

   o  Where the Composite Session mechanism is used: The "flute-ch"
      attribute MUST be in the media part of Primary Media of each
      distinct FLUTE session, and MUST NOT be given in other media
      declarations but these, nor in the session-level part of the SDP.

   The syntax for the attribute in ABNF is given below:

      flute-channel-line = "a=flute-ch:" ch CRLF
      ch = integer
      ;integer is as defined in [6].

   value is the number of channels used by the source to transmit data
   in a FLUTE session.

3.6.2.  Destination IP Address and Port Number for Channels

   SDP media-level information describes one or more channels.  The
   channel parameters MUST be given per channel and are:

   o  Destination IP address

   o  Destination port number

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

   A "c=" line can describe multiple addresses by using "number of
   addresses" sub-field, and also an "m=" line can describe multiple
   ports by using "number of ports" sub-field.  So multiple channels can
   be described by using one "c=" line and one "m=" line (slash
   notation).

   When more than one channel is used in a multicast FLUTE session, it
   is RECOMMENDED that the channels are differentiated based on
   destination IP address, and channels are not differentiated based on



Walsh, et al.             Expires July 31, 2006                [Page 11]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   destination port (although those ports could be same or different for
   each channels).  When more than one channel is used in a unicast
   FLUTE session, the channels have to be differentiated based on
   destination ports, as only one destination IP address could be used.
   Whenever channels are differentiated based on destination port number
   they must use the same destination IP address for that FLUTE session.

   In the case (always with a unicast session) where the same
   destination IP address is used for all the channels of the session
   and only the destination port number differentiates channels, the
   destination IP address MAY be given by the connection data field at
   session-level for all channels (if so, the connection data field MUST
   NOT be used at media-level).

   In the case where each channel has a different destination IP
   address, the destination IP addresses MUST be given at media-level,
   i.e. following an "m=" line.

   The sequence of multiple channels MUST 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).  This applies individually to each FLUTE session of an SDP
   whether one or more FLUTE sessions are described.  In the case of the
   slash notation usage for specifying multiple destination addresses or
   ports, the order of the channel sequence MUST be lowest value first
   and highest last.  (Note, slash notation for both destination IP
   address and port would be incompatible with requirement to not use
   both destination IP address and port to differentiate channels in a
   FLUTE session and thus slash notation for both destination IP address
   and port is not allowed for a single media.)

   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 *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E24

   In the above SDP attributes, the "m=" line indicates the media used
   and the "c=" line together with "m=" line's "port" sub-field
   indicates the corresponding channel's address and port respectively.
   Thus, in the above example, the media is transported on a channel
   that uses FLUTE over UDP.  Further, the "c=" line indicates the
   channel's address, which, in this case, is an IPv6 address, and "m="
   line indicates the channel's port (12345).

   Note, the value of the destination IP address implicitly indicated
   whether a multicast media belongs to an ASM or a SSM group as



Walsh, et al.             Expires July 31, 2006                [Page 12]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   described by [19].

3.7.  FEC Object Transmission Information

   An SDP description for a FLUTE session MAY include FEC Object
   Transmission Information (FEC-OTI) [12].  FEC parameters can be
   placed either at session-level or at media-level, although it is
   RECOMMENDED to place them at session-level.  Furthermore, if FEC
   parameters are placed at media-level (contrary to the recommendation)
   and the Composite Session mechanism is used, they should only be
   placed in the Primary Media for any FLUTE session description.  If
   FEC declarations on both session-level and media-level use the same
   reference number (fec-ref) then the media-level declaration takes
   precedence for that media component.  FEC parameters include:

   o  FEC Encoding ID

   o  FEC Instance ID (for FEC Encoding IDs 128-255)

   Where FEC-OTI is given, FEC parameters MUST be described in a "FEC-
   declaration" attribute.  Multiple instances of this attribute MAY
   exist both at session-level and media-level.  If an instance exists
   at session-level (or in a Primary Media), a reference to it MAY be
   used at media-level, and an attribute "FEC" MUST be defined for this
   purpose.  The absence of a both a "FEC-declaration" and a "FEC"
   attribute at media-level MUST be interpreted as the default FEC
   (Compact No-Code FEC [11] for FLUTE).

   The syntax for the attributes in ABNF is given below:

      fec-declaration-line = "a=FEC-declaration:" fec-ref SP
                             fec-enc-id [";" SP fec-inst-id] CRLF
      fec-ref = 1*3DIGIT
      ;value is the SDP-internal identifier for FEC-declaration

      fec-enc-id = "encoding-id=" enc-id
      enc-id = 1*DIGIT
      ;value is the FEC Encoding ID used

      fec-inst-id = "instance-id=" inst-id
      inst-id = 1*DIGIT
      ;value is the FEC Instance ID used

      fec-line = "a=FEC:" fec-ref CRLF

   Examples of FEC-OTI are shown in section 4.

   The FEC parameters are for capabilities description for the session.



Walsh, et al.             Expires July 31, 2006                [Page 13]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   (Note, any "FDT-like" fuller description of files in the session
   could give the FEC parameters per file).  FLUTE's FDT syntax (and
   codepoint header field usage) allows complete specification of these
   FEC parameters in-band with FLUTE (per file).  Thus machine
   configuration can be performed using FLUTE alone.

   There are five main reasons that the FEC Encoding and Instance IDs
   are optional capabilities descriptions:

   1.  It is not always necessary to explicitly describe the FEC
       capabilities in advance of the session - e.g. for simple (and
       short) sessions it can be more elegant to discover this from the
       session (FDT) itself (even when some mechanism for machine-
       readable session parameters, such as IP addresses and ports, is
       wanted in advance).

   2.  There may be some other out-of-band discovery of FEC capability
       requirements (e.g. well known-FEC/standardised capabilities for a
       certain application, verbal agreement between a group, etc.) that
       provides the FEC capability information.  This document does not
       want to prevent this, and in this case repeating the information
       in SDP would be unnecessary and wasteful (and probably result in
       implementations not following the flute-sdp specification).

   3.  FLUTE defaults to Compact No-Code FEC [11] and support for this
       is mandatory for FLUTE anyway so it is a given (capability
       requirement) which does not need to be described by the SDP.  In
       cases where only Compact No-Code FEC is required, there is no use
       in specifying any FEC Encoding (and Instance) IDs in the SDP
       (though it is allowed).

   4.  In cases where a FLUTE session description (SDP file) is not
       defined once for all time, it is possible that the FEC usage is
       not known in advance and the FEC capabilities would only be added
       to the SDP in a later version of that SDP file when the FEC codes
       have been selected (e.g. a larger audience may suggest stronger
       FEC to make FLUTE delivery more reliable, whereas additional bi-
       directional messages may be scalable for smaller groups).

   5.  Also, in cases where a FLUTE session description (SDP file) is
       very static (e.g. once for all time for that session), it is
       possible that the FEC usage is not known in advance and it needs
       to be left to some other mechanism (e.g.  FDT) to discover any
       FEC capability requirements set closer to the session
       transmission - with the same examples as in (4).

   Also, in a complex case of very many FEC codes being used in the
   session giving a full list in SDP is not seen as being reasonable



Walsh, et al.             Expires July 31, 2006                [Page 14]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   (but this is likely to be a rare case anyway).

   The identification and description of any congestion control (CC)
   instance related to layered media (multiple FLUTE channels) is
   orthogonal to the FEC declarations and other aspects of this
   document.  Hence, CC descriptions are not in scope of this document.

3.8.  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 at the session-level and/or media-level
   (including Primary Media of Composite Sessions) to enable efficient
   linkage to such information.

   The content description pointer attribute describes to the
   receiver(s) the URI where the content description is stored.  The
   content description pointer MUST be defined according to the
   "content-desc" attribute.

   The syntax for the attribute in ABNF is given below:

      content-desc-line = "a=content-desc:" URI-reference CRLF
      ;URI-reference is as defined in [10].

   An example of content description pointer is shown in section 4.

3.9.  Bandwidth Specification

   The specification of bandwidth (data rate) is OPTIONAL and where
   included in the SDP it SHALL adhere to the following rules.

   The maximum bit-rate required by a particular FLUTE media line (one
   or more FLUTE channels, depending on the usage or IP address and port
   ranges) MAY be specified.  In this case it is RECOMMENDED to use the
   TIAS bandwidth modifier [[14]] on media-level, although the AS
   bandwidth modifier [[6]] MAY be used on media-level.

   The session bit-rate MAY also be specified.  In this case it is
   RECOMMENDED to use the TIAS bandwidth modifier and the "a=maxprate"
   attribute for the session, and again AS is optional but not
   recommended.

   TIAS is generally preferred as it allows the calculation of the bit-
   rate in environments with translation of IP version or transport
   protocol, where as AS does not and thus adds significant complexity
   in such environments.



Walsh, et al.             Expires July 31, 2006                [Page 15]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   Any Transport Independent (TIAS) bandwidth SHALL be the largest sum
   of the sizes of all FLUTE/UDP packets transmitted during any one
   second long period of the FLUTE session, depending on which level it
   is being used, expressed as kilobits.  The size of the packet SHALL
   include all FLUTE, ALC, LCT and any extensions headers and payload.
   IP and UDP headers are excluded from the TIAS bit-rate calculation.
   Any Application Specific (AS) bandwidth SHALL be the largest sum of
   the sizes of all FLUTE/UDP packets transmitted during any one second
   long period for the related media line(s), expressed as kilobits.
   The size of the packet SHALL be the complete packet, i.e.  IP, UDP
   and FLUTE headers, and the data payload.

3.9.1.  Bandwidth Specification for Composite Sessions

   Where the multimedia session bit-rate is specified (at SDP session
   level) this applies to all media, irrespective of whether the
   Composite Session mechanism is used to describe multiple sessions
   (e.g. multiple FLUTE sessions).  So if multiple Composite Sessions
   are described in a single SDP and SDP session-level bit-rate is
   described, this session-level bit-rate would not relate to any single
   Composite Session.

   A normal TIAS or AS bit-rate declaration at the Primary Media level
   is to be interpreted as media-specific and not imply any inheritance
   to other media of the same Composite Session.  It is RECOMMENDED that
   aggregate Composite Session bandwidth is calculated as the sum of all
   constituent media bit-rate declarations.  Specification of a
   descriptor specifically for aggregate Composite Session bandwidth is
   beyond the scope of this document.






















Walsh, et al.             Expires July 31, 2006                [Page 16]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


4.  SDP Syntax Examples

   This section gives examples 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:1
      a=flute-ch:2
      a=FEC-declaration:0 encoding-id=0
      a=FEC-declaration:1 encoding-id=128; instance-id=0
      a=content-desc:http://www.example.com/flute-sessions/session001
      m=application 12345 FLUTE/UDP *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E24
      a=FEC:0
      m=application 12346 FLUTE/UDP *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E25
      a=FEC:1

   Figure 1: An SDP for FLUTE Session with Two Channels

   Figure 1 shows an example SDP description for FLUTE session with two
   channels.

   The attribute 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 source indicates that the receiver(s) should include the
   given IP address (2001:210:1:2:240:96FF:FE25:8EC9) into the 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
   attribute.

   The attribute defined in the line "a=flute-tsi:3" describes the
   Transport Session Identifier for the session.  The pair made of the
   source IP address and the TSI together uniquely identifies a FLUTE
   session.

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

   The "a=FEC-declaration" lines describes two different FEC schemes
   used in the FLUTE session.




Walsh, et al.             Expires July 31, 2006                [Page 17]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


   The "a=content-desc" line describes the URI where the content
   description is stored.

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

   The destination addresses for the channels are given in the "c="
   lines.  These also show to the receiver(s) that the channels are two
   (maybe more in other cases) consecutive channels.

   The "a=FEC" lines at media-level reference FEC declarations at
   session-level ("a=FEC-declaration").

      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:2
      a=flute-ch:1
      m=application 12345 FLUTE/UDP *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E24
      a=FEC-declaration:0 encoding-id=128; instance-id=0

   Figure 2: An SDP for FLUTE Session with One Channel

   Figure 2 shows an example SDP description for FLUTE session with one
   channel.





















Walsh, et al.             Expires July 31, 2006                [Page 18]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


      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=FEC-declaration:0 encoding-id=0
      a=FEC-declaration:1 encoding-id=128; instance-id=0'
      a=group:CS 1 2
      a=group:CS 3 4
      m=application 12345 FLUTE/UDP *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E24
      a=flute-tsi:1
      a=FEC:0
      a=mid:1
      m=application 12346 FLUTE/UDP *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E25
      a=mid:2
      m=application 12347 FLUTE/UDP *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E26
      a=flute-tsi:2
      a=FEC:1
      a=mid:3
      m=application 12348 FLUTE/UDP *
      c=IN IP6 FF1E:03AD::7F2E:172A:1E27
      a=mid:4

   Figure 3: An SDP for composite FLUTE session

   Figure 3 shows an example SDP description for composite FLUTE
   session.




















Walsh, et al.             Expires July 31, 2006                [Page 19]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


5.  Security Considerations

   See [6] for security considerations specific to the Session
   Description Protocol in general.  See also [8] for security
   consideration related to source address filters.














































Walsh, et al.             Expires July 31, 2006                [Page 20]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


6.  IANA Considerations

6.1.  Transport Protocol

   The "proto" sub-field of the media description field ("m=") describes
   the transport protocol used.  This document registers one value:
   "FLUTE/UDP" is a reference to FLUTE [1] running over UDP/IP.

6.1.1.  Media formats ("fmt")

   FLUTE media using the "FLUTE/UDP" proto value may use the character
   "*" as their "fmt" value.  The "*" character represents a wild card
   which indicates that miscellaneous and unspecified MIME types are
   contained in the FLUTE session.  Alternatively a list of MIME types
   (file formats) may be given in the "fmt" list.  These formats SHOULD
   be registered.  Use of an existing MIME subtype for the format is
   encouraged.  If no MIME subtype exists, it is RECOMMENDED that a
   suitable one is registered through the IETF process (RFC 2048).

6.2.  Attribute Names

   As recommended by [6], the new attribute names "flute-tsi",
   "flute-ch", "FEC-declaration", "FEC", "FEC-OTI-extension" and
   "content-desc" should be registered with IANA, as follows:

   The following contact information shall be used for all registrations
   included here:

      Contact:      Rod Walsh
                    EMail: rod.walsh (at) nokia.com

   SDP Attribute ("att-field"):
     Attribute name:     flute-tsi
     Long form:          FLUTE Transport Session Identifier
     Type of name:       att-field
     Type of attribute:  Session level or media level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
     Attribute name:     flute-ch
     Long form:          Number of Channels in a FLUTE Session
     Type of name:       att-field
     Type of attribute:  Session level or media level
     Subject to charset: No
     Purpose:            See this document



Walsh, et al.             Expires July 31, 2006                [Page 21]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
     Attribute name:     FEC-declaration
     Long form:          Forward Error Correction Declaration
     Type of name:       att-field
     Type of attribute:  Session level or media level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
     Attribute name:     FEC
     Long form:          A Reference to FEC Declaration
     Type of name:       att-field
     Type of attribute:  Media level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
     Attribute name:     FEC-OTI-extension
     Long form:          FEC Object Transmission Information extension
     Type of name:       att-field
     Type of attribute:  Session level or media level
     Subject to charset: No
     Purpose:            See this document
     Reference:          This document
     Values:             See this document

   SDP Attribute ("att-field"):
      Attribute name:     content-desc
      Long form:          Content Description Pointer
      Type of name:       att-field
      Type of attribute:  Session level or media level
      Subject to charset: No
      Purpose:            See this document
      Reference:          This document
      Values:             See this document

6.3.  Composite Session Token to Differentiate FLUTE Sessions

   IANA needs to register the following new 'semantics' attribute for
   the SDP grouping framework [13]:




Walsh, et al.             Expires July 31, 2006                [Page 22]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


      Semantics                            Token      Reference
      ---------------------------------    -----      ---------
      Composite Session                      CS         [RFCxxxx]

   It should be registered in the SDP parameters registry
   (http://www.iana.org/assignments/sdp-parameters) under Semantics for
   the "group" SDP Attribute.












































Walsh, et al.             Expires July 31, 2006                [Page 23]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


7.  Acknowledgements

   The authors would like to thank all the people who gave feedback on
   this document.















































Walsh, et al.             Expires July 31, 2006                [Page 24]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


8.  Contributors

   Magnus Westerlund
   Ericsson Research
   Ericsson AB
   SE-164 80 Stockholm
   Sweden
   EMail: Magnus.Westerlund (at) ericsson.com

   Joerg Ott
   Helsinki University of Technology
   Otakaari 5A
   FIN-02150 Espoo
   Finland
   EMail: jo (at) netlab.hut.fi




































Walsh, et al.             Expires July 31, 2006                [Page 25]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


9.  References

9.1.  Normative References

   [1]   Paila, T., Walsh, R., Luby, M., Lehtonen, R., and V. Roca,
         "FLUTE - File Delivery over Unidirectional Transport",
         draft-ietf-rmt-flute-revised-01 (work in progress),
         January 2006.

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

   [3]   Luby, M., Watson, M., Gemmell, J., Vicisano, L., Rizzo, L., and
         J. Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
         Instantiation", draft-ietf-rmt-pi-alc-revised-01 (work in
         progress), October 2005.

   [4]   Luby, M., Watson, M., Gemmell, J., Vicisano, L., Rizzo, L.,
         Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT)
         Building Block", draft-ietf-rmt-bb-lct-revised-01 (work in
         progress), October 2005.

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

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

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

   [8]   Quinn, B. and R. Finlayson, "Session Description Protocol (SDP)
         Source Filters", draft-ietf-mmusic-sdp-srcfilter-10 (work in
         progress), September 2005.

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

   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396,
         August 1998.

   [11]  Watson, M., "Basic Forward Error Correction (FEC) Schemes",
         draft-ietf-rmt-bb-fec-basic-schemes-revised-01 (work in
         progress), October 2005.

   [12]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
         Correction (FEC) Building Block",



Walsh, et al.             Expires July 31, 2006                [Page 26]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


         draft-ietf-rmt-fec-bb-revised-02 (work in progress),
         October 2005.

   [13]  Camarillo, G., Holler, J., Eriksson, G., and H. Schulzrinne,
         "Grouping of Media Lines in the Session Description Protocol
         (SDP)", RFC 3388, December 2002.

   [14]  Westerlund, M., "A Transport Independent Bandwidth Modifier for
         the Session Description Protocol (SDP)", RFC 3890,
         September 2004.

9.2.  Informative References

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

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

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

   [18]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in the
         Session Description Protocol (SDP)", RFC 4145, September 1998.

   [19]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
         draft-ietf-ssm-arch-07 (work in progress), October 2005.

   [20]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.

   [21]  "3GPP TS 26.346 V6.3.0 (2005-12), 3rd Generation Partnership
         Project; Technical Specification Group Services and System
         Aspects; Multimedia Broadcast/Multicast Service (MBMS);
         Protocols and codecs (Release 6)", December 2005.

   <Note to RFC Editor: if sdp-new goes to RFC it supersedes references
   6 and 7>
   <Note to RFC Editor: reference 8 needs correct RFC number when known>










Walsh, et al.             Expires July 31, 2006                [Page 27]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


Appendix A.  Use of FEC attributes with RTP sessions (informative)

   The "FEC-declaration" and "FEC" attributes provide general FEC-OTI
   information in FEC Encoding ID and FEC Instance ID values.  These may
   also be used for RTP sessions employing same FEC Building Block (as
   is done for 3GPP MBMS [21]).  However semantics of RTP are different
   from FLUTE (FEC is per session not per object) and RTP does not have
   in-band mechanism to signal FEC OTI extensions.  Thus, RTP FEC
   declarations are expected to be used for machine configuration as
   well as capability requirements specification (for FLUTE it is
   generally only the latter).

   Hence the FLUTE SDP, defined in this document, may be extended using
   a "FEC-OTI-extension" attribute, depending on the configuration needs
   of the FEC decoder used and the lack of an alternative means to
   signal the extended OTI information.  The purpose of extended FEC-OTI
   information define FEC code/instance-specific OTI required for
   receiver FEC payload configuration.  The contents of such an
   extension would be FEC code- specific and exact specification, beyond
   adherence to the ABNF below, needs to be specified by any FEC code
   using this attribute, and hence is outside the scope of this
   Appendix.

   A "FEC-OTI-extension" attribute must be immediately preceded by its
   associated "FEC-declaration" attribute and so the full FEC-OTI,
   including extension, will be found in two neighbouring attribute
   lines.  The fec-ref value binds a "FEC-OTI-extension" and "FEC-
   declaration attribute" pair.

   The syntax for the attribute in ABNF is given below:

      fec-oti-extension-line = "a=FEC-OTI-extension:" fec-ref SP
                               oti-extension CRLF
      oti-extension = base64
      base64 = *base64-unit [base64-pad]
      base64-unit = 4base64-char
      base64-pad = 2base64-char "==" / 3base64-char "="
      base64-char = ALPHA / DIGIT / "+" / "/"













Walsh, et al.             Expires July 31, 2006                [Page 28]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


Authors' Addresses

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

   Email: rod.walsh (at) nokia.com


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

   Email: jani.peltotalo (at) tut.fi


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

   Email: sami.peltotalo (at) tut.fi


   Harsh Mehta
   Nokia
   P.O. Box 325 (Hiomotie 32)
   Helsinki  FIN-00380
   Finland

   Email: harsh.mehta (at) nokia.com


   Igor D.D. Curcio
   Nokia
   P.O. Box 88 (Tieteenkatu 1)
   Tampere  FIN-33721
   Finland

   Email: igor.curcio (at) nokia.com






Walsh, et al.             Expires July 31, 2006                [Page 29]

Internet-Draft          SDP Descriptors for FLUTE           January 2006


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




Walsh, et al.             Expires July 31, 2006                [Page 30]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/