Transcript IETF DMM WG Mobility Exposure and Selection WT Call#1

IETF DMM WG
Mobility Exposure and Selection WT
Call#1
Oct 23, 2014
Basic Principles
• E2e data flow continuity can be accomplished at various
layers:
– IP-layer (e.g., MIP, PMIP)
– Transport-layer (e.g., SCTP, MPTCP)
– Application-layer (e.g., SIP, or proprietary)
• Mobility protocols at different layers may be applied to
each data flow, depending on applicability/availability.
– “Selection” needed for determining which protocol to apply on
a given e2e data flow.
– This selection is outside the scope of DMM. DMM only cares
about IP-layer mobility.
• DMM handles IP-layer mobility support, any other layer
mobility is outside the scope of DMM.
• Regardless of/in addition to other layer mobility, IP layer
mobility may be used.
2
Basic Principles
• Selection between client-based vs networkbased IP mobility is needed.
– This is a per-node selection (not per-flow). [This
point is OPEN to further discussion]
– Can be based on configuration (e.g., SIM)
– Dynamic negotiation/selection also allowed (e.g.,
ANDSF, other).
3
Basic Principles
• Source address for a data flow may be
1) A stable IP address that does not change until the flow terminates
• E.g., Skype call, VPN, live video streaming.
2) A stable IP address that does not change (practically) at all
• E.g., mobile server app using a (DNS/other) published IP address
3) An IP address that can change at each handover
• E.g., DNS client, IM client, apps using MPTCP
• IP addresses have a mobility attributes with following types:
1) Stable when in use
2) Always stable
3) Not stable (lost upon handover)
• IP address attributes will be “exposed” by the network to the MN’s IP stack
– MN can explicitly request (negotiate) an IP address with specific type
• IP address attributes will be “exposed” by the IP stack to the applications
on the MN
– Apps can explicitly request (negotiate) a source IP address with specific type
• Each data flow needs to be bound to an IP address according to its
mobility characteristic
– Source address “selection”
4
Work
• Describe how MN decides between IP-layer and
other layer-based mobility support (e.g., MPTCP,
SIP, app-layer) to apply on a given flow
• Describe how mobility attributes of IP addresses
are conveyed from network to MN.
• Describe how a required type of IP address is
configured, when one is not already available on
the MN.
• Describe how IP address type is communicated
between the apps and IP stack on the MN.
– Source address selection based on IP address type
5
Opens
• Do we want to expose the location of the IP
anchor to the apps?
• Backward compatibility
– Legacy host operating in new network
– New host operating in legacy network
6
Next Steps
• 2nd call, before IETF
• Meetup in IETF
7
Related Documents
• http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
• http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
• https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemandmobility/
• http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
• https://tools.ietf.org/html/draft-ietf-mif-mpvd-id-00
• https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-00
• http://tools.ietf.org/html/draft-ietf-mif-mpvd-ndp-support-00
• http://tools.ietf.org/html/draft-yegin-ip-mobility-orchestrator-00
• http://www.ietf.org/proceedings/90/slides/slides-90-dmm-7.pdf
8