rfc2902.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

   the following mechanisms used by multicast applications:

    1. Registering with the core or the RP (Rendezvous Point),
    2. Having the ID of the group include the core, and having joins
       specify the core
    3. Having the ID of the group include the core, and having joins
       and data specify both
    4. Sending data via unicast to all members, and
    5. Sending data via unicast transport to the RP.

   The group acknowledged that the current multicast model does not
   scale well for all scenarios that applications use.

   The group noted that reliable multicast is surprisingly orthogonal to
   the issues about the scaling of the multicast model to all possible
   applications.

2.4.2. Multicast - Action Items

   Encourage evaluation and written reports on these multicast
   protocols, and mechanisms for different types of protocols.

   Notify the IRTF Routing Research Group of the need to charter
   activity in this area.

2.5. Routing Stability

2.5.1. Routing Stability - Conclusions

   Damping the effects of route updates enhances stability, but possibly
   at the cost of reachability for some prefixes.  A prefix can be
   damped and reachable via another path, so that for such prefixes the
   effects of damping are less serious than for other prefixes.  The
   performance of various algorithms for enhancing stability should be



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


   measured by recording whether the affected route prefixes are
   reachable or not reachable.  Using current damping approaches,
   approximately 1% of the prefixes are affected at any one point in
   time.  We should try to find out how many prefixes are unreachable
   because of damping.

2.5.2. Routing Stability - Action Items

   The conclusion is that this effort merits continued investigation.

   The IRTF Routing Research Group should measure how stable things are,
   and if stability is an issue, to study methods of making them more
   stable.

2.6. ToS/CoS/QoS

   The group noted that the terms Type of Service (ToS), Class of
   Service (CoS), and Quality of Service (QoS) are imprecise as
   currently used.  The discussion started by defining the terminology
   as follows:

   ToS:  hop by hop routing based on destination plus ToS bits [9]
   CoS:  classes of service based on service contracts.  These classes
         of service are enabled by a variety of mechanisms which include
         queueing, and multiple physical or link level paths.
   QoS:  managing routes that meet certain quality of service constraints,
         and involving the following steps:

          *  routing the resource requests
          *  setting up a path that satisfies the constraints
          *  routing the data

   There is no smooth dividing line between between ToS and QoS. ToS is
   relative.  QoS is absolute.  The group discussed whether there is a
   demand for ToS, CoS and QoS. Differentiated-services [3] as discussed
   in the IETF is ToS++.

   The group also discussed a more general concept of "Constraint Based
   Routing" which was defined as traffic engineering on large aggregated
   flows.  Constraint based routing allows the providers to better
   utilize the bandwidth in their network to handle traffic requests
   from users.  Besides enabling policy management techniques,
   constraint based routing allows providers to route traffic based on
   the characteristics of the traffic flows.







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


2.6.1. ToS/CoS/QoS - Action Items

   We recommend that IETF should look into the issue of Constraint Based
   Routing.

2.7. Routing Protocol Security

2.7.1. Routing Security - Conclusions

   After a lengthy discussion of the various problems of network
   security, the group notes that:

    1. Routers need intrinsic system security as good as or better than
       any host computer.
    2. Improving router security will not solve all problems.
    3. Console access to the router can do everything.
    4. One compromised router can create disaster.
    5. ISPs and vendors should consider taking some control traffic out
       of band, due to lack of wire speed authentication.
    6. We discussed other issues that will be passed on to the
       appropriate people involved with network security.
    7. Identified areas of work to improve things (e.g., wire speed
       authentication).

2.7.2. Routing Security - Action Items

   The IETF should encourage work on "wire speed" authentication, pair-
   wise authentication of routers in routing protocols, and Byzantine
   robustness [6] in routing protocols.

2.8. Routing Policy

2.8.1. Routing Policy - Conclusions

   During our discussion on routing policy the group reviewed what could
   be done with BGP. The group noted that:

    1. Some routing policies requested by ISPs or NSPs are not solvable
       with BGP. Some of these "unsolvable" routing policies can be put
       into effect using tunnels and static configuration.
    2. BGP is only a mechanism for announcing reachability
    3. BGP routing controls traffic direction without regard to traffic
       volume.
    4. BGP policy management is too delicate, too easy to mess up, and
       fragile.






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


    5. Router Configuration Language is very complex and error-prone
    6. We can't count on symmetric routing, so ISPs/NSPs/Enterprise nets
       should deal with it.

   The group concluded the Internet needed a better routing policy
   specification language.

