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-admin-ip-space-01.txt < prev    next >
Text File  |  1996-12-23  |  9KB  |  281 lines
  1.  
  2. INTERNET-DRAFT                                           David Meyer
  3. draft-ietf-mboned-admin-ip-space-01.txt         University of Oregon
  4. Category:Best Current Practice                         December 1996
  5.  
  6.  
  7.                   Administratively Scoped IP Multicast
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.    This document specifies an Internet Best Current Practice for the
  13.    Internet Community, and requests discussion and suggestions for
  14.    improvements.  Distribution of this memo is unlimited.
  15.  
  16. Internet Drafts
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at any
  25.    time.  It is inappropriate to use Internet-Drafts as reference
  26.    material or to cite them other than as ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  30.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  31.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  32.    ftp.isi.edu (US West Coast).
  33.  
  34. Abstract
  35.  
  36.    This document defines the "administratively scoped IP multicast
  37.    space" to be  the range 239.0.0.0 to 239.255.255.255 . In addition,
  38.    it describes a simple set of semantics for the implementation of
  39.    Administratively Scoped IP Multicast.
  40.  
  41.    This memo is a product of the MBONE Deployment Working Group (MBONED)
  42.    in the Operational Requirements area of the Internet Engineering Task
  43.    Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50. Expires May 1997                                                [Page 1]
  51.  
  52.  
  53.  
  54.  
  55.  
  56. INTERNET-DRAFT    Administratively Scoped IP Multicast     December 1996
  57.  
  58.  
  59. Acknowledgments
  60.  
  61.    Much of this memo is taken from "Administratively Scoped IP
  62.    Multicast", Van Jacobson and Steve Deering, presented at the 30th
  63.    IETF, Toronto, Canada, 25 July 1994. Mark Handley and Dave Thaler
  64.    also made insightful comments on the orignal draft.
  65.  
  66. Introduction
  67.  
  68.  
  69.    Most current IP multicast implementations achieve some level of scop-
  70.    ing by using the TTL field in the IP header. Typical MBONE (Multicast
  71.    Backbone) usage has been to engineer TTL thresholds that confine
  72.    traffic to some administratively defined topological region.  The
  73.    basic forwarding rule for interfaces with configured TTL thresholds
  74.    is that for a packet is not forwarded across the interface unless its
  75.    remaining TTL greater than the threshold.
  76.  
  77.    TTL scoping has been used to control the distribution of multicast
  78.    traffic with the objective of easing stress on scarce resources
  79.    (e.g., bandwidth), or to achieve some kind of improved privacy or
  80.    scaling properties.  In addition, the TTL is also used in its tradi-
  81.    tional role to limit datagram lifetime. Given these often conflicting
  82.    roles, TTL scoping has proven difficult to implement reliably, and
  83.    the resulting schemes have often been complex and difficult to under-
  84.    stand.
  85.  
  86.    On the other hand, by using administratively scoped IP multicast, one
  87.    can achieve locally scoped multicast with simple, clear semantics.
  88.    The key properties of any implementation of administratively scoped
  89.    IP multicast are that (i). packets addressed to administratively
  90.    scoped multicast addresses do not cross configured administrative
  91.    boundaries, and (ii). administratively scoped multicast addresses are
  92.    locally assigned, and hence are not required to be unique across
  93.    administrative boundaries. These properties are sufficient to imple-
  94.    ment administrative scoping.
  95.  
  96. Allocation of the Administratively Scoped IP Multicast Address Space
  97.  
  98.    IANA should allocate the  range 239.0.0.0 to 239.255.255.255 to be
  99.    the "Administratively Scoped IP Multicast" address space.
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107. Expires May 1997                                                [Page 2]
  108.  
  109.  
  110.  
  111.  
  112.  
  113. INTERNET-DRAFT    Administratively Scoped IP Multicast     December 1996
  114.  
  115.  
  116. Discussion
  117.  
  118.  
  119.    In order to support administratively scoped IP multicast, a router
  120.    should support the configuration of scoped IP multicast boundaries.
  121.    Such a router, called a boundary router, does not forward packets
  122.    matching its boundary definition in either direction across its
  123.    border (the bi-directional check prevents problems with multicaccess
  124.    networks).  In addition, a boundary router always prunes the boundary
  125.    for dense-mode groups, or doesn't accept joins for sparse-mode groups
  126.    [PIMSM] in the administratively scoped range.
  127.  
  128. Structure of the IPv4 Administratively Scoped Multicast Space
  129.  
  130.  
  131.    The structure of the IP version 4 administratively scoped multicast
  132.    space is loosely based on the IP Version 6 Multicast Addresses
  133.    [RFC1884] assignments, and is partitioned into the following scope
  134.    classes:
  135.  
  136.            unassigned                      239.0.0.0/10
  137.            unassigned                      239.64.0.0/10
  138.            organization-local scope        239.128.0.0/10
  139.            site-local scope                239.192.0.0/10
  140.  
  141.    The other two scope classes of interest, link-local scope and global
  142.    scope, already exist to some extent in IP version 4 multicast space.
  143.    In particular, the link-local scope is 224.0.0.0/24. The existing
  144.    global scope allocations are currently somewhat more granular, and
  145.    include
  146.  
  147.  
  148.            224.1.0.0-224.1.255.255         ST Multicast Groups
  149.            224.2.0.0-224.2.127.253         Multimedia Conference Calls
  150.            224.2.127.254                   SAPv1 Announcements
  151.            224.2.127.255                   SAPv0 Announcements (deprecated)
  152.            224.2.128.0-224.2.255.255       SAP Dynamic Assignments
  153.            224.252.0.0-224.255.255.255     DIS transient groups
  154.            232.0.0.0-232.255.255.255       VMTP transient groups
  155.  
  156.    See ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses
  157.    for current multicast address assignments.
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Expires May 1997                                                [Page 3]
  165.  
  166.  
  167.  
  168.  
  169.  
  170. INTERNET-DRAFT    Administratively Scoped IP Multicast     December 1996
  171.  
  172.  
  173. Topological Requirements for Administrative Boundaries
  174.  
  175.  
  176.    An administratively scoped IP multicast region is defined to be a
  177.    topological region in which there are one or more boundary routers
  178.    with common boundary definitions. Such a router is said to be a boun-
  179.    dary for scoped addresses in the range defined in its configuration.
  180.  
  181.    Network administrators may configure a scope region whenever local
  182.    multicast scope is required. In addition, an administrator may con-
  183.    figure overlapping scope regions (networks can be in multiple scope
  184.    regions) where convenient, with the only limitations being that a
  185.    scope region must be connected (there must be a path between any two
  186.    nodes within a scope region that doesn't leave that region), and con-
  187.    vex (i.e., no path between any two points in the region can cross a
  188.    region boundary).
  189.  
  190. Example: DVMRP
  191.  
  192.  
  193.    DVMRP [DVMRP] implementations could be extended to support a boundary
  194.    attribute in the interface configuration [ASMA]. The boundary attri-
  195.    bute that includes a prefix and mask, and has the semantics that
  196.    packets matching the prefix and mask do not not pass the boundary. As
  197.    mentioned above, the implementation would also prune the boundary.
  198.  
  199. Security Considerations
  200.  
  201.    While security considerations are not explicitly discussed in this
  202.    memo, it is important to note that a boundary router as described
  203.    here should not be considered to provide any kind of firewall func-
  204.    tionality.
  205.  
  206. References
  207.  
  208.  
  209.       [ASMA]    V. Jacobson,  S. Deering, "Administratively Scoped IP
  210.                 Multicast", , presented at the 30th IETF, Toronto,
  211.                 Canada, 25 July 1994.
  212.  
  213.       [DVMRP]   T. Pusateri, "Distance Vector Multicast Routing
  214.                 Protocol", draft-ietf-idmr-dvmrp-v3-03, September,
  215.                 1996.
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Expires May 1997                                                [Page 4]
  222.  
  223.  
  224.  
  225.  
  226.  
  227. INTERNET-DRAFT    Administratively Scoped IP Multicast     December 1996
  228.  
  229.  
  230.       [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
  231.                 Architecture", RFC1884, December 1995.
  232.  
  233.       [PIMSM]   Estrin, D, et. al., "Protocol Independent Multicast
  234.                 Sparse Mode (PIM-SM): Protocol Specification",
  235.                 draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996.
  236.  
  237.  
  238. Author's Address
  239.  
  240.    David Meyer
  241.    Advanced Network Technology Center
  242.    University of Oregon
  243.    1225 Kincaid St.
  244.    Eugene, OR 97403
  245.  
  246.    phone:  +1 541.346.1747
  247.    email:  meyer@antc.uoregon.edu
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Expires May 1997                                                [Page 5]
  279.  
  280.  
  281.