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

Versions: 00 01                                                         
Network Working Group                                    Seisho Yasukawa
IETF Internet Draft                                                  NTT
Expires: April 2005
                                                          Shankar Karuna
                                                        Sarveshwar Bandi
                                                                Motorola


                                                           Adrian Farrel
                                                      Old Dog Consulting



                                                            October 2004




                       BGP/MPLS IP Multicast VPNs


                  draft-yasukawa-l3vpn-p2mp-mcast-00.txt


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


   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."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Copyright Notice


   Copyright (C) The Internet Society (2004). All Rights Reserved.





Yasukawa, Karuna, Bandi and Farrel.                             [Page 1]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



Abstract


   This document describes a solution framework for IP Multicast
   VPNs. It describes procedures for establishing optimal virtual
   private IP multicast networks over a provider network. The simple
   multicast tunnel operation mechanism within a core network provides
   easy and flexible IP multicast VPN service operation for the
   service provider. And because the solution can minimize PIM
   neighbor maintenance over remote PEs, the solution enhances the
   scalability performance of the multicast VPN service network. This
   document also describes a P2MP TE LSP based multicast tunnel
   mechanism which could enhance TE capability and reliability of IP
   multicast VPNs.



Conventions used in this document


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
































Yasukawa, Karuna, Bandi and Farrel.                             [Page 2]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



Contents


   1. Introduction .................................................. 04
   2. Motivations ................................................... 04
      2.1. Basic Motivations for IP multicast VPN operation ......... 04
      2.2. Motivations for IP multicast VPN protocol design ......... 05
   3. IP Multicast VPN Framework .................................... 06
      3.1. Basic network model ...................................... 06
      3.2. Proxy-Source/RP model .................................... 08
      3.3. Proxy-Source/RP function ................................. 09
      3.4. Auto-Discovery of VPN membership ......................... 09
      3.5. Default MDT configuration ................................ 10
      3.6 Exchanging IP multicast register information .............. 10
      3.6.1. Source Activate (SA) SAFI .............................. 11
      3.6.2. JOIN SAFI .............................................. 12
      3.7 Default MDT operation ..................................... 13
      3.8. Data MDT operation ....................................... 14
      3.9. Inter-Site Scaling and Site Interdependencies ............ 16
      3.10. Multi-Homing scenario ................................... 17
      3.11. Multi-Area/As operation ................................. 17
   4. IANA Considerations ........................................... 17
   5. Security Considerations ....................................... 17
   6. Acknowledgements .............................................. 17
   7. Intellectual Property Considerations .......................... 17
   8. Normative References .......................................... 18
   9. Informational References ...................................... 18
   10. Authors' Addresses ........................................... 19
   11. Full Copyright Statement ..................................... 20
























Yasukawa, Karuna, Bandi and Farrel.                             [Page 3]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



1. Introduction


   This document describes a solution framework for IP Multicast
   VPNs. It describes basic procedures for establishing optimal virtual
   private IP multicast networks over a provider network by dividing a
   customer's multicast network into multiple regions and setting
   independent multicast distribution trees within each customer site
   and interconnecting these independent trees by provider P2MP MPLS
   tunnels. In this solution, each PE connected to a customer's site
   acts as a proxy-source or a proxy-rendezvous point (RP) for the
   multicast group and a default multicast tunnel is established from a
   PE which accommodates a multicast source to multiple PEs which act as
   proxy-source/RP for their receivers in the connected site.


   As a result, the solution can construct IP multicast distribution
   trees that have optimal topologies for IP multicast distribution and
   avoid using multiple multicast and unicast distribution tunnels in
   the service provider core during the customer's tree transition
   phase. This simple multicast tunnel operation mechanism within a core
   provides easy and flexible IP multicast VPN service operation for the
   service provider. And, because the solution can terminate each
   customer's Join/Prune message at PEs, the solution can minimize PIM
   neighbor maintenance over remote PEs. This enhances the scalability
   performance of multicast VPN service network. This document also
   describes a P2MP TE LSP based multicast tunnel mechanism which could
   enhance TE capability and reliability of IP multicast VPNs.



2. Motivations


