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
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
|
<pre>Network Working Group S. Senum
Request for Comments: 1762 DigiBoard
Obsoletes: <a href="./rfc1376">1376</a> March 1995
Category: Standards Track
<span class="h1">The PPP DECnet Phase IV Control Protocol (DNCP)</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Point-to-Point Protocol (PPP) [<a href="#ref-1" title=""The Point-to-Point Protocol (PPP)"">1</a>] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol, and
proposes a family of Network Control Protocols (NCPs) for
establishing and configuring different network-layer protocols.
This document defines the NCP for establishing and configuring
Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
This document applies only to DNA Phase IV Routing messages (both
data and control), and not to other DNA Phase IV protocols (MOP, LAT,
etc).
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
There are two basic approaches to running the DNA Phase IV Routing
protocol over a serial line:
1. The approach that several router vendors have taken which is to
treat the serial link as an Ethernet, using the same data and
control messages an Ethernet would use.
2. The approach defined by Digital, which uses DDCMP and slightly
different control messages.
This document will define a method that uses the first approach.
<span class="grey">Senum [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1762">RFC 1762</a> PPP DNCP March 1995</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview Of Phase IV DNA Protocols</span>
The Phase IV DNA protocols which act as data link clients are:
o DNA Phase IV Routing
The Phase IV Digital Network Architecture (DNA) Routing
protocol is a network layer protocol providing services similar
to that of DoD IP. It routes messages in Phase IV DECnet
networks and manages the packet flow. The complete definition
of the DNA Phase IV Routing protocol can be found in [<a href="#ref-2" title=""DNA Routing Layer Functional Specification"">2</a>].
o DNA System Console
The Digital Network Architecture (DNA) System Console protocol
is a maintenance protocol providing low level access to a
system for the functions of:
. Identify processor
. Read data link counters
. Boot system
. Console carrier (a general purpose i/o channel)
The complete definition of the DNA System Console protocol can
be found in [<a href="#ref-3" title=""DNA Maintenance Operations Functional Specification"">3</a>].
o Digital Customer Use
The Digital Customer Use protocol is a value reserved for use
by Digital customers. It allocates a type for private use
which will not conflict with Digital or other vendor protocols.
o DNA Diagnostics
The Digital Network Architecture (DNA) Diagnostics protocol is
reserved to allow diagnostic software communications in
parallel with other data link clients.
o DNA Naming Service (DNS)
The Digital Network Architecture Naming Service (DNS) provides
a distributed naming service. It allows clients to register
named objects and to bind a set of attributes to the objects in
a distributed database.
o DNA Time Service (DTS)
The Digital Network Architecture Time Service (DTS) is a
protocol providing global clock synchronization in a
distributed environment.
<span class="grey">Senum [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1762">RFC 1762</a> PPP DNCP March 1995</span>
o DNA Load/Dump
The Digital Network Architecture (DNA) Load/Dump protocol is a
maintenance protocol for copying the contents of processor
memory to or from a remote system. For example, a system
manager can load an operating system into an unattended, remote
system. The complete definition of the Phase IV DNA Load/Dump
protocol can be found in [<a href="#ref-3" title=""DNA Maintenance Operations Functional Specification"">3</a>].
o DNA Experimental Use
The Digital Network Architecture (DNA) Experimental Use
protocol allows Digital experimental protocols to share a data
link with other data link clients. It is for use by Digital
Equipment Corporation only.
o DNA Communications Test
The Digital Network Architecture (DNA) Communications Test
protocol is a maintenance protocol for testing the data link
communications path. The complete definition of the DNA
Communications Test protocol can be found in [<a href="#ref-3" title=""DNA Maintenance Operations Functional Specification"">3</a>].
o Digital Protocol X1
The Digital X1 protocol is a network layer protocol currently
private to Digital.
This document defines the NCP for establishing and configuring
Digital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.
This document applies only to DNA Phase IV Routing messages (both
data and control), and not to other DNA Phase IV protocols.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. A PPP Network Control Protocol for DNA Phase IV Routing</span>
The DNA Phase IV Routing Control Protocol (DNCP) is responsible for
configuring, enabling, and disabling the DNA Phase IV Routing
protocol modules on both ends of the point-to-point link. DNCP uses
the same packet exchange mechanism as the Link Control Protocol
(LCP). DNCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. DNCP packets received before this
phase is reached should be silently discarded.
The DNA Phase IV Routing Control Protocol is exactly the same as the
Link Control Protocol [<a href="#ref-1" title=""The Point-to-Point Protocol (PPP)"">1</a>] with the following exceptions:
Frame Modifications
The packet may utilize any modifications to the basic frame format
which have been negotiated during the Link Establishment phase.
<span class="grey">Senum [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1762">RFC 1762</a> PPP DNCP March 1995</span>
Data Link Layer Protocol Field
Exactly one DNCP packet is encapsulated in the Information field
of a PPP Data Link Layer frame where the Protocol field indicates
type hex 8027 (DNA Phase IV Control Protocol).
Code field
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
and Code-Reject) are used. Other Codes should be treated as
unrecognized and should result in Code-Rejects.
Timeouts
DNCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation should be
prepared to wait for Authentication and Link Quality Determination
to finish before timing out waiting for a Configure-Ack or other
response. It is suggested that an implementation give up only
after user intervention or a configurable amount of time.
Configuration Option Types
DNCP has no Configuration Options.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Sending DNA Phase IV Routing Packets</span>
Before any DNA Phase IV Routing packets may be communicated, PPP
must reach the Network-Layer Protocol phase, and the DNA Phase IV
Routing Control Protocol must reach the Opened state.
Exactly one length field and one DNA Phase IV Routing packet are
encapsulated in the information field of a PPP Data Link Layer
frame where the Protocol field indicates type hex 0027 (DNA Phase
IV Routing). The length field contains a count of the number of
octets in the DNA Phase IV Routing packet. It is two octets in
length itself, and is stored in VAX byte ordering, to be more
consistent with DNA Phase IV Routing over Ethernet (i.e. least
significant byte first). It is needed to disambiguate optional
padding octets from real information.
The maximum length of a DNA Phase IV Routing packet transmitted
over a PPP link is the same as the maximum length of the
Information field of a PPP data link layer frame minus 2 octets
(for the Length field).
<span class="grey">Senum [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1762">RFC 1762</a> PPP DNCP March 1995</span>
The format of the packets themselves is the same as the format
used over Ethernet, without the Ethernet header, Pad, and FCS
fields.
A summary of the information field is shown below. The fields are
transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length LSB | Length MSB | DATA | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length LSB
Least significant byte of length field
Length MSG
Most significant byte of length field
DATA
DNA Phase IV Routing data, as specified in [<a href="#ref-2" title=""DNA Routing Layer Functional Specification"">2</a>]
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. General Considerations</span>
When a topology change in the network occurs, DNA Phase IV Routing
nodes immediately propagate changes via Level 1 and Level 2 Routing
messages, with a 1 second minimum delay between updates. DNA Phase
IV Routing nodes also periodically retransmit the complete Level 1
and Level 2 distance vectors to guard against data corruption in host
memory, and (in the case of Ethernet) loss of packets due to media
errors. Because Digital's serial links run a protocol that
guarantees delivery of packets (DDCMP), the recommended default
retransmit time is long (600 seconds), whereas for Ethernet, where
packet delivery is not guaranteed, the recommended default is short
(10 seconds), as documented in [<a href="#ref-2" title=""DNA Routing Layer Functional Specification"">2</a>]. To achieve convergence of routes
within a satisfactory time, the interval between updates should be
based upon the error rate of underlying data link. As such, it is
recommended that the time between routing updates be user
configurable per PPP interface.
The Hello timer and Listen timer should be set according to the
recommendations for broadcast links (15 and 45 seconds,
respectively).
<span class="grey">Senum [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1762">RFC 1762</a> PPP DNCP March 1995</span>
Routers MAY not send routing updates if the remote node connected via
the PPP link is an endnode. Endnodes MUST discard all routing
updates received over a PPP link. The type of a node (endnode versus
routing) can be determined from the hello messages received from it.
Security Considerations
Security issues are not discussed in this memo.
References
[<a id="ref-1">1</a>] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, <a href="./rfc1661">RFC</a>
<a href="./rfc1661">1661</a>, Daydreamer, July 1994.
[<a id="ref-2">2</a>] Digital Equipment Corporation, "DNA Routing Layer Functional
Specification", Version 2.0.0, Order No. AA-X435A-TK.
[<a id="ref-3">3</a>] Digital Equipment Corporation, "DNA Maintenance Operations
Functional Specification", Version 3.0.0, Order No. AA-X436A-TK.
Acknowledgments
Some of the text in this document is taken from previous documents
produced by the Point-to-Point Protocol Working Group of the Internet
Engineering Task Force (IETF).
The author wishes to thank Jim Muchow (Network Systems Corporation),
and Arthur Harvey (Digital Equipment Corporation) for their input to
this memo.
Chair's Address
The working group can be contacted via the current chair:
Fred Baker
Senior Software Engineer
Cisco Systems
519 Lado Drive
Santa Barbara, California 93111
Phone: (408) 526-4257
EMail: fred@cisco.com
<span class="grey">Senum [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1762">RFC 1762</a> PPP DNCP March 1995</span>
Author's Address
Questions about this memo can also be directed to the author:
Steven J. Senum
DigiBoard
6400 Flying Cloud Drive
Eden Prairie, Minnesota 55344
Phone: (612) 943-9020
EMail: sjs@digibd.com
Senum [Page 7]
</pre>
|
