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

Versions: (draft-mehta-rmt-flute-sdp) 00 01 02 03

RMT                                                             R. Walsh
Internet-Draft                                              J. Peltotalo
Intended status: Standards Track                            S. Peltotalo
Expires: March 16, 2013                 Tampere University of Technology
                                                               I. Curcio
                                                   Nokia Research Center
                                                                H. Mehta
                                                            Sep 12, 2012


                       SDP Descriptors for FLUTE
                      draft-ietf-rmt-flute-sdp-03

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
   semantic for grouping media streams into protocol-specific sessions,
   such as multiple-channel FLUTE sessions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 16, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Walsh, et al.            Expires March 16, 2013                 [Page 1]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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



































Walsh, et al.            Expires March 16, 2013                 [Page 2]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
     2.1.  New Terms  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  FLUTE Descriptors  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  FLUTE Protocol Identifier  . . . . . . . . . . . . . . . .  7
     3.2.  Composite Session Semantics  . . . . . . . . . . . . . . .  8
       3.2.1.  Composite Session Semantics for FLUTE Sessions . . . .  9
       3.2.2.  Composite Session Semantics for Protocols other
               than FLUTE . . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Source IP Address  . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Transport Session Identifier . . . . . . . . . . . . . . . 11
     3.5.  Session Timing Parameters  . . . . . . . . . . . . . . . . 12
     3.6.  Channelization Descriptors . . . . . . . . . . . . . . . . 12
       3.6.1.  Number of Channels . . . . . . . . . . . . . . . . . . 12
       3.6.2.  Destination IP Address and Port Number for Channels  . 13
     3.7.  FEC Scheme . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.8.  Content Description Pointer  . . . . . . . . . . . . . . . 16
     3.9.  Security Parameters  . . . . . . . . . . . . . . . . . . . 17
     3.10. Bandwidth Specification  . . . . . . . . . . . . . . . . . 17
       3.10.1. Bandwidth Specification for Composite Sessions . . . . 18
     3.11. SDP Specific Parameters  . . . . . . . . . . . . . . . . . 18
   4.  SDP Syntax Examples  . . . . . . . . . . . . . . . . . . . . . 19
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
     6.1.  Transport Protocol . . . . . . . . . . . . . . . . . . . . 23
       6.1.1.  Media formats ("fmt")  . . . . . . . . . . . . . . . . 23
     6.2.  Attribute Names  . . . . . . . . . . . . . . . . . . . . . 23
     6.3.  Composite Session Token to Differentiate FLUTE Sessions  . 25
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
   9.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     9.1.  From draft-ietf-rmt-flute-sdp-02 to
           draft-ietf-rmt-flute-sdp-03  . . . . . . . . . . . . . . . 28
     9.2.  From draft-ietf-rmt-flute-sdp-01 to
           draft-ietf-rmt-flute-sdp-02  . . . . . . . . . . . . . . . 28
     9.3.  From draft-ietf-rmt-flute-sdp-00 to
           draft-ietf-rmt-flute-sdp-01  . . . . . . . . . . . . . . . 28
     9.4.  From draft-mehta-rmt-flute-sdp-06 to
           draft-ietf-rmt-flute-sdp-00  . . . . . . . . . . . . . . . 28
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
     10.2. Informative References . . . . . . . . . . . . . . . . . . 31
   Appendix A.  Use of FEC Attributes with RTP Sessions
                (informative) . . . . . . . . . . . . . . . . . . . . 33
   Appendix B.  Further Design Logic for FEC-OTI Descriptors  . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35



Walsh, et al.            Expires March 16, 2013                 [Page 3]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