2.1. Basic Motivations for IP multicast VPN operation


  There are growing demands for providing IP multicast services on top
  of a BGP/MPLS IP VPN [RFC2547bis] environment. Candidates for these
  services are, for example, in-house video distribution/conference and
  data synchronization/distribution between business system servers
  which usually require strict QoS control and highly reliable network
  conditions. Therefore it is highly desirable that a solution has the
  capability to implement some QoS guarantee and protection mechanisms
  in itself, or has capabilities to operate with conventional QoS
  guarantee and protection mechanisms.


  Because IP multicast VPNs require full meshed multicast distribution
  between multiple customer sites, and this operation usually requires
  complicated multicast tree management within a provider core network,
  it is also highly desirable that a solution provides the service
  provider with several easy mechanisms to control and manage these IP
  multicast distributions within the network.




Yasukawa, Karuna, Bandi and Farrel.                             [Page 4]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



2.2. Motivations for IP multicast VPN protocol design


   The basic function of an IP multicast VPN is to enable a multicast
   source which exists in a customer site to send IP multicast traffic
   privately over the provider core network to multicast receivers that
   exist in different customer sites.


   To enable this private IP multicast transmission, several solutions
   have been proposed. Within the proposals, the most significant
   solution is [MCAST-VPN] which introduces the Multicast Domain (MD)
   mechanism to interconnect each customer's IP multicast networks over
   the provider network to enable IP multicast distribution between the
   sites. An MD is essentially a set of MVRFs associated with interfaces
   that can send multicast traffic to each other and is equivalent to
   a multi-access interface from the standpoint of a PIM customer
   instance. Therefore, in this MD model, a provider wide customer IP
   multicast network is formed over an MD which transparently exchanges
   customer's IP multicast control messages between PEs which form IP
   multicast adjacencies between them. This means that when the customer
   network runs the PIM protocol, PIM adjacencies are formed between
   MVRFs at the PEs and periodic PIM Join/Prune messages and Hello
   messages are transmitted between them.


   This features introduces some scalability concerns for the service
   provider when they operate IP multicast VPNs because today's
   conventional L3VPNs accommodate a lot of large scale VPNs and it is
   easily assumed that a majority of these VPNs will introduce IP
   multicast VPN services in the near future. This would require a huge
   amount of PIM adjacencies to be maintained over the provider core
   network and this would reduce the VPN's network performance and
   increase the difficulties of managing the network.


   A further MVPN proposal [MVPN-RAGGARWA] addresses three scalability
   concerns for this conventional [MCAST-VPN] solution as fundamental
   issues to be resolved. The first addressed concern is the overhead of
   PIM neighbor adjacencies. The second concern is the overhead of
   periodic PIM Join/Prune messages, and the last concern is the amount
   of state in the SP core. It is highly desirable for any solution to
   address these concerns.


   Another concern which is not yet addressed is suboptimal IP multicast
   distribution which could easily occur in an IP multicast VPN
   environment. Most customers want to operate their own private IP
   multicast networks over multiple customer sites which are usually
   widely separated from each other over the provider network, and it is
   easily assumed that the customer runs PIM [PIM-SM] with only a very
   limited number of RPs in sites which may be located remotely from the
   site which a multicast source belongs to. In this case, during shared




Yasukawa, Karuna, Bandi and Farrel.                             [Page 5]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   tree distribution, multicast packets must first be sent to the RP's
   site and then must to be sent back to receivers' sites even in the
   case where some receivers belong to the same site as the source. This
   kind of multiple transmission over the provider network is suboptimal
   and wastes network resource. Moreover some receivers would suffer
   severe transmission delays and some multicast application would not
   tolerate this.


   In addition to these undesirable conditions, a customer's IP
   multicast distribution pattern changes drastically when the
   distribution tree is transferred from a shared tree to a source
   specific tree. This would also cause drastic changes in the multicast
   distribution pattern in the provider core and would introduce
   unstable conditions for the operation of the core network and
   consequently for the VPNs. There is no mechanism for a service
   provider to limit this kind of undesirable condition and to control
   the multicast distribution pattern. Therefore it is highly desirable
   for a solution to address these concerns. It is desirable for a
   solution to provide the service provider with mechanisms which can
   avoid this kind of suboptimal IP multicast distribution within their
   core networks and which can allow control of multicast distribution
   within their core networks by eliminating the necessity of using and
   changing multiple multicast tunnels and by providing a minimum number
   of stable multicast tunnels which are easily managed by the service
   provider.


   Because some IP multicast VPN applications require bandwidth
   guarantees, delay-constrained multicast distribution paths, and
   highly reliable paths, it is desirable for a solution to have
   capabilities to setup a bandwidth guaranteed multicast distribution
   path, to explicitly control routes of the distribution path, and to
   accommodate global and fast local repair mechanisms.



