draft-thornburgh-adobe-rtmfp-06.txt   draft-thornburgh-adobe-rtmfp-07.txt 
Network Working Group M. Thornburgh Network Working Group M. Thornburgh
Internet-Draft Adobe Internet-Draft Adobe
Intended status: Informational April 15, 2013 Intended status: Informational May 2, 2013
Expires: October 17, 2013 Expires: November 3, 2013
Adobe's Secure Real-Time Media Flow Protocol Adobe's Secure Real-Time Media Flow Protocol
draft-thornburgh-adobe-rtmfp-06 draft-thornburgh-adobe-rtmfp-07
Abstract Abstract
This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), This memo describes the Secure Real-Time Media Flow Protocol (RTMFP),
an endpoint-to-endpoint communication protocol designed to securely an endpoint-to-endpoint communication protocol designed to securely
transport parallel flows of real-time video, audio, and data transport parallel flows of real-time video, audio, and data
messages, as well as bulk data, over IP networks. RTMFP has features messages, as well as bulk data, over IP networks. RTMFP has features
making it effective for peer-to-peer (P2P) as well as client-server making it effective for peer-to-peer (P2P) as well as client-server
communications, even when Network Address Translators (NATs) are communications, even when Network Address Translators (NATs) are
used. used.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 October 17, 2013. This Internet-Draft will expire on November 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 18 skipping to change at page 2, line 18
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Design Highlights of RTMFP . . . . . . . . . . . . . . . 5 1.1. Design Highlights of RTMFP . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 7 2.1. Common Elements . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Elementary Types and Constructs . . . . . . . . . . . 7 2.1.1. Elementary Types and Constructs . . . . . . . . . . . 7
2.1.2. Variable Length Unsigned Integer (VLU) . . . . . . . 8 2.1.2. Variable Length Unsigned Integer (VLU) . . . . . . . 9
2.1.3. Option . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.3. Option . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Option List . . . . . . . . . . . . . . . . . . . . . 10 2.1.4. Option List . . . . . . . . . . . . . . . . . . . . . 10
2.1.5. Internet Socket Address (Address) . . . . . . . . . . 11 2.1.5. Internet Socket Address (Address) . . . . . . . . . . 11
2.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 12 2.2.1. Encapsulation . . . . . . . . . . . . . . . . . . . . 12
2.2.2. Multiplex . . . . . . . . . . . . . . . . . . . . . . 13 2.2.2. Multiplex . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3. Encryption . . . . . . . . . . . . . . . . . . . . . 14 2.2.3. Encryption . . . . . . . . . . . . . . . . . . . . . 13
2.2.4. Packet . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.4. Packet . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1. Packet Fragment Chunk . . . . . . . . . . . . . . . . 18 2.3.1. Packet Fragment Chunk . . . . . . . . . . . . . . . . 19
2.3.2. Initiator Hello Chunk (IHello) . . . . . . . . . . . 19 2.3.2. Initiator Hello Chunk (IHello) . . . . . . . . . . . 20
2.3.3. Forwarded Initiator Hello Chunk (FIHello) . . . . . . 20 2.3.3. Forwarded Initiator Hello Chunk (FIHello) . . . . . . 20
2.3.4. Responder Hello Chunk (RHello) . . . . . . . . . . . 21 2.3.4. Responder Hello Chunk (RHello) . . . . . . . . . . . 21
2.3.5. Responder Redirect Chunk (Redirect) . . . . . . . . . 22 2.3.5. Responder Redirect Chunk (Redirect) . . . . . . . . . 22
2.3.6. RHello Cookie Change Chunk . . . . . . . . . . . . . 24 2.3.6. RHello Cookie Change Chunk . . . . . . . . . . . . . 24
2.3.7. Initiator Initial Keying Chunk (IIKeying) . . . . . . 25 2.3.7. Initiator Initial Keying Chunk (IIKeying) . . . . . . 25
2.3.8. Responder Initial Keying Chunk (RIKeying) . . . . . . 26 2.3.8. Responder Initial Keying Chunk (RIKeying) . . . . . . 26
2.3.9. Ping Chunk . . . . . . . . . . . . . . . . . . . . . 28 2.3.9. Ping Chunk . . . . . . . . . . . . . . . . . . . . . 28
2.3.10. Ping Reply Chunk . . . . . . . . . . . . . . . . . . 29 2.3.10. Ping Reply Chunk . . . . . . . . . . . . . . . . . . 29
2.3.11. User Data Chunk . . . . . . . . . . . . . . . . . . . 29 2.3.11. User Data Chunk . . . . . . . . . . . . . . . . . . . 29
2.3.11.1. Options for User Data . . . . . . . . . . . . . 31 2.3.11.1. Options for User Data . . . . . . . . . . . . . 31
2.3.11.1.1. User's Per-Flow Metadata . . . . . . . . . . 32 2.3.11.1.1. User's Per-Flow Metadata . . . . . . . . . . 32
2.3.11.1.2. Return Flow Association . . . . . . . . . . 32 2.3.11.1.2. Return Flow Association . . . . . . . . . . 32
2.3.12. Next User Data Chunk . . . . . . . . . . . . . . . . 33 2.3.12. Next User Data Chunk . . . . . . . . . . . . . . . . 33
2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) . . . 35 2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) . . . 35
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) . . . . 37 2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) . . . . 37
2.3.15. Buffer Probe Chunk . . . . . . . . . . . . . . . . . 39 2.3.15. Buffer Probe Chunk . . . . . . . . . . . . . . . . . 39
2.3.16. Flow Exception Report Chunk . . . . . . . . . . . . . 39 2.3.16. Flow Exception Report Chunk . . . . . . . . . . . . . 40
2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 40 2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 41
2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 40 2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 41
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 43 3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 43
3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . 44 3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . 45
3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . 44 3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . 45
3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 49
3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 48 3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 49
3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . 49 3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . 50
3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . 51 3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . 51
3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . 53 3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . 53
3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . 54 3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . 55
3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 55 3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 56
3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . 56 3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . 57
3.5.1.6. Redirector and Forwarder with NAT . . . . . . . 58 3.5.1.6. Redirector and Forwarder with NAT . . . . . . . 59
3.5.1.7. Load Distribution and Fault Tolerance . . . . . 61 3.5.1.7. Load Distribution and Fault Tolerance . . . . . 62
3.5.2. Congestion Control . . . . . . . . . . . . . . . . . 62 3.5.2. Congestion Control . . . . . . . . . . . . . . . . . 63
3.5.2.1. Time Critical Reverse Notification . . . . . . . 63 3.5.2.1. Time Critical Reverse Notification . . . . . . . 64
3.5.2.2. Retransmission Timeout . . . . . . . . . . . . . 63 3.5.2.2. Retransmission Timeout . . . . . . . . . . . . . 64
3.5.2.3. Burst Avoidance . . . . . . . . . . . . . . . . 65 3.5.2.3. Burst Avoidance . . . . . . . . . . . . . . . . 66
3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . 66 3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . 67
3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . 66 3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . 67 3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . 68
3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 67 3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 68
3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 68 3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 69
3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 68 3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 69
3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 69 3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 70
3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 70 3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 71
3.6.1.2. Messages and Sequencing . . . . . . . . . . . . 70 3.6.1.2. Messages and Sequencing . . . . . . . . . . . . 71
3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 71 3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 72
3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . 72 3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . 74 3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . 75
3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 75 3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 76
3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 75 3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 76
3.6.2.3.1. Startup Options . . . . . . . . . . . . . . 77 3.6.2.3.1. Startup Options . . . . . . . . . . . . . . 78
3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 77 3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 78
3.6.2.4. Processing Acknowledgements . . . . . . . . . . 78 3.6.2.4. Processing Acknowledgements . . . . . . . . . . 79
3.6.2.5. Negative Acknowledgement and Loss . . . . . . . 78 3.6.2.5. Negative Acknowledgement and Loss . . . . . . . 79
3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . 79 3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . 80
3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . 80 3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . 81
3.6.2.7.1. Forward Sequence Number Update . . . . . . . 80 3.6.2.7.1. Forward Sequence Number Update . . . . . . . 81
3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 81 3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 82
3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 82 3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 83
3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 83 3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 84
3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . 83 3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . 84
3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . 83 3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . 84
3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . 84 3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . 85
3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . 86 3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . 87
3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 87 3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 88
3.6.3.3. Buffering and Delivering Data . . . . . . . . . 89 3.6.3.3. Buffering and Delivering Data . . . . . . . . . 90
3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 91 3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 92
3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 91 3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 92
3.6.3.4.2. Size and Truncation . . . . . . . . . . . . 92 3.6.3.4.2. Size and Truncation . . . . . . . . . . . . 93
3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 93 3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 94
3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . 93 3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . 94
3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 93 3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 94
3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . 94 3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . 95
3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . 94 3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . 95
3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 95 3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 96
3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 96 3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 97
3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 97 3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 98
3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . 97 3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . 98
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 98 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99
5. Security Considerations . . . . . . . . . . . . . . . . . . . 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 99
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 99 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 100
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 99 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.1. Normative References . . . . . . . . . . . . . . . . . . 99 7.1. Normative References . . . . . . . . . . . . . . . . . . 101
7.2. Informative References . . . . . . . . . . . . . . . . . 100 7.2. Informative References . . . . . . . . . . . . . . . . . 101
Appendix A. Example Congestion Control Algorithm . . . . . . . . 100 Appendix A. Example Congestion Control Algorithm . . . . . . . . 101
A.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 100 A.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 102
A.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 102 A.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 103
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 106
1. Introduction 1. Introduction
Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for Adobe's Secure Real-Time Media Flow Protocol (RTMFP) is intended for
use as an endpoint-to-endpoint data transport service in IP networks. use as an endpoint-to-endpoint data transport service in IP networks.
It has features that make it well suited to the transport of real- It has features that make it well suited to the transport of real-
time media (such as low-delay video, audio, and data) as well as bulk time media (such as low-delay video, audio, and data) as well as bulk
data, and for client-server as well as peer-to-peer (P2P) data, and for client-server as well as peer-to-peer (P2P)
communication. These features include independent parallel message communication. These features include independent parallel message
flows which may have different delivery priorities, variable message flows which may have different delivery priorities, variable message
skipping to change at page 6, line 51 skipping to change at page 6, line 51
o Session identifiers allow an endpoint to multiplex many sessions o Session identifiers allow an endpoint to multiplex many sessions
over a single local transport address while allowing sessions to over a single local transport address while allowing sessions to
survive changes in transport address (as may happen in mobile or survive changes in transport address (as may happen in mobile or
wireless deployments). wireless deployments).
1.2. Terminology 1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this memo are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
The key phrase "MUST ONLY" in this document means that a particular
item is absolutely prohibited if the conditional circumstance does
not hold. The item is allowed if the conditional circumstance holds.
2. Syntax 2. Syntax
Definitions of types and structures in this specification use Definitions of types and structures in this specification use
traditional text diagrams paired with procedural descriptions using a traditional text diagrams paired with procedural descriptions using a
C-like syntax. C-like syntax. The C-like procedural descriptions SHALL be construed
as definitive.
Structures are packed to take only as many bytes as explicitly Structures are packed to take only as many bytes as explicitly
indicated. There is no 32-bit alignment constraint, and fields are indicated. There is no 32-bit alignment constraint, and fields are
not padded for alignment unless explicitly indicated or described. not padded for alignment unless explicitly indicated or described.
Text diagrams may include a bit ruler across the top; this is a Text diagrams may include a bit ruler across the top; this is a
convenience for counting bits in individual fields and does not convenience for counting bits in individual fields and does not
necessarily imply field alignment on a multiple of the ruler width. necessarily imply field alignment on a multiple of the ruler width.
The C-like procedural descriptions SHALL be construed as definitive. Unless specified otherwise, reserved fields SHOULD be set to 0 by a
sender and MUST be ignored by a receiver.
The procedural syntax of this specification defines correct and
error-free encoded inputs to a parser. The procedural syntax does
not describe a fully featured parser, including error detection and
handling. Implementations MUST include means to identify error
circumstances, including truncations causing elementary or composed
types to not fit inside containing structures, fields or elements.
Unless specified otherwise, an error circumstance SHALL abort the
parsing and processing of an element and its enclosing elements, up
to the containing packet.
2.1. Common Elements 2.1. Common Elements
This section lists types and structures that are used throughout this This section lists types and structures that are used throughout this
specification. specification.
2.1.1. Elementary Types and Constructs 2.1.1. Elementary Types and Constructs
This section lists the elementary types and constructs out of which This section lists the elementary types and constructs out of which
all of the following sections' definitions are built. all of the following sections' definitions are built.
skipping to change at page 9, line 40 skipping to change at page 9, line 48
(that is, encoding a maximum value of at least 2^64 - 1). (that is, encoding a maximum value of at least 2^64 - 1).
2.1.3. Option 2.1.3. Option
An Option is a Length-Type-Value triplet. Length and Type are An Option is a Length-Type-Value triplet. Length and Type are
encoded in VLU format. Length is the number of bytes of payload encoded in VLU format. Length is the number of bytes of payload
following the Length field. The payload comprises the Type and Value following the Length field. The payload comprises the Type and Value
fields. Type identifies the kind of option this is. The syntax of fields. Type identifies the kind of option this is. The syntax of
the Value field is determined by the type of option. the Value field is determined by the type of option.
An option may have a length of zero, in which case it has no type and An option can have a length of zero, in which case it has no type and
no value and is empty. An empty option is called a "Marker". no value and is empty. An empty option is called a "Marker".
+-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ +-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| length \ | type \ | value | | length \ | type \ | value |
+-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/ +-------------/-+~~~~~~~~~~~~~/~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/
^ ^ ^ ^
+-------- length bytes long (may be 0) ---------+ +-------- length bytes long (may be 0) ---------+
struct option_t struct option_t
{ {
skipping to change at page 13, line 11 skipping to change at page 12, line 33
The choice of port numbers is not mandated by this specification. The choice of port numbers is not mandated by this specification.
Higher protocol layers or the application define the port numbers Higher protocol layers or the application define the port numbers
used. used.
2.2.2. Multiplex 2.2.2. Multiplex
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| scrambled session ID (SSID) | | scrambled session ID (SSID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e first32[0] | | e first32[0] |
|- - - - - - n - - - - - - - - - - - - - - - - - - - - - - - -| |- - - - - - n - - - - - - - - - - - - - - - - - - - - - - - -|
| c first32[1] | | c first32[1] |
+- - - - - - r - - - - - - - - - - - - - - - - - - - - - - - -+ +- - - - - - r - - - - - - - - - - - - - - - - - - - - - - - -+
| y | | y |
| pted packet | | pted packet |
+---------------------------------------------------------------/ +---------------------------------------------------------------/
struct multiplex_t struct multiplex_t
{ {
skipping to change at page 14, line 13 skipping to change at page 13, line 30
length to 8. length to 8.
2.2.3. Encryption 2.2.3. Encryption
RTMFP packets are encrypted according to a Cryptography Profile. RTMFP packets are encrypted according to a Cryptography Profile.
This specification doesn't mandate a particular choice of This specification doesn't mandate a particular choice of
cryptography. The application defines the cryptographic syntax and cryptography. The application defines the cryptographic syntax and
algorithms. algorithms.
Packet encryption is RECOMMENDED to be a block cipher operating in Packet encryption is RECOMMENDED to be a block cipher operating in
CBC (or similar) mode. Encrypted packets MUST be decipherable Cipher Block Chaining [CBC] or similar mode. Encrypted packets MUST
without inter-packet dependency, since packets may be lost, be decipherable without inter-packet dependency, since packets may be
duplicated, or reordered in the network. lost, duplicated, or reordered in the network.
The packet encryption layer is responsible for data integrity and The packet encryption layer is responsible for data integrity and
authenticity, for example by means of a checksum or cryptographic authenticity, for example by means of a checksum or cryptographic
message authentication code. message authentication code.
Note that the structures described below are of plain, unencrypted Note that the structures described below are of plain, unencrypted
packets. Encrypted packets MUST be decrypted according to the packets. Encrypted packets MUST be decrypted according to the
Session Key associated with the Multiplex Session ID before being Session Key associated with the Multiplex Session ID before being
interpreted according to this specification. interpreted according to this specification.
skipping to change at page 16, line 17 skipping to change at page 16, line 17
timeCriticalReverse : Time Critical Reverse Notification. If set, timeCriticalReverse : Time Critical Reverse Notification. If set,
indicates that the sender is currently receiving packets on other indicates that the sender is currently receiving packets on other
sessions that have the timeCritical flag set. sessions that have the timeCritical flag set.
timestampPresent : If set, indicates that the timestamp field is timestampPresent : If set, indicates that the timestamp field is
present. If clear, there is no timestamp field. present. If clear, there is no timestamp field.
timestampEchoPresent : If set, indicates that the timestamp echo timestampEchoPresent : If set, indicates that the timestamp echo
field is present. If clear, there is no timestamp echo field. field is present. If clear, there is no timestamp echo field.
mode : The mode of this packet. Values are: mode : The mode of this packet. See below for additional discussion
of packet modes. Possible values are:
0 : Forbidden value 0 : Forbidden value
1 : Initiator Mark 1 : Initiator Mark
2 : Responder Mark 2 : Responder Mark
3 : Startup 3 : Startup
timestamp : If the timestampPresent flag is set, this field is timestamp : If the timestampPresent flag is set, this field is
skipping to change at page 16, line 47 skipping to change at page 16, line 48
chunks : Zero or more chunks follow the header. It is RECOMMENDED chunks : Zero or more chunks follow the header. It is RECOMMENDED
that a packet contain at least one chunk. that a packet contain at least one chunk.
padding : Zero or more bytes of padding follow the chunks. The padding : Zero or more bytes of padding follow the chunks. The
following conditions indicate padding: following conditions indicate padding:
* Fewer than three bytes (the size of a chunk header) remain in * Fewer than three bytes (the size of a chunk header) remain in
the packet. the packet.
* The chunkLength field of the current chunk indicates that the * The chunkLength field of what would be the current chunk header
chunk payload wouldn't fit in the remaining bytes of the indicates that the hypothetical chunk payload wouldn't fit in
packet. the remaining bytes of the packet.
Packet mode 0 is not allowed. Packets marked with this mode are Packet mode 0 is not allowed. Packets marked with this mode are
invalid and MUST be discarded. invalid and MUST be discarded.
The original initiator of a session MUST mark all non-startup packets The original initiator of a session MUST mark all non-startup packets
it sends in that session with packet mode 1 "Initiator Mark". It it sends in that session with packet mode 1 "Initiator Mark". It
SHOULD ignore any packet received in that session with packet mode 1. SHOULD ignore any packet received in that session with packet mode 1.
The original responder of a session MUST mark all non-startup packets The original responder of a session MUST mark all non-startup packets
it sends in that session with packet mode 2 "Responder Mark". It it sends in that session with packet mode 2 "Responder Mark". It
skipping to change at page 17, line 44 skipping to change at page 17, line 46
uint8_t chunkPayload[chunkLength]; uint8_t chunkPayload[chunkLength];
} :variable*8; } :variable*8;
chunkType : The chunk type code. chunkType : The chunk type code.
chunkLength : The size, in bytes, of the chunk payload. chunkLength : The size, in bytes, of the chunk payload.
chunkPayload : The type-specific payload of this chunk, chunkLength chunkPayload : The type-specific payload of this chunk, chunkLength
bytes in length (may be empty). bytes in length (may be empty).
The following chunk type codes are defined: Defined chunk types are enumerated here in the order they might be
encountered in the course of a typical session. The following chunk
type codes are defined:
0x7f : Packet Fragment (Section 2.3.1) 0x7f : Packet Fragment (Section 2.3.1)
0x30 : Initiator Hello (Section 2.3.2) 0x30 : Initiator Hello (Section 2.3.2)
0x0f : Forwarded Initiator Hello (Section 2.3.3) 0x0f : Forwarded Initiator Hello (Section 2.3.3)
0x70 : Responder Hello (Section 2.3.4) 0x70 : Responder Hello (Section 2.3.4)
0x71 : Responder Redirect (Section 2.3.5) 0x71 : Responder Redirect (Section 2.3.5)
0x79 : RHello Cookie Change (Section 2.3.6) 0x79 : RHello Cookie Change (Section 2.3.6)
0x38 : Initiator Initial Keying (Section 2.3.7) 0x38 : Initiator Initial Keying (Section 2.3.7)
skipping to change at page 18, line 36 skipping to change at page 18, line 41
0x51 : Data Acknowledgement Ranges (Section 2.3.14) 0x51 : Data Acknowledgement Ranges (Section 2.3.14)
0x18 : Buffer Probe (Section 2.3.15) 0x18 : Buffer Probe (Section 2.3.15)
0x5e : Flow Exception Report (Section 2.3.16) 0x5e : Flow Exception Report (Section 2.3.16)
0x0c : Session Close Request (Section 2.3.17) 0x0c : Session Close Request (Section 2.3.17)
0x4c : Session Close Acknowledgement (Section 2.3.18) 0x4c : Session Close Acknowledgement (Section 2.3.18)
0x08 : Reserved for future use
0x48 : Reserved for future use
0x00 : Ignore/Padding 0x00 : Ignore/Padding
0xff : Ignore/Padding 0xff : Ignore/Padding
A receiver MUST ignore a chunk having an unrecognized chunk type
code. A receiver MUST ignore a chunk appearing in a packet having a
mode inappropriate to that chunk type.
Unless specified otherwise, if a chunk has a syntax or processing
error (for example, the chunk's payload field is not long enough to
contain the specified syntax elements), the chunk SHALL be ignored as
though it was not present in the packet, and parsing and processing
SHALL commence with the next chunk in the packet, if any.
2.3.1. Packet Fragment Chunk 2.3.1. Packet Fragment Chunk
This chunk is used to divide a plain RTMFP packet (Section 2.2.4) This chunk is used to divide a plain RTMFP packet (Section 2.2.4)
that is unavoidably larger than the path MTU (such as session startup that is unavoidably larger than the path MTU (such as session startup
packets containing Responder Hello (Section 2.3.4) or Initiator packets containing Responder Hello (Section 2.3.4) or Initiator
Initial Keying (Section 2.3.7) chunks with large certificates) into Initial Keying (Section 2.3.7) chunks with large certificates) into
segments that do not exceed the path MTU, and to allow the segments segments that do not exceed the path MTU, and to allow the segments
to be sent through the network at a moderated rate to avoid jamming to be sent through the network at a moderated rate to avoid jamming
interfaces, links, or paths. interfaces, links, or paths.
skipping to change at page 31, line 45 skipping to change at page 31, line 45
sequenceNumber. sequenceNumber.
forwardSequenceNumber : The flow sender will not send (or resend) forwardSequenceNumber : The flow sender will not send (or resend)
any fragment with a sequence number less than or equal to the any fragment with a sequence number less than or equal to the
forward sequence number. forward sequence number.
options : If the optionsPresent flag is set, a list of zero or more options : If the optionsPresent flag is set, a list of zero or more
Options terminated by a Marker is present. See Section 2.3.11.1 Options terminated by a Marker is present. See Section 2.3.11.1
for defined options. for defined options.
userData : The actual user data for this sequence number. userData : The actual user data for this fragment.
The use of User Data is detailed in Section 3.6.2. The use of User Data is detailed in Section 3.6.2.
2.3.11.1. Options for User Data 2.3.11.1. Options for User Data
This section lists options that may appear in User Data option lists. This section lists options that may appear in User Data option lists.
A conforming implementation MUST support the options in this section. A conforming implementation MUST support the options in this section.
A flow receiver MUST reject a flow containing a flow option that is A flow receiver MUST reject a flow containing a flow option that is
not understood if the option type is less than 8192. A flow receiver not understood if the option type is less than 8192 (0x2000). A flow
MUST ignore any flow option that is not understood if the option type receiver MUST ignore any flow option that is not understood if the
is 8192 or greater. option type is 8192 or greater.
The following option type codes are defined for User Data: The following option type codes are defined for User Data:
0x00 : Users's Per-Flow Metadata (Section 2.3.11.1.1) 0x00 : Users's Per-Flow Metadata (Section 2.3.11.1.1)
0x0a : Return Flow Association (Section 2.3.11.1.2) 0x0a : Return Flow Association (Section 2.3.11.1.2)
2.3.11.1.1. User's Per-Flow Metadata 2.3.11.1.1. User's Per-Flow Metadata
This option conveys the user's per-flow metadata for the flow to This option conveys the user's per-flow metadata for the flow to
skipping to change at page 35, line 8 skipping to change at page 35, line 8
This chunk is considered to be for the same flowID as the most This chunk is considered to be for the same flowID as the most
recently preceding User Data or Next User Data chunk in the same recently preceding User Data or Next User Data chunk in the same
packet, having the same Forward Sequence Number, and having the next packet, having the same Forward Sequence Number, and having the next
sequence number. The optionsPresent, fragmentControl, abandon, and sequence number. The optionsPresent, fragmentControl, abandon, and
final flags, and the options (if present) have the same final flags, and the options (if present) have the same
interpretation as for the User Data chunk. interpretation as for the User Data chunk.
... ...
----------+------------------------------------ ----------+------------------------------------
10 00 07 | User Data chunk, length=7 10 00 07 | User Data chunk, length=7
10 | OPT=0, FRA=1 "begin", ABN=0, FIN=0 00 | OPT=0, FRA=0 "whole", ABN=0, FIN=0
02 05 03 | flowID=2, seq#=5, fsn=(5-3)=2 02 05 03 | flowID=2, seq#=5, fsn=(5-3)=2
00 01 02 | data 3 bytes: 00, 01, 02 00 01 02 | data 3 bytes: 00, 01, 02
----------+------------------------------------ ----------+------------------------------------
11 00 04 | Next User Data chunk,length=4 11 00 04 | Next User Data chunk,length=4
30 | OPT=0, FRA=3 "middle", ABN=0, FIN=0 00 | OPT=0, FRA=0 "whole", ABN=0, FIN=0
| flowID=2, seq#=6, fsn=2 | flowID=2, seq#=6, fsn=2
03 04 05 | data 3 bytes: 03, 04, 05 03 04 05 | data 3 bytes: 03, 04, 05
----------+------------------------------------ ----------+------------------------------------
11 00 04 | Next User Data chunk, length=4 11 00 04 | Next User Data chunk, length=4
20 | OPT=0, FRA=2 "end", ABN=0, FIN=0 00 | OPT=0, FRA=0 "whole", ABN=0, FIN=0
| flowID=2, seq#=7, fsn=2 | flowID=2, seq#=7, fsn=2
06 07 08 | data 3 bytes: 06, 07, 08 06 07 08 | data 3 bytes: 06, 07, 08
----------+------------------------------------ ----------+------------------------------------
flowID=2, seq#=5, #frags=3, data: 00 01 02 03 04 05 06 07 08 Figure 3: Sequential messages in one packet using Next User Data
Figure 3: A fragmented message in one packet
The use of Next User Data is detailed in Section 3.6.2.3.2. The use of Next User Data is detailed in Section 3.6.2.3.2.
2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack) 2.3.13. Data Acknowledgement Bitmap Chunk (Bitmap Ack)
This chunk is sent by the flow receiver to indicate to the flow This chunk is sent by the flow receiver to indicate to the flow
sender the User Data sequence numbers that have been received for one sender the User Data fragment sequence numbers that have been
flow. It MUST ONLY be in a packet belonging to an established received for one flow. It MUST ONLY be in a packet belonging to an
session and having packet mode 1 or 2. established session and having packet mode 1 or 2.
The flow receiver can choose to acknowledge User Data with this chunk The flow receiver can choose to acknowledge User Data with this chunk
or with a Range Ack. It SHOULD choose whichever format has the most or with a Range Ack. It SHOULD choose whichever format has the most
compact encoding of the sequence numbers received. compact encoding of the sequence numbers received.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x50 | chunkLength | | 0x50 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+-------------/-+ +-------------/-+-------------/-+-------------/-+
skipping to change at page 36, line 41 skipping to change at page 36, line 41
bool_t bit :1; bool_t bit :1;
if(bit) if(bit)
acknowledge(ackCursor + bitPosition); acknowledge(ackCursor + bitPosition);
} }
ackCursor += 8; ackCursor += 8;
} }
} :chunkLength*8; } :chunkLength*8;
flowID : VLU, the flow identifier. flowID : VLU, the flow identifier.
bufferBlocksAvailable : VLU, The number of 1024-byte blocks of User bufferBlocksAvailable : VLU, the number of 1024-byte blocks of User
Data that the receiver is currently able to accept. Data that the receiver is currently able to accept.
Section 3.6.3.5 describes how to calculate this value.
cumulativeAck : VLU, the acknowledgement of every sequence number in cumulativeAck : VLU, the acknowledgement of every fragment sequence
this flow that is less than or equal to this value. This MUST NOT number in this flow that is less than or equal to this value.
be less than the highest forward sequence number received in this This MUST NOT be less than the highest forward sequence number
flow. received in this flow.
bit field : A sequence of zero or more bytes representing a bit bit field : A sequence of zero or more bytes representing a bit
field of received sequence numbers after the cumulative field of received fragment sequence numbers after the cumulative
acknowledgement, least significant bit first. A set bit indicates acknowledgement, least significant bit first. A set bit indicates
receipt of a sequence number. A clear bit indicates that sequence receipt of a sequence number. A clear bit indicates that sequence
number was not received. The least significant bit of the first number was not received. The least significant bit of the first
byte is the second sequence number following the cumulative byte is the second sequence number following the cumulative
acknowledgement, the next bit is the third sequence number acknowledgement, the next bit is the third sequence number
following, and so on. following, and so on.
50 00 05 | Bitmap Ack, length=5 bytes 50 00 05 | Bitmap Ack, length=5 bytes
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16 05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
79 06 | 01111001 00000110 = 18, 21, 22, 23, 24, 27, 28 79 06 | 01111001 00000110 = 18, 21, 22, 23, 24, 27, 28
Example bitmap ack indicating acknowledgement of sequence numbers 0 Example bitmap ack indicating acknowledgement of fragment sequence
through 16, 18, 21 through 24, 27 and 28. numbers 0 through 16, 18, 21 through 24, 27 and 28.
Figure 4 Figure 4
2.3.14. Data Acknowledgement Ranges Chunk (Range Ack) 2.3.14. Data Acknowledgement Ranges Chunk (Range Ack)
This chunk is sent by the flow receiver to indicate to the flow This chunk is sent by the flow receiver to indicate to the flow
sender the User Data sequence numbers that have been received for one sender the User Data fragment sequence numbers that have been
flow. It MUST ONLY be in a packet belonging to an established received for one flow. It MUST ONLY be in a packet belonging to an
session and having packet mode 1 or 2. established session and having packet mode 1 or 2.
The flow receiver can choose to acknowledge User Data with this chunk The flow receiver can choose to acknowledge User Data with this chunk
or with a Bitmap Ack. It SHOULD choose whichever format has the most or with a Bitmap Ack. It SHOULD choose whichever format has the most
compact encoding of the sequence numbers received. compact encoding of the sequence numbers received.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x51 | chunkLength | | 0x51 | chunkLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------/-+-------------/-+-------------/-+ +-------------/-+-------------/-+-------------/-+
skipping to change at page 38, line 45 skipping to change at page 38, line 45
rangeFrom = ackCursor + holesMinusOne + 1; rangeFrom = ackCursor + holesMinusOne + 1;
rangeTo = rangeFrom + receivedMinusOne; rangeTo = rangeFrom + receivedMinusOne;
acknowledge(rangeFrom through rangeTo); acknowledge(rangeFrom through rangeTo);
ackCursor = rangeTo; ackCursor = rangeTo;
} }
} :chunkLength*8; } :chunkLength*8;
flowID : VLU, the flow identifier. flowID : VLU, the flow identifier.
bufferBlocksAvailable : VLU, The number of 1024-byte blocks of User bufferBlocksAvailable : VLU, the number of 1024-byte blocks of User
Data that the receiver is currently able to accept. Data that the receiver is currently able to accept.
Section 3.6.3.5 describes how to calculate this value.
cumulativeAck : VLU, the acknowledgement of every sequence number in cumulativeAck : VLU, the acknowledgement of every fragment sequence
this flow that is less than or equal to this value. This MUST NOT number in this flow that is less than or equal to this value.
be less than the highest forward sequence number received in this This MUST NOT be less than the highest forward sequence number
flow. received in this flow.
holesMinusOne / receivedMinusOne : Zero or more acknowledgement holesMinusOne / receivedMinusOne : Zero or more acknowledgement
ranges, run-length encoded. Runs are encoded as zero or more ranges, run-length encoded. Runs are encoded as zero or more
pairs of VLUs indicating the number (minus one) of missing pairs of VLUs indicating the number (minus one) of missing
sequence numbers followed by the number (minus one) of received sequence numbers followed by the number (minus one) of received
sequence numbers, starting at the cumulative acknowledgement. sequence numbers, starting at the cumulative acknowledgement.
NOTE: If a parser syntax error is encountered here (that is, if
the chunk is truncated such that not enough bytes remain to
completely encode both VLUs of the acknowledgement range), then
treat and process this chunk as though it was properly formed up
to the last completely encoded range.
51 00 07 | Range Ack, length=7 51 00 07 | Range Ack, length=7
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16 05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
00 00 | holes=1, received=1 -- missing 17, received 18 00 00 | holes=1, received=1 -- missing 17, received 18
01 03 | holes=2, received=4 -- missing 19..20, received 21..24 01 03 | holes=2, received=4 -- missing 19..20, received 21..24
Example range ack indicating acknowledgement of sequence numbers 0 Example range ack indicating acknowledgement of fragment sequence
through 16, 18, 21, 22, 23, 24. numbers 0 through 16, 18, 21, 22, 23, 24.
Figure 5 Figure 5
51 00 07 | Range Ack, length=9
05 7f 10 | flowID=5, bufAvail=127*1024 bytes, cumAck=0..16
00 00 | holes=1, received=1 -- missing 17, received 18
01 83 | holes=2, received=VLU parse error, ignore this range
Example range ack indicating acknowledgement of fragment sequence
numbers 0 through 16 and 18, with a truncated last range. Note the
truncation and parse error does not abort the entire chunk in this
case.
Figure 6
2.3.15. Buffer Probe Chunk 2.3.15. Buffer Probe Chunk
This chunk is sent by the flow sender in order to request the current This chunk is sent by the flow sender in order to request the current
available receive buffer (in the form of a Data Acknowledgement) for available receive buffer (in the form of a Data Acknowledgement) for
a flow. It MUST ONLY be in a packet belonging to an established a flow. It MUST ONLY be in a packet belonging to an established
session and having packet mode 1 or 2. session and having packet mode 1 or 2.
0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x18 | chunkLength | | 0x18 | chunkLength |
skipping to change at page 41, line 44 skipping to change at page 42, line 30
| | S E S S I O N | Peer C | | | S E S S I O N | Peer C |
| /=============================\ | | /=============================\ |
| || Flows || | | || Flows || |
| ||---------------------------->|| | | ||---------------------------->|| |
| ||<----------------------------|| | | ||<----------------------------|| |
| ||<----------------------------|| | | ||<----------------------------|| |
| \=============================/ | | \=============================/ |
| | | | | | | |
+--------+ +--------+ +--------+ +--------+
Figure 6: Sessions between pairs of communicating endpoints Figure 7: Sessions between pairs of communicating endpoints
Between any pair of communicating endpoints is a single, Between any pair of communicating endpoints is a single,
bidirectional, secured, congestion controlled session. bidirectional, secured, congestion controlled session.
Unidirectional flows convey messages from one end to the other within Unidirectional flows convey messages from one end to the other within
the session. the session.
An endpoint initiates a session to a far end when communication is An endpoint initiates a session to a far end when communication is
desired. An initiator begins with one or more candidate destination desired. An initiator begins with one or more candidate destination
socket addresses, and may learn and try more candidate addresses socket addresses, and may learn and try more candidate addresses
during startup handshaking. Eventually a first suitable response is during startup handshaking. Eventually a first suitable response is
skipping to change at page 42, line 41 skipping to change at page 43, line 25
A sender may indicate to a receiver that some user messages are of a A sender may indicate to a receiver that some user messages are of a
time-critical or real-time nature. A receiver may indicate to time-critical or real-time nature. A receiver may indicate to
senders on concurrent sessions that it is receiving time-critical senders on concurrent sessions that it is receiving time-critical
messages from another endpoint. The other senders SHOULD modify messages from another endpoint. The other senders SHOULD modify
their congestion control parameters to yield capacity to the session their congestion control parameters to yield capacity to the session
carrying time-critical messages. carrying time-critical messages.
A sender may close a flow. The flow is completed when the receiver A sender may close a flow. The flow is completed when the receiver
has no outstanding gaps before the final fragment of the flow. The has no outstanding gaps before the final fragment of the flow. The
sender and receiver reserve a completed flow's identifier for a time sender and receiver reserve a completed flow's identifier for a time
to allow in-flight messages to drain from the network. to allow in flight messages to drain from the network.
Eventually, neither end will have any flows open to the other. The Eventually, neither end will have any flows open to the other. The
session will be idle and quiescent. Either end may reliably close session will be idle and quiescent. Either end may reliably close
the session to recover its resources. the session to recover its resources.
In certain circumstances, an endpoint may be ceasing operation and In certain circumstances, an endpoint may be ceasing operation and
not have time to wait for acknowledgement of a reliable session not have time to wait for acknowledgement of a reliable session
close. In this case the halting endpoint may send an abrupt session close. In this case the halting endpoint may send an abrupt session
close to advise the far end that it is halting immediately. close to advise the far end that it is halting immediately.
skipping to change at page 48, line 28 skipping to change at page 48, line 31
| rcv IIKeying Glare v | | rcv IIKeying Glare v |
| far prevails +-------------+ | | far prevails +-------------+ |
|<-------------|S_KEYING_SENT|-------------+ |<-------------|S_KEYING_SENT|-------------+
| +-------------+ ultimate open timeout | +-------------+ ultimate open timeout
| |rcv RIKeying | |rcv RIKeying
| | | |
| rcv v | rcv v
| +-+ IIKeying +--------+ rcv Close Request | +-+ IIKeying +--------+ rcv Close Request
| |X|---------->| S_OPEN |--------------------+ | |X|---------->| S_OPEN |--------------------+
| +-+ +--------+ | | +-+ +--------+ |
| CLOSE| |rcv Close Ack | | | |ABRUPT CLOSE |
| | |rcv IIKeying session | | ORDERLY CLOSE| |or rcv Close Ack |
| | | override | | | |or rcv IIKeying |
| | | session override |
| | +-------+ | | | +-------+ |
| v | v | v | v
| +-----------+ | +-----------------+ | +-----------+ | +-----------------+
| |S_NEARCLOSE| | |S_FARCLOSE_LINGER| | |S_NEARCLOSE| | |S_FARCLOSE_LINGER|
| +-----------+ | +-----------------+ | +-----------+ | +-----------------+
| rcv Close Ack| | |rcv Close Ack | rcv Close Ack| | |rcv Close Ack
| or 90 seconds| v |or 19 seconds | or 90 seconds| v |or 19 seconds
| | +--------+ | | | +--------+ |
| +------>|S_CLOSED|<---------+ | +------>|S_CLOSED|<---------+
+-------------------------->| | +-------------------------->| |
+--------+ +--------+
Figure 7: Session state diagram Figure 8: Session state diagram
3.5.1. Startup 3.5.1. Startup
3.5.1.1. Normal Handshake 3.5.1.1. Normal Handshake
RTMFP sessions are established with a 4-way handshake in two round RTMFP sessions are established with a 4-way handshake in two round
trips. The Initiator begins by sending an IHello to one or more trips. The Initiator begins by sending an IHello to one or more
candidate addresses for the desired destination endpoint. A candidate addresses for the desired destination endpoint. A
Responder statelessly sends an RHello in response. The first correct Responder statelessly sends an RHello in response. The first correct
RHello received at the Initiator is selected; all others are ignored. RHello received at the Initiator is selected; all others are ignored.
skipping to change at page 49, line 39 skipping to change at page 49, line 48
| | | |
| RIKeying | | RIKeying |
| (RSID,SKRC,RSig)| | (RSID,SKRC,RSig)|
| (SID=ISID,Key=Default)| S_OPEN | (SID=ISID,Key=Default)| S_OPEN
|<-------------------------------| |<-------------------------------|
S_OPEN | | S_OPEN | |
| S E S S I O N | | S E S S I O N |
|<-------------------(SID=ISID)--| |<-------------------(SID=ISID)--|
|--(SID=RSID)------------------->| |--(SID=RSID)------------------->|
Figure 8: Normal handshake Figure 9: Normal handshake
In the following sections the handshake is detailed from the In the following sections the handshake is detailed from the
perspectives of the Initiator and Responder. perspectives of the Initiator and Responder.
3.5.1.1.1. Initiator 3.5.1.1.1. Initiator
The Initiator determines that a session is needed for an Endpoint The Initiator determines that a session is needed for an Endpoint
Discriminator. The Initiator creates state for a new opening session Discriminator. The Initiator creates state for a new opening session
and begins with a candidate endpoint address set containing at least and begins with a candidate endpoint address set containing at least
one address. The new session is placed in the S_IHELLO_SENT state. one address. The new session is placed in the S_IHELLO_SENT state.
skipping to change at page 53, line 22 skipping to change at page 53, line 32
3.5.1.2. Cookie Change 3.5.1.2. Cookie Change
In some circumstances, the Responder may generate an RHello cookie In some circumstances, the Responder may generate an RHello cookie
for an Initiator's address that isn't the address the Initiator would for an Initiator's address that isn't the address the Initiator would
use when sending packets directly to the Responder. This can happen, use when sending packets directly to the Responder. This can happen,
for example, when the Initiator has multiple local addresses, and for example, when the Initiator has multiple local addresses, and
uses one to reach a Forwarder (Section 3.5.1.5) but another to reach uses one to reach a Forwarder (Section 3.5.1.5) but another to reach
the Responder. the Responder.
Consider the following example: Initiator has two network interfaces, Consider the following example:
a first preferred interface with address Ix = 192.0.2.100:50000, and
a second with address Iy = 198.51.100.101:50001. Responder has one
interface with address Ry = 198.51.100.200:51000, on the same network
as Initiator's second interface. Initiator uses its first interface
to reach a Forwarder. Forwarder observes Initiator's address of Ix
and sends a Forwarded IHello (Section 2.3.3) to Responder. Responder
treats this as if it was an IHello from Ix, calculates a
corresponding cookie, and sends an RHello to Ix. Initiator receives
this RHello from Ry and selects that address as the destination for
the session. It then sends an IIKeying, copying the cookie from the
RHello. However, since the source of the RHello is Ry, on a network
to which the Initiator is directly connected, Initiator uses its
second interface Iy to send the IIKeying. Responder, on receiving
the IIKeying, will compare the cookie to the expected value based on
the source address of the packet, and since the IIKeying source
doesn't match the IHello source used to generate the cookie,
Responder will reject the IIKeying.
If Responder determines that it generated the cookie in the IIKeying
but the cookie doesn't match the sender's address (for example, if
the cookie is in two parts, with a first part generated independently
of the Initiator's address, and a second part dependent on the
address), Responder SHOULD generate a new cookie based on the address
from which the IIKeying was received, and send an RHello Cookie
Change chunk (Section 2.3.6) to the source of the IIKeying, using the
session ID from the IIKeying and the Default Session Key.
If Initiator receives an RHello Cookie Change chunk for a session in
the S_KEYING_SENT state, AND the old cookie matches the one
originally sent to the Responder, then: Initiator adopts the new
cookie, constructs and signs a new IIKeying chunk, and sends the new
IIKeying to the Responder. Initiator SHOULD NOT change the cookie
for a session more than once.
Initiator Forwarder Responder Initiator Forwarder Responder
| IHello | | | IHello | |
|(Src=Ix) | | |(Src=Ix) | |
|------------------------------->| | |------------------------------->| |
| | FIHello | | | FIHello |
| |(RA=Ix) | | |(RA=Ix) |
| |-------------------------------->| | |-------------------------------->|
| | | |
| RHello | | RHello |
skipping to change at page 54, line 38 skipping to change at page 54, line 34
| | | |
| IIKeying | | IIKeying |
|(Cookie:Iy) | |(Cookie:Iy) |
|----------------------------------------------------------------->| |----------------------------------------------------------------->|
| | | |
| RIKeying | | RIKeying |
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
|<======================== S E S S I O N =========================>| |<======================== S E S S I O N =========================>|
Figure 9: Handshake with Cookie Change Figure 10: Handshake with Cookie Change
Initiator has two network interfaces, a first preferred interface
with address Ix = 192.0.2.100:50000, and a second with address Iy =
198.51.100.101:50001. Responder has one interface with address Ry =
198.51.100.200:51000, on the same network as Initiator's second
interface. Initiator uses its first interface to reach a Forwarder.
Forwarder observes Initiator's address of Ix and sends a Forwarded
IHello (Section 2.3.3) to Responder. Responder treats this as if it
was an IHello from Ix, calculates a corresponding cookie, and sends
an RHello to Ix. Initiator receives this RHello from Ry and selects
that address as the destination for the session. It then sends an
IIKeying, copying the cookie from the RHello. However, since the
source of the RHello is Ry, on a network to which the Initiator is
directly connected, Initiator uses its second interface Iy to send
the IIKeying. Responder, on receiving the IIKeying, will compare the
cookie to the expected value based on the source address of the
packet, and since the IIKeying source doesn't match the IHello source
used to generate the cookie, Responder will reject the IIKeying.
If Responder determines that it generated the cookie in the IIKeying
but the cookie doesn't match the sender's address (for example, if
the cookie is in two parts, with a first part generated independently
of the Initiator's address, and a second part dependent on the
address), Responder SHOULD generate a new cookie based on the address
from which the IIKeying was received, and send an RHello Cookie
Change chunk (Section 2.3.6) to the source of the IIKeying, using the
session ID from the IIKeying and the Default Session Key.
If Initiator receives an RHello Cookie Change chunk for a session in
the S_KEYING_SENT state, AND the old cookie matches the one
originally sent to the Responder, then: Initiator adopts the new
cookie, constructs and signs a new IIKeying chunk, and sends the new
IIKeying to the Responder. Initiator SHOULD NOT change the cookie
for a session more than once.
3.5.1.3. Glare 3.5.1.3. Glare
Glare occurs when two endpoints attempt to initiate sessions to each Glare occurs when two endpoints attempt to initiate sessions to each
other concurrently. Glare is detected by receipt of a valid and other concurrently. Glare is detected by receipt of a valid and
authentic IIKeying from an endpoint address which is a destination authentic IIKeying from an endpoint address which is a destination
for an opening session. Only one session is allowed between a pair for an opening session. Only one session is allowed between a pair
of endpoints. of endpoints.
Glare is resolved by comparing the certificate in the received Glare is resolved by comparing the certificate in the received
skipping to change at page 55, line 28 skipping to change at page 56, line 14
3.5.1.4. Redirector 3.5.1.4. Redirector
+-----------+ +------------+ +-----------+ +-----------+ +------------+ +-----------+
| Initiator |---------->| Redirector | | Responder | | Initiator |---------->| Redirector | | Responder |
| |<----------| | | | | |<----------| | | |
| | +------------+ | | | | +------------+ | |
| |<=================================>| | | |<=================================>| |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 10: Redirector Figure 11: Redirector
A Redirector acts like a name server for Endpoint Discriminators. An A Redirector acts like a name server for Endpoint Discriminators. An
Initiator MAY use a Redirector to discover additional candidate Initiator MAY use a Redirector to discover additional candidate
endpoint addresses for a desired endpoint. endpoint addresses for a desired endpoint.
On receipt of an IHello chunk with an Endpoint Discriminator that On receipt of an IHello chunk with an Endpoint Discriminator that
does not select the Redirector's identity, the Redirector constructs does not select the Redirector's identity, the Redirector constructs
and sends a Responder Redirect chunk (Section 2.3.5) back to the and sends a Responder Redirect chunk (Section 2.3.5) back to the
Initiator containing one or more additional candidate addresses for Initiator containing one or more additional candidate addresses for
the indicated endpoint. the indicated endpoint.
skipping to change at page 56, line 26 skipping to change at page 56, line 47
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
| IIKeying | | IIKeying |
|----------------------------------------------------------------->| |----------------------------------------------------------------->|
| | | |
| RIKeying | | RIKeying |
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
|<======================== S E S S I O N =========================>| |<======================== S E S S I O N =========================>|
Figure 11: Handshake using a Redirector Figure 12: Handshake using a Redirector
Redirectors SHOULD NOT initiate new sessions to endpoints which might Deployment Note: Redirectors SHOULD NOT initiate new sessions to
use the Redirector's address as a candidate for another endpoint, endpoints which might use the Redirector's address as a candidate for
since the far end might interpret the Redirector's IIKeying as glare another endpoint, since the far end might interpret the Redirector's
for the far end's initiation to the other endpoint. IIKeying as glare for the far end's initiation to the other endpoint.
3.5.1.5. Forwarder 3.5.1.5. Forwarder
+-----------+ +-----------+ +---+ +-----------+ +-----------+ +-----------+ +---+ +-----------+
| Initiator |---->| Forwarder |<===>| N |<===>| Responder | | Initiator |---->| Forwarder |<===>| N |<===>| Responder |
| | +-----------+ | A | | | | | +-----------+ | A | | |
| |<=====================>| T |<===>| | | |<=====================>| T |<===>| |
+-----------+ +---+ +-----------+ +-----------+ +---+ +-----------+
Figure 12: Forwarder Figure 13: Forwarder
A Responder might be behind a NAT or firewall that doesn't allow A Responder might be behind a NAT or firewall that doesn't allow
inbound packets to reach the endpoint until it first sends an inbound packets to reach the endpoint until it first sends an
outbound packet for a particular far endpoint address. outbound packet for a particular far endpoint address.
A Forwarder's endpoint address MAY be a candidate address for another A Forwarder's endpoint address MAY be a candidate address for another
endpoint. A Responder MAY use a Forwarder to receive FIHello chunks endpoint. A Responder MAY use a Forwarder to receive FIHello chunks
sent on behalf of an Initiator. sent on behalf of an Initiator.
On receipt of an IHello chunk with an Endpoint Discriminator that On receipt of an IHello chunk with an Endpoint Discriminator that
skipping to change at page 57, line 36 skipping to change at page 58, line 24
| : | | : |
| IIKeying : | | IIKeying : |
|-------------------------------------------------:--------------->| |-------------------------------------------------:--------------->|
| : | | : |
| : RIKeying | | : RIKeying |
| :<---------------| | :<---------------|
|<------------------------------------------------: | |<------------------------------------------------: |
| : | | : |
|<======================== S E S S I O N ========>:<==============>| |<======================== S E S S I O N ========>:<==============>|
Figure 13: Forwarder handshake where Responder sends an RHello Figure 14: Forwarder handshake where Responder sends an RHello
Initiator Forwarder NAT Responder Initiator Forwarder NAT Responder
| IHello | | | | IHello | | |
|------------------------------->| | | |------------------------------->| | |
| | FIHello | | | | FIHello | |
| |--------------->|--------------->| | |--------------->|--------------->|
| | | | | |
| | Redirect | | | Redirect |
| | (Implied,RD={})| | | (Implied,RD={})|
| :<---------------| | :<---------------|
skipping to change at page 58, line 32 skipping to change at page 59, line 32
| : | | : |
| IIKeying : | | IIKeying : |
|------------------------------------------------>:--------------->| |------------------------------------------------>:--------------->|
| : | | : |
| : RIKeying | | : RIKeying |
| :<---------------| | :<---------------|
|<------------------------------------------------: | |<------------------------------------------------: |
| : | | : |
|<======================== S E S S I O N ========>:<==============>| |<======================== S E S S I O N ========>:<==============>|
Figure 14: Forwarder handshake where Responder sends an Implied Figure 15: Forwarder handshake where Responder sends an Implied
Redirect Redirect
3.5.1.6. Redirector and Forwarder with NAT 3.5.1.6. Redirector and Forwarder with NAT
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| I | | N | | I | | N | | R | | I | | N | | I | | N | | R |
| n |------>| A |------>| n | | A | | e | | n |------>| A |------>| n | | A | | e |
| i | | T | | t |<====>| T |<====>| s | | i | | T | | t |<====>| T |<====>| s |
| t |<------| |<------| r | | | | p | | t |<------| |<------| r | | | | p |
| i | | | | o | | | | o | | i | | | | o | | | | o |
| a | | | +---+ | | | n | | a | | | +---+ | | | n |
| t | | | | | | d | | t | | | | | | d |
| o |<=====>| |<================>| |<====>| e | | o |<=====>| |<================>| |<====>| e |
| r | | | | | | r | | r | | | | | | r |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
Figure 15: Introduction service for Initiator and Responder behind Figure 16: Introduction service for Initiator and Responder behind
NATs NATs
An Initiator and Responder might each be behind distinct NATs or An Initiator and Responder might each be behind distinct NATs or
firewalls that don't allow inbound packets to reach the respective firewalls that don't allow inbound packets to reach the respective
endpoints until each first sends an outbound packet for a particular endpoints until each first sends an outbound packet for a particular
far endpoint address. far endpoint address.
An introduction service comprising Redirector and Forwarder functions An introduction service comprising Redirector and Forwarder functions
may facilitate direct communication between endpoints each behind a may facilitate direct communication between endpoints each behind a
NAT. NAT.
skipping to change at page 60, line 41 skipping to change at page 61, line 41
| IIKeying : : | | IIKeying : : |
|-------------->: : | |-------------->: : |
| :-------------------------------->:--------------->| | :-------------------------------->:--------------->|
| : : | | : : |
| : : RIKeying | | : : RIKeying |
| : :<---------------| | : :<---------------|
|<--------------:<--------------------------------: | |<--------------:<--------------------------------: |
| : : | | : : |
|<=============>:<======== S E S S I O N ========>:<==============>| |<=============>:<======== S E S S I O N ========>:<==============>|
Figure 16: Handshake with Redirector and Forwarder Figure 17: Handshake with Redirector and Forwarder
At the point in the diagram marked (*), Responder's RHello from the At the point in the diagram marked (*), Responder's RHello from the
FIHello might arrive at Initiator's NAT before or after Initiator's FIHello might arrive at Initiator's NAT before or after Initiator's
IHello is sent outbound to Responder's public NAT address. If it IHello is sent outbound to Responder's public NAT address. If it
arrives before, it may be dropped by the NAT. If it arrives after, arrives before, it may be dropped by the NAT. If it arrives after,
it will transit the NAT and trigger keying without waiting for it will transit the NAT and trigger keying without waiting for
another round trip time. The timing of this race depends, among another round trip time. The timing of this race depends, among
other factors, on the relative distances of Initiator and Responder other factors, on the relative distances of Initiator and Responder
to each other and the introduction service. to each other and the introduction service.
skipping to change at page 61, line 20 skipping to change at page 62, line 20
| i | SESSION +-------------+ | i | SESSION +-------------+
| t |<=========>| Responder 2 | | t |<=========>| Responder 2 |
| i | +-------------+ | i | +-------------+
| a | IHello... +----------------+ | a | IHello... +----------------+
| t |-------------------------> X | Dead Responder | | t |-------------------------> X | Dead Responder |
| o | +----------------+ | o | +----------------+
| r | IHello/RHello +-------------+ | r | IHello/RHello +-------------+
| |<---------------->| Responder N | | |<---------------->| Responder N |
+---+ +-------------+ +---+ +-------------+
Figure 17: Parallel Open to Multiple Endpoints Figure 18: Parallel Open to Multiple Endpoints
Section 3.2 allows more than one endpoint to be selected by one Section 3.2 allows more than one endpoint to be selected by one
Endpoint Discriminator. This will typically be the case for a set of Endpoint Discriminator. This will typically be the case for a set of
servers, any of which could accommodate a connecting client. servers, any of which could accommodate a connecting client.
Section 3.5.1.1.1 allows an Initiator to use multiple candidate Section 3.5.1.1.1 allows an Initiator to use multiple candidate
endpoint addresses when starting a session, and specifies that the endpoint addresses when starting a session, and specifies that the
the sender of the first acceptable RHello chunk to be received is the sender of the first acceptable RHello chunk to be received is
selected to complete the session, with later responses ignored. An selected to complete the session, with later responses ignored. An
Initiator can start with the multiple candidate endpoint addresses, Initiator can start with the multiple candidate endpoint addresses,
skipping to change at page 61, line 49 skipping to change at page 62, line 49
In one circumstance, multiple servers of similar processing and In one circumstance, multiple servers of similar processing and
networking capacity may be located in near proximity to each other, networking capacity may be located in near proximity to each other,
such as in a data center. In this circumstance, a less heavily such as in a data center. In this circumstance, a less heavily
loaded server can respond to an IHello more quickly than more heavily loaded server can respond to an IHello more quickly than more heavily
loaded servers, and will tend to be selected by a client. loaded servers, and will tend to be selected by a client.
In another circumstance, multiple servers may be located in different In another circumstance, multiple servers may be located in different
physical locations, such as different data centers. In this physical locations, such as different data centers. In this
circumstance, a server that is located nearer (in terms of network circumstance, a server that is located nearer (in terms of network
distance) to the client can respond more quickly than more distant distance) to the client can respond earlier than more distant
servers, and will tend to be selected by the client. servers, and will tend to be selected by the client.
Multiple servers, in proximity or distant from one another, can form Multiple servers, in proximity or distant from one another, can form
a redundant pool of servers. A client can perform a parallel open to a redundant pool of servers. A client can perform a parallel open to
the multiple servers. In normal operation, the multiple servers will the multiple servers. In normal operation, the multiple servers will
all respond, and the client will select one of them as described all respond, and the client will select one of them as described
above. If one of the multiple servers fails, other servers in the above. If one of the multiple servers fails, other servers in the
pool can still respond to the client, allowing the client to pool can still respond to the client, allowing the client to
successfully complete to an S_OPEN session with one of them. successfully complete to an S_OPEN session with one of them.
skipping to change at page 70, line 14 skipping to change at page 71, line 14
3.6.1.1. Identity 3.6.1.1. Identity
Flows are multiplexed in a session by a flow identifier. Each end of Flows are multiplexed in a session by a flow identifier. Each end of
a session chooses its sending flow identifiers independently of the a session chooses its sending flow identifiers independently of the
other end. The choice of similar flow identifiers by both ends does other end. The choice of similar flow identifiers by both ends does
not imply an association. A sender MAY choose any identifier for any not imply an association. A sender MAY choose any identifier for any
flow; therefore, a flow receiver MUST NOT ascribe any semantic flow; therefore, a flow receiver MUST NOT ascribe any semantic
meaning, role, or name to a flow based only on its identifier. There meaning, role, or name to a flow based only on its identifier. There
are no "well known" or reserved flow identifiers. are no "well known" or reserved flow identifiers.
Bidirectional flow association is indicated with the Return Flow Bidirectional flow association is indicated at flow startup with the
Association option (Section 2.3.11.1.2). An endpoint can indicate Return Flow Association option (Section 2.3.11.1.2). An endpoint can
that a new sending flow is in return (or response) to a receiving indicate that a new sending flow is in return (or response) to a
flow from the other end. A sending flow MUST NOT indicate more than receiving flow from the other end. A sending flow MUST NOT indicate
one return association. A receiving flow can be specified as the more than one return association. A receiving flow can be specified
return association for any number of sending flows. The return flow as the return association for any number of sending flows. The
association, if any, is fixed for the lifetime of the sending flow. return flow association, if any, is fixed for the lifetime of the
sending flow. Note: Closure of one flow in an association does not
automatically close other flows in the association except as
specified in Section 3.6.3.1.
Flows are named with arbitrary user metadata. This specification Flows are named with arbitrary user metadata. This specification
doesn't mandate any particular encoding, syntax, or semantics for the doesn't mandate any particular encoding, syntax, or semantics for the
user metadata except for the encoded size (Section 2.3.11.1.1); the user metadata except for the encoded size (Section 2.3.11.1.1); the
user metadata is entirely reserved for the application. The user user metadata is entirely reserved for the application. The user
metadata is fixed for the lifetime of the flow. metadata is fixed for the lifetime of the flow.
3.6.1.2. Messages and Sequencing 3.6.1.2. Messages and Sequencing
Flows provide message-oriented framing. Large messages are Flows provide message-oriented framing. Large messages are
fragmented for transport in the network. Receivers reassemble fragmented for transport in the network. Receivers reassemble
fragmented messages and only present complete messages to the user. fragmented messages and only present complete messages to the user.
A sender queues messages on a sending flow one after another. A A sender queues messages on a sending flow one after another. A
receiver can recover the original queuing order of the messages, even receiver can recover the original queuing order of the messages, even
when they are reordered in transit by the network or as a result of when they are reordered in transit by the network or as a result of
loss and retransmission. Flows are the basic units of message loss and retransmission, by means of the messages' fragment sequence
sequencing; each flow is sequenced independently of all other flows; numbers. Flows are the basic units of message sequencing; each flow
inter-flow message arrival and delivery sequencing is not guaranteed. is sequenced independently of all other flows; inter-flow message
arrival and delivery sequencing is not guaranteed.
Independent flow sequencing allows a sender to prioritize the Independent flow sequencing allows a sender to prioritize the
transmission or retransmission of the messages of one flow over those transmission or retransmission of the messages of one flow over those
of other flows in a session, allocating capacity from the of other flows in a session, allocating capacity from the
transmission budget according to priority. RTMFP is designed for transmission budget according to priority. RTMFP is designed for
flows to be the basic unit of prioritization. In any flow, the flows to be the basic unit of prioritization. In any flow, fragment
sequence numbers of all fragments of a message MUST be greater than sequence numbers are unique and monotonically increasing; that is,
the sequence numbers of all fragments of all previously queued the fragment sequence numbers for any message MUST be greater than
messages in that flow. Receipt of fragments within a flow out of the fragment sequence numbers of all messages previously queued in
sequence number order creates discontiguous gaps at the receiver, that flow. Receipt of fragments within a flow out of sequence number
causing it to send an acknowledgement for every packet and for the order creates discontiguous gaps at the receiver, causing it to send
size of the encoded acknowledgements to grow. Therefore, for any an acknowledgement for every packet and for the size of the encoded
flow, the sender SHOULD send lower sequence numbers first. acknowledgements to grow. Therefore, for any flow, the sender SHOULD
send lower sequence numbers first.
A sender can abandon a queued message at any time, even if some A sender can abandon a queued message at any time, even if some
fragments of that message have been received by the other end. A fragments of that message have been received by the other end. A
receiver MUST be able to detect a gap in the flow when a message is receiver MUST be able to detect a gap in the flow when a message is
abandoned; therefore, each message SHOULD take at least one sequence abandoned; therefore, each message SHOULD take at least one sequence
number from the sequence space even if no fragments for that message number from the sequence space even if no fragments for that message
are ever sent. The sender will transmit the fragments of all are ever sent. The sender will transmit the fragments of all
messages not abandoned, and retransmit any lost fragments of all messages not abandoned, and retransmit any lost fragments of all
messages not abandoned, until all the fragments of all messages not messages not abandoned, until all the fragments of all messages not
abandoned are acknowledged by the receiver. A sender indicates a abandoned are acknowledged by the receiver. A sender indicates a
skipping to change at page 72, line 51 skipping to change at page 74, line 9
* SENT_ABANDONED: a boolean flag indicating whether this fragment * SENT_ABANDONED: a boolean flag indicating whether this fragment
was abandoned when sent; was abandoned when sent;
* EVER_SENT: a boolean flag indicating whether this fragment has * EVER_SENT: a boolean flag indicating whether this fragment has
been sent at least once, initially false; been sent at least once, initially false;
* NAK_COUNT: a count of the number of negative acknowledgements * NAK_COUNT: a count of the number of negative acknowledgements
detected for this fragment, initially 0; detected for this fragment, initially 0;
* IN_FLIGHT: a boolean flag indicating whether this fragment is * IN_FLIGHT: a boolean flag indicating whether this fragment is
currently in flight in the network, initially false; currently outstanding, or in flight, in the network, initially
false;
* TRANSMIT_SIZE: the size, in bytes, of the encoded User Data * TRANSMIT_SIZE: the size, in bytes, of the encoded User Data
chunk (including the chunk header) for this fragment when it chunk (including the chunk header) for this fragment when it
was transmitted into the network. was transmitted into the network.
o F_OUTSTANDING_BYTES: the sum of the TRANSMIT_SIZE of each entry in o F_OUTSTANDING_BYTES: the sum of the TRANSMIT_SIZE of each entry in
SEND_QUEUE where entry.IN_FLIGHT is true; SEND_QUEUE where entry.IN_FLIGHT is true;
o RX_BUFFER_SIZE: the most recent available buffer advertisement o RX_BUFFER_SIZE: the most recent available buffer advertisement
from the other end (Section 2.3.13, Section 2.3.14), initially from the other end (Section 2.3.13, Section 2.3.14), initially
skipping to change at page 74, line 30 skipping to change at page 75, line 30
v v
+-----------------+ +-----------------+
|F_COMPLETE_LINGER| |F_COMPLETE_LINGER|
+-----------------+ +-----------------+
| 130 seconds | 130 seconds
v v
+--------+ +--------+
|F_CLOSED| |F_CLOSED|
+--------+ +--------+
Figure 18: Sending flow state diagram Figure 19: Sending flow state diagram
3.6.2.1. Startup 3.6.2.1. Startup
The application opens a new sending flow to the other end in an The application opens a new sending flow to the other end in an
S_OPEN session. The implementation chooses a new flow ID that is not S_OPEN session. The implementation chooses a new flow ID that is not
assigned to any other sending flow in that session in the F_OPEN, assigned to any other sending flow in that session in the F_OPEN,
F_CLOSING, or F_COMPLETE_LINGER states. The flow starts in the F_CLOSING, or F_COMPLETE_LINGER states. The flow starts in the
F_OPEN state. The STARTUP_OPTIONS for the new flow is set with the F_OPEN state. The STARTUP_OPTIONS for the new flow is set with the
User's Per-Flow Metadata (Section 2.3.11.1.1). If this flow is in User's Per-Flow Metadata (Section 2.3.11.1.1). If this flow is in
return (or response) to an RF_OPEN receiving flow from the other end, return (or response) to a receiving flow from the other end, that
that flow's ID is encoded in a Return Flow Association flow's ID is encoded in a Return Flow Association
(Section 2.3.11.1.2) option and added to STARTUP_OPTIONS. (Section 2.3.11.1.2) option and added to STARTUP_OPTIONS. A new
sending flow SHOULD NOT be opened in response to a receiving flow
from the other end that is not in the RF_OPEN state when the sending
flow is opened.
At this point the flow exists in the sender, but not the receiver. At this point the flow exists in the sender, but not the receiver.
The flow begins when user data fragments are transmitted to the The flow begins when user data fragments are transmitted to the
receiver. A sender can begin a flow in the absence of immediate user receiver. A sender can begin a flow in the absence of immediate user
data by sending a Forward Sequence Number Update (Section 3.6.2.7.1), data by sending a Forward Sequence Number Update (Section 3.6.2.7.1),
by queuing and transmitting a user data fragment that is already by queuing and transmitting a user data fragment that is already
abandoned. abandoned.
3.6.2.2. Queuing Data 3.6.2.2. Queuing Data
skipping to change at page 76, line 20 skipping to change at page 77, line 20
entry.SEQUENCE_NUMBER - 1; otherwise entry.SEQUENCE_NUMBER - 1; otherwise
3. If the first entry in the SEND_QUEUE is IN_FLIGHT AND 3. If the first entry in the SEND_QUEUE is IN_FLIGHT AND
entry.SENT_ABANDONED is false: set FSN to entry.SEQUENCE_NUMBER - entry.SENT_ABANDONED is false: set FSN to entry.SEQUENCE_NUMBER -
1; otherwise 1; otherwise
4. The first entry in the SEND_QUEUE is abandoned and is either not 4. The first entry in the SEND_QUEUE is abandoned and is either not
IN_FLIGHT or was already abandoned when sent: set FSN to IN_FLIGHT or was already abandoned when sent: set FSN to
entry.SEQUENCE_NUMBER. entry.SEQUENCE_NUMBER.
The FSN MUST NOT be greater than any sequence number currently in The FSN MUST NOT be greater than any sequence number currently
flight. The FSN MUST NOT be equal to any sequence number currently outstanding. The FSN MUST NOT be equal to any sequence number
in flight that was not abandoned when sent. currently outstanding that was not abandoned when sent.
Assemble user data chunks for this flow into a packet to send to the Assemble user data chunks for this flow into a packet to send to the
receiver. While enough space remains in the packet and the flow is receiver. While enough space remains in the packet and the flow is
ready to transmit: ready to transmit:
1. Starting at the head of the SEND_QUEUE, find the first eligible 1. Starting at the head of the SEND_QUEUE, find the first eligible
fragment entry; fragment entry;
2. Encode entry into a User Data chunk (Section 2.3.11) or, if 2. Encode entry into a User Data chunk (Section 2.3.11) or, if
possible (Section 3.6.2.3.2), a Next User Data chunk possible (Section 3.6.2.3.2), a Next User Data chunk
skipping to change at page 79, line 26 skipping to change at page 80, line 26
After processing all acknowledgements in a packet containing at least After processing all acknowledgements in a packet containing at least
one acknowledgement, then for each sending flow in that session, for one acknowledgement, then for each sending flow in that session, for
each entry in that flow's SEND_QUEUE, if entry.IN_FLIGHT is true and each entry in that flow's SEND_QUEUE, if entry.IN_FLIGHT is true and
entry.TSN is less than session.MAX_TSN_ACK: increment entry.NAK_COUNT entry.TSN is less than session.MAX_TSN_ACK: increment entry.NAK_COUNT
and notify the congestion control and avoidance algorithms that a and notify the congestion control and avoidance algorithms that a
negative acknowledgement was detected in this packet. negative acknowledgement was detected in this packet.
For each sending flow in that session, for each entry in that flow's For each sending flow in that session, for each entry in that flow's
SEND_QUEUE, if entry.IN_FLIGHT is true and entry.NAK_COUNT is at SEND_QUEUE, if entry.IN_FLIGHT is true and entry.NAK_COUNT is at
least 3, that fragment was lost in the network and is no longer in least 3, that fragment was lost in the network and is no longer
flight. Set entry.IN_FLIGHT to false. Notify the congestion control considered to be in flight. Set entry.IN_FLIGHT to false. Notify
and avoidance algorithms of the loss. the congestion control and avoidance algorithms of the loss.
3.6.2.6. Timeout 3.6.2.6. Timeout
A fragment is considered lost and no longer in flight in the network A fragment is considered lost and no longer in flight in the network
if it has remained outstanding for at least ERTO. if it has remained outstanding for at least ERTO.
The following describes an OPTIONAL method to manage transmission The following describes an OPTIONAL method to manage transmission
timeouts. This method REQUIRES that either Burst Avoidance timeouts. This method REQUIRES that either Burst Avoidance
(Section 3.5.2.3) is implemented, or that the implementation's (Section 3.5.2.3) is implemented, or that the implementation's
congestion control and avoidance algorithms will eventually stop congestion control and avoidance algorithms will eventually stop
skipping to change at page 80, line 41 skipping to change at page 81, line 41
fragments of the message to which it belongs. fragments of the message to which it belongs.
An abandoned fragment MUST NOT be un-abandoned. An abandoned fragment MUST NOT be un-abandoned.
3.6.2.7.1. Forward Sequence Number Update 3.6.2.7.1. Forward Sequence Number Update
Abandoned data may leave gaps in the sequence number space of a flow. Abandoned data may leave gaps in the sequence number space of a flow.
Gaps may cause the receiver to hold completely received messages for Gaps may cause the receiver to hold completely received messages for
ordered delivery to allow for retransmission of the missing ordered delivery to allow for retransmission of the missing
fragments. User Data chunks (Section 2.3.11) encode a Forward fragments. User Data chunks (Section 2.3.11) encode a Forward
Sequence Number (FSN) to instruct the receiver that sequence numbers Sequence Number (FSN) to instruct the receiver that fragments with
less than or equal to the FSN will not be transmitted or sequence numbers less than or equal to the FSN will not be
retransmitted. transmitted or retransmitted.
When the receiver has gaps in the received sequence number space and When the receiver has gaps in the received sequence number space and
no non-abandoned message fragments remain in the SEND_QUEUE, the no non-abandoned message fragments remain in the SEND_QUEUE, the
sender SHOULD transmit a Forward Sequence Number Update (FSN Update) sender SHOULD transmit a Forward Sequence Number Update (FSN Update)
comprising a User Data chunk marked abandoned, whose sequence number comprising a User Data chunk marked abandoned, whose sequence number
is the FSN and whose fsnOffset is 0. An FSN Update allows the is the FSN and whose fsnOffset is 0. An FSN Update allows the
receiver to skip gaps that will not be repaired and deliver received receiver to skip gaps that will not be repaired and deliver received
messages to the user. An FSN Update may be thought of as a messages to the user. An FSN Update may be thought of as a
transmission or retransmission of abandoned sequence numbers without transmission or retransmission of abandoned sequence numbers without
actually sending the data. actually sending the data.
skipping to change at page 81, line 23 skipping to change at page 82, line 23
1 |<--- Ack ID=2, seq:0-16 1 |<--- Ack ID=2, seq:0-16
2 |---> Data ID=2, seq#=25, fsnOff=9 (fsn=16) 2 |---> Data ID=2, seq#=25, fsnOff=9 (fsn=16)
3 |---> Data ID=2, seq#=26, fsnOff=10 (fsn=16) 3 |---> Data ID=2, seq#=26, fsnOff=10 (fsn=16)
4 |<--- Ack ID=2, seq:0-18 4 |<--- Ack ID=2, seq:0-18
5 |---> Data ID=2, seq#=27, fsnOff=9 (fsn=18) 5 |---> Data ID=2, seq#=27, fsnOff=9 (fsn=18)
6 |---> Data ID=2, seq#=28, fsnOff=10 (fsn=18) 6 |---> Data ID=2, seq#=28, fsnOff=10 (fsn=18)
| : | :
There are 9 sequence numbers in flight with delayed acknowledgements. There are 9 sequence numbers in flight with delayed acknowledgements.
Figure 19: Normal flow with no loss Figure 20: Normal flow with no loss
Sender Sender
| : | :
1 |<--- Ack ID=3, seq:0-30 1 |<--- Ack ID=3, seq:0-30
2 |---> Data ID=3, seq#=45, fsnOff=15 (fsn=30) 2 |---> Data ID=3, seq#=45, fsnOff=15 (fsn=30)
3 |<--- Ack ID=3, seq:0-30, 32 (nack 31:1) 3 |<--- Ack ID=3, seq:0-30, 32 (nack 31:1)
4 |---> Data ID=3, seq#=46, fsnOff=16 (fsn=30) 4 |---> Data ID=3, seq#=46, fsnOff=16 (fsn=30)
5 |<--- Ack ID=3, seq:0-30, 32, 34 (nack 31:2, 33:1) 5 |<--- Ack ID=3, seq:0-30, 32, 34 (nack 31:2, 33:1)
6 |<--- Ack ID=3, seq:0-30, 32, 34-35 (nack 31:3=lost, 33:2) 6 |<--- Ack ID=3, seq:0-30, 32, 34-35 (nack 31:3=lost, 33:2)
7 |---> Data ID=3, seq#=47, fsnOff=15 (fsn=32, abandon 31) 7 |---> Data ID=3, seq#=47, fsnOff=15 (fsn=32, abandon 31)
skipping to change at page 82, line 44 skipping to change at page 83, line 44
24 |<--- Ack ID=3, seq:0-59, 61-63 (nack 60:3=lost) 24 |<--- Ack ID=3, seq:0-59, 61-63 (nack 60:3=lost)
25 |---> Data ID=3, ABN=1, seq#=60, fsnOff=0 (fsn=60, abandon 60) 25 |---> Data ID=3, ABN=1, seq#=60, fsnOff=0 (fsn=60, abandon 60)
26 |<--- Ack ID=3, seq:0-59, 61-64 26 |<--- Ack ID=3, seq:0-59, 61-64
| : | :
27 |<--- Ack ID=3, seq:0-64 27 |<--- Ack ID=3, seq:0-64
Flow with sequence numbers 31, 33, and 60 lost in transit, and a Flow with sequence numbers 31, 33, and 60 lost in transit, and a
pause at 64. 33 is retransmitted, 31 and 60 are abandoned. Note line pause at 64. 33 is retransmitted, 31 and 60 are abandoned. Note line
25 is a Forward Sequence Number Update (Section 3.6.2.7.1). 25 is a Forward Sequence Number Update (Section 3.6.2.7.1).
Figure 20: Flow with loss Figure 21: Flow with loss
3.6.2.9. Flow Control 3.6.2.9. Flow Control
The flow receiver advertises the amount of new data it's willing to The flow receiver advertises the amount of new data it's willing to
accept from the flow sender with the bufferBytesAvailable derived accept from the flow sender with the bufferBytesAvailable derived
field of an acknowledgement (Section 2.3.13, Section 2.3.14). field of an acknowledgement (Section 2.3.13, Section 2.3.14).
The flow sender MUST NOT send new data into the network if The flow sender MUST NOT send new data into the network if
flow.F_OUTSTANDING_BYTES is greater than or equal to the most flow.F_OUTSTANDING_BYTES is greater than or equal to the most
recently received buffer advertisement, unless flow.EXCEPTION is true recently received buffer advertisement, unless flow.EXCEPTION is true
skipping to change at page 84, line 39 skipping to change at page 85, line 39
3.6.3. Receiver 3.6.3. Receiver
Each receiving flow comprises the flow-specific information context Each receiving flow comprises the flow-specific information context
necessary to receive that flow's messages from the sending end and necessary to receive that flow's messages from the sending end and
deliver completed messages to the user. Each receiving flow context deliver completed messages to the user. Each receiving flow context
includes at least: includes at least:
o RF_FLOW_ID: this flow's identifier; o RF_FLOW_ID: this flow's identifier;
o SEQUENCE_SET: the set of all sequence numbers seen in this o SEQUENCE_SET: the set of all fragment sequence numbers seen in
receiving flow, whether received or abandoned, initially empty; this receiving flow, whether received or abandoned, initially
empty;
o RF_FINAL_SN: the final sequence number of the flow, initially o RF_FINAL_SN: the final fragment sequence number of the flow,
having no value; initially having no value;
o RECV_BUFFER: the message fragments waiting to be delivered to the o RECV_BUFFER: the message fragments waiting to be delivered to the
user, sorted by sequence number in ascending order, initially user, sorted by sequence number in ascending order, initially
empty; each message fragment entry comprising: empty; each message fragment entry comprising:
* SEQUENCE_NUMBER: the sequence number of this fragment; * SEQUENCE_NUMBER: the sequence number of this fragment;
* DATA: this fragment's user data; and * DATA: this fragment's user data; and
* FRA: the fragment control value for this message fragment, * FRA: the fragment control value for this message fragment,
having one of the values enumerated for that purpose in User having one of the values enumerated for that purpose in User
Data (Section 2.3.11). Data (Section 2.3.11).
o BUFFERED_SIZE: the sum of the lengths of each fragment in o BUFFERED_SIZE: the sum of the lengths of each fragment in
RECV_BUFFER plus any additional storage overhead for the fragments RECV_BUFFER plus any additional storage overhead for the fragments
incurred by the implementation, in bytes; incurred by the implementation, in bytes;
o BUFFER_CAPACITY: the desired maximum size for the receive buffer, o BUFFER_CAPACITY: the desired maximum size for the receive buffer,
in bytes; in bytes;
skipping to change at page 86, line 39 skipping to change at page 87, line 39
v v v v
+------------------+ +------------------+
|RF_COMPLETE_LINGER| |RF_COMPLETE_LINGER|
+------------------+ +------------------+
| 120 seconds | 120 seconds
v v
+---------+ +---------+
|RF_CLOSED| |RF_CLOSED|
+---------+ +---------+
Figure 21: Receiving flow state diagram Figure 22: Receiving flow state diagram
3.6.3.1. Startup 3.6.3.1. Startup
A new receiving flow starts on receipt of a User Data chunk A new receiving flow starts on receipt of a User Data chunk
(Section 2.3.11) encoding a flow ID not belonging to any other (Section 2.3.11) encoding a flow ID not belonging to any other
receiving flow in the same session in the RF_OPEN, RF_REJECTED, or receiving flow in the same session in the RF_OPEN, RF_REJECTED, or
RF_COMPLETE_LINGER states. RF_COMPLETE_LINGER states.
On receipt of such a User Data chunk: On receipt of such a User Data chunk:
skipping to change at page 91, line 23 skipping to change at page 92, line 23
is not 2-end: this segment is incomplete but still in is not 2-end: this segment is incomplete but still in
progress. Ordered delivery is no longer possible until at progress. Ordered delivery is no longer possible until at
least one more fragment is received. Stop. least one more fragment is received. Stop.
If flow.RF_FINAL_SN has a value and is equal to CSN, AND RECV_BUFFER If flow.RF_FINAL_SN has a value and is equal to CSN, AND RECV_BUFFER
is empty: all complete messages have been delivered to the user, so is empty: all complete messages have been delivered to the user, so
notify the user that the flow is complete. notify the user that the flow is complete.
3.6.3.4. Acknowledging Data 3.6.3.4. Acknowledging Data
A flow receiver SHOULD acknowledge all user data sequence numbers A flow receiver SHOULD acknowledge all user data fragment sequence
seen in that flow. Acknowledgements drive the sender's congestion numbers seen in that flow. Acknowledgements drive the sender's
control and avoidance algorithms, clear data from the sender's congestion control and avoidance algorithms, clear data from the
buffers, and in some sender implementations clock new data into the sender's buffers, and in some sender implementations clock new data
network, and therefore must be accurate and timely. into the network, and therefore must be accurate and timely.
3.6.3.4.1. Timing 3.6.3.4.1. Timing
For similar reasons as discussed in RFC 1122 Section 4.2.3.2 For similar reasons as discussed in RFC 1122 Section 4.2.3.2
[RFC1122], it is advantageous to delay sending acknowledgements for a [RFC1122], it is advantageous to delay sending acknowledgements for a
short time so that multiple data fragments can be acknowledged in a short time so that multiple data fragments can be acknowledged in a
single transmission. However, it is also advantageous for a sender single transmission. However, it is also advantageous for a sender
to receive timely notification about the receiver's disposition of to receive timely notification about the receiver's disposition of
the flow, particularly in unusual or exceptional circumstances, so the flow, particularly in unusual or exceptional circumstances, so
that the circumstances can be addressed if possible. that the circumstances can be addressed if possible.
skipping to change at page 93, line 41 skipping to change at page 94, line 41
As discussed in Acknowledging Data (Section 3.6.3.4.1), a flow As discussed in Acknowledging Data (Section 3.6.3.4.1), a flow
receiver can delay sending an acknowledgement for up to 200 receiver can delay sending an acknowledgement for up to 200
milliseconds after receiving user data. The method described in milliseconds after receiving user data. The method described in
Receiving Data (Section 3.6.3.2) sets the session's DELACK_ALARM. Receiving Data (Section 3.6.3.2) sets the session's DELACK_ALARM.
When DELACK_ALARM fires: set ACK_NOW to true. When DELACK_ALARM fires: set ACK_NOW to true.
3.6.3.4.5. Obligatory Acknowledgement 3.6.3.4.5. Obligatory Acknowledgement
One or more acknowledgements should be sent as soon as is practical One or more acknowledgements should be sent as soon as is practical
when the session's ACK_NOW flag is set. When the ACK_NOW flag is when the session's ACK_NOW flag is set. While the ACK_NOW flag is
set: set:
1. Choose a receiving flow that is ready to send an acknowledgement; 1. Choose a receiving flow that is ready to send an acknowledgement;
2. If there is no such flow: there is no work to do, set ACK_NOW to 2. If there is no such flow: there is no work to do, set ACK_NOW to
false, set RX_DATA_PACKETS to 0, clear the DELACK_ALARM, and false, set RX_DATA_PACKETS to 0, clear the DELACK_ALARM, and
stop; otherwise stop; otherwise
3. Start a new packet; 3. Start a new packet;
4. Assemble an acknowledgement for the flow and include it in the 4. Assemble an acknowledgement for the flow and include it in the
skipping to change at page 95, line 27 skipping to change at page 96, line 27
12 |<--- Data ID=3, seq#=33, fsnOff=1 (fsn=32) 12 |<--- Data ID=3, seq#=33, fsnOff=1 (fsn=32)
13 |---> Ack ID=3, seq#=0-47 13 |---> Ack ID=3, seq#=0-47
14 |<--- Data ID=3, seq#=48, fsnOff=16 (fsn=32) 14 |<--- Data ID=3, seq#=48, fsnOff=16 (fsn=32)
15 |<--- Data ID=3, seq#=49, fsnOff=17 (fsn=32) 15 |<--- Data ID=3, seq#=49, fsnOff=17 (fsn=32)
16 |---> Ack ID=3, seq#=0-49 16 |---> Ack ID=3, seq#=0-49
| : | :
Flow with sequence numbers 31 and 33 lost in transit, 31 abandoned Flow with sequence numbers 31 and 33 lost in transit, 31 abandoned
and 33 retransmitted. and 33 retransmitted.
Figure 22 Figure 23
3.6.3.5. Flow Control 3.6.3.5. Flow Control
The flow receiver maintains a buffer for reassembling and reordering The flow receiver maintains a buffer for reassembling and reordering
messages for delivery to the user (Section 3.6.3.3). The messages for delivery to the user (Section 3.6.3.3). The
implementation and the user may wish to limit the amount of resources implementation and the user may wish to limit the amount of resources
(including buffer memory) that a flow is allowed to use. (including buffer memory) that a flow is allowed to use.
RTMFP provides a means for each receiving flow to govern the amount RTMFP provides a means for each receiving flow to govern the amount
of data sent by the sender, by way of the bufferBytesAvailable of data sent by the sender, by way of the bufferBytesAvailable
skipping to change at page 97, line 52 skipping to change at page 98, line 52
session.ACK_NOW to true. session.ACK_NOW to true.
A receiving flow SHOULD remain in the RF_COMPLETE_LINGER state for A receiving flow SHOULD remain in the RF_COMPLETE_LINGER state for
120 seconds. After 120 seconds, move to the RF_CLOSED state. The 120 seconds. After 120 seconds, move to the RF_CLOSED state. The
receiving flow is now closed, and its resources can be reclaimed once receiving flow is now closed, and its resources can be reclaimed once
all complete messages in flow.RECV_BUFFER have been delivered to the all complete messages in flow.RECV_BUFFER have been delivered to the
user (Section 3.6.3.3). The same flow ID might be used for a new user (Section 3.6.3.3). The same flow ID might be used for a new
flow by the sender after this point. flow by the sender after this point.
Discussion: The flow sender detects that the flow is complete on Discussion: The flow sender detects that the flow is complete on
receiving an acknowledgement of all sequence numbers of the flow. receiving an acknowledgement of all fragment sequence numbers of the
flow. This can't happen until after the receiver has detected that
This can't happen until after the receiver has detected that the flow the flow is complete and acknowledged all of the sequence numbers.
is complete and acknowledged all of the sequence numbers. The The receiver's RF_COMPLETE_LINGER period is two minutes (one Maximum
receiver's RF_COMPLETE_LINGER period is two minutes (one Maximum Segment Lifetime (MSL)), which allows any in flight packets to drain
Segment Lifetime (MSL)), which allows any in-flight packets to drain
from the network without being misidentified, and gives the sender an from the network without being misidentified, and gives the sender an
opportunity to retransmit any sequence numbers if the completing opportunity to retransmit any sequence numbers if the completing
acknowledgement is lost. The sender's F_COMPLETE_LINGER period is at acknowledgement is lost. The sender's F_COMPLETE_LINGER period is at
least two minutes plus 10 seconds, and doesn't begin until the least two minutes plus 10 seconds, and doesn't begin until the
completing acknowledgement is received; therefore, the same flow completing acknowledgement is received; therefore, the same flow
identifier won't be re-used by the flow sender for a new sending flow identifier won't be re-used by the flow sender for a new sending flow
for at least 10 seconds after the flow receiver has closed the for at least 10 seconds after the flow receiver has closed the
receiving flow context. This ensures correct operation independent receiving flow context. This ensures correct operation independent
of network delay and even when the sender's clock runs up to 8 of network delay and even when the sender's clock runs up to 8
percent faster than the receiver's. percent faster than the receiver's.
skipping to change at page 98, line 38 skipping to change at page 99, line 37
This memo specifies a general framework that can be used to establish This memo specifies a general framework that can be used to establish
a confidential and authenticated session between endpoints. A a confidential and authenticated session between endpoints. A
Cryptography Profile, not specified herein, defines the cryptographic Cryptography Profile, not specified herein, defines the cryptographic
algorithms, data formats, and semantics as used within this algorithms, data formats, and semantics as used within this
framework. Designing a Cryptography Profile to ensure that framework. Designing a Cryptography Profile to ensure that
communications are protected to the degree required by the communications are protected to the degree required by the
application-specific threat model is outside the scope of this application-specific threat model is outside the scope of this
specification. specification.
A block cipher in CBC mode is RECOMMENDED for packet encryption
(Section 2.2.3). An attacker can predict the values of some fields
from one plain RTMFP packet to the next, or predict that some fields
may be the same from one packet to the next. This SHOULD be
considered in choosing and implementing a packet encryption cipher
and mode.
The well-known Default Session Key of a Cryptography Profile serves The well-known Default Session Key of a Cryptography Profile serves
multiple purposes, including: to scramble session startup packets to multiple purposes, including: to scramble session startup packets to
protect interior fields from undesirable modification by middleboxes protect interior fields from undesirable modification by middleboxes
such as NATs; to increase the effort required for casual passive such as NATs; to increase the effort required for casual passive
observation of startup packets; to allow for different applications observation of startup packets; to allow for different applications
of RTMFP using different Default Session Keys to (intentionally or of RTMFP using different Default Session Keys to (intentionally or
not) share network transport addresses without interference. The not) share network transport addresses without interference. The
Default Session Key, being well-known, MUST NOT be construed to Default Session Key, being well-known, MUST NOT be construed to
contribute to the security of session startup; session startup is contribute to the security of session startup; session startup is
essentially in the clear. essentially in the clear.
skipping to change at page 99, line 35 skipping to change at page 100, line 42
selected by the Initiator. The attacker needn't forge the desired selected by the Initiator. The attacker needn't forge the desired
Responder's source address, since the RHello is selected based on the Responder's source address, since the RHello is selected based on the
tag echo and not the packet's source address. This can simplify the tag echo and not the packet's source address. This can simplify the
attack in some network or host configurations. attack in some network or host configurations.
6. Acknowledgements 6. Acknowledgements
Special thanks go to Matthew Kaufman for his contributions to the Special thanks go to Matthew Kaufman for his contributions to the
creation and design of RTMFP. creation and design of RTMFP.
Thanks to Wesley Eddy, Philipp Hancke, Bela Lubkin, and Martin Thanks to Wesley Eddy, Philipp Hancke, Bela Lubkin, Richard
Stiemerling for their detailed reviews of this memo. Scheffenegger, and Martin Stiemerling for their detailed reviews of
this memo.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
skipping to change at page 100, line 20 skipping to change at page 101, line 30
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000. RFC 2914, September 2000.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
[CBC] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation", NIST Special Publication 800-38A,
December 2001, <http://csrc.nist.gov/publications/
nistpubs/800-38a/sp800-38a.pdf>.
7.2. Informative References 7.2. Informative References
[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.
[ScalableTCP] [ScalableTCP]
Kelly, T., "Scalable TCP: Improving Performance in Kelly, T., "Scalable TCP: Improving Performance in
Highspeed Wide Area Networks", December 2002, <http:// Highspeed Wide Area Networks", December 2002, <http://
datatag.web.cern.ch/datatag/papers/pfldnet2003-ctk.pdf>. datatag.web.cern.ch/datatag/papers/pfldnet2003-ctk.pdf>.
skipping to change at page 103, line 23 skipping to change at page 104, line 39
sent on ANY session in the last 800 milliseconds, and otherwise being sent on ANY session in the last 800 milliseconds, and otherwise being
TRUE. TRUE.
Let TC_SENT indicate whether a Time Critical Forward Notification has Let TC_SENT indicate whether a Time Critical Forward Notification has
been sent on this session within the last 800 milliseconds. been sent on this session within the last 800 milliseconds.
Implement the method of Section 3.6.2.6 to manage transmission Implement the method of Section 3.6.2.6 to manage transmission
timeouts, including setting the TIMEOUT_ALARM. timeouts, including setting the TIMEOUT_ALARM.
On being notified that the TIMEOUT_ALARM has fired, perform the On being notified that the TIMEOUT_ALARM has fired, perform the
function in Figure 23: function in Figure 24:
on TimeoutNotification(WAS_LOSS): on TimeoutNotification(WAS_LOSS):
set SSTHRESH to MAX(SSTHRESH, CWND * 3/4). set SSTHRESH to MAX(SSTHRESH, CWND * 3/4).
set ACKED_BYTES_ACCUMULATOR to 0. set ACKED_BYTES_ACCUMULATOR to 0.
if WAS_LOSS is TRUE: if WAS_LOSS is TRUE:
set CWND to CWND_TIMEDOUT. set CWND to CWND_TIMEDOUT.
else: else:
set CWND to CWND_INIT. set CWND to CWND_INIT.
Figure 23: Pseudocode for handling a timeout notification Figure 24: Pseudocode for handling a timeout notification
Before processing each received packet in this session: Before processing each received packet in this session:
1. Set ANY_LOSS to FALSE; 1. Set ANY_LOSS to FALSE;
2. Set ANY_NAKS to FALSE; 2. Set ANY_NAKS to FALSE;
3. Set ACKED_BYTES_THIS_PACKET to 0; and 3. Set ACKED_BYTES_THIS_PACKET to 0; and
4. Set PRE_ACK_OUTSTANDING to S_OUTSTANDING_BYTES. 4. Set PRE_ACK_OUTSTANDING to S_OUTSTANDING_BYTES.
skipping to change at page 104, line 6 skipping to change at page 105, line 23
On notification of loss (Section 3.6.2.5): set ANY_LOSS to TRUE. On notification of loss (Section 3.6.2.5): set ANY_LOSS to TRUE.
On notification of negative acknowledgement (Section 3.6.2.5): set On notification of negative acknowledgement (Section 3.6.2.5): set
ANY_NAKS to TRUE. ANY_NAKS to TRUE.
On notification of acknowledgement of data (Section 3.6.2.4): set On notification of acknowledgement of data (Section 3.6.2.4): set
ANY_ACKS to TRUE, and add the count of acknowledged bytes to ANY_ACKS to TRUE, and add the count of acknowledged bytes to
ACKED_BYTES_THIS_PACKET. ACKED_BYTES_THIS_PACKET.
After processing all chunks in each received packet for this session, After processing all chunks in each received packet for this session,
perform the function in Figure 24: perform the function in Figure 25:
if ANY_LOSS is TRUE: if ANY_LOSS is TRUE:
if (TC_SENT is TRUE) OR (PRE_ACK_OUTSTANDING > 67200 AND \ if (TC_SENT is TRUE) OR (PRE_ACK_OUTSTANDING > 67200 AND \
FASTGROW_ALLOWED is TRUE): FASTGROW_ALLOWED is TRUE):
set SSTHRESH to MAX(PRE_ACK_OUTSTANDING * 7/8, CWND_INIT). set SSTHRESH to MAX(PRE_ACK_OUTSTANDING * 7/8, CWND_INIT).
else: else:
set SSHTRESH to MAX(PRE_ACK_OUTSTANDING * 1/2, CWND_INIT). set SSHTRESH to MAX(PRE_ACK_OUTSTANDING * 1/2, CWND_INIT).
set CWND to SSTHRESH. set CWND to SSTHRESH.
set ACKED_BYTES_ACCUMULATOR to 0. set ACKED_BYTES_ACCUMULATOR to 0.
else if (ANY_ACKS is TRUE) AND (ANY_NAKS is FALSE) AND \ else if (ANY_ACKS is TRUE) AND (ANY_NAKS is FALSE) AND \
skipping to change at page 104, line 45 skipping to change at page 106, line 42
set AITHRESH_CAP to 2400. set AITHRESH_CAP to 2400.
else: else:
set AITHRESH_CAP to 4800. set AITHRESH_CAP to 4800.
add ACKED_BYTES_THIS_PACKET to ACKED_BYTES_ACCUMULATOR. add ACKED_BYTES_THIS_PACKET to ACKED_BYTES_ACCUMULATOR.
set AITHRESH to MIN(MAX(CWND / 16, 64), AITHRESH_CAP). set AITHRESH to MIN(MAX(CWND / 16, 64), AITHRESH_CAP).
while ACKED_BYTES_ACCUMULATOR >= AITHRESH: while ACKED_BYTES_ACCUMULATOR >= AITHRESH:
subtract AITHRESH from ACKED_BYTES_ACCUMULATOR. subtract AITHRESH from ACKED_BYTES_ACCUMULATOR.
add 24 to INCREASE. add 24 to INCREASE.
set CWND to MAX(CWND + MIN(INCREASE, SMSS), CWND_INIT). set CWND to MAX(CWND + MIN(INCREASE, SMSS), CWND_INIT).
Figure 24: Pseudocode for congestion window adjustment after Figure 25: Pseudocode for congestion window adjustment after
processing a packet processing a packet
Author's Address Author's Address
Michael C. Thornburgh Michael C. Thornburgh
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Avenue 345 Park Avenue
San Jose, CA 95110-2704 San Jose, CA 95110-2704
US US
 End of changes. 88 change blocks. 
243 lines changed or deleted 308 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/