rfc1287.txt

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

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


   __________________________________________________________________
   Slide 3

                        SOME CLAIMS -- MY POSITION

   We have two different goals:
      o Make it possible to build "The Internet"
      o Define a protocol suite called Internet

   Claim: These goals have very different implications.
     The protocols are but a means, though a powerful one.

   Claim: If "The Internet" is to succeed and grow, it will
     require specific design efforts.  This need will continue
     for at least another 10 years.

   Claim: Uncontrolled growth could lead to chaos.

   Claim: A grass-roots solution seems to be the only
     means to success.  Top-down mandates are powerless.


   __________________________________________________________________
   Slide 4

                          OUTLINE OF PRESENTATION

   1) The problem space and the solution space.

   2) A set of specific questions -- discussion.

   3) Return to top-level questions -- discussion.

   4) Plan for action -- meta discussion.

   Try to separate functional requirements from technical approach.

   Understand how we are bounded by our problem space and our
     solution space.

   Is architecture anything but protocols?










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


   __________________________________________________________________
   Slide 5

                        WHAT IS THE PROBLEM SPACE?

   Routing and addressing:
      How big, what topology, and what routing model?

   Getting big:
      User services, what technology for host and nets?

   Divestiture of the Internet:
      Accounting, controlling usage and fixing faults.

   New services:
      Video? Transactions? Distributed computing?

   Security:
      End node or network?  Routers or relays?

   __________________________________________________________________
   Slide 6

                        BOUNDING THE SOLUTION SPACE

   How far can we migrate from the current state?
      o Can we change the IP header (except to OSI)?
      o Can we change host requirements in mandatory ways?
      o Can we manage a long-term migration objective?
         -  Consistent direction vs. diverse goals, funding.

   Can we assume network-level connectivity?
      o Relays are the wave of the future (?)
      o Security a key issue; along with conversion.
      o Do we need a new "relay-based" architecture?

   How "managed" can/must "The Internet" be?
      o Can we manage or constrain connectivity?

   What protocols are we working with? One or many?











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


   __________________________________________________________________
   Slide 7

                        THE MULTI-PROTOCOL INTERNET

   "Making the problem harder for the good of mankind."

   Are we migrating, interoperating, or tolerating multiple protocols?
      o Not all protocol suites will have same range of functionality
        at the same time.
      o "The Internet" will require specific functions.

   Claim: Fundamental conflict (not religion or spite):
      o Meeting aggressive requirements for the Internet
      o Dealing with OSI migration.

   Conclusion: One protocol must "lead", and the others must follow.
      When do we "switch" to OSI?

   Consider every following slide in this context.

   __________________________________________________________________
   Slide 8

                          ROUTING and ADDRESSING

   What is the target size of "The Internet"?
      o How do addresses and routes relate?
      o What is the model of topology?
      o What solutions are possible?

   What range of policy routing is required?
      o BGP and IDRP are two answers.  What is the question?
      o Fixed classes, or variable paths?
      o Source controlled routing is a minimum.

   How seamless is the needed support for mobile hosts?
      o New address class, rebind to local address, use DNS?

   Shall we push for Internet multicast?











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


   __________________________________________________________________
   Slide 9

                        GETTING BIG -- AN OLD TITLE

   (Addressing and routing was on previous slide...)

   What user services will be needed in the next 10 years?
      o Can we construct a plan?
      o Do we need architectural changes?

   Is there a requirement for dealing better with ranges in
      speed, packet sizes, etc.
      o Policy to phase out fragmentation?

   What range of hosts (things != Unix) will we support?


   _________________________________________________________________
   Slide 10

                         DEALING WITH DIVESTITURE

   The Internet is composed of parts separately managed and
   controlled.

   What support is needed for network charging?
      o No architecture implies bulk charges and re-billing, pay
          for lost packets.
      o Do we need controls to supply billing id or routing?

   Requirement: we must support links with controlled sharing.
      (Simple form is classes based on link id.)
      o How general?

   Is there an increased need for fault isolation? (I vote yes!)
      o How can we find managers to talk to?
      o Do we need services in hosts?













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


   _________________________________________________________________
   Slide 11

                               NEW SERVICES

   Shall we support video and audio? Real time? What %?
      o Need to plan for input from research.  What quality?
      o Target date for heads-up to vendors.

   Shall we "better" support transactions?
      o Will TCP do? VMTP? Presentation? Locking?

   What application support veneers are coming?
      o Distributed computing -- will it actually happen?
      o Information networking?

   __________________________________________________________________
   Slide 12

                                 SECURITY

   Can we persist in claiming the end-node is the only line of defense?
      o What can we do inside the network?
      o What can ask the host to do?

   Do we tolerate relays, or architect them?
   Can find a better way to construct security boundaries?

   Do we need global authentication?

   Do we need new host requirements:
      o Logging.
      o Authentication.
      o Management interfaces.
         - Phone number or point of reference.

   __________________________________________________________________














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


APPENDIX B: Group Membership

   Group 1: ROUTING AND ADDRESSING

       Dave Clark, MIT  [Chair]
       Hans-Werner Braun, SDSC
       Noel Chiappa, Consultant
       Deborah Estrin, USC
       Phill Gross, CNRI
       Bob Hinden, BBN
       Van Jacobson, LBL
       Tony Lauck, DEC.

   Group 2: MULTI-PROTOCOL ARCHITECTURE

       Lyman Chapin, BBN  [Chair]
       Ross Callon, DEC
       Dave Crocker, DEC
       Christian Huitema, INRIA
       Barry Leiner,
       Jon Postel, ISI

   Group 3: SECURITY ARCHITECTURE

       Vint Cerf, CNRI  [Chair]
       Steve Crocker, TIS
       Steve Kent, BBN
       Paul Mockapetris, DARPA

   Group 4: TRAFFIC CONTROL AND STATE

       Robert Braden, ISI  [Chair]
       Chuck Davin,  MIT
       Dave Mills, University of Delaware
       Claudio Topolcic, CNRI

   Group 5: ADVANCED APPLICATIONS

       Russ Hobby, UCDavis  [Chair]
       Dave Borman, Cray Research
       Cliff Lynch, University of California
       Joyce K. Reynolds, ISI
       Bruce Schatz, University of Arizona
       Mike Schwartz, University of Colorado
       Greg Vaudreuil, CNRI.






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


Security Considerations

   Security issues are discussed in Section 4.

Authors' Addresses

   David D. Clark
   Massachusetts Institute of Technology
   Laboratory for Computer Science
   545 Main Street
   Cambridge, MA 02139

   Phone: [phone]
   EMail: [e-mail]

   Vinton G. Cerf
   Corporation for National Research Initiatives
   1895 Preston White Drive, Suite 100
   Reston, VA 22091

   Phone: [phone]
   EMail: [e-mail]

   Lyman A. Chapin
   Bolt, Beranek & Newman
   Mail Stop 20/5b
   150 Cambridge Park Drive
   Cambridge, MA 02140

   Phone: [phone]
   EMail: [e-mail]

   Robert Braden
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: [phone]
   EMail: [e-mail]

   Russell Hobby
   University of California
   Computing Services
   Davis, CA 95616

   Phone: [phone]
   EMail: [e-mail]




Clark, Chapin, Cerf, Braden, & Hobby                           [Page 29]