3. IP Multicast VPN Framework


3.1. Basic network model


   This document utilizes the same network model as BGP/IP MPLS VPNs
   [RFC2547bis] for realizing IP multicast VPNs. A provider configures
   whether a particular VPN is multicast-enabled or not. All the PEs
   that contain customer sites belonging to the same VPN with multicast
   enabled on them will be connected using a "Multicast Distribution
   Tree (MDT)" in the provider's backbone.








Yasukawa, Karuna, Bandi and Farrel.                             [Page 6]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   As deployed in BGP/IP MPLS VPNs [RFC2547bis] and [MCAST-VPN], each CE
   router is a multicast routing adjacency of a PE router, but CE
   routers at different sites do NOT become multicast routing
   adjacencies of each other.


   Unlike the [MCAST-VPN] model, this document proposes the use of BGP
   for both discovering IP multicast VPN membership and exchanging IP
   multicast routing information in a given IP multicast VPN.


   As for the membership discovery, all the PE routers advertise their
   IP multicast VPN membership to other PE routers using BGP so that
   each PE router in the network has a complete view of the IP multicast
   VPN membership of the other PE routers.


   After this information exchange, the Default MDT for a Multicast
   Domain is constructed automatically. Note that this Default MDT
   construction occurs when the PEs in the domain come up and advertise
   their membership of a multicast enabled VPN, and the construction
   does not depend on the existence of multicast traffic in the domain.


   One further difference is that the MDTs are usually created by P2MP
   TE LSPs by running a P2MP TE signaling protocol in the
   backbone. Therefore, it may not be necessary to run IP multicast
   routing protocols in the core to support IP multicast VPNs (dependent
   on how the P2MP TE trees are managed).


   As for multicast routing information exchange, this document proposes
   BGP to carry the information. Therefore, being different from the
   [MCAST-VPN] model, the customer's IP multicast instances of a
   particular VPN running on the PE do not form routing adjacencies
   with each other. This means that the customer's IP multicast control
   packets are always terminated at PEs and independent multicast
   domains are formed within each customer site which is a member of the
   IP multicast VPN. In this model, the customer's IP multicast control
   messages, such as PIM Join/Prune messages, are converted to BGP
   messages and these messages are exchanged between PEs so that IP
   multicast routing can be enabled between each independent IP
   multicast domains.


   This preserves two important features of BGP/IP MPLS VPNs
   [RFC2547bis]; "Separation of controlling and forwarding plane in the
   provider core" and "Distribution of customer's routing information
   via provider's routing facility". These are very important
   preservations for the SP to preserve its network management model
   while allowing it to control/engineer the customer's data traffic and
   control traffic over the network.






Yasukawa, Karuna, Bandi and Farrel.                             [Page 7]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   Multicast data packets from within a VPN are received from a CE
   router by an ingress PE router, the ingress PE then encapsulates the
   mutlicast packets and forwards them along the Default MDT to all the
   PE routers connected to sites of the given VPN. Every PE router
   attached to a site of the given VPN thus receives all multicast
   packets from within that VPN. If a particular PE router is not on the
   path to any receiver of that multicast group, the PE simply discards
   that packet.


   In the same way as [MCAST-VPN], this document proposes to set up Data
   MDTs to accommodate a large amount of traffic being sent to a
   particular multicast group but where that group does not have
   receivers at all the VPN sites.



3.2. Proxy-Source/RP model


   Section 2.2 of [RFC3446] describes the need to run multiple RPs in
   the scenarios where the topological location of RP, Source and
   receivers are unpredictable. This document proposes a solution along
   similar lines.


   This document proposes that all PEs which are members of a given VPN
   act as proxy Source/RPs for a given IP multicast group.
   Approving all the PEs to be a proxy Source/RP for the group, each
   customer site can form an independent IP multicast tree within the
   site regardless of multicast tree formations in other sites.


   To accomplish this model, a PE that is either directly connected to
   the multicast source in the VPN or connected via a CE MUST act as a
   proxy-RP for the receivers in the same site when the customer network
   runs PIM-SM protocol in the VPN.


   If a customer wants to run the RP within his network, in such a case
   the customer can configure one RP on each of his sites and can use an
   anycast-RP and MSDP based mechanism [RFC3446]. This solution can be
   extended to support such an approach and is presently out of scope of
   this document.


   A PE that is either directly connected to an RP in the VPN or
   connected via a CE MUST act as a Source/RP for the receivers in the
   same site, and a PE that is either directly connected to multicast
   receivers for that multicast group or connected via a CE MUST act as
   a Source/RP for the receivers in the same site.








