[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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
                     <draft-ietf-idmr-masc-00.txt>





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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/