-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathntp-extended-information-ef.xml
351 lines (289 loc) · 13.3 KB
/
ntp-extended-information-ef.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC0958 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0958.xml">
<!ENTITY RFC5905 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC2827 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2434 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-stenn-ntp-extended-information-04" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Network Time Protocol Extended Information">Network Time
Protocol Extended Information Extension Field</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Harlan Stenn" initials="H." surname="Stenn">
<organization>Network Time Foundation</organization>
<address>
<postal>
<street>P.O. Box 918</street>
<!-- Reorder these if your country does things differently -->
<city>Talent, OR</city>
<region/>
<code>97540</code>
<country>US</country>
</postal>
<phone/>
<email>[email protected]</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- other authors -->
<date year="2019"/>
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current
year is specified, xml2rfc will fill in the current day and month
for you. If the year is not the current one, it is necessary to
specify at least a month (xml2rfc assumes day="1" if not specified
for the purpose of calculating the expiry date). With drafts it is
normally sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working
Group", which is used by the RFC Editor as a nod to the history of
the IETF. -->
<keyword>NTP</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:</t>
<t>
The source code and issues list for this draft can be found in
https://github.com/hstenn/ietf-ntp-extended-information-ef
</t>
<t>
The core network packet used by NTP has no spare bits
available for reporting additional state information and no
larger data areas available for larger amounts of information.
This proposal offers a new extension field that would contain
this additional information.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The core NTP packet format has changed little since <xref
target="RFC0958">RFC 958</xref> was published in 1985. Since
then, there has been demonstrated need to convey additional
information about NTP's state in an NTP packet but no
backward-compatible way to usurp the few otherwise potentially
available bits has been found, and no larger data areas are
available in the core packet structure. This proposal offers
a new extension field that would contain this additional
information.
</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="The Extended Information Extension Field">
<t>
The Field Type of the Extended Information EF includes a
version number field in the low-order bits of the first octet,
to make it easier to evolve this specification. The initial
specification for this proposal uses Version 0, which equates
to 0x0009 [ADJUST AS NEEDED BASED ON IANA, IF AN IANA REGISTRY
IS USED]. A future revision for Version 1 would use 0x0109
[IBID].
</t>
<t>
The payload for Version 0 is comprised of a two octet Content
Descriptor followed by a two octet Content Data field, as
described below.
</t>
<t><figure title="NTP Extension Field: Extended Information">
<artwork name="NTP Extension Field: Extended Information"><![CDATA[
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
+---------------+---------------+-------------------------------+
| Field Type | Field Length |
+-------------------------------+-------------------------------+
| Content Descriptor 1 | Content Data 1 |
+---------------------------------------------------------------+]]></artwork>
</figure></t>
<t>
Field Type: TBD (Recommendation for IANA: 0x0009
(Extended-Information, Version 0))
</t>
<t>Field Length: as needed</t>
<section title="Version 0 Content Descriptor and Content Data fields">
<t>
There are 16 bits available for state information in the
Version 0 Extended Information Content Descriptor. These
bits are allocated as follows:
<list style="hanging">
<t hangText="0x0001:">
TAI Offset is stored in the low-order 8 bits (the second
octet) of the Content Data.
</t>
<t hangText="0x0002:">
Interleave Mode indicator in the low order bit of the
first octet of the Content Data. [NOTE: this may not be
useful, and it can be removed if desired. It can serve
as a belt-and-suspenders way to identify when a packet
contains interleaved timestamps.]
</t>
<t hangText="0xFFFD:">
Reserved for future versions. SHOULD be zeroes for
Version 0, and the meaning of any nonzero values is
unspecified.
</t>
</list>
</t>
<t>
The Content Data field of the Version 0 Extended Information
extension field is comprised of two octets, with the
contents allocated as follows:
<list style="hanging">
<t hangText="0xXXNN:">
The low-order 8 bits (NNNN) are the TAI Offset. Any
data in the high-order 8 bits (XXXX) are not part of the
TAI Offset.
</t>
<t hangText="0xX0XX:">
A value of 0 in the low-order bit of the first octet
indicates that the timestamps in the base packet are not
interleave-mode timestamps.
</t>
<t hangText="0xX1XX:">
A value of 1 in the low-order bit of the first octet
indicates that the timestamps in the base packet are
interleave-mode timestamps.
</t>
<t hangText="0xN2XX:">thru</t>
<t hangText="0xNDXX:">
Any of the seven high-order bits in the first octet are
reserved for future versions and SHOULD be zero for
Version 0. The meaning of any nonzero values is
unspecified.
</t>
</list>
</t>
<t><figure title="NTP Extension Field: Extended Information, Version 0
Content Fields">
<artwork name="NTP Extension Field: Extended Information, Version 0
Content Fields"><![CDATA[
Content Descriptor 1 Content Data 1
0x0001 TAI offset in the low-order 8 bits, 24-31
0x0002 Interleave Mode indicator in Bit 23
0xFFFD Reserved (Zeroes)
Interleave Mode: 1 if the sender is in interleave mode, 0 otherwise]]></artwork>
</figure></t>
<t>Example: A system that wants to convey an offset to TAI of 36
seconds, and show it is in interleave mode.</t>
<t><figure title="NTP Extension Field: Extended Information V0, Example">
<artwork name="NTP Extension Field: Extended Information V0, Example"><![CDATA[
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
+---------------+---------------+-------------------------------+
| Field Type (0x0009) | Field Length (0x0008) |
+-------------------------------+-------------------------------+
| 0x0003 | 0x0124 |
+-------------------------------+-------------------------------+]]></artwork>
</figure></t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author wishes to acknowledge the contributions of Martin
Burnicki and Sam Weiler.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo requests IANA to allocate NTP Extension Field Type
<list>
<t>0x0009 (Extended-Information, Version 0)</t>
</list>
for this proposal.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
No unusual or special security considerations are known to be
associated with this proposal.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.958.xml"?-->
&RFC0958;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml"?-->
&RFC5905;
</references>
<!-- Here we use entities that we defined at the beginning. -->
<!-- SW: Except that we're not really using these...
<references title="Informative References">
&RFC3552;
&I-D.narten-iana-considerations-rfc2434bis;
</references>
-->
<!--
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
-->
<!-- Change Log
v00 2016-03-NN HMS Initial Submission
-->
</back>
</rfc>