rfc917.txt

RFC 相关的技术文档

Network Working Group                                      Jeffrey Mogul
Request for Comments: 917                    Computer Science Department
                                                     Stanford University
                                                            October 1984

                            INTERNET SUBNETS


Status Of This Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

Overview

   We discuss the utility of "subnets" of Internet networks, which are
   logically visible sub-sections of a single Internet network.  For
   administrative or technical reasons, many organizations have chosen
   to divide one Internet network into several subnets, instead of
   acquiring a set of Internet network numbers.

   We propose procedures for the use of subnets, and discuss approaches
   to solving the problems that arise, particularly that of routing.

Acknowledgment

   This proposal is the result of discussion with several other people.
   J. Noel Chiappa, Chris Kent, and Tim Mann, in particular, provided
   important suggestions.

1. Introduction

   The original view of the Internet universe was a two-level hierarchy:
   the top level the catenet as a whole, and the level below it a
   collection of "Internet Networks", each with its own Network Number.
   (We do not mean that the Internet has a hierarchical topology, but
   that the interpretation of addresses is hierarchical.)

   While this view has proved simple and powerful, a number of
   organizations have found it inadequate and have added a third level
   to the interpretation of Internet addresses.  In this view, a given
   Internet Network might (or might not) be divided into a collection of
   subnets.

   The original, two-level, view carries a strong presumption that, to a
   host on an Internet network, that network may be viewed as a single
   edge; to put it another way, the network may be treated as a "black
   box" to which a set of hosts is connected.  This is true of the




Mogul                                                           [Page 1]