1.  Introduction

   The Session Description Protocol (SDP) [RFC4566] 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 [RFC3629]) 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
   [I-D.ietf-rmt-flute-revised], SAP [RFC2974], SIP [RFC3261], RTSP
   [RFC2326], HTTP [RFC2616], 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.  [RFC4145] defines
   protocol identifiers for connection-oriented reliable transports: TCP
   and TCP/TLS.

   This document defines two new protocol identifiers for File Delivery
   over Unidirectional Transport (FLUTE) protocol
   [I-D.ietf-rmt-flute-revised] and other required SDP attributes for
   initiating a FLUTE session.  The formal ABNF syntax [RFC5234] is used
   for the attributes.  This SDP syntax is independent of whether Any
   Source Multicast (ASM) or Source Specific Multicast (SSM) is used to
   route the media.

   Note, this document may also be used to describe sessions of the
   experimental FLUTE specification [RFC3926].






















Walsh, et al.            Expires March 16, 2013                 [Page 4]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   RFC2119 [RFC2119].

2.1.  New Terms

   SDP instance: A syntactically complete SDP description of an SDP
   session, possibly stored in a single computer file.

   Composite Session: An SDP mechanism that enables the grouping of
   media lines in to distinct sessions, so that a single SDP instance
   can describe multiple protocol-specific sessions.




































Walsh, et al.            Expires March 16, 2013                 [Page 5]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


3.  FLUTE Descriptors

   The FLUTE specification [I-D.ietf-rmt-flute-revised] 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.
   Listed below are the required and optional SDP parameters for FLUTE
   sessions (the parameters introduced, or made mandatory, by this
   specification but not inherited from the FLUTE specification are
   marked with an asterisk "*").

   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  An indication that the session is a FLUTE session;

   *  The start time and end time of the session.

   The optional parameters are:

   o  FEC scheme (a subset of FEC Object Transmission Information);

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

   o  Security parameters relevant for the session;

   *  Bandwidth specification.

   (Note, the best practice to provide parameters for FLUTE's optional
   content encoding of FDT Instances is in-band within FLUTE sessions
   and is therefore not specified using SDP.)

   (Note, out-of-band FEC Object Transmission Information useful for
   FLUTE sessions is limited to SDP signaling of capabilities
   requirements describing FEC Encoding ID(s) and FEC Instance ID(s) as
   FLUTE provides header fields for machine configuration for object
   reception.  This specification also provides a "fec-oti-extension",
   as an informative appendix, so that the same SDP syntax can be used
   to describe sessions using protocols other than FLUTE that do not



Walsh, et al.            Expires March 16, 2013                 [Page 6]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   have an in-band mechanism for FEC machine configuration.)

   (Note, description of congestion control parameters are not in scope
   of this document.)

   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 stream.  (Note, the SDP specification [RFC4566] use of
   the term "media stream" is semantically equivalent to the FLUTE
   specification use of the term "channel".)  Generally, each RTP media
   is recognized as a distinct RTP media session.  Hence, to preserve
   harmony with RTP media sessions within SDP descriptions, the optional
   Composite Session mechanism is specified in this document, using the
   SDP Grouping Framework [RFC5888].

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

3.1.  FLUTE Protocol Identifier

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

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

   We define two new values for the "proto" sub-field: FLUTE/UDP and
   FLUTE/UDP/ESP.  The FLUTE/UDP protocol identifier specifies that the
   session being described will use the FLUTE
   [I-D.ietf-rmt-flute-revised] protocol on top of a UDP connection.
   The FLUTE/UDP/ESP protocol identifier specifies that the session
   being described will use the FLUTE [I-D.ietf-rmt-flute-revised]
   protocol on top of a UDP connection and session security is achieved
   by means of IPsec/ESP in transport mode [RFC4303].

   As described below, more than one FLUTE session may be described by a
   single SDP instance 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 semantic as "*", in a
   non-standardized way, and so implementers may take this into account.
   An example of a FLUTE/UDP protocol identifier is shown in Section 4.




