Network Working Group                             Hong-Ke Zhang
INTERNET-DRAFT                                    Chun-Yue Zhou
Expiration Date: April 2006                       Bing-Yi Zhang
                                     Beijing Jiaotong University
                                                  En-Hui Liu
                                                  Spencer Dawkins
                                                  Hui  Liu
                                     Huawei Technologies Co.,Ltd.

                                                  October 2005


           Multicast in Virtual Router-based IP VPNs 


              <draft-zhang-l3vpn-vr-mcast-02.txt>



Status of this Memo

   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.


Abstract

   This document specifies the procedures required to be implemented 
   for IP multicast traffic to travel from one VPN site to another 
   within a Virtual Router-based IP VPN [VR-VPN]. It details the 
   solution according to process in local customer sites and in SP 
   backbone networks.


                                                                                                         
Hong-Ke Zhang, et al.        Expires April 2006               [Page 1]                                 
                                                                                                         
                                                                                                        
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005                                 
                                                                                                         
   
   This document is based on Requirements for Multicast in L3 
   Provider-Provisioned VPNs [MREQT] and specification of Network-based
   IP VPN Architecture using Virtual Routers that have been implemented 
   and deployed.


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 [KEYWORDS].


Table of Contents

    1      Introduction................................................2
    2      VR Deployment Scenarios.....................................3
    3      Proxy Source/RP and SPT Solution............................3
    3.1    Multicast Source Routing Table in VR .......................3 
    3.2    Multicast Routing in Local VPN Sites .......................3 
    3.3    Routing in SP Networks......................................4
    3.4    Multicast Data Receiving in Local Site......................5 
    4      Multicast Based on Unicast Tunnel...........................5
    4.1    Virtual Leaf Router Concept.................................6
    4.2.   Group Control Message ......................................6
    4.3    Group-VR State Table........................................7
    4.4    Multicast Forwarding........................................8
    5      Encapsulation...............................................9
    6      Scalability Considerations.................................10
    7      Security Considerations....................................11
    8      Acknowledgments............................................11
    9      Normative References.......................................11
    10     Informative References.....................................11
    11     Authors' Addresses.........................................11
    12     Intellectual Property Statement............................12




1. Introduction

   [MREQT] describes Requirements for Multicast in L3 
   provider-provisioned VPNs. [VR-VPN] specifies a network based IP VPN 
   architecture using Virtual Routers (denoted as VR-VPN) which have 
   been implemented and deployed by some vendors and service providers. 
   Based on them, this document specifies the procedures required to be 
   implemented for IP multicast traffic to travel from one VPN site to 
   another within a VR-VPN. It details the solutions according to 
   process in local sites and SP networks. 
   
                                                                              
Hong-Ke Zhang, et al.        Expires April 2006               [Page 2]        
                                                                              
                                                                             
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005      
                                                                              
   
   Two solutions are proposed in this document. One is based on the
   Proxy Source/RP [P2MP] and Shortest Path Tree is set up for backbone 
   transportation. It is detailedly described in former version of this 
   draft. Another solution is based on unicast tunnel mechanism. Virtual 
   Leaf Router concept is proposed and Group Control Message is 
   introduced to optimize the multicast in local site and across 
   backbone.
   
   
2. VR Deployment Scenarios

   In VR-VPNs, VPN customer sites access to service provider backbone 
   via the connection between Customer Edge(CE) and Virtual Router(VR). 
   CE can connect to VR via any access link, then forwards all 
   non-local service to VR. VRs belonging to the same VPN domain must 
   discover VPN membership and distribute reachability information. 
   There can exist multiple VRs on one Provider Edge(PE) device.

   Prior to support of VPN multicast, unicast VR VPN scenario should be
   established. It is required to select appropriate PE for customer 
   sites, distribute identifier for VPN, and configure VR on 
   correlative PE. The membership discovery of VRs belonging to the same
   VPN domain can be achieved through server query, explicit 
   configuration or auto-discovery method. Then tunnels (IP- or MPLS- 
   based) are set up to make connections between VRs. Finally the 
   routing protocol running on each VR disseminates VPN reachability 
   information through tunnels to other VRs. At this time VR VPN is set
   up for data transmission. The mechanism for doing these is detailed
   in [VR-VPN]. 
   

