File: rfc1070.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 (955 lines) | stat: -rw-r--r-- 36,400 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
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






Network Working Group                                          R. Hagens
Request for Comments:  1070                    U of Wiscsonsin - Madison
                                                                 N. Hall
                                               U of Wiscsonsin - Madison
                                                                 M. Rose
                                                    The Wollongong Group
                                                           February 1989


                Use of the Internet as a Subnetwork for
              Experimentation with the OSI Network Layer


Status of this Memo

   This RFC proposes a scenario for experimentation with the
   International Organization for Standardization (ISO) Open Systems
   Interconnection (OSI) network layer protocols over the Internet and
   requests discussion and suggestions for improvements to this
   scenario.  This RFC also proposes the creation of an experimental OSI
   internet.  To participate in the experimental OSI internet, a system
   must abide by the agreements set forth in this RFC.  Distribution of
   this memo is unlimited.

WARNING

   The methods proposed in this RFC are suitable ONLY for experimental
   use on a limited scale.  These methods are not suitable for use in an
   operational environment.

Introduction

   Since the International Organization for Standardization (ISO) Open
   Systems Interconnection (OSI) network layer protocols are in their
   infancy, both interest in their development and concern for their
   potential impact on internetworking are widespread.  This interest
   has grown substantially with the introduction of the US Government
   OSI Profile (GOSIP), which mandates, for the US Government, the use
   of OSI products in the near future.  The OSI network layer protocols
   have not yet received significant experimentation and testing.  The
   status of the protocols in the OSI network layer varies from ISO
   International Standard to "contribution" (not yet a Draft Proposal).
   We believe that thorough testing of the protocols and implementations
   of the protocols should take place concurrently with the progression
   of the protocols to ISO standards.  For this reason, the creation of
   an environment for experimentation with these protocols is timely.

   Thorough testing of network and transport layer protocols for



Hagens, Hall, & Rose                                            [Page 1]

RFC 1070                  Experimental OSI Net             February 1989


   internetworking requires a large, varied, and complex environment.
   While an implementor of the OSI protocols may of course test an
   implementation locally, few implementors have the resources to create
   a sufficiently large dynamic topology in which to test the protocols
   and implementations well.

   One way to create such an environment is to implement the OSI network
   layer protocols in the existing routers in an existing internetwork.
   This solution is likely to be disruptive due to the immature state of
   the OSI network layer protocols and implementations, coupled with the
   fact that a large set of routers would have to implement the OSI
   network layer in order to do realistic testing.

   This memo suggests a scenario that will make it easy for implementors
   to test with other implementors, exploiting the existing connectivity
   of the Internet without disturbing existing gateways.

   The method suggested is to treat the Internet as a subnetwork,
   hereinafter called the "IP subnet."  We do this by encapsulating OSI
   connectionless network layer protocol (ISO 8473) packets in IP
   datagrams, where IP refers to the Internet network layer protocol,
   RFC 791.  This encapsulation occurs only with packets travelling over
   the IP subnet to sites not reachable over a local area network.  The
   intent is for implementations to use OSI network layer protocols
   directly over links locally, and to use the IP subnet as a link only
   when necessary to reach a site that is separated from the source by
   an IP gateway.  While it is true that almost any system at a
   participating site may be reachable with IP, it is expected that
   experimenters will configure their systems so that a subset of their
   systems will consider themselves to be directly connected to the IP
   subnet for the purpose of testing the OSI network layer protocols or
   their implementations.  The proposed scheme permits systems to change
   their topological relationship to the IP subnet at any time, also to
   change their behavior as an end system (ES), intermediate system
   (IS), or both at any time.  This flexibility is necessary to test the
   dynamic adaptive properties of the routing exchange protocols.

   A variant of this scheme is proposed for implementors who do not have
   direct access to the IP layer in their systems.  This variation uses
   the User Datagram Protocol over IP (UDP/IP) as the subnetwork.

   In this memo we will call the experiment based on the IP subnet EON,
   an acronym for "Experimental OSI-based Network".  We will call the
   experiment based on the UDP/IP subnet EON-UDP.

   It is assumed that the reader is familiar with the OSI connectionless
   network layer and, in particular, with the following documents:




Hagens, Hall, & Rose                                            [Page 2]