Walsh, et al.            Expires March 16, 2013                 [Page 7]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   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 this session description specification.

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.  Subsection
   3.2.1. defines the FLUTE/UDP and FLUTE/UDP/ESP protocol identifier
   specific semantic.

   This mechanism is useful where multiple FLUTE sessions are described
   as part of a larger service or application, and so where maintaining
   and delivering session descriptions together (with a shared delivery
   fate) is good practice.  It may also improve bandwidth efficiency by
   eliminating repetition of redundant descriptors that would be
   necessary with multiple discrete SDP instances.

   The Composite Session mechanism inherits the "group" and "mid"
   attributes from the SDP grouping framework [RFC5888] and introduces
   the "CS" (Composite Session) token as a "semantics-extension".

   When the Composite Session mechanism is used: the SDP grouping
   framework [RFC5888] 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 given "mid" values
   that are identified in an "a=group:CS" line belong to the same
   Composite Session group and inherit the grouping specified for these
   mid values at session-level.

   The first (leftmost and uppermost) mid value 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.  These primary media attributes (i.e.  Composite
   Session default attributes) SHALL be overwritten at media level (for
   the specific media) where an attribute's syntax mandates this
   behavior for media-level overwriting of SDP session-level attributes;
   and media-level attribute overwriting of session level attribute
   inheritance shall not be allowed otherwise.





Walsh, et al.            Expires March 16, 2013                 [Page 8]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


3.2.1.  Composite Session Semantics for FLUTE Sessions

   When an SDP instance specifies only one FLUTE session, using the
   Composite Session mechanism is OPTIONAL.  When an SDP instance
   specifies more than one FLUTE session, using the Composite Session
   mechanism is REQUIRED.

   The Composite Session provides an unambiguous way to define multiple
   FLUTE sessions as distinct from multiple the media-sessions semantics
   of RTP.  It is used for describing more than one FLUTE session in an
   SDP instance and so its general use and support in SDP 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 one
   FLUTE protocol identifier (i.e. a FLUTE channel), use of the
   Composite Session semantics is RECOMMENDED.

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

   The Composite Session mechanism SHOULD NOT be used where the target
   clients are expected to include simpler FLUTE SDP parsers, such as in
   some releases of 3GPP MBMS [3GPP.26.346].  In this Restricted
   Behavior only one media protocol SHALL be described in one SDP
   instance (i.e. only FLUTE/UDP or only FLUTE/UDP/ESP or neither).

   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



Walsh, et al.            Expires March 16, 2013                 [Page 9]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   (mid values 1 and 3) being the Primary Media for each group
   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.

3.2.2.  Composite Session Semantics for Protocols other than FLUTE

   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 or FLUTE/UDP/
   ESP, nor on whether a complete SDP would include media of other
   transport protocols too.  Specification of Composite Session
   semantics beyond the use of FLUTE sessions is outside the scope of
   this document.

3.3.  Source IP Address

   The Asynchronous Layered Coding (ALC) [RFC5775] and the Layered
   Coding Transport (LCT) [RFC5651] 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 description of
   a FLUTE session description.  Restricted behavior is one source IP
   address per SDP instance.  Where multiple FLUTE sessions are
   described within one SDP instance this means one source IP address
   per Composite Session.

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

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

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

   o  In the restricted behavior 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 the SDP
      Source Filter specification [RFC4570].



Walsh, et al.            Expires March 16, 2013                [Page 10]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   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.

   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:0DB8:1:2:240:96FF:FE25:8EC9

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

3.4.  Transport Session Identifier

   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 inherited from LCT [RFC5651].  Note, the SDP
   specification [RFC4566] advises that sessions expire 30 minutes after
   the session-end time given in the t-field.  This should be considered
   an absolute minimum interpretation of a "large time".  TSI reuse is
   NOT RECOMMENDED whenever possible (thus, making "large time"
   unbounded regarding TSI reuse).

   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 an SDP instance.

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

   o  In the restricted behavior 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
      behavior.



Walsh, et al.            Expires March 16, 2013                [Page 11]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   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.

   The syntax for the attribute in ABNF is given below:

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

   Note, the range of values a TSI can adopt depends on the bit-length
   of the TSI for a session as defined by RFC5651 [RFC5651].

3.5.  Session Timing Parameters

   The SDP timing field "t=" [RFC4566] 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.

   Note, implementers may assume reasonable clock synchronization
   between SDP description, receiver wall clock and sender wall clock
   (within 60 seconds) unless specified otherwise for a specific
   deployment.  The method to achieve this is beyond the scope of the
   current specifications, but may use well known and mature approaches
   such as SNTP [RFC5905].

