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

1
BGP/MPLS IP Multicast VPNs draft-yasukawa-l3vpn-p
2mp-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 customers IP multicast
  traffic distribution using providers 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 customers multicast control and
  forwarding plane in the P-core.
• Distribution of customers multicast routing
  information via providers routing facility.

BGP (IPmcast membership discovery routing info)
PIM adjacency
CE
RP
PE
PIM adjacency
MVRF
P
PE
Source/DR
CE
C-IPmcast network
MVRF
PIM adjacency
PE
CE
Receiver
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
  customers 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
  providers 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 customers IP
  multicast data stream. The providers 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
  customers 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
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
CE1
CE2
PE2
PE1
Receiver
P
Receiver
Receiver
PE4
PE3
P-MPLS network
CE4
CE3
Receiver
Receiver
Receiver
Receiver
7
Default MDT creation
DR
PE1
CE
PE2

MP-BGP(MDT-SAFIRD, PE1, p-G1)
MP-BGP(MDT-SAFIRD, PE2, p-G2)
Path
Default P2MP LSP to MVRF mapping
Resv
Path
Default P2MP LSP to MVRF mapping
Resv
8
PIM-SM operation example
DR
PE1
CE
PE2

Register message
Register stop message
MP-BGP(SA-SAFIRD, PE1, p-G,c-S,c-G)
Register message
Register stop message
Join(, G)
Join(, G)
MP-BGP(Join-SAFIRD, 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
DR
PE1
CE
PE2

Join(S, G)
MP-BGP(Join-SAFIRD, 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-SAFIRD, 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 customers IP multicast
  distribution.
• - Monitor VPN customers 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 WGs 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