One document matched: draft-ietf-rmt-flute-sdp-03.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<rfc category="std" ipr="pre5378Trust200902" docName="draft-ietf-rmt-flute-sdp-03">

<front>
<title abbrev="SDP Descriptors for FLUTE" >SDP Descriptors for FLUTE</title> 

<author initials="R." surname="Walsh" fullname="Rod Walsh">
<organization>Tampere University of Technology</organization>
<address>
<postal>
<street>P.O. Box 553 (Korkeakoulunkatu 1)</street>
<city>Tampere</city>
<code>FI-33101</code>
<country>Finland</country>
</postal>
<email>roderick.walsh (at) tut.fi</email>
</address>
</author>

<author initials="J." surname="Peltotalo" fullname="Jani Peltotalo">
<organization>Tampere University of Technology</organization>
<address>
<postal>
<street>P.O. Box 553 (Korkeakoulunkatu 1)</street>
<city>Tampere</city>
<code>FI-33101</code>
<country>Finland</country>
</postal>
<email>jani.peltotalo (at) ieee.org</email>
</address>
</author>

<author initials="S." surname="Peltotalo" fullname="Sami Peltotalo">
<organization>Tampere University of Technology</organization>
<address>
<postal>
<street>P.O. Box 553 (Korkeakoulunkatu 1)</street>
<city>Tampere</city>
<code>FI-33101</code>
<country>Finland</country>
</postal>
<email>sami.peltotalo (at) tut.fi</email>
</address>
</author>

<author initials="I.D.D." surname="Curcio" fullname="Igor D.D. Curcio">
<organization>Nokia Research Center</organization>
<address>
<postal>
<street>P.O. Box 88 (Tieteenkatu 1)</street>
<city>Tampere</city>
<code>FI-33721</code>
<country>Finland</country>
</postal>
<email>igor.curcio (at) nokia.com</email>
</address>
</author>

<author initials="H." surname="Mehta" fullname="Harsh Mehta">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<code></code>
<country></country>
</postal>
<email>harsh.mehta (at) gmail.com</email>
</address>
</author>

<date day="12" month="Sep" year="2012" />
<area>Transport</area>
<workgroup>RMT</workgroup>

<keyword>FLUTE</keyword>
<keyword>SDP</keyword>
<keyword>Transport</keyword>
<keyword>Multicast</keyword>

<abstract>
<t>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.</t>
</abstract> 
</front>

<middle>
<section anchor="intro" title="Introduction">
<t>The Session Description Protocol (SDP) <xref target="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 <xref target="RFC3629">UTF-8</xref>) 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. <xref target="I-D.ietf-rmt-flute-revised">FLUTE</xref>, <xref target="RFC2974">SAP</xref>, <xref target="RFC3261">SIP</xref>, <xref target="RFC2326">RTSP</xref>, <xref target="RFC2616">HTTP</xref>, email etc.).</t>

<t>SDP defines two protocol identifiers that represent unreliable connectionless protocols. These are RTP/AVP and UDP. These are appropriate choices for multimedia streams. <xref target="RFC4145"/> defines protocol identifiers for connection-oriented reliable transports: TCP and TCP/TLS.</t>

<t>This document defines two new protocol identifiers for File Delivery over Unidirectional Transport (FLUTE) protocol <xref target="I-D.ietf-rmt-flute-revised"/> and other required SDP attributes for initiating a FLUTE session. The formal ABNF syntax <xref target="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.</t> 
</section>

<t>Note, this document may also be used to describe sessions of the experimental FLUTE specification <xref target="RFC3926"/>.</t>

<section title="Conventions Used in This Document">
<t>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 <xref target="RFC2119">RFC2119</xref>.</t>

<section title="New Terms">
<t>SDP instance: A syntactically complete SDP description of an SDP session, possibly stored in a single computer file.</t>
<t>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.</t>
</section>

</section>

<section title="FLUTE Descriptors">
<t>The FLUTE specification <xref target="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 "*").</t>

<t>The required parameters are:</t>

<list style='hanging'>
<t hangText='o'>The source IP address;</t>
<t hangText='o'>The number of channels in the session;</t>
<t hangText='o'>The destination IP address and port number for each channel in the session;</t>
<t hangText='o'>The Transport Session Identifier (TSI) of the session;</t>
<t hangText='o'>An indication that the session is a FLUTE session;</t>
<t hangText='*'>The start time and end time of the session.</t>
</list>

<t>The optional parameters are:</t>

<list style='hanging'>
<t hangText='o'>FEC scheme (a subset of FEC Object Transmission Information);</t>
<t hangText='o'>Some information that tells receiver in the first place, that the session contains files that are of interest;</t>
<t hangText='o'>Security parameters relevant for the session;</t>
<t hangText='*'>Bandwidth specification.</t>
</list>

