File: rfc1264.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (451 lines) | stat: -rw-r--r-- 17,016 bytes parent folder | download | duplicates (5)
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
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451






Network Working Group                                          R. Hinden
Request for Comments: 1264                                           BBN
                                                            October 1991


                    Internet Engineering Task Force
           Internet Routing Protocol Standardization Criteria

Status of this Memo

   This informational RFC presents procedures for creating and
   documenting Internet standards on routing protocols.  These
   procedures have been established by the Internet Activities Board
   (IAB) in consultation with the Internet Engineering Steering Group
   (IESG).  Distribution of this memo is unlimited.

1.0  Introduction

   The IAB and the IESG have evolved a three-stage Internet
   standardization process.  This process is explained in the "IAB
   Official Protocol Standards", published as an RFC several times a
   year (the current version is RFC 1250).

   In brief, the three stages of Internet standardization are Proposed
   (which requires a well written, openly reviewed specification), Draft
   (which requires Proposed status, multiple implementations and some
   operational experience), and full Internet Standard (which requires
   Draft status and more extensive operational experience).  The IAB and
   IESG are currently developing a more detailed explanation of the
   process, which will be available as an RFC.

   The purpose of this document is to provide more specific guidance for
   the advancement of routing protocols.  All levels of the
   standardization process are covered.

   There are currently two types of routing protocol in the Internet.
   These are Interior Gateway Protocols (IGP) sometimes called Intra-
   Domain Routing Protocols and Exterior Gateway Protocols (EGP)
   sometimes called Inter-Domain Routing Protocols.  This document uses
   the terms IGP and EGP.

2.0 Motivation

   The motivation for these requirements two-fold.  The first is to
   reduce the risk that there will be serious technical problems with a
   routing protocol after it reaches Draft Standard.  The second is to
   insure that the new routing protocol will support the continued
   growth of the Internet.



Hinden                                                          [Page 1]

RFC 1264               Routing Protocol Criteria            October 1991


   Routing protocols are complex, widely distributed, real-time
   algorithms.  They are difficult to implement and to test.  Even
   though a protocol may work in one environment with one
   implementation, that does not ensure that it will work in a different
   environment with multiple vendors.  A routing protocol may work well
   within a range of topologies and number of networks and routers, but
   may fail when an unforeseen limit is reached.  The result is that
   even with considerable operational experience, it is hard to
   guarantee that the protocol is mature enough for widespread
   deployment.

   The Internet is currently growing at an exponential rate.  Routing
   protocols and the management of internet addressing are key elements
   in the successful operation the Internet.  It is important that new
   routing protocols be designed to support this rapid growth.

3.0 General Requirements

   1) Documents specifying the Protocol and its Usage.  This may be
      one or more documents.  The specifications for the routing
      protocol must be well written such that independent,
      interoperable implementations can be developed solely based on
      the specification.  For example, it should be possible to
      develop an interoperable implementation without consulting the
      original developers of the routing protocol.

   2) A Management Information Base (MIB) must be written for the
      protocol.  Routing protocols, like all other internet protocols,
      need a MIB defined so they can be remotely managed.

   3) A security architecture of the protocol must be defined.  The
      security architecture must include mechanisms for authenticating
      routing messages and may include other forms of protection.

   4) Generally, a number of interoperable implementations must
      exist.  At least two must be written independently.

   5) There must be evidence that all features of the protocol have
      been tested, running between at least two implementations.  This
      must include that all of the security features have been
      demonstrated to operate, and that the mechanisms defined in the
      protocol actually provide the intended protection.

   6) There must be operational experience with the routing
      protocol.  The level of operational experience required is
      dependent on which level of standardization is requested.  All
      significant features of the protocol must be exercised.  In the
      case of an Interior Gateway Protocol (IGP), both interior and



Hinden                                                          [Page 2]