2.8.2. Routing Policy - Action Item

   Pass the concerns about the Routing Policy Syntax Language (RPSL) [1]
   to chairs of the Routing Policy Syntax (RPS) working group [11].

2.9. Network to Host Flow of Information

2.9.1. Host Information - Conclusions

   Publishing information about traffic statistics along backbone routes
   could improve the way Internet services replicate data for retrieval
   from various sites.  This replication could be especially important
   for the retrieval of information off the web.  Currently, web pages
   refer people to caches local to their sites; for instance, a European
   site might be used for United Kingdom customers and a North American
   site for North American customers.  Proponents of web caches want to
   auto-configure the locations of web caches so a user's web browser
   can automatically discover the local cache.  Other applications share
   this need for finding the best cache for a particular service.

2.9.2. Host Information - Action Items

   The group recommends a BOF be held on Measuring Path Characteristics.
   Measurement of path characteristics should include:

    -  format for exchange of measurement data
    -  mechanisms for distribution of measurement data

   IPPM working group [7] is dealing with issues within the measurement
   problem space.

2.10. Shorter Topics

2.10.1. Multi-strand Trunking

   PPP did multi-link in a way that required too much computation and
   could not be used for faster links.  Internet technology should treat
   multiple parallel trunks as 1 link at the IP layer, but with multi-
   dimensional metrics.





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


   Multi-strand Trunking - Action Items

    There is design and development work at layer two which should be
    done to support the multiple parallel trunks.  This layer two work
    is outside the scope of the IETF. Layer three routing should
    support richer metrics in OSPF.

2.10.2. Routing Diagnostic and Development Tools

2.10.2.1. Routing Diagnostics - Conclusions

   1. It would be nice to have an Authoritative Database listing those
      prefixes permitted from each AS. The authoritative data base was
      attempted before without success, but the group felt it might be
      useful to try again.
   2. SNMP version 3 should be deployed in order to make use of its
      improved authentication, scope and rate limiting
   3. Remotely-controlled traffic monitors should be used to measure
      traffic
   4. Better tools are needed for preventative problem detection

2.10.2.2. Routing Diagnostics - Action Items

   1. Encouraged an authoritative database within the Internet
   2. Notify SNMP version 3 working groups regarding needs for
      authentication, scope, and rate limiting.
   3. Encourage funding of better tools for remotely controlled traffic
      sources and pro-active problem detection.

2.10.3. Anycast

2.10.3.1. Anycast - Conclusions

   1. We need to describe the advantages and disadvantages of anycast.
   2. Local-scoped well-known anycast addresses will be useful to
      applications.

2.10.3.2. Anycast - Action Items

   A BOF should be held to plan work on anycast.

   If a working group forms, a paper on the advantages and disadvantages
   of anycast should be included as part of the charter.








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


2.10.4. Load Sensitive IGP routing for Best Effort Traffic

2.10.4.1. Load Sensitive IGP - Conclusions

   While load sensitive routing is interesting in some ways, it cannot
   be considered until certain problems are worked out.  Currently,
   constraint based routing is assigning administrative metrics to allow
   routing to adapt to different traffic patterns.  Load sensitive
   routing may increase oscillation and instability of routes.  This
   instability of routes, sometimes called churn, may affect the ability
   of the routing infrastructure to scale.

   Load sensitive routing would allow IGPs to better utilize links.
   Past and current efforts in load sensitive routing include:  QoS OSPF
   [10], Q-OSPF [10], and load sensitive routers developed by BBN.

2.10.4.2. Load Sensitive IGP - Action items

   The IRTF Routing Research group chair and Routing Area Director
   should discuss this subject and determine what techniques from Load
   Sensitive IGP routing are ready for IETF, and what requires
   additional research.

2.10.5. Geographical Addresses and Renumbering

   This topic was discussed, but without any conclusions or action
   items.

3. Summary of Action items

3.1. Action Items for the IAB

   1. The IAB should be concerned about the issues involving NATs
   2. Authoritative Database (for addresses within domains) should be