idnits 2.17.1 draft-asati-fecframe-config-signaling-00.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 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 621. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 634. 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 (February 18, 2008) is 5911 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-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 (~~), 3 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 February 18, 2008 4 Expires: August 2008 6 Signaling Protocol to convey FEC Framework Configuration Information 7 draft-asati-fecframe-config-signaling-00.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 August 18, 2008. 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 one signaling protocol to determine and 44 communicate the Configuration information between sender(s) and 45 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...............................................13 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 one 87 signalling protocol to determine and communicate the Configuration 88 information between sender and receiver(s). The configuration 89 information may be encoded in any compatible format such as SDP 90 [RFC4566], XML etc. The signaling protocol is intended to be generic 91 and could be utilized by any FEC scheme and/or any Content Delivery 92 Protocol (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 The FEC Framework document [FECARCH] defines a Content Delivery 105 Protocol (CDP) as a complete (suite of) specification which, through 106 the use of FEC Framework, is able to make use of a particular FEC 107 scheme to provide FEC capabilities. In other words, CDP is specific 108 to a FEC scheme, but makes use of common building blocks (including 109 signaling protocol) as defined in the FEC Framework document 110 [FECARCH]. 112 This document is structured such that Section 2 describes the terms 113 used in this document, section 3 describes the FEC Framework 114 configuration information, section 4 describes the signalling 115 protocol for the multicast, section 5 describes the signalling 116 protocol for the unicast, and section 6 describes security 117 consideration. 119 Copyright (C) The IETF Trust (2008). This version of this MIB module 120 is part of RFC XXXX; see the RFC itself for full legal notices. 122 Copyright (C) The IETF Trust (2008). The initial version of this MIB 123 module was published in RFC XXXX; for full legal notices see the RFC 124 itself. Supplementary information may be available at: 125 http://www.ietf.org/copyrights/ianamib.html. 127 2. Terminology/Abbreviations 129 This document makes use of the terms/abbreviations defined in the FEC 130 Framework document [FECARCH]. Additionally, it defines 132 o Media Sender - Node performing the Media encoding and producing 133 the original media flow to the 'FEC Sender' 135 o Media Receiver - Node performing the Media decoding; 137 o FEC Sender - Node performing the FEC encoding on the original 138 stream to produce the FEC stream 140 o FEC Receiver - Node performing the FEC decoding, as needed, and 141 providing the original media flow to the Media receiver. 143 o Sender - Same as FEC Sender 145 o Receiver - Same as FEC Receiver 147 o (Media) Stream - A single media instance i.e. an audio stream or 148 a video stream. 150 This documents deliberately refers to the 'FEC Sender' and 'FEC 151 Receiver' as the 'Sender' and 'Receiver' respectively. 153 3. FEC Framework Configuration Information 155 The FEC Framework [FECARCH] defines a minimum set of information that 156 MUST be communicated between the sender and receiver(s) for a proper 157 operation of an FEC scheme. This information is referred to as "FEC 158 Framework Configuration Information". This is the information that 159 the FEC Framework needs in order to apply FEC protection to the 160 transport flows. 162 A single instance of the FEC Framework provides FEC protection for 163 all packets of a specified set of source packet flows, by means of 164 one or more packet flows consisting of repair packets. As per the FEC 165 Framework document [FECARCH], the FEC Framework Configuation 166 Information includes, for each instance of the FEC Framework: 168 1. Identification of Source Flow(s) 170 2. Identification of the repair flow(s) 172 3. Identification of FEC Scheme 174 4. Length of Source FEC payload ID 175 5. FEC Scheme Specific Information (FSSI) 177 FSSI basically provides an opaque container to encode FEC scheme 178 specific configuration information such as buffer size, decoding 179 wait-time etc. Please refer to the FEC Framework document [FECARCH] 180 for more details. 182 The signaling protocol described in this document requires that the 183 application layer responsible for the FEC Framework instance i.e. FEC 184 scheme provide the value for each of the configuration information 185 parameter (listed above) encoded as per the chosen encoding format. 186 Failure to receive the complete information, the signaling protocol 187 module must return an error for the OAM purposes and optionally 188 convey to the application layer. Please refer to the figure 1 of the 189 FEC Framework document [FECARCH] for further illustration. 191 This document does make any assumption that the 'FEC sender and 192 receiver' functionality and the 'Media Source/Receiver' functionality 193 are implemented on the single device, though it is likely to be the 194 case. 196 3.1. Encoding Format 198 The FEC Framework configuration information (listed above in section 199 3) may be encoded in any format such as SDP, XML etc. as chosen or 200 prefered by a particular FEC Framework instance i.e. FEC Scheme. The 201 selection of such encoding format or syntax is independent of the 202 signaling protocol and beyond the scope of this document. 204 Whatever encoding format is selected for a particular FEC framework 205 instance, it must be known by the signaling protocol. This is to 206 provide a mean (e.g. a field such as Payload Type) in the signaling 207 protocol message(s) to convey the chosen encoding format for the 208 configuration information so that the Payload i.e. configuration 209 information can be correctly parsed as per the semantics of the 210 chosen encoding format. Please note that the the encoding format is 211 not a negotiated parameter, but rather a property of a particular FEC 212 Framework instance i.e. FEC scheme and/or its implementation. 214 Additionally, the encoding format for each FEC Framework 215 configuration parameter must be defined in terms of a sequence of 216 octets that can be embedded within the payload of the signaling 217 protocol message(s). The length of the encoding format MUST either 218 be fixed, or it must be possible to derive the length from examining 219 the encoded octets themselves. For example, the initial octets may 220 include some kind of length indication. 222 Each instance of the FEC Framework muse use a single encoding format 223 to describe e.g. encode all of the configuration information 224 associated with that instance. The signaling protocol may not 225 validate the encoded information, though it may validate the syntax 226 or length of the encoded information. 228 The reader may refer to the SDP elements document [FECSDP], which 229 describes the usage of 'SDP' encoding format as an example encoding 230 format for FEC framework configuration information. 232 4. Signaling Protocol 234 FEC Framework [FECARCH] requires certain FEC Framework Configuration 235 Information to be available to both sender and receiver(s). This 236 configuration information is almost always formulated at the sender 237 (or on behalf of a sender), the receiver(s) somehow must get this 238 configuration information. While one may envision a static method to 239 populate the configuration information at both sender and 240 receiver(s), it would require the knowledge of every receiver in 241 advance and that is something not always feasible. Hence, there is a 242 desire to define and describe dynamic method i.e. signaling protocol 243 to convey the configuration information from sender to one or more 244 receivers. 246 It is important to note that there may be either only one receiver 247 needing the FEC Framework configuration information to FEC protect a 248 "unicasted multimedia stream" (such as Video On Demand stream), or 249 one or more receivers needing the FEC Framework configuration 250 information to FEC protect a "multicasted multimedia stream" (such as 251 Broadcast TV or IPTV). While the unicasted stream requires the 252 identification of the receiver (which typically initiates the 253 communication) at the sender, the multicasted stream doesn't require 254 the identification of the receiver at the sender. 256 Such diversity necessitates describing at least two signaling 257 protocols - one to deliver the configuration information to many 258 receivers via multicasting (described in section 4.1), and the other 259 to deliver the configuration information to one and only one receiver 260 via unicasting (described in section 4.2). 262 Figure 1 below illustrates a sample topology showing the FEC sender 263 and FEC receiver (that may or many not be the Media Sender and Media 264 Receiver respectively) such that FEC_Sender1 is serving 265 FEC_Reciver11,12,13 via the multicast signaling protocol, whereas the 266 FEC_Sender2 is serving only FEC_Reciever2 via the unicast signaling 267 protocol. 269 FEC_Sender2---------| |--------FEC_Receiver2 270 | | 271 FEC_Sender1-----IP/MPLS network 272 |-----------FEC_Receiver11 273 |-----------FEC_Receiver12 274 |-----------FEC_Receiver13 276 Figure 1 Topology using Sender and Receiver 278 The rest of the section continues to use the terms 'Sender' and 279 'Receiver' to refer to the 'FEC Sender' and 'FEC Receiver' 280 respectively. 282 4.1. Signaling Protocol for Multicasting 284 A one-to-many signaling protocol is desired in order to effectively 285 deliver the FEC Framework configuration from one sender to many 286 receivers. The Session Announcement Protocol (SAP) version 2 287 [RFC2974] is used as the signaling protocol to multicast the 288 configuration information. The apparent advantage is that the server 289 doesn't need to maintain any state for any receiver using SAP. 291 At the high level, a sender, acting as the SAP announcer, signals the 292 FEC Framework Configuration Information for each FEC Framework 293 instance available at the sender, using the SAP message(s). The 294 configuration information, encoded in a suitable format as per the 295 section 3.1, is carried in the Payload of the SAP message(s). A 296 receiver, acting as the SAP listener, listens on a well known UDP 297 port and at least one well known multicast group IP address. This 298 enables the receiver to receives the SAP message(s) and obtains the 299 FEC Framework Configuration Information for each FEC Framework 300 Instnace. 302 Using the configuration information, the receiver becomes aware of 303 available FEC protection options, and may subscribe to one or more 304 multicast trees to receive the FEC streams using out-of-band 305 multicasting techniques such as PIM [RFC4601]. This, however, is 306 beyond the specification of this document. 308 SAP message is carried over UDP over IP. The destination UDP port 309 must be 9875 and source UDP port may be any available number. The SAP 310 message(s) SHOULD contain an authentication header and MAY be 311 subjected to the cryptography. One cryptography method suggested by 312 this specification is the usage of Group Cryptography as specified in 313 GDOI [RFC3547]. 315 Figure 2 below illustrates the SAP packet format (it is reprinted 316 from the RFC2974) - 318 0 1 2 3 319 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | V=1 |A|R|T|E|C| auth len | msg id hash | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 : originating source (32 or 128 bits) : 325 : : 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | optional authentication data | 328 : .... : 329 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 330 | optional payload type | 331 + +-+- - - - - - - - - -+ 332 | |0| | 333 + - - - - - - - - - - - - - - - - - - - - +-+ | 334 | | 335 : payload : 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 2 SAP Message format 341 While the RFC2974 includes explanation for each field, the most 342 interesting is the 'Payload' field. This field is required, by this 343 specification, to carry the the FEC Framework configuration 344 information. Subsequently, the 'Payload Type' field, which is a MIME 345 content type specifier, must describe the encoding format used to 346 encode the Payload,. For example, the 'Payload Type' field may be 347 application/sdp if the FEC framework configuration information was 348 encoded in SDP format. Similarly, it would be application/xml if the 349 FEC framework configuration information was encoded in XML format. 351 4.1.1. Sender Procedure 353 The sender signals the FEC framework configuration for each FEC 354 framework instance in a periodic SAP announcement message. The SAP 355 announcement message is sent to a well known multicast IP address and 356 port. The announcement is multicasted with the same scope as the 357 session it is announcing. 359 The SAP module at the sender obtains the FEC Framework configuration 360 information per Instance from the 'FEC Framework' module and places 361 that in the SAP payload accordingly. A single SAP (announcement) 362 message may carry the FEC Framework Configuration Information for 363 each FEC Framework Instance. This is a preferred method, though the 364 other method may be to aggregate more than one SAP (announcement) 365 messages in a single UDP datagram as long as the resulting UDP 366 datagram length is less than the IP MTU of the outgoing interface. 368 The IP packet carrying the SAP message must be sent with destination 369 IP address of either 239.16.33.254 (if IPv4 administrative scope 239. 370 is selected) or 224.2.127.254 (if IPv4 global scope 224.0.1.0- 371 238.255.255.255 is selected) or FF0X:0:0:0:0:0:2:7FFE (if IPv6 is 372 selected, where X is the 4-bit scope value) with UDP destination port 373 9875. The default IP TTL value should be 255, though the 374 implementation should allow to set it to any other value. The IP DSCP 375 field may be set to any value that indicates a desired QoS treatment 376 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. 391 This is required so that the receiver doesn't purge the cached 392 entry(s) from the database and doesn't trigger the deletion of FEC 393 Framework configuration information. While the time interval between 394 repetitions of an announcement can be calculated as per the very 395 sophisticated but complex formula explained in RFC2974, the preferred 396 and simpler mean is to let the user specify the time interval from 397 the range of 1-60 mins with suggested default being 10 mins. The 398 implementation of signaling protocol should provide the flexibility 399 to the operator to choose the complex method over the simpler method 400 of determining the SAP announcement time interval. Additionally, the 401 'time interval' should be signaled within the FEC Framework 402 configuration Information. 404 The sender may choose to delete the announced FEC framework 405 configuration information by sending a 'SAP deletion' message. This 406 may be used if the sender no longer desires to send any FEC streams. 407 If the sender needs to modify the announced FEC Framework 408 configuration Information for one or more FEC instances, then the 409 sender must send a new announcement message with a different 'Message 410 Identifier Hash' value as per the rules described in section 5 of 411 RFC2974. Such announcement message should be sent immediately 412 (without having to wait for the time-interval) to ensure that the 413 modifications are received by the receiver as soon as possible. The 414 sender must send the SAP deletion message to delete the previous SAP 415 announcement message (i.e. with the previous 'Message Identifier 416 Hash' value). 418 4.1.2. Receiver Procedure 420 The receiver must listen on UDP port 9875 for packets arriving with 421 IP destination address of either 239.16.33.254 (if IPv4 422 administrative scope is selected) or 224.2.127.254 (if IPv4 global 423 scope is selected) or FF0X:0:0:0:0:0:2:7FFE (if IPv6 is selected, 424 where X is the 4-bit scope value). 426 The receiver, upon receiving a SAP announcement message, creates an 427 entry, if it doesn't already exists, in a local database and passes 428 the FEC Framework configuration information from the SAP Payload 429 field to the 'FEC Framework' module. When the same annoucement 430 (please see section 5 of RFC2974) is received the next time, the 431 timer of the corresponding entry should be reset to the three times 432 the time-interval value that is signaled by the sender or one hour, 433 whichever is greater. 435 Editor's Note: SAP doesn't allow the time-interval to be signaled in 436 the SAP header. Hence, we need this to be specified in the FEC 437 Framework Configuration Information (allowed by SAP). For example, 438 the usage of "r=" (repeat time) field in SDP. 440 The receiver, upon receiving a SAP delete message, must delete the 441 matching SAP entry in its database. This should result in the 442 receiver no longer using the relevant FEC framework configuration 443 information for every instance, and should no longer subscribe to any 444 related FEC streams. 446 4.2. Signaling Protocol for Unicasting 448 The signaling protocol for unicasting enables two nodes, which wish 449 to communicate one-to-one across an IP network, to exchange the FEC 450 Framework configuration Information. This exchange may be 451 unidirectional or bidirectional depending on the application desiring 452 the FEC protection for its communication. 454 For example, a multimedia (VoD) client may send a request via 455 unicasting for a particular content to the multimedia (VoD) server, 456 which may offer various options such as encodings, bitrates, 457 transport etc. for the content. The client selects the suitable 458 options and answers to the server, paving the way for the content to 459 be unicasted on the chosen transport from server to the client. This 460 offer/answer signaling, described in [RFC3264], is commonly utilized 461 by many application protocols such as SIP, RTSP etc. 463 The fact that two nodes desiring unicast communication almost always 464 rely on an application to first exchange the application related 465 parameters via the signaling protocol, it is logical to enhance such 466 signaling protocol(s) to (a) convey the desire for the FEC protection 467 and (b) subsequently also exchange FEC parameters i.e. FEC Framework 468 Configuration information. This enables the node acting as the 469 offerer to offer 'FEC Framework Configuration Information' for each 470 of available FEC instances, and the node acting as the answerer 471 conveying the chosen FEC Framework instance(s) to the offerer. The 472 usage of FEC framework instance i.e. FEC scheme is beyond the scope 473 of this document. Please refer to the FEC Framework document 474 [FECARCH]. 476 While enhancing the application's signaling protocol to exchange FEC 477 parameters is one method (briefly explained above), another method 478 would be to have a unicast based generic protocol that could be used 479 by two nodes independent of the application's signaling protocol. The 480 latter method is under investigation and may be covered in future. 482 4.2.1. SIP 484 SIP [RFC3261] is an application-level signaling protocol to create, 485 modify, and terminate multimedia sessions with one or more 486 participants. SIP also enables the participants to discover one 487 another and to agree on a characterization of a multimedia session 488 they would like to share. SIP runs on either TCP or UDP or SCTP 489 transport, and uses SDP to describe multmedia session attributes. 491 SIP already uses offer/answer model with SDP, described in [RFC3264], 492 to exchange the information between two nodes to establish unicast 493 sessions between them. This specification extends the usage of this 494 model for exchanging the FEC Framework Configuration Information, 495 explained in section 3, between two SIP speaking nodes. 497 4.2.2. RSTP 499 RTSP [RFC2326] is an application-level signaling protocol for control 500 over the delivery of data with real-time properties. RTSP provides an 501 extensible framework to enable controlled, on-demand delivery of 502 real-time data, such as audio and video. RTSP runs on either TCP or 503 UDP transports. 505 RTSP already provides an ability to extend the existing method with 506 new parameters. This specification suggests requesting for the FEC 507 protection options by including "FEC Protection Required" in the 508 "Require:" header of SETUP (method) request message. The node 509 receiving such request either responds with "200 OK" message that 510 includes offers i.e. available FEC options (e.g. FEC Framework 511 Configuration Information for each Instnace) or "551 Option not 512 supported" message. 514 Node1->Node2: SETUP < ... > RTSP/1.0 516 CSeq: 1 518 Transport: 520 Require: FEC Protections Required 522 Node2->Node1: RTSP/1.0 200 OK | or | RTSP/1.0 551 Option Not 523 supported 525 CSeq: 1 | | CSeq: 1 527 Transport: 529 The requesting node (node1) may then send either the SETUP message 530 without using the Require: header, if the remote node didn't support 531 the "FEC protection", or a new SETUP message to request the selected 532 FEC protection streams. 534 4.2.3. DSM-CC 536 DSM-CC is a predominant suite of protocols including the signaling 537 protocol used for the video control plane in Cable/MSO networks that 538 have offered video services for decades. Unfortunately, DSM-CC is 539 actually standardised in MPEG-2 ISO/IEC 13818-6 (part 6 of the MPEG-2 540 standard), not within the IETF yet, hence, DSM-CC related 541 enhancements aren't covered in this document. The same is applicable 542 to Session Setup protocol (SSP) and Lightweight Stream Control 543 Protocol (LSCP) that are derived from DSM-CC, as well. 545 5. Security Considerations 547 There are no additional security consideration other than what's 548 already covered in RFC2974 for SAP, RFC2326 for RTSP, RFC3261 for SIP 549 etc. 551 6. IANA Considerations 553 None. 555 7. Conclusions 557 TBD. 559 8. Acknowledgments 561 TBD. 563 This document was prepared using 2-Word-v2.0.template.dot. 565 9. References 567 9.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, March 1997. 572 [FECARCH] Watson, M., "Forward Error Correction (FEC) Framework", 573 draft-ietf-fecframe-framework-01 (work in progress),, 574 November 2007. 576 [FECSDP] Begen, A., "SDP Elements for FEC Framework", draft-begen- 577 fecframe-sdp-elements-00 (work in progress), November 11 578 2007. 580 9.2. Informative References 582 [RFC2974] Handley, M., Perkins, C. and E. Whelan, "Session 583 Announcement Protocol", RFC 2974, October 2000. 585 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 586 Description Protocol", RFC 4566, July 2006. 588 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 589 with Session Description Protocol (SDP)", RFC 3264, June 590 2002. 592 [RFC2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time 593 Streaming Protocol (RTSP)", RFC 2326, April 1998. 595 [RFC3261] Handley, M., Schulzrinne, H., Schooler, E. and J. 596 Rosenberg, "SIP: Session Initiation Protocol", RFC 3261, 597 June 2002. 599 [RFC4601] Fenner, etc., "Protocol Independent Multicast - Sparse Mode 600 (PIM-SM) : Protocol Specification", RFC 4601, August 2006. 602 [RFC3547] Baugher, etc., "The Group Domain of Interpretation", RFC 603 3547, July 2003. 605 Author's Addresses 607 Rajiv Asati 608 Cisco Systems, 609 7025-6 Kit Creek Rd, RTP, NC, 27709-4987 610 Email: rajiva@cisco.com 612 Intellectual Property Statement 614 The IETF takes no position regarding the validity or scope of any 615 Intellectual Property Rights or other rights that might be claimed to 616 pertain to the implementation or use of the technology described in 617 this document or the extent to which any license under such rights 618 might or might not be available; nor does it represent that it has 619 made any independent effort to identify any such rights. Information 620 on the procedures with respect to rights in RFC documents can be 621 found in BCP 78 and BCP 79. 623 Copies of IPR disclosures made to the IETF Secretariat and any 624 assurances of licenses to be made available, or the result of an 625 attempt made to obtain a general license or permission for the use of 626 such proprietary rights by implementers or users of this 627 specification can be obtained from the IETF on-line IPR repository at 628 http://www.ietf.org/ipr. 630 The IETF invites any interested party to bring to its attention any 631 copyrights, patents or patent applications, or other proprietary 632 rights that may cover technology that may be required to implement 633 this standard. Please address the information to the IETF at 634 ietf-ipr@ietf.org. 636 Disclaimer of Validity 638 This document and the information contained herein are provided on an 639 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 640 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 641 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 642 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 643 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 644 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 646 Copyright Statement 648 Copyright (C) The IETF Trust (2008). 650 This document is subject to the rights, licenses and restrictions 651 contained in BCP 78, and except as set forth therein, the authors 652 retain all their rights. 654 Acknowledgment 656 Funding for the RFC Editor function is currently provided by the 657 Internet Society.