Yasukawa, Karuna, Bandi and Farrel.                             [Page 8]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   A P2MP TE LSP or a MP2MP TE LSP which is described in a later section
   is established from an ingress PE to multiple egress PEs to form a
   default MDT. The setup of default MDT is triggered after the VPN
   membership auto-discovery phase.


   Therefore, each egress PE which acts as a proxy-Source/RP can always
   receive IP multicast data traffic via this LSP tunnel.


   A P2MP TE LSP is established from an ingress PE to egress PEs which
   are interested in receiving the multicast data dynamically to form a
   data MDT. The ingress PE sets up and modifies a data MDT dynamically
   by receiving BGP messages which convey egress PEs interests for
   joining/leaving the VPN membership. Therefore, each egress PE which
   acts as a proxy-Source/RP can receive IP multicast data traffic via
   this LSP tunnel on demand.



3.3. Proxy-Source/RP function


   To make each PE interconnected to a customer site act as a proxy-RP,
   this document assumes that some RP discovery mechanisms, such as
   static configuration or Bootstrap Router, indicates all of the PIM
   router existing in the connected customer site to perform the same
   group-to-RP (PE) mapping. This ensures that all the PIM router in the
   customers site utilize the PE as RP.


   The PE which act as RP and interconnected to IP multicast source must
   handle PIM register message operations, including decapsulation and
   sending source specific join message and PIM register stop message
   and must convert PIM register message to IP multicast source active
   information.


   The PE which acts as RP and is interconnected to multicast receivers
   must terminate PIM Join/Prune messages and convert this information
   to IP multicast registration information.



3.4. Auto-Discovery of VPN membership


   This document assumes MDT SAFI [MDT-SAFI] to discover VPN
   membership. In this model, a MDT group-address is defined per
   Multicast Domain and all the PEs that are configured with MVRFs
   belonging to same IP multicast VPN discover each other thorough this
   SAFI.








Yasukawa, Karuna, Bandi and Farrel.                             [Page 9]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



3.5. Default MDT configuration


   After VPN membership discovery, each PE which is a member of an IP
   multicast VPN will trigger the formation of a P2MP tree towards every
   other PE that has Multicast VRFs for the same Multicast Domain. The
   P2MP TE LSPs [P2MP-RSVP] are established by assigning a MDT
   group-address to the P2MP ID of the SESSION object, and assigning the
   initiator PE's address to the Tunnel Sender Address of the
   SENDER_TEMPLATE object. The destination PEs are designated as leaves
   of the P2MP tree and are encoded as recipients in P2P Sub-LSP
   Objects.


   In order for each PE to forward received IP multicat data packets to
   the appropriate MVRF, each PE which is a member of the IP multicast
   VPN MUST associate the P2MP TE LSPs with a proper MVRF by assigned
   P2MP Labels. These associations are configured when a PE assigns P2MP
   Labels to the P2MP TE LSPs. Therefore, in this model, PHP operation
   MUST be strictly prohibited.


   A MP2MP TE LSP can be also utilized for establishing a Default
   MDT. With the help of Route Reflector functionality in MP-BGP the
   PE's interested in this Multicast Domain are learnt at the node that
   runs as the Route reflector and these PE's are configured as leaves
   for P2MP TE LSP with the route reflector node as root.


   After an RP has set up a P2MP TE LSP to the leaves, the leaves setup
   a P2P TE LSPs to the RP. In this way, a MP2MP TE LSP is established
   between PEs which are members of the Multicast Domain. This MP2MP
   based Default MDT configuration mechanism is useful but it is out of
   scope of this document. The detailed mechanism and procedure will be
   defined in the another [MP2MP-TE-MPLS] document.



3.6 Exchanging IP multicast register information


   This documents proposes exchanging two kinds of IP multicast register
   information between PEs via BGP.


   A new Subsequent-Address Family called Source Activate (SA) SAFI is
   newly defined to announce the activation of a particular customer's
   IP multicast data stream. This SAFI is used by a PE which is either
   directly connected to an IP multicast source or connected via a CE to
   inform other PEs located in different sites that a particular
   customer's (S,G) IP multicast data stream has become active and this
   active IP multicast data can be accessed via this announcing
   PE. Therefore, a PE which is either directly connected to an IP
   multicast source or connected via a CE and acts as proxy RP and sends
   this information via BGP after it confirms establishment of a source