RFC 1070                  Experimental OSI Net             February 1989


   RFC 768

      User Datagram Protocol.

   RFC 791

      Internet Protocol.

   ISO 8473

      Protocol for Providing the Connectionless mode Network Service.

   ISO DP 9542

      End System to Intermediate System Routing Exchange Protocol for
      Use in Conjunction with the Protocol for the Provision of the
      Connectionless-mode Network Service (ISO 8473).

   ISO TC 97/SC 6/N xxxx

      Intermediate System to Intermediate System Intra-Domain Routing
      Exchange Protocol.

   PD TR 97/SC 6/N 9575

      OSI Routing Framework.


Definitions

   EON

      An acronym for Experimental OSI Network, a name for the proposed
      experimental OSI-based internetwork that uses the IP over the
      Internet as a subnetwork.

   EON-UDP

      A name for the proposed experimental OSI-based internetwork that
      uses the UDP/IP over the Internet as a subnetwork.

   ES

      End system as defined by OSI: an OSI network layer entity that
      provides the OSI network layer service to a transport layer.






Hagens, Hall, & Rose                                            [Page 3]

RFC 1070                  Experimental OSI Net             February 1989


   IANA

      The Internet Assigned Numbers Authority.  Contact Joyce K.
      Reynolds (JKREY@ISI.EDU).

   IS

      An OSI network layer entity that provides the routing and
      forwarding functions of the OSI connectionless network layer.

   OSI CLNL

      OSI connectionless network layer.

   NSDU

      Network Service Data Unit.

   PDU

      Protocol Data Unit, or packet.

   NPDU

      Network Protocol Data Unit.

   ISO-gram

      An NPDU for any protocol in the OSI CLNL, including ISO 8473
      (CLNP), ISO DP 9542 (ES-IS), and ISO TC 97/SC 6/N xxxx (IS-IS).

   Participating system

      An ES or IS that is running a subset of the OSI CLNL protocols and
      is reachable through the application of these protocols and the
      agreements set forth in this memo.

   Core system

      An ES or IS that considers itself directly connected to the IP
      subnet for the purpose of participating in EON.

   NSAP-address

      Network Service Access Point address, or an address at which the
      OSI network services are available to a transport entity.





Hagens, Hall, & Rose                                            [Page 4]

RFC 1070                  Experimental OSI Net             February 1989


   SNPA-address

      SubNetwork Point of Attachment address, or an address at which the
      subnetwork service is available to the network entity.


Issues to be Addressed by this Memo

   In order to make the experimental OSI internet work, participating
   experimenters must agree upon:

   -    how ISO-grams will be encapsulated in IP or UDP packets,

   -    the format of NSAP-addresses to be used,

   -    how NSAP-addresses will be mapped to SNPA-addresses on
        the IP subnet,

   -    how multicasting, which is assumed by some OSI CLNL
        protocols, will be satisfied, and

   -    how topology information and host names will be
        disseminated.

   This memo contains proposals for each of these issues.

Design Considerations

   The goals of this memo are:

   -    to facilitate the testing of the OSI network layer
        protocols among different implementions,

   -    to do this as soon as possible, exploiting existing
        connectivity,

   -    to do this without requiring any changes to existing IP
        gateways,

   -    to create a logical topology that can be changed
        easily, for the purpose of testing the dynamic adaptive
        properties of the protocols, and

   -    to minimize the administrative requirements of this
        experimental internetwork.

   The following are not goals of this memo:




Hagens, Hall, & Rose                                            [Page 5]

RFC 1070                  Experimental OSI Net             February 1989


   -    to permit the use of arbitrary ISO-style
        NSAP-addresses,

   -    to require that participants have working
        implementations of all of the OSI routing protocols
        before they can participate in any capacity,

   -    to permit or encourage the use of existing IP routing
        methods and algorithms for the routing of ISO-grams
        among participating ESs and ISs,

   -    to create a production-like environment accommodating a
        very large number of systems (ESs, ISs or both), and

   -    to provide or to encourage IP-to-CLNP gatewaying.

Encapsulating ISO-grams in IP datagrams

   The entire OSI network layer PDU, whether it be an ISO 8473 PDU, an
   ISO DP 9542 PDU, or an IS-IS PDU, will be placed in the data portion
   of an IP datagrams at the source.  The ISO 8473 entity may fragment
   an NSDU into several NPDUs, in which case each NPDU will be
   encapsulated in an IP datagram.  The intent is for the OSI CLNL to
   fragment rather than to have IP fragment, for the purpose of testing
   the OSI CLNL.  Of course, there is no guarantee that fragmentation
   will not occur within the IP subnet, so reassembly must be supported
   at the IP level in the destination participating system.

   SNPA-addresses (Internet addresses) will be algorithmically derived
   from the NSAP-addresses as described below.  The "protocol" field of
   the IP datagram will take the value 80 (decimal), which has been
   assigned for this purpose.

