Transcript PPT Version
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) 61st IETF Washington DC November 2004 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 Pcore – 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 – 61st IETF Washington DC November 2004 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 Pcore. Distribution of customer’s multicast routing information via provider’s routing facility. BGP (IPmcast membership discovery & routing info) PE PIM adjacency Source/DR CE C-IPmcast network PE P PIM adjacency MVRF C-IPmcast network MVRF P2MP TE based MDT Provider IP/MPLS network RP CE PE PIM adjacency CE Receiver MVRF 61st IETF Washington DC November 2004 C-IPmcast network 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 Source/DR Receiver Proxy-RP CE Receiver P PE Provider IP/MPLS network Receiver PE Independent PIM network Proxy-Source/RP Receiver CE PE 61st IETF Washington DC November 2004 Receiver 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) | | | +----------------------------------+ | RD (8 octets) | | PE's IPv4 address | +----------------------------------+ | (4 octets) | | PE's IPv4 address | +----------------------------------+ | (4 octets) | | Provider's Group-address | +----------------------------------+ | (4 octets) | |Customer's Source-address| +----------------------------------+ | (4 octets) | |Customer's Source-address| +----------------------------------+ | (4 octets) | | Customer's Group-address| +----------------------------------+ | (4 octets) | |Customer's Group-address | +----------------------------------+ | (4 octets) | +----------------------------------+ 61st IETF Washington DC November 2004 PIM-SM operation example Configuring MVRFs on PE triggers exchange of MDT-SAFI information Interested receivers send their joins to the PEs (the RP for this site) Default MDT: Each PE sets up P2MP tunnel to other PEs of the same VPN Source PIM register message CE#1 Register stop message Source specific Join message MP-BGP(MDT-SAFI) MP-BGP(JOIN-SAFI) (SA-SAFI) MP-BGP PE#1 MVRF P CE#2 PE#2 MVRF Receiver Receiver Receiver PE#4 PE#3 CE#3 Receiver MVRF P-MPLS network MVRF CE#4 Receiver 61st IETF Washington DC November 2004 Join(*,G) Join(S,G) Receiver Receiver Default MDT creation DR PE1 PE2 MP-BGP(MDT-SAFI[RD, PE1, p-G1]) MP-BGP(MDT-SAFI[RD, PE2, p-G2]) Path Resv Default P2MP LSP to MVRF mapping Default P2MP LSP to MVRF mapping Path Resv 61st IETF Washington DC November 2004 CE PIM-SM operation example DR PE1 Register message Register stop message CE PE2 MP-BGP(SA-SAFI[RD, PE1, p-G,c-S,c-G]) Register message Register stop message Join(*, G) Source-specific Join IP Mcast Data (S,G) Join(*, G) MP-BGP(Join-SAFI[RD, PE2, c-S,c-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 Resv IP Mcast Data (S,G) over Data MDT Data P2MP LSP to MVRF mapping IP Mcast Data (S,G) 61st IETF Washington DC November 2004 PIM-SSM operation example DR PE1 Join(S, G) MP-BGP(Join-SAFI[RD, PE2, c-S,c-G]) Join(S,G) IP Mcast Data (S,G) CE PE2 IP Mcast Data (S,G) over Default MDT IP Mcast Data (S,G) Switch to Data P2MP Ingress PE can figure out interested receiver PEs MP-BGP(SA-SAFI[RD, PE1, p-G’,c-S,c-G]) Path Data P2MP LSP to MVRF mapping Resv IP Mcast Data (S,G) over Data MDT IP Mcast Data (S,G) 61st IETF Washington DC November 2004 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. 61st IETF Washington DC November 2004 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. 61st IETF Washington DC November 2004 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 61st IETF Washington DC November 2004