Yasukawa, Karuna, Bandi and Farrel.                            [Page 10]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   specific IP multicast tree between the Designated Router and itself
   by sending a Register-Stop message and receiving a Null-Register
   Message.


   Another Subsequent-Address Family called JOIN SAFI is also newly
   defined to announce the interest of a particular PE to join and prune
   a particular customer's IP multicast data stream. This SAFI is used
   by PEs which are either directly connected to IP multicast receivers
   or connected via CEs to inform a PE which is either directly
   connected to an IP multicast source or connected via a CE that they
   are interested in receiving a particular customer's (S,G) IP
   multicast data stream by announcing JOIN SAFI information. Therefore
   PEs which are either directly connected to IP multicast receivers or
   connected via CEs and which act as proxy-Source/RPs send this
   information via BGP after they have received SA information and have
   confirmed that IP multicast receivers in their site are also
   interested in receiving/leaving this IP multicast data stream by
   receiving customer Join/Prune message.



3.6.1. Source Activate (SA) SAFI


   This SAFI is used to announce to all the other PEs about a particular
   customer (S,G) data stream becoming active.


   SA SAFI:


         +------------------------------+
         |                              |
         |          RD (8 octets)       |
         +------------------------------+
         |      PE's IPv4 address       |
         |         (4 octets)           |
         +------------------------------+
         |  Provider's Group-address    |
         |         (4 octets)           |
         +------------------------------+
         |  Customer's Source-address   |
         |         (4 octets)           |
         +------------------------------+
         |  Customer's Group-address    |
         |         (4 octets)           |
         +------------------------------+


   PE's IPv4 address: IP address of the PE that has detected a multicast
   source in the customer network.






Yasukawa, Karuna, Bandi and Farrel.                            [Page 11]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   Provider's Group-address: The PE assigns a multicast group address
   from an address range that is independent of the customer multicast
   group addresses. This multicast group address is used by the PE's
   that have interested receivers to be able to associate a Data MDT
   associated with data stream corresponding to Customer's
   Source-address and Customer's Group-address


   Customer's Source-address: Address of customer's multicast source.
   Customer's Group-address : Address of customer's multicast group
                              address.



3.6.2. JOIN SAFI


    This SAFI will be used by a PE when it desires to receive data for
    a particular customer (S,G) data stream.


   JOIN SAFI:


         +------------------------------+
         |                              |
         |          RD (8 octets)       |
         +------------------------------+
         |      PE's IPv4 address       |
         |         (4 octets)           |
         +------------------------------+
         |  Customer's Source-address   |
         |         (4 octets)           |
         +------------------------------+
         |  Customer's Group-address    |
         |         (4 octets)           |
         +------------------------------+


   PE's IPv4 address: IP address of the PE that has interested
receivers.


   Customer's Source-address: Address of customer's multicast source.
   Customer's Group-address : Address of customer's multicast group
                              address.













Yasukawa, Karuna, Bandi and Farrel.                            [Page 12]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



3.7 Default MDT operation


   This section describes how the proposed solution enables IP multicast
   VPN operation using a Default MDT assuming a VPN customer runs the
   PIM-SM protocol within their network.


   To establish a Default MDT, MVRFs are first configured on every PE
   which is a member of a given IP multicast VPN. A unique group address
   and RD are assigned to that Multicast Domain. After this
   configuration, each that PE belongs to that Multicast Domain
   announces its VPN membership to other PEs by BGP using MDT-SAFI.


   After this auto-discovery of VPN membership, each PE initiates the
   formation of a P2MP TE LSP by assigning the group address to that
   LSP. A P2MP TE LSP is established from the initiator PE to other PEs
   which are also members of this Multicast Domain. During the P2MP TE
   LSP establishment each PE that is also egress of the LSP and a member
   of that Multicast Domain configures an association between P2MP TE
   LSPs which constitute Default MDT and MVRF for that Multicast Domain
   by relating assigned MPLS labels to the MVRF. The egress PE uses the
   group address announced by the PE, which is the root for this P2MP TE
   LSP, in the MDT-SAFI message [MDT-SAFI].


   Note that as described in the previous section, a MP2MP TE LSP could
   be utilized to establish the Default MDT. But MP2MP TE MPLS is out of
   scope of this document and its detailed mechanism and procedure will
   be addressed in another document.


   Because in this mechanism, each PE that is member of the Multicast
   Domain must act as a proxy-RP for that multicast groups. Therefore,
   all PIM router within a customer's site must be configured by some
   mechanism to treat a connected PE as its RP and to perform same
   group-to-proxy-RP mapping. Examples of these mechanism are static
   configuration and Bootstrap Router mechanism [PIM-BSR] described in
   the previous section.


   Consider the situation where an IP multicast source starts IP
   multicast distribution. The Designated Router (DR) encapsulates IP
   multicast data packets and sends these packets as PIM register
   messages to a PE which now act as proxy-RP for that customer's
   site. Receiving PIM register messages, the PE sends a source specific
   Join message to the DR to form a source specific multicast tree
   between the PE and the DR. The PE simultaneously starts announcing to
   other PEs the activation of a multicast group via BGP using the SA
   SAFI. The PE sends a Register stop message to the DR after it starts
   receiving multicast Data on the source specific tree.






