Skip to content

Instantly share code, notes, and snippets.

@justinjoy

justinjoy/gist:3ed9c5a5d1c82668e54db24d0907b9c9

Last active February 12, 2020 08:35
Show Gist options
  • Save justinjoy/3ed9c5a5d1c82668e54db24d0907b9c9 to your computer and use it in GitHub Desktop.
Save justinjoy/3ed9c5a5d1c82668e54db24d0907b9c9 to your computer and use it in GitHub Desktop.
Download ZIP
srt-rfc-txt-rendered
Raw
gistfile1.txt
mops M. Sharabayko
Internet-Draft Haivision
Intended status: Standards Track J. Kim
Expires: 15 August 2020 SK Telecom Co., Ltd.
12 February 2020
The SRT Protocol
draft-ietf-sharabayko-srt-latest
Abstract
TODO Abstract
Note to Readers
Source for this draft and an issue tracker can be found at
https://github.com/haivision/srt-rfc (https://github.com/haivision/
srt-rfc).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 15 August 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
Sharabayko & Kim Expires 15 August 2020 [Page 1]
Internet-Draft SRT February 2020
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
3. Data Packets . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Control Packets . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Handshake Extension . . . . . . . . . . . . . . . . . 6
4.1.2. Key Material Exchange . . . . . . . . . . . . . . . . 6
4.2. Keep Alive . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. ACK (Acknowledgement) . . . . . . . . . . . . . . . . . . 7
4.4. NAK (Loss Report) . . . . . . . . . . . . . . . . . . . . 8
4.5. Congestion Warning . . . . . . . . . . . . . . . . . . . 8
4.6. Shutdown . . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. ACKACK . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Drop Request . . . . . . . . . . . . . . . . . . . . . . 9
4.9. Peer Error . . . . . . . . . . . . . . . . . . . . . . . 9
5. Bandwidth Estimation . . . . . . . . . . . . . . . . . . . . 9
6. Control Events . . . . . . . . . . . . . . . . . . . . . . . 9
7. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . 9
8.1. Live Transmission mode . . . . . . . . . . . . . . . . . 9
8.2. File Transmission mode . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . . 10
Informative References . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Packet Sequence List coding . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
TODO Introduction
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Sharabayko & Kim Expires 15 August 2020 [Page 2]
Internet-Draft SRT February 2020
3. Data Packets
The data packet structure is as following.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PP|O|Enc|R| Message Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Data +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: data packet structure
F (1 bit): Packet Flag. The flag value of data packet must be 0.
Packet Sequence Number (31 bits):
PP (2 bits): Position of Packet. This field indicates the position
of packet. The value "10b" means the first packet, "00b" is
packets in the middle, "01b" is the last packet. If it is a
single data packet, the value is "11b".
O (1 bit): Order. Indicates whether the message should be delivered
in order or not. This value is not used in Live Transmission
Mode(Section 8.1).
Enc (2 bits): Encryption Flag. The flag bits indicate whether or
not data is encrypted. The value "00b" is not encrypted, "01b"
means ecnrypted data with even key, "11b" signifies ecrypted data
with odd key.
R (1 bit): Retransmitted Packet. This flag bit is clear when a
packet is transmitted very first time. If a packet is
retransmitted, the flag is set as "1".
Message Number (26 bits):
Timestamp (32 bits): The time stamp when the packet is sent. This
Sharabayko & Kim Expires 15 August 2020 [Page 3]
Internet-Draft SRT February 2020
is relative time value starting from when the connection is
established.
Destination Socket ID (32 bits):
Data (variable length): :
4. Control Packets
If the flag bit of SRT packet is set as "1", it should have a
following structure as a control packet.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Message Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Control Information Field +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: control packet structure
F (1 bit): Packet Flag. The control packet must set this flag as
"1".
Message Type (15 bits): Control Message Type. The use of these bits
is determined by the control message type definition.
* "0": Handshake
* "1": Keep Alive
* "2": ACK
* "3": NACK (Loss Report)
* "4": Congestion Warning
* "5": Shutdown
Sharabayko & Kim Expires 15 August 2020 [Page 4]
Internet-Draft SRT February 2020
* "6": ACKACK
* "7": Drop Request
* "8": Peer Error
Reserved (16 bits): This field is reserved for future definition.
Type-specific Information (32 bits): The use of this field is
defined by the particular control message type. Handshake
messages don't use this field.
Timestamp (32 bits): The time stamp when the packet is sent. This
is relative time value starting from when the connection is
established.
Destination Socket ID (32 bits):
Control Information Field (variable length): The use of this field
is defined by Message Type.
4.1. Handshake
Sharabayko & Kim Expires 15 August 2020 [Page 5]
Internet-Draft SRT February 2020
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Field | Extension Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Flow Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SYN Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer IP Address |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extension Type | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Extension Contents +
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 3: handshake packet structure
4.1.1. Handshake Extension
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRT Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRT Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver TsbPd Delay | Sender TsbPd Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: handshake extension structure
4.1.2. Key Material Exchange
Sharabayko & Kim Expires 15 August 2020 [Page 6]
Internet-Draft SRT February 2020
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| V | PT | Sign | Rev | KK|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEKI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cipher | Auth | SE | SLen | KLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Wrapped Key +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ ICV +
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| xSEK |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| oSEK |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 5: unwrapped key structure
4.2. Keep Alive
Keep-alive control packets are exchaged approximately every 10ms to
enable SRT streams to be automattically restored after a connection
loss.
Message Type: The type value of keep-alive control packet is "1".
Type-specific Information: This field is reserved for future
definition.
Control Information Field: This field must not appear in keep-alive
control packets.
4.3. ACK (Acknowledgement)
Acknowledgement control packets are used to provide delivery status
of data packets and RTT information.
Sharabayko & Kim Expires 15 August 2020 [Page 7]
Internet-Draft SRT February 2020
Message Type: The type value of ACK control packet is "2".
Type-specific Information: This field is used for ACK sequence
number.
The Control Information Field of ACK control packet is extended as
following.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Acknowledged Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTT variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available Buffer Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packets Receiving Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Estimated Link Capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: control information field of ACK control packet
4.4. NAK (Loss Report)
Negative acknowledgement control packets are used to signal failed
data packet deliveries.
Message Type: The type value of NAK control packet is "3".
Type-specific Information: This field is reserved for future
definition.
The Control Information Field of NAK control packet is a lost packet
number, or list of lost packet sequence numbers. See packet sequence
number coding in Appendix A.
4.5. Congestion Warning
4.6. Shutdown
Shutdown control packets are used to initiate the closing of an SRT
connection.
Sharabayko & Kim Expires 15 August 2020 [Page 8]
Internet-Draft SRT February 2020
Message Type: The type value of Shutdown control packet is "5".
Type-specific Information: This field is reserved for future
definition.
Control Information Field: This field must not appear in keep-alive
control packets.
4.7. ACKACK
ACKACK control packets are used to acknowledge the reception of an
ACK, and are instrumental in the ongoing caculation of RTT.
Message Type: The type value of ACKACK control packet is "6".
Type-specific Information: This field is used for ACK sequence
number.
Control Information Field: This field must not appear in keep-alive
control packets.
4.8. Drop Request
4.9. Peer Error
5. Bandwidth Estimation
6. Control Events
7. Timers
8. Congestion Control
8.1. Live Transmission mode
8.2. File Transmission mode
9. Security Considerations
TODO Security
10. IANA Considerations
TODO IANA
Sharabayko & Kim Expires 15 August 2020 [Page 9]
Internet-Draft SRT February 2020
Acknowledgments
TODO acknowledge.
References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Informative References
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Packet Sequence List coding
For any single packet sequence number or two consecutive sequence
numbers, it uses the original sequence number in the field. The
first bit must start with "0".
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: single or two consecutive sequence numbers coding
For any consectutive packet seqeunce numbers that the differnece
between the last and first is more than 1, only record the first (a)
and the the last (b) sequence numbers in the list field, and modify
the the first bit of a to "1".
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Sequence Number a (first) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Sequence Number b (last) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: list of sequence numbers coding
Sharabayko & Kim Expires 15 August 2020 [Page 10]
Internet-Draft SRT February 2020
Authors' Addresses
Maxim Sharabayko
Haivision
Email: maxlovic@gmail.com
Jeongseok Kim
SK Telecom Co., Ltd.
Email: jeongseok.kim@sk.com
Sharabayko & Kim Expires 15 August 2020 [Page 11]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment