rfc1287.txt

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

      Finally, it must be observed that we have no good solutions to
      safely storing secret information (such as the secret component of
      a public key pair) on systems like PCs or laptop computers that
      are not designed to enforce secure storage.

   4.4  Proposed Actions

      The following actions are proposed.

      A)   Security Reference Model

           A Security Reference Model for the Internet is needed, and it
           should be developed expeditiously.  This model should
           establish the target perimeters and document the objectives
           of the security architecture.

      B)   Privacy-Enhanced Mail (PEM)

           For Privacy Enhanced Mail, the most critical steps seem to be
           the installation of (1) a certificate generation and
           management infrastructure, and (2) X.500 directory services
           to provide access to public keys via distinguished names.
           Serious attention also needs to be placed on any limitations



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


           imposed by patent and export restrictions on the deployment
           of this system.

      C)   Distributed System Security

           We should examine security methods for distributed systems
           applications, in both simple (client/server) and complex
           (distributed computing environment) cases.  For example, the
           utility of certificates granting permissions/capabilities to
           objects bound to distinguished names should be examined.

      D)   Host-Level Security

           SP4 should be evaluated for host-oriented security, but SP3
           should also be considered for this purpose.

      E)   Application-Level Security

           We should implement application-level security services, both
           for their immediate utility (e.g., PEM, SNMP authentication)
           and also to gain valuable practical experience that can
           inform the refinement of the Internet security architecture.

5.  TRAFFIC CONTROL AND STATE

   In the present Internet, all IP datagrams are treated equally.  Each
   datagram is forwarded independently, regardless of any relationship
   it has to other packets for the same connection, for the same
   application, for the same class of applications, or for the same user
   class.  Although Type-of-Service and Precedence bits are defined in
   the IP header, these are not generally implemented, and in fact it is
   not clear how to implement them.

   It is now widely accepted that the future Internet will need to
   support important applications for which best-effort is not
   sufficient -- e.g., packet video and voice for teleconferencing.
   This will require some "traffic control" mechanism in routers,
   controlled by additional state, to handle "real-time" traffic.

   5.1  Assumptions and Principles


      o    ASSUMPTION: The Internet will need to support performance
           guarantees for particular subsets of the traffic.

      Unfortunately, we are far from being able to give precise meanings
      to the terms "performance", "guarantees", or "subsets" in this
      statement.  Research is still needed to answer these questions.



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


      o    The default service will continue to be the current "best-
           effort" datagram delivery, with no service guarantees.

      o    The mechanism of a router can be separated into (1) the
           forwarding path and (2) the control computations (e.g.,
           routing) which take place in the background.

           The forwarding path must be highly optimized, sometimes with
           hardware-assist, and it is therefore relatively costly and
           difficult to change.  The traffic control mechanism operates
           in the forwarding path, under the control of state created by
           routing and resource control computations that take place in
           background.  We will have at most one shot at changing the
           forwarding paths of routers, so we had better get it right
           the first time.

      o    The new extensions must operate in a highly heterogeneous
           environment, in which some parts will never support
           guarantees.  For some hops of a path (e.g., a high-speed
           LAN), "over-provisioning" (i.e., excess capacity) will allow
           adequate service for real-time traffic, even when explicit
           resource reservation is unavailable.

      o    Multicast distribution is probably essential.

   5.2  Technical Issues

      There are a number of technical issues to be resolved, including:

      o    Resource Setup

           To support real-time traffic, resources need to be reserved
           in each router along the path from source to destination.
           Should this new router state be "hard" (as in connections) or
           "soft" (i.e., cached state)?

      o    Resource binding vs. route binding

           Choosing a path from source to destination is traditionally
           performed using a dynamic routing protocol.  The resource
           binding and the routing might be folded into a single complex
           process, or they might be performed essentially
           independently.  There is a tradeoff between complexity and
           efficiency.

      o    Alternative multicast models

           IP multicasting uses a model of logical addressing in which



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


           targets attach themselves to a group.  In ST-2, each host in
           a multicast session includes in its setup packet an explicit
           list of target addresses.  Each of these approaches has
           advantages and drawbacks; it is not currently clear which
           will prevail for n-way teleconferences.

      o    Resource Setup vs. Inter-AD routing

           Resource guarantees of whatever flavor must hold across an
           arbitrary end-to-end path, including multiple ADs.  Hence,
           any resource setup mechanism needs to mesh smoothly with the
           path setup mechanism incorporated into IDPR.

      o    Accounting

           The resource guarantee subsets ("classes") may be natural
           units for accounting.

   5.3  Proposed Actions

      The actions called for here are further research on the technical
      issues listed above, followed by development and standardization
      of appropriate protocols.  DARTnet, the DARPA Research Testbed
      network, will play an important role in this research.

