< draft-mcquistin-augmented-tcp-example-00.txt		draft-mcquistin-augmented-tcp-example-01.txt >
	Network Working Group S. McQuistin		Network Working Group S. McQuistin
	Internet-Draft V. Band		Internet-Draft V. Band
	Intended status: Experimental D. Jacob		Intended status: Experimental D. Jacob
	Expires: 6 May 2021 C. S. Perkins		Expires: 6 November 2021 C. S. Perkins
	University of Glasgow		University of Glasgow
	2 November 2020		5 May 2021
	Describing TCP with Augmented Packet Header Diagrams		Describing TCP with Augmented Packet Header Diagrams
	draft-mcquistin-augmented-tcp-example-00		draft-mcquistin-augmented-tcp-example-01
	Abstract		Abstract
	This document describes TCP, and a number of its extensions, using		This document describes TCP, and a number of its extensions, using
	Augmented Packet Header Diagrams. This document is an example of the		Augmented Packet Header Diagrams. This document is an example of the
	Augmented Packet Header Diagram language: it is not intended as a		Augmented Packet Header Diagram language: it is not intended as a
	contribution to any ongoing or future work on maintaining or		contribution to any ongoing or future work on maintaining or
	extending TCP.		extending TCP.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 6 May 2021.		This Internet-Draft will expire on 6 November 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. TCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. TCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Comparison with draft-ietf-tcpm-rfc793bis . . . . . . . . . . 7		4. Comparison with draft-ietf-tcpm-rfc793bis . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. Informative References . . . . . . . . . . . . . . . . . . . 8		8. Informative References . . . . . . . . . . . . . . . . . . . 8
	Appendix A. Source code repository . . . . . . . . . . . . . . . 9		Appendix A. Source code repository . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This document uses Augmented Packet Header Diagrams		This document uses Augmented Packet Header Diagrams
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	this document does not necessarily reflect TCP, and its extensions,		this document does not necessarily reflect TCP, and its extensions,
	as presently standardised.		as presently standardised.
	2. TCP Header		2. TCP Header
	This document describes the TCP protocol. The TCP protocol uses TCP		This document describes the TCP protocol. The TCP protocol uses TCP
	Headers.		Headers.
	A TCP Header is formatted as follows:		A TCP Header is formatted as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Port | Destination Port |		| Source Port | Destination Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sequence Number |		| Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Acknowledgment Number |		| Acknowledgment Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data | |C|E|U|A|P|R|S|F| |		| Data | |C|E|U|A|P|R|S|F| |
	| Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window Size |		| Offset| Rsrvd |W|C|R|C|S|S|Y|I| Window Size |
	| | |R|E|G|K|H|T|N|N| |		| | |R|E|G|K|H|T|N|N| |
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	Sequence Number: 32 bits. The sequence number of the first data		Sequence Number: 32 bits. The sequence number of the first data
	octet in this segment (except when the SYN flag is set). If SYN		octet in this segment (except when the SYN flag is set). If SYN
	is set the sequence number is the initial sequence number (ISN)		is set the sequence number is the initial sequence number (ISN)
	and the first data octet is ISN+1.		and the first data octet is ISN+1.
	Acknowledgment Number: 32 bits. If the ACK control bit is set, this		Acknowledgment Number: 32 bits. If the ACK control bit is set, this
	field contains the value of the next sequence number the sender of		field contains the value of the next sequence number the sender of
	the segment is expecting to receive. Once a connection is		the segment is expecting to receive. Once a connection is
	established, this is always sent.		established, this is always sent.
	Data Offset (DOffset): 4 bits. The number of 32 bit words in the TCP		Data Offset (DOffset): 4 bits; DOffset >= 5. The number of 32 bit
	Header. This indicates where the data begins. The TCP header		words in the TCP Header. This indicates where the data begins.
	(even one including options) is an integral number of 32 bits		The TCP header (even one including options) is an integral number
	long.		of 32 bits long.
	Reserved (Rsrvd): 4 bits. A set of control bits reserved for future		Reserved (Rsrvd): 4 bits; Rsrvd == 0. A set of control bits reserved
	use. Must be zero in generated segments and must be ignored in		for future use. Must be zero in generated segments and must be
	received segments, if corresponding future features are		ignored in received segments, if corresponding future features are
	unimplemented by the sending or receiving host.		unimplemented by the sending or receiving host.
	CWR: 1 bit. Congestion Window Reduced		CWR: 1 bit. Congestion Window Reduced
	ECE: 1 bit. ECN-Echo		ECE: 1 bit. ECN-Echo
	URG: 1 bit. Urgent Pointer field significant		URG: 1 bit. Urgent Pointer field significant
	ACK: 1 bit. Acknowledgment field significant.		ACK: 1 bit. Acknowledgment field significant.
	PSH: 1 bit. Push Function (see the Send Call description)		PSH: 1 bit. Push Function (see the Send Call description)
	RST: 1 bit. Reset the connection		RST: 1 bit. Reset the connection
	SYN: 1 bit. Synchronize sequence numbers		SYN: 1 bit. Synchronize sequence numbers
	FIN: 1 bit. No more data from sender.		FIN: 1 bit; (FIN == 0) || (SYN == 0). No more data from sender.
	Window Size: 16 bits. The number of data octets beginning with the		Window Size: 16 bits. The number of data octets beginning with the
	one indicated in the acknowledgment field that the sender of this		one indicated in the acknowledgment field that the sender of this
	segment is willing to accept.		segment is willing to accept.
	The window size MUST be treated as an unsigned number, or else		The window size MUST be treated as an unsigned number, or else
	large window sizes will appear like negative windows and TCP will		large window sizes will appear like negative windows and TCP will
	not work (MUST-1). It is RECOMMENDED that implementations will		not work (MUST-1). It is RECOMMENDED that implementations will
	reserve 32-bit fields for the send and receive window sizes in the		reserve 32-bit fields for the send and receive window sizes in the
	connection record and do all window computations with 32 bits		connection record and do all window computations with 32 bits
	skipping to change at page 5, line 11 ¶		skipping to change at page 5, line 11 ¶
	only when DOffset > 5. Options may occupy space at the end of the		only when DOffset > 5. Options may occupy space at the end of the
	TCP header and are a multiple of 8 bits in length. All options		TCP header and are a multiple of 8 bits in length. All options
	are included in the checksum.		are included in the checksum.
	Payload. Payload.		Payload. Payload.
	3. TCP Options		3. TCP Options
	A TCP Option is one of: a EOL Option, a NOOP Option, a Maximum		A TCP Option is one of: a EOL Option, a NOOP Option, a Maximum
	Segment Size Option, a Window Scale Factor Option, a Timestamp		Segment Size Option, a Window Scale Factor Option, a Timestamp
	Option, or a SACK Permitted Option.		Option, a SACK Permitted Option, or a SACK Range Option.
	An EOL Option is formatted as follows:		An EOL Option is formatted as follows:
	0 1 2 3		0
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| 0 |		| 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	where:		where:
	Option Kind (Kind): 1 byte; Kind == 0. This option code indicates		Option Kind (Kind): 1 byte; Kind == 0. This option code indicates
	the end of the option list.		the end of the option list.
	A NOOP Option is formatted as follows:		A NOOP Option is formatted as follows:
	0 1 2 3		0
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| 1 |		| 1 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	where:		where:
	Option Kind (Kind): 1 byte; Kind == 1. This option code can be used		Option Kind (Kind): 1 byte; Kind == 1. This option code can be used
	between options, for example, to align the beginning of a		between options, for example, to align the beginning of a
	subsequent option on a word boundary.		subsequent option on a word boundary.
	A Maximum Segment Size Option is formatted as follows:		A Maximum Segment Size Option is formatted as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 2 | Length | Maximum Segment Size (MSS) |		| 2 | Length | Maximum Segment Size (MSS) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Option Kind (Kind): 1 byte; Kind == 2. If this option is present,		Option Kind (Kind): 1 byte; Kind == 2. If this option is present,
	then it communicates the maximum receive segment size at the TCP		then it communicates the maximum receive segment size at the TCP
	endpoint that sends this segment.		endpoint that sends this segment.
	Option Length (Length): 1 byte; Length == 4. Option length.		Option Length (Length): 1 byte; Length == 4. Option length.
	Maximum Segment Size (MSS): 2 bytes. The maximum segment size		Maximum Segment Size (MSS): 2 bytes. The maximum segment size
	allowed.		allowed.
	A Window Scale Factor Option is formatted as follows:		A Window Scale Factor Option is formatted as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 3 | Length | Window Scale Factor |		| 3 | Length | Window Scale Factor |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Option Kind (Kind): 1 byte; Kind == 3. If present, this option		Option Kind (Kind): 1 byte; Kind == 3. If present, this option
	carries the window scale factor.		carries the window scale factor.
	Option Length (Length): 1 byte; Length == 3. Option length.		Option Length (Length): 1 byte; Length == 3. Option length.
	Window Scale Factor: 1 byte. Window scale factor.		Window Scale Factor: 1 byte. Window scale factor.
	A Timestamp Option is formatted as follows:		A Timestamp Option is formatted as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 8 | Length |		| 8 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp value (TSval) |		| Timestamp value (TSval) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Timestamp echo reply (TSecr) |		| Timestamp echo reply (TSecr) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	carries a timestamp and an echoed timestamp.		carries a timestamp and an echoed timestamp.
	Option Length (Length): 1 byte; Length == 10. Option length.		Option Length (Length): 1 byte; Length == 10. Option length.
	Timestamp value (TSval): 4 bytes. TSval.		Timestamp value (TSval): 4 bytes. TSval.
	Timestamp echo reply (TSecr): 4 bytes. TSecr.		Timestamp echo reply (TSecr): 4 bytes. TSecr.
	A SACK Permitted Option is formatted as follows:		A SACK Permitted Option is formatted as follows:
	0 1 2 3		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 4 | Length |		| 4 | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Option Kind (Kind): 1 byte; Kind == 4. If present, this option		Option Kind (Kind): 1 byte; Kind == 4. If present, this option
	indicates that SACK is permitted.		indicates that SACK is permitted.
	Option Length (Length): 1 byte; Length == 2. Option length.		Option Length (Length): 1 byte; Length == 2. Option length.
	4. Comparison with draft-ietf-tcpm-rfc793bis		A SACK Range Option is formatted as follows:
	While the purpose of this document is to give an example use of the		0 1 2 3
	Augmented Packet Header Diagrams, and not to contribute to ongoing or		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
	future TCP standardisation efforts, it is instructive to draw		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	comparisons with documents that describe the same protocol. In		| 5 | Length |
	particular, the descriptions of the TCP header (Section 2) and TCP		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	options (Section 3) from this document can be compared with		| [Blocks] |
	Section 3.1 of [draft-ietf-tcpm-rfc793bis]. We have adopted the same		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	field descriptions to help with this comparison.
	Beyond the broad similarities, there are a number of elements where		where:
	this document describes the protocol differently. For example, the
	TCP header as defined in [draft-ietf-tcpm-rfc793bis] contains a
	variable-length padding field which is not present in the description
	contained in this document. The Padding field is used to pad the TCP
	header to a 32-bit boundary, and to ensure that the Payload begins on
	a 32-bit boundary. The length of the Padding field is the difference
	between the value of the Data Offset field and the length of the
	Options field. However, the length of the Options field is itself
	dependent on the value of the Data Offset field and the particular
	set of options contained within an instance of the TCP header. The
	Augmented Packet Header Diagram format cannot express this logic: the
	lengths of both the Padding and Payload fields would be variable. To
	overcome this, as shown in Section 2, the description of TCP given in
	this document relies upon End of List options being syntactically
	identical to Padding (i.e., being all zeroes). This highlights the
	limitations of the Augmented Packet Header Diagram format: prose text
	is much more expressive.
	However, the precision required by the Augmented Packet Header		Option Kind (Kind): 1 byte; Kind == 5. If present, this option
	Diagram can be beneficial. For example, the description of the		contains one or more SACK blocks.
	Options field in this document sets out an explicit length and
	presence constraint, where [draft-ietf-tcpm-rfc793bis] indicates that
	it is "variable". Similar constraints exist in the description given
	in [draft-ietf-tcpm-rfc793bis], but they are contained with the prose
	description of the field.
	In summary, the most striking comparison to be made is that the		Option Length (Length): 1 byte. Option length.
	description of TCP given in this document is largely similar to that
	given in [draft-ietf-tcpm-rfc793bis]. By retaining the overall		Blocks: (Length-2)/8 SACK Blocks. SACK blocks.
	structure of a packet header diagram and an accommpanying list of
	descriptions for each field, the Augmented Packet Header Diagram		A SACK Block is formatted as follows:
	format is close to that already in use. This is encouraging: it
	indicates that the Augmented Packet Header Diagram language can be		0 1 2 3
	used to describe realistic protocols, without introducing a format		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
	that is unfamiliar or difficult to write.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Left Edge |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Right Edge |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			where:
			Left Edge: 4 bytes. This is the first sequence number of this block.
			Right Edge: 4 bytes. This is the sequence number immediately
			following the last sequence number of this block.
			4. Comparison with draft-ietf-tcpm-rfc793bis
			The Augmented Packet Header Diagram format used in this example has
			also been adopted within [draft-ietf-tcpm-rfc793bis]. This example
			goes beyond [draft-ietf-tcpm-rfc793bis], and includes a number of TCP
			options that are not defined as part of that document, including the
			Window Scale Factor, Timestamp, SACK permitted, and SACK block
			options. In addition, the definition of the TCP header (Section 2)
			in this document includes a number of field constraints that are not
			specified in [draft-ietf-tcpm-rfc793bis].
			The purpose of this document is to give an example use of the
			Augmented Packet Header Diagrams, and not to contribute to ongoing or
			future TCP standardisation efforts. We include additional
			constraints and TCP options to demonstrate the ease with which these
			can be expressed in our format, and that these are then supported by
			the generated parser code.
	5. IANA Considerations		5. IANA Considerations
	This document contains no actions for IANA.		This document contains no actions for IANA.
	6. Security Considerations		6. Security Considerations
	The security implications of the Augmented Packet Header Diagrams		The security implications of the Augmented Packet Header Diagrams
	format are considered in [AUGMENTED-DIAGRAMS].		format are considered in [AUGMENTED-DIAGRAMS].
	skipping to change at page 8, line 43 ¶		skipping to change at page 8, line 43 ¶
	This work has received funding from the UK Engineering and Physical		This work has received funding from the UK Engineering and Physical
	Sciences Research Council under grant EP/R04144X/1.		Sciences Research Council under grant EP/R04144X/1.
	8. Informative References		8. Informative References
	[AUGMENTED-DIAGRAMS]		[AUGMENTED-DIAGRAMS]
	McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,		McQuistin, S., Band, V., Jacob, D., and C. S. Perkins,
	"Describing Protocol Data Units with Augmented Packet		"Describing Protocol Data Units with Augmented Packet
	Header Diagrams", Work in Progress, Internet-Draft, draft-		Header Diagrams", Work in Progress, Internet-Draft, draft-
	mcquistin-augmented-ascii-diagrams-07, 2 November 2020,		mcquistin-augmented-ascii-diagrams-08, 5 May 2021,
	<http://www.ietf.org/internet-drafts/draft-mcquistin-		<http://www.ietf.org/internet-drafts/draft-mcquistin-
	augmented-ascii-diagrams-07.txt>.		augmented-ascii-diagrams-08.txt>.
	[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,		[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
	September 1981, <https://www.rfc-editor.org/info/rfc793>.		September 1981, <https://www.rfc-editor.org/info/rfc793>.
	[draft-ietf-tcpm-rfc793bis]		[draft-ietf-tcpm-rfc793bis]
	Eddy, W., "Transmission Control Protocol (TCP)		Eddy, W., "Transmission Control Protocol (TCP)
	Specification", Work in Progress, Internet-Draft, draft-		Specification", Work in Progress, Internet-Draft, draft-
	ietf-tcpm-rfc793bis-19, 27 October 2020,		ietf-tcpm-rfc793bis-21, 3 May 2021, <http://www.ietf.org/
	<http://www.ietf.org/internet-drafts/draft-ietf-tcpm-		internet-drafts/draft-ietf-tcpm-rfc793bis-21.txt>.
	rfc793bis-19.txt>.
	Appendix A. Source code repository		Appendix A. Source code repository
	The source code for tooling that can be used to parse this document,		The source code for tooling that can be used to parse this document,
	and generate parser code for the protocol it describes, is available		and generate parser code for the protocol it describes, is available
	from https://github.com/glasgow-ipl/ips-protodesc-code.		from https://github.com/glasgow-ipl/ips-protodesc-code.
	Authors' Addresses		Authors' Addresses
	Stephen McQuistin		Stephen McQuistin
End of changes. 28 change blocks.
	83 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/