<t>(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.)</t>

<t>(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 have an in-band mechanism for FEC machine configuration.)</t>

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

<t>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 <xref target="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 <xref target="RFC5888"/>.</t>

<t>The description of these parameters in SDP is presented in the following sections.</t>

<section title="FLUTE Protocol Identifier">
<t>The following is the ABNF syntax for an "m=" line, as specified by <xref target="RFC4566">RFC4566</xref>: </t>

<artwork><![CDATA[
media-field = "m=" media SP port ["/" integer] SP
  proto 1*(SP fmt) CRLF]]>
</artwork>

<t>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 <xref target="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 <xref target="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 <xref target="RFC4303"/>.</t>

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

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

<t>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.</t>
</section>

<section title="Composite Session Semantics">
<t>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.</t>

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

<t>The Composite Session mechanism inherits the "group" and "mid" attributes from the SDP grouping framework <xref target="RFC5888"/> and introduces the "CS" (Composite Session) token as a "semantics-extension".</t>

<t>When the Composite Session mechanism is used: the SDP grouping framework <xref target="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.</t>

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

<section title="Composite Session Semantics for FLUTE Sessions">
<t>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.</t>

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

<t>To support simple applications, as well as ensure harmony with FLUTE SDP standards outside of the IETF <xref target="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).</t>

<t>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 <xref target="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).</t>

<t>A partial example of using the Composite Session mechanism for FLUTE is shown below.</t>

<artwork><![CDATA[
<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>]]>
</artwork>

<t>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 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.</t>
</section>

<section title="Composite Session Semantics for Protocols other than FLUTE">
<t>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.</t>
</section>

</section>

<section title="Source IP Address">
<t>The Asynchronous Layered Coding (ALC) <xref target="RFC5775"/> and the Layered Coding Transport (LCT) <xref target="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.</t>

<t>The source IP address MUST be defined according to the source-filter attribute ("a=source-filter") <xref target="RFC4570"/>, with the following exceptions: </t>

<list style="symbols">
<t>The source-filter attribute MUST be included in any SDP instance describing FLUTE sessions and per FLUTE session described.</t>
<t>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.</t>
<t>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 <xref target="RFC4570"/>.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
</list>

<t>An example of the use of this attribute is:</t>

<artwork><![CDATA[
a=source-filter: incl IN IP6 * 2001:0DB8:1:2:240:96FF:FE25:8EC9]]>
</artwork>

<t>This example uses the source-filter attribute to describe an IPv6 source address.</t>

</section>

<section title="Transport Session Identifier">
<t>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 <xref target="RFC5651"/>. Note, the SDP specification <xref target="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).</t>

<t>The TSI MUST be described by the "flute-tsi" attribute.</t>

<t>There MUST be exactly one occurrence of the "flute-tsi" attribute per FLUTE session description of an SDP instance.</t>

<list style="symbols">
<t> 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.</t>

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

<t>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.</t>
</list>

<t>The syntax for the attribute in ABNF is given below:</t>

<artwork><![CDATA[
flute-tsi-line = "a=flute-tsi:" tsi CRLF
tsi = 1*DIGIT]]>
</artwork>

<t>Note, the range of values a TSI can adopt depends on the bit-length of the TSI for a session as defined by RFC5651 <xref target="RFC5651"/>.</t>

</section>

<section title="Session Timing Parameters">
<t>The SDP timing field "t=" <xref target="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.</t>
<t>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 <xref target="RFC5905"/>.</t>
</section>

<section title="Channelization Descriptors">
<t>This section specifies the description of the channel(s) used within a FLUTE session. The required parameters for channelization description are:</t>

<list style="symbols">
<t>Number of channels</t>
<t>Destination IP address and port number for channels</t>
</list>

<section title="Number of Channels">
<t>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 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.</t>

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

<t>When the "flute-ch" attribute is used:</t>

<list style="symbols">
<t>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.</t>

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

<t>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.</t>
</list>

<t>The syntax for the attribute in ABNF is given below: </t>

<artwork><![CDATA[
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.]]>
</artwork>

</section>

<section title="Destination IP Address and Port Number for Channels">
<t>SDP media-level information describes one or more channels. The channel parameters MUST be given per channel and are:</t>

<list style="symbols">
<t>Destination IP address</t>
<t>Destination port number</t>
</list>

<t>The destination IP address MUST be defined according to the connection data field ("c=") of SDP <xref target="RFC4566"/>. The destination port number MUST be defined according to the "port" sub-field of the media description field ("m=") of SDP <xref target="RFC4566"/>.</t>

<t>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").</t>

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

<t>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).</t>

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

<t>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 single composite session (when the SDP describes multiple FLUTE sessions) or for a single SDP instance (when only one FLUTE session is described).</t>