RFC 917                                                     October 1984
Internet Subnets


   ARPANET, because the IMPs mask the use of specific links in that
   network.  It is also true of most local area network (LAN)
   technologies, such as Ethernet or ring networks.

   However, this presumption fails in many practical cases, because in
   moderately large organizations (e.g., Universities or companies with
   more than one building) it is often necessary to use more than one
   LAN cable to cover a "local area".  For example, at this writing
   there are eighteen such cables in use at Stanford University, with
   more planned.

   There are several reasons why an organization might use more than one
   cable to cover a campus:

      - Different technologies: Especially in a research environment,
        there may be more than one kind of LAN in use; e.g., an
        organization may have some equipment that supports Ethernet, and
        some that supports a ring network.

      - Limits of technologies: Most LAN technologies impose limits,
        based electrical parameters, on the number of hosts connected,
        and on the total length of the cable.  It is easy to exceed
        these limits, especially those on cable length.

      - Network congestion: It is possible for a small subset of the
        hosts on a LAN to monopolize most of the bandwidth.  A common
        solution to this problem is to divide the hosts into cliques of
        high mutual communication, and put these cliques on separate
        cables.

      - Point-to-Point links: Sometimes a "local area", such as a
        university campus, is split into two locations too far apart to
        connect using the preferred LAN technology.  In this case,
        high-speed point-to-point links might connect several LANs.

   An organization that has been forced to use more than one LAN has
   three choices for assigning Internet addresses:

      1. Acquire a distinct Internet network number for each cable.

      2. Use a single network number for the entire organization, but
         assign host numbers without regard to which LAN a host is on.
         (We will call this choice "transparent subnets".)

      3. Use a single network number, and partition the host address
         space by assigning subnet numbers to the LANs. ("Explicit
         subnets".)


Mogul                                                           [Page 2]



RFC 917                                                     October 1984
Internet Subnets


   Each of these approaches has disadvantages.  The first, although not
   requiring any new or modified protocols, does result in an explosion
   in the size of Internet routing tables.  Information about the
   internal details of local connectivity is propagated everywhere,
   although it is of little or no use outside the local organization.
   Especially as some current gateway implementations do not have much
   space for routing tables, it would be nice to avoid this problem.

   The second approach requires some convention or protocol that makes
   the collection of LANs appear to be a single Internet network.  For
   example, this can be done on LANs where each Internet address is
   translated to a hardware address using an Address Resolution Protocol
   (ARP), by having the bridges between the LANs intercept ARP requests
   for non-local targets.  However, it is not possible to do this for
   all LAN technologies, especially those where ARP protocols are not
   currently used, or if the LAN does not support broadcasts.  A more
   fundamental problem is that bridges must discover which LAN a host is
   on, perhaps by using a broadcast algorithm.  As the number of LANs
   grows, the cost of broadcasting grows as well; also, the size of
   translation caches required in the bridges grows with the total
   number of hosts in the network.

   The third approach addresses the key problem: existing standards
   assume that all hosts on an Internet local network are on a single
   cable.  The solution is to explicitly support subnets.  This does
   have a disadvantage, in that it is a modification of the Internet
   Protocol, and thus requires changes to IP implementations already in
   use (if these implementations are to be used on a subnetted network.)
   However, we believe that these changes are relatively minor, and once
   made, yield a simple and efficient solution to the problem.  Also,
   the approach we take in this document is to avoid any changes that
   would be incompatible with existing hosts on non-subnetted networks.

   Further, when appropriate design choices are made, it is possible for
   hosts which believe they are on a non-subnetted network to be used on
   a subnetted one, as will be explained later.  This is useful when it
   is not possible to modify some of the hosts to support subnets
   explicitly, or when a gradual transition is preferred.  Because of
   this, there seems little reason to use the second approach listed
   above.

   The rest of this document describes approaches to subnets of Internet
   Networks.






Mogul                                                           [Page 3]



RFC 917                                                     October 1984
Internet Subnets


   1.1. Terminology

      To avoid either ambiguity or prolixity, we will define a few
      terms, which will be used in the following sections:

      Catenet

         The collection of connected Internet Networks

      Network

         A single Internet network (that may or may not be divided into
         subnets.)

      Subnet

         A subnet of an Internet network.

      Network Number

         As in [8].

      Local Address

         The bits in an Internet address not used for the network
         number; also known as "rest field".

      Subnet Number

         A number identifying a subnet within a network.

      Subnet Field

         The bit field in an Internet address used for the subnet
         number.

      Host Field

         The bit field in an Internet address used for denoting a
         specific host.

      Gateway

         A node connected to two or more administratively distinct
         networks and/or subnets, to which hosts send datagrams to be
         forwarded.



Mogul                                                           [Page 4]



RFC 917                                                     October 1984
Internet Subnets


      Bridge

         A node connected to two or more administratively
         indistinguishable but physically distinct subnets, that
         automatically forwards datagrams when necessary, but whose
         existence is not know to other hosts.  Also called a "software
         repeater".

2. Standards for Subnet Addressing

   Following the division presented in [2], we observe that subnets are
   fundamentally an issue of addressing.  In this section, we first
   describe a proposal for interpretation of Internet Addressing to
   support subnets.  We then discuss the interaction between this
   address format and broadcasting; finally, we present a protocol for
   discovering what address interpretation is in use on a given network.

   2.1. Interpretation of Internet Addresses

      Suppose that an organization has been assigned an Internet network
      number, has further divided that network into a set of subnets,
      and wants to assign host addresses: how should this be done?
      Since there are minimal restrictions on the assignment of the
      "local address" part of the Internet address, several approaches
      have been proposed for representing the subnet number:

         1. Variable-width field: Any number of the bits of the local
            address part are used for the subnet number; the size of
            this field, although constant for a given network, varies
            from network to network.  If the field width is zero, then
            subnets are not in use.

         2. Fixed-width field: A specific number of bits (e.g., eight)
            is used for the subnet number, if subnets are in use.

         3. Self-encoding variable-width field: Just as the width (i.e.,
            class) of the network number field is encoded by its
            high-order bits, the width of the subnet field is similarly
            encoded.

         4. Self-encoding fixed-width field: A specific number of bits
            is is used for the subnet number.  Subnets are in use if the
            high-order bit of this field is one; otherwise, the entire
            local address part is used for host number.

      Since there seems to be no advantage in doing otherwise, all these
      schemes place the subnet field as the most significant field in


Mogul                                                           [Page 5]



RFC 917                                                     October 1984
Internet Subnets


      the local address part.  Also, since the local address part of a
      Class C address is so small, there is little reason to support
      subnets of other than Class A and Class B networks.

      What criteria can we use to choose one of these four schemes?
      First, do we want to use a self-encoding scheme; that is, should
      it be possible to tell from examining an Internet address if it
      refers to a subnetted network, without reference to any other
      information?

      One advantage to self-encoding is that it allows one to determine
      if a non-local network has been divided into subnets.  It is not
      clear that this would be of any use.  The principle advantage,
      however, is that no additional information is needed for an
      implementation to determine if two addresses are on the same
      subnet.  However, this can also be viewed as a disadvantage: it
      may cause problems for non-subnetted networks which have existing
      host numbers that use arbitrary bits in the local address part
      <1>.  In other words, it is useful to be able control whether a
      network is subnetted independently from the assignment of host
      addresses.  Another disadvantage of any self-encoding scheme is
      that it reduces the local address space by at least a factor of
      two.