RFC 1264               Routing Protocol Criteria            October 1991


      exterior routes must be carried (unless another mechanism is
      provided for the exterior routes).  In the case of a Exterior
      Gateway Protocol (EGP), it must carry the full complement of
      exterior routes.

   7) Two reports must be submitted to the IESG via the Routing Area
      Director.  The first report must document how requirements 1)
      through 6) of this document have been satisfied.  It must
      include:

      - Implementation experience.

      - Reference to the MIB for the protocol.

      - Description of the authentication mechanisms in the protocol.

      - List of implementations including origin of code.

      - Test scenarios and test results showing that all features of the
        protocols have been tested.

      - Description of operational experience.  This must include
        topology, environment, time and duration, implementations
        involved, and overall results and conclusions gained from the
        operational experience.

   The second report must summarize the key features of the protocol and
   analyze how the protocol will perform and scale in the Internet.  The
   intent of this requirement is to understand the boundary conditions
   of the routing protocol.  The new routing protocol must be compared
   with the existing routing protocols (e.g., RIP, EGP, etc.) as
   appropriate.  The report should answer several questions:

      - What are the key features and algorithms of the protocol?

      - How much link bandwidth, router memory and router CPU cycles
        does the protocol consume under normal conditions?

      - For these metrics, how does the usage scale as the routing
        environment grows?  This should include topologies at least an
        order of magnitude larger than the current environment.

      - What are the limits of the protocol for these metrics? (I.e.,
        when will the routing protocol break?)

      - For what environments is the protocol well suited, and for what
        is it not suitable?




Hinden                                                          [Page 3]

RFC 1264               Routing Protocol Criteria            October 1991


   The IESG will forward to the IAB its recommendation for advancement
   of the new routing protocol based on its evaluation of protocol
   specifications and these reports.

4.0 Requirements for Proposed Standard

   1) Documents specifying the Protocol and its Usage.  The
      specification for the routing protocol must be well written such
      that independent, interoperable implementations can be developed
      solely based on the specification.  For example, it should be
      possible to develop an interoperable implementation without
      consulting the original developers of the routing protocol.

   2) A Management Information Base (MIB) must be written for the
      protocol.  The MIB does not need to submitted for Proposed
      Standard at the same time as the routing protocol, but must be
      at least an Internet Draft.

   3) The security architecture of the protocol must be set forth
      explicitly.  The security architecture must include mechanisms for
      authenticating routing messages and may include other forms of
      protection.

   4) One or more implementations must exist.

   5) There must be evidence that the major features of the protocol
      have been tested.

   6) No operational experience is required for the routing protocol
      at this stage in the standardization process.

   7) A report must be submitted to the IESG via the Routing Area
      Director.  The report must document the key features of the
      protocol and describe how requirements 1) through 5) have been
      satisfied.  It must include:

      - What are the key features and algorithms of the protocol?

      - For what environments is the protocol well suited, and for what
        is it not suitable?

      - Description of the authentication mechanisms in the protocol.

      - Reference to the MIB for the protocol.

      - Implementation experience.

      - List of implementations including origin of code.



Hinden                                                          [Page 4]

RFC 1264               Routing Protocol Criteria            October 1991


      - Test scenarios and test results showing that the major features
        of the protocols have been tested.

   The IESG will forward to the IAB its recommendation for advancement
   of the new routing protocol to Proposed Standard based on its
   evaluation of protocol specifications and this reports.

5.0 Requirements for Draft Standard

   1) Revisions to the Protocol and Usage documents showing changes and
      clarifications made based on experience gained in the time
      between when the protocol was made a Proposed Standard and it
      being submitted for Draft Standard.  The revised documents should
      include a section summarizing the changes made.

   2) The Management Information Base (MIB) must be at the Proposed
      Standard level of standardization.

   3) Two or more interoperable implementations must exist.  At least
      two must be written independently.

   4) There must be evidence that all features of the protocol have
      been tested, running between at least two implementations.  This
      must include that all of the security features have been
      demonstrated to operate, and that the mechanisms defined in the
      protocol actually provide the intended protection.

   5) There must be significant operational experience.  This must
      include running in a moderate number routers configured in a
      moderately complex topology, and must be part of the operational
      Internet.  All significant features of the protocol must be
      exercised.  In the case of an Interior Gateway Protocol (IGP),
      both interior and exterior routes must be carried (unless another
      mechanism is provided for the exterior routes).  In the case of
      a Exterior Gateway Protocol (EGP), it must carry the full
      complement of exterior routes.

   6) Two reports must be submitted to the IESG via the Routing Area
      Director.  The first report must document how requirements 1)
      through 5) of this document have been satisfied.  It must include:

      - Reference to the MIB for the protocol.

      - Description of the authentication mechanisms in the protocol.

      - List of implementations including origin of code.

      - Implementation experience.



