Transcript PPT Version

MVPN Revisited
draft-mnapierala-mvpn-rev-00
IETF 68 March 2007
Maria Napierala
March 22 2007
IETF 68, L3VPN WG
1
Summary of the Proposal
• C-source is discovered based on 1st C-S packet received
on C-shared tree (PIM-SM) and on 1st (C-S, C-G) Join
(PIM-SSM)
• PIM-SM C-trees are (by default) automatically triggered
as SPTs by all egress PEs but there is no inter-PE RPTto-SPT switchover initiated by C-routers
• If a source C-S is reachable via several PEs,
downstream PE will choose its BGP best installed route
to reach C-S. If multiple next-hops are installed the tie
breaker is either highest IP address which is the default
RFP selection method*
• PE joins only those tunnels that were announced by its
best next hop to C-S
• Initial C-S traffic is dropped until the S-PMSI or UI-PMSI
is built
* Or could be based on per multicast state load splitting but there is no standard method
March 22 2007
IETF 68, L3VPN WG
2
New Additions
•
•
•
•
To be added in the next version (-01) of the draft
Support of C-Shared Trees
Support of C-Bidir Trees
Support of Anycast C-RPs
March 22 2007
IETF 68, L3VPN WG
3
Main Requirements
• Multicast routing in VRF should follow its unicast routing
policy
• Downstream PE should join only those tunnels that were
announced by its best next hop to C-S or C-RP
– a tunnel to be used for C-S should not be created either before Csource is discovered or after the source sends traffic natively on
(C-S,C-G) state
• RPF neighbor (upstream PE) for C-S should be unique
per set of VRFs with the same unicast routing policy
towards the C-S
– RPF neighbor selection should not include not installed BGP
routes because this might alter the expected traffic flows in MVPN
• Support of multiple RPF neighbors for Anycast C-RP is
required
March 22 2007
IETF 68, L3VPN WG
4
Main Differences from Other Proposal
• C-Multicast Routing:
– Point-to-point based not LAN-based RPF neighbor
selection (no DR or DR-like election procedure)
– RPF neighbor selection includes only BGP installed
routes
– RPF neighbor is unique to set of VRFs with the same
unicast routing policy
– PE joins only those tunnels that were announced by its
best next hop to C-S or C-RP
– PIM-like support of Anycast C-RPs: any downstream
PE on a single C-RPT to closest C-RP
• C-Source Discovery
– does not require PEs to participate in C-RP source
discovery process
– different Source Discovery for PIM-SSM and PIM-SM
March 22 2007
IETF 68, L3VPN WG
5
Source Discovery in MVPN
• Proposed solution consists in ASM-like C-source
discovery technique and results in the
simplification of inter-PE multicast traffic patterns
• ASM C-source discovery process is “intercepted”
by PE’s in order to extract C-source information
• Active C-sources become known in MVPN
negligibly later than they would in plain ASM
March 22 2007
IETF 68, L3VPN WG
6
Bypassing Shared Trees in MVPN
• Knowledge about active sources is used to
eliminate inter-PE shared tree (RPT) to shortest
path tree (SPT) switchover and to simplify PE-toPE inter-site multicast routing
– there are no inter-PE (C-S,C-G,rtp) Prune
messages
• In order to eliminate inter-site RPT-to-SPT
switchover, PIM control procedures in MVPN
context need to be modified. Those
modifications are straightforward
• Proposed modifications of PE-to-PE multicast
routing do not require changes to PIM protocol
in the customer domain
March 22 2007
IETF 68, L3VPN WG
7
Source Discovery Techniques
• Two source discovery techniques are defined,
one for PIM-SM and one for PIM-SSM
• Active source C-S is discovered in MVPN when:
(PIM-SM): PE attached to C-RP receives the first
(C-*, C-G) packet from C-S
(PIM-SSM): PE attached to C-S receives the first
(C-S, C-G) join, either from directly connected
CE or from another PE in MVPN
March 22 2007
IETF 68, L3VPN WG
8
Source Discovery in PIM-SM – 1
• When C-RP receives PIM Register from C-S, it extracts
from it multicast data packet and sends it over the shared
(C-*, C-G) tree
• PE attached to C-RP “snoops” for a packet received on
(C-*,C-G) and extract from it C-source address - this is no
different from the last hop router extracting source address
from the first packet it receives on shared tree in plain ASM
procedure
• When PE attached to C-RP receives the 1st multicast
packet from the source C-S over (C-*,C- G) tree it sends
(C-S, C-G, rpt) Prune towards C-RP and announces the
active source C-S to all PE’s in the MVPN
• PE attached to C-RP does not forward (C-*, C-G) traffic on
the interface leading to SP’s core network
March 22 2007
IETF 68, L3VPN WG
9
Source Discovery in PIM-SM – 2
• Upon receiving active C-S announcement message:
– PE’s connected to C-S send tunnel announcements for
(C-S, C-G)
– PE’s connected to receivers of C-G (i.e., egress PE’s)
convert (C-*, C-G) PIM Join/Prune messages received
from locally attached CE’s to (C-S, C-G) PIM Join/Prune
for all active sources C-S. Each egress PE will send (CS, C-G) join to its best next-hop to C-S
• Any PE with (C-*, C-G) or (C-S, C-G) state that receives
tunnel announcement for (C-S, C-G) with join the tunnel
announced by its best next hop to C-S
March 22 2007
IETF 68, L3VPN WG
10
Source Discovery in PIM-SM – 3
C-Source Becomes Inactive
• When C-S stops sending traffic (C-S, C-G) state
expires on PE’s attached to C-S
• PE’s attached to C-S sent source withdrawal
message for (C-S, C-G)
• Egress PE’s stop joining tunnels announced for
(C-S, C-G) and remove source and tunnel
information
March 22 2007
IETF 68, L3VPN WG
11
Source Discovery in PIM-SM – 4
Dually Homed C-Receivers
• There could be scenario where a dually homed
MVPN site with receiver(s) chooses a different nexthop PE depending on whether a shared (C-*,C-G)
tree or source (C-S,C-G) tree is joined. In means
that shared and source trees diverge at this site
• Egress PE on the C-RPT will receive (C-S,C-G,rtp)
Prune message from its directly connected CE
• Egress PE on the C-RPT will prune itself off (C-S, CG)-tree and the tunnel for (C-S,C-G) if there are no
receivers for (C-*,G) or (S,G) attached to it
• Egress PE on C-SPT will join the tunnel for (C-S,CG) if it was not joined yet
March 22 2007
IETF 68, L3VPN WG
12
Supporting Shared Trees
• MVPN customer might require to never switch
to SPT’s for a particular C-G. The information of
such C-groups has to be known to SP and has
to be made known to PE’s with this MVPN
• A PE attached to a C-RP for C-G will be the root
of the tunnel for all sources sending to C-G
March 22 2007
IETF 68, L3VPN WG
13
Supporting Shared Trees – 1
• PE attached to C-RP, upon receiving (C-*, C-G) PIM Join
from another PE, follows normal ASM procedure
• When PE attached to C-RP receives 1st multicast packet
over (C-*, C-G) tree (from any C-S), this PE forwards it to
its OIL for (C-*, C-G) and announces the active group C-G
and tunnel to be used for C-G traffic to all PE’s in the
MVPN:
– if MI-PMSI exists then the initial (C-*, C-G) packets could be sent
over this tunnel (more on this on slide 18)
– if MI-PSMI does not exist and since UI-PMSI or S-PMSI tunnel for
C-G is not built yet, the initial (C-*, C-G) packets sent to the
interface leading to SP’s core network will be dropped
• PE’s attached to receivers of C-G upon receiving the C-G
announcement will join the tunnel announced by the best
next hop to C-RP for C-G
March 22 2007
IETF 68, L3VPN WG
14
Supporting Shared Trees – 2
• (C-S, C-G) Joins/Prunes received from any site
other than the site with C-RP for C-G will be
dropped at PEs
• PE attached to C-S upon receiving 1st (C-S, C-G)
Join (from C-RP) announces the tunnel to be
used for (C-S, C-G) traffic
• PE’s attached to C-RP joins this tunnel
March 22 2007
IETF 68, L3VPN WG
15
Source Discovery for PIM-SM – Summary
• All (C-*, C-G) data traffic between PE’s is blocked and
inter-PE RPT to SPT multicast traffic switching is
eliminated
• Inter-PE (S,G,rpt) Prunes messages are eliminated
• Regardless of whether or not the traffic in C-network
switched to SPT’s, PE-to-PE MVPN traffic is sent only
on SPT’s
• All traffic to C-G can be kept on a shared tree if
required
March 22 2007
IETF 68, L3VPN WG
16
Source Discovery in PIM-SSM
• PE attached to C-S, upon receiving 1st (C-S, C-G) Join
from another PE or from a locally attached site,
announces tunnel for (C-S, C-G) traffic
• Upon receiving tunnel announcement a PE connected to
receiver(s) of (C-S, C-G) joins the tunnel announced by
its best next hop to C-S
• When C-S stops sending traffic then (C-S, C-G) expires
on PE’s attached to C-S and those PE’s sent tunnel
withdrawal message for (C-S, C-G)
• Egress PE’s stop joining tunnels announced for (C-S, CG) and (all PE’s) remove the tunnel information
March 22 2007
IETF 68, L3VPN WG
17
Choices for Handling Initial Packets Sent
over C-RPT
•
•
•
C-multicast traffic is dropped until S-PMSI is built
C-multicast traffic is dropped until UI-PMSI is built. UI-PMSI
should be announced during MVPN discovery and built upon
receiving C-S active announcement message. The UI-PMSI
and S-PMSI are rooted at the same ingress PE and hence
there will no traffic shifts in the SP network when traffic is
switched from UI-PMSI to S-PMSI
Traffic from C-S is not dropped but sent on MI-PMSI,
announced and built during MVPN discovery, until S-PMSI for
C-S tunnel is announced and built
– since the root of MI-PMSI might be different than the root of SPMSI, the C-S traffic might shift between two different tunnels
– if PIM-on-LAN procedure is used for C-multicast routing the
Assert process will force the same single forwarder for entire
MVPN. Hence, with PIM-on-LAN the initial C-RPT traffic cannot
be sent over MI-PMSI
 Since the initial traffic even if sent could be meaningless to
