Softwire Mesh Framework: Multicast Mingwei Xu Yong Cui CERNET, China Chris Metz, Cisco 68th IETF Meeting, Prague March 2007

Native IPv6 CERNET2 in China

Why we need Softwire Multicast? From CERNET Existing multicast applications are in IPv4 CERNET includes dozens of regional networks Regional networks support IPv4 multicast (including PIM-SM) Native IPv6 CERNET2 supports IPv6 multicast protocols CERNET2 is expected to support IPv4 access (including multicast) for regional networks

CERNET2 (IPv6 Multicast) CERNET Requirement 4over6 BGP-MP Peering Same behavior as a dual-stack backbone Encapsulation/decap Shanghai (IPv4 multicast) CERNET (IPv4 multicast) Softwire 4over6 4over6 CERNET2 (IPv6 Multicast) Beijing (IPv4 multicast) Guangzhou (IPv4 multicast) 4over6 4over6 IPv6 access IPv6 access

Essential issues Setup IPv6 core multicast tree Setup/Extend IPv4 multicast tree across IPv6 core Forward IPv4 multicast traffic across IPv6 core Encap IPv4 packet for transport across IPv6 multicast backbone IP-in-IP, GRE, …

Softwire Multicast Considerations Tradeoff Multicast traffic optimization Any PE/P receives unwanted E-IP multicast packet? State maintenance What state to be maintained on each PE/P router? Leverage existing technologies Based on mesh framework May use BGP to advertise routing info May support IP-in-IP or GRE encap (NO MPLS on CERNET/CERNET2)

Softwire Mesh Multicast Framework 1:1 Mapping (Internet Multicast Model) one E-IP tree maps to one I-IP tree I-IP core multicast state scales linearly with E-IP client multicast state “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

1:1 with PIM in the Core source I-IP Transit Core (PIM) E-IP Client Net E-IP Client Net AFBR1 AFBR2 CE1 CE2 2. I-IP PIM Join/Prune (RPF Vector) 1. E-IP PIM Join/Prune 3. E-IP PIM Join/Prune AFBR2 receives E-IP PIM Join/Prune, translates to I-IP PIM Join/Prune and forwards to AFBR1 use RPF vector so that core routers can forward PIM messages towards AFBR1 that leads to source E-IP/I-IP Translation performed at AFBR nodes if E-IP is IPv4 and I-IP is IPv6 then v4-mapped IPv6 addressing policy (ala RFC4291) is possible If E-IP is IPv6 and I-IP is IPv4 then additional inter-AFBR signaling needed so that AFBR2 can learn which PIM/IPv4 (S,G) to use in core

1:1 with MPLS/mLDP in the Core source I-IP Transit Core (mLDP) E-IP Client Net E-IP Client Net AFBR1 AFBR2 CE1 CE2 2. mLDP w/FEC ID 1. E-IP PIM Join/Prune 3. E-IP PIM Join/Prune AFBR2 receives E-IP PIM Join/Prune, computes FEC identifier based on (S,G) and sends to AFBR1 which is root of P2MP LSP tree AFBR1 extracts FEC identifier, computes (S,G) and sends E-IP PIM toward source Considerations (S,G)-FEC id encoding must be standardized PIM state – mLDP interactions

“mVPN-Like” Applied if requirement dictates # of I-IP multicast state less than # of E-IP multicast state AFBR = PE routers with one E-IP VPN Control Plane Options LAN-like: use I-IP multicast trees in core to emulate LAN and run E-IP PIM across this LAN NBMA: E-IP PIM – BGP signaling mediation Data Plane Options all E-IP multicast travels over single I-IP tree specific E-IP multicast travels over specific I-IP tree draft-ietf-l3vpn-2547bis-mcast-xx.txt

Comments on Encaps/Decaps In all cases, ingress AFBR encaps E-IP multicast packets for core I-IP transit to leaf AFBRs leaf AFBR(s) decaps sends on its way mVPN-like procedures explained in existing drafts 1:1 PIM in core uses various IP encaps including IP-in-IP, GRE, etc. mLDP in core uses labels

Next Steps Mailing list feedback Update draft-xu-softwire-4over6multicast-xx Update multicast section in -03 revision of softwire mesh framework doc