3  Proxy Source/RP and SPT Solution

   
3.1 Multicast Source Routing Table in VR

   In this solution, in order to decide whether there exists multicast 
   requirements from local VPN sites, every VR should store a multicast
   source routing table constructed by reachability information 
   distributed by VRs. This table records reachability information of 
   every multicast source S which the VR is interested in. The entry is
   (S, VR).


3.2 Multicast Routing in Local VPN Sites 

   It is necessary to deploy multicast routing protocols in local VPN 
   sites, CEs and PEs. All multicast routing protocols with the 
   
                                                                           
Hong-Ke Zhang, et al.        Expires April 2006               [Page 3]     
                                                                           
                                                                          
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005   
                                                                              

   mechanism of Join and Prune can be used. However, this document only
   considers the use of PIM-based protocols, including PIM-SM, PIM-SSM,
   PIM-DM or PIM-Bidir. In this solution, each VR becomes a PIM 
   adjacency of the CE connected, but CEs at different sites do not 
   become PIM adjacencies of each other, and VRs in the same PE do not
   become PIM adjacencies to each other, either.

   Every VR in a VR-VPN acts as a proxy Source/RP [P2MP] for its 
   connected VPN sites. The proxy Source/RP connects to the multicast 
   source in the VPN directly or via CEs. Since each VR acts as a 
   proxy-Source/RP in its VPN for its connected VPN sites, an 
   independent multicast tree can be formed within a customer site 
   regardless of multicast trees conformation within other sites.

   From the view of SP, the Proxy Source/RP is the proxy of all 
   multicast sources within a local VPN site. From the view of a VPN 
   site, the Proxy Source/RP is the RP of all multicast trees within 
   the local VPN site, i.e. all route states such as (C-Source,C-Group) 
   and (*,C-Group) assemble to RP via PIM Join/Prune messages. Here, 
   a C-Source address is a multicast source address in the local VPN 
   site, and a C-group address is a multicast group address in a VPN's 
   address space. 

   Acting as the Proxy Source means that VR must be the egress of all 
   multicast traffic to remote sites. Acting as the RP means that all 
   multicast sources within the VPN sites must register to VR, and VR 
   must be the ingress of all multicast traffic from remote sites. 


3.3 Routing in SP Networks

   First we define that Source-VR is a VR connected to a customer VPN 
   site which has multicast sources. According to VPN membership and 
   reachability information, Shortest Path Trees (SPT) can be 
   constructed between VRs in a VR-VPN, which are rooted at every 
   Source-VR and addressed on P-Group address space. A SPT tree 
   (Source-VR, P-Group) can be setup using PIM-based protocols or 
   MPLS P2MP tunnel. All multicast traffic from a Source-VR to 
   other VRs share the tree (Source-VR ,P-Group) in the SP network.
   Here, a P-Group address is a multicast group address in a SP's 
   address space, which represents all other VRs required to receive 
   the multicast traffic from a Source-VR.
 
   When there is a Source-VR acting as a Proxy Source/RP of a customer 
   site to receive multicast packets from the site, it encapsulates 
   the packets, and the traffic will be sent to all VRs acting as leaf 
   nodes in the same VPN along the Shortest Path Tree.

                                                                    
Hong-Ke Zhang, et al.        Expires April 2006               [Page 4]     
                                                                           
                                                                          
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005   
                                                                           

