Transcript mipshop
Mipshop – MIH DT report IETF 69 – Chicago 24th July 2007 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 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 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 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) 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 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 Discovery (MN view example) Legend: DHCP: Use DHCP MIH option after network acc auth DHCP_AAA: Use DHCP MIH options (tight coupling with AAA) MN discovering MoS MoS address preconf? Y end N DNS: Use DNS NAPTR/SRV record query N Y N MoS in visited network? Y DHCP/DNS end MN in Home ntwk? N Y Y MoS in Home network? N MoS in Home network DHCP_AAA/DNS end DNS end DHCP/DNS 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 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