Mobile SSM Sources (magma/mobileip/ssm interactions) Dave Thaler - PowerPoint PPT Presentation

Mobile SSM Sources (magma/mobileip/ssm interactions) Dave Thaler dthaler@microsoft.com

Mobile IP Review • Two primary requirements: 1. Transparent to apps/protocols • Existing sessions continue working 2. Route optimization after first packet burst • Packets follow shortest path between new location and correspondents • Other requirements not affected by the multicast problem: – Work in presence of source ingress filtering (IPv6-only) – Don’t require special infrastructure support in foreign locations (IPv6-only) – Allow stable home addresses in DNS – Allow location privacy as alternative to route optimization

Unicast Mobile IPv6 Example Home Agent Binding (Rtr) 2. Packet to HA. Cache: HA=COA CN 1. BU (Binding tunnel Update) Internet R1 HA MN 3. BU COA CN List: 4. Packet to HA via COA CN 5. Packet from COA (HA in HAOpt)

Unicast Mobile IPv6 Example Home Agent Binding (Rtr) Cache: HA=COA 2 CN 1. BU Internet 2. BU R1 R2 3. Packet to HA HA via COA2 MN COA2 CN List: CN

Effects on Multicast • No problem receiving normal data – Receiver’s address is typically irrelevant – After moving, you’re just like a new receiver • No problem sourcing ASM traffic from COA – Just like a new source to multicast routing – Can use HA Option so apps don’t see source change

The SSM Problem Join State: (HA,G) Home Agent 2. (HA,G) Join state Binding (Rtr) Cache: CN Internet R1 HA 1. (COA,G) data with HA in HAOpt MN COA CN List: BLACK HOLE!

Possible Solutions 1. Don’t use Mobile IP, make it the app’s problem – Ignores transparency requirement – Can’t expect arbitrary app writers to get it right 2. Always tunnel via HAgent from HA • Ignores route optimization requirement • Equivalent to PIM-SM with no SPT switching 3. Add mechanism to solve the problem

What’s the real cause? • In Mobile IP, the binding cache insures: – Upper layer always sees HA – Wire always sees COA • Host’s unicast routing uses binding cache • Host’s multicast routing does not! (Oops!) • So obvious answer is to use the BC just like unicast does: – App joins (HA,G) – Host sends (COA,G) join on the wire

The rest of the problem… • So how do you get a BU to the group? • Mobile source can multicast BU’s from HA tunneled via Home Agent – Must be periodic to allow new joiners – Somewhat analogous to periodic null registers – Requires a security mechanism that works with this • One final problem comes when source moves again…

Multicast Mobile IPv6 Example Join State: (HA,G) Home 3. Multicast BU Agent 2. (HA,G) Join state Binding (Rtr) Cache: HA=COA CN 4. (COA,G) Join state Internet R1 HA 1. (COA,G) data with HA in HAOpt MN COA CN List:

Multicast Mobile IPv6 Example Join State: (HA,G) Home Agent BU X Binding (Rtr) Cache: (COA,G) Join state HA=COA CN Internet R1 R2 HA MN COA2 CN List:

Final Rule Would Be • MLDv2 receivers always join to (S,G) • If a BC entry for S exists, they ALSO join to (COA,G) • When BU is received for a source S – Leave any old (COA,G)’s for that source – Join new (COA,G)’s for that source

So which solution? 1. Don’t use Mobile IP, make it the app’s problem – Ignores transparency requirement – Can’t expect arbitrary app writers to get it right 2. Always tunnel via HAgent from HA • Ignores route optimization requirement • Equivalent to PIM-SM with no SPT switching 3. Add mechanism to solve the problem • Binding Cache becomes a MUST? Keep in mind: source doesn’t necessarily know whether all receivers are exclude mode today.