draft-mcquistin-augmented-ascii-diagrams-04.txt   draft-mcquistin-augmented-ascii-diagrams-05.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: 26 October 2020 C. S. Perkins Expires: 19 December 2020 C. S. Perkins
University of Glasgow University of Glasgow
24 April 2020 17 June 2020
Describing Protocol Data Units with Augmented Packet Header Diagrams Describing Protocol Data Units with Augmented Packet Header Diagrams
draft-mcquistin-augmented-ascii-diagrams-04 draft-mcquistin-augmented-ascii-diagrams-05
Abstract Abstract
This document describes a machine-readable format for specifying the This document describes a machine-readable format for specifying the
syntax of protocol data units within a protocol specification. This syntax of protocol data units within a protocol specification. This
format is comprised of a consistently formatted packet header format is comprised of a consistently formatted packet header
diagram, followed by structured explanatory text. It is designed to diagram, followed by structured explanatory text. It is designed to
maintain human readability while enabling support for automated maintain human readability while enabling support for automated
parser generation from the specification document. This document is parser generation from the specification document. This document is
itself an example of how the format can be used. itself an example of how the format can be used.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 26 October 2020. This Internet-Draft will expire on 19 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
4. Augmented Packet Header Diagrams . . . . . . . . . . . . . . 10 4. Augmented Packet Header Diagrams . . . . . . . . . . . . . . 10
4.1. PDUs with Fixed and Variable-Width Fields . . . . . . . . 10 4.1. PDUs with Fixed and Variable-Width Fields . . . . . . . . 10
4.2. PDUs That Cross-Reference Previously Defined Fields . . . 13 4.2. PDUs That Cross-Reference Previously Defined Fields . . . 13
4.3. PDUs with Non-Contiguous Fields . . . . . . . . . . . . . 15 4.3. PDUs with Non-Contiguous Fields . . . . . . . . . . . . . 15
4.4. PDUs with Constraints on Field Values . . . . . . . . . . 16 4.4. PDUs with Constraints on Field Values . . . . . . . . . . 16
4.5. PDUs That Extend Sub-Structures . . . . . . . . . . . . . 17 4.5. PDUs That Extend Sub-Structures . . . . . . . . . . . . . 17
4.6. Storing Data for Parsing . . . . . . . . . . . . . . . . 18 4.6. Storing Data for Parsing . . . . . . . . . . . . . . . . 18
4.7. Connecting Structures with Functions . . . . . . . . . . 19 4.7. Connecting Structures with Functions . . . . . . . . . . 19
4.8. Specifying Enumerated Types . . . . . . . . . . . . . . . 20 4.8. Specifying Enumerated Types . . . . . . . . . . . . . . . 20
4.9. Specifying Protocol Data Units . . . . . . . . . . . . . 21 4.9. Specifying Protocol Data Units . . . . . . . . . . . . . 21
4.10. Importing PDU Definitions from Other Documents . . . . . 21 4.10. Importing PDU Definitions from Other Documents . . . . . 22
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
9. Informative References . . . . . . . . . . . . . . . . . . . 23 9. Informative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. ABNF specification . . . . . . . . . . . . . . . . . 24 Appendix A. ABNF specification . . . . . . . . . . . . . . . . . 24
A.1. Constraint Expressions . . . . . . . . . . . . . . . . . 24 A.1. Constraint Expressions . . . . . . . . . . . . . . . . . 24
A.2. Augmented packet diagrams . . . . . . . . . . . . . . . . 25 A.2. Augmented packet diagrams . . . . . . . . . . . . . . . . 25
Appendix B. Source code repository . . . . . . . . . . . . . . . 25 Appendix B. Source code repository . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
skipping to change at page 14, line 29 skipping to change at page 14, line 27
Payload Type (PT): 7 bits. This is a fixed-width field, as described Payload Type (PT): 7 bits. This is a fixed-width field, as described
previously. previously.
Sequence Number (PT): 16 bits. This is a fixed-width field, as Sequence Number (PT): 16 bits. This is a fixed-width field, as
described previously. described previously.
Timestamp (PT): 32 bits. This is a fixed-width field, as described Timestamp (PT): 32 bits. This is a fixed-width field, as described
previously. previously.
Synchronization Source identifier: 1 * Source Identifier. This is a Synchronization Source identifier: 1 Source Identifier. This is a
field whose structure is a previously defined PDU format (Source field whose structure is a previously defined PDU format (Source
Identifier). To indicate this, the width of the field is Identifier). To indicate this, the width of the field is
expressed in terms of cross-referenced structure. When used in expressed in terms of cross-referenced structure. When used in
constraint expressions, PDU names refer to the length of that PDU constraint expressions, PDU names refer to the length of that PDU
structure. structure.
Contributing Source identifiers: CC * Source Identifier. Where a Contributing Source identifiers: CC Source Identifier. Where a field
field is comprised of a sequence of previously defined structures, is comprised of a sequence of previously defined structures,
square brackets can be used to indicate this in the diagram. The square brackets can be used to indicate this in the diagram. The
length of the sequence can be defined using the constraint length of the sequence can be defined using the constraint
expression grammar as described earlier. expression grammar as described earlier. Where the length is
unknown, the type of each element of the sequence must be given in
square brackets.
In this example, both a PDU name (Source Identifier) and a field In this example, both a PDU name (Source Identifier) and a field
name (CC) are used in the constraint expression. The PDU name name (CC) are used in the constraint expression. The PDU name
refers to the length of the PDU, while the field name refers to refers to the length of the PDU, while the field name refers to
the value of the field. This is possible because field names the value of the field. This is possible because field names
cannot be the same as previously defined PDU names. cannot be the same as previously defined PDU names.
Header Extension: 32 bits; present only when X == 1. This is a field Header Extension: 32 bits; present only when X == 1. This is a field
whose presence is predicated on an expression given using the whose presence is predicated on an expression given using the
constraint expression grammar described earlier. Optional fields constraint expression grammar described earlier. Optional fields
skipping to change at page 15, line 17 skipping to change at page 15, line 18
[Note that this example deviates from the format as described in [Note that this example deviates from the format as described in
[RFC3550]. As specified in that document, the Header Extension [RFC3550]. As specified in that document, the Header Extension
would be a cross-referenced structure. This is not shown here for would be a cross-referenced structure. This is not shown here for
brevity.] brevity.]
Payload. The length of the Payload is not specified, and hence needs Payload. The length of the Payload is not specified, and hence needs
to be inferred from the total length of the packet and the lengths to be inferred from the total length of the packet and the lengths
of the known fields. There can only be one field of unspecified of the known fields. There can only be one field of unspecified
size in a PDU. size in a PDU.
Padding: Padding Count bytes; present only when (P == 1) and Padding: PC bytes; present only when (P == 1) && (PC > 0). This is a
(Padding Count > 0). variable size field, with size dependent on a later field in the
This is a variable size field, with size dependent on a later packet. Fields can only depend on the value of a later field if
field in the packet. Fields can only depend on the value of a they follow a field with unspecified size.
later field if they follow a field with unspecified size.
Padding Count: 1 byte; present only when P == 1. This is a fixed- Padding Count (PC): 1 byte; present only when P == 1. This is a
width field, as previously discussed. fixed-width field, as previously discussed.
4.3. PDUs with Non-Contiguous Fields 4.3. PDUs with Non-Contiguous Fields
In some binary formats, fields are striped across multiple non- In some binary formats, fields are striped across multiple non-
contiguous bits. This is often to allow for backwards compatibility contiguous bits. This is often to allow for backwards compatibility
with previous definitions of the same fields in earlier documents: with previous definitions of the same fields in earlier documents:
striping in this way allows for careful use of the possible range of striping in this way allows for careful use of the possible range of
values. values.
This format is illustrated using the STUN Message Type This format is illustrated using the STUN Message Type
skipping to change at page 16, line 52 skipping to change at page 16, line 50
where: where:
Header Form (HF): 1 bit; HF == 1. This is a fixed-width field, Header Form (HF): 1 bit; HF == 1. This is a fixed-width field,
constrained to be a of an known, exact value. At most one field constrained to be a of an known, exact value. At most one field
value constraint may be given, and if provided, it must be given value constraint may be given, and if provided, it must be given
as a boolean expression, separated by a semi-colon in the field as a boolean expression, separated by a semi-colon in the field
definition name (i.e., the text contained within the <dt> tag). definition name (i.e., the text contained within the <dt> tag).
If present, a value constraint must follow the name, short name, If present, a value constraint must follow the name, short name,
and length of the field, but appear before any presence and length of the field, but appear before any presence
constraint, if applicable. constraint, if applicable. The order of the field must be the
same in both the diagram and description list.
The order of the field must be the same in both the diagram and
description list.
Fixed Bit (FB): 1 bit; FB == 1. This is a fixed-width field, with a Fixed Bit (FB): 1 bit; FB == 1. This is a fixed-width field, with a
value constraint, as previously described. value constraint, as previously described.
Long Packet Type (T): 2 bits. This is a fixed-width field as Long Packet Type (T): 2 bits. This is a fixed-width field as
previously described. previously described.
Reserved Bits (R): 2 bits. This is a fixed-width field as previously Reserved Bits (R): 2 bits. This is a fixed-width field as previously
described. described.
skipping to change at page 20, line 15 skipping to change at page 20, line 15
func apply_protection(to: Unprotected Packet) func apply_protection(to: Unprotected Packet)
-> Protected Packet: -> Protected Packet:
apply packet protection to payload apply packet protection to payload
apply header protection to first_byte and packet_number apply header protection to first_byte and packet_number
construct appropriate Protected Packet based on first_byte construct appropriate Protected Packet based on first_byte
return Protected Packet return Protected Packet
In this example, 'Unprotected Packet' and 'Protected Packet' are In this example, 'Unprotected Packet' and 'Protected Packet' are
existing types. existing types.
To indicate that a structure is created from another by way of a To indicate that a PDU is created from another by way of a function,
function: "A/An <structure type A> is constructed from a <structure the sentence "A/An <PDU name A> is parsed from a <PDU name B> using
type B> using the <function name>(<parameters>) function.". This the <function name> function" is used. This indicates that a PDU A
indicates that a structure of type A is generated using the named is generated by passing PDU B into the named function. The function
function. The parameters in the function call are named fields from must take a single parameter, of the same type as PDU B, and return a
structure type B. They must match the function signature, both in PDU B.
number and type.
To indicate that a PDU can be serialised to another by way of a
function, the sentence "A/An <PDU name A> is serialised to a <PDU
name B> using the <function name> function" is used. This indicates
that a PDU B is generated by passing PDU A into the named function.
The function must take a single parameter, of the same type as PDU A,
and return a PDU B.
4.8. Specifying Enumerated Types 4.8. Specifying Enumerated Types
In addition to the use of the sub-structures, it is desirable to be In addition to the use of the sub-structures, it is desirable to be
able to define a type that may take the value of one of a set of able to define a type that may take the value of one of a set of
alternative structures. alternative structures.
The alternative structures that comprise an enumerated type are The alternative structures that comprise an enumerated type are
identified using the exact phrase "The <enumerated type name> is one identified using the exact phrase "The <enumerated type name> is one
of: <list of structure names>" where the list of structure names is a of: <list of structure names>" where the list of structure names is a
skipping to change at page 21, line 5 skipping to change at page 21, line 13
A PING Frame is formatted as follows: A PING Frame 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Frame Type (FT): 1 * Variable-Length Integer Encoding; FT == 1. Frame Type (FT): 1 Variable-Length Integer Encoding; FT == 1. Frame
Frame type, set to 1 for PING frames. type, set to 1 for PING frames.
A HANDSHAKE_DONE Frame is formatted as follows: A HANDSHAKE_DONE Frame 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 30 | | 30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
Frame Type (FT): 1 * Variable-Length Integer Encoding; FT == 30. Frame Type (FT): 1 Variable-Length Integer Encoding; FT == 30. Frame
Frame type, set to 30 for HANDSHAKE_DONE frames. type, set to 30 for HANDSHAKE_DONE frames.
A Frame is either a PING Frame or a HANDSHAKE_DONE Frame. A Frame is either a PING Frame or a HANDSHAKE_DONE Frame.
4.9. Specifying Protocol Data Units 4.9. Specifying Protocol Data Units
A document will set out different structures that are not, on their A document will set out different structures that are not, on their
own, protocol data units. To capture the parsing or serialisation of own, protocol data units. To capture the parsing or serialisation of
a protocol, it is necessary to be able to identify or construct those a protocol, it is necessary to be able to identify or construct those
packets that are valid PDUs. As a result, it is necessary for the packets that are valid PDUs. As a result, it is necessary for the
document to identify those structures that are PDUs. document to identify those structures that are PDUs.
skipping to change at page 21, line 41 skipping to change at page 21, line 49
The PDUs that comprise a protocol are identified using the exact The PDUs that comprise a protocol are identified using the exact
phrase "This document describes the <protocol name> protocol, The phrase "This document describes the <protocol name> protocol, The
<protocol name> protocol uses <list of PDU names>" where the list of <protocol name> protocol uses <list of PDU names>" where the list of
PDU names is a comma separated list (with the last element, if there PDU names is a comma separated list (with the last element, if there
is more than one element, preceded by 'and'), each optionally is more than one element, preceded by 'and'), each optionally
preceded by "a" or "an". The PDU names must be structure names preceded by "a" or "an". The PDU names must be structure names
defined in the document or a linked document. The PDU names are defined in the document or a linked document. The PDU names are
pluralised in the list. A document must contain exactly one instance pluralised in the list. A document must contain exactly one instance
of this phrase. of this phrase.
The Example protocol uses Long Headers, STUN Message Types, IPv4 This document describes the Example protocol. The Example protocol
Headers, and RTP Data Packets. uses Long Headers, STUN Message Types, IPv4 Headers, and RTP Data
Packets.
4.10. Importing PDU Definitions from Other Documents 4.10. Importing PDU Definitions from Other Documents
Protocols are often specified across multiple documents, either Protocols are often specified across multiple documents, either
because the specification of a protocol's data units has changed over because the specification of a protocol's data units has changed over
time, or because of explicit extension points contained in the time, or because of explicit extension points contained in the
protocol's original specification. To allow a document to make use protocol's original specification. To allow a document to make use
of a previous PDU definition, it is possible to import PDU of a previous PDU definition, it is possible to import PDU
definitions (written in the format described in this document) from definitions (written in the format described in this document) from
other documents. other documents.
skipping to change at page 25, line 10 skipping to change at page 25, line 10
Appendix A. ABNF specification Appendix A. ABNF specification
A.1. Constraint Expressions A.1. Constraint Expressions
cond-expr = eq-expr "?" cond-expr ":" eq-expr cond-expr = eq-expr "?" cond-expr ":" eq-expr
eq-expr = bool-expr eq-op bool-expr eq-expr = bool-expr eq-op bool-expr
bool-expr = ord-expr bool-op ord-expr bool-expr = ord-expr bool-op ord-expr
ord-expr = add-expr ord-op add-expr ord-expr = add-expr ord-op add-expr
add-expr = mul-expr add-op mul-expr add-expr = mul-expr add-op mul-expr
mul-expr = expr mul-op expr mul-expr = pow-expr mul-op pow-expr
pow-expr = expr pow-op expr
expr = *DIGIT / field-name / expr = *DIGIT / field-name /
field-name-ws / "(" expr ")" field-name-ws / "(" expr ")"
field-name = *ALPHA field-name = ALPHA *(ALPHA / DIGIT)
field-name-ws = *(field-name " ") field-name-ws = *(field-name " ")
pow-op = "^"
mul-op = "*" / "/" / "%" mul-op = "*" / "/" / "%"
add-op = "+" / "-" add-op = "+" / "-"
ord-op = "<=" / "<" / ">=" / ">" ord-op = "<=" / "<" / ">=" / ">"
bool-op = "&&" / "||" / "!" bool-op = "&&" / "||" / "!"
eq-op = "==" / "!=" eq-op = "==" / "!="
A.2. Augmented packet diagrams A.2. Augmented packet diagrams
Future revisions of this draft will include an ABNF specification for Future revisions of this draft will include an ABNF specification for
the augmented packet diagram format described in Section 4. Such a the augmented packet diagram format described in Section 4. Such a
 End of changes. 18 change blocks. 
35 lines changed or deleted 43 lines changed or added

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