Yasukawa, Karuna, Bandi and Farrel.                            [Page 13]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   When receivers in another customer site want to Join a given
   multicast distribution, then the receivers send Join (*,G) messages
   to their RP to form a shared multicast distribution tree. Note that a
   PE which is either directly connected to the receivers or connected
   via a CE now acts as proxy-RP for the receivers. Therefore a shared
   multicast distribution tree is formed from proxy-RP (PE) to multiple
   receivers in a customer's site. And because this PE knows that
   corresponding multicast data is already activated, the PE sends its
   IP multicast registry information via BGP using JOIN SAFI. This
   information is flooded to all the PEs. As a result, an ingress PE
   which is either directly connected to the IP multicast source or
   connected via a CE configures its MVRF to start forwarding received
   IP multicast data packets to a P2MP TE LSP which comprises the
   Default MDT. In this way, IP multicast data packets are MPLS
   encapsulated at an ingress proxy-RP (PE) and are tunneled via the
   P2MP TE LSP to all the egress proxy-Source/RPs (PEs) and these IP
   multicast data packets are decapsulated at the egress PEs and IP
   multicast data packets are transmitted to IP multicast receivers in
   the site if a shared tree is already formed by multicast receivers
   who are interested in receiving these IP multicast flows.


   When receivers in the customer's site want to switch multicast
   distribution trees from a shared tree to a source specific tree, the
   receivers send source specific Join (S,G) message to source node. In
   this case, a source node is located in another site and therefore
   this message is always transmitted to the PE which now acts as the
   proxy-RP for that multicast group. Receiving this source specific
   Join message, the PE changes IP multicast distribution to the source
   specific tree because the PE starts acting as proxy-Source from that
   point of time. Note that this multicast tree switch over does not
   cause any additional JOIN SAFI transmission by the PE because the PE
   can already receive IP multicast data and can act as proxy- Source
   without changing the multicast distribution operation over the
   provider core network. In this way, each customer's IP multicast
   domain switches IP multicast tree from shared tee to source specific
   tree independently without affecting the multicast distribution
   within a provider core network and another customer's sites.



3.8. Data MDT operation


   This document proposes to setup Data MDTs in addition to a Default
   MDT when IP multicast transmission over a Default MDT is judged as
   inefficient. The difference from conventional approaches [MCAST-VPN]
   [MVPN-RAGGARWA] is this document assumes that Data MDTs are
   constructed by [P2MP-RSVP]. Therefore, this proposal can construct
   QoS guaranteed and highly reliable Data MDTs which would be better
   for a particular class of IP multicast traffic.




