Dispatch Working Group M. Thompson
Internet-Draft T. Kristensen
Updates: 4582, 4583 G. Sandbakken
(if approved) T. Andersen
Intended status: Standards Track E. McLeod
Expires: March 6, 2011 Cisco
September 2, 2010
Revision of the Binary Floor Control Protocol (BFCP) for use over an
unreliable transport
draft-sandbakken-dispatch-bfcp-udp-00
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 Session
Description Protocol (SDP) format for BFCP streams.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 6, 2011.
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Thompson, et al. Expires March 6, 2011 [Page 1]
Internet-Draft BFCP-Unreliable September 2010
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Rationale and Scope . . . . . . . . . . . . . . . . . . . . . 5
4. Revision of RFC4582 . . . . . . . . . . . . . . . . . . . . . 6
4.1. Overview of Operation (4) . . . . . . . . . . . . . . . . 6
4.2. Floor Participant to Floor Control Server Interface
(4.1) . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. COMMON-HEADER Format (5.1) . . . . . . . . . . . . . . . . 6
4.4. ERROR-CODE (5.2.6) . . . . . . . . . . . . . . . . . . . . 7
4.5. FloorRequestStatusAck (5.3.14) . . . . . . . . . . . . . . 8
4.6. ErrorAck (5.3.15) . . . . . . . . . . . . . . . . . . . . 8
4.7. FloorStatusAck (5.3.16) . . . . . . . . . . . . . . . . . 8
4.8. Goodbye (5.3.17) . . . . . . . . . . . . . . . . . . . . . 9
4.9. GoodbyeAck (5.3.18) . . . . . . . . . . . . . . . . . . . 9
4.10. Transport (6) . . . . . . . . . . . . . . . . . . . . . . 9
4.11. Reliable Transport (6.1) . . . . . . . . . . . . . . . . . 10
4.12. Unreliable Transport (6.2) . . . . . . . . . . . . . . . . 11
4.13. Lower-Layer Security (7) . . . . . . . . . . . . . . . . . 13
4.14. Protocol Transactions (8) . . . . . . . . . . . . . . . . 13
4.15. Server Behavior (8.2) . . . . . . . . . . . . . . . . . . 13
4.16. Timers (8.3) . . . . . . . . . . . . . . . . . . . . . . . 13
4.17. Request Retransmission Timer, T1 (8.3.1) . . . . . . . . . 14
4.18. Response Retransmission Timer, T2 (8.3.2) . . . . . . . . 14
4.19. Timer Values (8.3.3) . . . . . . . . . . . . . . . . . . . 14
4.20. Receiving a Response [to a FloorRequest Message]
(10.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.21. Receiving a Response [to a FloorRelease Message]
(10.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.22. Receiving a Response [to a ChairAction Message] (11.2) . . 15
4.23. Receiving a Response [to a FloorQuery Message] (12.1.2) . 15
4.24. Receiving a Response [to a FloorRequestQuery Message]
(12.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.25. Receiving a Response [to a UserQuery Message] (12.3.2) . . 16
4.26. Receiving a Response [to a Hello Message] (12.4.2) . . . . 16
4.27. Reception of a FloorRequestStatus Message (13.1.3) . . . . 16
4.28. Reception of a FloorStatus Message (13.5.3) . . . . . . . 16
4.29. Reception of an Error Message (13.8.1) . . . . . . . . . . 16
4.30. Security Considerations (14) . . . . . . . . . . . . . . . 17
4.31. IANA Considerations - Primitive Subregistry (15.2) . . . . 17
4.32. IANA Considerations - Error Code Subregistry (15.4) . . . 17
4.33. Example Call Flows for BFCP over Unreliable Transport
Thompson, et al. Expires March 6, 2011 [Page 2]
Internet-Draft BFCP-Unreliable September 2010
(Appendix A) . . . . . . . . . . . . . . . . . . . . . . . 18
5. Revision of RFC4583 . . . . . . . . . . . . . . . . . . . . . 21
5.1. Fields in the 'm' Line (3) . . . . . . . . . . . . . . . . 21
5.2. Security Considerations (10) . . . . . . . . . . . . . . . 22
5.3. Registration of SDP 'proto' Values (11.1) . . . . . . . . 22
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25
A.1. draft-sandbakken-xcon-bfcp-udp-02 to
draft-sandbakken-dispatch-bfcp-udp-00 . . . . . . . . . . 25
A.2. draft-sandbakken-xcon-bfcp-udp-01 to -02 . . . . . . . . . 26
A.3. draft-sandbakken-xcon-bfcp-udp-00 to -01 . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Thompson, et al. Expires March 6, 2011 [Page 3]
Internet-Draft BFCP-Unreliable September 2010
1. Introduction
The motivation for using an unreliable transports for BFCP [RFC4582]
messages is fuelled by network deployments where middleboxes or media
relays 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, ICE-TCP
[I-D.ietf-mmusic-ice-tcp] or a standard UDP tunneling approach. In
Section 3 the rationale for and scoping of the approach chosen in
this draft is described.
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 intention 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
earlier versions of this draft (cf. Appendix A), have demonstrated
the approach to be feasible. The purpose of this document is to
formalize the deviations from the baseline specification enabling
interoperability between implementations.
The content of this draft relates to the BFCP protocol specification
[RFC4582] and the SDP format for describing BFCP streams [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. These two future bis
drafts will also deal with known issues not related to the extensions
described in this draft.
Earlier versions of this draft was submitted to the XCON working
group. As XCON is closing the draft is now moved and associated with
the Dispatch working group. The draft is in progress and notable
remaining work is detailed in Section 6.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Thompson, et al. Expires March 6, 2011 [Page 4]
Internet-Draft BFCP-Unreliable September 2010
3. Rationale and Scope
BFCP over TCP according to [RFC4582] is used by a number of vendors
and works well in some environments. In scenarios where the floor
control server has a public IP address, the client will have no
problem establishing the TCP connection towards the server.
On the other hand, in existing, deployed video-conferencing scenarios
the floor control server will be placed behind a NAT, as the floor
control server functionality is implemented in one of the
communicating endpoints. Roles are negotiated in the offer/answer
exchange, as specified in [RFC4583], and either endpoint may end up
being the floor control server. The session between these endpoints
typically consists of a number of RTP media streams for audio and
video and the BFCP connection. NAT traversal will be a problem for
BFCP over TCP. The RTP streams works fine as ICE is used to provide
connectivity. This draft defines UDP as an alternative transport for
BFCP, this enables usage of ICE in the same fashion as for the RTP
streams and utilizing the same infrastructure.
The progress and maybe real interest in finishing the specification
of ICE-TCP has been low, the ICE-TCP draft [I-D.ietf-mmusic-ice-tcp]
is currently expired. As a new editor of the draft presented his
roadmap at IETF-78, this will hopefully change. However, the most
important reason for not embracing ICE-TCP and throwing away this
draft is the low success rate.
Another option would be to keep the current BFCP specification as is
and tunnel it over UDP. No generic, general purpose UDP tunneling
protocol is specified within the IETF. Several approaches exist as
personal internet drafts, comprising UDT [I-D.gg-udt] which has been
around for some years, the expired TCP-over-UDP (ToU)
[I-D.baset-tsvwg-tcp-over-udp] draft and GUT [I-D.manner-tsvwg-gut]
that recently was chosen for the DCCP and SCTP encapsulation work.
The authors of this draft acknowledge the arguments in favor of a
general solution to support NAT and firewall traversal of existing
TCP-based protocols. This is also in line with the recommendations
in [RFC5405]. Currently, the quite simple and straight forward
extensions for BFCP over UDP specified in this draft is believed to
represent the best way forward in order to support existing products
and deployments in a timely manner. The progress with regard to
specifying a general purpose UDP tunneling protocol and the outcome
of the re-started work on the ICE-TCP specification will be monitored
and evaluated as results are available.
Thompson, et al. Expires March 6, 2011 [Page 5]
Internet-Draft BFCP-Unreliable September 2010
4. 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.
4.1. Overview of Operation (4)
Fourth paragraph change:
There are two types of transaction in BFCP: client-initiated
transactions and server-initiated transactions. Client-initiated
transactions consist of a message from a client to the floor
control server and a response from the floor control server to the
client. Correspondingly, server-initiated transactions consist of
a message from the floor control server to a client and the
associated acknowledgement message from the client to the floor
control server. Both messages can be related because they carry
the same Transaction ID value in their common headers.
4.2. Floor Participant to Floor Control Server Interface (4.1)
Before seventh paragraph (page 9), insert:
Figures 2 and 3 below show call flows for two sample BFCP
interactions when used over reliable transport. Appendix A
(Editorial Note: here-in Section 4.33) shows the same sample
interactions but over an unreliable transport.
4.3. COMMON-HEADER Format (5.1)
The figure below should replace Figure 5: COMMON-HEADER format.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |I| Res | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: COMMON-HEADER format
The following text preceeds "Reserved" on page 15:
Thompson, et al. Expires March 6, 2011 [Page 6]
Internet-Draft BFCP-Unreliable September 2010
I: The Transaction Initiator (I) flag-bit has relevance only for
use of BFCP over unreliable media. When clear, it signifies that
the transaction was opened by the client (floor participant,
chair) and that the Transaction ID that follows has been generated
by the client; when set, the transaction is a server-initiated
transaction and the Transaction ID that follows is pertinent to
the floor control server. Where BFCP is used over reliable
transports, the flag has no significance and SHOULD be cleared.
The Reserved field changes name to Res due to limited space in the
ASCII graphic in Figure 1. In the description of the Reserved field
"the 5 bits" is changed to "the 4 bits".
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.
The values below should be appended to the end of Table 1: BFCP
primitives.
+-------+-----------------------+--------------------+
| Value | Primitive | Direction |
+-------+-----------------------+--------------------+
| 14 | FloorRequestStatusAck | P -> S ; Ch -> S |
| 15 | ErrorAck | P -> S ; Ch -> S |
| 16 | FloorStatusAck | P -> S ; Ch -> S |
| 17 | Goodbye | P -> S ; Ch -> S ; |
| | | S -> P ; S -> Ch |
| 18 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | S -> P ; S -> Ch |
+-------+-----------------------+--------------------+
Table 1: BFCP primitives
4.4. ERROR-CODE (5.2.6)
The value below should be appended to the end of Table 5: Error Code
meaning.
+-------+-------------------------+
| Value | Meaning |
+-------+-------------------------+
| 10 | Unable to parse message |
+-------+-------------------------+
Table 2: Error Code meaning
Thompson, et al. Expires March 6, 2011 [Page 7]
Internet-Draft BFCP-Unreliable September 2010
4.5. FloorRequestStatusAck (5.3.14)
This new subsection should be added to specify the normative ABNF for
the new primitive, FloorRequestStatusAck.
Floor participants and chairs acknowledge the receipt of a
FloorRequestStatus message from the floor control server when
communicating over unreliable transport. The following is the
format of the FloorRequestStatusAck message:
FloorRequestStatusAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 2: FloorRequestStatusAck format
4.6. ErrorAck (5.3.15)
This new subsection should be added to specify the normative ABNF for
the new primitive, ErrorAck.
Floor participants and chairs acknowledge the receipt of an Error
message from the floor control server when communicating over
unreliable transport. The following is the format of the ErrorAck
message:
ErrorAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 3: ErrorAck format
4.7. FloorStatusAck (5.3.16)
This new subsection should be added to specify the normative ABNF for
the new primitive, FloorStatusAck.
Floor participants and chairs acknowledge the receipt of a
FloorStatus message from the floor control server when
communicating over unreliable transport. The following is the
format of the FloorStatusAck message:
Thompson, et al. Expires March 6, 2011 [Page 8]
Internet-Draft BFCP-Unreliable September 2010
FloorStatusAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 4: FloorStatusAck format
4.8. Goodbye (5.3.17)
This new subsection should be added to specify the normative ABNF for
the new primitive, Goodbye.
BFCP entities that wish to dissociate themselves from their remote
participant do so through the transmission of a Goodbye. The
following is the format of the Goodbye message:
Goodbye = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 5: Goodbye format
4.9. GoodbyeAck (5.3.18)
This new subsection should be added to specify the normative ABNF for
the new primitive, GoodbyeAck.
BFCP entities communicating over an unreliable transport should
acknowledge the receipt of a Goodbye message from a peer. The
following is the format of the GoodbyeAck message:
GoodbyeAck = (COMMON-HEADER)
*[EXTENSION-ATTRIBUTE]
Figure 6: GoodbyeAck format
4.10. Transport (6)
Much of the existing text remains but demoted to become subsection
6.1. This draft recommends an additional behavior for entities
participating in communication over a reliable transport that either
wish to leave or are asked to leave an established BFCP connection,
as detailed in the revised section introduction text below.
The transport over which BFCP entities exchange messages depends
on how clients obtain information to contact the floor control
server (e.g. using an SDP offer/answer exchange [RFC4583]). Two
Thompson, et al. Expires March 6, 2011 [Page 9]
Internet-Draft BFCP-Unreliable September 2010
transports are supported: TCP, appropriate where entities can be
sure that their connectivity is not impeded by NAT devices, media
relays or firewalls; and UDP for those deployments where TCP may
not be applicable or appropriate.
If a client wishes to end its BFCP association with a floor
control server, it is RECOMMENDED that the client send a Goodbye
message to dissociate itself from any allocated resources. If a
floor control server wishes to end its BFCP association with a
client (e.g. the Focus of the conference informs the floor control
server that the client has been kicked out from the conference),
it is RECOMMENDED that the floor control server send a Goodbye
message towards the client.
4.11. Reliable Transport (6.1)
BFCP entities may elect to exchange BFCP messages using TCP
connections. TCP provides an in-order reliable delivery of a stream
of bytes. Consequently, message framing is implemented in the
application layer. BFCP implements application-layer framing using
TLV-encoded attributes.
A client MUST NOT use more than one TCP connection to communicate
with a given floor control server within a conference. Nevertheless,
if the same physical box handles different clients (e.g. a floor
chair and a floor participant), which are identified by different
User IDs, a separate connection per client is allowed.
If a BFCP entity (a client or a floor control server) receives data
that cannot be parsed, the entity MUST close the TCP connection, and
the connection SHOULD be reestablished. Similarly, if a TCP
connection cannot deliver a BFCP message and times out, the TCP
connection SHOULD be reestablished.
The way connection reestablishment is handled depends on how the
client obtains information to contact the floor control server. Once
the TCP connection is reestablished, the client MAY resend those
messages for which it did not get a response from the floor control
server.
If a floor control server detects that the TCP connection towards one
of the floor participants is lost, it is up to the local policy of
the floor control server what to do with the pending floor requests
of the floor participant. In any case, it is RECOMMENDED that the
floor control server keep the floor requests (i.e., that it does not
cancel them) while the TCP connection is reestablished.
To maintain backwards compatibility with older implementations of
Thompson, et al. Expires March 6, 2011 [Page 10]
Internet-Draft BFCP-Unreliable September 2010
[RFC4583], BFCP entities MUST interpret the graceful close of their
TCP connection from their associated participant as an implicit
Goodbye message.
4.12. Unreliable Transport (6.2)
BFCP entities may elect to exchange BFCP messages using UDP
datagrams. UDP is an unreliable transport where neither delivery nor
delivery order is assured. Each BFCP UDP datagram MUST contain only
one BFCP message. The message format for exchange of BFCP in UDP
datagrams is the same as for a TCP stream above.
Clients MUST announce their presence to the floor control server by
transmission of a Hello message. This Hello message MUST be
responded to with a HelloAck message and only upon receipt can the
client consider the floor control service as present and available.
As described in Section 8, each request sent by a floor participant
or chair shall form a client transaction that expects an
acknowledgement message back from the floor control server within a
retransmission window. Concordantly, messages sent by the floor
control server that are not transaction-completing (e.g. FloorStatus
announcements as part of a FloorQuery subscription) are server-
initiated transactions that require acknowledgement messages from the
floor participant and chair entities to which they were sent.
If a BFCP entity receives data that cannot be parsed, the receiving
participant MAY send an Error message with parameter value 10
indicating receipt of a malformed message. If the message can be
parsed to the extent that it is able to discern that it was a
response to an outstanding request transaction, the client MAY
discard the message and await retransmission. BFCP entities
receiving an Error message with value 10 SHOULD acknowledge the error
and act accordingly.
Transaction ID values are non-sequential and entities are at liberty
to select values at random. Entities MUST only have at most one
outstanding request transaction at any one time. Implicit
subscriptions, such as FloorRequest messages that have multiple
responses as the floor control server processes intermediate states
until Granted or Denied terminal states attained, can be
characterized by a client-initiated request transaction whose
acknowledgement is implied by the first FloorRequestStatus response
from the floor control server. The subsequent changes in state for
the request are new transactions whose Transaction ID is determined
by the floor control server and whose receipt by the client
participant shall be acknowledged with a FloorRequestStatusAck
message.
Thompson, et al. Expires March 6, 2011 [Page 11]
Internet-Draft BFCP-Unreliable September 2010
By restricting entities to having at most one pending transaction
open, the out-of-order receipt of messages is mitigated. A server-
initiated request (e.g. a FloorStatus with an update from the floor
control server) received by a participant before the initial
FloorRequestStatus message that closes the client-initiated
transaction that was instigated by the FloorRequest clearly
supercedes the information conveyed in the delinquent response. As
the floor control server cannot send a second update to the implicit
floor status subscription until the first is acknowledged, ordinality
is maintained.
BFCP may be characterized to generate "low data-volume" traffic,
after the classification in [RFC5405]. Nevertheless is it necessary
to ensure suitable and necessary congestion control mechanisms are
used for BFCP over UDP. As described in previous paragraph every
entity - client or server - is only allowed to send one request at a
time, and await the acknowledging response. This way at most one
datagram is sent per RTT given the message is not lost during
transmission. In case the message is lost, the request
retransmission timer T1 specified in Section 4.17 will fire and the
message is retransmitted up to three times. The default initial
interval is set to 500ms and the interval is doubled after each
retransmission attempt, this is identical to the specification of the
T1 timer in SIP as described in Section 17.1.1.2 of [RFC3261].
BFCP entities SHOULD ensure that their messages are smaller than the
recommended MTU size of 1300 bytes when encoded to minimise
likelihood of fragmentation en route to their peer entity.
If a BFCP entity receives an ICMP port unreachable message mid-
conversation, the entity SHOULD treat the conversation as closed
(e.g. an implicit Goodbye message from the peer) and behave
accordingly. The entity MAY attempt to re-establish the conversation
afresh. The new connection will appear as a wholly new floor
participant, chair or floor control server with all state previously
held about that participant lost.
Note: This is because the peer entities cannot rely on IP and port
tuple to uniquely identify the participant, nor would extending Hello
to include an attribute that advertised what the entity previously
was assigned as a User ID be acceptable due to session hijacking.
In deployments where NAT appliances, firewalls or other such devices
are present and affecting port reachability for each entity, peer
connectivity checks, relay use and NAT pinhole maintenance SHALL be
achieved through the mechanisms defined in ICE [RFC5245].
Thompson, et al. Expires March 6, 2011 [Page 12]
Internet-Draft BFCP-Unreliable September 2010
4.13. Lower-Layer Security (7)
Add the following to the second sentence, change period ('.') with
comma:
, if transport over UDP is implemented, DTLS [RFC4347] MUST be
supported.
Editorial Note: More details needed. The DTLS details to be added
are modelled after their counterpart for RTP streams specified in
[RFC5763]. The normative text needed are either referenced or copied
across to this draft.
4.14. 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 T1 (see Section 4.16) until the transaction is
completed.
4.15. Server Behavior (8.2)
The final clause of this section shall be changed to read:
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.
4.16. Timers (8.3)
New section:
Thompson, et al. Expires March 6, 2011 [Page 13]
Internet-Draft BFCP-Unreliable September 2010
When BFCP entities are communicating over an unreliable transport,
two retransmission timers are employed to help mitigate against
loss of datagrams. Retransmission and response caching are not
required when BFCP entities communicate over reliable transports.
4.17. Request Retransmission Timer, T1 (8.3.1)
T1 is a timer that schedules retransmission of a request until an
appropriate response is received or until the maximum number of
retransmissions have occurred. The timer doubles on each re-
transmit, failing after three unacknowledged transmission attempts.
If a valid respone is not received for a client- or server-initiated
transaction, the implementation MUST consider the BFCP association as
failed. Implementations SHOULD follow the reestablishment procedure
described in section 6 (e.g. initiate a new offer/answer [RFC3264]
exchange). Alternatively, they MAY continue without BFCP and
therefore not be participant in any floor control actions.
4.18. Response Retransmission Timer, T2 (8.3.2)
T2 is a timer that, when fires, signals that the BFCP entity can
release knowledge of the transaction against which it is running. It
is started upon the first transmission of the response to a request
and is the only mechanism by which that response is released by the
BFCP entity. Any subsequent retransmissions of the same request can
be responded to by replaying the cached response, whilst that value
is retained until the timer has fired.
T2 shall be set such that it encompasses all legal retransmissions
per T1 plus a factor to accommodate network latency between BFCP
entities.
4.19. Timer Values (8.3.3)
The table below defines the different timers required when BFCP
entities communicate over an unreliable transport.
+-------+--------------------------------------+---------+
| Timer | Description | Value/s |
+-------+--------------------------------------+---------+
| T1 | Initial request retransmission timer | 0.5s |
| T2 | Response retransmission timer | 10s |
+-------+--------------------------------------+---------+
Table 3: Timers
The default value for T1 is 500 ms, this is an estimate of the RTT
Thompson, et al. Expires March 6, 2011 [Page 14]
Internet-Draft BFCP-Unreliable September 2010
for completing the transaction. T1 MAY be chosen larget, and this is
RECOMMENDED if it is known in advance that the RTT is larget.
Regardless of the value of T1, the exponential backoffs on
retransmissions described in Section 4.17 MUST be used.
4.20. 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 FloorRequestStatus message within the transaction
failure window to complete the transaction.
4.21. 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 FloorRequestStatus message within the transaction
failure window to complete the transaction.
4.22. 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.
4.23. 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.
4.24. 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
Thompson, et al. Expires March 6, 2011 [Page 15]
Internet-Draft BFCP-Unreliable September 2010
transaction failure window to complete the transaction.
4.25. 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.
4.26. 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, the floor control server MUST respond
with a HelloAck message within the transaction failure window to
complete the transaction.
4.27. 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.
4.28. 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.
4.29. 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.
Thompson, et al. Expires March 6, 2011 [Page 16]
Internet-Draft BFCP-Unreliable September 2010
4.30. Security Considerations (14)
It is a requirement that the extension of BFCP for unreliable
transports shall not introduce any new threats.
The considerations in [RFC4582] will be altered to cover TCP/TLS
connections as well as DTLS (UDP/TLS).
In addition to the RFCs mentioned for TCP and TLS connections, the
specifications for SRTP over DTLS [RFC5763] and [RFC5764] discuss
security issues in detail. Add references to them in the section.
Editorial Note: Expanded analysis and discussion will be added after
lower-layer security details is sorted out in Section 4.13.
4.31. 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] |
| 17 | Goodbye | RFC[XXXX] |
| 18 | GoodbyeAck | RFC[XXXX] |
+-------+-----------------------+-----------+
Table 4: BFCP primitive subregistry
4.32. IANA Considerations - Error Code Subregistry (15.4)
This section instructs the IANA to register the following new values
for the BFCP Error Code subregistry.
+-------+-------------------------+-----------+
| Value | Meaning | Reference |
+-------+-------------------------+-----------+
| 10 | Unable to parse message | RFC[XXXX] |
+-------+-------------------------+-----------+
Table 5: BFCP Error Code subregistry
Thompson, et al. Expires March 6, 2011 [Page 17]
Internet-Draft BFCP-Unreliable September 2010
4.33. Example Call Flows for BFCP over Unreliable Transport (Appendix
A)
(Editorial Note: This is a new appendix to [RFC4582].)
With reference to Section 4.1, the following figures show
representative call-flows for requesting and releasing a floor, and
obtaining status information about a floor when BFCP is deployed over
an unreliable transport. The figures here show a loss-less
interaction.
Editorial Note: A future version of this draft will show an example
with lost packets due to unreliable transport, as well as examples on
usage of DTLS and STUN in call the setup phase.
Floor Participant Floor Control
Server
|(1) FloorRequest |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorRequestStatus |
|Transaction ID: 123 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Pending |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(3) FloorRequestStatus |
|Transaction ID: 4098 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(4) FloorRequestStatusAck |
Thompson, et al. Expires March 6, 2011 [Page 18]
Internet-Draft BFCP-Unreliable September 2010
|Transaction ID: 4098 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorRequestStatus |
|Transaction ID: 4130 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
| |
|(6) FloorRequestStatusAck |
|Transaction ID: 4130 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(7) FloorRelease |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-ID: 789 |
|---------------------------------------------->|
| |
|(8) FloorRequestStatus |
|Transaction ID: 154 |
|User ID: 234 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 789 |
| OVERALL-REQUEST-STATUS |
| Request Status: Released |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
|<----------------------------------------------|
Figure 7: Requesting and releasing a floor
Note that in Figure 7, the FloorRequestStatus message from the floor
control server to the floor participant is a transaction-closing
message as a response to the client-initiated transaction with
Transaction ID 154. It does not and SHOULD NOT be followed by a
FloorRequestStatusAck message from the floor participant to the floor
control server.
Floor Participant Floor Control
Thompson, et al. Expires March 6, 2011 [Page 19]
Internet-Draft BFCP-Unreliable September 2010
Server
|(1) FloorQuery |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID: 543 |
|---------------------------------------------->|
| |
|(2) FloorStatus |
|Transaction ID: 257 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 2nd |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(3) FloorStatus |
|Transaction ID: 4319 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 764 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 124 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Accepted |
| Queue Position: 1st |
Thompson, et al. Expires March 6, 2011 [Page 20]
Internet-Draft BFCP-Unreliable September 2010
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(4) FloorStatusAck |
|Transaction ID: 4319 |
|User ID: 234 |
|---------------------------------------------->|
| |
|(5) FloorStatus |
|Transaction ID: 4392 |
|User ID: 234 |
|FLOOR-ID:543 |
|FLOOR-REQUEST-INFORMATION |
| Floor Request ID: 635 |
| OVERALL-REQUEST-STATUS |
| Request Status: Granted |
| FLOOR-REQUEST-STATUS |
| Floor ID: 543 |
| BENEFICIARY-INFORMATION |
| Beneficiary ID: 154 |
|<----------------------------------------------|
| |
|(6) FloorStatusAck |
|Transaction ID: 4392 |
|User ID: 234 |
|---------------------------------------------->|
Figure 8: Obtaining status information about a floor
5. Revision of RFC4583
This section details revisions to [RFC4583], the SDP format for
specifying BFCP streams. The section number to which updates apply
are indicated in parentheses in the titles of the sub-sections below.
5.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 ..."
Thompson, et al. Expires March 6, 2011 [Page 21]
Internet-Draft BFCP-Unreliable September 2010
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
5.2. Security Considerations (10)
In addition to the RFCs mentioned for TCP and TLS connections, the
specifications for SRTP over DTLS [RFC5763] and [RFC5764] discuss
security issues in detail. Add references to them in the section.
Editorial Note: Expanded analysis and discussion will be added after
lower-layer security details is sorted out in Section 4.13.
5.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] |
| UDP/TLS/BFCP | RFC[XXXX] |
+--------------+-----------+
Table 6: Value for the SDP 'proto' field
6. 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:
Adapting DTLS usage to BFCP: Currently the DTLS-SRTP specifications
[RFC5763] and [RFC5764] are referenced and used as basis for
intended BFCP usage of DTLS. Adaption to the BFCP context in
Section 4.13 will either be done by reference and noting
differences or by adding the normative specification needed to
this draft. This consideration applies to the two security
consideration sections as well, namely Section 4.30 and
Section 5.2. Adding examples on DTLS usage in the call setup
Thompson, et al. Expires March 6, 2011 [Page 22]
Internet-Draft BFCP-Unreliable September 2010
phase will provide guidance to implementors.
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 transports without
acknowledgements versus non-zero and active-unique with an
acknowledgement message when entities communicate over
unreliable transports. If we allow TCP-based implementations
to follow the graceful-close behavior of [RFC4582] without
mandating that the Goodbye message be signaled then it would
not be necessary to bump the protocol version number. TCP-
based implementations could continue as-is, whilst UDP-based
implementations would be at their first version and as such no
backward compatible issues would be present.
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. Currently, this is held with a broad-
sweeping statement of intent that implementations should
restrict the size of their messages. Further refinement might
be required, such as an applicability statement on those BFCP
messages and/or attributes deemed as inappropriate for use over
transports where fragmentation is a concern, or further
protocol specification to eradicate fragmentation as an issue.
A mechanism for splitting into additive messages might be
considered.
Example signaling flows: The next revision of this draft will
include further example signaling exchanges over unreliable
transport as a visual aid and reference for implementors.
Including updated transactions, message retransmission, usage
of DTLS during call setup and combined usage of DTLS and STUN.
7. Acknowledgements
The team working on this draft are: Trond G. Andersen, Charles Eckel,
Tom Kristensen, Eoin McLeod, Geir A. Sandbakken and Mark K. Thompson
at Cisco; Alfred E. Heggestad at Telio Telecom.
8. References
Thompson, et al. Expires March 6, 2011 [Page 23]
Internet-Draft BFCP-Unreliable September 2010
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010.
8.2. Informative References
[I-D.baset-tsvwg-tcp-over-udp]
Baset, S. and H. Schulzrinne, "TCP-over-UDP",
draft-baset-tsvwg-tcp-over-udp-01 (work in progress),
June 2009.
[I-D.gg-udt]
Gu, Y., "UDT: UDP-based Data Transfer Protocol",
draft-gg-udt-03 (work in progress), April 2010.
[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.
[I-D.manner-tsvwg-gut]
Manner, J., Varis, N., and B. Briscoe, "Generic UDP
Thompson, et al. Expires March 6, 2011 [Page 24]
Internet-Draft BFCP-Unreliable September 2010
Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in
progress), July 2010.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
Appendix A. Change History
A.1. draft-sandbakken-xcon-bfcp-udp-02 to
draft-sandbakken-dispatch-bfcp-udp-00
1. Draft name change. As XCON WG is closing this draft is submitted
to Dispatch WG as the arena of discussion.
2. Moved Transaction Identifier bit (I) from the Transaction ID to
one of the current 5 reserved bits. Keep current Transaction ID
syntax and semantics. Avoid potential problems with existing TCP
based implentations.
3. The way congestion control is taken care of is explained, with
reference to [RFC5405]. One message per RTT. Backoff and
normative behavior for timer T1 clarified.
4. Mandated support for DTLS in case unreliable transport (i.e.
UDP) is implemented. Details and examples to be included. Model
after [RFC5763], details on how to adapt the SRTP associated
details to BFCP and whether a reference or copying the text
across and changing is needed.
5. Added the Rationale and Scope section to position and explain the
motivation for this draft more in detail.
6. A number of typoes and editorial changes.
Thompson, et al. Expires March 6, 2011 [Page 25]
Internet-Draft BFCP-Unreliable September 2010
A.2. draft-sandbakken-xcon-bfcp-udp-01 to -02
1. Stepped away from changing semantics and directionality of Hello
and HelloAck messages for pinhole establishment and keep-alive in
favor of ICE toolset, particularly as this would have not
resolved connectivity establishment as a precursor to deployment
of DTLS [RFC4347] as a transport security mechanism.
2. Change to COMMON-HEADER to reserve bit-16 of Transaction ID to
show originator of transaction such that request/response and
response/acknowledgement mapping can be maintained without
colliding randomly chosen Transaction IDs. This also avoids a
three-way handshake scenario around FloorRequest where the
implicit acknowledgement (in FloorRequestStatus) might also be
interpreted as a transaction openening request on the part of the
floor control server.
3. Defined additional timer (T2) to soak up lost responses without
additional processing.
4. Restricted outstanding transactions to only one in-flight per
direction at any one time to mitigate re-ordering issues.
5. Defined entity behavior when transactions timeout.
6. Specified initial suggestion for how to minimise fragmentation of
messages.
7. Removed consideration of TCP-over-UDP after internal review.
8. Re-stated DTLS as likely preferred mechanism of securing
transport, although this investigation is on-going.
A.3. draft-sandbakken-xcon-bfcp-udp-00 to -01
1. Refactored to a format that represents explicit changes to base
RFCs.
2. Introduction of issues currently under investigation that
preclude adoption.
3. Specified retransmission timer for requests.
Thompson, et al. Expires March 6, 2011 [Page 26]
Internet-Draft BFCP-Unreliable September 2010
Authors' Addresses
Mark K. Thompson
Cisco
Ruscombe Business Park
Ruscombe, England
UK
Email: markth2@cisco.com
Tom Kristensen
Cisco
Philip Pedersens vei 22
N-1366 Lysaker
Norway
Email: tomkrist@cisco.com, tomkri@ifi.uio.no
Geir A. Sandbakken
Cisco
Philip Pedersens vei 22
N-1366 Lysaker
Norway
Email: geirsand@cisco.com
Trond G. Andersen
Cisco
Philip Pedersens vei 22
N-1366 Lysaker
Norway
Email: trondand@cisco.com
Eoin McLeod
Cisco
Ruscombe Business Park
Ruscombe, England
UK
Email: eoimcleo@cisco.com
Thompson, et al. Expires March 6, 2011 [Page 27]