NSAP-Address Format

   The OSI internetwork described here will form one routing domain,
   with one form of NSAP address recognized by all level 1 routers in
   this domain.  Other address formats may be agreed upon in later
   editions of this memo.

   The address format to be used in this experiment is that specified in
   RFC 1069.  According to RFC 1069, the low-order portion of the Domain
   Specific Part of the NSAP address may vary depending on the
   conventions of the particular routing domain.  For the purposes of
   this experiment, we shall use the following address format:






Hagens, Hall, & Rose                                            [Page 6]

RFC 1070                  Experimental OSI Net             February 1989


                        Address Format for EON
     Octet    Value         Meaning
     -------- ------------- ----------------------------------------
     1        47            Authority and Format Identifier
     2,3      00, 06        International Code Designator
     4        3             Version Number
     5,6      0             Global Area Number, see RFC 1069
     7,8      RDN           Routing Domain Number, assigned by IANA
     9-11     0             Pad
     12,13    0             LOC-AREA, see below
     14,15    0             unused
     16-19    A.B.C.D       Internet address
     20                     NSAP Selector, assigned IANA

      Note: It is our desire that the address format used by EON be
      consistent with RFC 1069.  To that end, the address format
      proposed by this RFC may change as future editions of RFC 1069
      become available.

   The mapping between NSAP-addresses and SNPA-addresses (Internet
   addreses) on the proposed IP subnet is straightforward.  The SNPA-
   address is embeded in the NSAP-address.

   There are several ways in which the LOC-AREA field could be used.

   (1) Assign local areas, administered by the Internet Assigned Numbers
       Authority (IANA).  The advantage of this is that it permits
       experimentation with area routing.  The disadvantage is that it
       will require an additional directory service to map host names to
       NSAP-addresses.  We would like to use the existing domain name
       servers to derive Internet addresses from names, and we would
       like NSAP-addresses to be derivable from the Internet addresses
       alone.

   (2) Have one local area in the EON, with LOC-AREA value 0.  This
       would eliminate the problem of name-toNSAP-address binding, but
       would not permit experimentation with area routing.  It would
       not, however preclude the use of areas later, for example, when
       OSI directory services are widely available.

   (3) Make the local area a simple function of the Internet address.
       The advantage of this is that it would permit experimentation
       with area addressing without requiring additional directory
       services, but the areas derived would not be under the control of
       the experimenters and may not correspond to anything useful or
       meaningful for the purposes of this experiment.

   We believe that initially, the preferred alternative is to use only



Hagens, Hall, & Rose                                            [Page 7]

RFC 1070                  Experimental OSI Net             February 1989


   zero-valued local areas.  Later editions of this memo may contain
   proposals for use of the local area field, when the IS-IS proposal is
   more mature and perhaps when OSI directory services are in use among
   experimenters.

   The value of the high-order portion of the DSP will be set in
   accordance with RFC 1069.

Other NSAP-Address Formats

   PDUs carrying NSAP-addresses of other formats can be routed through
   this domain.  This is the job of the level 2 routers, described in
   the IS-IS document.

