IEEE 802.21 MEDIA INDEPENDENT HANDOVER DCN:21-06-0523-01-0000 Title: MIH Header Issues Date Submitted: February 27, 2006 Presented at IEEE 802.21 session in Denver Authors or Source(s): Yoshihiro Ohba, Vivek Gupta, Kalyan Koora, Srinivasa Sreemanthula and Eunah Kim Abstract: This document raises several issues on the MIH Header format defined in 802.21 draft D00-05. 21-06-0523-01-0000

IEEE 802.21 presentation release statements This document has been prepared to assist the IEEE 802.21 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 802.21. The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual <http://standards.ieee.org/guides/opman/sect6.html#6.3> and in Understanding Patent Issues During IEEE Standards Development http://standards.ieee.org/board/pat/guide.html>  21-06-0523-01-0000

MIH Frame Format Octet 1 Octet 2 Octet 3 Octet 4 - r F d e e d H I x a 12 15 8 11 14 23 SID OpC o d e Message ID ( 4 ) ( 3 ) ( 9 ) Octet 1 Octet 2 Octet 3 Octet 4 BITS - > 3 4 7 23 31 No . of Header - - r VER Res . MIH Message ID F d e Identifier s e d H I x a i e M F H Variable Load Length MIHF Variable Header e l ( contains Header Identifiers in TLV format ) F b d H a a I i r o M a L V MIHF - Payload ( contains other service specific TLVs ) 21-06-0523-01-0000

MIH Message ID Message ID has the following sub-fields: Service Identifier (SID): Identifies the different MIH services (System Management, ES, CS, IS) Operation Code (OpCode): Type of operation to be performed with respect to the SID (Request, Response, Indication) Action Identifier (AID): This indicates the action to be taken w.r.t. the SID 21-06-0523-01-0000

Issue 1: Number of Header Identifiers Field If the Header Identifier TLV has the same format as TLVs used in the Payload part, then this field is not needed There is a proposal (21-06-0526-00-0000_IDs_in_primitives_and_header.doc) to use the IE TLV format for Header Identifier TLV Proposed solution: Delete Number of Header Identifiers field 21-06-0523-01-0000

Issue 2: Reserved Field too short The reserved field is too short Future extensions require more bits for this field Proposed solution: Expand the Reserved field to the 2nd octet of the MIH Fixed Header Shift the subsequent fields to the left 21-06-0523-01-0000

Issue 3: Transaction ID useful Transaction ID field has been removed from Fixed Header because it is not needed for “Indication” type actions But it is needed for Requests and Responses According to Issue 1, the space reserved for Number of Header Identifiers field can be re-used for Transaction ID Proposed Solution: Define 2-octet Transaction ID field between MIH Message ID field and Variable Load Length field 2^16-1 concurrent transactions can be supported 21-06-0523-01-0000

Issue 4: ACK Some command can take time to process (e.g., MIH_Switch). The sender of the request of such a command cannot tell whether the request gets lost or the request has been received but is taking time to process. The sender may unnecessary retransmit the request ACK mechanism is needed ACK can also be useful for indication and response Proposed Solution: Use two bits in the Reserved field in the MIH fixed header for “ACK-req” and “ACK-resp” flags Semantics: If the sender of a request, response and indication message requires an ACK, then it sets ACK-req flag in the message. If the receiver of a request, response and indication message finds that ACK-req flag is set, then it returns an ACK by setting the ACK-resp flag, copying the received Message ID and Transaction ID and with empty payload. An ACK MUST NOT be returned in response to an ACK. The ACK-req flag SHOULD NOT be set if the underlying transport is reliable. A request, response, indication message may be retransmitted based on timer in case an ACK is not received within an expected time period. When an MIHF receives a duplicate message for which an ACK has been returned, it MUST return a duplicate ACK. For a Request message, a Response message may be used as an alternative acknowledgment. 21-06-0523-01-0000

Issue 5: OpCode can be short There are already three operations, Indication, Request, Response Why we need three bits for OpCode? Proposed Solution: Decrease the OpCode field length from 3 to 2 bits Increase the AID field length from 9 to 10 bits 21-06-0523-01-0000

Comment 1: Replace Figure 31 with the Format below SID (4) OpCode (2) Action ID (10) . Octet 1 Octet 2 Octet 3 Octet 4 BITS - > 3 4 31 VER (4) ACK -req (1) ACK -resp (1) Reserved (10) MIH Message ID (16) - r F d e e d H x a I i e M F Transaction ID (16) H Variable Load Length (16) MIHF Variable Header e ( contains Header Identifiers in TLV format ) l F b d H a a I i M r o a L V MIHF - Payload ( contains other service specific TLVs ) 21-06-0523-01-0000

