rfc2902.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                           S. Deering
Request for Comments: 2902                                   Cisco Systems
Category: Informational                                           S. Hares
                                                            Merit Networks
                                                                C. Perkins
                                                     Nokia Research Center
                                                                R. Perlman
                                             Sun Microsystems Laboratories
                                                               August 2000


               Overview of the 1998 IAB Routing Workshop

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document is an overview of a Routing workshop held by the
   Internet Architecture Board (IAB) during March 25-27, 1998.  The
   major points of discussion are listed, along with some conclusions
   and action items for many of the points of discussion.

Table of Contents

   1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   2
   2. Conclusions and Action Items  . . . . . . . . . . . . . . . .   3
       2.1. Scaling of Unicast Routing and Addressing . . . . . . .   3
         2.1.1. Unicast Routing - Conclusions . . . . . . . . . . .   3
         2.1.2. Unicast Routing - Action Items  . . . . . . . . . .   4
       2.2. Levels of Addressing of Addressing and Routing  . . . .   4
       2.3. Network Address Translation (NAT) devices . . . . . . .   5
         2.3.1. NAT devices - Conclusions . . . . . . . . . . . . .   5
         2.3.2. NAT devices - Action Items  . . . . . . . . . . . .   5
       2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . .   5
         2.4.1. Multicast - Conclusions . . . . . . . . . . . . . .   5
         2.4.2. Multicast - Action Items  . . . . . . . . . . . . .   6
       2.5. Routing Stability . . . . . . . . . . . . . . . . . . .   6
         2.5.1. Routing Stability - Conclusions . . . . . . . . . .   6
         2.5.2. Routing Stability - Action Items  . . . . . . . . .   7
       2.6. ToS/CoS/QoS . . . . . . . . . . . . . . . . . . . . . .   7



Deering, et al.              Informational                      [Page 1]

RFC 2902       Overview of the 1998 IAB Routing Workshop     August 2000


         2.6.1. ToS/CoS/QoS - Action Items  . . . . . . . . . . . .   8
       2.7. Routing Protocol Security . . . . . . . . . . . . . . .   8
         2.7.1. Routing Security - Conclusions  . . . . . . . . . .   8
         2.7.2. Routing Security - Action Items . . . . . . . . . .   8
       2.8. Routing Policy  . . . . . . . . . . . . . . . . . . . .   8
         2.8.1. Routing Policy - Conclusions  . . . . . . . . . . .   8
         2.8.2. Routing Policy - Action Item  . . . . . . . . . . .   9
       2.9. Network to Host Flow of Information . . . . . . . . . .   9
         2.9.1. Host Information - Conclusions  . . . . . . . . . .   9
         2.9.2. Host Information - Action Items . . . . . . . . . .   9
      2.10. Shorter Topics  . . . . . . . . . . . . . . . . . . . .   9
         2.10.1. Multi-strand Trunking  . . . . . . . . . . . . . .   9
         2.10.2. Routing Diagnostic and Development Tools   . . . .  10
         2.10.3. Anycast  . . . . . . . . . . . . . . . . . . . . .  10
         2.10.4. Load Sensitive IGP routing for Best Effort Traffic  11
         2.10.5. Geographical Addresses and Renumbering   . . . . .  11
   3. Summary of Action items . . . . . . . . . . . . . . . . . . .  11
       3.1. Action Items for the IAB  . . . . . . . . . . . . . . .  11
       3.2. Action Items for IETF Working Group Chairs  . . . . . .  11
       3.3. Action Items for the IRTF Routing Research Group  . . .  12
   4. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   A. Participants  . . . . . . . . . . . . . . . . . . . . . . . .  12
   References . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  15
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  16

1. Introduction

   March 25 to March 27, 1998 the Internet Architecture Board (IAB) held
   a workshop on Routing.  The workshop focused on current problems
   within the Internet and the long term solutions that should be
   addressed.  This document summarizes the discussions the group had on
   routing, and lists the conclusions reached by the workshop.  Section
   2 lists the conclusions reached by the participants of the workshop
   and the suggestions for additional work or redirection of current
   work.  Sections 2.1-2.10 attempt to extract the major points of what
   was, in actuality, many multifaceted discussions, sometimes occurring
   all at the same time.  Appendix A contains a list of the participants
   who attended the workshop.  The full body of the report can be found
   at http://www.iab.org.

   The topics covered at length during the IAB workshop were:

    1. Scaling of Unicast Routing and Addressing (section 2.1)
    2. Unicast Addressing Issues (Section 2.2)
    3. The Effect of extending IP version 4 in the Internet by using
       Network Address Transformation boxes (Section 2.3)
    4. Multicast Routing (Section 2.4)



Deering, et al.              Informational                      [Page 2]