Multicast Addresses on the IP Subnet

   The ES-IS and IS-IS routing exchange protocols assume that broadcast
   subnetworks support two multicast addresses: one for all ESs and the
   other for all ISs.  While one could obviate this issue by treating
   the IP subnet as a general topology subnetwork or as a set of point-
   to-point links, it is also desirable to treat the IP subnet as a
   broadcast subnetwork for the purpose of testing those parts of an
   implementation that run over broadcast subnets.  A participating
   implementor not having access to several local machines running the
   OSI CLNL may test the protocols over the IP subnet as if the IP
   subnet were a broadcast subnet.

   The multicasting assumed by the OSI CLNL can be simulated by a small
   sublayer lying between the OSI CLNL and the IP subnet layer.  For the
   purpose of this discussion, call this sublayer an SNAcP, a SubNetwork
   Access Protocol, in OSI argot.  In each system the SNAcP caches a
   table of the Internet addresses of systems that it considers to be
   reachable in one ISO 8473-hop over the IP subnet.  These are called
   "core" systems.  In this sense, the use of the cache simulates a set
   of links over which a system will send ISO configuration messages (ES
   Hello, IS Hello, etc.) when it comes up.  As a local matter, the
   table of core systems may or may not expand during the system's
   lifetime, in response to configuration messages from other core
   systems.

   On the outgoing path, the SNAcP accepts an ISO-gram and a parameter
   indicating the intended use of this ISO-gram: send to a single
   system, to all ESs, to all ISs, or to all systems.  If the indended
   destination is a single system, the ISO-gram is sent only to its
   destination.  Otherwise, the SNAcP makes a copy of the ISO-gram for
   each of the SNPA-addresses in the cache, effecting a broadcast to all
   participating systems.  Before passing an ISO-gram to the IP subnet
   layer, the SNAcP prepends an SNAcP header to each outgoing ISO-gram.



Hagens, Hall, & Rose                                            [Page 8]

RFC 1070                  Experimental OSI Net             February 1989


   This header will take the form:

                          SNAcP Header Format
       Octet   Value                       Meaning
       --------------------------------------------------------
       1       01            Version number
       --------------------------------------------------------
       2                     Semantics of address:
               00            Not a multicast address
               01            All ESs
               02            All ISs
               03            Broadcast
       --------------------------------------------------------
       3,4                   OSI checksum as defined in ISO 8473

   The SNAcP header has three fields, a version number field, a
   semantics field, and a checksum field.  The version number will take
   the value 01.  The checksum field will take the two octet ISO
   (Fletcher) checksum of the SNAcP header.  The checksum algorithm is
   described in ISO 8473.

   The semantics field will take one of 4 values, indicating "all ESs",
   "all ISs", "broadcast", or "not a multicast address".  The value of
   the semantics field is determined by a parameter passed to the SNAcP
   by the calling OSI network entity.  A participant in the experiment
   may test the OSI network layer over a set of point-to-point links by
   choosing not to use the multicast capabilities provided by the SNAcP
   on the outgoing path.

   On the incoming path, the SNAcP inspects the SNAcP header and decides
   whether or not to accept the ISO-gram.  If it accepts the ISO-gram,
   the SNAcP removes the SNAcP header and passes the ISO-gram to the OSI
   CLNL, otherwise, it discards the ISO-gram.  The SNAcP will always
   accept ISO-grams with SNAcP headers indicating "not a multicast
   address" (value zero in the semantics field) and "broadcast" (value
   03).  Whether an SNAcP will accept ISO-grams for either of the two
   multicast groups "all ESs" (value 1) and "all ISs" (value 2) will
   depend on local configuration information.  If the system on which
   the SNAcP resides is configured as an end system, it will accept
   ISO-grams destined for "all ESs" and if it is configured as an
   intermediate system, it will accept ISO-grams destined for "all ISs".

   A participant who is testing the OSI network layer over a set of
   point-to-point links will accept ISO-grams according to these rules
   as well.

   Consideration was given to making the SNAcP extensible by making the
   semantics and checksum fields variable-length parameters, in the



Hagens, Hall, & Rose                                            [Page 9]

RFC 1070                  Experimental OSI Net             February 1989


   manner of ISO 8473.  We feel that the presence of a version number
   provides sufficient extensibility.

Errors on the IP subnet

   The IP subnet layer may receive ICMP messages and may pass error
   indications to the SNAcP layer as a result of having received these
   ICMP messages.  It is assumed that in this context, the IP subnet
   will handle ICMP messages in the same way that it handles them in any
   other context.  For example, upon receipt of an ICMP echo message,
   the IP subnet will respond with an ICMP echo reply, and the SNAcP
   need not be informed of the receipt of the ICMP echo message.
   Certain ICMP messages such as source quench are likely to produce an
   error indication to all layers using the IP subnet.  The actions
   taken by the SNAcP for these indications is purely a local matter,
   however the following actions are suggested.

                Suggested SNAcP Actions in Response to
                    ICMP-related Error Indications
         ICMP message type          Action taken by the SNAcP
      -----------------------------------------------------------
      Destination unreachable,   If the remote address is present
      Parameter problem,         in the cache of core systems'
      Time exceeded              addresses, mark it unusable.
                                 Inform network management.
      -----------------------------------------------------------
      Source quench              If the remote address is present
                                 in the cache of core systems'
                                 addresses, mark the remote
                                 address as unusable and set a
                                 timer for a time after which
                                 the address becomes usable
                                 again.
                                 Inform network management.
      -----------------------------------------------------------
      All others                 Ignored by the SNAcP layer.


   To "inform network management" may mean to print a message on the
   system console, to inform a local process, to increment a counter, to
   write a message in a log file, or it may mean to do nothing.

   The effect of marking a cached address as unusable is as follows.
   When the SNAcP attempts to broadcast or multicast an ISO-gram,
   addresses in the cache that are marked as unusable are ignored.  When
   the SNAcP attempts to send a non-multicast ISO-gram to an unusable
   cached address, the SNAcP returns an error indication to the OSI
   CLNL.  In this way, when the OSI CLNL uses the SNAcP to simulate a



