draft-ietf-bfcpbis-rfc4582bis-00.txt   draft-ietf-bfcpbis-rfc4582bis-01.txt 
BFCPbis Working Group T. Kristensen, Ed. BFCPbis Working Group T. Kristensen, Ed.
Internet-Draft C. Eckel Internet-Draft C. Eckel
Intended status: Standards Track A. Heggestad Intended status: Standards Track A. Heggestad
Expires: July 27, 2012 M. Thompson Expires: August 20, 2012 G. Sandbakken
G. Sandbakken
E. McLeod
Cisco Cisco
January 24, 2012 February 17, 2012
Revision of the Binary Floor Control Protocol (BFCP) for use over an Revision of the Binary Floor Control Protocol (BFCP) for use over an
unreliable transport unreliable transport
draft-ietf-bfcpbis-rfc4582bis-00 draft-ietf-bfcpbis-rfc4582bis-01
Abstract Abstract
This draft describes how to extend the Binary Floor Control Protocol This draft describes how to extend the Binary Floor Control Protocol
(BFCP) for use over an unreliable transport. It details the (BFCP) for use over an unreliable transport. It details the
differences from the BFCP protocol definition document and the differences from the BFCP protocol definition document and the
Session Description Protocol (SDP) format specified for BFCP streams. Session Description Protocol (SDP) format specified for BFCP streams.
Status of this Memo Status of this Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2012. This Internet-Draft will expire on August 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 27
3.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . . . 7
4. Difference from RFC4582 . . . . . . . . . . . . . . . . . . . 8 4. Difference from RFC4582 . . . . . . . . . . . . . . . . . . . 8
4.1. Overview of Operation (4) . . . . . . . . . . . . . . . . 8 4.1. Overview of Operation (4) . . . . . . . . . . . . . . . . 8
4.1.1. Floor Participant to Floor Control Server 4.1.1. Floor Participant to Floor Control Server
Interface (4.1) . . . . . . . . . . . . . . . . . . . 8 Interface (4.1) . . . . . . . . . . . . . . . . . . . 8
4.2. COMMON-HEADER Format (5.1) . . . . . . . . . . . . . . . . 8 4.2. COMMON-HEADER Format (5.1) . . . . . . . . . . . . . . . . 8
4.3. ERROR-CODE (5.2.6) . . . . . . . . . . . . . . . . . . . . 10 4.3. ERROR-CODE (5.2.6) . . . . . . . . . . . . . . . . . . . . 10
4.4. FloorRequestStatusAck (5.3.14) . . . . . . . . . . . . . . 10 4.4. FloorRequestStatusAck (5.3.14) . . . . . . . . . . . . . . 10
4.5. ErrorAck (5.3.15) . . . . . . . . . . . . . . . . . . . . 11 4.5. ErrorAck (5.3.15) . . . . . . . . . . . . . . . . . . . . 11
4.6. FloorStatusAck (5.3.16) . . . . . . . . . . . . . . . . . 11 4.6. FloorStatusAck (5.3.16) . . . . . . . . . . . . . . . . . 11
4.7. Goodbye (5.3.17) . . . . . . . . . . . . . . . . . . . . . 11 4.7. Goodbye (5.3.17) . . . . . . . . . . . . . . . . . . . . . 12
4.8. GoodbyeAck (5.3.18) . . . . . . . . . . . . . . . . . . . 12 4.8. GoodbyeAck (5.3.18) . . . . . . . . . . . . . . . . . . . 12
4.9. Transport (6) . . . . . . . . . . . . . . . . . . . . . . 12 4.9. Transport (6) . . . . . . . . . . . . . . . . . . . . . . 12
4.9.1. Reliable Transport (6.1) . . . . . . . . . . . . . . . 12 4.9.1. Reliable Transport (6.1) . . . . . . . . . . . . . . . 13
4.9.2. Unreliable Transport (6.2) . . . . . . . . . . . . . . 13 4.9.2. Unreliable Transport (6.2) . . . . . . . . . . . . . . 14
4.9.2.1. Congestion Control . . . . . . . . . . . . . . . . 15 4.9.2.1. Congestion Control . . . . . . . . . . . . . . . . 15
4.9.2.2. ICMP Error Handling . . . . . . . . . . . . . . . 15 4.9.2.2. ICMP Error Handling . . . . . . . . . . . . . . . 15
4.9.3. Large Message Considerations . . . . . . . . . . . . . 15 4.9.3. Large Message Considerations . . . . . . . . . . . . . 16
4.9.3.1. Fragmentation Handling . . . . . . . . . . . . . . 16
4.10. Lower-Layer Security (7) . . . . . . . . . . . . . . . . . 16 4.10. Lower-Layer Security (7) . . . . . . . . . . . . . . . . . 16
4.11. Protocol Transactions (8) . . . . . . . . . . . . . . . . 17 4.11. Protocol Transactions (8) . . . . . . . . . . . . . . . . 17
4.12. Server Behavior (8.2) . . . . . . . . . . . . . . . . . . 17 4.12. Server Behavior (8.2) . . . . . . . . . . . . . . . . . . 17
4.13. Timers (8.3) . . . . . . . . . . . . . . . . . . . . . . . 17 4.13. Timers (8.3) . . . . . . . . . . . . . . . . . . . . . . . 18
4.14. Request Retransmission Timer, T1 (8.3.1) . . . . . . . . . 17 4.14. Request Retransmission Timer, T1 (8.3.1) . . . . . . . . . 18
4.15. Response Retransmission Timer, T2 (8.3.2) . . . . . . . . 18 4.15. Response Retransmission Timer, T2 (8.3.2) . . . . . . . . 18
4.16. Timer Values (8.3.3) . . . . . . . . . . . . . . . . . . . 18 4.16. Timer Values (8.3.3) . . . . . . . . . . . . . . . . . . . 18
4.17. Authentication and Authorization (9) . . . . . . . . . . . 18 4.17. Authentication and Authorization (9) . . . . . . . . . . . 19
4.17.1. TLS Based Mutual Authentication (9.1) . . . . . . . . 19 4.17.1. TLS Based Mutual Authentication (9.1) . . . . . . . . 19
4.18. Receiving a Response [to a FloorRequest Message] 4.18. Receiving a Response [to a FloorRequest Message]
(10.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . 19 (10.1.2) . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.19. Receiving a Response [to a FloorRelease Message] 4.19. Receiving a Response [to a FloorRelease Message]
(10.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 19 (10.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.20. Receiving a Response [to a ChairAction Message] (11.2) . . 19 4.20. Receiving a Response [to a ChairAction Message] (11.2) . . 20
4.21. Receiving a Response [to a FloorQuery Message] (12.1.2) . 19 4.21. Receiving a Response [to a FloorQuery Message] (12.1.2) . 20
4.22. Receiving a Response [to a FloorRequestQuery Message] 4.22. Receiving a Response [to a FloorRequestQuery Message]
(12.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 19 (12.2.2) . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.23. Receiving a Response [to a UserQuery Message] (12.3.2) . . 20 4.23. Receiving a Response [to a UserQuery Message] (12.3.2) . . 20
4.24. Receiving a Response [to a Hello Message] (12.4.2) . . . . 20 4.24. Receiving a Response [to a Hello Message] (12.4.2) . . . . 20
4.25. Reception of a FloorRequestStatus Message (13.1.3) . . . . 20 4.25. Reception of a FloorRequestStatus Message (13.1.3) . . . . 21
4.26. Reception of a FloorStatus Message (13.5.3) . . . . . . . 20 4.26. Reception of a FloorStatus Message (13.5.3) . . . . . . . 21
4.27. Reception of an Error Message (13.8.1) . . . . . . . . . . 20 4.27. Reception of an Error Message (13.8.1) . . . . . . . . . . 21
4.28. Security Considerations (14) . . . . . . . . . . . . . . . 21 4.28. Security Considerations (14) . . . . . . . . . . . . . . . 21
4.29. IANA Considerations - Primitive Subregistry (15.2) . . . . 21 4.29. IANA Considerations - Primitive Subregistry (15.2) . . . . 21
4.30. IANA Considerations - Error Code Subregistry (15.4) . . . 21 4.30. IANA Considerations - Error Code Subregistry (15.4) . . . 22
4.31. Example Call Flows for BFCP over Unreliable Transport 4.31. Example Call Flows for BFCP over Unreliable Transport
(Appendix A) . . . . . . . . . . . . . . . . . . . . . . . 21 (Appendix A) . . . . . . . . . . . . . . . . . . . . . . . 22
5. Revision of RFC4583 . . . . . . . . . . . . . . . . . . . . . 25 5. Revision of RFC4583 . . . . . . . . . . . . . . . . . . . . . 25
5.1. Fields in the 'm' Line (3) . . . . . . . . . . . . . . . . 25 5.1. Fields in the 'm' Line (3) . . . . . . . . . . . . . . . . 26
5.2. Authentication (8) . . . . . . . . . . . . . . . . . . . . 25 5.2. Authentication (8) . . . . . . . . . . . . . . . . . . . . 26
5.3. Security Considerations (10) . . . . . . . . . . . . . . . 26 5.3. Security Considerations (10) . . . . . . . . . . . . . . . 26
5.4. Registration of SDP 'proto' Values (11.1) . . . . . . . . 26 5.4. Registration of SDP 'proto' Values (11.1) . . . . . . . . 26
6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 26 6. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Remaining Work . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29
A.1. draft-sandbakken-dispatch-bfcp-udp-03 to Appendix A. Change History . . . . . . . . . . . . . . . . . . . 30
draft-ietf-bfcpbis-rfc4582bis-00 . . . . . . . . . . . . . 29 A.1. draft-ietf-bfcpbis-rfc4582bis-00 to -01 . . . . . . . . . 30
A.2. draft-sandbakken-dispatch-bfcp-udp-02 to -03 . . . . . . . 30 A.2. draft-sandbakken-dispatch-bfcp-udp-03 to
A.3. draft-sandbakken-dispatch-bfcp-udp-01 to -02 . . . . . . . 30 draft-ietf-bfcpbis-rfc4582bis-00 . . . . . . . . . . . . . 30
A.4. draft-sandbakken-dispatch-bfcp-udp-00 to -01 . . . . . . . 30 A.3. draft-sandbakken-dispatch-bfcp-udp-02 to -03 . . . . . . . 31
A.5. draft-sandbakken-xcon-bfcp-udp-02 to A.4. draft-sandbakken-dispatch-bfcp-udp-01 to -02 . . . . . . . 31
draft-sandbakken-dispatch-bfcp-udp-00 . . . . . . . . . . 31 A.5. draft-sandbakken-dispatch-bfcp-udp-00 to -01 . . . . . . . 31
A.6. draft-sandbakken-xcon-bfcp-udp-01 to -02 . . . . . . . . . 31 A.6. draft-sandbakken-xcon-bfcp-udp-02 to
A.7. draft-sandbakken-xcon-bfcp-udp-00 to -01 . . . . . . . . . 32 draft-sandbakken-dispatch-bfcp-udp-00 . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 A.7. draft-sandbakken-xcon-bfcp-udp-01 to -02 . . . . . . . . . 33
A.8. draft-sandbakken-xcon-bfcp-udp-00 to -01 . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
This draft describes how to extend the BFCP protocol to support This draft describes how to extend the BFCP protocol to support
unreliable transport. Minor changes to the transaction model are unreliable transport. Minor changes to the transaction model are
introduced in that all requests now have an appropriate response to introduced in that all requests now have an appropriate response to
complete the transaction. The requests are sent with a retransmit complete the transaction. The requests are sent with a retransmit
timer associated with the response to achieve reliability. timer associated with the response to achieve reliability.
This extension does not change the semantics of BFCP. It permits UDP This extension does not change the semantics of BFCP. It permits UDP
skipping to change at page 5, line 30 skipping to change at page 5, line 30
audio and video, and a BFCP connection for floor control. Existing audio and video, and a BFCP connection for floor control. Existing
deployments are most common in, but not limited to, enterprise deployments are most common in, but not limited to, enterprise
networks. In existing deployments, NAT/firewall traversal for the networks. In existing deployments, NAT/firewall traversal for the
RTP streams works using ICE and/or other methods, including those RTP streams works using ICE and/or other methods, including those
described in [I-D.ietf-mmusic-media-path-middleboxes]. described in [I-D.ietf-mmusic-media-path-middleboxes].
When enhancing an existing SIP based video conferencing deployment When enhancing an existing SIP based video conferencing deployment
with support for content sharing, the BFCP connection often poses a with support for content sharing, the BFCP connection often poses a
problem. The reasons for this fall into two general classes. First, problem. The reasons for this fall into two general classes. First,
there may be a strong preference for UDP based signaling in general. there may be a strong preference for UDP based signaling in general.
On high capacity endpoints (e.g. PSTN gateways or SIP/H.323 On high capacity endpoints (e.g. PSTN gateways or SIP/H.323 inter-
interworking gateways), TCP can suffer from head of line blocking, working gateways), TCP can suffer from head of line blocking, and it
and it uses many kernel buffers. Network operators view UDP as a way uses many kernel buffers. Network operators view UDP as a way to
to avoid both of these. Second, establishment and traversal of the avoid both of these. Second, establishment and traversal of the TCP
TCP connection involving ephemeral ports, as is typically the case connection involving ephemeral ports, as is typically the case with
with BFCP over TCP, can be problematic, as described in Appendix A of BFCP over TCP, can be problematic, as described in Appendix A of
[I-D.ietf-mmusic-ice-tcp]. A broad study of NAT behavior and peer- [I-D.ietf-mmusic-ice-tcp]. A broad study of NAT behavior and peer-
to-peer TCP establishment for a comprehensive set of TCP NAT to-peer TCP establishment for a comprehensive set of TCP NAT
traversal techniques over a wide range of commercial NAT products traversal techniques over a wide range of commercial NAT products
concluded it was not possible to establish a TCP connection in 11% of concluded it was not possible to establish a TCP connection in 11% of
the cases [IMC05]. The results are worse when focusing on enterprise the cases [IMC05]. The results are worse when focusing on enterprise
NATs. A study of hole punching as a NAT traversal technique across a NATs. A study of hole punching as a NAT traversal technique across a
wide variety of deployed NATs reported consistently higher success wide variety of deployed NATs reported consistently higher success
rates when using UDP than when using TCP [P2PNAT]. rates when using UDP than when using TCP [P2PNAT].
To overcome the problems with establishing TCP flows between BFCP To overcome the problems with establishing TCP flows between BFCP
entities, this draft defines UDP as an alternate transport for BFCP, entities, this draft defines UDP as an alternate transport for BFCP,
leveraging the same mechanisms in place for the RTP over UDP media leveraging the same mechanisms in place for the RTP over UDP media
streams for the BFCP communication. When using UDP as the transport, streams for the BFCP communication. When using UDP as the transport,
it is RECOMMENDED to follow the guidelines provided in [RFC5405]. it is RECOMMENDED to follow the guidelines provided in [RFC5405].
NAT traversal for BFCP over UDP entities is discussed in more detail NAT traversal for BFCP over UDP entities is discussed in more detail
in Section 6. in Section 6.
The authors view this extension as an admittedly non-ideal, but The authors view this extension as a pragmatic solution to an
pragmatic, solution to an existing deployment challenge. existing deployment challenge.
3.1. Alternatives Considered 3.1. Alternatives Considered
In selecting the approach of defining UDP as an alternate transport In selecting the approach of defining UDP as an alternate transport
for BFCP, several alternatives were considered and explored to some for BFCP, several alternatives were considered and explored to some
degree. Each of these is discussed briefly in the following degree. Each of these is discussed briefly in the following
subsections. In summary, while these alternatives work in a number subsections. In summary, while these alternatives work in a number
of scenarios, they are not sufficient, in and of themselves, to of scenarios, they are not sufficient, in and of themselves, to
address the use case targeted by this draft. address the use case targeted by this draft.
skipping to change at page 9, line 8 skipping to change at page 9, line 8
(Editorial Note: here-in Section 4.31) shows the same sample (Editorial Note: here-in Section 4.31) shows the same sample
interactions but over an unreliable transport. interactions but over an unreliable transport.
4.2. COMMON-HEADER Format (5.1) 4.2. COMMON-HEADER Format (5.1)
The figure below should replace Figure 5: COMMON-HEADER format. The figure below should replace Figure 5: COMMON-HEADER format.
0 1 2 3 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 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 | | Ver |I|F| Res | Primitive | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conference ID | | Conference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID | User ID | | Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset | Fragment Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: COMMON-HEADER format Figure 2: COMMON-HEADER format
The description for "Ver" is changed as follows on page 15:
Ver: The 3-bit version field MUST be set to 1 when using BFCP over
reliable transport, i.e. as in [RFC4582]. The 3-bit version field
MUST be set to 2 when using BFCP over unreliable transport, with
the extensions specified in this document.
The following text precedes "Reserved" on page 15: The following text precedes "Reserved" on page 15:
I: The Transaction Initiator (I) flag-bit has relevance only for I: The Transaction Initiator (I) flag-bit has relevance only for
use of BFCP over unreliable transport. When clear, it indicates use of BFCP over unreliable transport. When cleared, it indicates
that this message is a request initiating a new transaction, and that this message is a request initiating a new transaction, and
the Transaction ID that follows has been generated for this the Transaction ID that follows has been generated for this
transaction. When set, it indicates that this message is a transaction. When set, it indicates that this message is a
response to a previous request, and the Transaction ID that response to a previous request, and the Transaction ID that
follows is the one associated with that request. When BFCP is follows is the one associated with that request. When BFCP is
used over reliable transports, the flag has no significance and used over reliable transports, the flag has no significance and
SHOULD be cleared. SHOULD be cleared.
F: The Fragmentation (F) flag-bit has relevance only for use of
BFCP over unreliable transport. When cleared, the message is not
fragmented. When set, it indicates that the message is a fragment
of a large fragmented BFCP message. (The optional fields Fragment
Offset and Fragment Length described below are present only if the
F flag is set).
The Reserved field changes name to Res due to limited space in the The Reserved field changes name to Res due to limited space in the
ASCII graphic in Figure 2. In the description of the Reserved field ASCII graphic in Figure 2. In the description of the Reserved field
"the 5 bits" is changed to "the 4 bits". "the 5 bits" is changed to "the 3 bits".
The description of Transaction ID should have the final clause The description of Transaction ID should have the final clause
deleted with the reference to Section 8 remaining. The value used deleted with the reference to Section 8 remaining. The value used
for server-initiated transactions MUST be non-zero when BFCP is used for server-initiated transactions MUST be non-zero when BFCP is used
over unreliable transports, and this qualification shall be described over unreliable transports, and this qualification shall be described
in the updated Section 8. in the updated Section 8.
The values below should be appended to the end of Table 1: BFCP The values below should be appended to the end of Table 1: BFCP
primitives. primitives.
skipping to change at page 10, line 19 skipping to change at page 10, line 23
| 15 | ErrorAck | P -> S ; Ch -> S | | 15 | ErrorAck | P -> S ; Ch -> S |
| 16 | FloorStatusAck | P -> S ; Ch -> S | | 16 | FloorStatusAck | P -> S ; Ch -> S |
| 17 | Goodbye | P -> S ; Ch -> S ; | | 17 | Goodbye | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S | | | | P <- S ; Ch <- S |
| 18 | GoodbyeAck | P -> S ; Ch -> S ; | | 18 | GoodbyeAck | P -> S ; Ch -> S ; |
| | | P <- S ; Ch <- S | | | | P <- S ; Ch <- S |
+-------+-----------------------+--------------------+ +-------+-----------------------+--------------------+
Table 1: BFCP primitives Table 1: BFCP primitives
The following text should be added after "User ID" on page 15:
Fragment Offset: This optional field is present only if the F flag
is set and contains a 16-bit value that specifies the number of
4-octet units contained in previous fragments.
Fragment Length: This optional field is present only if the F flag
is set and contains a 16-bit value that specifies the number of
4-octet units contained in this fragment.
4.3. ERROR-CODE (5.2.6) 4.3. ERROR-CODE (5.2.6)
The value below should be appended to the end of Table 5: Error Code The value below should be appended to the end of Table 5: Error Code
meaning. meaning.
+-------+-------------------------+ +-------+-------------------------+
| Value | Meaning | | Value | Meaning |
+-------+-------------------------+ +-------+-------------------------+
| 10 | Unable to parse message | | 10 | Unable to parse message |
| 11 | Use DTLS | | 11 | Use DTLS |
skipping to change at page 13, line 40 skipping to change at page 14, line 9
To maintain backwards compatibility with older implementations of To maintain backwards compatibility with older implementations of
[RFC4583], BFCP entities MUST interpret the graceful close of their [RFC4583], BFCP entities MUST interpret the graceful close of their
TCP connection from their associated participant as an implicit TCP connection from their associated participant as an implicit
Goodbye message. Goodbye message.
4.9.2. Unreliable Transport (6.2) 4.9.2. Unreliable Transport (6.2)
BFCP entities may elect to exchange BFCP messages using UDP BFCP entities may elect to exchange BFCP messages using UDP
datagrams. UDP is an unreliable transport where neither delivery nor datagrams. UDP is an unreliable transport where neither delivery nor
order is assured. Each BFCP UDP datagram MUST contain exactly one ordering is assured. Each BFCP UDP datagram MUST contain exactly one
BFCP message. In the event the size of a BFCP message exceeds the BFCP message. In the event the size of a BFCP message exceeds the
MTU size, the BFCP message will be fragmented at the IP layer. MTU size, the BFCP message will be fragmented at the IP layer.
Considerations related to fragmentation are covered in Section 4.9.3. Considerations related to fragmentation are covered in Section 4.9.3.
The message format for exchange of BFCP in UDP datagrams is the same The message format for exchange of BFCP in UDP datagrams is the same
as for a TCP stream above. as for a TCP stream above.
Clients MUST announce their presence to the floor control server by Clients MUST announce their presence to the floor control server by
transmission of a Hello message. This Hello message MUST be transmission of a Hello message. This Hello message MUST be
responded to with a HelloAck message and only upon receipt can the responded to with a HelloAck message and only upon receipt can the
client consider the floor control service as present and available. client consider the floor control service as present and available.
skipping to change at page 15, line 50 skipping to change at page 16, line 16
4.9.3. Large Message Considerations 4.9.3. Large Message Considerations
Large messages become a concern when using BFCP if the overall size Large messages become a concern when using BFCP if the overall size
of a single BFCP message exceeds that representable within the 16-bit of a single BFCP message exceeds that representable within the 16-bit
Payload Length field of the COMMON-HEADER. When using UDP, there is Payload Length field of the COMMON-HEADER. When using UDP, there is
the added concern that a single BFCP message can be fragmented at the the added concern that a single BFCP message can be fragmented at the
IP layer if its overall size exceeds the MTU threshold of the IP layer if its overall size exceeds the MTU threshold of the
network. network.
The target use cases for BFCP via UDP typically involve relatively 4.9.3.1. Fragmentation Handling
small BFCP messages. Combining that with the goal of minimizing
differences to the standard BFCP specification, BFCP entities SHOULD
ensure that their messages are smaller than the recommended MTU size
of 1300 bytes when encoded to minimize the likelihood of
fragmentation in route to their peer entity.
Note: While outside the scope of this document, the definition of When transmitting a BFCP message with size greater than the MTU, the
additional mechanisms to further address BFCP message sender should fragment the message into a series of N contiguous data
fragmentation are welcome. Potential mechanisms mentioned ranges. The sender should then create N BFCP fragment messages (one
previously include: for each data range) with the same Transaction ID. The size of each
of these N messages MUST be smaller than the MTU. The F flag in the
COMMON-HEADER is set to indicate fragmentation of the BFCP message.
- a mechanism for splitting a single large message into For each of these fragments the Fragment Offset and Fragment Length
additive messages. The mechanism defined for RELOAD in section fields are included in the COMMON-HEADER. The Fragment Offset field
5.7 of [I-D.ietf-p2psip-base] has been identified as a good denotes the number of bytes contained in the previous fragments. The
candidate. Fragment Length contains the length of the fragment itself. Note
that the Payload Length field contains the length of the entire,
unfragmented message.
- an applicability statement on those BFCP messages and/or When a BFCP implementation receives a BFCP message fragment, it MUST
attributes deemed as inappropriate for use over transports buffer the fragment until it has received the entire BFCP message.
where fragmentation is a concern. The state machine should handle the BFCP message only after all the
fragments for the message have been received.
- a SIP event package to deliver information to the endpoints. If a fragment of a BFCP message is lost, the sender will not receive
an ACK for the message. Therefore the sender will retransmit the
message with same transaction ID as specified in Section 4.13. If
the ACK sent by the receiver is lost, then the entire message will be
resent by the sender. The receiver MUST then retransmit the ACK.
The receiver can discard an incomplete buffer utilizing the Response
Retransmission Timer, starting the timer after the receipt of the
first fragment.
4.10. Lower-Layer Security (7) 4.10. Lower-Layer Security (7)
Expand the section to mandate support for DTLS when transport over Expand the section to mandate support for DTLS when transport over
UDP is used such that it reads as follows: UDP is used such that it reads as follows:
BFCP relies on lower-layer security mechanisms to provide replay BFCP relies on lower-layer security mechanisms to provide replay
and integrity protection and confidentiality. BFCP floor control and integrity protection and confidentiality. BFCP floor control
servers and clients (which include both floor participants and servers and clients (which include both floor participants and
floor chairs) MUST support TLS for transport over TCP and MUST floor chairs) MUST support TLS for transport over TCP and MUST
support DTLS for transport over UDP [RFC5246]. Any BFCP entity support DTLS for transport over UDP [RFC5246]. Any BFCP entity
MAY support other security mechanisms. MAY support other security mechanisms.
BFCP entities MUST support, at a minimum, the BFCP entities MUST support, at a minimum, the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [RFC5246]. TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [RFC5246].
Which party, the client or the floor control server, acts as the Which party, the client or the floor control server, acts as the
TLS/DTLS server depends on how the underlying TCP/DTLS connection TLS/DTLS server depends on how the underlying TLS/DTLS connection
is established. For example, when the TCP/DTLS connection is is established. For a TCP/TLS connection established using an SDP
established using an SDP offer/answer exchange [RFC4583], the offer/answer exchange [RFC4583], the answerer (which may be the
answerer (which may be the client or the floor control server) client or the floor control server) always acts as the TLS server.
always acts as the TLS/DTLS server. For a UDP/DTLS connection established using the same exchange,
either party can be the DTLS server depending on the setup
attributes exchanged, as defined in [RFC5763].
4.11. Protocol Transactions (8) 4.11. Protocol Transactions (8)
The final clause of the introduction to section 8 should be read as: The final clause of the introduction to section 8 should be read as:
Since they do not trigger any response, their Transaction ID is Since they do not trigger any response, their Transaction ID is
set to 0 when used over reliable transports, but must be non-zero set to 0 when used over reliable transports, but must be non-zero
and unique in the context of outstanding transactions over and unique in the context of outstanding transactions over
unreliable transports. unreliable transports.
skipping to change at page 26, line 47 skipping to change at page 27, line 27
to maintain those bindings once established, BFCP over UDP entities to maintain those bindings once established, BFCP over UDP entities
are RECOMMENDED to use STUN [RFC5389] for keep-alives, as described are RECOMMENDED to use STUN [RFC5389] for keep-alives, as described
for SIP [RFC5626]. This results in each BFCP entity sending a for SIP [RFC5626]. This results in each BFCP entity sending a
packet, both to open the pinhole and to learn what IP/port the NAT packet, both to open the pinhole and to learn what IP/port the NAT
assigned for the binding. assigned for the binding.
In order to facilitate traversal of BFCP packets through NATs, BFCP In order to facilitate traversal of BFCP packets through NATs, BFCP
over UDP entities are RECOMMENDED to use symmetric ports for sending over UDP entities are RECOMMENDED to use symmetric ports for sending
and receiving BFCP packets, as recommended for RTP/RTCP [RFC4961]. and receiving BFCP packets, as recommended for RTP/RTCP [RFC4961].
7. Future Work 7. Remaining Work
This draft reflects a work in progress, with at least the following This draft reflects a work in progress, with at least the following
items to be documented and/or revised: items to be documented and/or revised:
DTLS usage: Follow RFC 5763 recommendation for establishing DTLS, to
remove incosistency in current description in the draft.
Version number: Define BFCP via UDP as version 2. Whether or not
version 2 applies when using TCP may require more discussion.
Fragmentation scheme: To be handled some way or another in upcoming
version of this draft.
Example signaling flows: A later version of this draft will include Example signaling flows: A later version of this draft will include
further examples of signaling exchanges over unreliable further examples - as appropriate - of signaling exchanges over
transport as a visual aid and reference for implementers, unreliable transport as a visual aid and reference for
including updated transactions, message retransmission, usage implementers, potential candidates: Updated transactions,
of DTLS during call setup, and combined usage of DTLS and STUN. message retransmission, usage of DTLS during call setup, and
combined usage of DTLS and STUN.
Reformat and merge: After figuring out the technical details in this Reformat and merge: After figuring out the technical details in this
draft, the "diff" will be merged to form proper bis-drafts to draft, the "diff" will be merged to form proper bis-drafts to
become RFC4582bis (in BFCPbis WG) and RFC4583bis (in MMUSIC become RFC4582bis (in BFCPbis WG) and RFC4583bis (in MMUSIC
WG). WG).
8. Acknowledgements Other issues not related to transport Fixing erratas to the RFCs and
known minor issues with the existing specification.
We acknowledge substantial contributions to one or more previous 8. Contributing Authors
versions of this draft from Trond G. Andersen, Alfred E. Heggestad,
Gonzalo Camarillo, Roni Even, Lorenzo Miniero, Joerg Ott, Hadriel
Kaplan, Dan Wing, Cullen Jennings, David Benham, and Alan Ford.
9. References The authors/editors would like to thank Mark K. Thompson, Eoin McLeod
and Nivedita Melinkeri who made a major contribution to the
development of this document.
9.1. Normative References Eoin McLeod
Cisco
Email: eoimcleo@cisco.com
Nivedita Melinkeri
Cisco
Email: nivedita@cisco.com
Mark K. Thompson
Cisco
Email: markth2@cisco.com
9. Acknowledgements
We acknowledge contributions to one or more previous versions of this
draft from Trond G. Andersen, Gonzalo Camarillo, Roni Even, Lorenzo
Miniero, Joerg Ott, Hadriel Kaplan, Dan Wing, Cullen Jennings, David
Benham, and Alan Ford.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
skipping to change at page 28, line 20 skipping to change at page 29, line 19
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
9.2. Informative References 10.2. Informative References
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", draft-ietf-mmusic-ice-tcp-16 (work Establishment (ICE)", draft-ietf-mmusic-ice-tcp-16 (work
in progress), November 2011. in progress), November 2011.
[I-D.ietf-mmusic-media-path-middleboxes] [I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along Interactions for Signaling Protocol Communication along
the Media Path", the Media Path",
draft-ietf-mmusic-media-path-middleboxes-03 (work in draft-ietf-mmusic-media-path-middleboxes-03 (work in
progress), July 2010. progress), July 2010.
[I-D.ietf-p2psip-base]
Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-19 (work in
progress), October 2011.
[I-D.manner-tsvwg-gut] [I-D.manner-tsvwg-gut]
Manner, J., Varis, N., and B. Briscoe, "Generic UDP Manner, J., Varis, N., and B. Briscoe, "Generic UDP
Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in
progress), July 2010. progress), July 2010.
[IMC05] Guha, S. and P. Francis, "Characterization and Measurement [IMC05] Guha, S. and P. Francis, "Characterization and Measurement
of TCP Traversal through NATs and Firewalls", 2005, of TCP Traversal through NATs and Firewalls", 2005,
<http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>. <http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>.
[P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer [P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
skipping to change at page 29, line 34 skipping to change at page 30, line 27
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, May 2010. Security (DTLS)", RFC 5763, May 2010.
[RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. [RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
Appendix A. Change History Appendix A. Change History
A.1. draft-sandbakken-dispatch-bfcp-udp-03 to A.1. draft-ietf-bfcpbis-rfc4582bis-00 to -01
1. Mandated using version 2 (Ver field == 2) for BFCP over UDP, with
the extensions described in this draft. For BFCP over TCP, the
version is still 1.
2. Added text regarding fragmentation handling: A new 'F' flag and
Fragment Offset field in Section 4.2. Added fragmentation
handling mechanism in Section 4.9.3.1.
3. Resolve an inconsistency between Section 4.10 and Section 5.3, by
introducing the setup attribute for DTLS.
4. Moved some authors to the new Section 8 Contributing Authors.
5. A dash of editorial polish.
A.2. draft-sandbakken-dispatch-bfcp-udp-03 to
draft-ietf-bfcpbis-rfc4582bis-00 draft-ietf-bfcpbis-rfc4582bis-00
1. Draft name change. Adopted as main work item in BFCPbis WG. 1. Draft name change. Adopted as main work item in BFCPbis WG.
2. Switched from informational to standards track. 2. Switched from informational to standards track.
3. No conflict with IANA registries for BFCP, since the aim is a 3. No conflict with IANA registries for BFCP, since the aim is a
standards track RFC. Removed text in Future work section. standards track RFC. Removed text in Future work section.
4. Just editorial changes as requested by WG chairs; used as a 4. Just editorial changes as requested by WG chairs; used as a
starting point in the new WG. Will add changes in upcoming starting point in the new WG. Will add changes in upcoming
version. Also author list will be considered, for instance version. Also author list will be considered, for instance
adding a contributors section in the draft. adding a contributors section in the draft.
A.2. draft-sandbakken-dispatch-bfcp-udp-02 to -03 A.3. draft-sandbakken-dispatch-bfcp-udp-02 to -03
1. Added fragmentation and reassembly mechanism defined for RELOAD 1. Added fragmentation and reassembly mechanism defined for RELOAD
as a candidate mechanism for consideration for BFCP when as a candidate mechanism for consideration for BFCP when
transported over UDP. transported over UDP.
2. Added ERROR-CODE to indicate DTLS is required. 2. Added ERROR-CODE to indicate DTLS is required.
3. Added UDP/TLS/BFCP as 4th transport value for BFCP. 3. Added UDP/TLS/BFCP as 4th transport value for BFCP.
4. Added requirement to follow offer/answer procedure in [RFC5763] 4. Added requirement to follow offer/answer procedure in [RFC5763]
when using DTLS over UDP for BFCP. when using DTLS over UDP for BFCP.
A.3. draft-sandbakken-dispatch-bfcp-udp-01 to -02 A.4. draft-sandbakken-dispatch-bfcp-udp-01 to -02
1. Switched from standards track to informational. 1. Switched from standards track to informational.
2. Added section on motivation, including alternatives considered, 2. Added section on motivation, including alternatives considered,
to address issues raised at IETF 79 and on various workgroup to address issues raised at IETF 79 and on various workgroup
aliases. aliases.
3. Changed semantics of the Transaction Initiator (I) flag-bit. 3. Changed semantics of the Transaction Initiator (I) flag-bit.
4. Expanded transport section to more explicitly call out 4. Expanded transport section to more explicitly call out
considerations regarding congestion control and ICMP errors, and considerations regarding congestion control and ICMP errors, and
add considerations for large messages. add considerations for large messages.
5. Updated security related sections and added authentication 5. Updated security related sections and added authentication
section to address DTLS when using UDP. section to address DTLS when using UDP.
6. Added section on NAT Traversal. 6. Added section on NAT Traversal.
7. Some editorial changes. 7. Some editorial changes.
A.4. draft-sandbakken-dispatch-bfcp-udp-00 to -01 A.5. draft-sandbakken-dispatch-bfcp-udp-00 to -01
1. Decision made to not increase the protocol version number as a 1. Decision made to not increase the protocol version number as a
result of this extension. Certain aspects of this draft require result of this extension. Certain aspects of this draft require
different behaviors depending on whether a reliable or unreliable different behaviors depending on whether a reliable or unreliable
transport is being used, e.g. server-initiated transactions transport is being used, e.g. server-initiated transactions
having Transaction ID 0 over reliable transports without having Transaction ID 0 over reliable transports without
acknowledgements versus non-zero and active-unique with an acknowledgements versus non-zero and active-unique with an
acknowledgement message when entities communicate over unreliable acknowledgement message when entities communicate over unreliable
transports. As the graceful-close behavior of [RFC4582] is still transports. As the graceful-close behavior of [RFC4582] is still
allowed for TCP-based implementations without mandating the use allowed for TCP-based implementations without mandating the use
skipping to change at page 31, line 17 skipping to change at page 32, line 24
Was OK for a -00 draft, not strictly needed. Was OK for a -00 draft, not strictly needed.
3. Not mandate ICE as a SHALL, but leave it as a non-mandatory way 3. Not mandate ICE as a SHALL, but leave it as a non-mandatory way
of solving the potential need for NAT/FW traversal. of solving the potential need for NAT/FW traversal.
4. Emphasized that the reference to DTLS-SRTP are merely 4. Emphasized that the reference to DTLS-SRTP are merely
informational. informational.
5. A dash of polish and nitpicking added, some typos fixed. 5. A dash of polish and nitpicking added, some typos fixed.
A.5. draft-sandbakken-xcon-bfcp-udp-02 to A.6. draft-sandbakken-xcon-bfcp-udp-02 to
draft-sandbakken-dispatch-bfcp-udp-00 draft-sandbakken-dispatch-bfcp-udp-00
1. Draft name change. As XCON WG is closing this draft is submitted 1. Draft name change. As XCON WG is closing this draft is submitted
to Dispatch WG as the arena of discussion. to Dispatch WG as the arena of discussion.
2. Moved Transaction Identifier bit (I) from the Transaction ID to 2. Moved Transaction Identifier bit (I) from the Transaction ID to
one of the current 5 reserved bits. Keep current Transaction ID one of the current 5 reserved bits. Keep current Transaction ID
syntax and semantics. Avoid potential problems with existing TCP syntax and semantics. Avoid potential problems with existing TCP
based implementations. based implementations.
skipping to change at page 31, line 43 skipping to change at page 33, line 5
UDP) is implemented. Details and examples to be included. Model UDP) is implemented. Details and examples to be included. Model
after [RFC5763], details on how to adapt the SRTP associated after [RFC5763], details on how to adapt the SRTP associated
details to BFCP and whether a reference or copying the text details to BFCP and whether a reference or copying the text
across and changing is needed. across and changing is needed.
5. Added the Rationale and Scope section to position and explain the 5. Added the Rationale and Scope section to position and explain the
motivation for this draft more in detail. motivation for this draft more in detail.
6. A number of typos and editorial changes. 6. A number of typos and editorial changes.
A.6. draft-sandbakken-xcon-bfcp-udp-01 to -02 A.7. draft-sandbakken-xcon-bfcp-udp-01 to -02
1. Stepped away from changing semantics and directionality of Hello 1. Stepped away from changing semantics and directionality of Hello
and HelloAck messages for pinhole establishment and keep-alive in and HelloAck messages for pinhole establishment and keep-alive in
favor of ICE toolset, particularly as this would have not favor of ICE toolset, particularly as this would have not
resolved connectivity establishment as a precursor to deployment resolved connectivity establishment as a precursor to deployment
of DTLS [RFC4347] as a transport security mechanism. of DTLS [RFC4347] as a transport security mechanism.
2. Change to COMMON-HEADER to reserve bit-16 of Transaction ID to 2. Change to COMMON-HEADER to reserve bit-16 of Transaction ID to
show originator of transaction such that request/response and show originator of transaction such that request/response and
response/acknowledgement mapping can be maintained without response/acknowledgement mapping can be maintained without
skipping to change at page 32, line 27 skipping to change at page 33, line 38
5. Defined entity behavior when transactions timeout. 5. Defined entity behavior when transactions timeout.
6. Specified initial suggestion for how to minimize fragmentation of 6. Specified initial suggestion for how to minimize fragmentation of
messages. messages.
7. Removed consideration of TCP-over-UDP after internal review. 7. Removed consideration of TCP-over-UDP after internal review.
8. Re-stated DTLS as likely preferred mechanism of securing 8. Re-stated DTLS as likely preferred mechanism of securing
transport, although this investigation is on-going. transport, although this investigation is on-going.
A.7. draft-sandbakken-xcon-bfcp-udp-00 to -01 A.8. draft-sandbakken-xcon-bfcp-udp-00 to -01
1. Refactored to a format that represents explicit changes to base 1. Refactored to a format that represents explicit changes to base
RFCs. RFCs.
2. Introduction of issues currently under investigation that 2. Introduction of issues currently under investigation that
preclude adoption. preclude adoption.
3. Specified retransmission timer for requests. 3. Specified retransmission timer for requests.
Authors' Addresses Authors' Addresses
skipping to change at page 33, line 20 skipping to change at page 34, line 31
Email: eckelcu@cisco.com Email: eckelcu@cisco.com
Alfred E. Heggestad Alfred E. Heggestad
Cisco Cisco
Philip Pedersens vei 22 Philip Pedersens vei 22
N-1366 Lysaker N-1366 Lysaker
Norway Norway
Email: aheggest@cisco.com Email: aheggest@cisco.com
Mark K. Thompson
Cisco
Ruscombe Business Park
Ruscombe, England
UK
Email: markth2@cisco.com
Geir A. Sandbakken Geir A. Sandbakken
Cisco Cisco
Philip Pedersens vei 22 Philip Pedersens vei 22
N-1366 Lysaker N-1366 Lysaker
Norway Norway
Email: geirsand@cisco.com Email: geirsand@cisco.com
Eoin McLeod
Cisco
Ruscombe Business Park
Ruscombe, England
UK
Email: eoimcleo@cisco.com
 End of changes. 50 change blocks. 
118 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/