3.4 Multicast Data Receiving in Local Site

   After a VR acting as a leaf node has received the first packet from 
   Source-VR, it extracts basic information (Source-VR address and 
   P-Group address) in encapsulated packets, then decides whether 
   it has multicast requirement from the Source-VR. If there is no 
   multicast receiver in the local VPN sites it served, the VR discards 
   multicast packets and prunes from multicast tree (Source-VR, P-Group)
   to reject traffic from this Source-VR. A leaf VR which has been 
   pruned from trees should store the (Source-VR, P-Group)state. As 
   soon as a local site connecting to the pruned leaf VR needs again to
   receive any C-Source traffic proxied by the Source-VR, the pruned 
   leaf VR should explicitly join the tree once more, then receive 
   multicast packets from the Source-VR.

   Every VR acting as leaf nodes repeats these operations, thus 
   multicast packets from a Source-VR are forwarded only to those VRs 
   which require to receive multicast traffic from the Source-VR. 
   Every VR can be source (i.e. root) or receiver (i.e. leaf) of 
   a shortest path tree, and different trees are identified by 
   (Source-VR, P-Group).

   From the above-mentioned, the processing of multicast trees and 
   packets between VRs in a VPN is driven by multicast receiving 
   requirements of leaf VRs from a C-source, but independent 
   of local state of (C-source, C-Group). Only after multicast 
   traffic from Source-VR reach leaf VRs through the tree, leaf 
   VRs decide whether to discard or forward multicast packets 
   to local C-Group according to local (C-Source,C-Group) state.


4  Multicast Based on Unicast Tunnel

   One important characteristic of VR VPN is that it realizes better 
   traffic isolation between different VPNs, which can be used in the
   case where security is highly demanded. Besides, this VPN 
   architecture has no requirement on control and transport mechanism. 
   Unicast tunnel for multicast enhances the security characteristic 
   because it does not require SP backbone maintain multicast state of
   VPN.

   Broadcast replication between VRs is feasible when multicast load 
   is low. But if multicast traffic between the VRs is high, it is 
   necessary to make choice to send only to VRs with multicast demand.
   In order to avoid unnecessary traffic in local sites and across the    
   backbone, Virtual Leaf Router concept and Group Control Message        
   mechanism are introduced in this solution.                                  
 
                                                                         
Hong-Ke Zhang, et al.        Expires April 2006               [Page 5]      
                                                                            
                                                                           
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005    
                                                                            
 
4.1 Virtual Leaf Router Concept

   Regardless of the interaction  with the remote sites, the multicast
   processing in VPN customer site has no difference with normal 
   Internet multicasting. Any PIM instance could be deployed.
  
   When considering sending multicast traffic to the backbone, VR at 
   the customer side acts as a "leaf router". All remote group receiver
   and the backbone is thought as  a "LAN" connected to the "leaf 
   router". The Virtual Leaf Router has no difference with normal 
   multicast leaf router, with only exception than the backbone behind
   it is treated as a virtual "LAN". 
   
   In order not to pull multicast traffic down to VR and across 
   backbone when no receiver exists in remote site, the VR "Leaf 
   Router" should collect group membership of the "LAN". If there 
   exists remote group receiver, VR will maintain the state for it, 
   just as a normal router does after receiving a group report. The 
   leaf router participates the local multicast in a normal way. It 
   according to the group state from the "LAN" sends PIM Join or Prune
   messages in local domain. When a local source begins to send traffic
   to this group, VR "Leaf Router" will pull traffic to itself and 
   relay the traffic to the remote group receiver.  
   

4.2 Group Control Message 

   In section 5.1.1, VR as a leaf router just does the same thing as a 
   normal leaf router. It receives IGMP Report message from remote VRs, 
   which is referred to Group Control Message.
   
   This could be achieved with two different methods. For instance, the
   remote VR could resolve this information from periodic PIM 
   Join/Prune received from its internal nodes of the site. Or the 
   router in the remote sites, as it receives IGMP report message from
   its links, is required to make a copy of the message to its VR. 
   
   The second method may alter the behaviour of the routers a little 
   but has the advantage of low group delay and can be applied to any 
   PIM Protocol in local site. The first method does not affected the 
   operation of local sites, but it doesn't work well in PIM-DM 
   scenario. 
   
   When PIM-SM or PIM-BIDIR is running in local sites, all PIM 
   Join/Prunes are aggregated to RP in the protocol manner. Then it is
   possible to make configuration on RP to forward all the PIM (*,G) 
   and (S,G) Join/Prune message to VR. VR will learn from these messages
   which group or which source-specific group exists in local site. If 
 
                                                                         
