IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Analysis on Identifiers Date Submitted: January 9, 2006 Presented at IEEE session in Hawaii Authors or Source(s): Yoshihiro Ohba and Subir Das Abstract: This document gives some analysis on several identifiers related to MIH protocol.

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

Issue on Identifiers in Issue 1: How a remote event/command for a particular link is mapped to the MIHF that uses the link Issue 2: How an MIHF in the network can maintain the registration status for an MIHF UE while the UE may change its transport address(es) Issue 3: How an MIHF in the network can maintain the transport address(es) of an MIHF UE when the UE has multiple interfaces Issues that are not discussed in this document: NAT traversal: This is a transport issue Proxy operation: This is a message routing issue

Issue 1: Mapping Link Indications to Higher- Layer State In section 2.9 of draft-iab-link-indications-04.txt: “ [d] Mapping of Identifiers. When link indications are transported, it is generally for the purposes of saying something about Internet, Transport or Application layer operations at a remote element. These layers use different identifiers, and so it is necessary to match the link indication with relevant higher layer state. Therefore proposals need to demonstrate how the link indication can be mapped to the right higher layer state. ”

Issue 1: Mapping Link Indications to Higher- Layer State (cont’d) Issue: A higher-layer transport uses IP address as transport address, but an IP address itself does not represent a link (while an IP address can be used for identifying an MIHF, see next slide) Approach 1: Creating a mapping between an IP address and a link-layer address during event/command registration This helps a receiver of a remote event or command to identify the link using the source IP address of the event or command This does not work when a remote event or command for a particular link of an MIHF is sent over another link of the MIHF or when the same IP address is shared among multiple interfaces Approach 2: Carrying a link identifier with a remote event or command E.g., LinkIdentifier defined in Link_Up.indication primitive can be used for this purpose

Issue 2: Maintaining Registration Issue: How an MIHF in the network can maintain the registration status for an MIHF UE while the UE may change its transport address(es) Registration ID needs to be assigned during initial registration A transport address cannot serve as a registration ID because it can change after MN ’ s movement A new identifier needs to be defined for this purpose The same ID may be used for re-registration Does a registration ID need to be carried in each MIH message?

Issue 3: Multiple Interfaces Issue: How an MIHF in the network can maintain the transport address(es) of an MIHF UE when the UE has multiple interfaces Exchanging transport addresses during registration is needed for mapping a particular registration to transport address(es) required by transport protocol When adding or deleting a transport address, re-registration would be needed