RFC 2902       Overview of the 1998 IAB Routing Workshop     August 2000


    5. Routing Instability (Section 2.5)
    6. Quality of Service Routing (Section 2.6)
    7. Routing Security (Section 2.7)
    8. BGP Policy (Section 2.8)
    9. Flows of information from network routing to hosts for improved
       services (Section 2.9)

   In addition the following topics were briefly covered:

    a. Multi-strand trunking
    b. Better tools for monitoring and diagnosis of network problems
    c. Routing protocol bandwidth minimization
    d. Automatic renumbering and automatic organization
    e. Anycast
    f. Load-sensitive routing
    g. Geographical addressing

   These shorter topics are contained in section 2.10.

   It would be unrealistic to assume that the workshop had definitive
   answers to all the technical problems that were raised.  The best
   that can be hoped is that we raised most of the relevant issues and
   gave opinions that were the best guess of the people at the meeting,
   keeping in mind that the attendees did not come armed with data to
   back up opinions.  Much of the discussion amounted to an exploration
   of the intuition of the experts in attendance, intuition gained after
   years of experience in making the Internet work.  More work is needed
   to validate the intuition and experience by way of scientific
   experimentation and analysis.  Unfortunately, it's not so easy to
   find a spare collection of global Internets upon which one might
   perform controlled experiments.

2. Conclusions and Action Items

   The participants came to a number of conclusions after the
   discussions referred to in sections 2.1-2.10.  These conclusions,
   presented in this document, provide summary statements and action
   items for the IETF community.

2.1. Scaling of Unicast Routing and Addressing

2.1.1. Unicast Routing - Conclusions

   The participants of the workshop came to the following conclusions

    1. Most of the current unicast routing stability problems can be
       fixed with improved implementation.




Deering, et al.              Informational                      [Page 3]

RFC 2902       Overview of the 1998 IAB Routing Workshop     August 2000


    2. Some long term systemic issues that may eventually overwhelm the
       unicast routing are:

        -  Flaps - which will only get worse unless work is undertaken
        -  Multi-homing

    3. We'd like more research into what's breaking; not just more data,
       but more analysis of the data

   The group reviewed the following potential solutions:

    -  Architected NAT (improving the existing Network Address
       Translation schemes to provide better scaling)
    -  IPv6 (deploying an IP version 6 infrastructure)
    -  MAP/Encap (map to aggregatable addresses and encapsulate the
       original packet)
    -  Do nothing
    -  Aggressive renumbering (try to continue to encourage renumbering
       to improve utilization of the IP version 4 address space)
    -  Metro addressing (use a geographical or metropolitan based
       addressing scheme)

2.1.2. Unicast Routing - Action Items

   We recommend that the IRTF Routing Research group should encourage
   more analysis of routing data, not just the collection of more data.

2.2. Levels of Addressing of Addressing and Routing

   Levels of hierarchy do not matter to the customers.  Address
   hierarchy must be distinguished from routing hierarchy.  The group
   examined whether the current Internet has enough levels of hierarchy
   in Internet addresses or routing infrastructure.  The group did not
   find that levels of hierarchy should be added to the Internet, at
   least for now.  Flat routing at the AS level seems to be workable; if
   this changes in the future, hierarchy would need to be revisited, and
   studied with due consideration to convergence time for routing
   algorithms and trust management.  There is no universal agreement
   that adding levels of hierarchy at this point in time provides a
   well-defined benefit.  Furthermore, two levels is difficult for many
   people, and any more than that is difficult both to build and to use.










Deering, et al.              Informational                      [Page 4]

RFC 2902       Overview of the 1998 IAB Routing Workshop     August 2000


2.3. Network Address Translation (NAT) devices

2.3.1. NAT devices - Conclusions

   Upon reviewing the NATs, the group

    1. Noted that NAT devices are fairly widely deployed
    2. Identified various problems with the use of NAT devices within
       the internet
    3. Discussed the interaction between NAT devices and applications
    4. Listed the following options regarding NAT devices:

        -  Eliminate NATs
        -  Fix NATs to interact better with the rest of the Internet
        -  Fix applications to interact better with NAT boxes
        -  Don't do certain things -- like IP Security (IPSec)

2.3.2. NAT devices - Action Items

   1. Forward our concerns, problems and suggestions to the appropriate
      working groups
   2. Note architectural work outside the NAT working group
   3. Suggest to the IAB that it continue to be concerned about the
      issues involving NATs

2.4. Multicast

2.4.1. Multicast - Conclusions

   Since the multicast model was created, many multicast applications
   have been tried over the Internet multicast routing fabric.  The
   group began to discuss the multicast model in terms of enabling
   multicast applications to run efficiently, and scale favorably with
   future growth.  Multicast applications place varying requirements on
   multicast routing.

   Multicast applications may have a variable:

    -  number of sources,
    -  number of receivers,
    -  amount of data,
    -  amount of data in a burst, and length of quiet periods
    -  number of groups utilized per application or per set of
       cooperating applications, and
    -  amount of time during which the group exists
    -  topological distance between members of the group.
    -  volatility of membership




Deering, et al.              Informational                      [Page 5]

RFC 2902       Overview of the 1998 IAB Routing Workshop     August 2000


   Multicast routing must provide the flexibility to support the varying
   requirements of different multicast applications.  The current
   multicast model establishes multicast routing paths upon reception of
   a data packet.  The discussion on the viability of the multicast
   model examined the viability of the model in terms of the uses of
   multicast routing by applications and the scalability to full
   Internet usage.  For example, providing for many groups of small
   conferences (a small number of widely-dispersed people) with global
   topological scope scales badly given the current multicast model.

   The group felt the existing multicast protocols and multicast should
   be evaluated in terms of the requirements listed above.  The group
   suggested that the evaluation should include the multicast protocols
   DVMRP [12], MOSPF [8], PIM [4], CBT [2], and Express [5], as well as