Comment 2: Revise Table 18 as follows Field Name Size (bits) Description Version 4 This field is used to specify the version of protocol used. The importance of this is seen in downwards compatibility handling in the future. ACK-req 1 This field is used for requesting an acknowledgment for the message. See Section 8.3.1 for detailed usage of this field. ACK-resp This field is used for responding to the request for an acknowledgment for a message. See Section 8.3.1 for detailed usage of field. Reserved 10 This field is intentionally kept reserved. In un-used case, it all the bits of this field are to be set to '0'. MIH Message ID (MID) -- Service Identifier (SID) -- Operation Code (Opcode) -- Action Identifier (AID) 16 2 Combination of the following 3 fields. Identifies the different MIH services, possible values are: 1: System Management 2: Event Service 3: Command Service 4: Information Service Type of operation to be performed with respect to the SID, possible values are: 1: Request 2: Response 3: Indication This indicates the action to be taken w.r.t. the SID Transaction ID (TID) This field is used for matching Request and Response as well as matching Request, Response and Indication to an ACK. Variable Load Length Indicates the total length of the variable load embedded into the MIH Function frame and is the sum of MIHF variable header length and MIHF payload length. MIHF fixed header length is NOT included. 21-06-0523-01-0000

Comment 2 (cont’d): Append the following text to Section 8.1 MIH messages require reliability for remote communication on an end-to-end basis to ensure the receipt of data to the intended destination. It is particularly useful when the underlying transport used for remote communication does not provide reliability services. The nature of MIH communication may imply use of unacknowledged connection-less transport services to reduce transport overhead and ensure efficiency and reduced latency in the delivery of the MIH messages. Reliability can be provisioned with an optional acknowledgement service as part of the MIH protocol. The source end point can optionally request for an MIH ACK message to ensure successful receipt of a certain event, command or an information service message. MIH level ACK packet is used to acknowledge the successful receipt of MIH messages at the destination end point. When the MIH ACK is received by the source, it can determine the reliable delivery to the destination. If the message or the MIH ACK is lost, the source shall timeout and retransmit the same MIH message. The protocol defining the optional MIH ACK procedure is defined on top of the base MIH protocol capabilities. The MIH ACK is supported by use of 2 bits of information that is defined exclusively for ACK usage in the MIH header as shown in Figure 1. The ACK-Req bit is set by the source MIH node and the ACK-Resp bit is set by the destination MIH node. The underlying transport layer takes care of verifying MIH message integrity. As such verification of MIH message integrity is not required at MIH Function level. 21-06-0523-01-0000

Comment 2 (cont’d): Insert a new Section 8.3.1 Operation A source MIH node may start a timer at the time of sending a MIH packet with the ACK-req bit set and may buffer the MIH packet while the timer is active. The value of the timer may depend on the RTT between the two nodes. If the acknowledgement packet is not received within the expiry of the timer, the source node may retransmit the buffered packet immediately with same Message-ID (with ACK-Req bit set) and with the same Transaction-ID. If the source receives the ACK for the previous packet soon after retransmitting the same packet, then the source may determine successful delivery of the original packet and may not have to wait for any acknowledgement for the retransmitted packet. If the source received the acknowledgement before the timer expiry on original or any retransmitted attempt, then the source can reset the timer and release the packet buffer. The source can utmost make two retransmitted attempts in addition to the original attempt for the same message with the same Transaction-ID. The source must not attempt to retransmit a packet with same Message-ID and Transaction-ID when the ACK-req bit was not set in the original packet. When a destination receives an MIH packet with the ACK-Req bit set then the destination returns an acknowledgement packet with ACK-Resp bit set and copying the Message-ID and Transaction-ID from the received packet. This packet may have no other payload. In instances where the destination can immediately process the received packet and a response is available, then the ACK-Resp bit can be set in the MIH response packet. However, in this instance, the OpCode may indicate a response value. It is possible for a destination MIH node to set ACK-Resp bit in a MIH response packet and additionally, act as a source node for the response packet and request MIH acknowledgement services by setting the ACK-Req bit. The destination may chose to buffer the original MIH packet header to correlate with any retransmitted packet(s) containing the same Transaction-ID for a small time duration whose value may depend on the RTT between the two nodes to avoid duplicate processing of the same message. If such a retransmitted packet is received during this time period, the destination must respond with an acknowledgement packet even though an acknowledgement message was sent earlier for the original packet. In any case, the destination must not process the retransmitted packet if already done so, since it is a duplicate packet. If a destination receives an MIH packet with no ACK-Req bit set then no action is taken with respect to the MIH ACK protocol functionality. 21-06-0523-01-0000