<t>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:</t>

<artwork><![CDATA[
m=application 12345 FLUTE/UDP *
c=IN IP6 FF33::8000:1]]>
</artwork>

<t>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).</t>

<t>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 <xref target="RFC4607"/>.</t>

</section>
</section>

<section title="FEC Scheme">
<t>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) <xref target="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:</t>

<list style="symbols">
<t>FEC Encoding ID</t>
<t>FEC Instance ID (for FEC Encoding IDs 128-255)</t>
</list>

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

<t>The syntax for the attributes in ABNF is given below:</t>

<artwork><![CDATA[
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]]>
</artwork>

<t>Examples of FEC scheme information are shown in Section 4.</t>

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

<t>A more complete list of notes on the design logic for the FEC-OTI descriptors is provided as an appendix to this document.</t>

</section>

<section title="Content Description Pointer">
<t>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.</t>

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

<t>The syntax for the attribute in ABNF is given below:</t>

<artwork><![CDATA[
content-desc-line = "a=content-desc:" URI-reference CRLF
;URI-reference is as defined in [RFC3986].]]>
</artwork>

<t>An example of content description pointer is shown in Section 4.</t>

</section>

<section title="Security Parameters">
<t>To support the baseline secure ALC operation <xref target="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.</t>

<t>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 <xref target="RFC4567"/> can be used to carry messages, as specified by a key management protocol, in order to secure the media. In <xref target="RFC4567"/> the usage of the Multimedia Internet KEYing (MIKEY) key management protocol <xref target="RFC3830"/> is defined and guidelines for the registration of additional key management protocols is also provided.</t>

<t>Secondly, the "crypto" attribute defined in <xref target="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). <xref target="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 <xref target="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.</t>

</section>

<section title="Bandwidth Specification">
<t>The specification of bandwidth (data rate) is OPTIONAL and where included in the SDP it SHALL adhere to the following rules.</t>

<t>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 <xref target="RFC3890"/> on media-level, although the AS bandwidth modifier <xref target="RFC4566"/> MAY be used on media-level.</t>

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

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

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

<section title="Bandwidth Specification for Composite Sessions">
<t>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.</t>

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

</section>
</section>

<section title="SDP Specific Parameters">
<t>SDP <xref target="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.</t>
</section>

</section>

<section title="SDP Syntax Examples">
<t>This section gives examples of the use of SDP attributes to describe a FLUTE session.</t>

<figure title="An SDP Instance for a FLUTE Session with Two Channels" anchor="sdp-example-1">
<artwork><![CDATA[
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]]>
</artwork>
</figure>

<t>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.)</t> 

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

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

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

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

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

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

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

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

<figure title="An SDP Instance for a FLUTE Session with One Channel" anchor="sdp-example-2">
<artwork><![CDATA[
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 ]]>
</artwork>
</figure>

<t>Figure 2 shows an example SDP instance for a FLUTE session with one channel.</t>

<figure title="An SDP Instance for Multiple (two) FLUTE Sessions using the Composite Session Mechanism" anchor="sdp-example-3">
<artwork><![CDATA[
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]]>
</artwork>
</figure>

<t>Figure 3 shows an example SDP instance for multiple FLUTE sessions using the Composite Session mechanism.</t>
</section>

<section title="Security Considerations">
<t>See <xref target="RFC4566"/> for security considerations specific to the Session Description Protocol in general. See also <xref target="RFC4570"/> for security consideration related to source address filters.</t>

<t><xref target="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.</t>

</section>

<section title="IANA Considerations">
<section title="Transport Protocol">
<t>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 <xref target="I-D.ietf-rmt-flute-revised">FLUTE</xref> running over UDP/IP. "FLUTE/UDP/ESP" is a reference to <xref target="I-D.ietf-rmt-flute-revised">FLUTE</xref> running over UDP/IP and the session security is achieved by means of IPsec/ESP in a transport mode <xref target="RFC4303"/>.</t>

<section title="Media formats ("fmt")">
<t>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 <xref target="RFC4289"/>.</t>
</section>
</section>

<section title="Attribute Names">
<t>As recommended by <xref target="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:</t>

<t>The following contact information shall be used for all registrations included here:</t>

<artwork><![CDATA[
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
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]]>
</artwork>
</section>

<section title="Composite Session Token to Differentiate FLUTE Sessions">
<t>IANA needs to register the following new 'semantics' attribute for the SDP grouping framework <xref target="RFC5888"/>:</t>

