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