[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                     Dino Farinacci
INTERNET DRAFT                                                Liming Wei
                                                             John Meylor
                                                           cisco Systems
                                                           March 3, 1998


       Use of Anycast Clusters for Inter-Domain Multicast Routing
             <draft-ietf-farinacci-anycast-clusters-01.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 learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   Anycast Clusters is a proposal to connect multiple ISP sparse-mode
   PIM domains together. The environment we anticipate is multiple
   interconnection points among a set of ISPs when they are unable to
   colocate their respective RPs at the same dense-mode interconnect
   point. This is an alternative to the Multi-Level RP design and
   requires less new code in routers.

   This proposal is being submitted as a method for the initial phase of
   Inter-Domain Multicast deployment and is upward compatible with the
   IDMR protocols being proposed for subsequent phases.









Farinacci, Wei, Meylor                                          [Page 1]


RFC DRAFT                                                     March 1998


1.0 Introduction

   Anycast Clusters is a proposal to connect multiple ISP sparse-mode
   PIM domains together. The environment we anticipate is multiple
   interconnection points among a set of ISPs when they are unable to
   colocate their respective RPs at the same dense-mode interconnect
   point. This is an alternative to the Multi-Level RP design and
   requires less new code in routers.

   This proposal uses an adminstrative approach to solve the problem of
   connecting shared trees together across domains. To expedite
   deployment with minimal risk, changes to architecture or protocols
   are not considered.

   It is known that there is a 3rd party RP problem when an ISP must
   depend on another ISP's RP to 1) get their own sources' traffic on
   the shared tree and 2) to receive multicast traffic from sources
   inside and outside of their domain. This proposal reduces the
   probability that a 3rd party RP is used but doesn't eliminate it all
   together.


1.1 Terminology

   Multicast Cluster
      A Multicast Cluster is an interconnect or dense-mode region where
      there are two or more multicast peering agreements among ISPs. The
      Multicast Cluster runs dense-mode PIM.

   Anycast Cluster Address
      A single IP unicast address that every router on a Multicast
      Cluster interconnect has assigned to it. The address is assigned
      to a loopback interface on each multicast router. The same address
      is used on the loopback interface of each router.

   Cluster RP Address
      Is the address routers use to Register and Join to an RP. The RP
      address is the assigned Anycast Cluster Address.













Farinacci, Wei, Meylor                                          [Page 2]


RFC DRAFT                                                     March 1998


2.0 Overview

   There will be N Multicast Cluster interconnects configured in the
   Internet.  The number of interconnects may change but we anticipate
   it will not change often. The global multicast group address space
   will be divided among the N Multicast Clusters. That is, 1/Nth of the
   group address space will use the Cluster RP Address associated with
   each Multicast Cluster. This allows traffic distribution for
   different groups on each of their shared-trees to be split across all
   Multicast Clusters.

   Receivers in any domain join a single shared tree. The leaf routers
   that hear IGMP reports for a specific group will do a DNS lookup to
   obtain the Cluster RP Address. By converting the dotted decimal group
   address, obtained from the IGMP report, into a DNS domain name
   string, a name is created for the DNS lookup.

   The Joins that are propagated toward the RP will hit the first
   Cluster RP Address for the group, and hence why we call it an Anycast
   Cluster Address. For the same group that is joined, many border
   routers at the Multicast Cluster interconnect can act as the RP for
   the group. This is how a domain can pull down data for receivers in
   its domain.

   Many shared trees can be built if receivers in other domains use a
   different router as the RP on the Multicast Cluster. Each shared tree
   is joined together at the Multicast Cluster interconnect since it is
   a dense-mode interconnect.

   Similarly, Register messages from leaf routers use the dotted decimal
   group address to DNS string mapping and the closest router with the
   Cluster RP Address is used. This allows sources in the same domain to
   get their packets to the shared tree for receivers in other domains.

   Requiring the Multicast Cluster interconnect to run dense-mode PIM
   allows any RP that receives data via Register messages to forward on
   the interconnect so the other RPs in the Multicast Cluster can
   forward down their respective shared trees.


3.0 Group Allocation

   Since a global group address subrange is assigned to a Multicast
   Cluster interconnect and not to a domain, there is no address
   ownership or leasing algorithm issues to deal with. We anticipate the
   number of subranges be less than or equal to 256. So we believe it is
   easily manageable in DNS because of the small number and the
   infrequent changes to the allocation. The DNS records only need



