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-imrp-some-issues-00.txt < prev    next >
Text File  |  1997-02-12  |  20KB  |  538 lines
  1.  
  2.  
  3. MBONE Deployment Working Group                               David Meyer
  4. Internet Draft                                      University of Oregon
  5.  
  6.  
  7.  
  8. Expiration Date: August 1997                               February 1997
  9.  
  10.       Some Issues for an Inter-domain Multicast Routing Protocol
  11.  
  12.  
  13.                draft-ietf-mboned-imrp-some-issues-00.txt
  14.  
  15.  
  16. 1. Status Of This Memo
  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.  
  35. 2. Introduction
  36.  
  37.    The IETF's Inter-Domain Multicast Routing (IDMR) working group has
  38.    produced several multicast routing protocols, including Core Based
  39.    Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In
  40.    addition, the IDMR WG has formalized the specification of the
  41.    Distance Vector Multicast Routing Protocol [DVMRP]. Various
  42.    specifications for protocol inter-operation have also been produced
  43.    (see, for example, [THALER96] and [PIMMBR]). However, none of these
  44.    protocols seems ideally suited to the inter-domain routing case; that
  45.    is, while these protocols are appropriate for the intra-domain
  46.    routing environment, they break down in various ways when applied in
  47.    to the multi-provider inter-domain case.
  48.  
  49.    This document considers some of the scaling, stability and policy
  50.    issues that are of primary importance in a inter-domain, multi-
  51.  
  52.  
  53.  
  54. David Meyer                                             FORMFEED[Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  61.  
  62.  
  63.    provider multicast environment.
  64.  
  65.  
  66. 3. Forwarding State Requirements
  67.  
  68.    Any scalable protocol will have to minimize forwarding state
  69.    requirements. In the case of dense mode protocols [DVMRP][PIM-DM],
  70.    routers may carry forwarding or prune state for every (S,G) pair in
  71.    the Internet. This is true even for routers that may not be on any
  72.    delivery tree. It seems likely that as multicast deployment scales to
  73.    the size of the Internet, maintenance of (S,G) state will become
  74.    intractable.
  75.  
  76.    Shared tree protocols, on the other hand, have the advantage of
  77.    maintaining a single (*,G) entry for a group's receivers (thus
  78.    relaxing the requirement of maintaining (S,G) for the entire
  79.    Internet). However, this is not without its own disadvantages; see
  80.    the section on "Third-party Resource Dependencies" below.
  81.  
  82.  
  83. 4. Forwarding State Distribution
  84.  
  85.    The objective of a multicast forwarding state distribution mechanism
  86.    is to ensure that multicast traffic is efficiently distributed to
  87.    those parts of the topology where there are receivers. Dense and
  88.    sparse mode protocols will accept differing overheads based on design
  89.    tradeoffs. In the dense mode case, the data-driven nature state
  90.    distribution has disadvantage that data is periodically distributed
  91.    to branches of the distribution tree which don't have receivers
  92.    ("Flood and Prune" behavior). It seems unlikely that this mechanism
  93.    will be scalable to Internet-wide case.
  94.  
  95.    On the other hand, sparse mode protocols use receiver-initiated,
  96.    explicit joins to establish a forwarding path along a shared
  97.    distribution tree. While the on-demand nature of sparse mode
  98.    protocols have favorable properties with respect to distribution of
  99.    forwarding state, it also has the possible disadvantage of creating
  100.    dependencies on shared resources (again, see the section on "Third-
  101.    Party Resource Dependencies" below).
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. David Meyer                                             FORMFEED[Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  121.  
  122.  
  123. 5. Forwarding State Maintenance
  124.  
  125.    The many current multicast protocols attempt to accurately and
  126.    rapidly maintain distribution trees that are as close to optimal as
  127.    possible. This means that the shape of a distribution tree can be
  128.    rapidly changing. In addition, since distribution trees can be
  129.    global, they can be subject to high frequency control traffic.
  130.  
  131.    In contrast, the focus in the inter-domain unicast routing
  132.    environment is on minimizing routing traffic (see, for example,
  133.    [VILLAM95]), and controlling stability [LABOV97]. The implication is
  134.    that protocol overhead and stability must be controlled if we hope
  135.    multicast to scale to Internet sizes. Thus it seems likely that
  136.    Inter-domain multicast routing protocols will have to do less
  137.    forwarding state maintenance, and hence be less aggressive in
  138.    reshaping distribution trees. Note that this reshaping is related to
  139.    what has been termed "routing flux" (again, see [LABOV97]), since the
  140.    routing traffic does not directly affect path selection. Rather, the
  141.    primary effect is to require significant processing resources in a
  142.    border router. Finally, note that unlike the unicast case, we do not
  143.    have good data characterizing this effect for multicast routers.
  144.  
  145.  
  146. 5.1. Bursty Source Problem
  147.  
  148.    The "Bursty Source Problem" can be described as those cases in which
  149.    sources loose data because there is very long join latency and/or
  150.    initial send latency. The current set of multicast routing protocols
  151.    attempt, where possible, to avoid this problem (i.e., maximize
  152.    response to bursty sources). Further, the combination of long
  153.    latencies with flooding joins can become a problem where a large
  154.    number of groups are joined and left at high frequency.
  155.  
  156.  
  157. 6. Mixed Control
  158.  
  159.    Mixing control of topology discovery and distribution tree
  160.    construction can lead to efficiencies but also imposes various
  161.    constraints on topology discovery mechanisms. For example, DVMRP
  162.    [DVMRP] uses topology discovery facilities ("split horizon with
  163.    poison reverse")  to eliminate duplicate packets on a LAN, and to
  164.    detect non-leaf networks (an upstream router uses this information
  165.    when pruning downstream interfaces).
  166.  
  167.    On the other hand, PIM [PIM-DM] does not use any topology discovery
  168.    algorithm features when building delivery trees. However, this
  169.    independence is not without cost: PIM-DM accepts some duplicates on
  170.    multi-access LANs as a tradeoff for reduced protocol complexity.
  171.  
  172.  
  173.  
  174. David Meyer                                             FORMFEED[Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  181.  
  182.  
  183. 7. Neighbor Model
  184.  
  185.    The current inter-domain unicast routing model has some key
  186.    differences with proposed inter-domain multicast routing models with
  187.    respect to neighbor (peer) discovery. In particular, the current set
  188.    of multicast protocols depend heavily on dynamic neighbor discovery.
  189.    This is analogous to the situation with intra-domain unicast routing,
  190.    but is unlike current inter-domain unicast routing, where neighbors
  191.    are typically statically configured.
  192.  
  193.    The static neighbor configuration model has several benefits for
  194.    inter-domain routing. First, neighbors are predefined, which is a
  195.    policy requirement in most cases. In addition, the set of peers in
  196.    the inter-domain unicast routing system defines the set of possible
  197.    inter-domain topologies (with the current active topology represented
  198.    by the collection of AS paths).
  199.  
  200.    Another important difference relates to how inter-domain regions are
  201.    modeled. For purposes of this document, consider an inter-domain
  202.    region defined to be a part of an arbitrary topology in which a
  203.    higher level (inter-domain) routing protocol is used to calculate
  204.    paths between regions. In addition, each pair of adjacent regions is
  205.    connected by one or more multicast border routers. Current IDMR
  206.    proposals (e.g., [HDVMRP], [THALER96]) model an inter-domain region
  207.    as a routing domain. That is, border routers internetwork between one
  208.    or more intra-domain regions and an inter-domain region (again,
  209.    possibly more than one). In this model, inter-networking occurs
  210.    "inside" router. However, the inter-provider unicast routing model in
  211.    use today is quite different.  In particular, the  "peering" between
  212.    two providers occurs in neither of the provider's routing domains,
  213.    nor does it occur in some shared "inter-domain" routing domain. The
  214.    separation provides the administrative and policy control that is
  215.    required in today's Internet.
  216.  
  217.  
  218.  
  219. 8. Unicast Topology Dependency
  220.  
  221.    Ideally, unicast and multicast topologies are congruent in the
  222.    Internet. However, since it is frequently difficult to field new
  223.    facilities (such as IP multicast) in the "core" the Internet
  224.    infrastructure, there will continue to be many cases in which unicast
  225.    and multicast topologies are not congruent (either because a region
  226.    is not multicast capable at all, or because the region is not
  227.    natively forwarding multicast traffic). Thus, it is unlikely that the
  228.    entire IPv4 Internet will be able to carry native multicast traffic
  229.    in the foreseeable future. In addition, various policy requirements
  230.    will in certain cases cause to topologies to further diverge. The
  231.  
  232.  
  233.  
  234. David Meyer                                             FORMFEED[Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  241.  
  242.  
  243.    implication is that a successful IDMR will need a topology discover
  244.    mechanism, or have other mechanisms for dealing with those cases in
  245.    which unicast and multicast topologies are not congruent.
  246.  
  247.  
  248.  
  249. 9. Third-Party Resource Dependencies
  250.  
  251.    Shared tree protocols require one or more globally shared Rendezvous
  252.    Points (RPs) [PIM-SM] or Cores [CBT]. The RP or Core effectively
  253.    serves as the root of a group specific shared tree. Data is sent to
  254.    the RP/Core for delivery on the shared tree. This means that some
  255.    groups may have an RP (or core) that is fielded by a third party. For
  256.    example, if providers A, B and C share a PIM-SM inter-domain region,
  257.    then there will exist an RP that is mapped to C's multicast border
  258.    router. In this case, C is hosting a kind of "transit RP" for A and B
  259.    (A and B register to C to communicate between themselves, even if C
  260.    has no receivers for the group(s) served by the RP.
  261.  
  262.  
  263. 10. Traffic Concentration Problem
  264.  
  265.    Traffic can be "concentrated" on a shared tree. This can lead to
  266.    increased latency or packet loss. However, this is less of a problem
  267.    in the shared-media exchange point environment.
  268.  
  269.  
  270. 11. Distant RP/Core Problem
  271.  
  272.    In the shared tree model, if the RP or Core is distant
  273.    (topologically), then joins will travel to the distant RP/Core, even
  274.    if the data is being delivered locally. Note that this problem is
  275.    exacerbated by the global nature of the RP/Core space; if a router is
  276.    registering to a RP/Core that is not in the local domain (say,
  277.    fielded by the site's direct provider), then the routing domain is
  278.    flat.
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294. David Meyer                                             FORMFEED[Page 5]
  295.  
  296.  
  297.  
  298.  
  299.  
  300. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  301.  
  302.  
  303. 12. Multicast Internal Gateway Protocol (MIGP) Independence
  304.  
  305.    A shared tree, explicit join protocol inter-domain routing protocol
  306.    may require modification to a leaf domain's internal multicast
  307.    routing mechanism. The problem arises when a domain is running a
  308.    "flood and prune" protocol such as DVMRP or PIM-DM internally while
  309.    participating in a shared tree inter-domain protocol. In this case,
  310.    those areas of the (internal) topology where there are no sources
  311.    will not receive inter-domain traffic. It has been suggested that
  312.    these protocols be modified to use Domain Wide Reports [HDVMRP] to
  313.    communication domain-wide group membership to a domain's border
  314.    routers.
  315.  
  316.  
  317. 13. Encapsulations
  318.  
  319.    An IDMRP should minimize encapsulations where ever possible. PIM-SM
  320.    encapsulates packets sent to the shared tree in PIM Register messages
  321.    (data can be delivered natively if the last hop router or the RP
  322.    switches to the shortest path tree).  HDVMRP requires every inter-
  323.    domain packet to be rewritten with an additional level of
  324.    encapsulation for inter-domain forwarding. Further, the number of
  325.    encapsulations/decapsulations for paths that traverse N
  326.    administrative domains is O(N); each border border router "registers"
  327.    to a group specific RP, which then decapsulates the packet for
  328.    distribution on the shared tree.
  329.  
  330.  
  331.  
  332. 14. Policy Provisions
  333.  
  334.    Current inter-domain unicast routing protocols have a rich and well
  335.    developed policy model.  In contrast, multicast routing protocols
  336.    have little or no provision for implementing routing policy
  337.    (administrative scoping is one major exception).  A concrete example
  338.    of this need is the various problems with inadvertent injection of
  339.    unicast routing tables into the MBONE, coupled with our inability to
  340.    propagate the resultant large DVMRP routing tables, point out the
  341.    need for such policy oriented controls.
  342.  
  343.    A simple example illustrates why a successful inter-domain multicast
  344.    routing protocol will need to have a well developed policy model:
  345.    Consider three providers, A, B, and C, that have connections to a
  346.    shared-media exchange point.  Assume that connectivity is non-
  347.    transitive due to some policy (the common case, since bi-lateral
  348.    agreements are a very common form of peering agreement).  That is, A
  349.    and B are peers, B and C are peers, but A and C are not peers. Now,
  350.    consider a source prefix P, where P belongs to a customer of A (i.e.,
  351.  
  352.  
  353.  
  354. David Meyer                                             FORMFEED[Page 6]
  355.  
  356.  
  357.  
  358.  
  359.  
  360. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  361.  
  362.  
  363.    P is advertised by A).  Now, multicast packets forwarded by A's
  364.    border router will be correctly accepted by B, since B sees the RPF
  365.    interface for P to be the shared-media of the exchange.  Likewise,
  366.    C's border router will reject the packets forwarded by A's border
  367.    router because, by definition, C does not have A's routes through its
  368.    interface on the exchange (so packets sourced "inside" A fail the RPF
  369.    check in C's border router).
  370.  
  371.    In the example above, RPF is a powerful enough mechanism to inform C
  372.    that it should not accept packets sourced in P from A over the
  373.    exchange.  However, consider the common case in which P is multi-
  374.    homed to both A and B.  C now sees a route for P from B though its
  375.    interface on the exchange.  Without some form of multi-provider
  376.    cooperation and/or packet filtering, C could accept multicast packets
  377.    from A across the exchange, even though A and C don't peer.  Clearly,
  378.    this is an unintended consequence.  In addition, note that RPF itself
  379.    is essentially a packet filtering technology, and as such has
  380.    qualitatively different resource requirements than the route filters
  381.    that are commonly deployed in border routers.
  382.  
  383.  
  384. 14.1. Today's MBONE
  385.  
  386.    Another way to view the policy issues described above is to consider
  387.    the perspective of unicast reachability. Today's MBONE is comprised
  388.    of a single flat AS. Further, this AS running a simple distance
  389.    vector topology discovery protocol. This arrangement is unlikely to
  390.    scale gracefully or provide the same rich policy control that we find
  391.    in the unicast Internet. There are additional problems with a flat AS
  392.    model: the flat AS model fits neither the operational or
  393.    organizational models commonly found in Internet today.
  394.  
  395.  
  396. 15. Equal Cost Multipath
  397.  
  398.    A common way to incrementally scale available bandwidth is to provide
  399.    parallel equal cost paths. It would be an advantage if a multicast
  400.    routing protocol could support this. However, this would seem
  401.    difficult to achieve when using Reverse Path Forwarding, so it is
  402.    unclear whether this goal is achievable.
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414. David Meyer                                             FORMFEED[Page 7]
  415.  
  416.  
  417.  
  418.  
  419.  
  420. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  421.  
  422.  
  423. 16. Conclusion
  424.  
  425.    Deployment of a general purpose IP multicast infrastructure for the
  426.    Internet has been slowed by various factors. One of the primary
  427.    reasons, however, is the lack of a true inter-domain Multicast
  428.    Routing Protocol.  Several proposals have been advanced to solve this
  429.    problem, including PIM-SM [PIM-SM], DVMRP [PIMMBR], and Hierarchical
  430.    DVMRP [HDVMRP]. However, the concerns outlined above have prevented
  431.    any of these protocols from being adopted as the standard inter-
  432.    domain multicast routing protocol. Finally, it is worth noting that
  433.    DVMRP, since it is the common denominator among router vendor
  434.    offerings, is currently the de-facto inter-domain routing protocol.
  435.  
  436.  
  437. 17. Security Considerations
  438.  
  439.    Security considerations are not discussed in this memo.
  440.  
  441.  
  442. 18. References
  443.  
  444.    [CBT]      A. Ballardie, et. al., "Core Based Trees (CBT)
  445.               Multicast -- Protocol Specification --",
  446.               draft-ietf-idmr-cbt-spec-06.txt, September, 1996.
  447.  
  448.    [DVMRP]    T. Pusateri, "Distance Vector Multicast Routing
  449.               Protocol", draft-ietf-idmr-dvmrp-v3-03, September,
  450.               1996.
  451.  
  452.    [HDVMRP]   Ajit S.. Thyagarajan and Steve Deering, "
  453.               Hierarchical Distance-Vector Multicast Routing for
  454.               the MBone", In Proceedings of the ACM SIGCOMM, pages
  455.               60-66, October, 1995.
  456.  
  457.    [LABOV97]  Labovitz, Craig, et. al., "Internet Routing
  458.               Instability", Submitted to SIGCOMM97.
  459.  
  460.    [PIMARCH]  Estrin, D, et. al., "Protocol Independent Multicast
  461.               Sparse Mode (PIM-SM): Motivation and Architecture",
  462.               draft-ietf-idmr-pim-arch-04.ps , October, 1996.
  463.  
  464.    [PIM-DM]   Estrin, D, et. al., "Protocol Independent Multicast
  465.  
  466.               Dense Mode (PIM-DM): Protocol Specification",
  467.               draft-ietf-idmr-PIM-DM-spec-04.ps, September, 1996.
  468.  
  469.    [PIMMBR]   Estrin, D, et. al., "PIM Multicast Border Router
  470.               (PMBR) specification for connecting PIM-SM domains
  471.               to a DVMRP Backbone", draft-ietf-idmr-PIMBR-spec-01.ps,
  472.  
  473.  
  474.  
  475. David Meyer                                             FORMFEED[Page 8]
  476.  
  477.  
  478.  
  479.  
  480.  
  481. Internet Draft draft-ietf-mboned-imrp-some-issues-00.txt   February 1997
  482.  
  483.  
  484.               September, 1996.
  485.  
  486.    [PIM-SM]   Estrin, D, et. al., "Protocol Independent Multicast
  487.               Sparse Mode (PIM-SM): Protocol Specification",
  488.               draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996.
  489.  
  490.    [THALER96] D. Thaler, "Interoperability Rules for Multicast
  491.               Routing Protocols", draft-thaler-interop-00.ps,
  492.               November, 1996.
  493.  
  494.    [VILLAM95] C Villamizar, Ravi Chandra, and Ramesh Govindan,
  495.               "Controlling BGP/IDRP Routing Overhead",
  496.               draft-ietf-idr-rout-dampen-00.ps, July, 1995.
  497.  
  498.  
  499.  
  500.  
  501. 19. Acknowledgments
  502.  
  503.    Dino Farinacci and Dave Thaler provided several insightful comments
  504.    on earlier drafts of this document.
  505.  
  506.  
  507.  
  508. 20. Author Information
  509.  
  510.  
  511.    David Meyer
  512.    University of Oregon
  513.    1225 Kincaid St.
  514.    Eugene, OR 97403
  515.    Phone: (541) 346-1747
  516.    e-mail: meyer@antc.uoregon.edu
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535. David Meyer                                             FORMFEED[Page 9]
  536.  
  537.  
  538.