draft-thornburgh-adobe-rtmfp-03.txt   draft-thornburgh-adobe-rtmfp-04.txt 
Network Working Group M. Thornburgh Network Working Group M. Thornburgh
Internet-Draft Adobe Internet-Draft Adobe
Intended status: Informational February 12, 2013 Intended status: Informational February 14, 2013
Expires: August 16, 2013 Expires: August 18, 2013
Adobe's Secure Real-Time Media Flow Protocol Adobe's Secure Real-Time Media Flow Protocol
draft-thornburgh-adobe-rtmfp-03 draft-thornburgh-adobe-rtmfp-04
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 August 16, 2013. This Internet-Draft will expire on August 18, 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 3, line 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . 39
2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 40 2.3.17. Session Close Request Chunk (Close) . . . . . . . . . 40
2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 40 2.3.18. Session Close Acknowledgement Chunk (Close Ack) . . . 40
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 43 3.2. Endpoint Identity . . . . . . . . . . . . . . . . . . . . 43
3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . . 44 3.3. Packet Multiplex . . . . . . . . . . . . . . . . . . . . . 44
3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . . 44 3.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . . 44
3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 47 3.5.1. Startup . . . . . . . . . . . . . . . . . . . . . . . 48
3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 47 3.5.1.1. Normal Handshake . . . . . . . . . . . . . . . . 48
3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . . 48 3.5.1.1.1. Initiator . . . . . . . . . . . . . . . . . . 49
3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . . 50 3.5.1.1.2. Responder . . . . . . . . . . . . . . . . . . 51
3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . . 52 3.5.1.2. Cookie Change . . . . . . . . . . . . . . . . . . 53
3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . . 53 3.5.1.3. Glare . . . . . . . . . . . . . . . . . . . . . . 54
3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 54 3.5.1.4. Redirector . . . . . . . . . . . . . . . . . . . 55
3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . . 55 3.5.1.5. Forwarder . . . . . . . . . . . . . . . . . . . . 56
3.5.1.6. Redirector and Forwarder with NAT . . . . . . . . 57 3.5.1.6. Redirector and Forwarder with NAT . . . . . . . . 58
3.5.2. Congestion Control . . . . . . . . . . . . . . . . . . 60 3.5.2. Congestion Control . . . . . . . . . . . . . . . . . . 61
3.5.2.1. Time Critical Reverse Notification . . . . . . . 60 3.5.2.1. Time Critical Reverse Notification . . . . . . . 61
3.5.2.2. Retransmission Timeout . . . . . . . . . . . . . 61 3.5.2.2. Retransmission Timeout . . . . . . . . . . . . . 62
3.5.2.3. Burst Avoidance . . . . . . . . . . . . . . . . . 63 3.5.2.3. Burst Avoidance . . . . . . . . . . . . . . . . . 64
3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . . 64 3.5.3. Address Mobility . . . . . . . . . . . . . . . . . . . 65
3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.5.4. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . . 65 3.5.4.1. Keepalive . . . . . . . . . . . . . . . . . . . . 66
3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 65 3.5.4.2. Address Mobility . . . . . . . . . . . . . . . . 66
3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 66 3.5.4.3. Path MTU Discovery . . . . . . . . . . . . . . . 67
3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 66 3.5.5. Close . . . . . . . . . . . . . . . . . . . . . . . . 67
3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.6. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 67 3.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 68
3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 67 3.6.1.1. Identity . . . . . . . . . . . . . . . . . . . . 68
3.6.1.2. Messages and Sequencing . . . . . . . . . . . . . 68 3.6.1.2. Messages and Sequencing . . . . . . . . . . . . . 69
3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 69 3.6.1.3. Lifetime . . . . . . . . . . . . . . . . . . . . 70
3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . . 70 3.6.2. Sender . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . . 71 3.6.2.1. Startup . . . . . . . . . . . . . . . . . . . . . 72
3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 71 3.6.2.2. Queuing Data . . . . . . . . . . . . . . . . . . 73
3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 72 3.6.2.3. Sending Data . . . . . . . . . . . . . . . . . . 73
3.6.2.3.1. Startup Options . . . . . . . . . . . . . . . 74 3.6.2.3.1. Startup Options . . . . . . . . . . . . . . . 75
3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 74 3.6.2.3.2. Send Next Data . . . . . . . . . . . . . . . 75
3.6.2.4. Processing Acknowledgements . . . . . . . . . . . 74 3.6.2.4. Processing Acknowledgements . . . . . . . . . . . 76
3.6.2.5. Negative Acknowledgement and Loss . . . . . . . . 75 3.6.2.5. Negative Acknowledgement and Loss . . . . . . . . 76
3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . . 76 3.6.2.6. Timeout . . . . . . . . . . . . . . . . . . . . . 77
3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . . 77 3.6.2.7. Abandoning Data . . . . . . . . . . . . . . . . . 78
3.6.2.7.1. Forward Sequence Number Update . . . . . . . 77 3.6.2.7.1. Forward Sequence Number Update . . . . . . . 78
3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 77 3.6.2.8. Examples . . . . . . . . . . . . . . . . . . . . 79
3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 79 3.6.2.9. Flow Control . . . . . . . . . . . . . . . . . . 80
3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 80 3.6.2.9.1. Buffer Probe . . . . . . . . . . . . . . . . 81
3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . . 80 3.6.2.10. Exception . . . . . . . . . . . . . . . . . . . . 81
3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . . 80 3.6.2.11. Close . . . . . . . . . . . . . . . . . . . . . . 81
3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . . 81 3.6.3. Receiver . . . . . . . . . . . . . . . . . . . . . . . 82
3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . . 82 3.6.3.1. Startup . . . . . . . . . . . . . . . . . . . . . 84
3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 83 3.6.3.2. Receiving Data . . . . . . . . . . . . . . . . . 85
3.6.3.3. Buffering and Delivering Data . . . . . . . . . . 85 3.6.3.3. Buffering and Delivering Data . . . . . . . . . . 87
3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 87 3.6.3.4. Acknowledging Data . . . . . . . . . . . . . . . 89
3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 87 3.6.3.4.1. Timing . . . . . . . . . . . . . . . . . . . 89
3.6.3.4.2. Size and Truncation . . . . . . . . . . . . . 88 3.6.3.4.2. Size and Truncation . . . . . . . . . . . . . 90
3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 88 3.6.3.4.3. Constructing . . . . . . . . . . . . . . . . 91
3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . . 89 3.6.3.4.4. Delayed Acknowledgement . . . . . . . . . . . 91
3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 89 3.6.3.4.5. Obligatory Acknowledgement . . . . . . . . . 91
3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . . 90 3.6.3.4.6. Opportunistic Acknowledgement . . . . . . . . 92
3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . . 90 3.6.3.4.7. Example . . . . . . . . . . . . . . . . . . . 92
3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 91 3.6.3.5. Flow Control . . . . . . . . . . . . . . . . . . 93
3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 92 3.6.3.6. Receiving a Buffer Probe . . . . . . . . . . . . 94
3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 93 3.6.3.7. Rejecting a Flow . . . . . . . . . . . . . . . . 95
3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . . 93 3.6.3.8. Close . . . . . . . . . . . . . . . . . . . . . . 95
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 94 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96
5. Security Considerations . . . . . . . . . . . . . . . . . . . 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 96
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 95 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 97
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.1. Normative References . . . . . . . . . . . . . . . . . . . 95 7.1. Normative References . . . . . . . . . . . . . . . . . . . 97
7.2. Informative References . . . . . . . . . . . . . . . . . . 96 7.2. Informative References . . . . . . . . . . . . . . . . . . 98
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 98
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 37, line 13 skipping to change at page 37, line 13
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
Figure 4: Example bitmap ack indicating acknowledgement of sequence Example bitmap ack indicating acknowledgement of sequence numbers 0
numbers 0 through 16, 18, 21 through 24, 27 and 28. through 16, 18, 21 through 24, 27 and 28.
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 sequence numbers that have been received for one
flow. It MUST ONLY be in a packet belonging to an established 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.
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
skipping to change at page 39, line 16 skipping to change at page 39, line 16
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.
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
Figure 5: Example range ack indicating acknowledgement of sequence Example range ack indicating acknowledgement of sequence numbers 0
numbers 0 through 16, 18, 21, 22, 23, 24. through 16, 18, 21, 22, 23, 24.
Figure 5
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 47, line 23 skipping to change at page 48, line 5
delay, initially unset; delay, initially unset;
o The state, at any time being one of the following values: the o The state, at any time being one of the following values: the
opening states S_IHELLO_SENT and S_KEYING_SENT; the open state opening states S_IHELLO_SENT and S_KEYING_SENT; the open state
S_OPEN; the closing states S_NEARCLOSE and S_FARCLOSE_LINGER; and S_OPEN; the closing states S_NEARCLOSE and S_FARCLOSE_LINGER; and
the closed states S_CLOSED and S_OPEN_FAILED; and the closed states S_CLOSED and S_OPEN_FAILED; and
o The role of this end of the session, which is either Initiator or o The role of this end of the session, which is either Initiator or
Responder. Responder.
Note: this diagram is only a summary of state transitions and their
causing events, and is not a complete operational specification.
rcv IIKeying Glare
far prevails +-------------+ ultimate open timeout
+--------------|S_IHELLO_SENT|-------------+
| +-------------+ |
| |rcv RHello v
| | +-------------+
| | |S_OPEN_FAILED|
| | +-------------+
| rcv IIKeying Glare v ^
| far prevails +-------------+ |
|<-------------|S_KEYING_SENT|-------------+
| +-------------+ ultimate open timeout
| |rcv RIKeying
| |
| rcv v
| +-+ IIKeying +--------+ rcv Close Request
| |X|---------->| S_OPEN |--------------------+
| +-+ +--------+ |
| CLOSE| |rcv Close Ack |
| | |rcv IIKeying session |
| | | override |
| | +-------+ |
| v | v
| +-----------+ | +-----------------+
| |S_NEARCLOSE| | |S_FARCLOSE_LINGER|
| +-----------+ | +-----------------+
| rcv Close Ack| | |rcv Close Ack
| or 90 seconds| v |or 19 seconds
| | +--------+ |
| +------>|S_CLOSED|<---------+
+-------------------------->| |
+--------+
Figure 7: 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.
The Initiator computes its half of the session keying and sends an The Initiator computes its half of the session keying and sends an
skipping to change at page 48, line 30 skipping to change at page 49, line 37
| | | |
| 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 7: Normal handshake Figure 8: 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 34 skipping to change at page 54, line 36
| | | |
| IIKeying | | IIKeying |
|(Cookie:Iy) | |(Cookie:Iy) |
|----------------------------------------------------------------->| |----------------------------------------------------------------->|
| | | |
| RIKeying | | RIKeying |
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
|<======================== S E S S I O N =========================>| |<======================== S E S S I O N =========================>|
Figure 8: Handshake with Cookie Change Figure 9: Handshake with Cookie Change
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 54, line 24 skipping to change at page 55, line 27
3.5.1.4. Redirector 3.5.1.4. Redirector
+-----------+ +------------+ +-----------+ +-----------+ +------------+ +-----------+
| Initiator |---------->| Redirector | | Responder | | Initiator |---------->| Redirector | | Responder |
| |<----------| | | | | |<----------| | | |
| | +------------+ | | | | +------------+ | |
| |<=================================>| | | |<=================================>| |
+-----------+ +-----------+ +-----------+ +-----------+
Figure 9: Redirector Figure 10: 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 55, line 26 skipping to change at page 56, line 26
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
| IIKeying | | IIKeying |
|----------------------------------------------------------------->| |----------------------------------------------------------------->|
| | | |
| RIKeying | | RIKeying |
|<-----------------------------------------------------------------| |<-----------------------------------------------------------------|
| | | |
|<======================== S E S S I O N =========================>| |<======================== S E S S I O N =========================>|
Figure 10: Handshake using a Redirector Figure 11: Handshake using a Redirector
Redirectors SHOULD NOT initiate new sessions to endpoints which might Redirectors SHOULD NOT initiate new sessions to endpoints which might
use the Redirector's address as a candidate for another endpoint, use the Redirector's address as a candidate for another endpoint,
since the far end might interpret the Redirector's IIKeying as glare since the far end might interpret the Redirector's IIKeying as glare
for the far end's initiation to the other endpoint. 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 11: Forwarder Figure 12: 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 56, line 36 skipping to change at page 57, line 36
| : | | : |
| IIKeying : | | IIKeying : |
|-------------------------------------------------:--------------->| |-------------------------------------------------:--------------->|
| : | | : |
| : RIKeying | | : RIKeying |
| :<---------------| | :<---------------|
|<------------------------------------------------: | |<------------------------------------------------: |
| : | | : |
|<======================== S E S S I O N ========>:<==============>| |<======================== S E S S I O N ========>:<==============>|
Figure 12: Forwarder handshake where Responder sends an RHello Figure 13: 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 57, line 32 skipping to change at page 58, line 32
| : | | : |
| 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 Implied Figure 14: 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 14: Introduction service for Initiator and Responder behind Figure 15: 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 59, line 41 skipping to change at page 60, line 41
| IIKeying : : | | IIKeying : : |
|-------------->: : | |-------------->: : |
| :-------------------------------->:--------------->| | :-------------------------------->:--------------->|
| : : | | : : |
| : : RIKeying | | : : RIKeying |
| : :<---------------| | : :<---------------|
|<--------------:<--------------------------------: | |<--------------:<--------------------------------: |
| : : | | : : |
|<=============>:<======== S E S S I O N ========>:<==============>| |<=============>:<======== S E S S I O N ========>:<==============>|
Figure 15: Handshake with Redirector and Forwarder Figure 16: 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 71, line 18 skipping to change at page 72, line 18
o F_FINAL_SN: the sequence number assigned to the final message o F_FINAL_SN: the sequence number assigned to the final message
fragment of the flow, initially having no value; fragment of the flow, initially having no value;
o EXCEPTION: a boolean flag indicating whether an exception has been o EXCEPTION: a boolean flag indicating whether an exception has been
reported by the receiver, initially false; reported by the receiver, initially false;
o The state, at any time being one of the following values: the open o The state, at any time being one of the following values: the open
state F_OPEN; the closing states F_CLOSING and F_COMPLETE_LINGER; state F_OPEN; the closing states F_CLOSING and F_COMPLETE_LINGER;
and the closed state F_CLOSED. and the closed state F_CLOSED.
Note: this diagram is only a summary of state transitions and their
causing events, and is not a complete operational specification.
+--------+
| F_OPEN |
+--------+
|CLOSE or
|rcv Flow Exception
|
v
+---------+
|F_CLOSING|
+---------+
|rcv Data Ack
| 0..F_FINAL_SN
v
+-----------------+
|F_COMPLETE_LINGER|
+-----------------+
| 130 seconds
v
+--------+
|F_CLOSED|
+--------+
Figure 17: 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 an RF_OPEN receiving flow from the other end,
that flow's ID is encoded in a Return Flow Association that flow's ID is encoded in a Return Flow Association
skipping to change at page 78, line 16 skipping to change at page 79, line 33
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 16: Normal flow with no loss Figure 18: 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 79, line 44 skipping to change at page 80, 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 17: Flow with loss Figure 19: 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 82, line 28 skipping to change at page 84, line 5
o SHOULD_ACK: whether or not an acknowledgement should be sent for o SHOULD_ACK: whether or not an acknowledgement should be sent for
this flow, initially false; this flow, initially false;
o EXCEPTION_CODE: the exception code to report to the sender when o EXCEPTION_CODE: the exception code to report to the sender when
the flow has been rejected, initially 0; the flow has been rejected, initially 0;
o The state, at any time being one of the following values: the open o The state, at any time being one of the following values: the open
state RF_OPEN; the closing states RF_REJECTED and state RF_OPEN; the closing states RF_REJECTED and
RF_COMPLETE_LINGER; and the closed state RF_CLOSED. RF_COMPLETE_LINGER; and the closed state RF_CLOSED.
Note: this diagram is only a summary of state transitions and their
causing events, and is not a complete operational specification.
+-+
|X|
+-+
|rcv User Data for
| no existing flow
v
+---------+
| RF_OPEN |
+---------+
rcv all sequence numbers| |user reject,
0..RF_FINAL_SN | |rcv bad option,
| |no metadata at open,
| |association specified
| | but not F_OPEN at open
+---+ |
| v
| +-----------+
| |RF_REJECTED|
| +-----------+
| |rcv all sequence numbers
| | 0..RF_FINAL_SN
v v
+------------------+
|RF_COMPLETE_LINGER|
+------------------+
| 120 seconds
v
+---------+
|RF_CLOSED|
+---------+
Figure 20: 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:
1. Set temporary variables METADATA, ASSOCIATED_FLOWID, and 1. Set temporary variables METADATA, ASSOCIATED_FLOWID, and
skipping to change at page 91, line 24 skipping to change at page 93, line 24
9 |---> Ack ID=3, seq:0-30, 32, 34-46 9 |---> Ack ID=3, seq:0-30, 32, 34-46
10 |<--- Data ID=3, seq#=47, fsnOff=15 (fsn=32) 10 |<--- Data ID=3, seq#=47, fsnOff=15 (fsn=32)
11 |---> Ack ID=3, seq:0-32, 34-47 11 |---> Ack ID=3, seq:0-32, 34-47
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
| : | :
Figure 18: Flow with sequence numbers 31 and 33 lost in transit, 31 Flow with sequence numbers 31 and 33 lost in transit, 31 abandoned
abandoned and 33 retransmitted. and 33 retransmitted.
Figure 21
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
 End of changes. 21 change blocks. 
84 lines changed or deleted 191 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/