<artwork><![CDATA[
Semantics                            Token      Reference
---------------------------------    -----      ---------
Composite Session    		     CS         This document]]>
</artwork>
<t>It should be registered in the SDP parameters registry (http://www.iana.org/assignments/sdp-parameters) under Semantics for the "group" SDP Attribute.</t>
</section>
</section>

<section title="Acknowledgements">
<t>The authors would like to thank all the people who gave feedback on this document.</t>
</section>

<section title="Contributors">

<t>Magnus Westerlund<vspace />
Ericsson Research<vspace />
Ericsson AB<vspace />

SE-164 80 Stockholm<vspace />
Sweden<vspace />
EMail: Magnus.Westerlund (at) ericsson.com</t>

<t>Jörg Ott<vspace />
Aalto University<vspace />
Otakaari 5A<vspace />
FI-02150 Espoo<vspace />
Finland<vspace />
EMail: jo (at) netlab.tkk.fi</t>

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

</section>

<section title="Change Log">

<section title="From draft-ietf-rmt-flute-sdp-02 to draft-ietf-rmt-flute-sdp-03">
<t>One clarification in Section 3.6.1 and two clarifications in Section 3.6.2 (no changes to the meaning).</t>  
</section>

<section title="From draft-ietf-rmt-flute-sdp-01 to draft-ietf-rmt-flute-sdp-02">
<t>Author affiliation update</t>
<t>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).</t>
<t>More specific reference to Section 7.3.1 in <xref target="I-D.ietf-rmt-flute-revised"/> for attacks against session descriptions is added to Section 5.</t>
<t>Moved the note on out of scope congestion control to a more sensible place.</t>
<t>Added note for Figure 1 to explain why it does not follow a recommendation.</t>
<t>Changed spellings to US English.</t>
</section>

<section title="From draft-ietf-rmt-flute-sdp-00 to draft-ietf-rmt-flute-sdp-01">
<t>New value for the "proto" sub-field, i.e. FLUTE/UDP/ESP defined.</t>
<t>New section "Security Parameters" added. This section defines two possibilities which can be used to set up the needed security parameters for ESP.</t>
<t>Clarifications for: media-level attribute overwriting of Composite Session Primary Media attributes; media protocol usage for Restricted Behavior only one; crypto attribute usage.</t>
</section>

<section title="From draft-mehta-rmt-flute-sdp-06 to draft-ietf-rmt-flute-sdp-00">
<t>Document name changed to reflect the status as an official working group draft.</t> 
<t>All editorial notes removed, except those related to open CC and SEC discussion.</t>
<t>Clarified Composite Session Semantics regarding primary media. "The first media line declared..." changed to "The first (leftmost) mid value declared...".</t>
<t>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).</t>
<t>Documented the previously implicit assumption regarding wall clock synchronization.</t>
<t>RFC5445 reference corrected (now in the informative references section).</t>

</section>
</section>

</middle>

<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-rmt-flute-revised.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.5775.xml"?>
<?rfc include="reference.RFC.5651.xml"?>
<?rfc include="reference.RFC.5234.xml"?>
<?rfc include="reference.RFC.4566.xml"?>
<?rfc include="reference.RFC.4570.xml"?>
<?rfc include="reference.RFC.3629.xml"?>
<?rfc include="reference.RFC.3986.xml"?>
<?rfc include="reference.RFC.5052.xml"?>
<?rfc include="reference.RFC.5888.xml"?>
<?rfc include="reference.RFC.3890.xml"?>
<?rfc include="reference.RFC.4303.xml"?>
<?rfc include="reference.RFC.4567.xml"?>
<?rfc include="reference.RFC.4568.xml"?>
<?rfc include="reference.RFC.3830.xml"?>
</references>

<references title="Informative References">
<?rfc include="reference.RFC.3926.xml"?>
<?rfc include="reference.RFC.2974.xml"?>
<?rfc include="reference.RFC.3261.xml"?>
<?rfc include="reference.RFC.2616.xml"?>
<?rfc include="reference.RFC.4145.xml"?>
<?rfc include="reference.RFC.4607.xml"?>
<?rfc include="reference.RFC.2326.xml"?>
<?rfc include="reference.RFC.4289.xml"?>
<?rfc include="reference.RFC.5445.xml"?>
<?rfc include="reference.RFC.5905.xml"?>
<?rfc include="reference.3GPP.26.346.xml"?>
</references>

<section title="Use of FEC Attributes with RTP Sessions (informative)">
<t>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 <xref target="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).</t>

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

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

<t>The syntax for the attribute in ABNF is given below: </t>

<artwork><![CDATA[
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 / "+" / "/"]]>
</artwork>

</section>

<section title="Further Design Logic for FEC-OTI Descriptors">
<t>There are several reasons that the FEC Encoding and Instance IDs are optional capabilities descriptions:</t>

<list style="numbers">
<t>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).</t>

<t>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).</t>

<t>FLUTE defaults to Compact No-Code FEC <xref target="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).</t>

<t>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).</t>

<t>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.</t>
</list>

<t>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).</t>

</section>

</back>
</rfc>