Farinacci, Wei, Meylor                                          [Page 3]


RFC DRAFT                                                     March 1998


   change when there is a new Multicast Cluster configured. This occurs
   at the rate when new multicast peering interconnects are deployed by
   ISPs.


4.0 Example Multicast Cluster Design

   Let's say, initially, there are 12 ISPs that will multicast peer at 8
   different public interconnects. Therefore, there will be 8 Multicast
   Clusters. Let's say the 224.2.0.0/16 range of group addresses are
   used for global multicast addressing.

   Let's allocate a class C network for the Cluster RP Addresses with
   the following address convention:

       223.255.255.x where x defines the Cluster RP Address. The host address
       for all RPs at a Multicast Cluster will be 1 by convention. So:

           223.255.255.1   = Cluster 1
           223.255.255.3   = Cluster 2
           223.255.255.5   = Cluster 3
           223.255.255.7   = Cluster 4
           ...
           223.255.255.255 = Cluster 128

   Each ISP router that wishes to be the RP on the Multicast Cluster 1
   will do the following:

      interface loopback0
      ip address 223.255.255.1 255.255.255.255

   It is required that at least two RPs are present at any interconnect
   so a single ISP doesn't have to carry the load for the the entire
   group subrange allocated to the Multicast Cluster.

   A single ISP can provide an RP for all or some of the Multicast
   Clusters it is attached to but is required to provide an RP on at
   least one interconnect.













Farinacci, Wei, Meylor                                          [Page 4]


RFC DRAFT                                                     March 1998


   In the DNS the 224.2.0.0/16 range could be divided as follows:

   Cluster  Group Range        DNS Mapping                     RP Address
   -------  -----------        -----------                     ----------
   000      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.1
            where 0 <= x <= 31
   001      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.3
            where 32 <= x <= 63
   010      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.5
            where 64 <= x <= 95
   011      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.7
            where 96 <= x <= 127
   100      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.9
            where 128 <= x <= 159
   101      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.11
            where 160 <= x <= 191
   110      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.13
            where 192 <= x <= 223
   111      224.2.x.0/24  ->   x.2.224.mcast.net      IN    A  223.255.255.15
            where 224 <= x <= 255

   So if a leaf router received an IGMP  report  (or  data  packet)  for
   group 224.2.129.5, it would do a DNS lookup for 5.129.2.224.mcast.net
   (or if  the  /24  convention  is  accepted  it  could  simply  lookup
   129.2.224.mcast.net  to reduce DNS entries) and get 223.255.255.9 re-
   turned. It would Join or Register to the closest RP 223.255.255.9.


5.0 Observation

   By using Anycast Cluster RP Addresses, no single ISP will have to be
   RP for the entire group subrange allocated to the Multicast Cluster.
   The workload and responsibility can be shared among the RPs (and
   different ISPs) on that Multicast Cluster.

   If an ISP doesn't configure an RP on a Multicast Cluster, it must do
   so on another Multicast Cluster so it can be a good citizen and share
   responsibilty.  Since group addresses are mostly randomly allocated,
   the RP load can be shared across Multicast Clusters and depending on
   the source and receiver location may be load shared across routers
   within a Multicast Cluster.

6.0 Acknowledgements

   The authors would like to thank David Meyer and Steve Deering for
   their insightful comments.





Farinacci, Wei, Meylor                                          [Page 5]


RFC DRAFT                                                     March 1998


7.0 Author's Address:

   Dino Farinacci
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134
   Email: dino@cisco.com

   Liming Wei
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134
   Email: lwei@cisco.com

   John Meylor
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134
   Email: jmeylor@cisco.com


8.0 References

[1] Estrin D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley M., Jacobson, V., Liu C., Sharma, P., Wei, L., "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification",
draft-ietf-idmr-pim-sm-specv2-00.txt, September 9, 1997.

[2] Thaler, D., Estrin, D., Meyer, D., "Border Gateway Multicast
Protocol (BGMP): Protocol Specification", draft-ietf-idmr-gum-01.txt,
October 30, 1997.

[3] Bates, T., Chandra, R., Katz, D., and Y. Rekhter., "Multiprotocol
Extensions for BGP-4", draft-ietf-idr-bgp4-multiprotocol-01.txt,
September 1997.
















Farinacci, Wei, Meylor                                          [Page 6]