IP Multicast VPN Solution Framework for QoS Guarantees

1. BGP/MPLS IP Multicast VPNsdraft-yasukawa-l3vpn-p2mp-mcast-00.txt Seisho Yasukawa (NTT) Shankar Karuna (Motorola) Sarveshwar Bandi (Motorola) Adrian Farrel (Old Dog)

2. Motivations • Establish a solution framework for IP Multicast VPNs which can provide QoS guarantees and reliable IP multicast services while giving the SP enough network operation & management capabilities. • Focus is multicast VPN not multicast VPLS • Scalable architecture • Avoid overhead of PIM adjacency maintenance in or across the P-core • Avoid suboptimal IP multicast distribution • Shortest paths • Within P-core • Across entire customer network • Replication as late as possible • Avoid data tree switch-over (shared to source-based) over P-core • Easy & flexible operation • Control and manage VPN customer’s IP multicast traffic distribution using provider’s facilities. • Introduce QoS guarantees & TE (Explicit route indication, FRR etc) capabilities

3. Basic network model • Adopt BGP/IP MPLS VPNs network model. • Each CE is a multicast routing (PIM) adjacency of an attached PE router. • Already use BGP for VPN membership discovery • Extend BGP use for exchange of IP multicast routing information • Establish P2MP TE based MDTs to forward IP multicast data over P-core. • Preserve two important features • Separation of customer’s multicast control and forwarding plane in the P-core. • Distribution of customer’s multicast routing information via provider’s routing facility. BGP (IPmcast membership discovery & routing info) PIM adjacency PE RP CE PIM adjacency MVRF P PE Source/DR CE C-IPmcast network MVRF PIM adjacency PE Receiver CE C-IPmcast network P2MP TE based MDT MVRF Provider IP/MPLS network C-IPmcast network

4. Proxy-Source/RP model • All PEs which are members of a VPN act as proxy-Source/RPs. • Each PE which acts as proxy-Source/RP terminates customer’s PIM messages, this enables independent PIM network operation within each customer site. • P2MP TE based MDT interconnects PEs so that each downstream PE can receive IP multicast data via the MDT. • Note that the P-core connectivity is a separate issue • It is possible to use any tunneling transport over the P-core (e.g. P2P MPLS TE, GRE) • P2MP MPLS TE is an optimization in the P-core Independent PIM network Proxy-Source/RP CE Independent PIM network Receiver Proxy-RP P Source/DR CE Receiver PE Independent PIM network Proxy-Source/RP PE Receiver Receiver CE PE Provider IP/MPLS network Receiver

5. Exchanging IP multicast register information • Use MDT-SAFI to discover PEs of same VPN. The provider’s group address advertised in this SAFI is used to map the default MDT to a VPN • Introduce Source Active (SA) SAFI to announce the activation of a particular customer’s IP multicast data stream. The provider’s group address advertised in this SAFI is used to map a data MDT to a VPN • Introduce JOIN SAFI to announce the interest of a particular PE to join/prune a particular customer’s IP multicast data stream. SA SAFI JOIN 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) | +----------------------------------+ +---------------------------------+ | | | RD (8 octets) | +----------------------------------+ | PE's IPv4 address | | (4 octets) | +----------------------------------+ |Customer's Source-address| | (4 octets) | +----------------------------------+ | Customer's Group-address| | (4 octets) | +----------------------------------+

6. MP-BGP (JOIN-SAFI) MP-BGP (SA-SAFI) Source specific Join message Register stop message PIM register message MP-BGP(MDT-SAFI) MVRF MVRF MVRF MVRF Join(S,G) Join(*,G) PIM-SM operation example Interested receivers send their joins to the PEs (the RP for this site) Configuring MVRFs on PE triggers exchange of MDT-SAFI information Default MDT: Each PE sets up P2MP tunnel to other PEs of the same VPN Source CE#1 CE#2 PE#2 PE#1 Receiver P Receiver Receiver PE#4 PE#3 P-MPLS network CE#4 CE#3 Receiver Receiver Receiver Receiver

7. Default MDT creation CE DR PE1 PE2 MP-BGP(MDT-SAFI[RD, PE1, p-G1]) MP-BGP(MDT-SAFI[RD, PE2, p-G2]) Path Default P2MP LSP to MVRF mapping Resv Path Default P2MP LSP to MVRF mapping Resv

8. PIM-SM operation example CE DR PE1 PE2 Register message Register stop message MP-BGP(SA-SAFI[RD, PE1, p-G,c-S,c-G]) Register message Register stop message Join(*, G) Join(*, G) MP-BGP(Join-SAFI[RD, PE2, c-S,c-G]) Source-specific Join IP Mcast Data (S,G) IP Mcast Data (S,G) over Default MDT IP Mcast Data (S,G) Switch to Data P2MP (set P2MP with p-G announced in SA-SAFI) Path Data P2MP LSP to MVRF mapping Resv IP Mcast Data (S,G) over Data MDT IP Mcast Data (S,G)

9. PIM-SSM operation example CE DR PE1 PE2 Join(S, G) MP-BGP(Join-SAFI[RD, PE2, c-S,c-G]) Join(S,G) IP Mcast Data (S,G) IP Mcast Data (S,G) over Default MDT IP Mcast Data (S,G) Switch to Data P2MP MP-BGP(SA-SAFI[RD, PE1, p-G’,c-S,c-G]) Path Data P2MP LSP to MVRF mapping Resv Ingress PE can figure out interested receiver PEs IP Mcast Data (S,G) over Data MDT IP Mcast Data (S,G)

10. Characteristics • Can support PIM-SM/PIM-SSM with same model. • Support Data-MDT - SA SAFI sends Data-MDT information - After ingress PE receives JOIN SAFIs, the PE can establish Data-MDT dynamically to interested PEs. - That is, add receivers to P2MP TE LSP • Support Multiple topologies of MDT. - P2MP tree - MP2MP tree (Needs stitching P2P LSPs with a P2MP LSP) - Support for other tunnel technologies (e.g. GRE) • Supports Multi-AS operation • Supports same RD operation as unicast rfc2547bis. Enforce policy operation by RT. • SP can manage/monitor VPN customer’s IP multicast distribution. - Monitor VPN customer’s Mcast distribution by RR - Control Mcast traffic distribution pattern within a core by P2MP TE. • Enable stable & scalable operation - Tree transition (Shared tree to source specific tree) - Transition does not propagate across the provider core.

11. OPEN issues • Applicability to PIM-DM and PIM-BIDIR. • Optimize Default/Data P2MP tree operation - Number of Default P2MP trees can be reduced. - A lot of combinations exist when multiple Mcast flows share Default/Data P2MP tree. - Possibility to introduce further aggregation • Details of protection mechanism for multi-homing. • Details of multi-provider operation.

12. Next steps • Revise the draft to resolve open issues. • Need WG’s input for polishing up this solution especially in following areas. - Is P2MP TE MPLS applicable to MVPN? - Agreement to introduce Proxy-Source/RP method to enhance scalability and manageability of Multicast IP VPNs. • Offer these mechanisms as input to the development of a future Multicast IP VPN solution • Cooperate with other solution teams to • Find common ground • Develop a single solution for the WG