Hinden                                                          [Page 5]

RFC 1264               Routing Protocol Criteria            October 1991


      - Test scenarios and test results showing that all features of the
        protocols have been tested.

      - Description of operational experience.  This must include
        topology, environment, time and duration, implementations
        involved, and overall results and conclusions gained from the
        operational experience.

   The second report must summarize the key features of the protocol and
   analyze how the protocol will perform and scale in the Internet.  The
   intent of this requirement is to understand the boundary conditions
   of the routing protocol.  The new routing protocol must be compared
   with the existing routing protocols (e.g., RIP, EGP, etc.) as
   appropriate.  The report should answer several questions:

      - What are the key features and algorithms of the protocol?

      - How much link bandwidth, router memory and router CPU cycles
        does the protocol consume under normal conditions?

      - For these metrics, how does the usage scale as the routing
        environment grows?  This should include topologies at least an
        order of magnitude larger than the current environment.

      - What are the limits of the protocol for these metrics? (I.e.,
        when will the routing protocol break?)

      - For what environments is the protocol well suited, and for what
        is it not suitable?

   The IESG will forward to the IAB its recommendation for advancement
   of the new routing protocol to Draft Standard based on its evaluation
   of protocol specifications and these reports.

6.0 Requirements for Standard

   1) Revisions to the Protocol and Usage documents showing changes and
      clarifications made based on experience gained in the time between
      when the protocol was made a Draft Standard and it being submitted
      for Standard.  The changes should be to clarify the protocol
      or provide guidance in its implementation.  No significant changes
      can be made to the protocol at this stage.  The revised documents
      should include a section summarizing the changes made.

   2) The Management Information Base (MIB) must be submitted for
      Standard at the same time as the routing protocol.

   3) Three or more interoperable implementations must exist.  At least



Hinden                                                          [Page 6]

RFC 1264               Routing Protocol Criteria            October 1991


      two must be written independently.

   4) There must be evidence that all features of the protocol have been
      tested, running between at least two independently written
      implementations.  This must include that all of the security
      features have been demonstrated to operate, and that the mechanisms
      defined in the protocol actually provide the intended protection.

   5) There must be significant operational experience.  This must
      include running in a large number routers configured in a complex
      topology, and must be part of the operational Internet.  The
      operational experience must include multi-vendor operation.  All
      significant features of the protocol must be exercised.  In the
      case of an Interior Gateway Protocol (IGP), both interior and
      exterior routes must be carried (unless another mechanism is
      provided for the exterior routes).  In the case of a Exterior
      Gateway Protocol (EGP), it must carry the full complement of
      exterior routes.

   6) Two reports must be submitted to the IESG via the Routing Area
      Director.  The first report must document how requirements 1)
      through 5) of this document have been satisfied.  It must include:

      - Reference to the MIB for the protocol.

      - Description of the authentication mechanisms in the protocol.

      - List of implementations including origin of code.

      - Implementation experience.

      - Test scenarios and test results showing that all features of the
        protocols have been tested.

      - Description of operational experience.  This must include
        topology, environment, time and duration, implementations
        involved, and overall results and conclusions gained from the
        operational experience.

   The second report should be a revision to the report prepared when
   the protocol was submitted for Draft Standard.  It must describe the
   additional knowledge and understanding gained in the time between
   when the protocol was made a Draft standard and when it was submitted
   for Standard.

   The IESG will forward to the IAB its recommendation for advancement
   of the new routing protocol to Standard based on its evaluation of
   protocol specifications and these reports.



Hinden                                                          [Page 7]

RFC 1264               Routing Protocol Criteria            October 1991


Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Robert M. Hinden
   Bolt Beranek and Newman, Inc.
   50 Moulton Street
   Cambridge, MA 02138

   Phone: (617) 873-3757

   EMail: hinden@bbn.com





































Hinden                                                          [Page 8]