330 likes | 594 Views
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
E N D
Softwire Mesh Multicast Mingwei Xu, CERNET, China Yong Cui, CERNET, China Chris Metz, Cisco 70th IETF Meeting, Vancouver Dec. 2007
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
Review achievement after IETF69 • Multicast draft is updated • New candidate solutions are proposed • PIM-SSM IPv6 Transitions • RPF-Vector-Based Address Translation
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
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
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.
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.
1. Receiving a PIM Join Message CE send join to PE1 EB::1A Join(11.1.1.2; 232.0.0.1)
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)
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)
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
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.
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
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.
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
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
Possible MTree in Core Join(EB::1A; FF3x::8f00:1) with11.1.1.2; 232.0.0.1)
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
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
JOIN(*,G)—DR Calculating RP for G DR calculates RP => 59.66.76.215
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
JOIN(*,G)—Forwarding JOIN (*,G’) IPv6 dest: FF02::D Upstream Neighor P Join(*, FF18:226.0.0.13) Vector EA::22
JOIN(*,G)—Forwarding JOIN (*,G’) IPv6 dest: FF02::D Upstream Neighor EA::22 Join(*, FF18:226.0.0.13) Vector EA::22
JOIN(*,G)-- Forwarding JOIN (*,G’) IPv6 dest: FF02::D Upstream Neighor PE3 VIF Join(*, FF18:226.0.0.13) Vector EA::22
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
JOIN(*,G)—JOIN (*,G) Forwarding IPv4 dest: 224.0.0.13 Upstream Neighor 59.66.76.215 Join(*, 226.0.0.13)
JOIN(*,G)—JOIN (*,G) Reaching RP IPv4 dest: 224.0.0.13 Upstream Neighor :NUll Join(*, 226.0.0.13)
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) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+…
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
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
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
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