MIF API Extension Discussion MIF IETF 78 Dapeng Liu Yuri Ismailov

Agenda Background & Motivation for MIF API Extension Potential Scope of MIF API Re-charter discussion of MIF API

Background for MIF API Extension There are already Socket API extension work in IETF IPv6 MPTCP SHIM6 HIP SCTP

CategoryDescriptionDocument IPv6 socket(AF_INET6, SOCK_STREAM, 0); socket(AF_INET6, SOCK_DGRAM, 0); IPv6 address structure IPv6 Socket address structure RFC 3493: Basic Socket Interface Extensions for IPv6 Informational MPTCPNew options for getsockopt()/setsockopt() TCP_MP_ENABLE: Enable/disable MPTCP TCP_MP_SUBFLOWS: Get the addresses currently used by the MPTCP subflows TCP_MP_PROFILE: Get/set the MPTCP profile MPTCP Application Interface Considerations Informational SHIM6New options for getsockopt()/setsockopt() SHIM_ASSOCIATED/SHIM_DONTSHIM/SHIM_HOT_STANDBY/SHIM_LOC_LO CAL_PREF Socket Application Program Interface (API) for Multihoming Shim Informational HIPNew socket/resolver structure for HIP New options forgetsockopt()/setsockopt() SHIM_LOC_LOCAL_PREF/SHIM_LOC_PEER_PREF… Basic Socket Interface Extensions for Host Identity Protocol (HIP) Experimental Examples of Socket API Extensions

Background for MIF API Extension Motivation 1: Once there is a device with multiple interfaces, which can be operational simultaneously we face up the problem of making a choice. The choice of the interface may be centralized (per device policy) or distributed (every application decides which interface(s) to use and for which flow) If the choice either centralized or distributed, then there is no collision between those two approaches If there is more than one centralized approach to interface selection then only one at a time can be used otherwise collision is possible.

Example of collision case Mobile IP with multiple CoA (centralized) The concept is to make visible a single interface for applications and the choice of where to send the traffic is up-to MIP mechanism PMIP logical interface for flow mobility (centralized) Similar to MIP. Could not be used at the same time with MIP interface because will compete for being default for applications. The same referrs to HIP, SHIM6, and probably some other approaches as well.

Potential MIF API Solution Distributed approach to interface selection Leaves choices for applications, however Assume MIP is running at the same host... Assume PMIP logical interface configured in the same host... One of possible approaches to avoid this is to assign type of interfaces for logical interfaces, but then applications will have to be aware about MIP, PMIP, etc. This goes against MIP, PMIP, … concept. MIF host Application need this flexibility According to real development and coding experience

Motivation 2 MIF host has DNS split issues Gethostbyname()/Getaddrinfo() – Lack the ability to specify which DNS server New DNS API parameters for DNS-split?

Motivation 3 Connection Manager API need to have standardized Behavior – Provide information to application: e.g. allow the application to adapt their behaviour to the selected physical interface – Receive command from application: in order to allow the Interface to user space: allow the user to provide its preferences – Interface to operator policy provisioning: get policy from operator

Agenda Motivation for MIF API Extension Potential Scope of MIF API Re-charter discussion of MIF API

Potential MIF API Scope MIF API used for interface selection MIF API used for DNS selection MIF API used for Connection Manger

Agenda Motivation for MIF API Extension Potential Scope of MIF API Re-charter discussion of MIF API

Work Item: – An API describing how applications can exploit additional features of multiple interfaces enabled stack. This API should be an optional extension to the current set of networking API, that provides ability of interface selection, dns selection, etc. Expected output: – Informational RFC