3.6.  Channelization Descriptors

   This section specifies the description of the channel(s) used within
   a FLUTE session.  The required parameters for channelization
   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 channelization 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



Walsh, et al.            Expires March 16, 2013                [Page 12]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   document.  The number of channels of a certain FLUTE session is
   calculated by summing the number of unique destination IP address and
   port number pairs for a certain FLUTE session.

   The OPTIONAL "flute-ch" attribute describes the number of channels
   used by the source to transmit a 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
      sessions MUST be exactly equal to the number of FLUTE sessions
      described in that SDP.  A client SHOULD discard all of an SDP
      instance if this condition is not met.  Alternative behavior, such
      as retries at delivery, error reporting and partial use of SDP
      instances known to include errors, are beyond the scope of this
      document.

   o  In the restricted behavior of only one FLUTE session description
      in an SDP and no use of the Composite Session mechanism: Any
      "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 [RFC4566], and its 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



Walsh, et al.            Expires March 16, 2013                [Page 13]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


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

   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 (called "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
   destination port (although those ports could be same or different for
   each of the channels).  Whenever destination port number is used to
   differentiate between FLUTE channels, the same destination IP address
   MUST be used for all channels in that FLUTE session.  Note, 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.  Also note, the use of address
   and port to differentiate channels is a FLUTE sender configuration
   decision that the SDP describes, and so a receiver implementation
   still needs to handle all valid cases.

   In the case 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.

   Some applications of FLUTE and FLUTE SDP benefit from identifying an
   ordinal sequence of FLUTE channels in a FLUTE session.  In this case,
   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 FLUTE session - i.e. for a



Walsh, et al.            Expires March 16, 2013                [Page 14]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   single composite session (when the SDP describes multiple FLUTE
   sessions) or for a single SDP instance (when only one FLUTE session
   is described).

   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 FF33::8000:1

   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 can indicate whether a
   multicast media belongs to an ASM or a SSM group as described by
   [RFC4607].

3.7.  FEC Scheme

   An SDP description for a FLUTE session MAY include information for
   one or more FEC schemes (a subset of FEC Object Transmission
   Information (FEC-OTI) [RFC5052] that is useful for reception
   capability evaluation at the receiver).  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 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 any FEC scheme 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.



Walsh, et al.            Expires March 16, 2013                [Page 15]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   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 scheme information are shown in Section 4.

   The FEC parameters are for capabilities description for the session.
   These parameters do not mandate a certain machine configuration but
   instead indicate which capabilities might be needed for successful
   reception of objects from specific channels.  (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.

   A more complete list of notes on the design logic for the FEC-OTI
   descriptors is provided as an appendix to 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:




Walsh, et al.            Expires March 16, 2013                [Page 16]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


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

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

3.9.  Security Parameters

   To support the baseline secure ALC operation [RFC5775], subsection
   3.2.1. defines the FLUTE/UDP/ESP protocol identifier for a FLUTE
   session where the session security is achieved using IPsec/ESP in a
   transport mode.

   This document describes two informative ways which can be used to
   deliver the needed security parameters for IPsec/ESP Security
   Association (SA).  Firstly, the "key-mgmt" attribute defined in
   [RFC4567] can be used to carry messages, as specified by a key
   management protocol, in order to secure the media.  In [RFC4567] the
   usage of the Multimedia Internet KEYing (MIKEY) key management
   protocol [RFC3830] is defined and guidelines for the registration of
   additional key management protocols is also provided.

   Secondly, the "crypto" attribute defined in [RFC4568] provides
   cryptographic key distribution capabilities, but it is intended for
   usage when keying material is protected along with the signaling
   (i.e. when the session description itself is retrieved using a secure
   method).  [RFC4568] describes this attribute primarily for a unicast
   offer/answer models, but also for "offer only" mode with multicast
   delivery, and sets a policy by mandating that "the sender MUST
   include exactly one crypto attribute" (implying "one crypto attribute
   per media", although [RFC4568] is slightly ambiguous on this).  The
   definition of composite session adds a case to the usage of the
   crypto attribute and so, a crypto attribute definition in a Composite
   Session Primary Media SHALL BE inherited to all media of that
   particular Composite Session group, except where individual child
   media overwrite this with their own crypto attribute.

3.10.  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 [RFC3890] on media-level, although the AS
   bandwidth modifier [RFC4566] MAY be used on media-level.

   The session bit-rate MAY also be specified.  In this case it is



Walsh, et al.            Expires March 16, 2013                [Page 17]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   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.

   Any Transport Independent (TIAS) bandwidth SHALL be the largest sum
   of the sizes of all FLUTE/UDP or FLUTE/UDP/ESP 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, UDP and ESP 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 or FLUTE/UDP/ESP
   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, ESP and FLUTE headers, and the
   data payload.

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

3.11.  SDP Specific Parameters

   SDP [RFC4566] also mandates three parameters ("v=", "o=" and "s=")
   that would be present in every FLUTE SDP instance regardless of their
   usefulness to the FLUTE session description.






Walsh, et al.            Expires March 16, 2013                [Page 18]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


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 2001:0DB8::112E:144A:1E24
   s=File delivery session example
   i=More information
   t=2873397496 2873404696
   a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9
   a=flute-tsi:3
   a=flute-ch:2
   a=FEC-declaration:0 encoding-id=0
   a=FEC-declaration:1 encoding-id=129; instance-id=0
   a=content-desc:http://www.example.com/flute-sessions/session001
   m=application 12345 FLUTE/UDP *
   c=IN IP6 FF33::8000:1
   a=FEC:0
   m=application 12346 FLUTE/UDP *
   c=IN IP6 FF33::8000:2
   a=FEC:1

      Figure 1: An SDP Instance for a FLUTE Session with Two Channels

   Figure 1 shows an example SDP instance for a FLUTE session with two
   channels.  (Note, to introduce the SDP semantics of the current
   document in simpler smaller steps, figure 1 does not follow the
   recommendation of subsection 3.2.1 to use the Composite Session
   semantics when an SDP describes more than one FLUTE media stream.
   Thus, the form of figure 1 is not expected to be normally used in
   practice.)

   The attribute defined in the line "a=source-filter: incl IN IP6 *
   2001:0DB8: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:0DB8: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



Walsh, et al.            Expires March 16, 2013                [Page 19]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   specifies the channels.

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

   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 of an ordinal
   sequence of 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 2001:0DB8::112E:144A:1E24
   s=File delivery session example
   i=More information
   t=2873397496 2873404696
   a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9
   a=flute-tsi:2
   a=flute-ch:1
   m=application 12345 FLUTE/UDP *
   c=IN IP6 FF33::8000:1
   a=FEC-declaration:0 encoding-id=129; instance-id=0

      Figure 2: An SDP Instance for a FLUTE Session with One Channel

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















Walsh, et al.            Expires March 16, 2013                [Page 20]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   v=0
   o=user123 2890844526 2890842807 IN IP6 2001:0DB8::112E:144A:1E24
   s=File delivery session example
   i=More information
   t=2873397496 2873404696
   a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9
   a=FEC-declaration:0 encoding-id=0
   a=FEC-declaration:1 encoding-id=129; instance-id=0'
   a=group:CS 1 2
   a=group:CS 3 4
   m=application 12345 FLUTE/UDP *
   c=IN IP6 FF33::8000:1
   a=flute-tsi:1
   a=FEC:0
   a=mid:1
   m=application 12346 FLUTE/UDP *
   c=IN IP6 FF33::8000:2
   a=mid:2
   m=application 12347 FLUTE/UDP *
   c=IN IP6 FF33::8000:3
   a=flute-tsi:2
   a=FEC:1
   a=mid:3
   m=application 12348 FLUTE/UDP *
   c=IN IP6 FF33::8000:4
   a=mid:4

   Figure 3: An SDP Instance for Multiple (two) FLUTE Sessions using the
                        Composite Session Mechanism

   Figure 3 shows an example SDP instance for multiple FLUTE sessions
   using the Composite Session mechanism.



















Walsh, et al.            Expires March 16, 2013                [Page 21]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


5.  Security Considerations

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

   [I-D.ietf-rmt-flute-revised] provides security consideration
   regarding FLUTE sessions, from which Section 7.3.1 specifically
   addresses attacks against the session description.  The current
   document does not introduce additional security considerations beyond
   these prior specifications.








































Walsh, et al.            Expires March 16, 2013                [Page 22]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


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 two values:
   "FLUTE/UDP" is a reference to FLUTE [I-D.ietf-rmt-flute-revised]
   running over UDP/IP.  "FLUTE/UDP/ESP" is a reference to FLUTE
   [I-D.ietf-rmt-flute-revised] running over UDP/IP and the session
   security is achieved by means of IPsec/ESP in a transport mode
   [RFC4303].

6.1.1.  Media formats ("fmt")

   FLUTE media using the "FLUTE/UDP" or "FLUTE/UDP/ESP" 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 as described in RFC4289 [RFC4289].

6.2.  Attribute Names

   As recommended by [RFC4566], 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: roderick.walsh (at) tut.fi

   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



Walsh, et al.            Expires March 16, 2013                [Page 23]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


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




Walsh, et al.            Expires March 16, 2013                [Page 24]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


6.3.  Composite Session Token to Differentiate FLUTE Sessions

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

   Semantics                            Token      Reference
   ---------------------------------    -----      ---------
   Composite Session                    CS         This document

   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 March 16, 2013                [Page 25]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


7.  Acknowledgements

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















































Walsh, et al.            Expires March 16, 2013                [Page 26]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


8.  Contributors

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

   Joerg Ott
   Aalto University
   Otakaari 5A
   FI-02150 Espoo
   Finland
   EMail: jo (at) netlab.tkk.fi

   Vincent Roca
   INRIA
   655, av. de l'Europe
   Inovallee; Montbonnot
   ST ISMIER cedex 38334
   France
   Email: vincent.roca (at) inria.fr




























Walsh, et al.            Expires March 16, 2013                [Page 27]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


9.  Change Log

9.1.  From draft-ietf-rmt-flute-sdp-02 to draft-ietf-rmt-flute-sdp-03

   One clarification in Section 3.6.1 and two clarifications in Section
   3.6.2 (no changes to the meaning).

9.2.  From draft-ietf-rmt-flute-sdp-01 to draft-ietf-rmt-flute-sdp-02

   Author affiliation update

   Changed the term "FEC OTI" to "FEC scheme" where appropriate to avoid
   misunderstandings between the current specification's use for OTI
   capability requirements description and the wider application of OTI
   for receiver FEC configuration for LCT/FLUTE objects (the latter
   being beyond the scope of the present specification).

   More specific reference to Section 7.3.1 in
   [I-D.ietf-rmt-flute-revised] for attacks against session descriptions
   is added to Section 5.

   Moved the note on out of scope congestion control to a more sensible
   place.

   Added note for Figure 1 to explain why it does not follow a
   recommendation.

   Changed spellings to US English.

9.3.  From draft-ietf-rmt-flute-sdp-00 to draft-ietf-rmt-flute-sdp-01

   New value for the "proto" sub-field, i.e.  FLUTE/UDP/ESP defined.

   New section "Security Parameters" added.  This section defines two
   possibilities which can be used to set up the needed security
   parameters for ESP.

   Clarifications for: media-level attribute overwriting of Composite
   Session Primary Media attributes; media protocol usage for Restricted
   Behavior only one; crypto attribute usage.

9.4.  From draft-mehta-rmt-flute-sdp-06 to draft-ietf-rmt-flute-sdp-00

   Document name changed to reflect the status as an official working
   group draft.

   All editorial notes removed, except those related to open CC and SEC
   discussion.



Walsh, et al.            Expires March 16, 2013                [Page 28]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   Clarified Composite Session Semantics regarding primary media.  "The
   first media line declared..." changed to "The first (leftmost) mid
   value declared...".

   Clarifying note added to disambiguate the apparent difference between
   LCT and SDP "guard interval" for session expiry and session id reuse.
   This include the non mandatory recommendation to avoid TSI reuse
   whenever possible (e.g. for a 48bit TSI and non-extremely-high-
   frequency session changes from a specific sender, this would often be
   the case).

   Documented the previously implicit assumption regarding wall clock
   synchronization.

   RFC5445 reference corrected (now in the informative references
   section).



































Walsh, et al.            Expires March 16, 2013                [Page 29]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


10.  References

10.1.  Normative References

   [I-D.ietf-rmt-flute-revised]
              Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
              "FLUTE - File Delivery over Unidirectional Transport",
              draft-ietf-rmt-flute-revised-16 (work in progress),
              June 2012.

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

   [RFC5775]  Luby, M., Watson, M., and L. Vicisano, "Asynchronous
              Layered Coding (ALC) Protocol Instantiation", RFC 5775,
              April 2010.

   [RFC5651]  Luby, M., Watson, M., and L. Vicisano, "Layered Coding
              Transport (LCT) Building Block", RFC 5651, October 2009.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4570]  Quinn, B. and R. Finlayson, "Session Description Protocol
              (SDP) Source Filters", RFC 4570, July 2006.

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052, August 2007.

   [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
              Protocol (SDP) Grouping Framework", RFC 5888, June 2010.

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

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.



Walsh, et al.            Expires March 16, 2013                [Page 30]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   [RFC4567]  Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
              Carrara, "Key Management Extensions for Session
              Description Protocol (SDP) and Real Time Streaming
              Protocol (RTSP)", RFC 4567, July 2006.

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

10.2.  Informative References

   [RFC3926]  Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
              "FLUTE - File Delivery over Unidirectional Transport",
              RFC 3926, October 2004.

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

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

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

   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

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

   [RFC4289]  Freed, N. and J. Klensin, "Multipurpose Internet Mail
              Extensions (MIME) Part Four: Registration Procedures",
              BCP 13, RFC 4289, December 2005.

   [RFC5445]  Watson, M., "Basic Forward Error Correction (FEC)
              Schemes", RFC 5445, March 2009.




Walsh, et al.            Expires March 16, 2013                [Page 31]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [3GPP.26.346]
              3GPP, "Multimedia Broadcast/Multicast Service (MBMS);
              Protocols and codecs", 3GPP TS 26.346 10.4.0, June 2012.












































Walsh, et al.            Expires March 16, 2013                [Page 32]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


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 (e.g.
   as is done for 3GPP MBMS [3GPP.26.346]).  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 FEC-OTI information.  The purpose of extended
   FEC-OTI information is to 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 neighboring 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 March 16, 2013                [Page 33]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


Appendix B.  Further Design Logic for FEC-OTI Descriptors

   There are several 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/standardized 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 instance would be unnecessary and wasteful (and probably
       result in implementations not following the flute-sdp
       specification).

   3.  FLUTE defaults to Compact No-Code FEC [RFC5445] 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
       instance.  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 instance(though it is allowed).

   4.  In cases where a FLUTE session description (SDP instance) 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 instance 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 instance)
       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 mentioned above.

   Also, in a complex case of very many FEC codes being used in the
   session giving a full list in SDP instance is not seen as being
   reasonable (but this is likely to be a rare case anyway).




Walsh, et al.            Expires March 16, 2013                [Page 34]


Internet-Draft          SDP Descriptors for FLUTE               Sep 2012


Authors' Addresses

   Rod Walsh
   Tampere University of Technology
   P.O. Box 553 (Korkeakoulunkatu 1)
   Tampere  FI-33101
   Finland

   Email: roderick.walsh (at) tut.fi


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

   Email: jani.peltotalo (at) ieee.org


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

   Email: sami.peltotalo (at) tut.fi


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

   Email: igor.curcio (at) nokia.com


   Harsh Mehta


   Email: harsh.mehta (at) gmail.com









Walsh, et al.            Expires March 16, 2013                [Page 35]


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