Softwire Mesh Framework: Multicast Mingwei Xu Yong Cui CERNET, China Chris Metz, Cisco 68 th 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

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

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 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 AFBR1 AFBR2 I-IP Transit Core (PIM) CE1 CE2 E-IP Client Net E-IP Client Net 1. E-IP PIM Join/Prune 2. I-IP PIM Join/Prune (RPF Vector) 3. E-IP PIM Join/Prune source

1:1 with MPLS/mLDP in the Core 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 AFBR1 AFBR2 I-IP Transit Core (mLDP) CE1 CE2 E-IP Client Net E-IP Client Net 1. E-IP PIM Join/Prune 2. mLDP w/FEC ID 3. E-IP PIM Join/Prune source

“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