Methods to Convey Forward Error Correction (FEC) Framework Configuration Information
draft-ietf-fecframe-config-signaling-09
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6695.
|
|
---|---|---|---|
Author | Rajiv Asati | ||
Last updated | 2018-12-20 (Latest revision 2012-06-08) | ||
Replaces | draft-asati-fecframe-config-signaling | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Informational | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 6695 (Informational) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Martin Stiemerling | ||
IESG note | |||
Send notices to | (None) |
draft-ietf-fecframe-config-signaling-09
FECFRAME Working Group Rajiv Asati Internet Draft Cisco Systems Intended status: Informational Expires: July 2012 June 8, 2012 Methods to convey FEC Framework Configuration Information draft-ietf-fecframe-config-signaling-09.txt Abstract FEC Framework document [RFC6363] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use signaling protocols such as Session Announcement Protocol (SAP), Session Initiation Protocol (SIP), Real Time Stream 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 Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents Asati Expires July 8, 2012 [Page 1] Internet-Draft FEC Framework Config Signaling June 8, 2012 at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 8, 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...................................................3 2. Specification Language.........................................4 3. Terminology/Abbreviations......................................4 4. FEC Framework Configuration Information........................5 4.1. Encoding Format...........................................6 5. Signaling Protocol Usage.......................................7 5.1. Signaling Protocol for Multicasting.......................8 5.1.1. Sender Procedure.....................................9 5.1.2. Receiver Procedure..................................12 5.2. Signaling Protocol for Unicasting........................13 5.2.1. SIP.................................................13 5.2.2. RTSP................................................14 6. Security Considerations.......................................15 7. IANA Considerations...........................................15 Asati Expires July 8, 2012 [Page 2] Internet-Draft FEC Framework Config Signaling June 8, 2012 8. Acknowledgments...............................................15 9. References....................................................16 9.1. Normative References.....................................16 9.2. Informative References...................................16 Author's Addresses...............................................17 1. Introduction 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 sender and reciever(s). This document describes how various signaling protocols such as Session Announcement Protocol (SAP)[RFC2974], Session Initiation Protocol (SIP)[RFC3261], Real Time Stream Protocol (RTSP)[RFC2326] etc. could be used by the FEC scheme (and/or Content Delivery Protocol (CDP))to communicate the Configuration information between sender and receiver(s). The configuration information may be encoded in any compatible format such as SDP [RFC4566], XML etc., though this document references 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 such that Section 2 describes the terms used in this document, section 4 describes the FEC Framework Configuration Information, section 5 describes how to use signaling protocol for the multicast and unicast applications, and section 6 describes security consideration. Asati Expires July 8, 2012 [Page 3] Internet-Draft FEC Framework Config Signaling June 8, 2012 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 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. Asati Expires July 8, 2012 [Page 4] Internet-Draft FEC Framework Config Signaling June 8, 2012 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 the FEC Framework document [RFC6363] section 6.5, 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. FEC Scheme Specific Information (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 parameter (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 the Operation, Administration and Maintenance (OAM) purposes and optionally convey this error to the application layer. Please refer to the figure 1 of the FEC Framework document [RFC6363] for further illustration. This document does not make any assumption that the 'FEC sender' and 'Media Sender' functionalities are implemented on the same device, Asati Expires July 8, 2012 [Page 5] Internet-Draft FEC Framework Config Signaling June 8, 2012 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 prefered by a particular FEC Framework instance. The selection of such encoding format or syntax is independent of the signaling protocol and beyond the scope of this document. Whatever encoding format is selected for a particular FEC framework instance, it 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 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 'SDP' encoding format as an example encoding format for FEC Framework Configuration Information. Asati Expires July 8, 2012 [Page 6] Internet-Draft FEC Framework Config Signaling June 8, 2012 5. Signaling Protocol Usage FEC Framework [RFC6363] requires certain FEC Framework Configuration Information to be available to both sender and receiver(s). This configuration information is almost always formulated at the sender (or on behalf of a sender), and somehow made available at the receiver(s). While one may envision a static method to populate the configuration information at both 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 misconfiguration possibility. Hence, there is a benefit in using a dynamic method i.e., signaling protocol to convey the configuration information between 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, 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 (described in section 5.1), and the other to deliver the configuration information to one and only one receiver via unicasting (described in section 5.2). Figure 1 below illustrates a sample topology showing the FEC sender and FEC receiver (that may or may not be the Media Sender and Media Receiver respectively) such that FEC_Sender1 is serving FEC_Receiver11,12,13 via the multicast signaling protocol, whereas the 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 Expires July 8, 2012 [Page 7] Internet-Draft FEC Framework Config Signaling June 8, 2012 5.1. Signaling Protocol for Multicasting This specification describes using Session Announcement Protocol (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 being 9875 and source UDP port being any available number, as described in RFC2974. The SAP message(s) MUST contain an authentication header using 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 the 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 the section 5.1.1). This enables the receiver to receive the SAP message(s) and obtains 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. Figure 2 below illustrates the SAP packet format (it is reprinted from the RFC2974) - Asati Expires July 8, 2012 [Page 8] Internet-Draft FEC Framework Config Signaling June 8, 2012 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 the RFC2974 includes explanation 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 was encoded in XML format. Section 5.1.1 describes the sender procedure, whereas the section 5.1.2 describes the receiver procedure in the context of config signaling using RFC2974. 5.1.1. Sender Procedure The sender signals the FEC framework configuration for each FEC framework instance in a periodic SAP announcement message [RFC2974]. The SAP announcement message is sent to a well known multicast IP Asati Expires July 8, 2012 [Page 9] Internet-Draft FEC Framework Config Signaling June 8, 2012 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 SAP message boundary. Hence, this specification recommends single SAP announcement message to be sent in a UDP datagram. The IP packet carrying the SAP message must be sent to 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 SAP message must use destination UDP port being 9875 and source UDP port bein any available number. The default IP 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 DSCP field may be set to any value that indicates a desired QoS treatment in the IP network. The IP packet carrying the SAP message must be sent with 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 the one 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 Asati Expires July 8, 2012 [Page 10] Internet-Draft FEC Framework Config Signaling June 8, 2012 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(s) from the database and doesn't trigger the deletion of 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 suggested default value being 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 simpler method requires the time-interval to be included in the FEC Framework Configuration Information, if the default time interval (=60 seconds) for SAP message repeations is not used. For example, the usage of "r=" (repeat time) field in SDP may convey the time-interval value, if 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 time-out period for the multicast routing entry is 210 seconds, per the PIM specification [RFC4601], though the time-out 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. 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 anymore 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 Asati Expires July 8, 2012 [Page 11] Internet-Draft FEC Framework Config Signaling June 8, 2012 section 5 of RFC2974 [RFC2974]. Such 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 IP destination address of either 224.2.127.254 (if IPv4 global scope session is used for the FEC stream), or 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 RFC2974 [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 time-out value, which is (re)set to five times the time-interval value, which is either the default = 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 "r=" (repeat time) field in SDP to convey the time-interval value, if SDP encoding format is used. The time-out value associated with each entry is reset when the corresponding announcement (please see section 5 of [RFC2974]) is received. If the time-out 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]. The deletion of SAP entry must result in the receiver no longer using the relevant FEC Framework Configuration Information for the corresponding instance, and must no longer subscribe to any related FEC streams. Asati Expires July 8, 2012 [Page 12] Internet-Draft FEC Framework Config Signaling June 8, 2012 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 to the server, paving the way for the content to be unicast on the chosen transport from 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., FEC Framework Configuration Information. This enables the node acting as the offerer to offer 'FEC Framework Configuration Information' for each of available FEC instances, and the node acting as the answerer conveying the chosen FEC Framework instance(s) to the offerer. The usage of FEC framework instance is explained 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 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 Expires July 8, 2012 [Page 13] Internet-Draft FEC Framework Config Signaling June 8, 2012 they would like to share. SIP runs on either TCP or UDP or SCTP transport, and uses SDP as the encoding format to describe multmedia session attributes. SIP already uses an offer/answer model with SDP, described in [RFC3264], to exchange the 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, explained in section 4. Any SDP specific enhancements to accommodate the FEC Framework are covered in the SDP Elements specification [RFC6364]. 5.2.2. RTSP Real-Time Streaming Protocol (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 '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 message, so as to request for FEC protection for the data. The node receiving such request either responds with "200 OK" message that includes offers i.e., available FEC options (e.g. FEC Framework Configuration Information for each Instance) or "551 Option not supported" message. A sample of 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> Asati Expires July 8, 2012 [Page 14] Internet-Draft FEC Framework Config Signaling June 8, 2012 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. Suffice to say, if the requesting node (Node1) received '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 SAP message(s) be authenticated to ensure sender authentication, as described in section 5.1. There is no additional security consideration other than what's already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and [RFC3261] for SIP. 7. IANA Considerations This document requests IANA to register 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 provides the following information in compliance with section 3.8.1 in [RFC2326]: . Name of option-tag = FEC-protection-needed . Description = See section 5.2.2 . Change of 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. This document was prepared using 2-Word-v2.0.template.dot. Asati Expires July 8, 2012 [Page 15] Internet-Draft FEC Framework Config Signaling June 8, 2012 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. [RFC6363] Watson, M., "Forward Error Correction (FEC) Framework", RFC6363, March 2011. [RFC6364] Begen, A., "Session Description Protocol Elements for FEC Framework ", RFC6364, October 2011. [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. 9.2. Informative References [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [RFC3261] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4601] Fenner, etc., "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 4601, August 2006. [RFC3547] Baugher, etc., "The Group Domain of Interpretation", RFC 3547, July 2003. Asati Expires July 8, 2012 [Page 16] Internet-Draft FEC Framework Config Signaling June 8, 2012 Author's Addresses Rajiv Asati Cisco Systems, 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 Email: rajiva@cisco.com Asati Expires July 8, 2012 [Page 17]