1 / 33

Softwire Mesh Multicast

Softwire Mesh Multicast. Mingwei Xu, CERNET, China Yong Cui, CERNET, China Chris Metz, Cisco 70 th IETF Meeting, Vancouver Dec. 2007. Native IPv6 CERNET2 in China. Review softwire mcast problem. Why we need Softwire Multicast? Existing multicast applications are in IPv4

teryl
Download Presentation

Softwire Mesh Multicast

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. Softwire Mesh Multicast Mingwei Xu, CERNET, China Yong Cui, CERNET, China Chris Metz, Cisco 70th IETF Meeting, Vancouver Dec. 2007

  2. Native IPv6 CERNET2 in China

  3. Review softwire mcast problem • Why we need Softwire Multicast? • Existing multicast applications are in IPv4 • Native IPv6 CERNET2 core supports IPv6 multicast protocols • Setup/Extend IPv4 multicast tree across IPv6 core • Forward IPv4 multicast traffic across IPv6 core

  4. Review achievement after IETF69 • Multicast draft is updated • New candidate solutions are proposed • PIM-SSM IPv6 Transitions • RPF-Vector-Based Address Translation

  5. Softwire Mesh Multicast Framework • 1:1 Mapping (Internet Multicast Model) • PIM in the Core • PIM-SSM IPv6 Transitions • RPF-Vector-Based Address Translation • MPLS/mLDP in the Core • “mVPN-like” • I-IP core multicast state scales less than linearly with E-IP client multicast state • AFBR routers act like PE routers supporting one VPN • Techniques outlined in L3VPN Multicast docs

  6. Advantage of PIM-SSM • PIM-SSM • Single source multicast • Address Allocation • Makes each source independently responsible for resolving address collisions. • Access Control • This makes it much harder to "spam" an SSM channel than an ASM multicast group • Handling of well-known sources • SSM requires only source-based Forwarding trees, making it viable for immediate deployment

  7. Scenario & Terminology E-IP: The network address family of customer network. I-IP: The network address family of the transit core. PE: Provider edge router, which supports the address family of both I-IP and E-IP. Upstream PE: The PE router located at the upstream of multicast data flow, which connects the transit core and the customer network the source S belongs to. Downstream PE: The PE router located at the downstream of multicast data flow, which connects the transit core and the customer network containing a group member.

  8. Procedure on Downstream PE PEs receive Join/Prune message from CEs. Upstream PE judge whether the (S,G) tree has been constructed or not . If the multicast tree has been mapping, PE adds the address of CE into the management of multicast group membership Calculating the corresponding address and sending a Join message.

  9. 1. Receiving a PIM Join Message CE send join to PE1 EB::1A Join(11.1.1.2; 232.0.0.1)

  10. 2. Check existing mgroup Join(11.1.1.2; 232.0.0.1) PE1 judge whether this tree has been constructed or not EB::1A Join(11.1.1.2; 232.0.0.1)

  11. 3. If the tree has already existed PE just need to add theaddress of CE into the management of multicast group membership DR EB::1A Join(11.1.1.2; 232.0.0.1)

  12. 4. Translate join message into core Send generated Join message (S’,G’) and the (S,G) by attribute field Join(EB::1A； FF3x::8f00:1) with11.1.1.2; 232.0.0.1) EB::1A

  13. 4. Join Message A new source encoding type: (draft-ietf-pim-join-attributes-03) 0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Addr Family | Encoding Type | Rsrvd |S|W|R| Mask Len |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Source Address (Encoded-Source format) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|F|S| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....|F|S| Type | Length | Value+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....Type: 0, The source address of customer network 1, The multicast group address of customer network Value: Source Address (Encoded-Source format) Group Address (Encoded-Group format) IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are currently designated as source-specific multicast (SSM) For IPv6, the address prefix FF3x::/32 is reserved for SSM use When the scenario is 4over6, we choose the FF3X::8f00:0/24 to be the prefix of the multicast address for the 232/8.

  14. Procedure on Upstream PE • The upstream PE judge whether the (S,G) tree has been constructed or not. • If the tree has been constructed before, the downstream PE keep the common state and add multicast members in the table • PE sends an E-IP PIM Join message to the source S

  15. 1. Check existing mgroup on upstream PE Join(EB::1A； FF3x::8f00:1) with11.1.1.2; 232.0.0.1) Join(11.1.1.2; 232.0.0.1) The upstream PE judge whether the (S,G) tree has been constructedor not.

  16. 2. Adds multicast members Join(EB::1A； FF3x::8f00:1) with11.1.1.2; 232.0.0.1) The downstream PE need to keep the common state and add multicast members in the table

  17. 3. Sends an E-IP PIM Join message Join(EB::1A； FF3x::8f00:1) with11.1.1.2; 232.0.0.1) Join(11.1.1.2; 232.0.0.1) sends an E-IP PIM Join/Prune message to the source S S

  18. Possible MTree in Core Join(EB::1A； FF3x::8f00:1) with11.1.1.2; 232.0.0.1)

  19. Summary of PIM-SSM Transition • Advantage • IPv4 & IPv6 • Support both 4over6 or 6over4 • Path optimization • Each multicast group in customer networks has a corresponding I-IP PIM-SSM in the transit core • Disadvantage • The state information storage needed is proportional to the numbers of multicast trees passing through the routers • Status • I-D complete and will be submitted soon

  20. RPF-Vector-Based Address Translation • PIM-SM Unicast Messages • Register and C-RP-adv • Use softwire unicast mechansim • PIM-SM Multicast Messages to ALL-PIM-ROUTERS • Register-Stop • Use RVAT mechansim • Hello • Suspending • Join/Prune • Use RVAT mechansim • Bootstrap • Use softwire unicast mechansim

  21. JOIN(*,G)—DR Calculating RP for G DR calculates RP => 59.66.76.215

  22. JOIN(*,G)—Forwarding JOIN IPv4 dest: 224.0.0.13 Upstream Neighor 59.66.74.211 Join(*, 226.0.0.13) 59.66.74.211

  23. JOIN(*,G)—Forwarding JOIN (*,G’) IPv6 dest: FF02::D Upstream Neighor P Join(*, FF18:226.0.0.13) Vector EA::22

  24. JOIN(*,G)—Forwarding JOIN (*,G’) IPv6 dest: FF02::D Upstream Neighor EA::22 Join(*, FF18:226.0.0.13) Vector EA::22

  25. JOIN(*,G)-- Forwarding JOIN (*,G’) IPv6 dest: FF02::D Upstream Neighor PE3 VIF Join(*, FF18:226.0.0.13) Vector EA::22

  26. JOIN(*,G)—JOIN (*,G’) Decap. IPv4 dest: 224.0.0.13 Upstream Neighor 59.66.76.218 Join(*, 226.0.0.13) 59.66.76.218

  27. JOIN(*,G)—JOIN (*,G) Forwarding IPv4 dest: 224.0.0.13 Upstream Neighor 59.66.76.215 Join(*, 226.0.0.13)

  28. JOIN(*,G)—JOIN (*,G) Reaching RP IPv4 dest: 224.0.0.13 Upstream Neighor :NUll Join(*, 226.0.0.13)

  29. How to Fill an RPF-VECTOR IPv6Prefix + IPv4Prefix =96+24=120 AddreFamily +EncodingType +UnicastAddr =8+8+128=144 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family| Encoding Type | Rsrvd |S|W|R| Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Source Address (Encoded-Source format) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|S| Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+… |F|S| Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+… 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 0 | 0 |1 |1 |1 | 120 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | encoded format for ( ::FFFF:59.66.76.215) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+… |1 |1 | 0 | 144 | eccoded format for (EA::22) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+…

  30. Summary for RPF-Vector-Based Address Translation • Advantages • Virtually the same as PIM-SM • IPv6 multicast tree is part of the IPv4 tree • Simple , incremental and light-weighted • Disadvantages • Only available in 4over6 scenario • Status • I-D complete and will be submitted soon

  31. Any new requirement? • Unicast core? • Some old routers in the core may not support multicast • We need to forward multicast packet from one edge to the other by unicast encap. • Dual-stack source • Both IPv4 receiver and IPv6 receiver

  32. Multicast framework • Main content in mcast framework • Detail the requirement • Restrict the problem in mesh mcast • Leverage existing solutions • Describe the framework for new candidate solutions • Status of mcast framework • Mainly complete as an informational draft • Revision/comments/collaboration are welcome • Request to be a WG document

  33. Multicast solutions • 1:1 Mapping (mcast core) • PIM in the Core • RPF-Vector-Based Address Translation • PIM-SSM IPv6 Transitions • MPLS/mLDP in the Core • “mVPN-like” (mcast core) • Leverage L3VPN solutions • Unicast core • Leverage any existing solutions or propose new ones

More Related