-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathrfc1028.txt
1963 lines (1313 loc) · 78.6 KB
/
rfc1028.txt
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
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group J. Davin
Request for Comments: 1028 Proteon, Inc.
J. Case
University of Tennessee at Knoxville
M. Fedor
Cornell University
M. Schoffstall
Rensselaer Polytechnic Institute
November 1987
A Simple Gateway Monitoring Protocol
1. Status of this Memo
This document is being distributed to members of the Internet
community in order to solicit their reactions to the proposals
contained in it. While the issues discussed may not be directly
relevant to the research problems of the Internet, they may be
interesting to a number of researchers and implementors.
This memo defines a simple application-layer protocol by which
management information for a gateway may be inspected or altered by
logically remote users.
This proposal is intended only as an interim response to immediate
gateway monitoring needs while work on more elaborate and robust
designs proceeds with the care and deliberation appropriate to that
task. Accordingly, long term use of the mechanisms described here
should be seriously questioned as more comprehensive proposals emerge
in the future. Distribution of this memo is unlimited.
2. Protocol Design Strategy
The proposed protocol is shaped in large part by the desire to
minimize the number and complexity of management functions realized
by the gateway itself. This goal is attractive in at least four
respects:
(1) The development cost for gateway software necessary to
support the protocol is accordingly reduced.
(2) The degree of management function that is remotely
supported is accordingly increased, thereby admitting
fullest use of internet resources in the management task.
Davin, Case, Fedor and Schoffstall [Page 1]
RFC 1028 Simple Gateway Monitoring November 1987
(3) The degree of management function that is remotely
supported is accordingly increased, thereby imposing the
fewest possible restrictions on the form and sophistication
of management tools.
(4) A simplified set of management functions is easily
understood and used by developers of gateway management
tools.
A second design goal is that the functional paradigm for monitoring
and control be sufficiently extensible to accommodate additional,
possibly unanticipated aspects of gateway operation.
A third goal is that the design be, as much as possible, independent
of the architecture and mechanisms of particular hosts or particular
gateways.
Consistent with the foregoing design goals are a number of decisions
regarding the overall form of the protocol design.
One such decision is to model all gateway management functions as
alterations or inspections of various parameter values. By this
model, a protocol entity on a logically remote host (possibly the
gateway itself) interacts with a protocol entity resident on the
gateway in order to alter or retrieve named portions (variables) of
the gateway state. This design decision has at least two positive
consequences:
(1) It has the effect of limiting the number of essential
management functions realized by the gateway to two: one
operation to assign a value to a specified configuration
parameter and another to retrieve such a value.
(2) A second effect of this decision is to avoid introducing
into the protocol definition support for imperative
management commands: the number of such commands is in
practice ever-increasing, and the semantics of such
commands are in general arbitrarily complex.
The exclusion of imperative commands from the set of explicitly
supported management functions is unlikely to preclude any desirable
gateway management operation. Currently, most gateway commands are
requests either to set the value of some gateway parameter or to
retrieve such a value, and the function of the few imperative
commands currently supported is easily accommodated in an
asynchronous mode by this management model. In this scheme, an
imperative command might be realized as the setting of a parameter
value that subsequently triggers the desired action.
Davin, Case, Fedor and Schoffstall [Page 2]
RFC 1028 Simple Gateway Monitoring November 1987
A second design decision is to realize any needed authentication
functionality in a distinct protocol layer that provides services to
the monitoring protocol itself. The most important benefit of this
decision is a reduction in the complexity of the individual protocol
layers - thereby easing the task of implementation.
Consistent with this layered design strategy is a third design
decision that the identity of an application protocol entity is known
to its peers only by the services of the underlying authentication
protocol. Implicit in this decision is a model of access control by
which access to variables of a gateway configuration is managed in
terms of the association between application entities and sessions of
the authentication protocol. Thus, multi-level access to gateway
variables is supported by multiple instances of the application
protocol entity, each of which is characterized by:
(1) the set of gateway variables known to said entity,
(2) the mode of access (READ-ONLY or READ-WRITE) afforded to
said set of variables, and
(3) the authentication protocol session to which belong the
messages sent and received by said entity.
A fourth design decision is to adopt the conventions of the CCITT
X.409 recommendation [1] for representing the information exchanged
between protocol entities. One cost of this decision is a modest
increase in the complexity of the protocol implementation. One
benefit of this decision is that protocol data are represented on the
network in a machine-independent, widely understood, and widely
accepted form. A second benefit of this decision is that the form of
the protocol messages may be concisely and understandably described
in the X.409 language defined for such purposes.
A fifth design decision, consistent with the goal of minimizing
gateway complexity, is that the variables manipulated by the protocol
assume only integer or octet string type values.
A sixth design decision, also consistent with the goal of minimizing
gateway complexity, is that the exchange of protocol messages
requires only an unreliable datagram transport, and, furthermore,
that every protocol message is entirely and independently
representable by a single transport datagram. While this document
specifies the exchange of protocol messages via the UDP protocol [2],
the design proposed here is in general suitable for use with a wide
variety of transport mechanisms.
Davin, Case, Fedor and Schoffstall [Page 3]
RFC 1028 Simple Gateway Monitoring November 1987
A seventh design decision, consistent with the goals of simplicity
and extensibility, is that the variables manipulated by the protocol
are named by octet string values. While this decision departs from
the architectural traditions of the Internet whereby objects are
identified by assigned integer values, the naming of variables by
octet strings affords at least two valuable benefits. Because the
set of octet string values constitutes a variable name space that, as
convenient, manifests either flat or hierarchical structure,
(1) a single, simple mechanism can provide both random access
to individual variables and sequential access to
semantically related groups of variables, and
(2) the variable name space may be extended to accommodate
unforeseen needs without compromising either the
relationships among existing variables or the potential
for further extensions to the space.
An eighth design decision is to minimize the number of unsolicited
messages required by the protocol definition. This decision is
consistent with the goal of simplicity and motivated by the desire to
retain maximal control over the amount of traffic generated by the
network management function - even at the expense of additional
protocol overhead. The strategy implicit in this decision is that
the monitoring of network state at any significant level of detail is
accomplished primarily by polling for appropriate information on the
part of the monitoring center. In this context, the definition of
unsolicited messages in the protocol is confined to those strictly
necessary to properly guide a monitoring center regarding the timing
and focus of its polling.
3. The Gateway Monitoring Protocol
The gateway monitoring protocol is an application protocol by which
the variables of a gateway's configuration may be inspected or
altered.
Communication among application protocol entities is by the exchange
of protocol messages using the services of the authentication
protocol described elsewhere in this document. Each such message is
entirely and independently represented by a single message of the
underlying authentication protocol. An implementation of this
protocol need not accept protocol messages whose length exceeds 484
octets.
The form and function of the four message types recognized by a
protocol entity is described below. The type of a given protocol
message is indicated by the value of the implicit type tag for the
Davin, Case, Fedor and Schoffstall [Page 4]
RFC 1028 Simple Gateway Monitoring November 1987
data structure that is represented by said message according to the
conventions of the CCITT X.409 recommendation.
3.1. The Get Request Message Type
The form of a message of Get Request type is described below in the
language defined in the CCITT X.409 recommendation:
var_value_type ::= CHOICE {
INTEGER,
OCTET STRING
}
var_name_type := OCTET STRING
var_op_type ::= SEQUENCE {
var_name var_name_type,
var_value var_value_type
}
var_op_list_type ::= SEQUENCE OF var_op_type
error_status_type ::= INTEGER {
gmp_err_noerror (0),
gmp_err_too_big (1),
gmp_err_nix_name (2),
gmp_err_bad_value (3)
}
error_index_type ::= INTEGER
request_id_type ::= INTEGER
get_req_message_type ::= [ APPLICATION 1 ] IMPLICIT
SEQUENCE {
request_id request_id_type,
error_status error_status_type,
error_index error_index_type,
var_op_list var_op_list_type
Davin, Case, Fedor and Schoffstall [Page 5]
RFC 1028 Simple Gateway Monitoring November 1987
}
Upon receipt of a message of this type, the receiving entity responds
according to any applicable rule in the list below:
(1) If, for some var_op_type component of the received message, the
value of the var_name field does not lexicographically precede
the name of some variable known to the receiving entity, then
the receiving entity sends to the originator of the received
message a message of identical form except that the indicated
message type is Get Response, the value of the error_status
field is gmp_err_nix_name, and the value of the error_index
field is the unit-based index of said var_op_type component in
the received message.
(2) If the size of the Get Response type message generated as
described below would exceed the size of the largest message
for which the protocol definition requires acceptance, then the
receiving entity sends to the originator of the received message
a message of identical form except that the indicated message
type is Get Response, the value of the error_status field is
gmp_err_too_big, and the value of the error_index field is zero.
If none of the foregoing rules apply, then the receiving entity sends
to the originator of the received message a Get Response type message
such that, for each var_op_type component of the received message, a
corresponding component of the generated message represents the name
and value of that variable whose name is, in the lexicographical
ordering of the names of all variables known to the receiving entity
together with the value of the var_name field of the given component,
the immediate successor to that value. The value of the error_status
field of the generated message is gmp_err_noerror and the value of
the error_index field is zero. The value of the request_id field of
the generated message is that for the received message.
Messages of the Get Request type are generated by a protocol entity
only at the request of the application user.
3.2. The Get Response Message Type
The form of messages of this type is identical to that of Get Request
type messages except for the indication of message type. In the CCITT
X.409 language,
get_rsp_message_type ::= [ APPLICATION 2 ] IMPLICIT
SEQUENCE {
Davin, Case, Fedor and Schoffstall [Page 6]
RFC 1028 Simple Gateway Monitoring November 1987
request_id request_id_type,
error_status error_status_type,
error_index error_index_type,
var_op_list var_op_list_type
}
The response of a protocol entity to a message of this type is to
present its contents to the application user.
Messages of the Get Response type are generated by a protocol entity
only upon receipt of Set Request or Get Request type messages as
described elsewhere in this document.
3.3. The Trap Request Message Type
The form of a message of this type is described below in the language
defined in the CCITT X.409 recommendation:
val_list_type ::= SEQUENCE OF var_value_type
trap_type_type ::= INTEGER
trap_req_message_type ::= [ APPLICATION 3 ] IMPLICIT
SEQUENCE {
trap_type trap_type_type,
val_list val_list_type
}
The response of a protocol entity to a message of this type is to
present its contents to the application user.
Messages of the Trap Request type are generated by a protocol entity
only at the request of the application user.
The significance of the val_list component of a Trap Request type
message is implementation-specific.
Interpretations for negative values of the trap_type field are
implementation-specific. Interpretations for non-negative values of
the trap_type field are defined below.
3.3.1. The Cold Start Trap Type
A Trap Request type message for which the value of the trap_type
Davin, Case, Fedor and Schoffstall [Page 7]
RFC 1028 Simple Gateway Monitoring November 1987
field is 0, signifies that the sending protocol entity is
reinitializing itself such that the gateway configuration or the
protocol entity implementation may be altered.
3.3.2. The Warm Start Trap Type
A Trap Request type message for which the value of the trap_type
field is 1, signifies that the sending protocol entity is
reinitializing itself such that neither the gateway configuration nor
the protocol entity implementation is altered.
3.3.3. The Link Failure Trap Type
A Trap Request type message for which the value of the trap_type
field is 2, signifies that the sending protocol entity recognizes a
failure in one of the communication links represented in the gateway
configuration.
3.3.4. The Authentication Failure Trap Type
A Trap Request type message for which the value of the trap_type
field is 3, signifies that the sending protocol entity is the
addressee of a protocol message that is not properly authenticated.
3.3.5. The EGP Neighbor Loss Trap Type
A Trap Request type message for which the value of the trap_type
field is 4, signifies that an EGP neighbor for whom the sending
protocol entity was an EGP peer has been marked down and the peer
relationship no longer obtains.
3.4. The Set Request Message Type
The form of messages of this type is identical to that of Get Request
type messages except for the indication of message type. In the
CCITT X.409 language:
set_req_message_type ::= [ APPLICATION 4 ] IMPLICIT
SEQUENCE {
request_id request_id_type,
error_status error_status_type,
error_index error_index_type,
var_op_list var_op_list_type
}
Davin, Case, Fedor and Schoffstall [Page 8]
RFC 1028 Simple Gateway Monitoring November 1987
Upon receipt of a message of this type, the receiving entity responds
according to any applicable rule in the list below:
(1) If, for some var_op_type component of the received message, the
value of the var_name field names no variable known to the
receiving entity, then the receiving entity sends to the
originator of the received message a message of identical form
except that the indicated message type is Get Response, the
value of the error_status field is gmp_err_nix_name, and the
value of the error_index field is the unit-based index of said
var_op_type component in the received message.
(2) If, for some var_op_type component of the received message, the
contents of the var_value field does not, according to the CCITT
X.409 recommendation, manifest a type, length, and value that is
consistent with that required for the variable named by the
value of the var_name field, then the receiving entity sends to
the originator of the received message a message of identical
form except that the indicated message type is Get Response, the
value of the error_status field is gmp_err_bad_value, and the
value of the error_index field is the unit-based index of said
var_op_type component in the received message.
(3) If the size of the Get Response type message generated as
described below would exceed the size of the largest message for
which the protocol definition requires acceptance, then the
receiving entity sends to the originator of the received
message a message of identical form except that the indicated
message type is Get Response, the value of the error_status
field is gmp_err_too_big, and the value of the error_index field
is zero.
If none of the foregoing rules apply, then for each var_op_type
component of the received message, according to the sequence of such
components represented by said message, the value represented by the
var_value field of the given component is assigned to the variable
named by the value of the var_name field of that component. The
receiving entity sends to the originator of the received message a
message of identical form except that the indicated message type is
Get Response, the value of the error_status field is gmp_err_noerror,
and the value of the error_index field is zero.
Messages of the Set Request type are generated by a protocol entity
only at the request of the application user.
Recognition and processing of Set Request type frames is not required
by the protocol definition.
Davin, Case, Fedor and Schoffstall [Page 9]
RFC 1028 Simple Gateway Monitoring November 1987
4. The Authentication Protocol
The authentication protocol is a session-layer protocol by which
messages specified by a protocol user are selectively delivered to
other protocol users. The protocol definition precludes delivery to
a protocol user of any user message for which the protocol
representation lacks a specified "authentic" form.
Communication among authentication protocol entities is accomplished
by the exchange of protocol messages, each of which is entirely and
independently represented by a single UDP datagram. An
authentication protocol entity responds to protocol messages received
at UDP port 153 on the host with which it is associated.
A half-session of the authentication protocol is, for any ordered
pair of protocol users, the set of messages sent from the first user
of the pair to the second user of said pair. A session of the
authentication protocol is defined to be union of two complementary
half-sessions of the protocol - that is, the set of messages
exchanged between a given pair of protocol users. Associated with
each protocol half-session is a triplet of functions:
(1) The authentication function for a given half-session is a
boolean-valued function that characterizes the set of
authentication protocol messages that are of acceptable,
authentic form with respect to the set of all possible
authentication protocol messages.
(2) The message interpretation function for a given half-
session is a mapping from the set of authentication
protocol messages accepted by the authentication function
for said half-session to the set of all possible user
messages.
(3) The message representation function for a given half-
session is a mapping that is the inverse of the message
interpretation function for said half-session.
The association between half-sessions of the authentication protocol
and triplets of functions is not defined in this document.
The form and function of the single message type recognized by a
protocol entity is described below. The type of a given protocol
message is indicated by the value of the implicit type tag for the
data structure that is represented by said message according to the
conventions of the CCITT X.409 recommendation.
Davin, Case, Fedor and Schoffstall [Page 10]
RFC 1028 Simple Gateway Monitoring November 1987
4.1. The Data Request Message Type
Messages of this type are represented by a sequence of fields whose
form and interpretation are described below.
4.1.1. The Message Length Field
The Message Length field of a given Data Request message represents
the length of said message as an unsigned, 16-bit, binary integer.
This value is encoded such that more significant bits precede less
significant bits in the order of transmission and includes the length
of the Message Length field itself.
4.1.2. The Session ID Length Field
The Session ID Length field of a given Data Request message
represents the length, in octets, of the Session ID field of said
message. This value is encoded as an unsigned, 8-bit, binary
integer.
4.1.3. The Session ID Field
The Session ID field of a given Data Request message represents the
name of the protocol session to which said message belongs. The
value of this field is encoded as asequence of octets whose length is
the value of the Session ID Length field for said message.
4.1.4. The User Data Field
The User Data field of a given Data Request message represents a
message being passed from one protocol user to another. The value of
this field is encoded according to conventions implicit in the
message representation function for the appropriate half of the
protocol session named by the value of the Session ID field for said
message.
Upon receipt of a Data Request type message, the receiving
authentication protocol entity verifies the form of said message by
application of the authentication function associated with its half
of the session named by the value of the Session ID field in the
received message. If the form of the received message is accepted as
"authentic" by said function, then the user message computed by the
application of the message interpretation function for said half-
session to the value of the User Data field of the received message
is presented to the protocol user together with an indication of the
protocol session to which the received message belongs.
Davin, Case, Fedor and Schoffstall [Page 11]
RFC 1028 Simple Gateway Monitoring November 1987
Otherwise, the message is discarded and an indication of the receipt
of an unauthenticated message is presented to the protocol user.
A message of this type is generated only at the request of the
protocol user to communicate a message to another user of the
protocol. Such a request specifies the user message to be sent as
well as the session of the authentication protocol to which said user
message belongs. The value of the Session ID field of the generated
message is the name of the session specified in the user request.
The value of the User Data field of the generated message is computed
by applying the message representation function for the appropriate
half of the specified session to the specified user message.
5. Variable Names
The variables retrieved or manipulated by the application protocol
are named by octet string values. Such values are represented in
this document in two ways:
(1) A variable name octet string may be represented
numerically by a sequence of hexadecimal numbers, each of
which denotes the value of the corresponding octet in
said string.
(2) A variable name octet string may be represented
symbolically by a character string whose form reflects
the sequence of octets in said name while at the same
time suggesting to a human reader the semantics of the
named variable.
Variable name octet strings are represented symbolically according to
the following two rules:
(1) The symbolic character string representation of the
variable name of zero length is the character string of
zero length.
(2) The symbolic character string representation of a
variable name of non-zero length n is the concatenation
of the symbolic character string representation of the
variable name formed by the first (n - 1) octets of the
given name together with the underscore character ("_")
and a character string that does not include the
underscore character, such that the resulting character
string is unique among the symbolic character string
representations for all variable names of length n.
Davin, Case, Fedor and Schoffstall [Page 12]
RFC 1028 Simple Gateway Monitoring November 1987
Thus, for example, the variable names represented numerically as:
01 01 01,
01 01 02,
01 02 01,
01 03 01 03 01,
01 03 01 03 02,
01 03 01 04 01, and
01 03 01 04 02
might be represented symbolically by the character strings:
_GW_version_id,
_GW_version_rev,
_GW_cfg_nnets,
_GW_net_if_type_net1,
_GW_net_if_type_net2,
_GW_net_if_speed_net1, and
_GW_net_if_speed_net2.
All variable names are terminated by an implementation specific octet
string of non-zero length. Thus, a complete variable name is not
specified for any of the variables defined in this document. Rather,
for each defined variable, some prefix portion of its name is
specified, with the understanding that the rightmost portion of its
name is specific to the protocol implementation.
Fullest exploitation of the semantics of the Get Request type message
requires that names for related variables be chosen so as to be
contiguous in the lexicographic ordering of all variable names
recognized by an application protocol entity. This principle is
observed in the naming of variables currently defined by this
document, and it should be observed as well for variables defined by
subsequent revisions of this document and for variables introduced by
particular implementations of the protocol.
A particular implementation of a protocol entity may present
variables in addition to those defined by this document, provided
that in no case will an implementation-specific variable be presented
as having a name identical to that for one of the variables defined
here. By convention, the names of variables specific to a particular
implementation share a common prefix that distinguishes said
variables from those defined in this document and from those that may
be presented by other implementations of an application protocol
entity. For example, variables specific to an implementation of this
protocol in version 1.3 of the Squeaky gateway product of the
Swinging Gateway company might have the names represented by:
Davin, Case, Fedor and Schoffstall [Page 13]
RFC 1028 Simple Gateway Monitoring November 1987
01 FF 01 01 13 01,
01 FF 01 01 13 02, and
01 FF 01 01 13 03,
for which the corresponding symbolic representations might be:
_GW_impl_Swinging_Squeaky_v1.3_variableA,
_GW_impl_Swinging_Squeaky_v1.3_variableB, and
_GW_impl_Swinging_Squeaky_v1.3_variableC.
The names and semantics of implementation-specific variables are not
otherwise defined by this document, although implementors are
encouraged to publish such definitions either as appendices to this
document or by other appropriate means.
Variable names of which the initial portion is represented
numerically as 02 and symbolically as "_HOST" are reserved for future
use. Variable names of which the initial portion is represented
numerically as 03 and symbolically as "_TS" are similarly reserved.
6. Required Variables
To the extent that the information represented by a variable defined
in this section is also represented internally by a gateway for which
this protocol is realized, access to that variable must be afforded
by at least one application protocol entity associated with said
gateway.
6.1. The _GW_version_id Variable
The variable such that the initial portion of its name is represented
symbolically as "_GW_version_id" and numerically as:
01 01 01
has an octet string value that identifies the protocol entity
implementation (e.g., "ACME Packet-Whiz Model II").
6.2. The _GW_version_rev Variable
The variable such that the initial portion of its name is represented
symbolically as "_GW_version_rev" and numerically as:
01 01 02
has an integer value that identifies the revision level of the entity
implementation. The encoding of the revision level as an integer
Davin, Case, Fedor and Schoffstall [Page 14]
RFC 1028 Simple Gateway Monitoring November 1987
value is implementation-specific.
6.3. The _GW_cfg_nnets Variable
The variable such that the initial portion of its name is represented
symbolically as "_GW_cfg_nnets" and numerically as:
01 02 01
has an integer value that represents the number of logical network
interfaces afforded by the configuration of the gateway.
6.4. Network Interface Variables
This section describes a related set of variables that represent
attributes of the logical network interfaces afforded by the gateway
configuration. Each such network interface is uniquely identified by
an octet string. The convention by which names are assigned to the
network interfaces of a gateway is implementation-specific.
6.4.1. The _GW_net_if_type Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_type" and numerically as:
01 03 01 03
has an integer value that represents the type of the network
interface identified by the remainder of the name for said variable.
The value of a variable of this class represents network type
according to the conventions described in Appendix 1.
6.4.2. The _GW_net_if_speed Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_speed" and numerically as:
01 03 01 04
has an integer value that represents the estimated nominal bandwidth
in bits per second of the network interface identified by the
remainder of the name for said variable.
6.4.3. The _GW_net_if_in_pkts Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_in_pkts" and numerically as:
Davin, Case, Fedor and Schoffstall [Page 15]
RFC 1028 Simple Gateway Monitoring November 1987
01 03 01 01 01
has an integer value that represents the number of packets received
by the gateway over the network interface identified by the remainder
of the name for said variable.
6.4.4. The _GW_net_if_out_pkts Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_out_pkts" and numerically as:
01 03 01 02 01
has an integer value that represents the number of packets
transmitted by the gateway over the network interface identified by
the remainder of the name for said variable.
6.4.5. The _GW_net_if_in_bytes Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_in_bytes" and numerically as:
01 03 01 01 02
has an integer value that represents the number of octets received by
the gateway over the network interface identified by the remainder of
the name for said variable.
6.4.6. The _GW_net_if_out_bytes Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_out_bytes" and numerically as:
01 03 01 02 02
has an integer value that represents the number of octets transmitted
by the gateway over the network interface identified by the remainder
of the name for said variable.
6.4.7. The _GW_net_if_in_errors Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_in_errors" and numerically as:
01 03 01 01 03
has an integer value that represents the number of reception errors
encountered by the gateway on the network interface identified by the
Davin, Case, Fedor and Schoffstall [Page 16]
RFC 1028 Simple Gateway Monitoring November 1987
remainder of the name for said variable. The definition of a
reception error is implementation-specific and may vary according to
network type.
6.4.8. The _GW_net_if_out_errors Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_out_errors" and numerically as:
01 03 01 02 03
has an integer value that represents the number of transmission
errors encountered by the gateway on the network interface identified
by the remainder of the name for said variable. The definition of a
transmission error is implementation-specific and may vary according
to network type.
6.4.9. The _GW_net_if_status Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_net_if_status" and numerically as:
01 03 01 05
has an integer value that represents the current status of the
network interface identified by the remainder of the name for said
variable. Network status is represented according to the conventions
described in Appendix 2.
6.5. Internet Protocol Variables
This section describes variables that represent information related
to protocols and mechanisms of the Internet Protocol (IP) family [3].
6.5.1. Protocol Address Variable Classes
This section describes a related set of variables that represent
attributes of the the IP interfaces presented by a gateway on the
various networks to which it is attached. Each such protocol
interface is uniquely identified by an octet string. The convention
by which names are assigned to the protocol interfaces for a gateway
is implementation-specific.
6.5.1.1. The _GW_pr_in_addr_value Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_addr_value" and numerically as:
Davin, Case, Fedor and Schoffstall [Page 17]
RFC 1028 Simple Gateway Monitoring November 1987
01 04 01 01 01
has an octet string value that literally represents the 32-bit
Internet address for the IP interface identified by the remainder of
the name for said variable.
6.5.1.2. The _GW_pr_in_addr_scope Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_addr_scope" and numerically as:
01 04 01 01 02
has an octet string value that names the network interface with which
the IP interface identified by the remainder of the name for said
variable is associated.
6.5.2. Exterior Gateway Protocol (EGP) Variables
This section describes variables that represent information related
to protocols and mechanisms of the EGP protocol [4].
6.5.2.1. The _GW_pr_in_egp_core Variable
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_egp_core" and numerically as:
01 04 01 03 01
has an integer value that characterizes the associated gateway with
respect to the set of INTERNET core gateways. A nonzero value
indicates that the associated gateway is part of the INTERNET core.
6.5.2.2. The _GW_pr_in_egp_as Variable Class
A variable such that the initial portion of its name is represented
symbolically as "_GW_pr_in_egp_as" and numerically as:
01 04 01 03 02
has an integer value that literally identifies an Autonomous System
to which this gateway belongs.