idnits 2.17.1 draft-ietf-fecframe-config-signaling-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 632. 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 Copyright Line does not match the current year -- 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 (November 1, 2008) is 5627 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-03 == Outdated reference: A later version (-11) exists of draft-ietf-fecframe-sdp-elements-01 -- 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 (~~), 4 warnings (==), 11 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: May 2009 November 1, 2008 6 Methods to convey FEC Framework Configuration Information 7 draft-ietf-fecframe-config-signaling-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on May 1, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 FEC Framework document [FECARCH] defines the FEC Framework 42 Configuration Information necessary for the FEC framework operation. 43 This document describes how to use existing signaling protocols to 44 determine and dynamically communicate the Configuration information 45 between sender(s) and receiver(s). 47 Conventions used in this document 49 In examples, "C:" and "S:" indicate lines sent by the client and 50 server respectively. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Terminology/Abbreviations......................................3 60 3. FEC Framework Configuration Information........................4 61 3.1. Encoding Format...........................................5 62 4. Signaling Protocol.............................................6 63 4.1. Signaling Protocol for Multicasting.......................7 64 4.1.1. Sender Procedure.....................................9 65 4.1.2. Receiver Procedure..................................10 66 4.2. Signaling Protocol for Unicasting........................11 67 4.2.1. SIP.................................................12 68 4.2.2. RSTP................................................12 69 4.2.3. DSM-CC..............................................13 70 5. Security Considerations.......................................13 71 6. IANA Considerations...........................................13 72 7. Conclusions...................................................13 73 8. Acknowledgments...............................................14 74 9. References....................................................15 75 9.1. Normative References.....................................15 76 9.2. Informative References...................................15 77 Author's Addresses...............................................16 78 Intellectual Property Statement..................................16 79 Disclaimer of Validity...........................................16 81 1. Introduction 83 FEC Framework document [FECARCH] defines the FEC Framework 84 Configuration Information that governs the overall FEC framework 85 operation common to any FEC scheme. This information MUST be 86 available at both sender and reciever(s). This document describes how 87 to use various signaling protocols to determine and communicate the 88 Configuration information between sender and receiver(s). The 89 configuration information may be encoded in any compatible format 90 such as SDP [RFC4566], XML etc. A signaling protocol could be 91 utilized by any FEC scheme and/or any Content Delivery Protocol 92 (CDP). 94 This document doesn't describe any FEC scheme specifics information 95 (for example, how are source blocks are constructed) or any sender or 96 receiver side operation for a particular FEC scheme (for example, 97 whether the receiver makes use of one or more repair flows that are 98 received) etc. Such FEC scheme specifics should be covered in 99 separate document(s). This document doesn't mandate a particular 100 encoding format for the configuration information either. 102 104 Content Delivery Protocol (CDP) is defined as a complete (suite of) 105 specification which, through the use of FEC Framework, is able to 106 make use of FEC scheme(s) to provide FEC capabilities. In other 107 words, CDP makes use of common building blocks (including signaling 108 protocol) as defined in the FEC Framework document [FECARCH]. 110 This document is structured such that Section 2 describes the terms 111 used in this document, section 3 describes the FEC Framework 112 configuration information, section 4 describes how to use signaling 113 protocol for the multicast application, section 5 describes the 114 signaling protocol for the unicast application, and section 6 115 describes security consideration. 117 Copyright (C) The IETF Trust (2008). This version of this MIB module 118 is part of RFC XXXX; see the RFC itself for full legal notices. 120 2. Terminology/Abbreviations 122 This document makes use of the terms/abbreviations defined in the FEC 123 Framework document [FECARCH]. Additionally, it defines 125 o Media Sender - Node performing the Media encoding and producing 126 the original media flow to the 'FEC Sender' 128 o Media Receiver - Node performing the Media decoding; 130 o FEC Sender - Node performing the FEC encoding on the original 131 stream to produce the FEC stream 133 o FEC Receiver - Node performing the FEC decoding, as needed, and 134 providing the original media flow to the Media receiver. 136 o Sender - Same as FEC Sender 138 o Receiver - Same as FEC Receiver 140 o (Media) Stream - A single media instance i.e. an audio stream or 141 a video stream. 143 This document deliberately refers to the 'FEC Sender' and 'FEC 144 Receiver' as the 'Sender' and 'Receiver' respectively. 146 3. FEC Framework Configuration Information 148 The FEC Framework [FECARCH] defines a minimum set of information that 149 MUST be communicated between the sender and receiver(s) for a proper 150 operation of an FEC scheme. This information is referred to as "FEC 151 Framework Configuration Information". This is the information that 152 the FEC Framework needs in order to apply FEC protection to the 153 transport flows. 155 A single instance of the FEC Framework provides FEC protection for 156 all packets of a specified set of source packet flows, by means of 157 one or more packet flows consisting of repair packets. As per the FEC 158 Framework document [FECARCH], the FEC Framework Configuation 159 Information includes, for each instance of the FEC Framework: 161 1. Identification of Source Flow(s) 163 2. Identification of the repair flow(s) 165 3. Identification of FEC Scheme 167 4. Length of Source FEC payload ID 169 5. FEC Scheme Specific Information (FSSI) 170 FSSI basically provides an opaque container to encode FEC scheme 171 specific configuration information such as buffer size, decoding 172 wait-time etc. Please refer to the FEC Framework document [FECARCH] 173 for more details. 175 The usage of signaling protocols described in this document requires 176 that the application layer responsible for the FEC Framework instance 177 i.e. FEC scheme provide the value for each of the configuration 178 information parameter (listed above) encoded as per the chosen 179 encoding format. Failure to receive the complete information, the 180 signaling protocol module must return an error for the OAM purposes 181 and optionally convey to the application layer. Please refer to the 182 figure 1 of the FEC Framework document [FECARCH] for further 183 illustration. 185 This document does not make any assumption that the 'FEC sender and 186 receiver' functionality and the 'Media Source/Receiver' functionality 187 are implemented on the single device, though it may be the case. 189 3.1. Encoding Format 191 The FEC Framework configuration information (listed above in section 192 3) may be encoded in any format such as SDP, XML etc. as chosen or 193 prefered by a particular FEC Framework instance i.e. FEC Scheme. The 194 selection of such encoding format or syntax is independent of the 195 signaling protocol and beyond the scope of this document. 197 Whatever encoding format is selected for a particular FEC framework 198 instance, it must be known by the signaling protocol. This is to 199 provide a mean (e.g. a field such as Payload Type) in the signaling 200 protocol message(s) to convey the chosen encoding format for the 201 configuration information so that the Payload i.e. configuration 202 information can be correctly parsed as per the semantics of the 203 chosen encoding format at the receiver. Please note that the encoding 204 format is not a negotiated parameter, but rather a property of a 205 particular FEC Framework instance i.e. FEC scheme and/or its 206 implementation. 208 Additionally, the encoding format for each FEC Framework 209 configuration parameter must be defined in terms of a sequence of 210 octets that can be embedded within the payload of the signaling 211 protocol message(s). The length of the encoding format MUST either 212 be fixed, or derived by examining the encoded octets themselves. For 213 example, the initial octets may include some kind of length 214 indication. 216 Each instance of the FEC Framework muse use a single encoding format 217 to describe e.g. encode all of the configuration information 218 associated with that instance. The signaling protocol may not 219 validate the encoded information, though it may validate the syntax 220 or length of the encoded information. 222 The reader may refer to the SDP elements document [FECSDP], which 223 describes the usage of 'SDP' encoding format as an example encoding 224 format for FEC framework configuration information. 226 4. Signaling Protocol Usage 228 FEC Framework [FECARCH] requires certain FEC Framework Configuration 229 Information to be available to both sender and receiver(s). This 230 configuration information is almost always formulated at the sender 231 (or on behalf of a sender),the receiver(s) somehow must get this 232 configuration information. While one may envision a static method to 233 populate the configuration information at both sender and 234 receiver(s), it would require the knowledge of every receiver in 235 advance and that is something not always feasible. Hence, there is a 236 desire to describe using methods i.e. signaling protocol to convey 237 the configuration information between sender and one or more 238 receivers. 240 It is important to note that there may be either only one receiver 241 needing the FEC Framework configuration information to FEC protect a 242 "unicasted multimedia stream" (such as Video On Demand stream), or 243 one or more receivers needing the FEC Framework configuration 244 information to FEC protect a "multicasted multimedia stream" (such as 245 Broadcast TV or IPTV). While the unicasted stream requires the 246 identification of the receiver at the sender, the multicasted stream 247 doesn't necessarily require the identification of the receiver at the 248 sender. 250 Such diversity necessitates describing using at least two types of 251 signaling protocols - one to deliver the configuration information to 252 many receivers via multicasting (described in section 4.1), and the 253 other to deliver the configuration information to one and only one 254 receiver via unicasting (described in section 4.2). 256 Figure 1 below illustrates a sample topology showing the FEC sender 257 and FEC receiver (that may or may not be the Media Sender and Media 258 Receiver respectively) such that FEC_Sender1 is serving 259 FEC_Reciver11,12,13 via the multicast signaling protocol, whereas the 260 FEC_Sender2 is serving only FEC_Reciever2 via the unicast signaling 261 protocol. 263 FEC_Sender2---------| |--------FEC_Receiver2 264 | | 265 FEC_Sender1-----IP/MPLS network 266 |-----------FEC_Receiver11 267 |-----------FEC_Receiver12 268 |-----------FEC_Receiver13 270 Figure 1 Topology using Sender and Receiver 272 The rest of the section continues to use the terms 'Sender' and 273 'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver' 274 respectively. 276 4.1. Signaling Protocol for Multicasting 278 This specification describes using Session Announcement Protocol 279 (SAP) version 2 [RFC2974] as the signaling protocol to multicast the 280 configuration information from one sender to many receivers. The 281 apparent advantage is that the server doesn't need to maintain any 282 state for any receiver using SAP. 284 At the high level, a sender, acting as the SAP announcer, signals the 285 FEC Framework Configuration Information for each FEC Framework 286 instance available at the sender, using the SAP message(s). The 287 configuration information, encoded in a suitable format as per the 288 section 3.1, is carried in the Payload of the SAP message(s). A 289 receiver, acting as the SAP listener, listens on a well known UDP 290 port and at least one well known multicast group IP address. This 291 enables the receiver to receive the SAP message(s) and obtains the 292 FEC Framework Configuration Information for each FEC Framework 293 Instance. 295 Using the configuration information, the receiver becomes aware of 296 available FEC protection options, and may subscribe to one or more 297 multicast trees to receive the FEC streams using out-of-band 298 multicasting techniques such as PIM [RFC4601]. This, however, is 299 outside the scope of this document. 301 SAP message is carried over UDP over IP. The destination UDP port 302 must be 9875 and source UDP port may be any available number. The SAP 303 message(s) SHOULD contain an authentication header and MAY be 304 subjected to the cryptography. One cryptography method suggested by 305 this specification is the usage of Group Cryptography as specified in 306 GDOI [RFC3547]. 308 Figure 2 below illustrates the SAP packet format (it is reprinted 309 from the RFC2974) - 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | V=1 |A|R|T|E|C| auth len | msg id hash | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 : originating source (32 or 128 bits) : 318 : : 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | optional authentication data | 321 : .... : 322 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 323 | optional payload type | 324 + +-+- - - - - - - - - -+ 325 | |0| | 326 + - - - - - - - - - - - - - - - - - - - - +-+ | 327 | | 328 : payload : 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 2 SAP Message format 334 While the RFC2974 includes explanation for each field, it is worth 335 discussing the 'Payload' and 'Payload Type' field. This field must be 336 used to carry the FEC Framework configuration information. 337 Subsequently, the optional 'Payload Type' field, which is a MIME 338 content type specifier, must describe the encoding format used to 339 encode the Payload. For example, the 'Payload Type' field may be 340 application/sdp if the FEC framework configuration information is 341 encoded in SDP format and carried in the SAP payload. Similarly, it 342 would be application/xml if the FEC framework configuration 343 information was encoded in XML format. 345 4.1.1. Sender Procedure 347 The sender signals the FEC framework configuration for each FEC 348 framework instance in a periodic SAP announcement message. The SAP 349 announcement message is sent to a well known multicast IP address and 350 port. The announcement is multicasted with the same scope as the 351 session being announced. 353 The SAP module at the sender obtains the FEC Framework configuration 354 information per Instance from the 'FEC Framework' module and places 355 that in the SAP payload accordingly. A single SAP (announcement) 356 message may carry the FEC Framework Configuration Information for 357 each FEC Framework Instance. This is the preferred method, though the 358 other method may be to aggregate more than one SAP (announcement) 359 messages in a single UDP datagram as long as the resulting UDP 360 datagram length is less than the IP MTU of the outgoing interface. 362 The IP packet carrying the SAP message must be sent to destination IP 363 address of either 239.16.33.254 (if IPv4 administrative scope 364 239.0.0.0-239.255.255.255 is selected) or 224.2.127.254 (if IPv4 365 global scope 224.0.1.0-238.255.255.255 is selected) or 366 FF0X:0:0:0:0:0:2:7FFE (if IPv6 is selected, where X is the 4-bit 367 scope value) with UDP destination port 9875. The default IP TTL value 368 should be 255, though the implementation should allow to set it to 369 any other value. The IP DSCP field may be set to any value that 370 indicates a desired QoS treatment in the IP network. 372 The IP packet carrying the SAP message must be sent with source IP 373 address that is reachable by the receiver. The sender may assign the 374 same IP address in the "originating source" field of the SAP message, 375 as the one used in the source IP address of the IP packet. 377 Furthermore, the FEC Framework Configuration Information must NOT 378 include any of the reserved multicast group IP addresses for the FEC 379 streams (i.e. source or repair flows), though it may use the same IP 380 address as the 'originating source' address to identify the FEC 381 streams (i.e. source or repair flows). Please refer to IANA 382 assignments for multicast addresses. 384 The sender must periodically send the 'SAP announcement' message. 385 This is required so that the receiver doesn't purge the cached 386 entry(s) from the database and doesn't trigger the deletion of FEC 387 Framework configuration information. While the time interval between 388 repetitions of an announcement can be calculated as per the very 389 sophisticated but complex formula explained in RFC2974, the preferred 390 and simpler mean is to let the user specify the time interval from 391 the range of 1-200 seconds with suggested default being 60 seconds. 392 The time interval must be chosen to ensure that SAP announcement 393 message is sent out before the corresponding multicast routing entry 394 (S,G) or (*,G) on the router doesn't time out. It is worth noting 395 that the default time-out period for the multicast routing entry is 396 210 seconds, per the PIM specification [RFC4601], though it may 397 depend on the implementation. The SAP implementation should provide 398 the flexibility to the operator to choose the complex method over the 399 simpler method of determining the SAP announcement time interval. 400 Additionally, the 'time interval' should be signaled within the FEC 401 Framework configuration Information. 403 The sender may choose to delete the announced FEC framework 404 configuration information by sending a 'SAP deletion' message. This 405 may be used if the sender no longer desires to send any FEC streams. 406 If the sender needs to modify the announced FEC Framework 407 configuration Information for one or more FEC instances, then the 408 sender must send a new announcement message with a different 'Message 409 Identifier Hash' value as per the rules described in section 5 of 410 RFC2974. Such announcement message should be sent immediately 411 (without having to wait for the time-interval) to ensure that the 412 modifications are received by the receiver as soon as possible. The 413 sender must send the SAP deletion message to delete the previous SAP 414 announcement message (i.e. with the previous 'Message Identifier 415 Hash' value). 417 4.1.2. Receiver Procedure 419 The receiver must listen on UDP port 9875 for packets arriving with 420 IP destination address of either 239.16.33.254 (if IPv4 421 administrative scope is selected) or 224.2.127.254 (if IPv4 global 422 scope is selected) or FF0X:0:0:0:0:0:2:7FFE (if IPv6 is selected, 423 where X is the 4-bit scope value). 425 The receiver, upon receiving a SAP announcement message, creates an 426 entry, if it doesn't already exists, in a local database and passes 427 the FEC Framework configuration information from the SAP Payload 428 field to the 'FEC Framework' module. When the same annoucement 429 (please see section 5 of RFC2974) is received the next time, the 430 timer of the corresponding entry should be reset to the three times 431 the time-interval value that is signaled by the sender or one hour, 432 whichever is greater. 434 Editor's Note: Unfortunately, SAP doesn't allow the time-interval to 435 be signaled in the SAP header. Hence, the time-interval should be 436 specified in the FEC Framework Configuration Information. For 437 example, the usage of "r=" (repeat time) field in SDP. 439 The receiver, upon receiving a SAP delete message, must delete the 440 matching SAP entry in its database. This should result in the 441 receiver no longer using the relevant FEC framework configuration 442 information for every instance, and should no longer subscribe to any 443 related FEC streams. 445 4.2. Signaling Protocol for Unicasting 447 This document describes leveraging any signaling protocol that is 448 already used by the unicast application, for exchanging the FEC 449 Framework configuration Information between two nodes. 451 For example, a multimedia (VoD) client may send a request via 452 unicasting for a particular content to the multimedia (VoD) server, 453 which may offer various options such as encodings, bitrates, 454 transport etc. for the content. The client selects the suitable 455 options and answers to the server, paving the way for the content to 456 be unicasted on the chosen transport from server to the client. This 457 offer/answer signaling, described in [RFC3264], is commonly utilized 458 by many application protocols such as SIP, RTSP etc. 460 The fact that two nodes desiring unicast communication almost always 461 rely on an application to first exchange the application related 462 parameters via the signaling protocol, it is logical to enhance such 463 signaling protocol(s) to (a) convey the desire for the FEC protection 464 and (b) subsequently also exchange FEC parameters i.e. FEC Framework 465 Configuration information. This enables the node acting as the 466 offerer to offer 'FEC Framework Configuration Information' for each 467 of available FEC instances, and the node acting as the answerer 468 conveying the chosen FEC Framework instance(s) to the offerer. The 469 usage of FEC framework instance i.e. FEC scheme is explained the FEC 470 Framework document [FECARCH]. 472 While enhancing anapplication's signaling protocol to exchange FEC 473 parameters is one method (briefly explained above), another method 474 would be to have a unicast based generic protocol that could be used 475 by two nodes independent of the application's signaling protocol. The 476 latter method is under investigation and may be covered by a separate 477 document. 479 The remainder of this section provides example signaling protocols 480 and explains how they can be used to exchange FEC Framework 481 Configuration information. 483 4.2.1. SIP 485 SIP [RFC3261] is an application-level signaling protocol to create, 486 modify, and terminate multimedia sessions with one or more 487 participants. SIP also enables the participants to discover one 488 another and to agree on a characterization of a multimedia session 489 they would like to share. SIP runs on either TCP or UDP or SCTP 490 transport, and uses SDP as the encoding format to describe multmedia 491 session attributes. 493 SIP already uses offer/answer model with SDP, described in [RFC3264], 494 to exchange the information between two nodes to establish unicast 495 sessions between them. This document extends the usage of this model 496 for exchanging the FEC Framework Configuration Information, explained 497 in section 3. Any SDP specific enhancements to accommodate the FEC 498 Framework are covered in the SDP Elements specification [FECSDP]. 500 4.2.2. RSTP 502 RTSP [RFC2326] is an application-level signaling protocol for control 503 over the delivery of data with real-time properties. RTSP provides an 504 extensible framework to enable controlled, on-demand delivery of 505 real-time data, such as audio and video. RTSP runs on either TCP or 506 UDP transports. 508 RTSP already provides an ability to extend the existing method with 509 new parameters. This specification suggests requesting for the FEC 510 protection options by including "FEC Protection Required" in the 511 "Require:" header of SETUP (method) request message. The node 512 receiving such request either responds with "200 OK" message that 513 includes offers i.e. available FEC options (e.g. FEC Framework 514 Configuration Information for each Instnace) or "551 Option not 515 supported" message. A sample of related message exchange is shown 516 below - 517 Node1->Node2: SETUP < ... > RTSP/1.0 518 CSeq: 1 519 Transport: 520 Require: FEC Protections Required 522 Node2->Node1: RTSP/1.0 200 OK 523 CSeq: 1 524 Transport: 526 The requesting node (Node1) may then send either the SETUP message 527 without using the Require: header, if the remote node didn't support 528 the "FEC protection", or a new SETUP message to request the selected 529 FEC protection streams. 531 4.2.3. DSM-CC 533 DSM-CC is a predominant suite of protocols including the signaling 534 protocol used for the video control plane in Cable/MSO networks that 535 have offered video services for decades. DSM-CC is standardised in 536 MPEG-2 ISO/IEC 13818-6 (part 6 of the MPEG-2 standard), not within 537 the IETF yet, hence, DSM-CC related enhancements aren't covered in 538 this document. The same is applicable to Session Setup protocol (SSP) 539 and Lightweight Stream Control Protocol (LSCP) that are derived from 540 DSM-CC, as well. 542 5. Security Considerations 544 There is no additional security consideration other than what's 545 already covered in RFC2974 for SAP, RFC2326 for RTSP, RFC3261 for SIP 546 etc. 548 6. IANA Considerations 550 None. 552 7. Conclusions 554 TBD. 556 8. Acknowledgments 558 Thanks to Colin Perkins for pointing out the issue with the time- 559 interval for the SAP messages. Additionally, thanks to Mark Watson, 560 Ali Begen and Ulas Kozat for solidifying this proposal. 562 This document was prepared using 2-Word-v2.0.template.dot. 564 9. References 566 9.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [FECARCH] Watson, M., "Forward Error Correction (FEC) Framework", 572 draft-ietf-fecframe-framework-03 (work in progress), 573 October 2008. 575 [FECSDP] Begen, A., "SDP Elements for FEC Framework", draft-ietf- 576 fecframe-sdp-elements-01 (work in progress), July 14 2008. 578 9.2. Informative References 580 [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session 581 Announcement Protocol", RFC 2974, October 2000. 583 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 584 Description Protocol", RFC 4566, July 2006. 586 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 587 with Session Description Protocol (SDP)", RFC 3264, June 588 2002. 590 [RFC2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time 591 Streaming Protocol (RTSP)", RFC 2326, April 1998. 593 [RFC3261] Handley, M., Schulzrinne, H., Schooler, E. and J. 594 Rosenberg, "SIP: Session Initiation Protocol", RFC 3261, 595 June 2002. 597 [RFC4601] Fenner, etc., "Protocol Independent Multicast - Sparse Mode 598 (PIM-SM) : Protocol Specification", RFC 4601, August 2006. 600 [RFC3547] Baugher, etc., "The Group Domain of Interpretation", RFC 601 3547, July 2003. 603 Author's Addresses 605 Rajiv Asati 606 Cisco Systems, 607 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 608 Email: rajiva@cisco.com 610 Intellectual Property Statement 612 The IETF takes no position regarding the validity or scope of any 613 Intellectual Property Rights or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; nor does it represent that it has 617 made any independent effort to identify any such rights. Information 618 on the procedures with respect to rights in RFC documents can be 619 found in BCP 78 and BCP 79. 621 Copies of IPR disclosures made to the IETF Secretariat and any 622 assurances of licenses to be made available, or the result of an 623 attempt made to obtain a general license or permission for the use of 624 such proprietary rights by implementers or users of this 625 specification can be obtained from the IETF on-line IPR repository at 626 http://www.ietf.org/ipr. 628 The IETF invites any interested party to bring to its attention any 629 copyrights, patents or patent applications, or other proprietary 630 rights that may cover technology that may be required to implement 631 this standard. Please address the information to the IETF at 632 ietf-ipr@ietf.org. 634 Disclaimer of Validity 636 This document and the information contained herein are provided on an 637 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 638 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 639 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 640 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 641 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 642 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 644 Copyright Statement 646 Copyright (C) The IETF Trust (2008). 648 This document is subject to the rights, licenses and restrictions 649 contained in BCP 78, and except as set forth therein, the authors 650 retain all their rights. 652 Acknowledgment 654 Funding for the RFC Editor function is currently provided by the 655 Internet Society.