Hagens, Hall, & Rose                                           [Page 10]

RFC 1070                  Experimental OSI Net             February 1989


   set of point-to-point links, it is notified when a link fails, but
   when the OSI CLNL uses the SNAcP to simulate a multicast subnet, it
   is not notified when one system on the subnet goes down.

Use of UDP/IP in Lieu of IP

   In addition to using IP directly, for testing purposes it may be
   useful to support the OSI CLNL over the User Datagram Protocol (UDP).
   This is because some implementors do not have direct access to IP,
   but do have access to the UDP.  For example, an implementor may have
   an a binary license for an operating system that provides TCP/IP and
   UDP/IP, but no direct access to IP.  These implementors may
   participate in a parallel experiment, called EON-UDP, by using UDP/IP
   as a subnetwork instead of using the IP subnet.  In this case, the
   OSI NPDU (after fragmentation, if applicable) will be placed in the
   data portion of a UDP datagram.  UDP port 147 (decimal) has been
   assigned for this purpose.  These participants will place an SNAcP
   between UDP and ISO 8473 rather than between IP and ISO 8473.  In all
   other respects, the EON-UDP experiment is identical to the EON
   experiment.

   Of course, network layers entities using the UDP/IP subnet will not
   interoperate directly with network layers entities using the IP
   subnet.  The procedures proposed in this memo do not prevent an
   implementor from building an EON to EON-UDP gateway, however the
   issues related to building and routing to such a gateway are not
   addressed in this memo.  This memo simply proposes two distinct
   parallel experiments for two groups of experimenters having different
   resources.

   The preferred method of experimentation is to use the IP subnet, in
   other words, EON.  The EON-UDP variant is intended for use only by
   those who cannot participate in EON.

Dissemination of Topological Information and Host Names

   The EON experiment simulates a logical topology that is not as
   connected as the underlying logical topology offered by the Internet.
   The topology of the IP subnet is, in effect, simulated by the SNAcP
   layer in each of the core systems.  Each of the core systems caches a
   list of the other core systems in the EON.  When a system boots, it
   needs some initial list of the participating core systems.  For this
   reason, a list of core systems will be maintained by the IANA.

   In addition, a list of all participating ESs will be maintained by
   the IANA.  This list is not necessary for the functioning of the EON
   network layer.  It is a convenience to the experimenters, and is
   meant for use by application layer software or human users.



Hagens, Hall, & Rose                                           [Page 11]