Hong-Ke Zhang, et al.        Expires April 2006               [Page 6]      
                                                                            
                                                                           
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005    
                                                                            
    
   the message shows a joining or leaving for a group, VR will generate
   a IGMP report message to be encapsulated and tunneled to remote VR 
   or VRs. In this case, only RP is required to relay PIM Join/Prune 
   message. Delay is introduced, for RP is in a transitional position 
   and VR should wait for a period of time to make full decision. The 
   second method could also be adopted here.
   
   When PIM-SSM is running, the group report will be for specific 
   source. If the source is not in local site, the (S,G) Join/Leave will
   be unicasted to VR, who knows which VR in the remote end with this 
   source attached to it. The first method is easily realized then and
   group delay is low compared to PIM-SM and PIM-BIDIR. The second 
   method could also be adopted here.
   
   When PIM-DM is running, the first method is difficult to deploy, for 
   without multicast traffic for a group sent to leaf router, no join or 
   prune will be originated. So it is impossible for VR to know in 
   advance the group state of the local sites. The only possible way is
   to adopt the second method. 
   
   Once group membership states trigger on VR, they are immediately 
   sent in IGMP message format to other related VRs, across the 
   backbone. Utilization of this Group Control Message has three 
   advantages. First, it is possible to introduce low latency as a 
   remote receiver dynamically joins or leaves a group. Secondly, once
   received by VR, the "IGMP" message be delivered to the virtual "Leaf
   router", being incorporated well into the virtual "LAN" backbone 
   mechanism. Thirdly, the message conveys only the IP group 
   information and make no requirements of multicast protocol type for
   the two remote sites. Finally, the Group Control Message is in solid
   state and does not change so frequently as PIM Join/Prune messages.  
   
   In this solution, Group Control Message should be transmitted 
   encapsulated in unicast tunnel. But Group Control Method is not 
   restricted only to unicast tunnel. It is possible to carry the Group
   Control Message in any other form of control mechanism, such as BGP 
   protocol. And further, it is can even deployed in BGP/MPLS VPN model.
   It realized efficient control over multicast forwarding between VPN 
   sites.
   

4.3 Group-VR State Table
   
   To avoid unnecessary replication, VR in the ingress should be aware 
   which remote VR has actual receiver in its site. Thus VR in ingress
   should maintain group states from remote VRs, referred to as
   group-VR state table. When VR receives local multicast packets, it 
   decides according to the group-VR table to choose to send to a 
 
                                                                         
Hong-Ke Zhang, et al.        Expires April 2006               [Page 7]      
                                                                            
                                                                           
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005    
                                                                            
   subset of VRs. Thus VRs without active members will not receive
   the traffic. 
 
   The Group-VR state table is recorded in each VR. VR refers to it 
   before transmitting. The table is constructed from the Group Control
   Message delivered by remote sites and changes dynamically as the 
   remote receiver joins and leaves a group. There are two types of 
   entry,(*,G)VR and (S,G)VR, respectively standing for normal group 
   and source specific group. 

   If a remote receiver joins in a (*,G) group, and there is no other
   receiver belongs to this group, group control information is tunneled
   by its VR (i.g. VR1) to every other VRs across the backbone. Other 
   VRs will record this (*,G)-VR1 relation for this VPN. Usually multiple
   remote VRs may have members for the same group. Then the (*,G) state
   may link to multiple VRs, i.g. denoted as (*,G)-VR1-VR2-VR3.
   
   When PIM-SSM is used in local site, (S,G)Join should be initiated. 
   In this case, only VR attached to S needs this group information. 
   And (S,G)-VR1 entry should be maintained on this VR. And multiple VRs 
   can be corresponded to a source-specific receiving, which can be 
   denoted as (S,G)-VR1-VR2-VR3.
   
   The group-VR table on a VR is used in unicast tunnel multicast model.
   When local source delivers multicast traffic for remote receivers, 
   it helps to eliminate unnecessary data transferring. The group states
   for local member need not be kept in the table.
  
   Because VR knows in advance the group information of other VRs 
   before transmitting. Other VRs will not receive traffic they don't 
   like, which implement some efficiency in backbone transfer.
   
