idnits 2.17.1 draft-ietf-fecframe-config-signaling-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6363]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 8, 2012) is 4339 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3547' is defined on line 669, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 FECFRAME Working Group Rajiv Asati 2 Internet Draft Cisco Systems 3 Intended status: Informational 4 Expires: July 2012 6 June 8, 2012 8 Methods to convey FEC Framework Configuration Information 9 draft-ietf-fecframe-config-signaling-09.txt 11 Abstract 13 FEC Framework document [RFC6363] defines the FEC Framework 14 Configuration Information necessary for the FEC framework operation. 15 This document describes how to use signaling protocols such as 16 Session Announcement Protocol (SAP), Session Initiation Protocol 17 (SIP), Real Time Stream Protocol (RTSP) etc. for determining and 18 communicating the Configuration information between sender(s) and 19 receiver(s). 21 This document doesn't define any new signaling protocol. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with 26 the provisions of BCP 78 and BCP 79. This document may contain 27 material from IETF Documents or IETF Contributions published or made 28 publicly available before November 10, 2008. The person(s) 29 controlling the copyright in some of this material may not have 30 granted the IETF Trust the right to allow modifications of such 31 material outside the IETF Standards Process. Without obtaining an 32 adequate license from the person(s) controlling the copyright in 33 such materials, this document may not be modified outside the IETF 34 Standards Process, and derivative works of it may not be created 35 outside the IETF Standards Process, except to format it for 36 publication as an RFC or to translate it into languages other than 37 English. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other documents 46 at any time. It is inappropriate to use Internet-Drafts as 47 reference material or to cite them other than as "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 52 The list of Internet-Draft Shadow Directories can be accessed at 53 http://www.ietf.org/shadow.html 55 This Internet-Draft will expire on November 8, 2012. 57 Copyright Notice 59 Copyright (c) 2012 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with 67 respect to this document. Code Components extracted from this 68 document must include Simplified BSD License text as described in 69 Section 4.e of the Trust Legal Provisions and are provided without 70 warranty as described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction...................................................3 75 2. Specification Language.........................................4 76 3. Terminology/Abbreviations......................................4 77 4. FEC Framework Configuration Information........................5 78 4.1. Encoding Format...........................................6 79 5. Signaling Protocol Usage.......................................7 80 5.1. Signaling Protocol for Multicasting.......................8 81 5.1.1. Sender Procedure.....................................9 82 5.1.2. Receiver Procedure..................................12 83 5.2. Signaling Protocol for Unicasting........................13 84 5.2.1. SIP.................................................13 85 5.2.2. RTSP................................................14 86 6. Security Considerations.......................................15 87 7. IANA Considerations...........................................15 88 8. Acknowledgments...............................................15 89 9. References....................................................16 90 9.1. Normative References.....................................16 91 9.2. Informative References...................................16 92 Author's Addresses...............................................17 94 1. Introduction 96 FEC Framework document [RFC6363] defines the FEC Framework 97 Configuration Information that governs the overall FEC framework 98 operation common to any FEC scheme. This information must be 99 available at both sender and reciever(s). 101 This document describes how various signaling protocols such as 102 Session Announcement Protocol (SAP)[RFC2974], Session Initiation 103 Protocol (SIP)[RFC3261], Real Time Stream Protocol (RTSP)[RFC2326] 104 etc. could be used by the FEC scheme (and/or Content Delivery 105 Protocol (CDP))to communicate the Configuration information between 106 sender and receiver(s). The configuration information may be encoded 107 in any compatible format such as SDP [RFC4566], XML etc., though 108 this document references to SDP encoding usage quite extensively. 110 Note that this document doesn't define any new signaling protocol; 111 rather it just provides examples of how existing protocols should 112 be used. Also, the list of signaling protocols for unicast is not 113 intended to be a complete list. 115 This document doesn't describe any FEC scheme specific information 116 (FSSI) (for example, how source blocks are constructed) or any 117 sender or receiver side operation for a particular FEC scheme (for 118 example, whether the receiver makes use of one or more repair flows 119 that are received). Such FEC scheme specifics should be covered in 120 separate document(s). This document doesn't mandate a particular 121 encoding format for the configuration information either. 123 This document is structured such that Section 2 describes the terms 124 used in this document, section 4 describes the FEC Framework 125 Configuration Information, section 5 describes how to use signaling 126 protocol for the multicast and unicast applications, and section 6 127 describes security consideration. 129 2. Specification Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Terminology/Abbreviations 137 This document makes use of the terms/abbreviations defined in the 138 FEC Framework document [RFC6363] and defines the following 139 additional terms: 141 o Media Sender - Node providing original media flow(s) to the 142 'FEC Sender' 144 o Media Receiver - Node performing the Media decoding; 146 o FEC Sender - Node performing the FEC encoding on the 147 original media flow(s) to produce the FEC repair flow(s) 149 o FEC Receiver - Node performing the FEC decoding, as needed, 150 and providing the original media flow(s) to the Media receiver. 152 o Sender - Same as FEC Sender 154 o Receiver - Same as FEC Receiver 156 o (Media) Flow - A single media instance i.e., an audio stream 157 or a video stream. 159 This document deliberately refers to the 'FEC Sender' and 'FEC 160 Receiver' as the 'Sender' and 'Receiver' respectively. 162 4. FEC Framework Configuration Information 164 The FEC Framework [RFC6363] defines a minimum set of information 165 that is communicated between the sender and receiver(s) for a proper 166 operation of an FEC scheme. This information is referred to as "FEC 167 Framework Configuration Information". This is the information that 168 the FEC Framework needs in order to apply FEC protection to the 169 transport flows. 171 A single instance of the FEC Framework provides FEC protection for 172 all packets of a specified set of source packet flows, by means of 173 one or more packet flows consisting of repair packets. As per the 174 FEC Framework document [RFC6363] section 6.5, the FEC Framework 175 Configuration Information includes the following for each FEC 176 Framework instance: 178 1. Identification of the repair flow(s) 180 2. Identification of Source Flow(s) 182 3. Identification of FEC Scheme 184 4. Length of Explicit Source FEC payload ID 186 5. FEC Scheme Specific Information (FSSI) 188 FSSI basically provides an opaque container to encode FEC scheme 189 specific configuration information such as buffer size, decoding 190 wait-time etc. Please refer to the FEC Framework document [RFC6363] 191 for more details. 193 The usage of signaling protocols described in this document requires 194 that the application layer responsible for the FEC Framework 195 instance provide the value for each of the configuration information 196 parameter (listed above) encoded as per the chosen encoding format. 197 In case of failure to receive the complete information, the 198 signaling protocol module must return an error for the Operation, 199 Administration and Maintenance (OAM) purposes and optionally convey 200 this error to the application layer. Please refer to the figure 1 of 201 the FEC Framework document [RFC6363] for further illustration. 203 This document does not make any assumption that the 'FEC sender' and 204 'Media Sender' functionalities are implemented on the same device, 205 though that may be the case. Similarly, this document does not make 206 any assumption that 'FEC receiver' and 'Media Receiver' 207 functionalities are implemented on the same device, though that may 208 be the case. There may also be more than one Media Sender. 210 4.1. Encoding Format 212 The FEC Framework Configuration Information (listed above in section 213 4) may be encoded in any format such as SDP, XML etc. as chosen or 214 prefered by a particular FEC Framework instance. The selection of 215 such encoding format or syntax is independent of the signaling 216 protocol and beyond the scope of this document. 218 Whatever encoding format is selected for a particular FEC framework 219 instance, it must be known to the signaling protocol. This is to 220 provide a means (e.g. a field such as Payload Type) in the signaling 221 protocol message(s) to convey the chosen encoding format for the 222 configuration information so that the Payload i.e., configuration 223 information can be correctly parsed as per the semantics of the 224 chosen encoding format at the receiver. Please note that the 225 encoding format is not a negotiated parameter, but rather a property 226 of a particular FEC Framework instance and/or its implementation. 228 Additionally, the encoding format for each FEC Framework 229 configuration parameter must be defined in terms of a sequence of 230 octets that can be embedded within the payload of the signaling 231 protocol message(s). The length of the encoding format must either 232 be fixed, or derived by examining the encoded octets themselves. 233 For example, the initial octets may include some kind of length 234 indication. 236 Independent of the encoding formats supported by an FEC scheme, each 237 instance of the FEC Framework must use a single encoding format to 238 describe all of the configuration information associated with that 239 instance. The signaling protocol specified in this document should 240 not validate the encoded information, though it may validate the 241 syntax or length of the encoded information. 243 The reader may refer to the SDP elements document [RFC6364], which 244 describes the usage of 'SDP' encoding format as an example encoding 245 format for FEC Framework Configuration Information. 247 5. Signaling Protocol Usage 249 FEC Framework [RFC6363] requires certain FEC Framework Configuration 250 Information to be available to both sender and receiver(s). This 251 configuration information is almost always formulated at the sender 252 (or on behalf of a sender), and somehow made available at the 253 receiver(s). While one may envision a static method to populate the 254 configuration information at both sender and receiver(s), it would 255 not be optimal since it would (a) require the knowledge of every 256 receiver in advance, (b) require the time and means to configure 257 each receiver and sender, and (c) increase the misconfiguration 258 possibility. Hence, there is a benefit in using a dynamic method 259 i.e., signaling protocol to convey the configuration information 260 between sender and one or more receivers. 262 Since the configuration information may be needed at a particular 263 receiver versus many receivers (depending on the multimedia stream 264 being unicast e.g. Video on Demand, or multicast e.g. Broadcast or 265 IPTV), we need two types of signaling protocols - one to deliver the 266 configuration information to many receivers via multicasting 267 (described in section 5.1), and the other to deliver the 268 configuration information to one and only one receiver via 269 unicasting (described in section 5.2). 271 Figure 1 below illustrates a sample topology showing the FEC sender 272 and FEC receiver (that may or may not be the Media Sender and Media 273 Receiver respectively) such that FEC_Sender1 is serving 274 FEC_Receiver11,12,13 via the multicast signaling protocol, whereas 275 the FEC_Sender2 is serving only FEC_Receiver2 via the unicast 276 signaling protocol. 278 FEC_Sender2---------| |--------FEC_Receiver2 279 | | 280 FEC_Sender1-------IP/MPLS network 281 |-----------FEC_Receiver11 282 |-----------FEC_Receiver12 283 |-----------FEC_Receiver13 285 Figure 1 Topology using Sender and Receiver 287 The rest of the document continues to use the terms 'Sender' and 288 'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver' 289 respectively. 291 5.1. Signaling Protocol for Multicasting 293 This specification describes using Session Announcement Protocol 294 (SAP) version 2 [RFC2974] as the signaling protocol to multicast the 295 configuration information from one sender to many receivers. The 296 apparent advantage is that the server doesn't need to maintain any 297 state for any receiver using SAP. 299 SAP messages are carried over UDP over IP with destination UDP 300 port being 9875 and source UDP port being any available number, 301 as described in RFC2974. The SAP message(s) MUST contain an 302 authentication header using PGP authentication. 304 At the high level, a sender, acting as the SAP announcer, signals 305 the FEC Framework Configuration Information for each FEC Framework 306 instance available at the sender, using the SAP message(s). The 307 configuration information, encoded in a suitable format as per the 308 section 4.1, is carried in the Payload of the SAP message(s). A 309 receiver, acting as the SAP listener, listens on a well-known UDP 310 port and at least one well known multicast group IP address (as 311 explained in the section 5.1.1). This enables the receiver to 312 receive the SAP message(s) and obtains the FEC Framework 313 Configuration Information for each FEC Framework Instance. 315 Using the configuration information, the receiver becomes aware of 316 available FEC protection options, corresponding multicast trees (S,G 317 or *,G addresses) etc. The receiver may subsequently subscribe to 318 one or more multicast trees to receive the FEC streams using out-of- 319 band multicasting techniques such as PIM [RFC4601]. This, however, 320 is outside the scope of this document. 322 Figure 2 below illustrates the SAP packet format (it is reprinted 323 from the RFC2974) - 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | V=1 |A|R|T|E|C| auth len | msg id hash | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 : originating source (32 or 128 bits) : 331 : : 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | optional authentication data | 334 : .... : 335 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 336 | optional payload type | 337 + +-+- - - - - - - - - -+ 338 | |0| | 339 + - - - - - - - - - - - - - - - - - - - - +-+ | 340 | | 341 : payload : 342 | | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 2 SAP Message format 347 While the RFC2974 includes explanation for each field, it is worth 348 discussing the 'Payload' and 'Payload Type' fields. The 'Payload' 349 field is used to carry the FEC Framework Configuration Information. 350 Subsequently, the optional 'Payload Type' field, which is a MIME 351 content type specifier, is used to describe the encoding format used 352 to encode the Payload. 354 For example, the 'Payload Type' field may be application/sdp if 355 the FEC Framework Configuration Information is encoded in SDP 356 format and carried in the SAP payload. Similarly, it would be 357 application/xml if the FEC Framework Configuration Information was 358 encoded in XML format. 360 Section 5.1.1 describes the sender procedure, whereas the section 361 5.1.2 describes the receiver procedure in the context of config 362 signaling using RFC2974. 364 5.1.1. Sender Procedure 366 The sender signals the FEC framework configuration for each FEC 367 framework instance in a periodic SAP announcement message [RFC2974]. 368 The SAP announcement message is sent to a well known multicast IP 369 address and UDP port, as specified in [RFC2974]. The announcement is 370 multicast with the same scope as the session being announced. 372 The SAP module at the sender obtains the FEC Framework Configuration 373 Information per Instance from the 'FEC Framework' module and places 374 that in the SAP payload accordingly. A single SAP (announcement) 375 message must carry the FEC Framework Configuration Information for a 376 single FEC Framework Instance. The SAP message is then sent over UDP 377 over IP. 379 While it is possible to aggregate multiple SAP (announcement) 380 messages in a single UDP datagram as long as the resulting UDP 381 datagram length is less than the IP MTU of the outgoing interface, 382 this specification does not recommend it since there is no length 383 field in the SAP header to identify SAP message boundary. Hence, 384 this specification recommends single SAP announcement message to 385 be sent in a UDP datagram. 387 The IP packet carrying the SAP message must be sent to destination 388 IP address of one of the following depending on the selected scope: 390 - 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255 391 is selected for the FEC stream), or 393 - FF0X:0:0:0:0:0:2:7FFE (if IPv6 multicasting is selected for the 394 FEC stream, where X is the 4-bit scope value), or 396 - the highest multicast address (239.255.255.255, for example) in 397 the relevant administrative scope zone (if IPv4 administrative 398 scope 239.0.0.0-239.255.255.255 is selected for the FEC stream) 400 As defined in RFC2974, the IP packet carrying SAP message must use 401 destination UDP port being 9875 and source UDP port bein any 402 available number. The default IP TTL value (or Hop Limit value) 403 should be 255 at the sender, though the sender implementation may 404 allow it to be any other value to implicitly create the multicast 405 boundary for SAP announcements. The IP DSCP field may be set to any 406 value that indicates a desired QoS treatment in the IP network. 408 The IP packet carrying the SAP message must be sent with source IP 409 address that is reachable by the receiver. The sender may assign the 410 same IP address in the "originating source" field of the SAP 411 message, as the one used in the source IP address of the IP packet. 413 Furthermore, the FEC Framework Configuration Information must not 414 include any of the reserved multicast group IP addresses for the FEC 415 streams (i.e., source or repair flows), though it may use the same 416 IP address as the 'originating source' address to identify the FEC 417 streams (i.e., source or repair flows). Please refer to IANA 418 assignments for multicast addresses. 420 The sender must periodically send the 'SAP announcement' message to 421 ensure that the receiver doesn't purge the cached entry(s) from the 422 database and doesn't trigger the deletion of FEC Framework 423 Configuration Information. 425 While the time interval between repetitions of an announcement can 426 be calculated as per the very sophisticated but complex method 427 explained in [RFC2974], this document recommends a simpler method in 428 which the user specifies the time interval in the range of 1-200 429 seconds with suggested default value being 60 seconds. In this 430 method, the 'time interval' may be signaled in the SAP message 431 payload e.g. within the FEC Framework Configuration Information. 433 Note that SAP doesn't allow the time-interval to be signaled in 434 the SAP header. Hence, the usage of simpler method requires the 435 time-interval to be included in the FEC Framework Configuration 436 Information, if the default time interval (=60 seconds) for SAP 437 message repeations is not used. For example, the usage of "r=" 438 (repeat time) field in SDP may convey the time-interval value, if 439 SDP encoding format is used. 441 The time interval must be chosen to ensure that SAP announcement 442 messages are sent out before the corresponding multicast routing 443 entry e.g. (S,G) or (*,G) (corresponding to the SAP multicast 444 tree(s)) on the router(s) times out. (It is worth noting that the 445 default time-out period for the multicast routing entry is 210 446 seconds, per the PIM specification [RFC4601], though the time-out 447 period may be set to another value as allowed by the router 448 implementation.) 450 A SAP implementation may also support the complex method for 451 determining the SAP announcement time interval, and provide the 452 option to select it. 454 The sender may choose to delete the announced FEC Framework 455 Configuration Information, as defined in section 4 of RFC2974. The 456 explicit deletion is useful if the sender no longer desires to send 457 anymore FEC streams. 459 If the sender needs to modify the announced FEC Framework 460 Configuration Information for one or more FEC instances, then the 461 sender must send a new announcement message with a different 462 'Message Identifier Hash' value as per the rules described in 463 section 5 of RFC2974 [RFC2974]. Such announcement message should be 464 sent immediately (without having to wait for the time-interval) to 465 ensure that the modifications are received by the receiver as soon 466 as possible. The sender must also send the SAP deletion message to 467 delete the previous SAP announcement message (i.e., with the 468 previous 'Message Identifier Hash' value). 470 5.1.2. Receiver Procedure 472 The receiver must listen on UDP port 9875 for packets arriving with 473 IP destination address of either 224.2.127.254 (if IPv4 global scope 474 session is used for the FEC stream), or FF0X:0:0:0:0:0:2:7FFE (if 475 IPv6 is selected, where X is the 4-bit scope value), or the highest 476 IP address (239.255.255.255, for example) in the relevant 477 administrative scope zone (if IPv4 administrative scope 239.0.0.0- 478 239.255.255.255 is selected for the FEC stream). These IP addresses 479 are mandated for SAP usage by RFC2974 [RFC2974]. 481 The receiver, upon receiving a SAP announcement message, creates an 482 entry, if it doesn't already exist, in a local database and passes 483 the FEC Framework Configuration Information from the SAP Payload 484 field to the 'FEC Framework' module. Each entry also maintains a 485 time-out value, which is (re)set to five times the time-interval 486 value, which is either the default = 60 seconds, or the value 487 signaled by the sender. 489 Note that SAP doesn't allow the time-interval to be signaled in 490 the SAP header. Hence, the time-interval should be included in the 491 FEC Framework Configuration Information. For example, the usage of 492 "r=" (repeat time) field in SDP to convey the time-interval value, 493 if SDP encoding format is used. 495 The time-out value associated with each entry is reset when the 496 corresponding announcement (please see section 5 of [RFC2974]) is 497 received. If the time-out value for any entry reaches zero, then 498 that entry must be deleted from the database, as described in 499 section 4 of [RFC2974]. The receiver, upon receiving a SAP delete 500 message, must delete the matching SAP entry in its database, as 501 described in section 4 of [RFC2974]. 503 The deletion of SAP entry must result in the receiver no longer 504 using the relevant FEC Framework Configuration Information for the 505 corresponding instance, and must no longer subscribe to any related 506 FEC streams. 508 5.2. Signaling Protocol for Unicasting 510 This document describes leveraging any signaling protocol that is 511 already used by the unicast application, for exchanging the FEC 512 Framework Configuration Information between two nodes. 514 For example, a multimedia (VoD) client may send a request via 515 unicasting for a particular content to the multimedia (VoD) server, 516 which may offer various options such as encodings, bitrates, 517 transport etc. for the content. The client selects the suitable 518 options and answers to the server, paving the way for the content to 519 be unicast on the chosen transport from server to the client. This 520 offer/answer signaling, described in [RFC3264], is commonly utilized 521 by many application protocols such as SIP, RTSP etc. 523 The fact that two nodes desiring unicast communication almost always 524 rely on an application to first exchange the application related 525 parameters via the signaling protocol makes it logical to enhance 526 such signaling protocol(s) to (a) convey the desire for the FEC 527 protection and (b) subsequently also exchange FEC parameters i.e., 528 FEC Framework Configuration Information. This enables the node 529 acting as the offerer to offer 'FEC Framework Configuration 530 Information' for each of available FEC instances, and the node 531 acting as the answerer conveying the chosen FEC Framework 532 instance(s) to the offerer. The usage of FEC framework instance is 533 explained the FEC Framework document [RFC6363]. 535 While enhancing an application's signaling protocol to exchange FEC 536 parameters is one method (briefly explained above), an alternative 537 method would be to have a unicast based generic protocol that could 538 be used by two nodes independent of the application's signaling 539 protocol. The latter is not covered by this document, of course. 541 The remainder of this section provides example signaling protocols 542 and explains how they can be used to exchange FEC Framework 543 Configuration Information. 545 5.2.1. SIP 547 SIP [RFC3261] is an application-level signaling protocol to create, 548 modify, and terminate multimedia sessions with one or more 549 participants. SIP also enables the participants to discover one 550 another and to agree on a characterization of a multimedia session 551 they would like to share. SIP runs on either TCP or UDP or SCTP 552 transport, and uses SDP as the encoding format to describe multmedia 553 session attributes. 555 SIP already uses an offer/answer model with SDP, described in 556 [RFC3264], to exchange the information between two nodes to 557 establish unicast sessions between them. This document extends the 558 usage of this model for exchanging the FEC Framework Configuration 559 Information, explained in section 4. Any SDP specific enhancements 560 to accommodate the FEC Framework are covered in the SDP Elements 561 specification [RFC6364]. 563 5.2.2. RTSP 565 Real-Time Streaming Protocol (RTSP) [RFC2326] is an application- 566 level signaling protocol for control over the delivery of data with 567 real-time properties. RTSP provides an extensible framework to 568 enable controlled, on-demand delivery of real-time data, such as 569 audio and video. RTSP runs on either TCP or UDP transports. 571 RTSP already provides an ability to extend the existing method with 572 new parameters. This specification defines 'FEC Protection Needed' 573 option-tag (please see section 7 for IANA Considerations) and 574 prescribes including it in the Require (or Proxy-Require) header of 575 SETUP (method) request message, so as to request for FEC protection 576 for the data. 578 The node receiving such request either responds with "200 OK" 579 message that includes offers i.e., available FEC options (e.g. FEC 580 Framework Configuration Information for each Instance) or "551 581 Option not supported" message. A sample of related message exchange 582 is shown below - 584 Node1->Node2: SETUP < ... > RTSP/1.0 585 CSeq: 1 586 Transport: 587 Require: FEC-protection-needed 589 Node2->Node1: RTSP/1.0 200 OK 590 CSeq: 1 591 Transport: 593 The requesting node (Node1) may then send a new SETUP message to 594 convey the selected FEC protection to Node2, and proceed with 595 regular RTSP messaging. 597 Suffice to say, if the requesting node (Node1) received '551 Option 598 not supported' response from Node2, then the requesting node (Node1) 599 may send the SETUP message without using the Require header. 601 6. Security Considerations 603 This document recommends SAP message(s) be authenticated to ensure 604 sender authentication, as described in section 5.1. 606 There is no additional security consideration other than what's 607 already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and 608 [RFC3261] for SIP. 610 7. IANA Considerations 612 This document requests IANA to register a new RTSP Option tag 613 (option-tag) listed below in the RTSP/1.0 Option Tags table of the 614 "Real Time Streaming Protocol (RTSP)/1.0 Parameters" registry 615 available from http://www.iana.org/, and provides the following 616 information in compliance with section 3.8.1 in [RFC2326]: 618 . Name of option-tag = FEC-protection-needed 620 . Description = See section 5.2.2 622 . Change of Control = IETF 624 8. Acknowledgments 626 Thanks to Colin Perkins for pointing out the issue with the time- 627 interval for the SAP messages. Additionally, thanks to Vincent Roca, 628 Ali Begen, Mark Watson, Ulas Kozat and David Harrington for greatly 629 improving this document. 631 This document was prepared using 2-Word-v2.0.template.dot. 633 9. References 635 9.1. Normative References 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, March 1997. 640 [RFC6363] Watson, M., "Forward Error Correction (FEC) Framework", 641 RFC6363, March 2011. 643 [RFC6364] Begen, A., "Session Description Protocol Elements for 644 FEC Framework ", RFC6364, October 2011. 646 [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session 647 Announcement Protocol", RFC 2974, October 2000. 649 9.2. Informative References 651 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 652 Description Protocol", RFC 4566, July 2006. 654 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 655 with Session Description Protocol (SDP)", RFC 3264, June 656 2002. 658 [RFC2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time 659 Streaming Protocol (RTSP)", RFC 2326, April 1998. 661 [RFC3261] Handley, M., Schulzrinne, H., Schooler, E. and J. 662 Rosenberg, "SIP: Session Initiation Protocol", RFC 3261, 663 June 2002. 665 [RFC4601] Fenner, etc., "Protocol Independent Multicast - Sparse 666 Mode (PIM-SM): Protocol Specification", RFC 4601, August 667 2006. 669 [RFC3547] Baugher, etc., "The Group Domain of Interpretation", RFC 670 3547, July 2003. 672 Author's Addresses 674 Rajiv Asati 675 Cisco Systems, 676 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 677 Email: rajiva@cisco.com