home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mboned-limit-rate-guide-00.txt < prev    next >
Text File  |  1997-02-19  |  7KB  |  174 lines
  1.  
  2.  
  3. INTERNET-DRAFT                                                D. Junkins
  4. draft-ietf-mboned-limit-rate-guide-00.txt                   NorthWestNet
  5. Category: Best Current Practice                         18 February 1997
  6. Expires 18 August 1997
  7.  
  8.  
  9.                 Guidelines for Rate Limits on the MBONE
  10.  
  11.  
  12. 1. Status of this Memo
  13.  
  14.    This document is an Internet-Draft.  Internet-Drafts are working
  15.    documents of the Internet Engineering Task Force (IETF), its areas,
  16.    and its working groups.  Note that other groups may also distribute
  17.    working documents as Internet-Drafts.
  18.  
  19.    Internet-Drafts are draft documents valid for a maximum of six months
  20.    and may be updated, replaced, or obsoleted by other documents at any
  21.    time.  It is inappropriate to use Internet-Drafts as reference
  22.    material or to cite them other than as ``work in progress.''
  23.  
  24.    To learn the current status of any Internet-Draft, please check the
  25.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  26.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  27.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  28.    ftp.isi.edu (US West Coast).
  29.  
  30.  
  31. 2. Abstract
  32.  
  33.    Much confusion and misunderstanding exists in the Internet community
  34.    on the use of rate limits on the Multicast Backbone (MBONE).  This
  35.    document dispels some of the misunderstandings of rate limits and
  36.    describes the best current practices for when to implement rate
  37.    limits on MBONE links.
  38.  
  39.    It is a product of the Multicast Deployment Working Group in the
  40.    Operational Requirements area of the Internet Engineering Task Force.
  41.    Submit comments to <mboned@ns.uoregon.edu> or the author.
  42.  
  43.  
  44. 3. History of DVMRP Tunnel Rate Limits
  45.  
  46.    The MBone (Multicast Backbone) of the Internet is composed of a DVMRP
  47.    backbone connected to regions that may be running other multicast
  48.    routing protocols.  These multicast islands are connected together by
  49.    DVMRP tunnels across the unicast Internet backbone.
  50.  
  51.    The original multicast router for the MBONE was mrouted.  Mrouted,
  52.    through version 3.8, has a rate limit of 512 kbps enabled by default
  53.    on each tunnel interface.  This rate limit was included in mrouted
  54.    because of concern that multicast traffic could consume all available
  55.    bandwidth on some links of the Internet.  Other multicast router
  56.  
  57.  
  58. Junkins                                                         [Page 1]
  59.  
  60. Expires 18 August 1997       INTERNET-DRAFT             18 February 1997
  61.  
  62.  
  63.    implementations include support for rate limits on interfaces but
  64.    they are not enabled by default.
  65.  
  66.    Several things have changed in the Internet and IP multicasting that
  67.    make the idea of a global rate limit for the MBONE no longer
  68.    necessary.  First, the size of provider's backbone circuits has
  69.    increased greatly.  It is no longer a valid concern that a single
  70.    multicast transmitter could send enough multicast traffic to
  71.    completely fill a national providers backbone circuit since those
  72.    circuits have moved from DS-1 (1.536 Mbps) to DS-3 (44.210 Mbps).
  73.  
  74.    Second, multicast pruning is now widely deployed across the MBONE and
  75.    is being mandated as a requirement for MBONE multicast routers
  76.    [PRUNING].  Pruning prevents multicast routers from forwarding
  77.    multicast traffic to neighbors that have no receivers for the
  78.    destination multicast group.  With the original implementation of
  79.    mrouted, pruning was not implemented so multicast traffic sent to the
  80.    MBONE was distributed across the entire backbone.
  81.  
  82.    Because of the original lack of pruning and the default rate limiting
  83.    of 512 kbps enabled on mrouted, many people believe that there is a
  84.    total capacity of 512 kbps for the aggregate traffic sent on the 
  85.    MBONE.  In fact, many people have used this as a reason not to
  86.    develop multicast applications.  With increased bandwidth in the
  87.    national service providers networks and with pruning multicast
  88.    routers deployed widely on the MBONE, neither of the previous
  89.    constraints on MBONE traffic are valid any longer.
  90.  
  91.  
  92. 4. Current Use of Rate Limits
  93.  
  94.    Backbone providers that are tunneling multicast traffic across their
  95.    networks are encouraged to raise the default rate limit on mrouted
  96.    boxes to a more useful limit.  It is essential to encourage the use
  97.    of multicast traffic as a more scalable alternative to unicast
  98.    streaming technologies.
  99.  
  100.    This is not to say that rate limits no longer are required anywhere
  101.    on the MBONE.  End-points on the MBONE may still require rate limits
  102.    their tunnels to prevent multicast users from consuming all available
  103.    bandwidth on the customer's access link.  End-points should determine
  104.    how much of their bandwidth they want to allow multicast traffic to
  105.    consume and should request that their tunnel provider only allow that
  106.    much traffic traffic on the tunnel.  Some multicast routers also
  107.    permit the configuration of an inbound rate limit to prevent
  108.    congestion within the router.
  109.  
  110.    Rate limits are also very useful on congested links due to the fact
  111.    that the current DVMRP implementation does not retransmit prunes.  If
  112.    the prune message is lost, the group will continue to be transmitted
  113.    across the tunnel.
  114.  
  115. Junkins                                                         [Page 2]
  116.  
  117. Expires 18 August 1997       INTERNET-DRAFT             18 February 1997
  118.  
  119.  
  120.    Backbone providers may also choose to set a rate limit on their
  121.    tunnels that is high enough not to impede normal multicast traffic
  122.    but low enough to protect against denial-of-service attacks.  The
  123.    potential for denial of service attacks on a multicast group are
  124.    similar to "flood pinging" against a unicast targe, except the
  125.    potential exists to hit more that one path through the network at the
  126.    same time. 
  127.  
  128.    In all applications of rate limits, it is important to remember that,
  129.    with pruning, these rate limits will only apply to multicast groups
  130.    that have receivers at the other end of the tunnel.  At no time does
  131.    a rate limit applied to a DVMRP tunnel imply a total aggregate
  132.    capacity of the MBONE.
  133.  
  134.  
  135. 5. Security Considerations
  136.  
  137.    The removal of rate limits altogether on backbone provider's MBONE
  138.    tunnels could possibly lead to denial-of-service attacks by sending
  139.    large amounts of traffic to a global multicast group such as the SDR
  140.    group.
  141.  
  142.  
  143. 6. References
  144.  
  145.    [PRUNING] J. Hawkinson, "Multicast pruning a necessity", Work in
  146.            progress (internet-draft).
  147.  
  148.  
  149. 7. Author's Address
  150.  
  151.    Doug Junkins
  152.    NorthWestNet
  153.    15400 30th Place SE, Suite 202
  154.    Bellevue, WA  98007
  155.  
  156.    phone: +1 206 649 7419
  157.    email: junkins@nwnet.net
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172. Junkins                                                         [Page 3]
  173.  
  174.