4.4 Multicast Forwarding
   
   With the mechanism mentioned above, it is easy to make multicast 
   forwarding in local sites. First, without remote senders or receivers
   for this site, the multicast process is exactly same as normal case.
   The Virtual Leaf Router behaves just like a normal router without any
   group member on it. No traffic will flow to VR and the backbone.
   If there exist remote receivers, the remote VR will inform this 
   Virtual Leaf Router by Group Control Message. If a local source is 
   sending traffic to that group, the multicast data will travel down
   to this VR Leaf Router. And the VR will relay them to backbone.
   
   If a remote source is sending, and there is local receiver for this
   group, VR will retrieve multicast data from backbone, and simply 
   send them to Local site.
   
   Thus optimization is realized in local site: If no receiving require 
   exists from remote sites, no traffic will flow to the VR on PE. And 
   in backbone, VRs with no traffic will not receive unnecessary packets.

                                                                                                                     
Hong-Ke Zhang, et al.        Expires April 2006               [Page 8]                                               
                                                                                                                     
                                                                                                                    
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005                                             
                                                                                                                     

5  Encapsulation

   The multicast VR-VPNs uses the same encapsulation methods as listed
   in [MVPN-7]. These also apply to the MPLS-in-IP and MPLS-in-GRE 
   encapsulation methods.


5.1 Encapsulation in GRE

   GRE encapsulation can be used when forwarding multicast traffic 
   through SP network. The IP Protocol Number field in the IP Header 
   and the Protocol Type field of the GRE Header follows [MVPN-7].
   The following diagram shows the progression of the packet as it 
   enters and leaves the service provider network.


   Packets received        Packets in transit      Packets forwarded
   at ingress VR           in the service          by egress VRs
                           provider network

   ++=============++       ++=============++       ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++       ++=============++       ++=============++
                           |      GRE      |     
                           +---------------+
                           |  P-IP Header  |
                           +---------------+


5.2 Encapsulation in IP

   IP-in-IP encapsulation can also be used. The parameter about IP 
   Protocol Number field follows [MVPN-7]. The following diagram shows 
   the progression of the packet as it enters and leaves the service
   provider network.

   Packets received        Packets in transit      Packets forwarded
   at ingress VR           in the service          by egress VRs
                           provider network

   ++=============++       ++=============++       ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++       ++=============++       ++=============++
                           |  P-IP Header  |
                           +---------------+

                                                                                                                     
Hong-Ke Zhang, et al.        Expires April 2006               [Page 9]                                               
                                                                                                                     
                                                                                                                    
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005                                             
                                                                                                                     




5.3 Encapsulation in MPLS

   If the P routers in SP networks support MPLS and extended RSVP 
   protocol, MPLS encapsulation can be used. The multicast distribution
   trees can be constructed by P2MP MPLS LSP mechanism, and additional 
   MPLS encapsulation procedures are used, as specified in 
   [RSVP-TE-P2MP].


   Packets received        Packets in transit      Packets forwarded
   at ingress VR           in the service          by egress VRs
                           provider network

   ++=============++       ++=============++       ++=============++
   || C-Payload   ||       || C-Payload   ||       || C-Payload   ||
   ++=============++ >>>>> ++=============++ >>>>> ++=============++
   || C-IP Header ||       || C-IP Header ||       || C-IP Header ||
   ++=============++       ++=============++       ++=============++
                           | P-MPLS Header |
                           +---------------+


5.4 Interoperability

   In a VR-VPN, all Virtual Routers in the VPN must agree on the method 
   of encapsulation. It can be achieved either by configuration or 
   by means of some discovery protocols. Here, GRE encapsulation is 
   suggested to be used due to its simple and lower payload.


