rfc2991.txt

RFC 的详细文档！

   prefix).  This means that today's multicast forwarder's always keep
   per-flow state, although for some multicast routing protocols, the
   "flow" may be fairly coarse (e.g., traffic from all sources to the
   same destination).  Since per-flow state is kept by the forwarder, it
   is recommended that the router always use HRW to select the next-hop.

   Routers using explicit-joining protocols such as PIM-SM [5] should
   thus use the multipath information when determining to which neighbor
   a join message should be sent.  For example, when multiple next-hops
   exist for a given Rendezvous Point (RP) toward which a (*,G) Join
   should be sent, it is recommended that HRW be used to select the
   next-hop to use for each group.

5.  Applicability

   The algorithms discussed above (except round-robin) all rely on some
   form of hash function.  Equal flow distribution is achieved when the
   hash function is uniformly distributed.  Since the commonly used hash
   functions only become uniformly distributed when the number of inputs
   is relatively large, these algorithms are more applicable to routers
   used to route many flows, than in, for example, a small business
   setting.





Thaler & Hopps               Informational                      [Page 5]

RFC 2991                    Multipath Issues               November 2000


6.  Redundant Parallel Links

   A related problem occurs when multiple parallel links are used
   between the same pair of routers.  A common solution is to bundle the
   two links together into a "super"-link when is then used for routing.
   For multicast forwarding, this results in the two links being reduced
   to a single next-hop (over the combined link) which can be used to
   prevent duplicates.  When a unicast or multicast packet is queued to
   the combined link, some method, such as those discussed earlier, is
   still required to determine the physical link on which to transmit
   the packet.  If the parallel links are identical, then most of the
   concerns discussed in this document are avoided with the combined
   link.  The exception is packet reordering, which can still occur with
   round-robin, adversely affecting TCP.

7.  Security Considerations

   This document discusses issues with various methods of choosing a
   next-hop from among multiple valid next-hops.  As such, it does not
   directly impact the security of the Internet infrastructure or its
   applications.

   One issue that is worth mentioning, however, is that when next-hop
   selection is predictable, an attacker can synthesize traffic that
   will all hash the same, making it possible to launch a denial-of-
   service attack that overloads a particular path.  Since a special
   case of this is when the same (single) next-hop is always selected,
   such an attack is easiest when multipath is not being used.
   Introducing multipath routing can make such an attack more difficult;
   the more unpredictable the hash is, the harder it becomes to conduct
   a denial-of-service attack against any single link.




















Thaler & Hopps               Informational                      [Page 6]

RFC 2991                    Multipath Issues               November 2000


8.  References

   [1]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [2]  Maufer, T., "Deploying IP Multicast in the Enterprise",
        Prentice-Hall, 1998.

   [3]  Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC
        2992, November 2000.

   [4]  Thaler, D., and C.V. Ravishankar, "Using Name-Based Mappings to
        Increase Hit Rates", IEEE/ACM Transactions on Networking,
        February 1998.

   [5]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
        Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
        "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
        Specification", RFC 2362, June 1998.

   [6]  Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
        RFC 2581, April 1999.

   [7]  Nichols, K., Blake, S., Baker, F. and D. Black., "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", RFC 2474, December 1998.


























Thaler & Hopps               Informational                      [Page 7]

RFC 2991                    Multipath Issues               November 2000


9.  Authors' Addresses

   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA  98052

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


   Christian E. Hopps
   NextHop Technologies, Inc.
   517 W. William Street
   Ann Arbor, MI 48103-4943
   U.S.A

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
































Thaler & Hopps               Informational                      [Page 8]

RFC 2991                    Multipath Issues               November 2000


10.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Thaler & Hopps               Informational                      [Page 9]