Context Transfer Protocol Extension for Multicast draft-vonhugo-multimob-cxtp-extension-00.txt Proposal of seamless handover support for IP multicast services D. von Hugo and H. 1

Introduction Chartered goal for Multimob WG: – Mechanisms to optimize multicast traffic during a handover may include context transfer functionality Re-use existing protocols and adapt as little as possible – PMIPv6, MultiMob base, MLD Proxy, PIM-SM, … as is CXTP extension to cover multicast handover: here based on PMIPv6 – Potential applicability also for MIPv6 Speed up handover process Reduce packet loss Reduce network entities’ complexity Reduce load on terminal and network Divided CXTP part from “I-D.asaeda-multimob-pmip6-extension” 2

Addressing lossless and low delay session continuity after MN’s (PMIPv6) handover Assumptions: – Both MAG and LMA may be operated as MLD proxy or multicast router. – Explicit tracking available – MN already receiving multicast data hands over from old (p-) MAG to new (n-) MAG and should continuously receive multicast traffic through n-MAG after HO completion without any MLD signaling on the new wireless link p-MAG MN n-MAG Internet PMIP6 domain MAG-LMA tunnel LMA MC source 3

Proposed extensions to CXTP messages MN attaching new MAG sends RS (reactive) n-MAG learns about p-MAG via PBU/PBA (for PMIPv6 ) n-MAG sends CT-Req to p-MAG –CT Activate Request (CTAR) ? p-MAG via CXTP provides multicast states of MN to n-MAG using M- CTD n-MAG may have to subscribe via MLD (or PIM) Join to LMA. n-MAG requests p-MAG to B(uffer) multicast data for later F(orwarding) via n-MAG to MN after successful handover completion: M-CTDR(B/F). With delivery of Multicast data to MN, n-MAG may order p-MAG to L(eave) MN’s groups: M-CTDR(L). MN p-MAG n-MAG LMA || | | |-MLD Report-->|===== MLD Report (aggregated Join) ==>| | | | |---> PIM join |< |<============ Multicast data =======| (or MLD to MC Rtr.) | | | | Detach | | | | | | | Attach | | | | | | | | RS >| | ||| PBU > | | | |< PBA | | |<---CT-Req | | | | | | | |--CXTP (M-CTD) -->| | | | | | | | |===MLD Report ==>| | |<----M-CTDR(B) ----| | | | | | | < RA | | | | |<== Multicast data =| | |<--- M-CTDR(F) ----| | | |== Multicast data =>| | | |<--- M-CTDR(L) ---- | | | | | | |< Multicast data | | | | | | | |======== MLD Report (Leave)=======>| | | | |---> PIM prune |||| (or MLD Leave) MLD listener handover with CXTP and MLD proxy 4

Message Types M-CTD –(MN addr., Filter mode, (S,G)) M-CTDR –M-CTDR(B): Buffer –M-CTDR(F): Forward –M-CTDR(L): Leave 5

Open questions n-MAG informed about p-MAG using mechanism defined in RFC5949 (FPMIP6) ? –Is multicasting to potential n-MAGs or p-MAGs a practicable alternative? Is a trigger (CTAR) for sending CT-Req actually needed? Applicability to (non-P) MIPv6 and inclusion of proactive/predictive handover for future revision? Further comments and suggestions welcome! Thanks! 6