1 / 35

Multicast in BGP/MPLS VPNs draft-to-become-l3vpn-2547bis-mcast-00.txt

Multicast in BGP/MPLS VPNs draft-to-become-l3vpn-2547bis-mcast-00.txt. Eric Rosen (erosen@cisco.com) Rahul Aggarwal (rahul@juniper.net). Other Authors/Contributors. Co-Authors Yiqun Cai, IJsbrands Wijnands, Yakov Rekhter, Thomas Morin Contributors/Acknowledgements

ggarland
Télécharger la présentation

Multicast in BGP/MPLS VPNs draft-to-become-l3vpn-2547bis-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. Multicast in BGP/MPLS VPNsdraft-to-become-l3vpn-2547bis-mcast-00.txt Eric Rosen (erosen@cisco.com) Rahul Aggarwal (rahul@juniper.net)

  2. Other Authors/Contributors • Co-Authors • Yiqun Cai, IJsbrands Wijnands, Yakov Rekhter, Thomas Morin • Contributors/Acknowledgements • Arjen Boers, Toerless Eckert, Luyuan Fang, Dino Farinacci, Lenny Guiliano, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony Speakman, Dan Tappan, Authors of draft-yasukawa-l3vpn-p2mp-mcast-00.txt

  3. Agenda • Design Objective • Overview of the MVPN Architecture • MVPN Auto-Discovery • MVPN Routing Information Exchange • I-PMSI Instantiation • S-PMSI Instantiation • Inter-AS Procedures • Co-locating C-RP on the PE • Encapsulation

  4. Multicast Support for 2547 VPN: components • Control plane: exchanging VPN multicast routing information: • Between CE and PE • Among PEs • Data plane: forwarding VPN multicast traffic within the service provider(s) Very similar to the unicast support for 2547 VPNs

  5. A given customer (multicast) packet should traverse a given service provider link at most once Deliver customer multicast traffic to only PEs that have (customer) receivers for that traffic Deliver customer multicast traffic along the “optimal” paths within the service provider (from the ingress PE to the egress PEs) Design Objectives for multicast support in 2547 VPN service (not a complete list) Optimize Bandwidth: Optimize State: • The amount of state within the service provider network required to support Multicast in 2547 VPN service should be no greater than what is required to support unicast in 2547 VPN service • The overhead of maintaining the state to support Multicast in 2547 VPN service should be no greater than what is required to support unicast in 2547 VPN service Optimizing Bandwidth and State are conflicting goals

  6. Agenda • Design Objective • Overview of the MVPN Architecture • MVPN Auto-Discovery • MVPN Routing Information Exchange • I-PMSI Instantiation • S-PMSI Instantiation • Inter-AS Procedures • Co-locating C-RP on the PE • Encapsulation

  7. MVPN ArchitectureControl Plane • MVPN Auto-Discovery • Allows discovering MVPN membership information using BGP • Elimination of overhead of PIM Hellos • MVPN Routing Information Exchange among PEs • Preserves the ability to use existing PIM machinery • Allows reliable exchange of VPN Multicast Routing Information • PIM refresh reduction or BGP • Control traffic doesn’t necessarily use the tunnels used by the data traffic • Similar to 2547 unicast architecture • Allows unicast PIM or BGP

  8. MVPN ArchitectureData Plane Tree = PIM-SM, PIM-SSM, PIM-Bidir, RSVP-TE P2MP LSPs, Receiver Initiated P2MP LSPs Separate Tree per-set-of C-(S, G)s “Selective Mapping” Separate Tree per-set-of MVPNs “Inclusive Mapping” Ingress Replication Separate Tree for Every C-(S, G) Aggregate State State = Unicast 2547bis Unbounded State Increasing P-router state and Bandwidth efficiency Decreasing P-router state and Bandwidth efficiency

  9. New Framework and Terminology • Prior proposals differ in following ways: • multicast service expected from SP network • method of implementing the multicast service • method of exchanging multicast routing info • One size doesn’t fit all, so need way of describing various options • Distinguish multicast service from implementation • Clarify relation between routing info exchange and multicast data transport service • Clarify inter-relationships of various options

  10. P-Multicast Service Interface • PMSI: Provider-network Multicast Service Interface • Service is scoped to one MVPN • Three types: • MI-PMSI: Multipoint Inclusive, all→all • all PEs can transmit to all PEs • UI-PMSI: Unidirectional Inclusive, some→all • Unidirectional, selected PEs can transmit to selected PEs • Selective: S-PMSI, some→some • Unidirectional, selected PEs can transmit to selected PEs

  11. Instantiating PMSIs • PMSIs instantiated by tunnels. Possible tunnels: • PIM-created trees (any flavor) • Point-to-Multipoint LSPs • Unicast tunnels: • from ingress to all egresses, with ingress replication • to root of distribution tree • PMSI instantiation may require set of tunnels • Single tunnel may instantiate more than one PMSI • Encaps a function of tunnel, not service

  12. Mappings to Old Terminology • Default MDT • MI-PMSI, instantiated by PIM Shared Tree or set of PIM Source Trees • Data MDT • S-PMSI, instantiated by PIM Source Tree • New terminology helpful in: • Describing the complete set of options • Allowing multiple instantiations of same service, without changing service spec

  13. Tunnel Issues • Applicability of each technique? • One size doesn’t fit all • MPLS vs. GRE vs. MPLS-in-GRE vs. … • Source-initiated or receiver-initiated creation • Options for creating and destroying the tunnels: • As part of the discovery phase • As separate phase after discovery • As needed (depending on traffic characteristics) • Ensuring interoperability? • Force common tunnel choice?

  14. Agenda • Design Objective • Overview of the MVPN Architecture • MVPN Auto-Discovery • MVPN Routing Information Exchange • I-PMSI Instantiation • S-PMSI Instantiation • Inter-AS Procedures • Co-locating C-RP on the PE • Encapsulation

  15. Discovery • What MVPN multicast-specific info needs to be known before MVPN service can be set up: • What PMSIs are going to be used: • Will MVPN routing information be unicast or multicast • Do we want to have the service available before it is needed • What tunnels are to be used to instantiate the PMSIs: • What information is needed to set up the tunnels and identify the tunnels • What encapsulation is going to be used • Is aggregation supported

  16. Agenda • Design Objective • Overview of the MVPN Architecture • MVPN Auto-Discovery • MVPN Routing Information Exchange • I-PMSI Instantiation • S-PMSI Instantiation • Inter-AS Procedures • Co-locating C-RP on the PE • Encapsulation

  17. Exchange of VPN Multicast Routing Info Among PEs • Only two possibilities considered: • PIM • BGP

  18. Exchange of VPN Multicast Routing Info Among PEs: PIM • C-Join/Prune messages can be either: • Multicast (requires MI-PMSI) • Unicast (from one PE to one PE) • N.B.: Unicast is different from MI-PMSI over unicast tunnels • Can use full or lightweight adjacency

  19. Using PIM… • Lightweight adjacencies • Minimizes overhead by eliminating periodic messages: • Refresh reduction (to be spec’ed by PIM WG) • Hello suppression (in L3VPN, BGP provides the necessary information) • Not interoperable with full adjacencies • Finding the RPF in inter-AS MVPNs

  20. Using PIM • Control Messages: Multicast or Unicast • MI-PMSI: Allows Asserts, Join Suppression, standard “PIM on a LAN” • Unicast: no join suppression, no asserts • Various Pros and Cons to each • Unicast presupposes that all PEs must choose same PE as RPF hop for given C-S

  21. MVPN Routing Information ExchangeUsing BGP VPN A Site 4 PE 4 CE-A4 VPN A Site 1 CE -A1 PE 2 VRF-A VPN B Site 3 CE-B3 VRF-A PIM C-Join C-S, C-G VRF-A VRF-B PE 1 C-S -> C-G VRF-A VRF-B RR CE-A3 VPN B Site 1 CE-B1 VPN A Site 3 VRF-B PE 3 CE-B2 PEs have I-BGP Peering Only With the RR CE-A2 VPN B Site 2 VPN A Site 2 BGP MVPN Routing Information Update: <RD, C-S, C-G, Originator PE – PE1 Upstream PE – PE2, RT>

  22. Agenda • Design Objective • Overview of the MVPN Architecture • MVPN Auto-Discovery • MVPN Routing Information Exchange • I-PMSI Instantiation • S-PMSI Instantiation • Inter-AS Procedures • Co-locating C-RP on the PE • Encapsulation

  23. I-PMSI Instantiation • UI-PMSI or MI-PMSI • Ingress Replication • P-Multicast Trees • No architectural limitations on the tree building protocol • Current spec limits specific procedures to PIM-SM, PIM-SSM, PIM-Bidir, RSVP-TE P2MP LSPs • Source Based Trees or Shared Trees • Aggregation • Tunnel Identifier (Usage Described Later) • <Session, Sender Template> for RSVP-TE P2MP LSPs • <P-S, P-G> for PIM-SSM

  24. PMSI InstantiationIngress Replication Ingress Replication – Flooding (S-PMSI Recommended) VPN A Site 4 PE 4 CE-A4 VPN A Site 1 CE -A1 PE 2 VRF-A VPN B Site 3 CE-B3 VRF-A PIM C-Join C-S, C-G VRF-A VRF-B PE 1 C-S -> C-G VRF-A VRF-B RR CE-A3 VPN B Site 1 CE-B1 VPN A Site 3 VRF-B PE 3 CE-B2 MVPN Membership Discovery: <Ingress Replication Capability, Downstream MPLS Label> eg PE1 CE-A2 VPN B Site 2 VPN A Site 2 MVPN Rtng Information – Unicast PIM or BGP

  25. Aggregate P-Multicast Trees • Allow one P-multicast Tree to be shared across multiple VPNs • Can be setup using PIM-SM or PIM-SSM or P2MP MPLS TE • Support for PIM-Bidir is for further study • Requires a MPLS label to demultiplex a particular VPN • ‘Upstream’ label allocation by the root of the tree • Egress PEs maintain a separate label space for each P-multicast tree root • State grows less than linearly with number of MVPNs • Some efficiency of multicast routing may be sacrificed

  26. I-PMSI InstantiationP-Multicast Trees VPN A Site 4 PE 4 CE-A4 VPN A Site 1 CE -A1 PE 2 VRF-A VPN B Site 3 CE-B3 VRF-A PIM C-Join C-S, C-G VRF-A VRF-B PE 1 C-S -> C-G VRF-A VRF-B RR CE-A3 VPN B Site 1 CE-B1 VPN A Site 3 VRF-B PE 3 CE-B2 MVPN Membership Discovery: <Aggregation Capability> eg PE1 CE-A2 VPN B Site 2 VPN A Site 2 Aggregate Tree – PE2 as Root BGP Signaled MVPN – Tree Binding: <RD, Root PE, Upstream Label, RT, Tree Identifier>

  27. Agenda • Design Objective • Overview of the MVPN Architecture • MVPN Auto-Discovery • MVPN Routing Information Exchange • I-PMSI Instantiation • S-PMSI Instantiation • Inter-AS Procedures • Co-locating C-RP on the PE • Encapsulation

  28. S-PMSI Instantiation • Separate tree for set of <C-S, C-G>s that may belong to different MVPNs • Increase bandwidth efficiency for the mapped <C-S, C-G>s. • Eg. High Bandwidth Streams • Discover the leaves i.e. PEs with receivers in <C-S, C-G>s using MVPN Routing Information • For RSVP-TE P2MP LSPs or/and Aggregation • Unicast PIM or BGP or MI-PMSI with Join Suppression off • Ingress Replication or P-Multicast Trees • Protocol for switching to S-PMSI • BGP or UDP

  29. S-PMSI InstantiationP-Multicast Trees – BGP Signaling PIM C-Join C-S1, C-G1 VPN A Site 4 PE 4 CE-A4 C-S2 -> C-G2 VPN A Site 1 CE -A1 PE 2 VRF-A VPN B Site 3 CE-B3 VRF-A PIM C-Join C-S2, C-G2 VRF-A VRF-B PE 1 C-S1 -> C-G1 VRF-A VRF-B RR CE-A3 VPN B Site 1 CE-B1 VPN A Site 3 VRF-B PE 3 CE-B2 Leaf Discovery – MVPN Routing Exchange Eg. BGP CE-A2 VPN B Site 2 VPN A Site 2 Selective Aggregate Tree – PE2 as Root BGP Signaled set of <C-S, C-G> – Tree Binding: <RD, Root PE, C-S, C-G, Upstream Label, RT, Tree Identifier>

  30. S-PMSIs – UDP Signaling • If an MI-PMSI is in use for flow’s MVPN, can use “in-band” protocol, i.e., UDP-based protocol identifying flow and S-PMSI • Existing protocol may benefit from some enhancements: • Reduce soft state overhead • Ability to identify non-PIM tunnels

  31. Inter-AS Procedures • First Model – Tunnel spans multiple ASs • Support for Unicast VPN Option A, B and C • “RPF Attribute” to get around Next-Hop Rewrite in Option B • PIM Extension to carry the proxy address when PIM P-Multicast Trees are used and P routers don’t have the route to the ingress PE • Second Model – Each AS can have its own tunneling mechanism for intra-AS tunnels • Overlay Inter-AS tunnel on top of the intra-AS tunnels • Build on BGP MVPN Auto-discovery and BGP MVPN-Tunnel Binding • Support for Unicast VPN Option A, B and C

  32. Inter-AS ProceduresSecond Model – Overlay Inter-AS Tunnel • MVPN membership spanning tree rooted at the origin AS, with other ASs as nodes of the tree • The overlay tunnel traverses this spanning tree • Origin AS announces that it has a MVPN to other ASs – not the PEs that belong to the MVPN • Each AS node on the spanning tree has its own intra-AS tunnel • MVPN-tunnel binding flows towards the root of the overlay tree using BGP – essentially MPLS label switching at the ASBRs • Support for S-PMSIs

  33. Co-locating C-RP on a PE • One potential deployment model • Customer may outsource C-RP to the SP and the SP may co-locate the C-RP with the PE • Two options: • 1. Anycast RP based on (*, G) advertisements that PE receives from CEs • This is similar to the model in draft-yasukawa-l3vpn-mvpn-p2mp-00.txt • 2. Anycast RP based on propagating active source announcements in BGP • This is the model in draft-yasukawa-l3vpn-mvpn-p2mp-00.txt

  34. Encapsulation • When multiple PMSIs are aggregated into a single tunnel, how to demux the packets • Unicast Tunnels: • MPLS Label (downstream-assigned) • Don’t want separate IP dest addr per PE per MVPN • Multicast Tunnels: • MPLS Label (upstream-assigned) • When PIM messages are unicast: • MPLS downstream-assigned label • RD (or RT) in PIM message • Ensuring agreement (among PEs) on encaps

  35. Conclusion • Comments ? • Request to be a WG document • Request authors of draft-yasukawa-l3vpn-mvpn-p2mp to join the draft

More Related