doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc6695.txt b/doc/rfc/rfc6695.txt
new file mode 100644
index 0000000..930d15a
--- /dev/null
+++ b/doc/rfc/rfc6695.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          R. Asati
+Request for Comments: 6695                                 Cisco Systems
+Category: Informational                                      August 2012
+ISSN: 2070-1721
+
+
+            Methods to Convey Forward Error Correction (FEC)
+                  Framework Configuration Information
+
+Abstract
+
+   The Forward Error Correction (FEC) Framework document (RFC 6363)
+   defines the FEC Framework Configuration Information necessary for the
+   FEC Framework operation.  This document describes how to use
+   signaling protocols such as the Session Announcement Protocol (SAP),
+   the Session Initiation Protocol (SIP), the Real Time Streaming
+   Protocol (RTSP), etc. for determining and communicating the
+   configuration information between sender(s) and receiver(s).
+
+   This document doesn't define any new signaling protocol.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6695.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asati                         Informational                     [Page 1]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+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
+   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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Specification Language ..........................................3
+   3. Terminology/Abbreviations .......................................3
+   4. FEC Framework Configuration Information .........................4
+      4.1. Encoding Format ............................................5
+   5. Signaling Protocol Usage ........................................6
+      5.1. Signaling Protocol for Multicasting ........................7
+           5.1.1. Sender Procedure ....................................9
+           5.1.2. Receiver Procedure .................................11
+      5.2. Signaling Protocol for Unicasting .........................12
+           5.2.1. SIP ................................................12
+           5.2.2. RTSP ...............................................13
+   6. Security Considerations ........................................14
+   7. IANA Considerations ............................................14
+   8. Acknowledgments ................................................14
+   9. References .....................................................14
+      9.1. Normative References ......................................14
+      9.2. Informative References ....................................15
+
+1.  Introduction
+
+   The FEC Framework document [RFC6363] defines the FEC Framework
+   Configuration Information that governs the overall FEC Framework
+   operation common to any FEC scheme.  This information must be
+   available at both the sender and receiver(s).
+
+   This document describes how various signaling protocols such as the
+   Session Announcement Protocol (SAP) [RFC2974], the Session Initiation
+   Protocol (SIP) [RFC3261], the Real Time Streaming Protocol (RTSP)
+   [RFC2326], etc. could be used by the FEC scheme (and/or the Content
+   Delivery Protocol (CDP)) to communicate the configuration information
+
+
+
+Asati                         Informational                     [Page 2]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   between the sender and receiver(s).  The configuration information
+   may be encoded in any compatible format, such as the Session
+   Description Protocol (SDP) [RFC4566], XML, etc., though this document
+   refers to SDP encoding usage quite extensively.
+
+      Note that this document doesn't define any new signaling protocol;
+      rather, it just provides examples of how existing protocols should
+      be used.  Also, the list of signaling protocols for unicast is not
+      intended to be a complete list.
+
+   This document doesn't describe any FEC-Scheme-Specific Information
+   (FSSI) (for example, how source blocks are constructed) or any
+   sender- or receiver-side operation for a particular FEC scheme (for
+   example, whether the receiver makes use of one or more repair flows
+   that are received).  Such FEC scheme specifics should be covered in
+   separate document(s).  This document doesn't mandate a particular
+   encoding format for the configuration information either.
+
+   This document is structured as follows: Section 3 describes the terms
+   used in this document, Section 4 describes the FEC Framework
+   Configuration Information, Section 5 describes how to use signaling
+   protocols for multicast and unicast applications, and Section 6
+   discusses security considerations.
+
+2.  Specification Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Terminology/Abbreviations
+
+   This document makes use of the terms/abbreviations defined in the FEC
+   Framework document [RFC6363] and defines the following additional
+   terms:
+
+   o  Media Sender - Node providing original media flow(s) to the 'FEC
+      Sender'
+
+   o  Media Receiver - Node performing the media decoding
+
+   o  FEC Sender - Node performing the FEC encoding on the original
+      media flow(s) to produce the FEC repair flow(s)
+
+   o  FEC Receiver - Node performing the FEC decoding, as needed, and
+      providing the original media flow(s) to the Media Receiver
+
+   o  Sender - Same as FEC Sender
+
+
+
+Asati                         Informational                     [Page 3]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   o  Receiver - Same as FEC Receiver
+
+   o  (Media) Flow - A single media instance, i.e., an audio stream or a
+      video stream
+
+   This document deliberately refers to the 'FEC Sender' and 'FEC
+   Receiver' as the 'Sender' and 'Receiver', respectively.
+
+4.  FEC Framework Configuration Information
+
+   The FEC Framework [RFC6363] defines a minimum set of information that
+   is communicated between the sender and receiver(s) for a proper
+   operation of an FEC scheme.  This information is referred to as "FEC
+   Framework Configuration Information".  This is the information that
+   the FEC Framework needs in order to apply FEC protection to the
+   transport flows.
+
+   A single instance of the FEC Framework provides FEC protection for
+   all packets of a specified set of source packet flows, by means of
+   one or more packet flows consisting of repair packets.  As per
+   Section 5.5 of the FEC Framework document [RFC6363], the FEC
+   Framework Configuration Information includes the following for each
+   FEC Framework instance:
+
+   1. Identification of the repair flow(s)
+
+   2. Identification of source flow(s)
+
+   3. Identification of FEC scheme
+
+   4. Length of Explicit Source FEC Payload ID
+
+   5. FSSI
+
+   FSSI basically provides an opaque container to encode FEC-scheme-
+   specific configuration information such as buffer size, decoding
+   wait-time, etc.  Please refer to the FEC Framework document [RFC6363]
+   for more details.
+
+   The usage of signaling protocols described in this document requires
+   that the application layer responsible for the FEC Framework instance
+   provide the value for each of the configuration information
+   parameters (listed above) encoded as per the chosen encoding format.
+   In case of failure to receive the complete information, the signaling
+   protocol module must return an error for Operations, Administration,
+   and Maintenance (OAM) purposes and optionally convey this error to
+   the application layer.  Please refer to Figure 1 of the FEC Framework
+   document [RFC6363] for further illustration.
+
+
+
+Asati                         Informational                     [Page 4]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   This document does not make any assumption that the 'FEC Sender' and
+   'Media Sender' functionalities are implemented on the same device,
+   though that may be the case.  Similarly, this document does not make
+   any assumption that 'FEC Receiver' and 'Media Receiver'
+   functionalities are implemented on the same device, though that may
+   be the case.  There may also be more than one Media Sender.
+
+4.1.  Encoding Format
+
+   The FEC Framework Configuration Information (listed above in
+   Section 4) may be encoded in any format, such as SDP, XML, etc., as
+   chosen or preferred by a particular FEC Framework instance.  The
+   selection of such encoding formats or syntax is independent of the
+   signaling protocol and beyond the scope of this document.
+
+   Any encoding format that is selected for a particular FEC Framework
+   instance must be known to the signaling protocol.  This is to provide
+   a means (e.g., a field such as Payload Type) in the signaling
+   protocol message(s) to convey the chosen encoding format for the
+   configuration information so that the payload (i.e., configuration
+   information) can be correctly parsed as per the semantics of the
+   chosen encoding format at the receiver.  Please note that the
+   encoding format is not a negotiated parameter, but rather a property
+   of a particular FEC Framework instance and/or its implementation.
+
+   Additionally, the encoding format for each FEC Framework
+   configuration parameter must be defined in terms of a sequence of
+   octets that can be embedded within the payload of the signaling
+   protocol message(s).  The length of the encoding format must either
+   be fixed or be derived by examining the encoded octets themselves.
+   For example, the initial octets may include some kind of length
+   indication.
+
+   Independent of the encoding formats supported by an FEC scheme, each
+   instance of the FEC Framework must use a single encoding format to
+   describe all of the configuration information associated with that
+   instance.  The signaling protocol specified in this document should
+   not validate the encoded information, though it may validate the
+   syntax or length of the encoded information.
+
+   The reader may refer to the SDP elements document [RFC6364], which
+   describes the usage of the 'SDP' encoding format as an example
+   encoding format for the FEC Framework Configuration Information.
+
+
+
+
+
+
+
+
+Asati                         Informational                     [Page 5]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+5.  Signaling Protocol Usage
+
+   The FEC Framework [RFC6363] requires that certain FEC Framework
+   Configuration Information be available to both the sender and
+   receiver(s).  This configuration information is almost always
+   formulated at the sender (or on behalf of the sender) and somehow
+   made available at the receiver(s).  While one may envision a static
+   method to populate the configuration information at both the sender
+   and receiver(s), it would not be optimal, since it would (a) require
+   the knowledge of every receiver in advance, (b) require the time and
+   means to configure each receiver and sender, and (c) increase the
+   possibility of misconfiguration.  Hence, there is a benefit in using
+   a dynamic method (i.e., signaling protocol) to convey the
+   configuration information between the sender and one or more
+   receivers.
+
+   Since the configuration information may be needed at a particular
+   receiver versus many receivers (depending on the multimedia stream
+   being unicast (e.g., Video on Demand (VoD); or multicast, e.g.,
+   broadcast or IPTV), we need two types of signaling protocols -- one
+   to deliver the configuration information to many receivers via
+   multicasting (as described in Section 5.1), and the other to deliver
+   the configuration information to one and only one receiver via
+   unicasting (as described in Section 5.2).
+
+   Figure 1 below illustrates a sample topology showing the FEC Sender
+   and FEC Receiver (which may or may not be the Media Sender and Media
+   Receiver, respectively) such that FEC_Sender1 is serving
+   FEC_Receiver11, FEC_Receiver12, and FEC_Receiver13 via the multicast
+   signaling protocol, whereas FEC_Sender2 is serving only FEC_Receiver2
+   via the unicast signaling protocol.
+
+          FEC_Sender2---------|         |--------FEC_Receiver2
+                              |         |
+          FEC_Sender1-------IP/MPLS network
+                                  |-----------FEC_Receiver11
+                                  |-----------FEC_Receiver12
+                                  |-----------FEC_Receiver13
+
+               Figure 1.  Topology Using Sender and Receiver
+
+   The rest of the document continues to use the terms 'Sender' and
+   'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver',
+   respectively.
+
+
+
+
+
+
+
+Asati                         Informational                     [Page 6]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+5.1.  Signaling Protocol for Multicasting
+
+   This specification describes using SAP version 2 [RFC2974] as the
+   signaling protocol to multicast the configuration information from
+   one sender to many receivers.  The apparent advantage is that the
+   server doesn't need to maintain any state for any receiver using SAP.
+
+      SAP messages are carried over UDP over IP with destination UDP
+      port 9875, as described in [RFC2974], and a source UDP port of any
+      available number.  The SAP message(s) MUST contain an
+      authentication header using Pretty Good Privacy (PGP)
+      authentication.
+
+   At the high level, a sender, acting as the SAP announcer, signals the
+   FEC Framework Configuration Information for each FEC Framework
+   instance available at the sender, using the SAP message(s).  The
+   configuration information, encoded in a suitable format as per
+   Section 4.1, is carried in the payload of the SAP message(s).  A
+   receiver, acting as the SAP listener, listens on a well-known UDP
+   port and at least one well-known multicast group IP address (as
+   explained in Section 5.1.1).  This enables the receiver to receive
+   the SAP message(s) and obtain the FEC Framework Configuration
+   Information for each FEC Framework instance.
+
+   Using the configuration information, the receiver becomes aware of
+   available FEC protection options, corresponding multicast trees (S,G
+   or *,G addresses), etc.  The receiver may subsequently subscribe to
+   one or more multicast trees to receive the FEC streams using out-of-
+   band multicasting techniques such as PIM [RFC4601].  This, however,
+   is outside the scope of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asati                         Informational                     [Page 7]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   Figure 2 below (reprinted from [RFC2974]) illustrates the SAP packet
+   format.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | V=1 |A|R|T|E|C|   auth len    |         msg id hash           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     :                originating source (32 or 128 bits)            :
+     :                                                               :
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                    optional authentication data               |
+     :                              ....                             :
+     *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
+     |                      optional payload type                    |
+     +                                         +-+- - - - - - - - - -+
+     |                                         |0|                   |
+     + - - - - - - - - - - - - - - - - - - - - +-+                   |
+     |                                                               |
+     :                            payload                            :
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                       Figure 2.  SAP Message Format
+
+   While [RFC2974] includes explanations for each field, it is worth
+   discussing the 'Payload' and 'Payload Type' fields.  The 'Payload'
+   field is used to carry the FEC Framework Configuration Information.
+   Subsequently, the optional 'Payload Type' field, which is a MIME
+   content type specifier, is used to describe the encoding format used
+   to encode the payload.
+
+      For example, the 'Payload Type' field may be application/sdp if
+      the FEC Framework Configuration Information is encoded in SDP
+      format and carried in the SAP payload.  Similarly, it would be
+      application/xml if the FEC Framework Configuration Information
+      were encoded in XML format.
+
+   Section 5.1.1 describes the sender procedure, whereas Section 5.1.2
+   describes the receiver procedure in the context of config signaling
+   using [RFC2974].
+
+
+
+
+
+
+
+
+
+Asati                         Informational                     [Page 8]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+5.1.1.  Sender Procedure
+
+   The sender signals the FEC Framework Configuration Information for
+   each FEC Framework instance in a periodic SAP announcement message
+   [RFC2974].  The SAP announcement message is sent to a well-known
+   multicast IP address and UDP port, as specified in [RFC2974].  The
+   announcement is multicast with the same scope as the session being
+   announced.
+
+   The SAP module at the sender obtains the FEC Framework Configuration
+   Information per instance from the 'FEC Framework' module and places
+   that in the SAP payload accordingly.  A single SAP (announcement)
+   message must carry the FEC Framework Configuration Information for a
+   single FEC Framework instance.  The SAP message is then sent over UDP
+   over IP.
+
+      While it is possible to aggregate multiple SAP (announcement)
+      messages in a single UDP datagram as long as the resulting UDP
+      datagram length is less than the IP MTU of the outgoing interface,
+      this specification does not recommend it, since there is no length
+      field in the SAP header to identify a SAP message boundary.
+      Hence, this specification recommends that a single SAP
+      announcement message be sent in a UDP datagram.
+
+   The IP packet carrying the SAP message must be sent to a destination
+   IP address of one of the following, depending on the selected scope:
+
+   - 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255 is
+     selected for the FEC stream), or
+
+   - ff0x:0:0:0:0:0:2:7ffe (if IPv6 multicasting is selected for the FEC
+     stream, where x is the 4-bit scope value), or
+
+   - the highest multicast address (239.255.255.255, for example) in the
+     relevant administrative scope zone (if IPv4 administrative scope
+     239.0.0.0-239.255.255.255 is selected for the FEC stream)
+
+   As defined in [RFC2974], the IP packet carrying a SAP message must
+   use destination UDP port 9875 and a source UDP port of any available
+   number.  The default IP Time to Live (TTL) value (or Hop Limit value)
+   should be 255 at the sender, though the sender implementation may
+   allow it to be any other value to implicitly create the multicast
+   boundary for SAP announcements.  The IP Differentiated Services Code
+   Point (DSCP) field may be set to any value that indicates a desired
+   QoS treatment in the IP network.
+
+
+
+
+
+
+Asati                         Informational                     [Page 9]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   The IP packet carrying the SAP message must be sent with a source IP
+   address that is reachable by the receiver.  The sender may assign the
+   same IP address in the 'originating source' field of the SAP message
+   as that used in the source IP address of the IP packet.
+
+   Furthermore, the FEC Framework Configuration Information must not
+   include any of the reserved multicast group IP addresses for the FEC
+   streams (i.e., source or repair flows), though it may use the same IP
+   address as the 'originating source' address to identify the FEC
+   streams (i.e., source or repair flows).  Please refer to IANA
+   assignments for multicast addresses.
+
+   The sender must periodically send the 'SAP announcement' message to
+   ensure that the receiver doesn't purge the cached entry or entries
+   from the database and doesn't trigger the deletion of the FEC
+   Framework Configuration Information.
+
+   While the time interval between repetitions of an announcement can be
+   calculated as per the very sophisticated but complex method explained
+   in [RFC2974], this document recommends a simpler method in which the
+   user specifies the time interval in the range of 1-200 seconds, with
+   a suggested default value of 60 seconds.  In this method, the 'time
+   interval' may be signaled in the SAP message payload, e.g., within
+   the FEC Framework Configuration Information.
+
+      Note that SAP doesn't allow the time interval to be signaled in
+      the SAP header.  Hence, the usage of a simpler method requires
+      that the time interval be included in the FEC Framework
+      Configuration Information if the default time interval (60
+      seconds) for SAP message repetitions is not used.  For example,
+      the usage of the 'r=' (repeat time) field in SDP may convey the
+      time interval value if the SDP encoding format is used.
+
+   The time interval must be chosen to ensure that SAP announcement
+   messages are sent out before the corresponding multicast routing
+   entry, e.g., (S,G) or (*,G) (corresponding to the SAP multicast
+   tree(s)) on the router(s) times out.  (It is worth noting that the
+   default timeout period for the multicast routing entry is
+   210 seconds, per the PIM specification [RFC4601], though the timeout
+   period may be set to another value as allowed by the router
+   implementation.)
+
+      A SAP implementation may also support the complex method for
+      determining the SAP announcement time interval and provide the
+      option to select it.
+
+
+
+
+
+
+Asati                         Informational                    [Page 10]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   The sender may choose to delete the announced FEC Framework
+   Configuration Information, as defined in Section 4 of [RFC2974].  The
+   explicit deletion is useful if the sender no longer desires to send
+   any more FEC streams.
+
+   If the sender needs to modify the announced FEC Framework
+   Configuration Information for one or more FEC instances, then the
+   sender must send a new announcement message with a different 'Message
+   Identifier Hash' value as per the rules described in Section 5 of
+   RFC 2974 [RFC2974].  Such an announcement message should be sent
+   immediately (without having to wait for the time interval) to ensure
+   that the modifications are received by the receiver as soon as
+   possible.  The sender must also send the SAP deletion message to
+   delete the previous SAP announcement message (i.e., with the previous
+   'Message Identifier Hash' value).
+
+5.1.2.  Receiver Procedure
+
+   The receiver must listen on UDP port 9875 for packets arriving with
+   an IP destination address of either 224.2.127.254 (if an IPv4 global
+   scope session is used for the FEC stream), ff0x:0:0:0:0:0:2:7ffe (if
+   IPv6 is selected, where x is the 4-bit scope value), or the highest
+   IP address (239.255.255.255, for example) in the relevant
+   administrative scope zone (if IPv4 administrative scope 239.0.0.0-
+   239.255.255.255 is selected for the FEC stream).  These IP addresses
+   are mandated for SAP usage by RFC 2974 [RFC2974].
+
+   The receiver, upon receiving a SAP announcement message, creates an
+   entry, if it doesn't already exist, in a local database and passes
+   the FEC Framework Configuration Information from the SAP Payload
+   field to the 'FEC Framework' module.  Each entry also maintains a
+   timeout value, which is (re)set to five times the time interval
+   value, which in turn is either the default of 60 seconds or the value
+   signaled by the sender.
+
+      Note that SAP doesn't allow the time interval to be signaled in
+      the SAP header.  Hence, the time interval should be included in
+      the FEC Framework Configuration Information -- for example, the
+      usage of the 'r=' (repeat time) field in SDP to convey the time
+      interval value if the SDP encoding format is used.
+
+   The timeout value associated with each entry is reset when the
+   corresponding announcement (please see Section 5 of [RFC2974]) is
+   received.  If the timeout value for any entry reaches zero, then that
+   entry must be deleted from the database, as described in Section 4 of
+   [RFC2974].  The receiver, upon receiving a SAP delete message, must
+   delete the matching SAP entry in its database, as described in
+   Section 4 of [RFC2974].
+
+
+
+Asati                         Informational                    [Page 11]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   The deletion of a SAP entry must result in the receiver no longer
+   using the relevant FEC Framework Configuration Information for the
+   corresponding instance and no longer subscribing to any related FEC
+   streams.
+
+5.2.  Signaling Protocol for Unicasting
+
+   This document describes leveraging any signaling protocol that is
+   already used by the unicast application, for exchanging the FEC
+   Framework Configuration Information between two nodes.
+
+   For example, a multimedia (VoD) client may send a request via
+   unicasting for a particular content to the multimedia (VoD) server,
+   which may offer various options such as encodings, bitrates,
+   transport, etc. for the content.  The client selects the suitable
+   options and answers the server, paving the way for the content to be
+   unicast on the chosen transport from the server to the client.  This
+   offer/answer signaling, described in [RFC3264], is commonly utilized
+   by many application protocols, such as SIP, RTSP, etc.
+
+   The fact that two nodes desiring unicast communication almost always
+   rely on an application to first exchange the application-related
+   parameters via the signaling protocol makes it logical to enhance
+   such signaling protocol(s) to (a) convey the desire for the FEC
+   protection and (b) subsequently also exchange FEC parameters, i.e.,
+   the FEC Framework Configuration Information.  This enables the node
+   acting as the offerer to offer 'FEC Framework Configuration
+   Information' for each available FEC instance and the node acting as
+   the answerer to convey the chosen FEC Framework instance(s) to the
+   offerer.  The usage of the FEC Framework instance is explained in the
+   FEC Framework document [RFC6363].
+
+   While enhancing an application's signaling protocol to exchange FEC
+   parameters is one method (briefly explained above), an alternative
+   method would be to have a unicast-based generic protocol that could
+   be used by two nodes, independent of the application's signaling
+   protocol.  The latter is not covered by this document, of course.
+
+   The remainder of this section provides example signaling protocols
+   and explains how they can be used to exchange the FEC Framework
+   Configuration Information.
+
+5.2.1.  SIP
+
+   SIP [RFC3261] is an application-level signaling protocol to create,
+   modify, and terminate multimedia sessions with one or more
+   participants.  SIP also enables the participants to discover one
+   another and to agree on a characterization of a multimedia session
+
+
+
+Asati                         Informational                    [Page 12]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   they would like to share.  SIP runs on either TCP, UDP, or Stream
+   Control Transmission Protocol (SCTP) transport and uses SDP as the
+   encoding format to describe multimedia session attributes.
+
+   SIP already uses an offer/answer model with SDP as described in
+   [RFC3264] to exchange information between two nodes to establish
+   unicast sessions between them.  This document extends the usage of
+   this model for exchanging the FEC Framework Configuration Information
+   (described in Section 4).  Any SDP-specific enhancements to
+   accommodate the FEC Framework are covered in the SDP elements
+   specification [RFC6364].
+
+5.2.2.  RTSP
+
+   RTSP [RFC2326] is an application-level signaling protocol for control
+   over the delivery of data with real-time properties.  RTSP provides
+   an extensible framework to enable controlled, on-demand delivery of
+   real-time data such as audio and video.  RTSP runs on either TCP or
+   UDP transports.
+
+   RTSP already provides an ability to extend the existing method with
+   new parameters.  This specification defines the
+   'FEC-protection-needed' option tag (please see Section 7 for IANA
+   Considerations) and prescribes including it in the Require (or
+   Proxy-Require) header of SETUP (method) request messages, so as to
+   request FEC protection for the data.
+
+   The node receiving such a request either responds with a '200 OK'
+   message that includes offers, i.e., available FEC options (e.g., FEC
+   Framework Configuration Information for each instance) or a '551
+   Option not supported' message.  A sample of a related message
+   exchange is shown below.
+
+      Node1->Node2:  SETUP < ... > RTSP/1.0
+                     CSeq: 1
+                     Transport: <omitted for simplicity>
+                     Require: FEC-protection-needed
+
+      Node2->Node1:  RTSP/1.0 200 OK
+                     CSeq: 1
+                     Transport: <omitted for simplicity>
+
+   The requesting node (Node1) may then send a new SETUP message to
+   convey the selected FEC protection to Node2 and proceed with regular
+   RTSP messaging.
+
+
+
+
+
+
+Asati                         Informational                    [Page 13]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   Suffice it to say that if the requesting node (Node1) received a '551
+   Option not supported' response from Node2, then the requesting node
+   (Node1) may send the SETUP message without using the Require header.
+
+6.  Security Considerations
+
+   This document recommends that SAP message(s) be authenticated to
+   ensure sender authentication, as described in Section 5.1.
+
+   There are no additional security considerations other than those
+   already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and
+   [RFC3261] for SIP.
+
+7.  IANA Considerations
+
+   IANA has registered a new RTSP option tag (option-tag), listed below,
+   in the RTSP/1.0 Option Tags table of the "Real Time Streaming
+   Protocol (RTSP)/1.0 Parameters" registry available from
+   http://www.iana.org/, and it provides the following information in
+   compliance with Section 3.8.1 of [RFC2326]:
+
+      o  Name of option-tag:  FEC-protection-needed
+
+      o  Description:         See Section 5.2.2
+
+      o  Change Control:      IETF
+
+8.  Acknowledgments
+
+   Thanks to Colin Perkins for pointing out the issue with the time
+   interval for the SAP messages.  Additionally, thanks to Vincent Roca,
+   Ali Begen, Mark Watson, Ulas Kozat, and David Harrington for greatly
+   improving this document.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2974]   Handley, M., Perkins, C., and E. Whelan, "Session
+               Announcement Protocol", RFC 2974, October 2000.
+
+
+
+
+
+
+
+
+Asati                         Informational                    [Page 14]
+
+RFC 6695             FEC Framework Config Signaling          August 2012
+
+
+   [RFC6363]   Watson, M., Begen, A., and V. Roca, "Forward Error
+               Correction (FEC) Framework", RFC 6363, October 2011.
+
+   [RFC6364]   Begen, A., "Session Description Protocol Elements for the
+               Forward Error Correction (FEC) Framework", RFC 6364,
+               October 2011.
+
+9.2.  Informative References
+
+   [RFC2326]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+               Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+   [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.
+
+   [RFC3264]   Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+               with Session Description Protocol (SDP)", RFC 3264,
+               June 2002.
+
+   [RFC4566]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+               Description Protocol", RFC 4566, July 2006.
+
+   [RFC4601]   Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+               "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+               Protocol Specification (Revised)", RFC 4601, August 2006.
+
+Author's Address
+
+   Rajiv Asati
+   Cisco Systems
+   7025-6 Kit Creek Rd.
+   RTP, NC  27709-4987
+
+   EMail: rajiva@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Asati                         Informational                    [Page 15]
+