idnits 2.17.1 draft-sandbakken-xcon-bfcp-udp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 draft header indicates that this document updates RFC4582, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4583, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4582, updated by this document, for RFC5378 checks: 2004-07-13) -- 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 (March 2, 2010) is 5131 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) == Missing Reference: 'Appendix A' is mentioned on line 178, but not defined == Missing Reference: 'Section 8' is mentioned on line 404, but not defined == Missing Reference: 'XXXX' is mentioned on line 890, but not defined == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-08 ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) ** Obsolete normative reference: RFC 4583 (Obsoleted by RFC 8856) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thompson, Ed. 3 Internet-Draft T. Kristensen 4 Updates: 4582, 4583 G. Sandbakken 5 (if approved) T. Andersen 6 Intended status: Standards Track E. McLeod 7 Expires: September 3, 2010 TANDBERG 8 March 2, 2010 10 Revision of the Binary Floor Control Protocol (BFCP) for use over an 11 unreliable transport 12 draft-sandbakken-xcon-bfcp-udp-02 14 Abstract 16 This memo extends the Binary Floor Control Protocol (BFCP) for use 17 over an unreliable transport. It details a set of revisions to the 18 protocol definition document and the specification of BFCP streams in 19 the Session Description Protocol (SDP). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 3, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Revision of RFC4582 . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Overview of Operation (4) . . . . . . . . . . . . . . . . 5 65 3.2. Floor Participant to Floor Control Server Interface 66 (4.1) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. COMMON-HEADER Format (5.1) . . . . . . . . . . . . . . . . 5 68 3.4. ERROR-CODE (5.2.6) . . . . . . . . . . . . . . . . . . . . 6 69 3.5. FloorRequestStatusAck (5.3.14) . . . . . . . . . . . . . . 6 70 3.6. ErrorAck (5.3.15) . . . . . . . . . . . . . . . . . . . . 7 71 3.7. FloorStatusAck (5.3.16) . . . . . . . . . . . . . . . . . 7 72 3.8. Goodbye (5.3.17) . . . . . . . . . . . . . . . . . . . . . 8 73 3.9. GoodbyeAck (5.3.18) . . . . . . . . . . . . . . . . . . . 8 74 3.10. Transport (6) . . . . . . . . . . . . . . . . . . . . . . 8 75 3.11. Reliable transport (6.1) . . . . . . . . . . . . . . . . . 9 76 3.12. Unreliable transport (6.2) . . . . . . . . . . . . . . . . 10 77 4. Lower-Layer Security (7) . . . . . . . . . . . . . . . . . . . 11 78 5. Protocol Transactions (8) . . . . . . . . . . . . . . . . . . 11 79 5.1. Server Behavior (8.2) . . . . . . . . . . . . . . . . . . 12 80 5.2. Timers (8.3) . . . . . . . . . . . . . . . . . . . . . . . 12 81 5.2.1. Request retransmission timer, T1 (8.3.1) . . . . . . . 12 82 5.2.2. Response retransmission timer, T2 (8.3.2) . . . . . . 12 83 5.2.3. Timer values (8.3.3) . . . . . . . . . . . . . . . . . 13 84 5.3. Receiving a response [to a FloorRequest Message] 85 (10.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5.4. Receiving a response [to a FloorRelease Message] 87 (10.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.5. Receiving a response [to a ChairAction Message] (11.2) . . 13 89 5.6. Receiving a response [to a FloorQuery Message] (12.1.2) . 14 90 5.7. Receiving a response [to a FloorRequestQuery Message] 91 (12.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 5.8. Receiving a response [to a UserQuery Message] (12.3.2) . . 14 93 5.9. Receiving a response [to a Hello Message] (12.4.2) . . . . 14 94 5.10. Reception of a FloorRequestStatus Message (13.1.3) . . . . 14 95 5.11. Reception of a FloorStatus Message (13.5.3) . . . . . . . 15 96 5.12. Reception of an Error Message (13.8.1) . . . . . . . . . . 15 97 5.13. Security Considerations (14) . . . . . . . . . . . . . . . 15 98 5.14. IANA Considerations - Primitive Subregistry (15.2) . . . . 15 99 5.15. IANA Considerations - Error Code Subregistry (15.4) . . . 15 100 5.16. Example call flows for BFCP over Unreliable Transports 101 (Appendix A) . . . . . . . . . . . . . . . . . . . . . . . 16 102 6. Revision of RFC4583 . . . . . . . . . . . . . . . . . . . . . 19 103 6.1. Fields in the 'm' Line (3) . . . . . . . . . . . . . . . . 20 104 6.2. Security Considerations (10) . . . . . . . . . . . . . . . 20 105 6.3. Registration of SDP 'proto' values (11.1) . . . . . . . . 20 106 7. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 108 9. Normative References . . . . . . . . . . . . . . . . . . . . . 22 109 Appendix A. Changes to previous drafts . . . . . . . . . . . . . 22 110 A.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 22 111 A.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 23 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 114 1. Introduction 116 The motivation for using unreliable transports for BFCP [RFC4582] 117 messages is fuelled by network deployments where RTP proxies are 118 present for NAT and firewall traversal. In these deployments, TCP 119 may neither be applicable nor appropriate, for example, due to lack 120 of support for TCP media relay or ICE-TCP [I-D.ietf-mmusic-ice-tcp]. 122 This memo extends the BFCP protocol to support unreliable transport. 123 Minor changes to the transaction model are introduced in that all 124 requests now have an appropriate response to complete the 125 transaction. The requests are sent with a retransmit timer 126 associated with the response to achieve reliability. 128 The intension is not to change the semantics of BFCP, but to present 129 a trivial and workable extension that permits UDP as a transport. 130 Existing implementations in the spirit of the approach detailed in 131 -00 and -01 of this draft have demonstrated the approach to be 132 feasible. The purpose of this document is to formalise the 133 deviations from the baseline specification enabling interoperability 134 between implementations. 136 The content of this draft relates to the BFCP protocol specification 137 [RFC4582] and the format for the specification of BFCP streams in the 138 SDP [RFC4583]. This memo is written with the goal of being 139 incorporated into an upcoming revision of those documents without 140 requiring additional protocol and stream specification documents. 142 This draft is not recommended for adoption as an XCON working group 143 item at this time owing to the outstanding work detailed in 144 Section 7, but is submitted for information and discussion within the 145 XCON community. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. Revision of RFC4582 155 This section details revisions to [RFC4582], the base protocol 156 specification of BFCP. The section number to which updates apply are 157 indicated in parentheses in the titles of the sub-sections below. 159 3.1. Overview of Operation (4) 161 Fourth paragraph change: 163 There are two types of transaction in BFCP: client-initiated 164 transactions and server-initiated transactions. Client-initiated 165 transactions consist of a message from a client to the floor 166 control server and a response from the floor control server to the 167 client. Correspondingly, server-initiated transactions consist of 168 a message from the floor control server to a client and the 169 associated acknowledgement message from the client to the floor 170 control server. Both messages can be related because they carry 171 the same Transaction ID value in their common headers. 173 3.2. Floor Participant to Floor Control Server Interface (4.1) 175 Before seventh paragraph (page 9), insert: 177 Figures 2 and 3 below show call flows for two sample BFCP 178 interactions when used over reliable transport. [Appendix A] 179 (Note: here-in Section 5.16) shows the same sample interactions 180 but over an unreliable transport. 182 3.3. COMMON-HEADER Format (5.1) 184 The figure below should replace Figure 5: COMMON-HEADER format. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Ver |Reserved | Primitive | Payload Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Conference ID | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |I| Transaction ID | User ID | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1: COMMON-HEADER format 198 The following text preceeds "Transaction ID" on page 16: 200 I: The Transaction Initiator (I) flag-bit has relevance only for 201 use of BFCP over unreliable media. When clear, it signifies that 202 the transaction was opened by the client (floor participant, 203 chair) and that the Transaction ID that follows has been generated 204 by the client; when set, the transaction is a server-initiated 205 transaction and the Transaction ID that follows is pertinent to 206 the floor control server. Where BFCP is used over reliable 207 transports, the flag has no significance and SHOULD be cleared. 209 Note: An alternative is that we don't actually specify bit-16 of the 210 Transaction ID to be a flag per se, but define a range of Transaction 211 IDs that are defined as valid for each supported transport. 213 The description of Transaction ID should have the final clause 214 deleted with the reference to Section 8 remaining. The value used 215 for server-initiated transactions shall be non-zero when BFCP is used 216 over unreliable transports, and this qualification shall be described 217 in the updated Section 8. 219 The values below should be appended to the end of Table 1: BFCP 220 primitives. 222 +-------+-----------------------+-----------------------------------+ 223 | Value | Primitive | Direction | 224 +-------+-----------------------+-----------------------------------+ 225 | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | 226 | 15 | ErrorAck | P -> S ; Ch -> S | 227 | 16 | FloorStatusAck | P -> S ; Ch -> S | 228 | 17 | Goodbye | P -> S ; Ch -> S ; S -> P ; S -> | 229 | | | Ch | 230 | 18 | GoodbyeAck | P -> S ; Ch -> S ; S -> P ; S -> | 231 | | | Ch | 232 +-------+-----------------------+-----------------------------------+ 234 Table 1: BFCP primitives 236 3.4. ERROR-CODE (5.2.6) 238 The value below should be appended to the end of Table 5: Error Code 239 meaning. 241 +-------+-------------------------+ 242 | Value | Meaning | 243 +-------+-------------------------+ 244 | 10 | Unable to parse message | 245 +-------+-------------------------+ 247 Table 2: Error Code meaning 249 3.5. FloorRequestStatusAck (5.3.14) 251 This new subsection should be added to specify the normative ABNF for 252 the new primitive, FloorRequestStatusAck. 254 Floor participants and chairs acknowledge the receipt of a 255 FloorRequestStatus message from the floor control server when 256 communicating over unreliable transport. The following is the 257 format of the FloorRequestStatusAck message: 259 FloorRequestStatusAck = (COMMON-HEADER) 260 *[EXTENSION-ATTRIBUTE] 262 Figure 2: FloorRequestStatusAck format 264 3.6. ErrorAck (5.3.15) 266 This new subsection should be added to specify the normative ABNF for 267 the new primitive, ErrorAck. 269 Floor participants and chairs acknowledge the receipt of an Error 270 message from the floor control server when communicating over 271 unreliable transport. The following is the format of the ErrorAck 272 message: 274 ErrorAck = (COMMON-HEADER) 275 *[EXTENSION-ATTRIBUTE] 277 Figure 3: ErrorAck format 279 3.7. FloorStatusAck (5.3.16) 281 This new subsection should be added to specify the normative ABNF for 282 the new primitive, FloorStatusAck. 284 Floor participants and chairs acknowledge the receipt of a 285 FloorStatus message from the floor control server when 286 communicating over unreliable transport. The following is the 287 format of the FloorStatusAck message: 289 FloorStatusAck = (COMMON-HEADER) 290 *[EXTENSION-ATTRIBUTE] 292 Figure 4: FloorStatusAck format 294 3.8. Goodbye (5.3.17) 296 This new subsection should be added to specify the normative ABNF for 297 the new primitive, Goodbye. 299 BFCP entities that wish to dissociate themselves from their remote 300 participant do so through the transmission of a Goodbye. The 301 following is the format of the Goodbye message: 303 Goodbye = (COMMON-HEADER) 304 *[EXTENSION-ATTRIBUTE] 306 Figure 5: Goodbye format 308 3.9. GoodbyeAck (5.3.18) 310 This new subsection should be added to specify the normative ABNF for 311 the new primitive, GoodbyeAck. 313 BFCP entities communicating over an unreliable transport should 314 acknowledge the receipt of a Goodbye message from a peer. The 315 following is the format of the GoodbyeAck message: 317 GoodbyeAck = (COMMON-HEADER) 318 *[EXTENSION-ATTRIBUTE] 320 Figure 6: GoodbyeAck format 322 3.10. Transport (6) 324 Much of the existing text remains but demoted to become subsection 325 6.1. This draft recommends an additional behaviour for entities 326 participating in communication over a reliable transport that either 327 wish to leave or are asked to leave an established BFCP connection, 328 as detailed in the revised section introduction text below. 330 Note: The UDP fragmentation handling issue is still unfinished as it 331 is felt that the document should allow a mechanism for messages that 332 can grow significantly (e.g. UserStatus) to be split into separate 333 additive messages. 335 The transport over which BFCP entities exchange messages depends 336 on how clients obtain information to contact the floor control 337 server (e.g., using an SDP pffer/answer exchange [RFC4583]). Two 338 transports are supported: TCP, appropriate where entities can be 339 sure that their connectivity is not impeded by NAT devices, media 340 relays or firewalls; and UDP for those deployments where TCP may 341 not be applicable or appropriate. 343 If a client wishes to end its BFCP association with a floor 344 control server, it is RECOMMENDED that the client send a Goodbye 345 message to dissociate itself from any allocated resources. If a 346 floor control server wishes to end its BFCP association with a 347 client (e.g., the Focus of the conference informs the floor 348 control server that the client has been kicked out from the 349 conference), it is RECOMMENDED that the floor control server send 350 a Goodbye message towards the client. 352 3.11. Reliable transport (6.1) 354 BFCP entities may elect to exchange BFCP messages using TCP 355 connections. TCP provides an in-order reliable delivery of a stream 356 of bytes. Consequently, message framing is implemented in the 357 application layer. BFCP implements application-layer framing using 358 TLV-encoded attributes. 360 A client MUST NOT use more than one TCP connection to communicate 361 with a given floor control server within a conference. Nevertheless, 362 if the same physical box handles different clients (e.g., a floor 363 chair and a floor participant), which are identified by different 364 User IDs, a separate connection per client is allowed. 366 If a BFCP entity (a client or a floor control server) receives data 367 that cannot be parsed, the entity MUST close the TCP connection, and 368 the connection SHOULD be reestablished. Similarly, if a TCP 369 connection cannot deliver a BFCP message and times out, the TCP 370 connection SHOULD be reestablished. 372 The way connection reestablishment is handled depends on how the 373 client obtains information to contact the floor control server. Once 374 the TCP connection is reestablished, the client MAY resend those 375 messages for which it did not get a response from the floor control 376 server. 378 If a floor control server detects that the TCP connection towards one 379 of the floor participants is lost, it is up to the local policy of 380 the floor control server what to do with the pending floor requests 381 of the floor participant. In any case, it is RECOMMENDED that the 382 floor control server keep the floor requests (i.e., that it does not 383 cancel them) while the TCP connection is reestablished. 385 To maintain backwards compatability with older implementations of 387 [RFC4583], BFCP entities MUST interpret the graceful close of their 388 TCP connection from their associated participant as an implicit 389 Goodbye message. 391 3.12. Unreliable transport (6.2) 393 BFCP entities may elect to exchange BFCP messges using UDP datagrams. 394 UDP is an unreliable transport where neither delivery nor delivery 395 order is assured. At most one BFCP message shall be conveyed per 396 datagram. The message format for exchange of BFCP in UDP datagrams 397 is the same as for a TCP stream above. 399 Clients MUST announce their presence to the floor control server by 400 tranmission of a Hello message. This Hello message MUST be responded 401 to with a HelloAck message and only upon receipt can the client 402 consider the floor control service as present and available. 404 As described in [Section 8], each request sent by a floor participant 405 or chair shall form a client transaction that expects an 406 acknowledgement message back from the floor control server within a 407 retransmission window. Concordantly, messages sent by the floor 408 control server that are not transaction-completing (e.g. FloorStatus 409 announcements as part of a FloorQuery subscription) are server- 410 initiated transactions that require acknowledgement messages from the 411 floor participant and chair entities to which they were sent. 413 If a BFCP entity receives data that cannot be parsed, the receiving 414 participant MAY send an Error message with parameter value 10 415 indicating receipt of a malformed message. If the message can be 416 parsed to the extent that it is able to discern that it was a 417 response to an outstanding request transaction, the client MAY 418 discard the message and await retransmission. BFCP entities 419 receiving an Error message with value 10 SHOULD acknowledge the error 420 and act accordingly. 422 Transaction ID values are non-sequential and entities are at liberty 423 to select values at random. Entities MUST only have at most one 424 outstanding request transaction at any one time. Implicit 425 subscriptions, such as FloorRequest messages that have multiple 426 responses as the floor control server processes intermediate states 427 until Granted or Denied terminal states attained, can be 428 characterised by a client-initiated request transaction whose 429 acknowledgement is implied by the first FloorRequestStatus response 430 from the floor control server. The subsequent changes in state for 431 the request are new transactions whose Transaction ID is determined 432 by the floor control server and whose receipt by the client 433 participant shall be acknowledged with a FloorRequestStatusAck 434 message. 436 By restricting participants to having at most one pending transaction 437 open, the out-of-order receipt of messages is mitigated. A server- 438 initiated request (e.g., a FloorStatusRequest with an update from the 439 floor control server) received by a participant before the initial 440 FloorRequestStatus message that closes the client-initiated 441 transaction that was instigated by the FloorRequest clearly 442 supercedes the information conveyed in the delinquent response. As 443 the floor control server cannot send a second update to the implicit 444 floor status subscription until the first is acknowledged, ordinality 445 is maintained. 447 BFCP entities SHOULD ensure that their messages are smaller than the 448 recommended MTU size of 1300 bytes when encoded to minimise 449 likelihood of fragmentation en route to their peer entity. 451 If a BFCP entity receives an ICMP port unreachable message mid- 452 conversation, the entity SHOULD treat the conversation as closed 453 (e.g., an implicit Goodbye message from the peer) and behave 454 accordingly. The entity MAY attempt to re-establish the conversation 455 afresh. The new connection will appear as a wholly new floor 456 participant, chair or floor control server with all state previously 457 held about that participant lost. 459 Note: This is because the peer entities cannot rely on IP and port 460 tuple to uniquely identify the participant, nor would extending Hello 461 to include an attribute that advertised what the entity previously 462 was assigned as a User ID be acceptable due to session hijacking. 464 In deployments where NAT appliances, firewalls or other such devices 465 are present and affecting port reachability for each entity, peer 466 connectivity checks, relay use and NAT pinhole maintenance SHALL be 467 achieved through the mechanisms defined in [I-D.ietf-mmusic-ice]. 469 4. Lower-Layer Security (7) 471 For review in future revisions of this draft, per Section 7. 473 5. Protocol Transactions (8) 475 The final clause of the introduction to section 8 shall be changed to 476 read: 478 Since they do not trigger any response, their Transaction ID is 479 set to 0 when used over reliable transports, but must be non-zero 480 and unique in the context of outstanding transactions over 481 unreliable transports. 483 When using BFCP over unreliable transports, all requests will use 484 retransmit timer T1 (see Section 5.2) until the transaction is 485 completed. 487 5.1. Server Behavior (8.2) 489 The final clause of this section shall be changed to read: 491 Server-initiated transactions MUST contain a Transaction ID equal 492 to 0 when BFCP is used over reliable transports. Over unreliable 493 transport, the Transaction ID shall have the same properties as 494 for client-initiated transactions: the server MUST set the 495 Transaction ID value in the common header to a number that is 496 different from 0 and that MUST NOT be reused in another message 497 from the server until the appropriate response from the client is 498 received for the transaction. The server uses the Transaction ID 499 value to match this message with the response from the floor 500 participant or floor chair. 502 5.2. Timers (8.3) 504 New section: 506 When BFCP entities are communicating over an unreliable transport, 507 two retransmission timers are employed to help mitigate against 508 loss of datagrams. Retransmission and response caching are not 509 required when BFCP entities communicate over reliable transports. 511 5.2.1. Request retransmission timer, T1 (8.3.1) 513 T1 is a timer that schedules retransmission of a request until an 514 appropriate response is received or until the maximum number of 515 retransmissions have occurred. The timer doubles on each re- 516 transmit, failing after three unacknowledged transmission attempts. 518 If a valid respone is not received for a client- or server-initiated 519 transaction, the implementation MUST consider the BFCP association as 520 failed. Implementations SHOULD follow the reestablishment procedure 521 described in section 6 (e.g. initiate a new offer/answer [RFC3264] 522 exchange). Alternatively, they MAY continue without BFCP and 523 therefore not be participant in any floor control actions. 525 5.2.2. Response retransmission timer, T2 (8.3.2) 527 T2 is a timer that, when fires, signals that the BFCP entity can 528 release knowledge of the transaction against which it is running. It 529 is started upon the first transmission of the response to a request 530 and is the only mechanism by which that response is released by the 531 BFCP entity. Any subsequent retransmissions of the same request can 532 be responded to by replaying the cached response, whilst that value 533 is retained until the timer has fired. 535 T2 shall be set such that it encompasses all legal retransmissions 536 per T1 plus a factor to accommodate network latency between BFCP 537 entities. 539 5.2.3. Timer values (8.3.3) 541 The table below defines the different timers required when BFCP 542 entities communicate over an unreliable transport. 544 +-------+--------------------------------------+---------+ 545 | Timer | Description | Value/s | 546 +-------+--------------------------------------+---------+ 547 | T1 | Initial request retransmission timer | 0.5s | 548 | T2 | Response retransmission timer | 10s | 549 +-------+--------------------------------------+---------+ 551 Table 3: Timers 553 5.3. Receiving a response [to a FloorRequest Message] (10.1.2) 555 Prepend the sentence below at the start of this subsection: 557 When communicating over unreliable transport and upon receiving a 558 FloorRequest from a participant, the floor control server MUST 559 respond with a FloorRequestStatus message within the transaction 560 failure window to complete the transaction. 562 5.4. Receiving a response [to a FloorRelease Message] (10.2.2) 564 Prepend the sentence below at the start of this subsection: 566 When communicating over unreliable transport and upon receiving a 567 FloorRelease from a participant, the floor control server MUST 568 respond with a FloorRequestStatus message within the transaction 569 failure window to complete the transaction. 571 5.5. Receiving a response [to a ChairAction Message] (11.2) 573 Prepend the sentence below at the start of this subsection: 575 When communicating over unreliable transport and upon receiving a 576 ChairAction from a participant, the floor control server MUST 577 respond with a ChairActionAck message within the transaction 578 failure window to complete the transaction. 580 5.6. Receiving a response [to a FloorQuery Message] (12.1.2) 582 Prepend the sentence below at the start of this subsection: 584 When communicating over unreliable transport and upon receiving a 585 FloorQuery from a participant, the floor control server MUST 586 respond with a FloorStatus message within the transaction failure 587 window to complete the transaction. 589 5.7. Receiving a response [to a FloorRequestQuery Message] (12.2.2) 591 Prepend the sentence below at the start of this subsection: 593 When communicating over unreliable transport and upon receiving a 594 FloorRequestQuery from a participant, the floor control server 595 MUST respond with a FloorRequestStatus message within the 596 transaction failure window to complete the transaction. 598 5.8. Receiving a response [to a UserQuery Message] (12.3.2) 600 Prepend the sentence below at the start of this subsection: 602 When communicating over unreliable transport and upon receiving a 603 UserQuery from a participant, the floor control server MUST 604 respond with a UserStatus message within the transaction failure 605 window to complete the transaction. 607 5.9. Receiving a response [to a Hello Message] (12.4.2) 609 Prepend the sentence below at the start of this subsection: 611 When communicating over unreliable transport and upon receiving a 612 Hello from a participant, the floor control server MUST respond 613 with a HelloAck message within the transaction failure window to 614 complete the transaction. 616 5.10. Reception of a FloorRequestStatus Message (13.1.3) 618 The sentence below shall appear as a new subsection: 620 When communicating over unreliable transport and upon receiving a 621 FloorRequestStatus message from a floor control server, the 622 participant MUST respond with a FloorRequestStatusAck message 623 within the transaction failure window to complete the transaction. 625 5.11. Reception of a FloorStatus Message (13.5.3) 627 The sentence below shall appear as a new subsection: 629 When communicating over unreliable transport and upon receiving a 630 FloorStatus message from a floor control server, the participant 631 MUST respond with a FloorStatusAck message within the transaction 632 failure window to complete the transaction. 634 5.12. Reception of an Error Message (13.8.1) 636 The sentence below shall appear as a new subsection: 638 When communicating over unreliable transport and upon receiving an 639 Error message from a floor control server, the participant MUST 640 respond with a ErrorAck message within the transaction failure 641 window to complete the transaction. 643 5.13. Security Considerations (14) 645 It is a requirement that the extension of BFCP for unreliable 646 transports shall not introduce any new threats. 648 Note: work is currently underway investigating the adoption of DTLS 649 as an appropriate transport mechanism for BFCP. 651 5.14. IANA Considerations - Primitive Subregistry (15.2) 653 This section instructs the IANA to register the following new values 654 for the BFCP primitive subregistry. 656 +-------+-----------------------+-----------+ 657 | Value | Primitive | Reference | 658 +-------+-----------------------+-----------+ 659 | 14 | FloorRequestStatusAck | RFC[XXXX] | 660 | 15 | ErrorAck | RFC[XXXX] | 661 | 16 | FloorStatusAck | RFC[XXXX] | 662 | 17 | Goodbye | RFC[XXXX] | 663 | 18 | GoodbyeAck | RFC[XXXX] | 664 +-------+-----------------------+-----------+ 666 Table 4: BFCP primitive subregistry 668 5.15. IANA Considerations - Error Code Subregistry (15.4) 670 This section instructs the IANA to register the following new values 671 for the BFCP Error Code subregistry. 673 +-------+-------------------------+-----------+ 674 | Value | Meaning | Reference | 675 +-------+-------------------------+-----------+ 676 | 10 | Unable to parse message | RFC[XXXX] | 677 +-------+-------------------------+-----------+ 679 Table 5: BFCP Error Code subregistry 681 5.16. Example call flows for BFCP over Unreliable Transports (Appendix 682 A) 684 (Note: This is a new appendix to [RFC4582].) 686 With reference to Section 4.1, the following figures show 687 representative call-flows for requesting and releasing a floor, and 688 obtaining status information about a floor when BFCP is deployed over 689 an unreliable transport. The figures here show a loss-less 690 interaction. 692 Note: A future version of this draft will show an example with lost 693 packets due to unreliable transport. 695 Floor Participant Floor Control 696 Server 697 |(1) FloorRequest | 698 |Transaction ID: 123 | 699 |User ID: 234 | 700 |FLOOR-ID: 543 | 701 |---------------------------------------------->| 702 | | 703 |(2) FloorRequestStatus | 704 |Transaction ID: 123 | 705 |User ID: 234 | 706 |FLOOR-REQUEST-INFORMATION | 707 | Floor Request ID: 789 | 708 | OVERALL-REQUEST-STATUS | 709 | Request Status: Pending | 710 | FLOOR-REQUEST-STATUS | 711 | Floor ID: 543 | 712 |<----------------------------------------------| 713 | | 714 |(3) FloorRequestStatus | 715 |Transaction ID: 4098 | 716 |User ID: 234 | 717 |FLOOR-REQUEST-INFORMATION | 718 | Floor Request ID: 789 | 719 | OVERALL-REQUEST-STATUS | 720 | Request Status: Accepted | 721 | Queue Position: 1st | 722 | FLOOR-REQUEST-STATUS | 723 | Floor ID: 543 | 724 |<----------------------------------------------| 725 | | 726 |(4) FloorRequestStatusAck | 727 |Transaction ID: 4098 | 728 |User ID: 234 | 729 |---------------------------------------------->| 730 | | 731 |(5) FloorRequestStatus | 732 |Transaction ID: 4130 | 733 |User ID: 234 | 734 |FLOOR-REQUEST-INFORMATION | 735 | Floor Request ID: 789 | 736 | OVERALL-REQUEST-STATUS | 737 | Request Status: Granted | 738 | FLOOR-REQUEST-STATUS | 739 | Floor ID: 543 | 740 |<----------------------------------------------| 741 | | 742 |(6) FloorRequestStatusAck | 743 |Transaction ID: 4130 | 744 |User ID: 234 | 745 |---------------------------------------------->| 746 | | 747 |(7) FloorRelease | 748 |Transaction ID: 154 | 749 |User ID: 234 | 750 |FLOOR-REQUEST-ID: 789 | 751 |---------------------------------------------->| 752 | | 753 |(8) FloorRequestStatus | 754 |Transaction ID: 154 | 755 |User ID: 234 | 756 |FLOOR-REQUEST-INFORMATION | 757 | Floor Request ID: 789 | 758 | OVERALL-REQUEST-STATUS | 759 | Request Status: Released | 760 | FLOOR-REQUEST-STATUS | 761 | Floor ID: 543 | 762 |<----------------------------------------------| 764 Figure 7: Requesting and releasing a floor 766 Note that in Figure 7, the FloorRequestStatus message from the floor 767 control server to the floor participant is a transaction-closing 768 message as a response to the client-initiated transaction with 769 Transaction ID 154. It does not and SHOULD NOT be followed by a 770 FloorRequestStatusAck message from the floor participant to the floor 771 control server. 773 Floor Participant Floor Control 774 Server 775 |(1) FloorQuery | 776 |Transaction ID: 257 | 777 |User ID: 234 | 778 |FLOOR-ID: 543 | 779 |---------------------------------------------->| 780 | | 781 |(2) FloorStatus | 782 |Transaction ID: 257 | 783 |User ID: 234 | 784 |FLOOR-ID:543 | 785 |FLOOR-REQUEST-INFORMATION | 786 | Floor Request ID: 764 | 787 | OVERALL-REQUEST-STATUS | 788 | Request Status: Accepted | 789 | Queue Position: 1st | 790 | FLOOR-REQUEST-STATUS | 791 | Floor ID: 543 | 792 | BENEFICIARY-INFORMATION | 793 | Beneficiary ID: 124 | 794 |FLOOR-REQUEST-INFORMATION | 795 | Floor Request ID: 635 | 796 | OVERALL-REQUEST-STATUS | 797 | Request Status: Accepted | 798 | Queue Position: 2nd | 799 | FLOOR-REQUEST-STATUS | 800 | Floor ID: 543 | 801 | BENEFICIARY-INFORMATION | 802 | Beneficiary ID: 154 | 803 |<----------------------------------------------| 804 | | 805 |(3) FloorStatus | 806 |Transaction ID: 4319 | 807 |User ID: 234 | 808 |FLOOR-ID:543 | 809 |FLOOR-REQUEST-INFORMATION | 810 | Floor Request ID: 764 | 811 | OVERALL-REQUEST-STATUS | 812 | Request Status: Granted | 813 | FLOOR-REQUEST-STATUS | 814 | Floor ID: 543 | 815 | BENEFICIARY-INFORMATION | 816 | Beneficiary ID: 124 | 817 |FLOOR-REQUEST-INFORMATION | 818 | Floor Request ID: 635 | 819 | OVERALL-REQUEST-STATUS | 820 | Request Status: Accepted | 821 | Queue Position: 1st | 822 | FLOOR-REQUEST-STATUS | 823 | Floor ID: 543 | 824 | BENEFICIARY-INFORMATION | 825 | Beneficiary ID: 154 | 826 |<----------------------------------------------| 827 | | 828 |(4) FloorStatusAck | 829 |Transaction ID: 4319 | 830 |User ID: 234 | 831 |---------------------------------------------->| 832 | | 833 |(5) FloorStatus | 834 |Transaction ID: 4392 | 835 |User ID: 234 | 836 |FLOOR-ID:543 | 837 |FLOOR-REQUEST-INFORMATION | 838 | Floor Request ID: 635 | 839 | OVERALL-REQUEST-STATUS | 840 | Request Status: Granted | 841 | FLOOR-REQUEST-STATUS | 842 | Floor ID: 543 | 843 | BENEFICIARY-INFORMATION | 844 | Beneficiary ID: 154 | 845 |<----------------------------------------------| 846 | | 847 |(6) FloorStatusAck | 848 |Transaction ID: 4392 | 849 |User ID: 234 | 850 |---------------------------------------------->| 852 Figure 8: Obtaining status information about a floor 854 6. Revision of RFC4583 856 This section details revisions to [RFC4583], the format for 857 specifying BFCP streams. The section number to which updates apply 858 are indicated in parentheses in the titles of the sub-sections below. 860 6.1. Fields in the 'm' Line (3) 862 The section shall be re-written to remove reference to the 863 exclusivity of TCP as a transport for BFCP streams. 865 1. In paragraph four, "... will initiate its TCP connection ..." 866 becomes "... will direct BFCP messages ..." 868 2. In paragraph four, delete "Since BFCP only runs on top of TCP, 869 the port is always a TCP port." 871 3. In paragraph five, we now define three new values for the 872 transport field, adding "UDP/BFCP" as the third symbol, changing 873 "former" for "first", "latter" for "second", and adding a final 874 clause defining the use of UDP/BFCP as being for when BFCP runs 875 on top of UDP 877 6.2. Security Considerations (10) 879 At this time, see Section 7. 881 6.3. Registration of SDP 'proto' values (11.1) 883 This section should be renamed now that there are more values to 884 register in the SDP parameters registry, with the following added to 885 the table: 887 +----------+-----------+ 888 | Value | Reference | 889 +----------+-----------+ 890 | UDP/BFCP | RFC[XXXX] | 891 +----------+-----------+ 893 Table 6: Value for the SDP 'proto' field 895 7. Future work 897 This draft reflects a work in progress, with at least the following 898 items to be documented and/or revised before soliciting adoption by 899 the XCON working group: 901 Secured transport Initial investigation has highlighted that the 902 previously recommended approach of re-using Hello and HelloAck 903 messages to open and maintain NAT pinholes is inadequate when 904 considering the adoption of DTLS as a transport security 905 mechanism. However, at this time insufficient work has been 906 done to confirm DTLS as a recommendation, particularly as 907 regards signaling DTLS roles, key exchange, etc. It is likely 908 that [I-D.ietf-sip-dtls-srtp-framework] will inform this 909 investigation. 911 Protocol revision Certain aspects of this draft require different 912 behaviors depending on whether a reliable or unreliable 913 transport is being used, e.g. server-initiated transactions 914 having Transaction ID 0 over reliable transports without 915 acknowledgements versus non-zero and active-unique with an 916 acknowledgement message when entities communicate over 917 unreliable transports. If we allow TCP-based implementations 918 to follow the graceful-close behaviour of [RFC4582] without 919 mandating that the Goodbye message be signaled then it would 920 not be necessary to bump the protocol version number. TCP- 921 based implementations could continue as-is, whilst UDP-based 922 implementations would be at their first version and as such no 923 backward compatible issues would be present. 925 Fragmentation It has been observed that BFCP message structures can 926 grow to be sufficiently large that they exceed the typical MTU 927 threshold for local area networks (assumed here as 1500 928 octets). For example, a FloorStatus message with multiple 929 FLOOR-REQUEST-INFORMATION attributes that contain detailed 930 STATUS-INFO in the OVERALL-REQUEST-STATUS and FLOOR-REQUEST- 931 STATUS attributes. A strategy for coping with such fragmented 932 messages is required. Currently, this is held with a broad- 933 sweeping statement of intent that implementations should 934 restrict the size of their messages. Further refinement is 935 likely required, such as an applicability statement on those 936 BFCP messages and/or attributes deemed as inappropriate for use 937 over transports where fragmentation is a concern, or further 938 protocol specification to eradicate fragmentation as an issue. 940 Example signaling flows The next revision of this draft will include 941 further example signaling exchanges over unreliable transport 942 showing updated transactions and message retransmission as a 943 visual aid and reference for implementors. 945 8. Acknowledgements 947 The team working on this draft are: Trond G. Andersen, Tom 948 Kristensen, Eoin McLeod, Geir A. Sandbakken and Mark K. Thompson at 949 TANDBERG; Alfred E. Heggestad at Telio Telecom. 951 9. Normative References 953 [I-D.ietf-mmusic-ice] 954 Rosenberg, J., "Interactive Connectivity Establishment 955 (ICE): A Protocol for Network Address Translator (NAT) 956 Traversal for Offer/Answer Protocols", 957 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 959 [I-D.ietf-mmusic-ice-tcp] 960 Perreault, S. and J. Rosenberg, "TCP Candidates with 961 Interactive Connectivity Establishment (ICE)", 962 draft-ietf-mmusic-ice-tcp-08 (work in progress), 963 October 2009. 965 [I-D.ietf-sip-dtls-srtp-framework] 966 Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 967 for Establishing an SRTP Security Context using DTLS", 968 draft-ietf-sip-dtls-srtp-framework-07 (work in progress), 969 March 2009. 971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, March 1997. 974 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 975 with Session Description Protocol (SDP)", RFC 3264, 976 June 2002. 978 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 979 Security", RFC 4347, April 2006. 981 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 982 Control Protocol (BFCP)", RFC 4582, November 2006. 984 [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format 985 for Binary Floor Control Protocol (BFCP) Streams", 986 RFC 4583, November 2006. 988 Appendix A. Changes to previous drafts 990 A.1. -01 to -02 992 1. Stepped away from changing semantics and directionality of Hello 993 and HelloAck messages for pinhole establishment and keep-alive in 994 favour of ICE toolset, particularly as this would have not 995 resolved connectivity establishment as a precursor to deployment 996 of DTLS [RFC4347] as a transport security mechansim. 998 2. Change to COMMON-HEADER to reserve bit-16 of Transaction ID to 999 show originator of transaction such that request/response and 1000 response/acknowledgement mapping can be maintained without 1001 colliding randomly chosen Transaction IDs. This also avoids a 1002 three-way handshake scenario around FloorRequest where the 1003 implicit acknowledgement (in FloorRequestStatus) might also be 1004 interpreted as a transaction openening request on the part of the 1005 floor control server. 1007 3. Defined additional timer (T2) to soak up lost responses without 1008 additional processing. 1010 4. Restricted outstanding transactions to only one in-flight per 1011 direction at any one time to mitigate re-ordering issues. 1013 5. Defined entity behaviour when transactions timeout. 1015 6. Specified initial suggestion for how to minimise fragmentation of 1016 messages. 1018 7. Removed consideration of TCP-over-UDP after internal review. 1020 8. Re-stated DTLS as likely preferred mechanism of securing 1021 transport, although this investigation is on-going. 1023 A.2. -00 to -01 1025 1. Refactored to a format that represents explicit changes to base 1026 RFCs. 1028 2. Introduction of issues currently under investigation that 1029 preclude adoption. 1031 3. Specified retransmission timer for requests. 1033 Authors' Addresses 1035 Mark K. Thompson (editor) 1036 TANDBERG 1037 Philip Pedersens vei 22 1038 N-1366 Lysaker 1039 Norway 1041 Phone: +44-118-934-8711 1042 Email: mark.thompson@tandberg.com 1043 URI: http://www.tandberg.com/ 1044 Tom Kristensen 1045 TANDBERG 1047 Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no 1049 Geir A. Sandbakken 1050 TANDBERG 1052 Email: geir.sandbakken@tandberg.com 1054 Trond G. Andersen 1055 TANDBERG 1057 Email: trond.andersen@tandberg.com 1059 Eoin McLeod 1060 TANDBERG 1062 Email: eoin.mcleod@tandberg.com