Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mboned / mboned-minutes-97apr.txt < prev next >

Wrap

Text File | 1997-05-29 | 19KB | 518 lines

Editor's Note: These minutes have not been edited. MBONED WG Meeting April 7, 1997 Memphis, TN David Meyer/University of Oregon, Chair Reported by Matt Crawford and David Meyer -------------------------------------------------------------------- Agenda -------------------------------------------------------------------- I. Monday, April 7 1300-1500 (i). Introduction, Agenda Bashing and Status (ii). Status of Pruning/Pruning Draft (iii). Administratively Scoped Multicast (iv). Using TTLs with Admin Scoped Addresses (v). Using DHCP to allocate multicast addresses (vi). Issues for an Inter-domain Multicast Routing Protocol (vii). Current IDMR Inter-domain Routing Proposals II. Monday, April 7 1930-2200 (viii). M-BGP Proposal Overview (ix). Multicast Diagnostic Tools (x). Intro to Multicast Routing (xi). Rate Limiting Draft -------------------------------------------------------------------- (i). Introduction, Agenda Bashing, and Status -------------------------------------------------------------------- David Meyer convened the meeting, giving a status report of progress made by the MBONED WG. Meyer noted that there was a MBONED web page at: http://www.antc.uoregon.edu/MBONED/ and a mail list that one can subscribe to: majordomo@ns.uoregon.edu.edu subscribe mboned He then asked for additions and changes to the agenda. -------------------------------------------------------------------- (ii). Progress on the Pruning Draft -------------------------------------------------------------------- John Hawkinson gave an update on the state of the pruning draft. The purpose was to be a BCP-to-be; things got politically complicated. IESG wrote a lot of comments but they never got to the author. That was fixed, then the ball was dropped. New draft expected in about two weeks. -------------------------------------------------------------------- (iii). Update on the admin scoping draft -------------------------------------------------------------------- Dave Meyer reported that the IANA has allocated the administrative scope. The draft has needs a minor update to the reserved ranges. A new draft will be posted soon. -------------------------------------------------------------------- (iv). Using TTLs with admin. scoped addresses -------------------------------------------------------------------- Ross Finlayson gave an overview of his idea for using using ttls with admin. scoped addresses. The problem: pruning doesn't happen if TTL expires inside the MBONE, because the router doesn't know that a higher-TTL packet wont arrive later. The one-line answer -- make sure the TTL is high enough to reach admin. scope boundaries. If there were no flood-and-prune protocols, this wouldn't be an issue. What TTL should an app. use (when, e.g., sdr doesn't tell it)? Easy answer: always 255 -- OK on a well-managed intranet. But it's dangerous for the global internet -- there's no guarantee scopes are universally set up correctly. Border routers will get many flood-and-prune hits. Proposal -- each admin scope range has an effective TTL large enough to reach all intended members. Defined along with the range -- by IANA or dynamically? Apps should always use exactly this TTL. (But lower TTL allowed for expanding-ring search.) Implications for mrouters No effect on admin scope implementation mrouters may allow configuration in terms of TTL thresholds alone. completely optional feature packets to non-admin-scoped address check against TTL thresh. as usual (but still no pruning). Sysadmins may find TTL-threshold-only configuration simpler. Lazy sysadmins get an easy migration path to admin. scoping. admin scope boundaries would come automatically with some s/w update. Key Issues App developers need guidance about what TTLs to use w/ admin scoped addrs, even if the answer is always 255. What effective TTLs are appropriate for the ranges already proposed? (E.g., 15 for site local 239.192/10?) Q: Van: TTL is used for too many things loop suppression expanding ring search; admin boundaries The final recommendation was to abolish the use of TTL as a boundary mechanism. No action taken on this draft. -------------------------------------------------------------------- (v). (v). Using DHCP to allocate multicast addresses -------------------------------------------------------------------- Baiju Patel discussed his draft using DHCP for multicast address allocation. Motivation: Coordinated address allocation Avoid collision Support admin. scoped addresses Common solution for all applications Problem: 1. mechanism for allocating addresses 2. allocation policy 3. usage policy Address #1 now, defer 2 & 3. Current art: Application specific guess (SDR) a gatekeeper manages a set of addresses Or individual solutions hard to manage! Parameters which need to be associated with a multicast address Scope Classes of scopes: IANA defined or Locally administered Examples: Intel/Jones Farm, Intel/Oregon, Intel,USA, ... Implementation of scope: by TTL or router configuration -- not part of this proposal. Start time Lease time TTL? You should be given an upper bound when you get the right to use an address. Tried to leverage what exists, where possible ... DHCP -- used for two purposes Allocation of IP addresses Distribution of host configuration parameters (DNS server, NNTP server, Router, ...) Can we meet requirements with DHCP extensions? Extend DHCP to provide scope information (a number and a string) Provide mechanisms to request, allocate. renew lease, release assignments of mcast addrs Details - Client obtains scope list and unicast or multicast address for MDHCP server using DHCPINFORM. - Client selects a scope, then sends a unicast or multicast DHCPDISCOVER - Server(s) send unicast DHCPOFFER of multicast address(es) - Client sends unicast or multicast DHCPREQUEST - Server sends DHCPACK or DHCPNAK. When a lease is created,some cookie is given out. Any participant can use the cookie to renew the lease in order, for example, to continue a conference after its creator has left. Other features -- - Client MDHCP and DHCP could be in a single implementation. - Client MDHCP and DHCP could be separate, MDHCP client would use (a new?) PORT option. - Servers could be combined or separate. Use of multicast or unicast ensures that DHCP-only implementations are not affected by MDHCP messages. Guidelines - Server MUST Not allocate same address with overlapping scope & time to two different requests. - Server SHOULD avoid allocating an address that is already allocated for a different time in the same scope. Questions: Crawford: Use of multicast for MDHCP non-interference with DHCP won't work in v6 Handley: SDR's scaling is good. Jacobson: Yes, and the scaling of MDHCP is bad. No structure - space is flat - multiple servers must coordinate, either by structure (which wastes a lot) or by talking between servers. How? Block of addresses, if your app. needs more than one. Someone: but at a corporate-sized scale, this can work. No action taken by the working group. -------------------------------------------------------------------- (v). Issues for an Inter-domain Multicast Routing Protocol -------------------------------------------------------------------- David Meyer discussed his draft on issues for an Inter-domain Multicast Routing Protocol. During the description, he pointed out that many common Internet applications exhibit point-to-multipoint or "multicast" behavior. The world wide web's data distribution and caching models, soft real-time applications such as video conferencing and application sharing, and USENET News (NNTP) are examples of common applications which assume a point-to-multipoint distribution model. These applications have historically relied on unicast technologies to implement point-to-multipoint or multipoint-to-multipoint communication topologies. In particular, multipoint communication in the Internet had been and is still is (in many cases) implemented by replicating unicast flows, one for each receiver. Replicating unicast flows is clearly neither efficient nor scalable; the problem is exacerbated in the inter-domain environment, where resources are particularly scarce. Over the past few years, however, efficient IP layer multicasting has been recognized as one of the essential architectural features required in an Internet that can scale to very large sizes. In recent years we have seen the first multicast routing and forwarding protocols designed and deployed on the Internet [DVMRP, PIMARCH, CBT]. While these protocols have been relatively successful in small scale deployment [MBONE], However, these protocols have exhibited various deficiencies when scaling to the Internet sizes while still providing adequate policy control for network service providers. The seminal work on multicast routing is contained in Steve Deering's thesis [DEERING89]. Deering outlined a mechanism for building shortest path multicast distribution trees (SPT) using Reverse Path Forwarding (RPF). For each (S,G) pair, the method builds a distribution tree rooted at the source such that each receiver is on the shortest path back to the source (the notation (S,G) represents a source,group pair). When the path between a sender and receiver is symmetrical, RPF computes the shortest path tree. The method is data-driven, data is flooded down all the branches of the distribution tree. Nodes that have no downstream receivers send "prune" packets upstream (toward the source) to prune branches of the tree which have no receivers. This protocol has become known as as Dense-Mode [PIM-DM], and is most useful when group members are densely clustered in some part of the topology. To address the case of sparsely distributed group members, Minimal Shared-Tree (MST) distribution algorithms have been introduced. Shared distribution trees have their origin as approximations of Steiner Minimal Trees, and use a variation on Center-based trees [WALL80] as their basis. Current shared tree multicast distribution algorithms include Core Based Trees [CBT] and Protocol Independent Multicasting Sparse Mode [PIM-SM]. The root of the shared tree is often called a Core or Rendezvous Point (RP). Shortest Path and Shared Tree algorithms represent trade-offs [WEI93] at three fundamental points in the design space: - Delay Shared tree algorithms have worse delays for large groups, since no known RP placement can produce shortest paths. Shared tree algorithms also don't handle dynamic group membership as well as shortest path tree, since optimal RP placement is a function of group membership distribution. In summary, SPT multicast routing algorithms like DVMRP or MOSPF [MOSPF] have the worst case delay is bounded by the round-trip time (RTT) from the receiver to the sender, whereas shared tree algorithms like PIM-SM and CBT have worst case delay bounded by twice the RTT from receiver to RP/core (assuming symmetrical unicast routing from sender to receiver). - Traffic Concentration Traffic concentration is a well known problem for shared tree protocols. For some important classes of topologies, shared tree and source trees yield the same delay characteristics. - State information Shortest path trees require much more state information. Shared tree approaches only require a single tree, used by all, while the shortest path trees are relative to each site as source. It is possible that shortest path trees could require a (S,G) pair for every active sender or receiver in the Internet. Today's multi-provider Internet reveals a fourth issue in the traditional design space: the ability to express and implement inter-provider policies. However, unlike current inter-domain unicast routing protocols (which have a rich and well developed policy model), neither of the two classes of algorithms described are adaptable in a straight forward way to the policy oriented multi-provider environment found in todays Internet. A simple example illustrates the problem: Consider three providers, A, B, and C, that have connections to a shared-media exchange point. Assume that connectivity is non-transitive due to some policy (the common case, since bi-lateral agreements are a very common form of peering agreement). That is, A and B are peers, B and C are peers, but A and C are not peers. Now, consider a source S covered by a prefix P, where P belongs to a customer of A (i.e., P is advertised by A). Now, multicast packets forwarded by A's border router will be correctly accepted by B's border router, since it sees the RPF interface for P to be the shared-media of the exchange. Likewise, C's border router will reject the packets forwarded by A's border router because, by definition, C's border router does not have A's routes through its interface on the exchange (so packets sourced "inside" A fail the RPF check in C's border router). In this example above, RPF is a powerful enough mechanism to inform C that it should not accept packets sourced in P from A over the exchange. However, consider the common case in which P multi-homed to both A and B. C now sees a route for P from B through its interface on the exchange. Without some form of multi-provider cooperation and/or packet filtering (or a more sophisticated RPF mechanism), C could accept multicast packets sourced by S from A across the shared media exchange, even though A and C have not entered into any agreement on the exchange. The situation described above is caused by the overloading of the semantics of unicast route (as described above), and the reliance on the RPF check as a policy mechanism. Note: During the IDMR meeting, it was suggested that this document be reworked into a requirements document. Meyer agreed to edit the document. -------------------------------------------------------------------- (vi). Current IDMR Inter-domain Routing Proposals -------------------------------------------------------------------- Dave Thaler (Deborah Estrin, Dino Farinacci) -- IDMRP concepts and deployment "A number of ideas that a number of us have been banging around for the last year or so." Goals of an IDMRP: low BW overhead minimize state low CPU consumption fast convergence Today's interoperability can achieve source-specific trees in flood-and-prune regions. Either no pruning, or state per source. Must flood either the data or the membership information Result: NOT acceptable Not a new problem - inter-domain mcast has the same menu of choices and intra-domain mcast. Concentrate work on an O(G) state O(C) mumble protocol, somewhat like HDVMRP Future goal: "Group-shared three of domains" Features of IDMRP scheme in progress independent of M-IGP Group-shared trees of domain (low state volume) Bidirectional group-shared tree (minimize 3rd party dependence Group state is aggregatable A group-shared tree of domains has effects on policy: - Can't have source-specific policies on group shared trees -- Can have group-specific policies Requiring switch to SPT first (before receiving data) would introduce a bursty-source problem, so don't require that. Summary: tradeoff between amount of state and amount of policy control. Using center-based trees requires mapping group G to root for RPF; however, for locality, want every domain to be a potential root domain (root gets all data). E.g., a group for a "lecture" should be rooted at the lecturer's domain. Advertising to BSR model is not as scalable when number of candidate RPs is unbounded. We want group state to be aggregatable. Proposal: put some structure into multicast addresses -- Dynamically assign group prefixes to user domains with topological significance (and repeat for each scope level). -- What do you do RPF check against? Use a "representative IP address" (aka Landmark address) for RPF check at BRs. BRs must map G to Landmark address ... -- Implications: Local-prefix periodically announced in each domain. Address allocators (eg, SDR) see prefix per scope and allocate from that range. -- Other allocation schemes merely give poorer tree of domains for the traffic. Policy II - Tragedy of the commons -- Transiting multicast means you're willing to transit between subtree branches. -- Since no single domain is the root for all groups, this (bold assertion follows) evens out. -- Result: less overhead for everyone. If people honor the recommended address allocation, the groups you provide transit for are usually your customers' groups. Q: Draw the picture in the real internet and "usually" -> "occasionally." Q: A long three-way discussion among Randy Bush, Van Jacobson and Sue Hares about transit, policy, peering, and so on. -------------------------------------------------------------------- (vii). M-BGP -------------------------------------------------------------------- Tony Ballardie described his draft with Martin Tatham that extends BGP to support inter-domain multicast routing (policy). The main issues here include the fact that this proposal just builds paths, and not distribution trees. An interesting "convergence" is occurring with the IDR. They are looking at various multi-protocol BGP proposals. Of course, M-BGP could be viewed as another address in this context. -------------------------------------------------------------------- (ix). Multicast Diagnostic Tools -------------------------------------------------------------------- Bernard Aboba outlined the current draft. Few comments were given. No working group action was taken. -------------------------------------------------------------------- (x). Intro to Multicast Routing -------------------------------------------------------------------- Tom Maufer introduced himself and asked for additional comments. draft-ietf-mboned-intro-multicast-00.txt is in WG last call. -------------------------------------------------------------------- (xi). Rate Limiting Draft -------------------------------------------------------------------- Doug Junkins outlined the current draft. A few comments were given. A new draft will be posted.