August 2, 2005 IETF 63 – Paris, France Media Independent Handover Services and Interoperability Ajay Rajkumar Chair, IEEE WG

August 2, 2005 IETF 63 – Paris, France Scenarios considered by WG Between 802.xx and 802.yy Between 802.xx and Cellular 3GPP standards 3GPP2 standards Between ESS

August 2, 2005 IETF 63 – Paris, France What does Heterogeneous Handover Mean? Session Continuity at the IP layer Adaptation to new link at layer two Address continuity at layer three Service Continuity at the Application layer(s)

August 2, 2005 IETF 63 – Paris, France Reference Model

August 2, 2005 IETF 63 – Paris, France Information Service Link access parameters Security mechanisms Neighbor maps Location Provider and other Access information Cost of link Etc.

August 2, 2005 IETF 63 – Paris, France IS Requirements Two types of requirements: Transport requirements Architectural/protocol requirements Terminology: Network MIHF Instance (NMI) Resides in MIH-enabled network element Network element must be Layer-4 capable Mobile MIHF Instance (MMI) Resides in Mobile Node Protocol vs. interfaces: two interfaces considered (separately) to identify requirements MMI  NMI is here referred to as “access” MIIS I/F NMI  NMI is here referred to as “network” MIIS I/F

August 2, 2005 IETF 63 – Paris, France Transport Requirements for MIIS “access” MIIS I/F: Reliability: “network” MIIS I/F Reliability:

August 2, 2005 IETF 63 – Paris, France Architectural/Protocol Requirements for MIIS (1) Generic requirement for “access” and “network” interface: Protocol messages carry Information Elements specified in Protocol defines message format and message payload Protocol exchanges are query-based (request/response); scenarios where “delayed” response is provided asynchronously based on an MMI/NMI request are also considered Protocol should be independent of any specific mobility protocol

August 2, 2005 IETF 63 – Paris, France Architectural/Protocol Requirements for MIIS (2) “access” MIIS I/F: Discovery capability: The MMI must be able to discover presence of NMI for accessing IS service (discovered NMI could be the actual IS server) in either the serving network or candidate network The MMI must be able to discover address of NMI for accessing to IS service in either the serving network or candidate network to exchange L3 or above traffic It should be possible to drive discovery of NMI for accessing to IS service though information provided by MMI (e.g. MMI indicates that NMI for or is needed, if there is one) Security: As part of discovery, the MMI must be able to discover whether a security association can/shall be established with the NMI in either the serving network or candidate network, and if yes which credentials can be used to authenticate with NMI Protocol allows for authentication of NMI by MMI Protocol enables mutual authentication between MMI and NMI Payload encryption is optional. On/off decision can be made during discovery phase (e.g. mandated by MMI or NMI policies) Integrity protection is supported and required for IS Replay detection is optional for MIIS

August 2, 2005 IETF 63 – Paris, France Architectural/Protocol Requirements for MIIS (3) “network” MIIS I/F Security: Protocol enables mutual authentication between NMIs Payload encryption is optional. On/off decision can be made e.g. based on NMI policies Integrity protection is supported and required for IS Replay detection is optional