rfc1287.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           D. Clark
Request for Comments: 1287                                           MIT
                                                               L. Chapin
                                                                     BBN
                                                                 V. Cerf
                                                                    CNRI
                                                               R. Braden
                                                                     ISI
                                                                R. Hobby
                                                                UC Davis
                                                           December 1991


                Towards the Future Internet Architecture

Status of this Memo

   This informational RFC discusses important directions for possible
   future evolution of the Internet architecture, and suggests steps
   towards the desired goals.  It is offered to the Internet community
   for discussion and comment.  This memo provides information for the
   Internet community.  It does not specify an Internet standard.
   Distribution of this memo is unlimited.

Table of Contents

   1.  INTRODUCTION .................................................  2

   2.  ROUTING AND ADDRESSING .......................................  5

   3.  MULTI-PROTOCOL ARCHITECTURES .................................  9

   4.  SECURITY ARCHITECTURE ........................................ 13

   5   TRAFFIC CONTROL AND STATE .................................... 16

   6.  ADVANCED APPLICATIONS ........................................ 18

   7.  REFERENCES ................................................... 21

   APPENDIX A. Setting the Stage .................................... 22

   APPENDIX B. Group Membership ..................................... 28

   Security Considerations .......................................... 29

   Authors' Addresses ............................................... 29




Clark, Chapin, Cerf, Braden, & Hobby                            [Page 1]

RFC 1287            Future of Internet Architecture        December 1991


1.  INTRODUCTION

   1.1 The Internet Architecture

      The Internet architecture, the grand plan behind the TCP/IP
      protocol suite, was developed and tested in the late 1970s by a
      small group of network researchers [1-4].  Several important
      features were added to the architecture during the early 1980's --
      subnetting, autonomous systems, and the domain name system [5,6].
      More recently, IP multicasting has been added [7].

      Within this architectural framework, the Internet Engineering Task
      Force (IETF) has been working with great energy and effectiveness
      to engineer, define, extend, test, and standardize protocols for
      the Internet.  Three areas of particular importance have been
      routing protocols, TCP performance, and network management.
      Meanwhile, the Internet infrastructure has continued to grow at an
      astonishing rate.  Since January 1983 when the ARPANET first
      switched from NCP to TCP/IP, the vendors, managers, wizards, and
      researchers of the Internet have all been laboring mightily to
      survive their success.

      A set of the researchers who had defined the Internet architecture
      formed the original membership of the Internet Activities Board
      (IAB).  The IAB evolved from a technical advisory group set up in
      1981 by DARPA to become the general technical and policy oversight
      body for the Internet.  IAB membership has changed over the years
      to better represent the changing needs and issues in the Internet
      community, and more recently, to reflect the internationalization
      of the Internet, but it has retained an institutional concern for
      the protocol architecture.

      The IAB created the Internet Engineering Task Force (IETF) to
      carry out protocol development and engineering for the Internet.
      To manage the burgeoning IETF activities, the IETF chair set up
      the Internet Engineering Steering Group (IESG) within the IETF.
      The IAB and IESG work closely together in ratifying protocol
      standards developed within the IETF.

      Over the past few years, there have been increasing signs of
      strains on the fundamental architecture, mostly stemming from
      continued Internet growth.  Discussions of these problems
      reverberate constantly on many of the major mailing lists.

   1.2  Assumptions

      The priority for solving the problems with the current Internet
      architecture depends upon one's view of the future relevance of



Clark, Chapin, Cerf, Braden, & Hobby                            [Page 2]

