idnits 2.17.1 draft-ietf-fecframe-config-signaling-02.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 e.g. encode 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 (February 24, 2010) is 5168 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) == Unused Reference: 'RFC2119' is defined on line 600, but no explicit reference was found in the text == 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 (~~), 9 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 February 24, 2010 8 Methods to convey FEC Framework Configuration Information 9 draft-ietf-fecframe-config-signaling-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 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 months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 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 24, 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 respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 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. Terminology/Abbreviations......................................3 61 3. FEC Framework Configuration Information........................4 62 3.1. Encoding Format...........................................5 63 4. Signaling Protocol Usage.......................................6 64 4.1. Signaling Protocol for Multicasting.......................7 65 4.1.1. Sender Procedure.....................................9 66 4.1.2. Receiver Procedure..................................11 67 4.2. Signaling Protocol for Unicasting........................12 68 4.2.1. SIP.................................................13 69 4.2.2. RSTP................................................13 70 5. Security Considerations.......................................14 71 6. IANA Considerations...........................................14 72 7. Acknowledgments...............................................14 73 8. References....................................................16 74 8.1. Normative References.....................................16 75 8.2. Informative References...................................16 76 Author's Addresses...............................................17 78 1. Introduction 80 FEC Framework document [FECARCH] defines the FEC Framework 81 Configuration Information that governs the overall FEC framework 82 operation common to any FEC scheme. This information MUST be 83 available at both sender and reciever(s). 85 This document describes how to use various signaling protocols to 86 communicate the Configuration information between sender and 87 receiver(s). The configuration information may be encoded in any 88 compatible format such as SDP [RFC4566], XML etc. A signaling 89 protocol could be utilised by any FEC scheme and/or any Content 90 Delivery Protocol (CDP). 92 This document doesn't describe any FEC scheme specific information 93 (FSSI) (for example, how source blocks are constructed) or any sender 94 or receiver side operation for a particular FEC scheme (for example, 95 whether the receiver makes use of one or more repair flows that are 96 received). Such FEC scheme specifics SHOULD be covered in separate 97 document(s). This document doesn't mandate a particular encoding 98 format for the configuration information either. 100 This document is structured such that Section 2 describes the terms 101 used in this document, section 3 describes the FEC Framework 102 Configuration Information, section 4 describes how to use signaling 103 protocol for the multicast applications, section 5 describes the 104 signaling protocol for the unicast applications, and section 6 105 describes security consideration. 107 2. Terminology/Abbreviations 109 This document makes use of the terms/abbreviations defined in the FEC 110 Framework document [FECARCH]. Additionally, it defines the following: 112 o Media Sender - Node performing the Media encoding and producing 113 the original media flow(s) to the 'FEC Sender' 115 o Media Receiver - Node performing the Media decoding; 117 o FEC Sender - Node performing the FEC encoding on the original 118 stream to produce the FEC stream(s) 120 o FEC Receiver - Node performing the FEC decoding, as needed, and 121 providing the original media flow(s) to the Media receiver. 123 o Sender - Same as FEC Sender 125 o Receiver - Same as FEC Receiver 127 o (Media) Stream - A single media instance i.e., an audio stream or 128 a video stream. 130 This document deliberately refers to the 'FEC Sender' and 'FEC 131 Receiver' as the 'Sender' and 'Receiver' respectively. 133 3. FEC Framework Configuration Information 135 The FEC Framework [FECARCH] defines a minimum set of information that 136 MUST be communicated between the sender and receiver(s) for a proper 137 operation of an FEC scheme. This information is referred to as "FEC 138 Framework Configuration Information". This is the information that 139 the FEC Framework needs in order to apply FEC protection to the 140 transport flows. 142 A single instance of the FEC Framework provides FEC protection for 143 all packets of a specified set of source packet flows, by means of 144 one or more packet flows consisting of repair packets. As per the FEC 145 Framework document [FECARCH] section 6.5, the FEC Framework 146 Configuration Information includes the following for each FEC 147 Framework instance: 149 1. Identification of Source Flow(s) 151 2. Identification of the repair flow(s) 153 3. Identification of FEC Scheme 155 4. Length of Source FEC payload ID 157 5. FEC Scheme Specific Information (FSSI) 159 FSSI basically provides an opaque container to encode FEC scheme 160 specific configuration information such as buffer size, decoding 161 wait-time etc. Please refer to the FEC Framework document [FECARCH] 162 for more details. 164 The usage of signaling protocols described in this document requires 165 that the application layer responsible for the FEC Framework instance 166 provide the value for each of the configuration information parameter 167 (listed above) encoded as per the chosen encoding format. Failure to 168 receive the complete information, the signaling protocol module MUST 169 return an error for the Operation, Administration and Maintenance 170 (OAM) purposes and optionally convey to the application layer. Please 171 refer to the figure 1 of the FEC Framework document [FECARCH] for 172 further illustration. 174 This document does not make any assumption that the 'FEC sender' and 175 'Media Source/Sender' functionalities are implemented on the same 176 device, though that may be the case. Similarly, this document does 177 not make any assumption that 'FEC receiver' and 'Media Receiver' 178 functionalities are implemented on the same device, though that may 179 be the case. 181 3.1. Encoding Format 183 The FEC Framework Configuration Information (listed above in section 184 3) may be encoded in any format such as SDP, XML etc. as chosen or 185 prefered by a particular FEC Framework instance. The selection of 186 such encoding format or syntax is independent of the signaling 187 protocol and beyond the scope of this document. 189 Whatever encoding format is selected for a particular FEC framework 190 instance, it MUST be known to the signaling protocol. This is to 191 provide a means (e.g. a field such as Payload Type) in the signaling 192 protocol message(s) to convey the chosen encoding format for the 193 configuration information so that the Payload i.e., configuration 194 information can be correctly parsed as per the semantics of the 195 chosen encoding format at the receiver. Please note that the encoding 196 format is not a negotiated parameter, but rather a property of a 197 particular FEC Framework instance and/or its implementation. 199 Additionally, the encoding format for each FEC Framework 200 configuration parameter MUST be defined in terms of a sequence of 201 octets that can be embedded within the payload of the signaling 202 protocol message(s). The length of the encoding format MUST either 203 be fixed, or derived by examining the encoded octets themselves. For 204 example, the initial octets may include some kind of length 205 indication. 207 Independent of what all encoding formats supported by an FEC scheme, 208 each instance of the FEC Framework MUST use a single encoding format 209 to describe e.g. encode all of the configuration information 210 associated with that instance. The signaling protocol specified in 211 this document SHOULD not validate the encoded information, though it 212 may validate the syntax or length of the encoded information. 214 The reader may refer to the SDP elements document [FECSDP], which 215 describes the usage of 'SDP' encoding format as an example encoding 216 format for FEC Framework Configuration Information. 218 4. Signaling Protocol Usage 220 FEC Framework [FECARCH] requires certain FEC Framework Configuration 221 Information to be available to both sender and receiver(s). This 222 configuration information is almost always formulated at the sender 223 (or on behalf of a sender), and somehow made available at the 224 receiver(s). While one may envision a static method to populate the 225 configuration information at both sender and receiver(s), it would 226 not be optimal since it would (i) require the knowledge of every 227 receiver in advance, (b) require the time and means to configure each 228 receiver and sender, and (c) increase the misconfiguration 229 possibility. Hence, there is a benefit in using a dynamic method 230 i.e., signaling protocol to convey the configuration information 231 between sender and one or more receivers. 233 Since the configuration information may be needed at a particular 234 receiver versus many receivers (depending on the multimedia stream 235 being unicast e.g. Video on Demand, or multicast e.g. Broadcast or 236 IPTV), we need two types of signaling protocols - one to deliver the 237 configuration information to many receivers via multicasting 238 (described in section 4.1), and the other to deliver the 239 configuration information to one and only one receiver via unicasting 240 (described in section 4.2). 242 Figure 1 below illustrates a sample topology showing the FEC sender 243 and FEC receiver (that may or may not be the Media Sender and Media 244 Receiver respectively) such that FEC_Sender1 is serving 245 FEC_Reciver11,12,13 via the multicast signaling protocol, whereas the 246 FEC_Sender2 is serving only FEC_Reciever2 via the unicast signaling 247 protocol. 249 FEC_Sender2---------| |--------FEC_Receiver2 250 | | 251 FEC_Sender1-----IP/MPLS network 252 |-----------FEC_Receiver11 253 |-----------FEC_Receiver12 254 |-----------FEC_Receiver13 256 Figure 1 Topology using Sender and Receiver 258 The rest of the section continues to use the terms 'Sender' and 259 'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver' 260 respectively. 262 4.1. Signaling Protocol for Multicasting 264 This specification describes using Session Announcement Protocol 265 (SAP) version 2 [RFC2974] as the signaling protocol to multicast the 266 configuration information from one sender to many receivers. The 267 apparent advantage is that the server doesn't need to maintain any 268 state for any receiver using SAP. 270 At the high level, a sender, acting as the SAP announcer, signals the 271 FEC Framework Configuration Information for each FEC Framework 272 instance available at the sender, using the SAP message(s). The 273 configuration information, encoded in a suitable format as per the 274 section 3.1, is carried in the Payload of the SAP message(s). A 275 receiver, acting as the SAP listener, listens on a well known UDP 276 port and at least one well known multicast group IP address (as 277 explained in the section 4.1.1). This enables the receiver to receive 278 the SAP message(s) and obtains the FEC Framework Configuration 279 Information for each FEC Framework Instance. 281 One may refer to 'Requirements for IP Multicast Session Announcement 282 in the Internet' document [SAP-REQ] to know about the SAP 283 limitations. 285 Using the configuration information, the receiver becomes aware of 286 available FEC protection options, corresponding multicast trees (S,G 287 or *,G addresses) etc. The receiver may subsequently subscribe to one 288 or more multicast trees to receive the FEC streams using out-of-band 289 multicasting techniques such as PIM [RFC4601]. This, however, is 290 outside the scope of this document. 292 SAP message is carried over UDP over IP. The destination UDP port 293 MUST be 9875 and source UDP port may be any available number. The SAP 294 message(s) SHOULD contain an authentication header and MAY employ 295 cryptography. One cryptography method suggested by this specification 296 is the usage of Group Cryptography as specified in GDOI [RFC3547]. 298 Figure 2 below illustrates the SAP packet format (it is reprinted 299 from the RFC2974) - 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | V=1 |A|R|T|E|C| auth len | msg id hash | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 : originating source (32 or 128 bits) : 308 : : 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | optional authentication data | 311 : .... : 312 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 313 | optional payload type | 314 + +-+- - - - - - - - - -+ 315 | |0| | 316 + - - - - - - - - - - - - - - - - - - - - +-+ | 317 | | 318 : payload : 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 2 SAP Message format 324 While the RFC2974 includes explanation for each field, it is worth 325 discussing the 'Payload' and 'Payload Type' fields. The 'Payload' 326 field MUST be used to carry the FEC Framework Configuration 327 Information. Subsequently, the optional 'Payload Type' field, which 328 is a MIME content type specifier, MUST describe the encoding format 329 used to encode the Payload. For example, the 'Payload Type' field may 330 be application/sdp if the FEC Framework Configuration Information is 331 encoded in SDP format and carried in the SAP payload. Similarly, it 332 would be application/xml if the FEC Framework Configuration 333 Information was encoded in XML format. 335 4.1.1. Sender Procedure 337 The sender signals the FEC framework configuration for each FEC 338 framework instance in a periodic SAP announcement message [RFC2974]. 339 The SAP announcement message is sent to a well known multicast IP 340 address and UDP port, as specified in [RFC2974]. The announcement is 341 multicast with the same scope as the session being announced. 343 The SAP module at the sender obtains the FEC Framework Configuration 344 Information per Instance from the 'FEC Framework' module and places 345 that in the SAP payload accordingly. A single SAP (announcement) 346 message MUST carry the FEC Framework Configuration Information for a 347 single FEC Framework Instance. The SAP message is then sent over UDP 348 over IP. 350 While it is possible to aggregate multiple SAP (announcement) 351 messages in a single UDP datagram as long as the resulting UDP 352 datagram length is less than the IP MTU of the outgoing interface, 353 this specification does not recommend it since there is no length 354 field in the SAP header to identify SAP message boundary. Hence, 355 this specification recommends single SAP announcement message to be 356 sent in a UDP datagram. 358 The IP packet carrying the SAP message MUST be sent to destination IP 359 address of one of the following depending on the selected scope: 361 - 224.2.127.254 (if IPv4 global scope 224.0.1.0-238.255.255.255 362 is selected for the FEC stream), or 364 - FF0X:0:0:0:0:0:2:7FFE (if IPv6 multicasting is selected for the 365 FEC stream, where X is the 4-bit scope value), or 367 - the highest multicast address (239.255.255.255, for example) in 368 the relevant administrative scope zone (if IPv4 administrative 369 scope 239.0.0.0-239.255.255.255 is selected for the FEC stream) 371 The destination UDP port MUST be 9875 and source UDP port may be any 372 available number. The default IP TTL value (or Hop Limit value) 373 SHOULD be 255, though the implementation may allow it to be any other 374 value to implicitly create the multicast boundary for SAP 375 announcements. The IP DSCP field may be set to any value that 376 indicates a desired QoS treatment in the IP network. 378 The IP packet carrying the SAP message MUST be sent with source IP 379 address that is reachable by the receiver. The sender may assign the 380 same IP address in the "originating source" field of the SAP message, 381 as the one used in the source IP address of the IP packet. 383 Furthermore, the FEC Framework Configuration Information MUST NOT 384 include any of the reserved multicast group IP addresses for the FEC 385 streams (i.e., source or repair flows), though it may use the same IP 386 address as the 'originating source' address to identify the FEC 387 streams (i.e., source or repair flows). Please refer to IANA 388 assignments for multicast addresses. 390 The sender MUST periodically send the 'SAP announcement' message to 391 ensure that the receiver doesn't purge the cached entry(s) from the 392 database and doesn't trigger the deletion of FEC Framework 393 Configuration Information. 395 Please note that the deletion of FEC Framework Configuration 396 Information SHOULD not mean that the receiver stops its FEC 397 processing for the instance for which it had already got the 398 configuration information. 400 While the time interval between repetitions of an announcement can be 401 calculated as per the very sophisticated but complex method explained 402 in [RFC2974], the preferred and simpler method recommended by this 403 specification is to let the user specify the time interval from the 404 range of 1-200 seconds with suggested default being 60 seconds. The 405 time interval MUST be chosen to ensure that SAP announcement message 406 is sent out before the corresponding multicast routing entry e.g. 407 (S,G) or (*,G) (corresponding to the SAP multicast tree(s)) on the 408 router doesn't time out. (It is worth noting that the default time- 409 out period for the multicast routing entry is 210 seconds, per the 410 PIM specification [RFC4601], though the time-out value may be set to 411 another value as allowed by the implementation.) 413 The SAP implementation MAY also support the complex method for 414 determining the SAP announcement time interval, and provide the 415 option to select it over the simpler method. 417 When simpler method is used, the 'time interval' may be signaled in 418 the SAP message payload e.g. within the FEC Framework Configuration 419 Information. 421 Note that SAP doesn't allow the time-interval to be signaled in the 422 SAP header. Hence, the usage of simpler method desires the time- 423 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 sender may choose to delete the announced FEC Framework 430 Configuration Information by sending a 'SAP deletion' message. This 431 deletion may be useful if the sender no longer desired to send any 432 FEC streams. If the sender needs to modify the announced FEC 433 Framework Configuration Information for one or more FEC instances, 434 then the sender MUST send a new announcement message with a different 435 'Message Identifier Hash' value as per the rules described in section 436 5 of RFC2974 [RFC2974]. Such announcement message SHOULD be sent 437 immediately (without having to wait for the time-interval) to ensure 438 that the modifications are received by the receiver as soon as 439 possible. The sender MUST send the SAP deletion message to delete the 440 previous SAP announcement message (i.e., with the previous 'Message 441 Identifier Hash' value). 443 4.1.2. Receiver Procedure 445 The receiver MUST listen on UDP port 9875 for packets arriving with 446 IP destination address of either 224.2.127.254 (if IPv4 global scope 447 session is used for the FEC stream), or FF0X:0:0:0:0:0:2:7FFE (if 448 IPv6 is selected, where X is the 4-bit scope value), or the highest 449 IP address (239.255.255.255, for example) in the relevant 450 administrative scope zone (if IPv4 administrative scope 239.0.0.0- 451 239.255.255.255 is selected for the FEC stream). These IP addresses 452 are mandated for SAP usage by RFC2974 [RFC2974]. 454 The receiver, upon receiving a SAP announcement message, creates an 455 entry, if it doesn't already exist, in a local database and passes 456 the FEC Framework Configuration Information from the SAP Payload 457 field to the 'FEC Framework' module. Each entry also maintains a 458 time-out value, which is (re)set to the five times the time-interval 459 value, which is either the default = 60 seconds, or the value 460 signaled by the sender. 462 Note that SAP doesn't allow the time-interval to be signaled in the 463 SAP header. Hence, the time-interval SHOULD be included in the FEC 464 Framework Configuration Information. For example, the usage of "r=" 465 (repeat time) field in SDP to convey the time-interval value, if 466 SDP encoding format is used. 468 The time-out value associated with each entry is reset when the 469 corresponding annoucement (please see section 5 of [RFC2974]) is 470 received. If the time-out value for any entry reaches zero, then the 471 entry is deleted from the database. 473 The receiver, upon receiving a SAP delete message, MUST delete the 474 matching SAP entry in its database. This SHOULD result in the 475 receiver no longer using the relevant FEC Framework Configuration 476 Information for the corresponding instance, and SHOULD no longer 477 subscribe to any related FEC streams. 479 4.2. Signaling Protocol for Unicasting 481 This document describes leveraging any signaling protocol that is 482 already used by the unicast application, for exchanging the FEC 483 Framework Configuration Information between two nodes. 485 For example, a multimedia (VoD) client may send a request via 486 unicasting for a particular content to the multimedia (VoD) server, 487 which may offer various options such as encodings, bitrates, 488 transport etc. for the content. The client selects the suitable 489 options and answers to the server, paving the way for the content to 490 be unicast on the chosen transport from server to the client. This 491 offer/answer signaling, described in [RFC3264], is commonly utilized 492 by many application protocols such as SIP, RTSP etc. 494 The fact that two nodes desiring unicast communication almost always 495 rely on an application to first exchange the application related 496 parameters via the signaling protocol, it is logical to enhance such 497 signaling protocol(s) to (a) convey the desire for the FEC protection 498 and (b) subsequently also exchange FEC parameters i.e., FEC Framework 499 Configuration Information. This enables the node acting as the 500 offerer to offer 'FEC Framework Configuration Information' for each 501 of available FEC instances, and the node acting as the answerer 502 conveying the chosen FEC Framework instance(s) to the offerer. The 503 usage of FEC framework instance is explained the FEC Framework 504 document [FECARCH]. 506 While enhancing an application's signaling protocol to exchange FEC 507 parameters is one method (briefly explained above), another method 508 would be to have a unicast based generic protocol that could be used 509 by two nodes independent of the application's signaling protocol. The 510 latter method is under investigation and may be covered by a separate 511 document. 513 The remainder of this section provides example signaling protocols 514 and explains how they can be used to exchange FEC Framework 515 Configuration Information. 517 4.2.1. SIP 519 SIP [RFC3261] is an application-level signaling protocol to create, 520 modify, and terminate multimedia sessions with one or more 521 participants. SIP also enables the participants to discover one 522 another and to agree on a characterization of a multimedia session 523 they would like to share. SIP runs on either TCP or UDP or SCTP 524 transport, and uses SDP as the encoding format to describe multmedia 525 session attributes. 527 SIP already uses an offer/answer model with SDP, described in 528 [RFC3264], to exchange the information between two nodes to establish 529 unicast sessions between them. This document extends the usage of 530 this model for exchanging the FEC Framework Configuration 531 Information, explained in section 3. Any SDP specific enhancements to 532 accommodate the FEC Framework are covered in the SDP Elements 533 specification [FECSDP]. 535 4.2.2. RSTP 537 RTSP [RFC2326] is an application-level signaling protocol for control 538 over the delivery of data with real-time properties. RTSP provides an 539 extensible framework to enable controlled, on-demand delivery of 540 real-time data, such as audio and video. RTSP runs on either TCP or 541 UDP transports. 543 RTSP already provides an ability to extend the existing method with 544 new parameters. This specification defines 'FEC Protection Required' 545 option-tag (please see section 6 for IANA Considerations) and 546 prescribes including it in the Require (or Proxy-Require) header of 547 SETUP (method) request message, so as to request for FEC protection 548 for the data. 550 The node receiving such request either responds with "200 OK" message 551 that includes offers i.e., available FEC options (e.g. FEC Framework 552 Configuration Information for each Instnace) or "551 Option not 553 supported" message. A sample of related message exchange is shown 554 below - 555 Node1->Node2: SETUP < ... > RTSP/1.0 556 CSeq: 1 557 Transport: 558 Require: FECprotectionRequired 560 Node2->Node1: RTSP/1.0 200 OK 561 CSeq: 1 562 Transport: 564 The requesting node (Node1) may then send a new SETUP message to 565 convey the selected FEC protection to Node2, and proceed with regular 566 RTSP messaging. 568 Suffice to say, if the requesting node (Node1) received '551 Option 569 not supported' response from Node2, then the requesting node (Node1) 570 may send the SETUP message without using the Require header. 572 5. Security Considerations 574 There is no additional security consideration other than what's 575 already covered in [RFC2974] for SAP, [RFC2326] for RTSP, and 576 [RFC3261] for SIP. 578 6. IANA Considerations 580 This document requests IANA to register a new option-tag for FEC 581 protection required, as described in section 4.2.2, and provides the 582 following information in compliance with section 3.8.1 in [RFC2326]: 584 . Name of option = FECprotectionRequired 586 . Change of Control = IETF 588 7. Acknowledgments 590 Thanks to Colin Perkins for pointing out the issue with the time- 591 interval for the SAP messages. Additionally, thanks to Mark Watson, 592 Ali Begen and Ulas Kozat for solidifying this proposal. 594 This document was prepared using 2-Word-v2.0.template.dot. 596 8. References 598 8.1. Normative References 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [FECARCH] Watson, M., "Forward Error Correction (FEC) Framework", 604 draft-ietf-fecframe-framework-05 (work in progress), Jan 605 2010. 607 [FECSDP] Begen, A., "SDP Elements for FEC Framework", draft-ietf- 608 fecframe-sdp-elements-04 (work in progress), Feb 2010. 610 [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session 611 Announcement Protocol", RFC 2974, October 2000. 613 8.2. Informative References 615 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 616 Description Protocol", RFC 4566, July 2006. 618 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 619 with Session Description Protocol (SDP)", RFC 3264, June 620 2002. 622 [RFC2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time 623 Streaming Protocol (RTSP)", RFC 2326, April 1998. 625 [RFC3261] Handley, M., Schulzrinne, H., Schooler, E. and J. 626 Rosenberg, "SIP: Session Initiation Protocol", RFC 3261, 627 June 2002. 629 [RFC4601] Fenner, etc., "Protocol Independent Multicast - Sparse Mode 630 (PIM-SM): Protocol Specification", RFC 4601, August 2006. 632 [RFC3547] Baugher, etc., "The Group Domain of Interpretation", RFC 633 3547, July 2003. 635 [SAP-REQ] Asaeda, etc., "Requirements for IP Multicast Session 636 Announcement in the Internet, draft-ietf-mboned-session- 637 announcement-req-02, April 2010. 639 Author's Addresses 641 Rajiv Asati 642 Cisco Systems, 643 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 644 Email: rajiva@cisco.com