61st IETF Washington DC November 2004

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

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

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 P-core.– Distribution of customer’s multicast routing information via provider’s routing facility.

Source/DR CE

CE RP

CE Receiver

PPE C-IPmcastnetwork

C-IPmcastnetwork

C-IPmcastnetwork

Provider IP/MPLS network

PIM adjacency

MVRF

MVRF

MVRF

PIM adjacency

PIM adjacency

BGP (IPmcast membership discovery & routing info)

P2MP TE based MDT

PE

PE

61st IETF Washington DC November 2004

Source/DR CE

CE

CE Receiver

Proxy-Source/RP

PProxy-RP

Proxy-Source/RP

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 th

e 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

Provider IP/MPLS network

PE

PE

PE

Receiver

Receiver

Receiver

Receiver

Independent PIM network

Independent PIM network

61st IETF Washington DC November 2004

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.

+---------------------------------+ | | | 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) | +----------------------------------+

SA SAFI JOIN SAFI

61st IETF Washington DC November 2004

Source CE#1 CE#2

CE#4

Receiver

P

PE#1

P-MPLSnetworkCE#3

ReceiverReceiver

Receiver

ReceiverReceiver Receiver

PE#2

PE#3 PE#4

MVRF MVRF

MVRFMVRF

PIM-SM operation example

MP-BGP(MDT-SAFI)

PIM register message MP-BGP (SA-SAFI)

Register stop message

Join(*,G)

MP-BGP (JOIN-SAFI)

Source specific Join message

Join(S,G)

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

Interested receivers send their joins to the PEs (the RP for this site)

61st IETF Washington DC November 2004

Default MDT creation

DR PE1 PE2 CE

MP-BGP(MDT-SAFI[RD, PE1, p-G1])

PathResv

Default P2MP LSPto MVRF mapping

MP-BGP(MDT-SAFI[RD, PE2, p-G2])

PathResv

Default P2MP LSPto MVRF mapping

61st IETF Washington DC November 2004

PIM-SM operation example

DR PE1 PE2 CE

Register message

MP-BGP(SA-SAFI[RD, PE1, p-G,c-S,c-G])

Join(*, G)MP-BGP(Join-SAFI[RD, PE2, c-S,c-G])

Source-specific Join

Register stop message

Register messageRegister stop message

Join(*, G)

IP Mcast Data (S,G) IP Mcast Data (S,G) over Default MDT IP Mcast Data (S,G)

Switch toData P2MP (set P2MP with p-G

announced in SA-SAFI)

PathResv

Data P2MP LSPto MVRF mapping

IP Mcast Data (S,G) over Data MDT IP Mcast Data (S,G)

61st IETF Washington DC November 2004

PIM-SSM operation example

DR PE1 PE2 CE

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 toData P2MP

MP-BGP(SA-SAFI[RD, PE1, p-G’,c-S,c-G])PathResv

Data P2MP LSPto MVRF mapping

IP Mcast Data (S,G) over Data MDT IP Mcast Data (S,G)

Ingress PE can figureout interested receiver PEs

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 groundDevelop a single solution for the WG