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