IETF DMM WG Mobility Exposure and Selection WT Call#2 Nov 6, 2014

Work Items #1. 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 #2. Describe how mobility attributes of IP addresses are conveyed from network to MN. #3. Describe how a required type of IP address is configured, when one is not already available on the MN. #4. Describe how IP address type is communicated between the apps and IP stack on the MN. – Source address selection based on IP address type 2

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 [SUSTAINED IP ADDRESS (better term?)] 2) Always stable [FIXED IP ADDRESS] 3) Not stable (lost upon handover) [NOMADIC IP ADDRESS] IP address can change its type – Nomadic  Sustained: possible, but may not be available on all networks Alternative: Network provide another IP address when the MN needs a sustained IP address Changing type on the same IP address may pose efficiency issues, system may be better off providing a second IP address – Sustained  Fixed: possible (but may not be very efficient) Same for Nomadic  Fixed Network protocols to configure IP address of desired type are independent of the API between the apps and IP stack on the MN – Supporting the 3 address types can be implemented by various DMM technologies that are being discussed in DMM WG 3

Basic Principles IP address attributes will be “exposed” by the network to the MN’s IP stack (related to work#2) – MN can explicitly request (negotiate) an IP address with specific type (related to work#3) 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” Define extensions to RFC 5014 “IPv6 Socket API for Source Address Selection” 4

RFC 5014 Extensions RFC 5014 already defined 2 flags: – IPV6_PREFER_SRC_HOME – IPV6_PREFER_SRC_COA Not sufficient, as we need to distinguish among 3 different types – Fixed IP Address – Sustained IP Address – Nomadic IP Address Also, solution must trigger IP address allocation attempt if the requested type IP address is not already configured: – Work#3: “Describe how a required type of IP address is configured, when one is not already available on the MN” 5

RFC 5014 Extensions 2 relevant drafts: – ( – mobility/ mobility/ ( 6

Legacy Legacy MN w/o API support Legacy apps w/o API support Advanced app/MN, but network does not support any/some mobility types We need to provide guidelines 7

Triggers IP stack sending triggers to apps about IP address events – In scope? Not clear. – Nothing new needed, it’s already there? 8

Work Items #2/3 #2. Describe how mobility attributes of IP addresses are conveyed from network to MN. #3. Describe how a required type of IP address is configured, when one is not already available on the MN Sri will provide the revised list for the above proposals. 9

Next Steps Reading and discussing existing API drafts Meetup in Honolulu? – Decide on Monday. 10

Slides from Call#1 11

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. 12

Basic Principles Selection between client-based vs network- based 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). 13

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” 14

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 15

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 16

Next Steps 2nd call, before IETF Meetup in IETF 17

Related Documents mobility/ mobility/