RFC 1287            Future of Internet Architecture        December 1991


      TCP/IP with respect to the OSI protocol suite.  One view has been
      that we should just let the TCP/IP suite strangle in its success,
      and switch to OSI protocols.  However, many of those who have
      worked hard and successfully on Internet protocols, products, and
      service are anxious to try to solve the new problems within the
      existing framework.  Furthermore, some believe that OSI protocols
      will suffer from versions of many of the same problems.

      To begin to attack these issues, the IAB and the IESG held a one-
      day joint discussion of Internet architectural issues in January
      1991.  The framework for this meeting was set by Dave Clark (see
      Appendix A for his slides).  The discussion was spirited,
      provocative, and at times controversial, with a lot of soul-
      searching over questions of relevance and future direction.  The
      major result was to reach a consensus on the following four basic
      assumptions regarding the networking world of the next 5-10 years.

      (1)  The TCP/IP and OSI suites will coexist for a long time.

           There are powerful political and market forces as well as
           some technical advantages behind the introduction of the OSI
           suite.  However, the entrenched market position of the TCP/IP
           protocols means they are very likely to continue in service
           for the foreseeable future.

      (2)  The Internet will continue to include diverse networks and
           services, and will never be comprised of a single network
           technology.

           Indeed, the range of network technologies and characteristics
           that are connected into the Internet will increase over the
           next decade.

      (3)  Commercial and private networks will be incorporated, but we
           cannot expect the common carriers to provide the entire
           service.  There will be mix of public and private networks,
           common carriers and private lines.

      (4)  The Internet architecture needs to be able to scale to 10**9
           networks.

           The historic exponential growth in the size of the Internet
           will presumably saturate some time in the future, but
           forecasting when is about as easy as forecasting the future
           economy.  In any case, responsible engineering requires an
           architecture that is CAPABLE of expanding to a worst-case
           size.  The exponent "9" is rather fuzzy; estimates have
           varied from 7 to 10.



Clark, Chapin, Cerf, Braden, & Hobby                            [Page 3]

RFC 1287            Future of Internet Architecture        December 1991


   1.3  Beginning a Planning Process

      Another result of the IAB and IESG meeting was the following list
      of the five most important areas for architectural evolution:

      (1)  Routing and Addressing

           This is the most urgent architectural problem, as it is
           directly involved in the ability of the Internet to continue
           to grow successfully.

      (2)  Multi-Protocol Architecture

           The Internet is moving towards widespread support of both the
           TCP/IP and the OSI protocol suites.  Supporting both suites
           raises difficult technical issues, and a plan -- i.e., an
           architecture -- is required to increase the chances of
           success.  This area was facetiously dubbed "making the
           problem harder for the good of mankind."

           Clark had observed that translation gateways (e.g., mail
           gateways) are very much a fact of life in Internet operation
           but are not part of the architecture or planning.  The group
           discussed the possibility of building the architecture around
           the partial connectivity that such gateways imply.

      (3)  Security Architecture

           Although military security was considered when the Internet
           architecture was designed, the modern security issues are
           much broader, encompassing commercial requirements as well.
           Furthermore, experience has shown that it is difficult to add
           security to a protocol suite unless it is built into the
           architecture from the beginning.

      (4)  Traffic Control and State

           The Internet should be extended to support "real-time"
           applications like voice and video.  This will require new
           packet queueing mechanisms in gateways -- "traffic control"
           -- and additional gateway state.

      (5)  Advanced Applications

           As the underlying Internet communication mechanism matures,
           there is an increasing need for innovation and
           standardization in building new kinds of applications.




Clark, Chapin, Cerf, Braden, & Hobby                            [Page 4]

RFC 1287            Future of Internet Architecture        December 1991


      The IAB and IESG met again in June 1991 at SDSC and devoted three
      full days to a discussion of these five topics.  This meeting,
      which was called somewhat perversely the "Architecture Retreat",
      was convened with a strong resolve to take initial steps towards
      planning evolution of the architecture.  Besides the IAB and IESG,
      the group of 32 people included the members of the Research
      Steering Group (IRSG) and a few special guests.  On the second
      day, the Retreat broke into groups, one for each of the five
      areas.  The group membership is listed in Appendix B.

      This document was assembled from the reports by the chairs of
      these groups.  This material was presented at the Atlanta IETF
      meeting, and appears in the minutes of that meeting [8].

2.  ROUTING AND ADDRESSING

   Changes are required in the addressing and routing structure of IP to
   deal with the anticipated growth and functional evolution of the
   Internet.  We expect that:

   o    The Internet will run out of certain classes of IP network
        addresses, e.g., B addresses.

   o    The Internet will run out of the 32-bit IP address space
        altogether, as the space is currently subdivided and managed.

   o    The total number of IP network numbers will grow to the point
        where reasonable routing algorithms will not be able to perform
        routing based upon network numbers.

   o    There will be a need for more than one route from a source to a
        destination, to permit variation in TOS and policy conformance.
        This need will be driven both by new applications and by diverse
        transit services.  The source, or an agent acting for the
        source, must control the selection of the route options.

   2.1  Suggested Approach

      There is general agreement on the approach needed to deal with
      these facts.

      (a)  We must move to an addressing scheme in which network numbers
           are aggregated into larger units as the basis for routing.
           An example of an aggregate is the Autonomous System, or the
           Administrative Domain (AD).

           Aggregation will accomplish several goals: define regions
           where policy is applied, control the number of routing



