IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Session Identifier Date Submitted: February xx, 2006 Presented at IEEE session in Denver Authors or Source(s): Yoshihiro Ohba, Qiaobing Xie, Subir Das, Ronny Kim, Srinivas Sreemanthula, Kalyan Koora and Vivek Gupta Abstract: This document proposes use of session identifier for identifying an MIH registration session across different MIH transport instances between a pair of communicating MIHFs.

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

Problem Description Assumption: MIHF at MN needs to register with an MIHF in the network for specific event and command services Scenario: MIHF at MN with multiple interfaces may use multiple transport protocol instances to communicate with an MIHF in the network (PoS or non-PoS MIH), for example: One TCP, UDP or SCTP instance and one Ethertype transport instance Multiple Ethertype instances Multiple TCP, UDP or SCTP instances Problem: How the MIHF in the network can associate multiple transport instances of the same MIHF at MN with a registration?

Case 1: Single MIHF Hop A PoS needs to maintain a registration state for the MN across multiple transport instances The transport instances of the MN is visible to the PoS MNPoS Transport Connection X Transport Connection Y

Case 2: Multiple MIHF Hops Each PoS that has a transport instance with a MN relays a registration request towards the non-PoS MIH PoS needs to maintain a registration state for the MN (Same as Case 1) A non-PoS MIH needs to maintain a registration state for the MN across multiple PoSes that relay the registration requests The transport instances of MN are not visible to the non-PoS MIH MN PoS Transport Connection X Transport Connection Y PoS Non- PoS MIH

Proposal Define a session identifier (SessionID) that is assigned at the time of initial registration Single-hop: The SessionID is assigned by a PoS Multi-hop: The SessionID is assigned by a non-PoS MIH The SessionID is valid only during the lifetime of a registration A registration state needs to have at least a SessionID and local handles to the transport instances When sending and receiving MIH messages related to the registration, the SessionID and the transport instances are used, except that a SessionID is not carried in the initial registration request The same SessionID may or may not be shared among different services (e.g., Event Service and Command Service) Multiple SessionIDs may be associated with the same transport instance

Proposal (cont’d) When a MN or a PoS wants to add a new transport instance to the existing registration or delete an already associated transport instance from the existing registration, it re-registers with the registrar using the SessionID assigned during registration “ Add ” indication is used for adding a new transport instance “ Delete ” indication is used for deleting a transport instance The “ Add ” or “ Delete ” indication is carried in the re-registration request Re-registration request: A registration request using the SessionID for an existing registration The re-registration request will be sent over the transport instance to be added or deleted If “ Add ” or “ Delete ” indication is NOT carried in the re-registration request, the currently associated transport instance(s) is (are) replaced with the transport instance that carries the re-registration request In multi-hop case, “ Add ” or “ Delete ” indication for the first hop PoS may not be propagated to the next hop

Issue Issue: Can SessionID be defined as a locally generated unique identifier within the entity that assigns it? Solution: In single-hop case, a local unique identifier can serve as a SessionID In multi-hop case, a local unique identifier may not work SessionID conflict can occur when different non-PoS MIHs assign the same SessionID for different registrations MN2 PoS1 Non- PoS MIH1 Non- PoS MIH2 MN1 SessionID=100 (requested by MN1) SessionID=100 (requested by MN2) SessionID conflict PoS2 Network1 Network2

Another Example of SessionID Conflict MN2 PoS Non- PoS MIH MN1 SessionID=100 (requested by MN1, assigned by PoS) SessionID=100 (requested by MN2, assigned by non-PoS MIH) SessionID conflict (PoS cannot know whether SessionID=100 is for MN1 or MN2) Re-registration request (SessionID=100, “Add”)

Candidate Solutions Solution 1: Use a local unique identifier for both single-hop and multi-hop cases Constraint: No two non-PoS MIHs communicating with a PoS should not generate the same identifier Solution 2: Use a global unique identifier for both single-hop and multi-hop cases Assigning a global unique identifier is an issue Solution 3: Use a local unique identifier for single-hop case and use a global unique identifier for multi-hop case This will add more complexity and need an additional identifier to identify the two cases Diameter protocol defines SessionID to be global unique to address this issue based on Solution 2, where Session ID is a combination of FQDN and local unique numbers. Can we re-use the same format for SessionID?

Proposed Solution for SessionID Use Solution 2 (global unique identifier) Re-use the Diameter Session-Id format [RFC 3588] SessionID Format: MIHF-ID; ; [; ] MIHF-ID is an FQDN of the entity assigning the SessionID and are decimal representations of the high and low 32 bits of a monotonically increasing 64-bit value. The 64-bit value is rendered in two part to simplify formatting by 32-bit processors. At startup, the high 32 bits of the 64-bit value MAY be initialized to the time, and the low 32 bits MAY be initialized to zero. This will for practical purposes eliminate the possibility of overlapping SessionIDs after a reboot, assuming the reboot process takes longer than a second. Alternatively, an implementation MAY keep track of the increasing value in non-volatile memory. is implementation specific but may include a modem's device Id, a layer 2 address, timestamp, etc.