6.  ADVANCED APPLICATIONS

   One may ask: "What network-based applications do we want, and why
   don't we have them now?"  It is easy to develop a large list of
   potential applications, many of which would be based on a
   client/server model.  However, the more interesting part of the
   question is: "Why haven't people done them already?"  We believe the
   answer to be that the tools to make application writing easy just do
   not exist.

   To begin, we need a set of common interchange formats for a number of
   data items that will be used across the network.  Once these common
   data formats have been defined, we need to develop tools that the
   applications can use to move the data easily.

   6.1  Common Interchange Formats

      The applications have to know the format of information that they
      are exchanging, for the information to have any meaning.   The
      following format types are to concern:

      (1)  Text - Of the formats in this list, text is the most stable,
           but today's international Internet has to address the needs



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


           of character sets other than USASCII.

      (2)  Image -  As we enter the "Multimedia Age", images will become
           increasingly important, but we need to agree on how to
           represent them in packets.

      (3)  Graphics - Like images, vector graphic information needs a
           common definition. With such a format we could exchange
           things like architectural blueprints.

      (4)  Video - Before we can have a video window running on our
           workstation, we need to know the format of that video
           information coming over the network.

      (5)  Audio/Analog - Of course, we also need the audio to go with
           the video, but such a format would be used for representation
           of all types of analog signals.

      (6)  Display - Now that we are opening windows on our workstation,
           we want to open a window on another person's workstation to
           show her some data pertinent to the research project, so now
           we need a common window display format.

      (7)  Data Objects - For inter-process communications we need to
           agree on the formats of things like integers, reals, strings,
           etc.

      Many of these formats are being defined by other, often several
      other, standards organizations.  We need to agree on one format
      per category for the Internet.

   6.2  Data Exchange Methods

      Applications will require the following methods of data exchange.

      (1)  Store and Forward

           Not everyone is on the network all the time.  We need a
           standard means of providing an information flow to
           sometimes-connected hosts, i.e., we need a common store-and-
           forward service.  Multicasting should be included in such a
           service.

      (2)  Global File Systems

           Much of the data access over the network can be broken down
           to simple file access. If you had a real global file system
           where you access any file on the Internet (assuming you have



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


           permission), would you ever need FTP?

      (3)  Inter-process Communications

           For a true distributed computing environment, we need the
           means to allow processes to exchange data in a standard
           method over the network.  This requirement encompasses RPC,
           APIs, etc.

      (4)  Data Broadcast

           Many  applications need to send the same information to many
           other hosts.  A standard and efficient method is needed to
           accomplish this.

      (5)  Database Access

           For good information exchange, we need to have a standard
           means for accessing databases. The Global File System can get
           you to the data, but the database access methods will tell
           you about its structure and content.

      Many of these items are being addressed by other organizations,
      but for Internet interoperability, we need to agree on the methods
      for the Internet.

      Finally, advanced applications need solutions to the problems of
      two earlier areas in this document.  From the Traffic Control and
      State area, applications need the ability to transmit real-time
      data.  This means some sort of expectation level for data delivery
      within a certain time frame.  Applications also require global
      authentication and access control systems from the Security area.
      Much of the usefulness of today's Internet applications is lost
      due to the lack of trust and security.  This needs to be solved
      for tomorrow's applications.
















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


7.  REFERENCES

   [1]  Cerf, V. and R. Kahn, "A Protocol for Packet Network
        Intercommunication," IEEE Transactions on Communication, May
        1974.

   [2]  Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet
        Protocol," Computer Networks, Vol. 5, No. 4, July 1981.

   [3]  Leiner, B., Postel, J., Cole, R., and D. Mills, "The DARPA
        Internet Protocol Suite," Proceedings INFOCOM 85, IEEE,
        Washington DC, March 1985.  Also in: IEEE Communications
        Magazine, March 1985.

   [4]  Clark, D., "The Design Philosophy of the DARPA Internet
        Protocols", Proceedings ACM SIGCOMM '88, Stanford, California,
        August 1988.

   [5]  Mogul, J., and J. Postel, "Internet Standard Subnetting
        Procedure", RFC 950, USC/Information Sciences Institute, August
        1985.

   [6]  Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
        1034, USC/Information Sciences Institute, November 1987.

   [7]  Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
        Stanford University, August 1989.

   [8]  "Proceedings of the Twenty-First Internet Engineering Task
        Force", Bell-South, Atlanta, July 29 - August 2, 1991.





















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


APPENDIX A: Setting the Stage


   Slide 1
                           WHITHER THE INTERNET?

                         OPTIONS FOR ARCHITECTURE



                           IAB/IESG -- Jan 1990



                              David D. Clark



   __________________________________________________________________
   Slide 2

                      SETTING THE TOPIC OF DISCUSSION

   Goals:

       o Establish a common frame of understanding for
         IAB, IESG and the Internet community.

       o Understand the set of problems to be solved.

       o Understand the range of solutions open to us.

       o Draw some conclusions, or else
         "meta-conclusions".