Clark, Chapin, Cerf, Braden, & Hobby                            [Page 5]

RFC 1287            Future of Internet Architecture        December 1991


           elements, and provide elements for network management.  Some
           believe that it must be possible to further combine
           aggregates, as in a nesting of ADs.

      (b)  We must provide some efficient means to compute common
           routes, and some general means to compute "special" routes.

           The general approach to special routes will be some form of
           route setup specified by a "source route".

      There is not full agreement on how ADs may be expected to be
      aggregated, or how routing protocols should be organized to deal
      with the aggregation boundaries.   A very general scheme may be
      used [ref. Chiappa], but some prefer a scheme that more restricts
      and defines the expected network model.

      To deal with the address space exhaustion, we must either expand
      the address space or else reuse the 32 bit field ("32bf") in
      different parts of the net.  There are several possible address
      formats that might make sense, as described in the next section.

      Perhaps more important is the question of how to migrate to the
      new scheme.  All migration plans will require that some routers
      (or other components inside the Internet) be able to rewrite
      headers to accommodate hosts that handle only the old or format or
      only the new format.  Unless the need for such format conversion
      can be inferred algorithmically, migration by itself will require
      some sort of setup of state in the conversion element.

      We should not plan a series of "small" changes to the
      architecture.  We should embark now on a plan that will take us
      past the exhaustion of the address space.  This is a more long-
      range act of planning than the Internet community has undertaken
      recently, but the problems of migration will require a long lead
      time, and it is hard to see an effective way of dealing with some
      of the more immediate problems, such as class B exhaustion, in a
      way that does not by itself take a long time.  So, once we embark
      on a plan of change, it should take us all the way to replacing
      the current 32-bit global address space.  (This conclusion is
      subject to revision if, as is always possible, some very clever
      idea surfaces that is quick to deploy and gives us some breathing
      room.  We do not mean to discourage creative thinking about
      short-term actions.  We just want to point out that even small
      changes take a long time to deploy.)

      Conversion of the address space by itself is not enough.  We must
      at the same time provide a more scalable routing architecture, and
      tools to better manage the Internet.  The proposed approach is to



Clark, Chapin, Cerf, Braden, & Hobby                            [Page 6]

RFC 1287            Future of Internet Architecture        December 1991


      ADs as the unit of aggregation for routing.  We already have
      partial means to do this.  IDPR does this.  The OSI version of BGP
      (IDRP) does this.  BGP could evolve to do this.  The additional
      facility needed is a global table that maps network numbers to
      ADs.

      For several reasons (special routes and address conversion, as
      well as accounting and resource allocation), we are moving from a
      "stateless" gateway model, where only precomputed routes are
      stored in the gateway, to a model where at least some of the
      gateways have per-connection state.

   2.2  Extended IP Address Formats

      There are three reasonable choices for the extended IP address
      format.

      A)   Replace the 32 bit field (32bf) with a field of the same size
           but with different meaning.  Instead of being globally
           unique, it would now be unique only within some smaller
           region (an AD or an aggregate of ADs).  Gateways on the
           boundary would rewrite the address as the packet crossed the
           boundary.

           Issues: (1) addresses in the body of packets must be found
           and rewritten; (2) the host software need not be changed; (3)
           some method (perhaps a hack to the DNS) must set up the
           address mappings.

           This scheme is due to Van Jacobson.  See also the work by
           Paul Tsuchiya on NAT.

      B)   Expand the 32bf to a 64 bit field (or some other new size),
           and use the field to hold a global host address and an AD for
           that host.

           This choice would provide a trivial mapping from the host to
           the value (the AD) that is the basis of routing.  Common
           routes (those selected on the basis of destination address
           without taking into account the source address as well) can
           be selected directly from the packet address, as is done
           today, without any prior setup.

      3)   Expand the 32bf to a 64 bit field (or some other new size),
           and use the field as a "flat" host identifier.  Use
           connection setup to provide routers with the mapping from
           host id to AD, as needed.




Clark, Chapin, Cerf, Braden, & Hobby                            [Page 7]

RFC 1287            Future of Internet Architecture        December 1991


           The 64 bits can now be used to simplify the problem of
           allocating host ids, as in Ethernet addresses.

      Each of these choices would require an address re-writing module
      as a part of migration.  The second and third require a change to
      the IP header, so host software must change.

   2.3  Proposed Actions