RFC 1070                  Experimental OSI Net             February 1989


   Two pairs of lists are kept, one for the EON and one for EON-UDP.

   core.EON  This is a list of SNPA-addresses of those systems
             that will be (logically) reachable via the IP subnet
             in one ISO 8473-hop from any other core system.  This
             does not mean that systems in this file are gateways
             or ISs.  They may be ESs, ISs or both.  A site may
             participate as a core system before its address is
             included in this file and distributed to other core
             systems, but under these circumstances other core systems
             will not know to send configuration messages (ESHs and
             ISHs) to the new site when coming up or rebooting.  The
             SNPA-addresses in this file will be ASCII strings of
             the form A.B.C.D, no more than one per line.
             White space (tabs, blanks) will be optional before
             A and after D.  A pound-sign (#) will indicate that
             it and everything following it on that line is a comment.
             For example:

             128.105.2.153 # bounty.cs.wisc.edu

   core.EON-UDP
             This is the equivalent of core.EON for use with
             the UDP/IP subnet.  The format is the same that of
             core.EON.

   hosts.EON This is a list of the ASCII host names of all end
             systems participating in the IP subnet experiment,
             one host name per line.  It is not used by the OSI
             CLNL.

   hosts.EON-UDP
             This is a list of the ASCII host names of all end
             systems participating in the UDP/IP subnet experiment,
             one host name per line.  It is meant for the use of
             applications.  It is not used by the OSI CLNL.

   The files will be available from the IANA via anonymous ftp.  Sites
   wishing to join the experimental OSI internet will have to have their
   host names and core system addresses added to the appropriate files.
   They may do so by sending requests to Joyce K. Reynolds at the
   electronic mail address:

             JKREY@ISI.EDU







Hagens, Hall, & Rose                                           [Page 12]

RFC 1070                  Experimental OSI Net             February 1989


Hypothetical EON Topology

   Figure 1 describes the logical links in a hypothetical topology, in
   which three university computer sciences departments are
   participating in the experiment: the University of Wisconsin (U of
   W), the University of Tudor (U of Tudor), and the University of
   Fordor (U of Fordor).  The U of W has two local area networks(LANs),
   128.105.4 and 128.105.2, and four systems that are acting as ESs in
   the experiment.  Two systems are attached to both LANs.  Only one of
   these two systems is forwarding ISO-grams, in other words, acting as
   an IS.  The U of Tudor has only one participating system, and it is
   acting as an ES.  The U of Fordor has two systems that are
   participating in the experiment, one of which is an IS only, and the
   other of which is acting as an ES only.

   The contents of the core.EON and hosts.EON files for this topology
   are shown below.

   #
   # core.EON for hypothetical EON topology
   #
   128.105.2.153   # IS/ES in cs.wisc.edu
   26.5.0.73       # ES in cs.tudor.edu
   192.5.2.1       # IS in cs.fordor.edu


   #
   # hosts.EON hypothetical EON topology
   #
   128.105.4.150   # ES in cs.wisc.edu
   128.105.2.150   # same as above : multihomed ES
   128.105.4.154   # ES in cs.wisc.edu
   128.105.4.151   # ES in cs.wisc.edu
   128.105.2.153   # IS/ES in cs.wisc.edu
   26.5.0.73       # ES in cs.tudor.edu
   192.5.2.2       # ES in cs.fordor.edu















Hagens, Hall, & Rose                                           [Page 13]

RFC 1070                  Experimental OSI Net             February 1989


    ______U of WI (128.105)______
   (                             )
   ( 128.105.4                   )
   (   |                         )                   _U of Tudor__
   (   |   128.105.2.150         )                  (             )
   (   |   128.105.4.150         )                  (             )
   (   |------ES-----------|     )                  (   ES        )
   (   |                   |     )                  (  26.5.0.73  )
   (   |                   |     )                  (   |         )
   (   |                   |     )                  (___|_________)
   (   |                   |     )                      |
   (   |                   |     )         -------------
   (   |---ES              |     )        _|_
   (   |  128.105.4.154    |     )       (   )
   (   |                   |     )      (     )
   (   |                   |     )     (  IP   )
   (   |                   |----------(  subnet )
   (   |                   |     )     (       )
   (   |                   |     )      (     )
   (   |                   |     )       (___)
   (   |---ES              |     )         |
   (   |  128.105.4.151    |     )         -------------
   (   |                   |     )                      |
   (   |                   |     )                 _U of Fordor_
   (   |                   |     )                (     |       )
   (   |---IS/ES-----------|     )                (     |       )
   (      128.105.2.153    |     )                (    IS       )
   (      128.105.4.153    |     )                (   192.5.2.1 )
   (                       |     )                (     |       )
   (                       |     )                (     |       )
   (                  128.105.2  )                (    ES       )
   (                             )                (   192.5.2.2 )
   (_____________________________)                (_____________)

                    Figure 1: Hypothetical EON Topology


   The U of Fordor system 192.5.2.1 may, in addition to acting as an IS,
   begin acting as an ES at any time, by participating in the ES-IS
   protocol as an ES and by beginning to serve a set of NSAPs.  It may
   act as an ES or as an IS or as both.  In fact, the U of Fordor
   systems 192.5.2.1 and 192.5.2.2 could reverse roles at any time,
   regardless of their physical connectivity to the Internet, merely by
   modifying their use of the ES-IS protocol and by their serving or not
   serving NSAPs.  Suppose that these two systems reverse roles:
   192.5.2.1 becomes an ES, not a core system, and 192.5.2.2 becomes a
   core system and an IS.  Suppose further that the experimenters at the
   U of Fordor do not inform the IANA of the change immediately, so the



Hagens, Hall, & Rose                                           [Page 14]

RFC 1070                  Experimental OSI Net             February 1989


   core.EON file is out-of-date for a while.  The effect will be that
   other core systems will continue to send configuration messages to
   192.5.2.1, which will respond as an ES, not as an IS, and it will
   appear that 192.5.2.2 is not reachable from the rest of the topology
   because the other core systems will not know to send configuration
   information to it.  However, when 192.5.2.2 is booted, it will send
   configuration messages to all core systems informing them of its
   existence via the IS-IS protocol.  Those core systems that are acting
   as ISs will respond with their configuration messages, update their
   core system caches, thereby establishing a set of logical links
   between 192.5.2.2 and the rest of the core systems.

Relationship of this Memo to other RFCs

   RFCs 1006 and 983

      ISO Transport Services on top of the TCP.  Whereas RFCs 1006 and
      983 offer a means of running the OSI session layer protocol and
      higher OSI layers over TCP/IP, this memo provides a means of
      running the OSI network and transport layers on an IP
      internetwork.

   RFC 1069

      Guidelines for the use of Internet-IP addresses in the ISO
      Connectionless-Mode Network Protocol.  RFC 1069 suggests a method
      to use the existing Internet routing and addressing in a gateway
      that forwards ISO connectionless network layer protocol datagrams.
      In contrast, this memo suggests a method to use the ISO routing
      and addressing in a gateway that forwards ISO connectionless
      network layer protocol datagrams.

   RFC 982

      ANSI Working Document X3S3.3/85-258.  This is a set of guidelines
      for specifying the structure of the DSP part of an ISO address.
      The addresses described in this memo meet the guidelines set forth
      in RFC 982.

References

      Plummer, D., "An Ethernet Address Resolution Protocol - or -
      Converting Network Protocol Addresses to 48.bit Ethernet Address
      for Transmission on Ethernet Hardware", RFC 826, MIT, November
      1982.

      Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A Reverse
      Address Resolution Protocol", RFC 903, Stanford, June 1984.



Hagens, Hall, & Rose                                           [Page 15]

RFC 1070                  Experimental OSI Net             February 1989


      Postel, J., "Internet Protocol - DARPA Internet Program Protocol
      Specification", RFC 791, DARPA, September 1981.

      Postel, J., "Internet Control Message Protocol - DARPA Internet
      Program Protocol Specification", RFC 792, ISI, September 1981.

      Postel, J., "User Datagram Protocol", RFC 768, ISI, August 1980.

      ISO, "Protocol For Providing the Connectionless Mode Network
      Service", (ISO 8473), March 1986.  (This is also published as RFC
      994.)

      ISO, "End System to Intermediate System Routing Exchange Protocol
      for Use in Conjunction with the Protocol for the Provision of the
      Connectionless-mode Network Service (ISO 8473)", (ISO DP 9542).
      (This is also published as RFC 995.)

      ISO, "Intermediate System to Intermediate System Intra-Domain
      Routing Exchange Protocol", (ISO TC 97/SC 6/N xxxx).

      OSI, "OSI Routing Framework", (PD TR 97/SC 6/N 9575).






























Hagens, Hall, & Rose                                           [Page 16]

RFC 1070                  Experimental OSI Net             February 1989


Authors' Addresses

      Robert A. Hagens
      Computer Sciences Department
      University of Wisconsin - Madison
      1210 West Dayton Street
      Madison, WI  53706
      608/ 262-1017

      EMail: hagens@cs.wisc.edu

      Nancy E. Hall
      Computer Sciences Department
      University of Wisconsin - Madison
      1210 West Dayton Street
      Madison, WI  53706
      608/ 262-5945

      EMail: nhall@cs.wisc.edu

      Marshall T. Rose
      The Wollongong Group
      San Antonio Blvd.
      Palo Alto, California
      415/ 962-7100

      Email: mrose@twg.com




Comments and Suggestions

   Please direct comments, suggestions, and indications of desire to
   participate to the authors.
















Hagens, Hall, & Rose                                           [Page 17]