IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: L3 Transport for MIH Services Date Submitted: July 19, 2007 Presented at IEEE session in San Francisco, CA, USA Authors or Source(s): Juan Carlos Zuniga, Patrick Stupar, Subir Das, Gabor Bajko, Srinivas Sreemanthula, Yoshiro Ohba, Daniel Park, Telemaco Melia Abstract: This contribution provides an overview of current L3 Transport considerations for MIH

IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE ’ s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE ’ s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3

L3 Transport for MIH Services (MoS)

Introduction The MIH L3 transport problem can be divided in two parts –Discovery Process required for the MIHF at the Mobile Node (MN) to discover the peer MIHF (e.g. IP address) of the Mobility Services (MoS) in the network, e.g. PoS –Transport This is the service provided to allow the communication between two MIHFs once they discover each other Security aspects are considered together with the Transport service MIPSHOP-DT has evaluated candidate solutions for both aspects –Existing IETF-based solutions have been given preference

Assumptions Solution is intended for MIH Services If MIHFID is available, FQDN or NAI’s realm is used for MoS discovery –Note: shall restrict to these Solutions are chosen to cover all possible deployment scenarios –Scenarios are described in next slide Existing standard tracks transport solutions are preferred MIHF discovery can be executed during initial network attachment or thereafter

Deployment Scenarios The following deployment scenarios are identified –Case 1: Home Network MoS The MN and the services are located in the Home Network (MoSh) –Case 2: Visited Network MoS MN is in the Visited Network and services are also provided by the Visited Network (MoSv) –Case 3: Roaming MoS MN is in the Visited Network and all services are provided by the Home Network (MoSh) –Case 4: MoS3 MN is in Home or Visited Network and services are provided by a 3 rd Party Network (MoS3)

Discovery (1/2) From the different considered solutions, DHCP and DNS are the two main options DHCP –Works for deployment cases 1 and 2, either Providing directly the IP address of the MIHF, or Combined with DNS –Obtain domain name of serving network through DHCP and then resolve the IP address of the peer MIHF by DNS –Deployment case 3 can work if Relay configuration by AAA is used to discover the MoSh –This requires tight coupling between Discovery and Network Access Authentication –Case 4 cannot be supported with existing DHCP Solution requires: –Defining DHCPv4 and DHCPv6 options for MIH discovery and –Registering DHCP Option codes with IANA

Discovery (2/2) DNS –All deployment scenarios can be supported Visited network domain name can be obtained from DHCP Home network domain name can be preconfigured in MN Third party domain names can be obtained from an already discovered MIH IS or others –DNS resolution can be performed Directly from the network domain name (FQDN) From the Service tag and then from the FQDN –Solution requires: Service tag definition Registering application service tag “MIH” with IANA

Discovery Flow (Example) MN attached to ntwk A and discovering MIH Ntwk A local? N Y MoS add preconf? Y end Opt 1Opt 2 Use DHCP MIH options N Home ntwk? Use DNS NAPTR/SRV record query Use DHCP MIH option after ntwk acc auth Y Opt 1Opt 2 N end

Transport From the different considered solutions, UDP and TCP are the two main options –Both are applicable to all scenarios –NAT/FW-traversal recommendations can be made MIH over UDP allows reliability via MIH ACK mechanism defined in and provides better latency MIH over TCP can provide for congestion control –However, congestion control is not foreseen to be an issue, since MIH information flow is not significant Security can be provided at MIH level or by existing mechanisms (e.g. IPsec, DTLS/TLS) Both UDP and TCP can be supported –The choice would depend on latency and congestion control requirements Solution requires: –Writing definition (recommendations) –Requesting Port # to IANA