Network Working Group M. Thompson, Ed. Internet-Draft T. Kristensen Updates: 4582, 4583 G. Sandbakken (if approved) T. Andersen Intended status: Standards Track TANDBERG Expires: April 26, 2010 October 23, 2009 Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport draft-sandbakken-xcon-bfcp-udp-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Thompson, et al. Expires April 26, 2010 [Page 1]
Internet-Draft BFCP-Unreliable October 2009 Abstract This memo extends the Binary Floor Control Protocol (BFCP) for use over an unreliable transport. It details a set of revisions to the protocol definition document and the specification of BFCP streams in the Session Description Protocol (SDP). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Revision of RFC4582 . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview of Operation (4) . . . . . . . . . . . . . . . . 4 2.2. Floor Participant to Floor Control Server Interface (4.1) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. COMMON-HEADER Format (5.1) . . . . . . . . . . . . . . . . 5 2.4. Hello (5.3.11) . . . . . . . . . . . . . . . . . . . . . . 5 2.5. FloorRequestStatusAck (5.3.14) . . . . . . . . . . . . . . 6 2.6. ErrorAck (5.3.15) . . . . . . . . . . . . . . . . . . . . 6 2.7. FloorStatusAck (5.3.16) . . . . . . . . . . . . . . . . . 6 2.8. Transport (6) . . . . . . . . . . . . . . . . . . . . . . 6 2.8.1. Unreliable transport (6.2) . . . . . . . . . . . . . . 7 2.9. Lower-Layer Security (7) . . . . . . . . . . . . . . . . . 7 2.10. Protocol Transactions (8) . . . . . . . . . . . . . . . . 7 2.10.1. Server Behavior (8.2) . . . . . . . . . . . . . . . . 7 2.10.2. Timers (8.3) . . . . . . . . . . . . . . . . . . . . . 8 2.11. Receiving a response [to a FloorRequest Message] (10.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.12. Receiving a response [to a FloorRelease Message] (10.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.13. Receiving a response [to a ChairAction Message] (11.2) . . 9 2.14. Receiving a response [to a FloorQuery Message] (12.1.2) . 9 2.15. Receiving a response [to a FloorRequestQuery Message] (12.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.16. Receiving a response [to a UserQuery Message] (12.3.2) . . 9 2.17. Receiving a response [to a Hello Message] (12.4.2) . . . . 9 2.18. Reception of a FloorRequestStatus Message (13.1.3) . . . . 10 2.19. Reception of a FloorStatus Message (13.5.3) . . . . . . . 10 2.20. Reception of an Error Message (13.8.1) . . . . . . . . . . 10 2.21. Security Considerations (14) . . . . . . . . . . . . . . . 10 2.22. IANA Considerations - Primitive Subregistry (15.2) . . . . 10 3. Revision of RFC4583 . . . . . . . . . . . . . . . . . . . . . 11 3.1. Fields in the 'm' Line (3) . . . . . . . . . . . . . . . . 11 3.2. Security Considerations (10) . . . . . . . . . . . . . . . 11 3.3. Registration of SDP 'proto' values (11.1) . . . . . . . . 11 4. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Thompson, et al. Expires April 26, 2010 [Page 2]
Internet-Draft BFCP-Unreliable October 2009 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Thompson, et al. Expires April 26, 2010 [Page 3]
Internet-Draft BFCP-Unreliable October 2009 1. Introduction The motivation for using unreliable transports for BFCP [RFC4582] messages is fuelled by network deployments where RTP proxies are present for NAT and firewall traversal. In these deployments, TCP may neither be applicable nor appropriate, for example, due to lack of support for TCP media relay or ICE-TCP [I-D.ietf-mmusic-ice-tcp]. This memo extends the BFCP protocol to support unreliable transport. Minor changes to the transaction model are introduced in that all requests now have an appropriate response to complete the transaction. The requests are sent with a retransmit timer associated with the response to achieve reliability. The draft also defines a mechanism to ensure bi-directional opening of pin-holes with appropriate keep-alive mechanism needed to keep those bindings available. The intension is not to change the semantics of BFCP, but to present a trivial and workable extension that permits UDP as a transport. Existing implementations in the spirit of the approach detailed in -00 of this draft have demonstrated the approach to be feasible. The purpose of this document is to formalise the deviations from the baseline specification enabling interoperability between implementations. The content of this draft relates to the BFCP protocol specification [RFC4582] and the format for the specification of BFCP streams in the SDP [RFC4583]. This memo is written with the goal of being incorporated into an upcoming revision of those documents without requiring additional protocol and stream specification documents. This draft is not recommended for adoption as an XCON working group item at this time owing to the outstanding work detailed in Section 4, but is submitted for information and discussion within the XCON community. 2. Revision of RFC4582 This section details revisions to [RFC4582], the base protocol specification of BFCP. The section number to which updates apply are indicated in parentheses in the titles of the sub-sections below. 2.1. Overview of Operation (4) Fourth paragraph, final sentence change: Thompson, et al. Expires April 26, 2010 [Page 4]
Internet-Draft BFCP-Unreliable October 2009 Over reliable transports, server-initiated transactions consist of a single message, whose Transaction ID is 0, from the floor control server to a client. Over unreliable transports, the Transaction ID must be non-zero and unique in the context of outstanding Transaction ID numbers used toward that particular client from the floor control server. Clients shall respond with the appropriate transaction-closing response message with the same Transaction ID. 2.2. Floor Participant to Floor Control Server Interface (4.1) Ninth paragraph (page 11), replace "ID is 0" in first clause with: ... ID is 0 when communicating over reliable transports, non-zero and unique in the context of outstanding floor control server to client transactions otherwise. Caption of Figure 3 on page 13 should be updated to reflect that this call flow is over reliable transport, hence the Transaction ID of 0. 2.3. COMMON-HEADER Format (5.1) The values below should be appended to the end of Table 1: BFCP primitives.[c_Version] +-------+-----------------------+------------------+ | Value | Primitive | Direction | +-------+-----------------------+------------------+ | 14 | FloorRequestStatusAck | P -> S ; Ch -> S | | 15 | ErrorAck | P -> S ; Ch -> S | | 16 | FloorStatusAck | P -> S ; Ch -> S | +-------+-----------------------+------------------+ Table 1: BFCP primitives Further, the description of Transaction ID should have the final clause deleted with the reference to Section 8 remaining. The value used for server-initiated transactions shall be non-zero when BFCP is used over unreliable transports, and this qualification shall be described in the updated Section 8. 2.4. Hello (5.3.11) This sentence below should be inserted between the two sentences that open this subsection: Thompson, et al. Expires April 26, 2010 [Page 5]
Internet-Draft BFCP-Unreliable October 2009 Over unreliable transports, the floor control servers shall also use the Hello message to check the liveness and open any NAT pinholes as a direct consequence on the path between themselves and the floor participants and floor chairs (See Section 2.8.1). 2.5. FloorRequestStatusAck (5.3.14) This new subsection should be added to specify the normative ABNF for the new primitive, FloorRequestStatusAck. FloorRequestStatusAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE] Figure 1: FloorRequestStatusAck format 2.6. ErrorAck (5.3.15) This new subsection should be added to specify the normative ABNF for the new primitive, ErrorAck. ErrorAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE] Figure 2: ErrorAck format 2.7. FloorStatusAck (5.3.16) This new subsection should be added to specify the normative ABNF for the new primitive, FloorStatusAck. FloorStatusAck = (COMMON-HEADER) *[EXTENSION-ATTRIBUTE] Figure 3: FloorStatusAck format 2.8. Transport (6) The existing text should be demoted to become subsection 6.1 re- titled appropriately with suitable text added as introduction to section 6 (to follow in a later revision of this draft). The discussion around identification of flows remains valid over both Thompson, et al. Expires April 26, 2010 [Page 6]
Internet-Draft BFCP-Unreliable October 2009 transport types and there is no proposal to change the failure behavior of TCP connections over which errors have been received. A new subsection 6.2 should be added with details of the use of BFCP over unreliable transport, thus: 2.8.1. Unreliable transport (6.2) TBD. This section shall detail characteristics and consequences of transmission of BFCP messages using UDP flows, including use of Transaction ID to track request/response pairs, how to handle ICMP port unreachable failures mid-flow, and further issues as needed. This section should also detail how NAT pinholes can be opened to cater for scenarios where either or both participants are behind restrictive NATs and therefore not port-reachable. It is proposed that the Hello message be re-appropriated for use by the floor control server as well as the existing use by floor participants and floor chairs. An initial Hello should be sent by all participants using the Timer A as defined in Section 2.10.2. After a HelloAck has been received by all participants, the client must continue to send Hello every 30 seconds for keep alive (Timer B). The floor control server should not send further Hello messages after the initial exchange. 2.9. Lower-Layer Security (7) For review in future revisions of this draft, per Section 4. 2.10. Protocol Transactions (8) The final clause of the introduction to section 8 shall be changed to read: Since they do not trigger any response, their Transaction ID is set to 0 when used over reliable transports, but must be non-zero and unique in the context of outstanding transactions over unreliable transports. When using BFCP over unreliable transports, all requests will use retransmit timer A (see Section 2.10.2) until the transaction is completed. 2.10.1. Server Behavior (8.2) The final clause of this section shall be changed to read: Thompson, et al. Expires April 26, 2010 [Page 7]
Internet-Draft BFCP-Unreliable October 2009 Server-initiated transactions MUST contain a Transaction ID equal to 0 when BFCP is used over reliable transports. Over unreliable transport, the Transaction ID shall have the same properties as for client-initiated transactions: the server MUST set the Transaction ID value in the common header to a number that is different from 0 and that MUST NOT be reused in another message from the server until the appropriate response from the client is received for the transaction. The server uses the Transaction ID value to match this message with the response from the floor participant or floor chair. 2.10.2. Timers (8.3) When an unreliable transport is used, Timer A shall be used as a retransmit timer by which a request is retransmitted until an appropriate response is received or until the maximum number of retransmissions have occurred. Timer A doubles on each re-transmit, starting at 500ms and failing after three unsuccessful retransmission attempts. That is, intervals of 500ms, 1s and 2s, with a total transaction window of 7.5s (The cumulation of retry periods plus double the value of Timer A after the last permitted retransmission). If a valid respone is not received for a client or server initiated transaction, the implementation MUST consider the BFCP stream as failed and follow the connection reestablishment as described in section 6 (e.g. initiate a new offer/answer [RFC3264] exchange). 2.11. Receiving a response [to a FloorRequest Message] (10.1.2) Prepend the sentence below at the start of this subsection: When communicating over unreliable transport and upon receiving a FloorRequest from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction. 2.12. Receiving a response [to a FloorRelease Message] (10.2.2) Prepend the sentence below at the start of this subsection: When communicating over unreliable transport and upon receiving a FloorRelease from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction. Thompson, et al. Expires April 26, 2010 [Page 8]
Internet-Draft BFCP-Unreliable October 2009 2.13. Receiving a response [to a ChairAction Message] (11.2) Prepend the sentence below at the start of this subsection: When communicating over unreliable transport and upon receiving a ChairAction from a participant, the floor control server MUST respond with a ChairActionAck message within the transaction failure window to complete the transaction. 2.14. Receiving a response [to a FloorQuery Message] (12.1.2) Prepend the sentence below at the start of this subsection: When communicating over unreliable transport and upon receiving a FloorQuery from a participant, the floor control server MUST respond with a FloorStatus message within the transaction failure window to complete the transaction. 2.15. Receiving a response [to a FloorRequestQuery Message] (12.2.2) Prepend the sentence below at the start of this subsection: When communicating over unreliable transport and upon receiving a FloorRequestQuery from a participant, the floor control server MUST respond with a FloorRequestStatus message within the transaction failure window to complete the transaction. 2.16. Receiving a response [to a UserQuery Message] (12.3.2) Prepend the sentence below at the start of this subsection: When communicating over unreliable transport and upon receiving a UserQuery from a participant, the floor control server MUST respond with a UserStatus message within the transaction failure window to complete the transaction. 2.17. Receiving a response [to a Hello Message] (12.4.2) Prepend the sentence below at the start of this subsection: When communicating over unreliable transport and upon receiving a Hello from a participant or floor control server (in the case of initial exchanges), the recipient MUST respond with a HelloAck message within the transaction failure window to complete the transaction. Thompson, et al. Expires April 26, 2010 [Page 9]
Internet-Draft BFCP-Unreliable October 2009 2.18. Reception of a FloorRequestStatus Message (13.1.3) The sentence below shall appear as a new subsection: When communicating over unreliable transport and upon receiving a FloorRequestStatus message from a floor control server, the participant MUST respond with a FloorRequestStatusAck message within the transaction failure window to complete the transaction. 2.19. Reception of a FloorStatus Message (13.5.3) The sentence below shall appear as a new subsection: When communicating over unreliable transport and upon receiving a FloorStatus message from a floor control server, the participant MUST respond with a FloorStatusAck message within the transaction failure window to complete the transaction. 2.20. Reception of an Error Message (13.8.1) The sentence below shall appear as a new subsection: When communicating over unreliable transport and upon receiving an Error message from a floor control server, the participant MUST respond with a ErrorAck message within the transaction failure window to complete the transaction. 2.21. Security Considerations (14) TBD. It is a requirement that the extension of BFCP for unreliable transports shall not introduce any new threats. 2.22. IANA Considerations - Primitive Subregistry (15.2) This section instructs the IANA to register the following new values for the BFCP primitive subregistry. +-------+-----------------------+-----------+ | Value | Primitive | Reference | +-------+-----------------------+-----------+ | 14 | FloorRequestStatusAck | RFC[XXXX] | | 15 | ErrorAck | RFC[XXXX] | | 16 | FloorStatusAck | RFC[XXXX] | +-------+-----------------------+-----------+ Table 2: BFCP primitive subregistry Thompson, et al. Expires April 26, 2010 [Page 10]
Internet-Draft BFCP-Unreliable October 2009 3. Revision of RFC4583 This section details revisions to [RFC4583], the format for specifying BFCP streams. The section number to which updates apply are indicated in parentheses in the titles of the sub-sections below. 3.1. Fields in the 'm' Line (3) The section shall be re-written to remove reference to the exclusivity of TCP as a transport for BFCP streams. 1. In paragraph four, "... will initiate its TCP connection ..." becomes "... will direct BFCP messages ..." 2. In paragraph four, delete "Since BFCP only runs on top of TCP, the port is always a TCP port." 3. In paragraph five, we now define three new values for the transport field, adding "UDP/BFCP" as the third symbol, changing "former" for "first", "latter" for "second", and adding a final clause defining the use of UDP/BFCP as being for when BFCP runs on top of UDP 3.2. Security Considerations (10) At this time, see Section 4. 3.3. Registration of SDP 'proto' values (11.1) This section should be renamed now that there are more values to register in the SDP parameters registry, with the following added to the table: +----------+-----------+ | Value | Reference | +----------+-----------+ | UDP/BFCP | RFC[XXXX] | +----------+-----------+ Table 3: Value for the SDP 'proto' field 4. Future work This draft reflects a work in progress, with at least the following items to be documented and/or revised before soliciting adoption by the XCON working group: Thompson, et al. Expires April 26, 2010 [Page 11]
Internet-Draft BFCP-Unreliable October 2009 Secured transport This revision of the draft has not addressed the security of the transport of the BFCP stream. It is likely that the recommendation will be to specify UDP/DTLS/BFCP with the same cipher set as specified in [RFC4583]. However, no such recommendation shall be made until further study is carried out regarding the impact on such an approach where participant reachability may be hindered (e.g. opening and maintenance of NAT pin-holes and the directionality of the BFCP stream). Protocol revision Certain aspects of this draft require different behaviors depending on whether a reliable or unreliable transport is being used, e.g. server-initiated transactions having Transaction ID 0 over reliable without response versus non-zero and active-unique with a confirmation message over unreliable transports. This inconsistency may be unsuitable for implementors. We may look to keeping the behavior consistent across both types of transport, which may in turn require a change of version field in the COMMON-HEADER (Section 5.1 of [RFC4582]) such that implementations can discern which behavior to use. Fragmentation It has been observed that BFCP message structures can grow to be sufficiently large that they exceed the typical MTU threshold for local area networks (assumed here as 1500 octets). For example, a FloorStatus message with multiple FLOOR-REQUEST-INFORMATION attributes that contain detailed STATUS-INFO in the OVERALL-REQUEST-STATUS and FLOOR-REQUEST- STATUS attributes. A strategy for coping with such fragmented messages is required. This may be as simple as an applicability statement on those BFCP messages and/or attributes deemed as inappropriate for use over transports where fragmentation is a concern, or it may require further protocol specification to eradicate fragmentation as an issue. UDP encapsulation of TCP An alternative suggestion for conveying BFCP streams in such network deployments as has previously motivated this work has been to investigate encapsulating the TCP stream in a UDP flow [I-D.denis-udp-transport]. Example signaling flows Future versions of this draft should include at least one example of a signaling exchange over unreliable transport showing updated transactions and message retransmission as a visual aid and reference for implementors. Thompson, et al. Expires April 26, 2010 [Page 12]
Internet-Draft BFCP-Unreliable October 2009 5. Acknowledgements The team working on this draft are: Trond G. Andersen, Tom Kristensen, Eoin McLeod, Geir A. Sandbakken and Mark K. Thompson at TANDBERG; Alfred E. Heggestad at Telio Telecom. 6. Normative References [I-D.denis-udp-transport] Denis-Courmont, R., "UDP-Encapsulated Transport Protocols", draft-denis-udp-transport-00 (work in progress), July 2008. [I-D.ietf-mmusic-ice-tcp] Perreault, S. and J. Rosenberg, "TCP Candidates with Interactive Connectivity Establishment (ICE)", draft-ietf-mmusic-ice-tcp-08 (work in progress), October 2009. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006. [RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006. Editorial Comments [c_Version] MKT: The version field may need revising in this table, also, depending on the outcome of future work. Thompson, et al. Expires April 26, 2010 [Page 13]
Internet-Draft BFCP-Unreliable October 2009 Authors' Addresses Mark K. Thompson (editor) TANDBERG Philip Pedersens vei 22 N-1366 Lysaker Norway Phone: +44-118-934-8711 Email: mark.thompson@tandberg.com URI: http://www.tandberg.com/ Tom Kristensen TANDBERG Email: tom.kristensen@tandberg.com, tomkri@ifi.uio.no Geir A. Sandbakken TANDBERG Email: geir.sandbakken@tandberg.com Trond G. Andersen TANDBERG Email: trond.andersen@tandberg.com Thompson, et al. Expires April 26, 2010 [Page 14]