Yasukawa, Karuna, Bandi and Farrel.                            [Page 14]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   This section describes how the proposed solution enables IP multicast
   VPN operation using the Data MDT assuming a VPN customer runs the
   PIM-SM protocol within their network. In this document, we assume two
   kinds of Data MDT construction model; Static configuration model and
   Traffic driven model.


   In the static configuration model, we assume that IP multicast flows
   which are transmitted by Data MDTs are pre-defined and mutually
   agreed by the SP and its customers. This means that multicast group
   addresses assigned for IP multicast flows which use Data MDT are
   pre-defined and configured on each PE's MVRF. Therefore an ingress PE
   which is registered by this multicast group address can setup, modify
   and tear-down an appropriate P2MP TE LSP on demand. When several
   downstream PEs which act as proxy-RP for interconnected customer
   sites detect the existence of receivers which are interested in
   joining a particular multicast distribution by receiving Join
   messages, then the PEs report their interest to join the group by BGP
   using the JOIN SAFI. After receiving these reports, an ingress PE
   establishes a P2MP TE LSP to the egress leaves which have reported
   interest. After this operation, when a new PE uses the BGP JOIN SAFI
   to report to the ingress PE its interest to join the the group, the
   ingress PE initiates Grafting and expands the P2MP TE LSP to reach
   that new PE. When an existing PE detects that no more receivers are
   connected to a customer's site by receiving Prune messages, the PE
   withdraws the corresponding IP multicast registration by using BGP
   withdraw message specifying the corresponding JOIN SAFI.


   Then the ingress PE initiates Pruning and cuts out the unnecessary
   leaf from the P2MP TE LSP. In this way, this proposal can setup,
   modify and tear-down Data MDT on demand basis.


   In the traffic driven model, an ingress PE monitors incoming IP
   multicast data packets and when it detects some data flow exceeds a
   pre-determined threshold, then the ingress PE immediately establishes
   a new P2MP TE LSP to reach the receivers' PEs because the ingress PE
   recognizes which PEs are interested in joining this group via
   BGP. After establishment, the ingress PE switches corresponding IP
   multicast data packets from the Default MDT to the Data MDT. In this
   way, Data MDT based IP multicast transmission is performed on demand
   in this model. After this Data MDT establishment, this model follows
   exactly the same operations as the static configuration model when
   the Data MDT is modified.


   In order to associate the Data MDT with the appropriate MVRF, the
   egress PEs utilize the PE Group-address announced by the PE (which is
   the root of the P2MP TE LSP) via the SA SAFI.






Yasukawa, Karuna, Bandi and Farrel.                            [Page 15]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



3.9. Inter-Site Scaling and Site Interdependencies


   As described in section 3.8, customer sites may be members of the
   same multicast VPN yet operate in near independence. That is, each
   site has its own RP and may choose to use a source-specific tree
   based at the PE, or a shared distribution tree. This choice is
   private to each customer site, and is not communicated to other sites
   (nor would it provide any useful information if it were
   communicated).


   Clearly, also, the number of leaves downstream of an egress PE does
   not affect the way in which the traffic is managed at upstream
   nodes. That is, neither the source site nor the MPLS P2MP TE LSP in
   the SP's network are in any way different if there is one or one
   hundred receivers at a customer site downstream of an egress PE. The
   PE represents a fixed point in the multicast tree that must receive
   data and is an egress of the MPLS P2MP TE LSP.


   For this reason, there is no requirement for the routing protocols to
   report each receiver across the SP network to the ingress site when
   the receivers are added to or removed from the multicast group. All
   that is required is that the egress PE reports (using the BGP JOIN
   SAFI) when the first receiver joins the group so that it becomes a
   leaf on the MPLS P2MP TE LSP, and indicates when the last receiver at
   the site leaves the multicast group so that the PE can be pruned from
   the MPLS P2MP TE LSP. In order to make this optimization each PE must
   count the number of receivers at its site, but since it is acting as
   a proxy-source/RP this is easy for it to do. Such an optimization
   substantially reduces the amount of MP-BGP traffic caused by the VPN
   multicast group and is RECOMMENDED for all implementations.


   Note that an egress PE that makes this optimization may further
   protect itself against flapping membership of a multicast group. In
   the case where the membership may frequently vary between no
   receivers and some receivers an egress PE MAY choose to remain as a
   leaf of the MPLS P2MP TE LSP for some period of time (controllable by
   the operator) even when it has no downstream receivers for the
   multicast traffic. If a local timer expires before any new receivers
   join the group, the PE should use MP-BGP to report that it no longer
   wishes to receive data for the multicast group, and this will result
   in it being pruned from the MPLS P2MP TE LSP tree. Any traffic
   received by a PE for a multicast group for which it has no downstream
   receivers SHOULD be discarded.









Yasukawa, Karuna, Bandi and Farrel.                            [Page 16]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



3.10. Multi-Homing scenario


   The proposed solution provides a very effective fail over mechanism
   in the case where the multicast source/receivers are connected to
   multiple PEs. The PEs which are connected to the customer network
   announce themselves as the RPs via the bootstrap mechanism. When one
   of the PE fails the alternate PE becomes RP for this multicast domain
   and this PE can readily takeover as it is already connected via the
   default MDT.



