GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc1070

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:
  1. how ISO-grams will be encapsulated in IP or UDP packets,
  1. the format of NSAP-addresses to be used,
  1. how NSAP-addresses will be mapped to SNPA-addresses on

the IP subnet,

  1. how multicasting, which is assumed by some OSI CLNL

protocols, will be satisfied, and

  1. 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:
  1. to facilitate the testing of the OSI network layer

protocols among different implementions,

  1. to do this as soon as possible, exploiting existing

connectivity,

  1. to do this without requiring any changes to existing IP

gateways,

  1. to create a logical topology that can be changed

easily, for the purpose of testing the dynamic adaptive

      properties of the protocols, and
  1. 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

  1. to permit the use of arbitrary ISO-style

NSAP-addresses,

  1. to require that participants have working

implementations of all of the OSI routing protocols

      before they can participate in any capacity,
  1. to permit or encourage the use of existing IP routing

methods and algorithms for the routing of ISO-grams

      among participating ESs and ISs,
  1. to create a production-like environment accommodating a

very large number of systems (ESs, ISs or both), and

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1070.txt · Last modified: 1989/02/17 17:42 (external edit)