Internet Engineering Task Force Deborah Estrin (USC) INTERNET-DRAFT Mark Handley (ISI) Expires May 1998 Satish Kumar (USC) David Thaler (Merit) 20 November 1997 The Multicast Address Set Claim (MASC) Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast) or ftp.isi.edu (US West Coast). 1. Introduction The MASC protocol is used by a node (typically a router) to claim one or more sets of addresses (''address sets'') from which Multicast Address Allocation Servers (MAAS's) within its domain will allocate group addresses to hosts. Each address set has an associated lifetime, and is chosen out of a larger address set with a lifetime at least as long, in a manner such that address sets are aggregatable. At any time, each MASC node will typically be advertising several address sets with different lifetimes and scopes allowing MAAS's to choose appropriate addresses for their clients. Expires May 1998 [Page 1] Draft MASC November 1997 Each address set associated with a domain is injected into an inter- domain routing protocol (e.g., BGP4+ [1]), where it can be used by an inter-domain multicast tree construction protocol (e.g., BGMP [2]) to construct inter-domain group-shared trees. Note that a domain need not claim an address set to be able to allocate addresses, nor does claiming necessarily guarantee that hosts in other domains will not use an address in the set (since, for example, hosts are not forced to contact a MAAS before using a group address). Claiming does, however, ensure that inter-domain multicast distribution trees for any group in the address set will be locally-rooted, and that traffic will be sent outside the given domain only when and where external receivers exist. Editors Note: This document is very incomplete. We have tried to mark those sections that are the most incomplete. 2. Design philosophy The key design requirements for our inter-domain address allocation mechanism are: o Efficient address space utilization, which naturally implies that address allocations be based on the actual address usage patterns, and therefore that it be dynamic. o Address aggregation, that implies that the address allocation mechanism be hierarchical. o Robustness, by having decentralized (i.e., BGP-like) mechanisms. The timeliness in obtaining an address set is not a major design constraint as this is taken care of at a lower level (as explained elsewhere in the document). 3. Overall Architecture The Multicast Address Set Claim (MASC) protocol is used by MASC domains to claim address sets for use by Multicast Address Allocation Servers (MAASs) within each domain. Typically one or more border routers of each domain which desires multicast address space of its own would run MASC. Throughout this document the term MASC domain refers to a domain that has at least one node running MASC; typically these domains will be ASs Expires May 1998 [Page 2] Draft MASC November 1997 (Autonomous Systems). A MASC domain claims an address set, advertises this to other MASC domains in the network, and waits while listening for any collisions. If there is a collision, the MASC speaker(s) may have to give up the current claim and claim a different address set, which it then advertises again to other MASC domains. The MASC domain repeats the above procedure till it gets an unallocated address set. After a sufficiently long collision-free waiting period, the address set obtained by a MASC node is then injected as a "multicast route" into the inter-domain routing protocol (e.g., BGP4+) as Network Layer Reachability Information (NLRI). The above route information pertaining to multicast is stored in border routers in a routing table we will refer to as the Group-RIB (G-RIB). The G-RIB is used by inter-domain multicast routing protocols like the Border Gateway Multicast Routing protocol (BGMP) to build group shared trees that are rooted in the MASC domain advertising the address set. In particular this is achieved by the border routers forwarding group specific joins/packets from receivers/sources towards the root domain via the next-hop indicated by the G-RIB information. In order to reduce the size and slow the growth of G-RIB, the border routers perform CIDR-like aggregation of the multicast NLRI information. This motivates our MASC algorithm to select address sets for domains in such a way as to ensure good aggregation in addition to achieving good address space utilization. A figure illustrating the MASC architecture is at http://netweb.usc.edu/kkumar/masc.ps. 4. MASC The domain hierarchy used by MASC is congruent to the somewhat hierarchical structure of the inter-domain topology, e.g., backbones connected to regionals, regionals connected to metropolitan providers, etc. MASC peerings are locally configured as in BGP. A MASC domain that is a customer of other MASC domains will have one or more of those provider domains as its parent. For example, a MASC domain that is a regional provider will choose one of its backbone provider domains as its parent. Children MAY be configured with their parent MASC domain, but in general may use heuristics such as to whom they point default to automatically select one or more parent domains. Parents may be configured with children domains as well. The multicast address set claims made by a MASC domain are driven by its own, and its children domains' usage patterns in a bottom-up fashion, thus resulting in good address space utilization. At the same time, the address space partition is effectively done in a top-down fashion since Expires May 1998 [Page 3] Draft MASC November 1997 children MASC domains pick their address sets out of their parent's address sets, thus leading to good aggregation. The address set claims made by a MASC domain are advertised to the parent. The domain's MASC speaker(s) then advertise it to all its other children MASC domains. These children MASC domains generate collision announcements if necessary which are forwarded to their sibling MASC domain that made the claim. The claimant domain may have to give up its current claim and make a claim for another address set based on criteria described later in the document. {Editors NOTE} Give an example here of a leaf domain claiming from its parent, parent making a claim from its parent that is a backbone network etc. 5. Start-up rules Start up is based on the same rules as those used in steady state. A MASC node at one specially-selected domain or exchange is bootstrapped to advertise the entire multicast address space i.e., 224/4. The MASC nodes in leaf domains hear this advertisement and pick an address set from this range, the size of which depends on their current address requirements. Since each allocation domain picks an address subset from the entire address space, the address sets that are initially requested are not necessarily aggregatable. During this phase the parent nodes get an estimate of the amount of address space that they need to claim to satisfy the requirements of their children. Using thes estimates these parent domains claim address sets sufficiently large to satisfy their own and their children's claims. They may then send back collision announcements to their children whose claims fall outside the parent's space, forcing the children to pick up new address sets which will then be aggregatable. 6. Claim-collide mechanism Our design prefers a claim-collide mechanism to a query-response type of mechanism for the following reasons. In a query-response mechanism, replicas of the MASC node would be needed in parent MASC domains in order to make their responses be robust to failures. This brings about the associated problem of synchronization of the replicas and possibly additional fragmentation of the address space. Besides, we still need to handle address collisions even in this mechanism. Instead, our proposed claim-collide mechanism is simpler and more robust than a query-response mechanism. Expires May 1998 [Page 4] Draft MASC November 1997 Each address set is also associated with a lifetime to prevent domains from permanently claiming a set of addresses. A domain MUST renew requests for a certain address set if it wishes to continue to advertise a route for it. 7. Detailed Claim-Collide Mechanism Rules {Editors Note: To be filled in} 8. Packet Formats {Editors Note: To be filled in} 9. Open Issues o Initial request amounts o Rules for when to claim more space o Manage addresses with different lifetimes. What to reclaim and what not? o Aggregation wrt multihomed domains (problems due to longest match) 10. References [1] Bates, T., Chandra, R., Katz, D., and Y. Rekhter., "Multiprotocol Extensions for BGP-4", draft-ietf-idr-bgp4-multiprotocol-01.txt, September 1997. [2] Thaler, D., Estrin, D. and D. Meyer., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", draft-ietf-idmr-gum- 01.txt, October 1997. 11. Security Considerations Security issues are not discussed in this memo. Expires May 1998 [Page 5] Draft MASC November 1997 12. Authors' Addresses Deborah Estrin Computer Science Dept./ISI University of Southern California Los Angeles, CA 90089 Email: estrin@usc.edu Mark Handley USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina Del Rey, CA 90292 Email: mjh@isi.edu Satish Kumar Computer Science Dept./ISI University of Southern California Los Angeles, CA 90089 Email: kkumar@usc.edu David Thaler Merit Network, Inc 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105-2785 Phone: +1 313 647 4813 Email: thalerd@merit.net Expires May 1998 [Page 6] Draft MASC November 1997 Table of Contents 1 Introduction .................................................... 1 2 Design philosophy ............................................... 2 3 Overall Architecture ............................................ 2 4 MASC ............................................................ 3 5 Start-up rules .................................................. 4 6 Claim-collide mechanism ......................................... 4 7 Detailed Claim-Collide Mechanism Rules .......................... 5 8 Packet Formats .................................................. 5 9 Open Issues ..................................................... 5 10 References ..................................................... 5 11 Security Considerations ........................................ 5 12 Authors' Addresses ............................................. 6 Expires May 1998 [Page 7]