3.11. Multi-Area/As operation


   This solution can be easily extended to Multi-Area/As operations as
   P2MP TE tunnels can be setup in such scenarios between the PEs. The
   details of this section will be provided in the next revision.



4. IANA Considerations


   [TBD]



5. Security Considerations


  Since this document is based on [RFC2547bis] and [P2MP-RSVP], the
  security considerations involving those drafts apply here as well.



6. Acknowledgements


   We would like to thank Antu Chatterjee and Masaaki TAKAGI for their
   suggestions and contributions to this draft



7. Intellectual Property Considerations


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.







Yasukawa, Karuna, Bandi and Farrel.                            [Page 17]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.



8. Normative References


   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.


   [RFC3667]    Bradner, S., "IETF Rights in Contributions", BCP 78,
                RFC 3667, February 2004.


   [RFC3668]    Bradner, S., Ed., "Intellectual Property Rights in IETF
                Technology", BCP 79, RFC 3668, February 2004.


   [RFC2547bis] Rosen, E., et. al. "BGP/MPLS VPNs",
                draft-ietf-l3vpn-rfc2547bis, work in progress


   [PIM-SM]     B. Fenner, M. Handley, H. Holbrook, I. Kouvelas,
                "Protocol Independent Multicast - Sparse Mode (PIM-SM):
                 Protocol Specification (Revised)",
                draft-ietf-pim-sm-v2-new-08.txt, work in progress.



9. Informational References


   [RFC3446]   D. Kim, D. Meyer, H. Kilmer, D. Farinacci,
               "Anycast Rendevous Point (RP) mechanism using Protocol
               Independent Multicast (PIM) and Multicast Source
               Discovery Protocol (MSDP)", January 2003


   [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
               October 1998.


   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
               Tunnels", RFC 3209, December 2001.




Yasukawa, Karuna, Bandi and Farrel.                            [Page 18]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   [RFC3552]   Rescorla E. and B. Korver, "Guidelines for Writing RFC
               Text on Security Considerations", BCP: 72, RFC 3552,
               July 2003.


   [P2MP-REQ]  S. Yasukawa, et. al., "Requirements for Point to
               Multipoint Traffic Engineered MPLS LSPs",
               draft-ietf-mpls-p2mp-requirement, work in progress.


   [P2MP-RSVP] R. Aggarwal, et. al., "Extensions to RSVP-TE for Point to
               Multipoint TE LSPs", draft-raggarwa-mpls-rsvp-te-p2mp,
               work in progress.


   [MDT-SAFI]  Nalawade and Sreekantiah, "MDT SAFI",
               draft-nalawade-idr-mdt-safi-00.txt, February 2004


   [MCAST-VPN] Y. Cai, E. Rosen, I. Wijnands, "Multicast in BGP/MPLS
               IP VPNs", <draft-rosen-vpn-mcast-07.txt>, May 2004.



   [MVPN-RAGGARWA] R. Aggarwal, "Multicast in BGP/MPLS VPNs and VPLS",
               <draft-raggarwa-l3vpn-mvpn-vpls-mcast-00.txt>,
               February, 2004.


   [MP2MP-TE-MPLS] Work in progress


   [PIM-BSR]   N.Bhaskar, A Gall and Stig Venaas,
               "BootStrap Router(BSR) Mechanism for PIM",
               <draft-ietf-pim-sm-bsr-04.txt>, July 2004.



10. Authors' Addresses


   Seisho Yasukawa
   NTT Corporation
   9-11, Midori-Cho 3-Chome
   Musashino-Shi, Tokyo 180-8585,
   Japan
   Phone: +81 422 59 4769
   Email: yasukawa.seisho@lab.ntt.co.jp


   Shankar Karuna
   Motorola
   Vanenburg IT park, Madhapur,
   Hyderabad, India
   Email: kshankar@motorola.com







Yasukawa, Karuna, Bandi and Farrel.                            [Page 19]


Internet Draft   draft-yasukawa-l3vpn-p2mp-mcast-00.txt     October 2004



   Sarveshwar Bandi
   Motorola
   Vanenburg IT park, Madhapur,
   Hyderabad, India
   Email: sarvesh@motorola.com


   Adrian Farrel
   Old Dog Consulting
   EMail:  adrian@olddog.co.uk



11. Full Copyright Statement


   Copyright (C) The Internet Society (2004). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.




























Yasukawa, Karuna, Bandi and Farrel.                            [Page 20]