1 / 12

BGP/MPLS IP Multicast VPNs draft-yasukawa-l3vpn-p2mp-mcast-00.txt

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

chinue
Download Presentation

BGP/MPLS IP Multicast VPNs draft-yasukawa-l3vpn-p2mp-mcast-00.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related