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 (Rtr) CN MN Binding Cache: tunnel

• 1. BU

(Binding Update) R1 COA HA Internet

• 4. Packet to HA via COA
• 3. BU

HA=COA CN List:

• 2. Packet to HA.

CN

• 5. Packet from COA (HA in HAOpt)

Unicast Mobile IPv6 Example

Home Agent (Rtr) CN Binding Cache: R1 MN COA2 HA Internet R2

• 1. BU

HA=COA CN List: CN

• 2. BU

2

• 3. Packet to

HA via COA2

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

Home Agent (Rtr) CN MN Binding Cache: R1 COA HA Internet CN List:

• 1. (COA,G) data with HA in HAOpt

Join State: (HA,G)

• 2. (HA,G) Join state

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

Home Agent (Rtr) CN MN Binding Cache: R1 COA HA Internet CN List:

• 1. (COA,G) data with HA in HAOpt

Join State: (HA,G)

• 2. (HA,G) Join state
• 3. Multicast BU

HA=COA

• 4. (COA,G) Join state

Multicast Mobile IPv6 Example

Home Agent (Rtr) CN Binding Cache: R1 MN COA2 HA Internet R2 HA=COA CN List: (HA,G) (COA,G) Join state Join State: BUX

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.