6  Scalability Considerations

   The first solution based on Proxy Source/RP initiates SPT tree in 
   backbone. The SPT is set up on a per-VR basis. The number of trees
   rooted on VRs is relatively static. The P-Group address can be 
   configured by administrator or auto-selected in certain range.
   Thus the number of trees (Source-VR, P-Group) in SP networks will 
   neither exceed the number of VRs nor change with the number of 
   customers, the number of C-Source and C-Group, or the topology of 
   local trees (C-Source, C-Group) in local sites. So it not only 
   reduces payload on SP networks effectively but also improves 
   scalability.
   
 
                                                                         
Hong-Ke Zhang, et al.        Expires April 2006               [Page 10]      
                                                                            
                                                                           
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005    
                                                                            
 
7. Security Considerations

   Security considerations discussed in [VR-VPN] apply to this document.
   From a route deployment standpoint, the isolation between different 
   VPNs is crucial. In this solution, processing in SP network will be
   implemented in those VRs belonging to the same VPN. It can get good
   isolation performance because every VPN has private multicast address
   space. If only the whole system isolates VRs in the same PE reliably,
   the security will reach an acceptable level.


8. Acknowledgment

   We would like to thank Quan-Lin Li, Yue Zhang, Shuai Gao and 
   Ya-juan Qin for their valuable comments and suggestions on 
   this document.


9. Normative References

   [PPVPN-TERM]  "Provider Provisioned VPN terminology", L. Anderssoo, 
               T. Madsen, September 2004, 
               draft-ietf-l3vpn-ppvpn-terminology-04


10. Informative References

   [MREQT]    "Requirements for Multicast in L3 Provider-Provisioned
              VPNs", T. Morin, Ed. ,France Telecom R&D, February 2005,
              draft-ietf-l3vpn-ppvpn-mcast-reqts-00.txt
   [VR-VPN]   "Network based IP VPN Architecture using Virtual Routers", 
              Paul Knight, Hamid Ould-Brahim, Bryan Gleeson, 
              April 2004, draft-ietf-l3vpn-vpn-vr-02.txt 
   [MVPN-7]   "Multicast in MPLS/BGP VPNs", E. Rosen. et. al., May 2004
              draft-rosen-vpn-mcast-07.txt
   [P2MP]     "BGP/MPLS IP Multicast VPNs", Seisho Yasukawa et. al., 
              October 2004, draft-yasukawa-l3vpn-p2mp-mcast-00.txt


11. Authors' Addresses

   Hong-Ke Zhang
   IP lab, Beijing JiaoTong Univ.
   Beijing, China, 100044
   Tel: +86-10-51685677 
   Email: hkzhang@center.njtu.edu.cn

                                                                         
Hong-Ke Zhang, et al.        Expires April 2006               [Page 11]      
                                                                            
                                                                           
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005    

                                                                            
   Chun-Yue Zhou, Bing-Yi Zhang
   IP lab, Beijing JiaoTong Univ.
   Beijing, China, 100044
   Email: zhouchunyue@hotmail.com
          bingyizhang@hotmail.com

   En-Hui LIU
   Huawei Technologies Co., Ltd.
   Beijing, China, 100085
   Tel: +86-10-82882495
   Fax: +86-10-82882537
   Email: LEH10814@huawei.com

   Spencer Dawkins
   Huawei Technologies Co., Ltd.
   TX, USA, 75075
   Email: sdawkins@futurewei.com
   
   Hui Liu
   Huawei Technologies Co., Ltd.
   Beijing, China, 100085
   Tel: +86-10-82882233
   Fax: +86-10-82882770
   Email: Liuhui47967@huawei.com


12. Intellectual Property Statement

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

                                                                          
Hong-Ke Zhang, et al.        Expires April 2006               [Page 12]      
                                                                            
                                                                           
Internet Draft   Multicast in Virtual Router-based IP VPNs  October 2005    
                                                                            
 
Full Copyright Notice

   Copyright (C) The Internet Society (2005).  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.






                                                                                                                 
Hong-Ke Zhang, et al.        Expires April 2006               [Page 13]