receivers, there is no advantage in using MI-PMSI for C-traffic
March 22 2007
IETF 68, L3VPN WG
18
Handling Multiple Equal Cost Paths to
C-S/C-RP
• If there are multiple next-hops to C-S or to dynamic C-RP
installed by BGP in VRF, PE with the highest IP address is
chosen as the next hop*
• If there are multiple next-hops to static C-RP installed by
BGP in VRF, the closest PE (based on SP network IGP
cost) is chosen as a next hop and only as a tie breaker the
PE with the highest IP address
• IGP cost-based next-hop selection provides PIM-like
support of Anycast C-RP’s: C-receivers join the closest
Anycast C-RP across SP network
– PE cannot distinguish multiple next hops to C-RP due to different
Anycast C-RPs or due to static/Anycast C-RP being dually homed
with equal-cost. Hence, closest distance-based next hop selection
could trigger more tunnels in SP network
*Or per multicast state load splitting could be but it is not standardized
March 22 2007
IETF 68, L3VPN WG
19
Supporting Anycast C-RPs
Static/Anycast C-RP can be supported in one of
following ways:
1. Using IGP cost in the best route selection to
static C-RP (default static C-RP selection)
2. Tie breaker is always the highest IP address
but VPN uses different unicast routing
policies to reach different Anycast-RP’s
serving C-G. This allows MVPN customer to
define its Anycast C-RP selection
March 22 2007
IETF 68, L3VPN WG
20
Supporting C-Bidir – 1
• PIM Bidir chooses single Designated Forwarder
(DF) for upstream packets (away from the source)
on every network segment and point-to-point link
– the DF election procedure eliminates parallel downstream
paths from any RP
• Two options of supporting C-Bidir Trees
– all VRFs of the same VPN have to have the same unicast
routing policy; the best next hop to C-RP is chosen as a
DF for C-RP’s bidirectional groups (tie breaker is the
highest IP address)
– a group of VRFs with the same unicast routing policy
uses unique (across MVPN) C-RP(s) with unique (across
MVPN) bidirectional groups
March 22 2007
IETF 68, L3VPN WG
21
Supporting C-Bidir – 2
• Designated Forwarder PE upon receiving
(C-*,C-G) Join from another PE announces the
tunnel to be used for C-G traffic
– for scalability, C-Bidir traffic should use MP2MP
tunnels in SP network (build with PIM Bidir or with
MP2MP LSPs)
• If Designated Forwarder PE prunes interface
leading to SP core network from its OIL for
(C-*, C-G) (i.e., all remote PEs pruned
themselves off (C-*, C-G) tree), this PE
announces the tunnel withdrawal for C-G
March 22 2007
IETF 68, L3VPN WG
22
Additional Requirements
• Discovery of multipoint-to-multipoint/few
applications (will be added to next version of the draft)
• Tunnel aggregation – receiver tracking
• Support of C-BSR and C-Auto-RP
– still require default MI-PMSI
– based on refresh mechanism (every 60 sec)
March 22 2007
IETF 68, L3VPN WG
23