Mipshop – MIH DT report

1. Mipshop – MIH DT report IETF 69 – Chicago 24th July 2007

2. Admin stuff • Updated DT members list: • Subir Das • Nada Golmie • Heejin Jang • Telemaco Melia (editor and DT leader) • Sam Xia • Juan Carlos Zuniga • Gabor Bajko • Document being worked out, available soon • 802.21 liaison has been updated

3. 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 (Point of Service), either during initial attachment or during handover • Transport • This is the service provided to allow the communication between two MIHFs via MIH protocol once they discover each other • Security aspects are considered together with the Transport service • Candidate solutions for both aspects have been evaluated • Existing standard track IETF-based solutions have been given preference

4. Assumptions • Solution is aimed at supporting 802.21 MIH Services • If MIHFID is available, FQDN or NAI’s realm is used for MoS discovery • DT recommends to 802.21 to restrict to only these two • Solutions are chosen to cover all possible deployment scenarios • Next slide • MIHF discovery can be executed during initial network attachment or thereafter

5. 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 3rd Party Network (MoS3)

6. 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 • Providing MoS domain name of serving network • 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 by DHCP • Solution requires: • Defining DHCPv4 and DHCPv6 options for MIH discovery and • Registering DHCP Option codes with IANA

7. 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 • From the Service tag and then from the FQDN • Solution requires: • Defining DNS usage and service tag(s) • e.g. “_mih._udp.mydomain.foo” • Registering application service tag(s) “MIH” with IANA

8. Discovery (MN view example) Legend: DHCP: Use DHCP MIH option after network acc auth DHCP_AAA: Use DHCP MIH options (tight coupling with AAA) DNS: Use DNS NAPTR/SRV record query MoS address preconf? Y MN discovering MoS end N MN in Home ntwk? Y N MoS in visited network? MoS in Home network? Y N N Y MoS in Home network Y N DNS DHCP/DNS DHCP_AAA/DNS DHCP/DNS end end end end

9. 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 802.21 and provides better latency • MIH over TCP can provide additional congestion control • Security can be provided at MIH level or by existing transport/IP security 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