MIPSHOP Working Group Internet-Draft A. Rahman Expires: December 9, 2006 U. Olvera-Hernandez M. Watfa InterDigital Communications June 9, 2006 Transport of Media Independent Handover Messages Over IP draft-rahman-mipshop-mih-transport-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 9, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a mechanism for using UDP/IP for the transport of Media Independent Handover (MIH) messages between network nodes. MIH messages carry technology specific link layer information and commands that can be used to optimize handover procedures across different access technologies such as cellular and WLAN. MIH will complement Layer 3 mobility protocols such as Mobile IP. Rahman, et al. Expires - December 9, 2006 [Page 1] Internet Draft Transport of MIH Messages June 9, 2006 Table of Contents 1. Introduction.....................................................2 2. Terminology......................................................3 3. Network Model....................................................4 4. Encapsulation Model..............................................5 5. Host Environment.................................................5 6. Protocol Details.................................................7 6.1. MIH Message Encapsulation...................................7 6.2. MIH Message Delivery........................................8 6.3. MIH Application Timers......................................9 6.4. Signaling Scenario 1: Direct MIH Signaling over UDP/IP.....10 6.5. Signaling Scenario 2: MIH Signaling via WLAN MIH Proxy.....13 6.6. MIH Proxy Entity in WLAN...................................17 7. Interaction of MIH with Other Protocols.........................18 8. Security Considerations.........................................18 9. IANA Considerations.............................................18 References.........................................................18 Authors' Addresses.................................................19 Disclaimer of Validity.............................................20 Copyright Statement................................................20 1. Introduction IEEE 802.21 is developing lower layer (i.e. below IP) services to enable seamless handover across different access technologies. These services are termed Information Services (IS), Event Services (ES), and Command Services (CS) [1]. These services are used by a MIH Application that is located either in a Mobile Node (MN) or a Mobility Manager (MM) node. An important concept in IEEE 802.21 is that MIH Service messages can be exchanged between network nodes that may not be in the same sub- network. This is referred to as remote MIH message exchange. This places requirements for new functionality to be defined in IP level protocols which are well described in [2-4]. An example of remote message exchange is when a MN on a given wireless technology, say WLAN, may require to handover to another technology because the WLAN coverage is degrading. MIH remote message exchange functionality allows the MN to query a MM for a list of alternative access technologies to handover to in the area where the WLAN coverage is degrading. The MM would then use IS messages to reply back with, for example, a list of cellular and 802.16 Rahman, et al. Expires - December 9, 2006 [Page 2] Internet Draft Transport of MIH Messages June 9, 2006 candidates that the MN could handover to. This document describes a mechanism for transport of remote MIH messages using UDP/IP. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" in this document are to be interpreted as described in [5]. The following terminology and abbreviations are used in this document. 802.16 A published IEEE standard for broadband wireless metropolitan area networks. 802.21 A draft IEEE standard for inter-technology mobility. MIH Media Independent Handover. MIH Application Media Independent Handover Application that supports various services and intelligence for handover across multiple access technologies. Mobile Node (MN) A mobile device that supports an MIH Application and multiple access technologies. Access Point (AP) A Layer 2 device that offers WLAN connectivity to an MN. Base Station (BS) Radio Frequency termination point for cellular and 802.16 access technology. Mobility Manager (MM) An MIH Application enabled network node that supports and/or manages MNs for seamless handover. The MM has a high level view of the overall network configuration and operation. Rahman, et al. Expires - December 9, 2006 [Page 3] Internet Draft Transport of MIH Messages June 9, 2006 3. Network Model With the rapid emergence of wireless technologies it is often the case that there are several access technologies in a given geographical area. This mix of technologies makes seamless mobility more challenging as it requires the mobility protocols to account for the different access link layers. Figure 1 shows a representative network with cellular, WLAN and 802.16 access technologies which are all connected to the Internet. A MN is also shown which may move between the different access technologies based on coverage, QoS or other requirements. Finally, there is also an MM connected to the network which will aid the MN in its mobility decisions. Both the MM and MN contain an MIH Application and will be able to communicate MIH remote messages via UDP/IP. +--------+ | MM | +--------+ | | /-----------------------------------+-----\ / Internet \ \ / \--+----------+--------------+------------/ | | | ( ) ( ) ( ) (Cell.) (WLAN ) (802.16) (Network) (Network) (Network) ( ) ( ) ( ) ( ) ( ) ( ) | | | +---------+ +---------+ +---------+ |Cell. BS | | WLAN AP | |802.16 BS| +-------- + +---------+ +---------+ <--Mobility--> +--+ |MN| +--+ Figure 1: MIH Network Model Rahman, et al. Expires - December 9, 2006 [Page 4] Internet Draft Transport of MIH Messages June 9, 2006 4. Encapsulation Model Figure 2 illustrates the encapsulation principle for MIH messages. Essentially, the MIH message shall be inserted inside a UDP datagram which can fit in either an IPv4 or IPv6 packet. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +--------+--------+--------+--------+ + | | | | + IP | | + | Packet + UDP +----+----+----+----+ + | + | Datagram | MIH | | + | | | Message | | | + + | | + + | | +----+----+----+----+ | | + | | + | +-----------------------------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Structure of a UDP/IP Packet with an MIH Message 5. Host Environment Figure 3 shows an example of an MIH Application enabled MN. The MN supports both WLAN and cellular technologies. The MIH Application sends and receives MIH messages through UDP through a unique port number that shall be registered and obtained from IANA [6]. It is assumed that the MM's IP address will be discovered as per [7]. The following steps are involved in processing a MIH message that is received in an MN. The description starts from the network layer (IP) in the MN and assumes well functioning lower layers that receive the relevant lower layer frames: Rahman, et al. Expires - December 9, 2006 [Page 5] Internet Draft Transport of MIH Messages June 9, 2006 ------------------------------- | | | ------------- ------------ | | |MIH App. | |Other App.| | | ------@------ ------------ | | New \ | | Port \ | | Number\ | | -------- | | | UDP | | | -------- | | | | | -------- | | | IP | | | -------- | | | | | | | | | | ------ ------- | | |WLAN| |Cell.| | | ------ ------- | -----------|---------|--------- | | WLAN Interface <-----o o------> Cellular Interface Figure 3: An MIH Application Enabled MN 1. The Network layer (IP) receives an IP packet from it lower layers and strips off the IP header, processes it and then forwards it to the appropriate Transport protocol (UDP). 2. The Transport layer (UDP) then receives a UDP datagram. Its headers are in turn removed and processed. The UDP protocol then forwards the contents of its data field it to the appropriate Application layer. This is determined by the value of the destination port number. The MIH Application shall have a newly defined port number. Therefore, the MIH message would be forwarded to the MIH Application. 3. The MIH Application would then decode the MIH message according to the IEEE 802.21 specifications [1] and shall then react as required. The steps taken by the MN to transmit an MIH message are symmetric to the steps explained above and the flow shall be in the reverse path as follows: Rahman, et al. Expires - December 9, 2006 [Page 6] Internet Draft Transport of MIH Messages June 9, 2006 1. The MIH Application shall generate an MIH message (as specified in IEEE 802.21) and pass it to the Transport Layer (UDP) through the newly defined port. 2. The UDP shall encapsulate the data in a UDP datagram and shall set the header fields accordingly. 3. The datagram is then sent to the Network Layer (IP) where it is in turn encapsulated in an IP packet and all the header fields of the packet are set accordingly. This packet is then sent to the appropriate lower layer for transmission to the network. A network node such as an MM shall follow a similar process. 6. Protocol Details This section provides the details of MIH encapsulation in a UDP/IP packet, the transport mechanism used to quickly and reliably deliver MIH messages, examples and signaling scenarios between an MN and an MM. 6.1. MIH Encapsulation Message Figure 4 gives the details of an IPv6 packet that encapsulates the UDP datagram. However, an IPv4 packet can also be used since the encapsulation of a UDP datagram is the same in both cases. The UDP datagram (with an MIH message in it) resides in the IPv6 Data field. No changes are necessary to the IPv6 (or IPv4) packet headers for support of MIH message transport. Rahman, et al. Expires - December 9, 2006 [Page 7] Internet Draft Transport of MIH Messages June 9, 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|Tra. Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IPv6 Data + | | + +--------+--------+--------+--------+ + | | Source | Destination | | + | Port | Port | + | +--------+--------+--------+--------+ | + | | | + | | Length | Checksum | | + +--------+--------+--------+--------+ + | | UDP Data | | + | | + | + +----+----+----+----+ + | + | | | | + | | | MIH Message | | | + + | | + + | | +----+----+----+----+ | | + | | + | +-----------------------------------+ | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: IPv6 Packet Encapsulation of a UDP Datagram with a MIH Message 6.2. MIH Message Delivery Even though UDP does not provide reliable transport, this section shows how reliability can be implemented at the application layer (in this case the MIH Application) by using application timers. The mechanism involves an interaction between the sender and the receiver of an MIH message and is as follows: 1. The sender of a message may indicate that an ACK message should be returned by the receiver. This is done by setting ACK Request bit internally in the MIH message frame. The details of this field and other fields of the MIH message frame are specified in IEEE 802.21 [1]. An application timer is then set just after the Rahman, et al. Expires - December 9, 2006 [Page 8] Internet Draft Transport of MIH Messages June 9, 2006 transmission. If an ACK message arrives to the sender before the application timer expires, then the message is assumed to have been delivered correctly to the receiver. If an ACK does not arrive within the timeout period then the sender will retransmit the message until an ACK arrives. 2. The receiver (i.e. the MIH Application in the receiving node), upon receipt of message, will send an ACK message to acknowledge the receipt of an MIH message. This is done by setting the ACK Respond bit of the MIH message frame as specified in IEEE 802.21 [1] and inserting it into a UDP datagram. 3. The optional UDP Checksum field can also be used to check for errors in messages. If used and a message is found to be in error, the UDP will not forward the data to the application layer. This means that the receiving application will never receive the encapsulated MIH message and cannot send an ACK message. Thus the sender of the message would eventually retransmit after its timer expires. The next section discusses the values of the timers based on the type of MIH message that is sent. 6.3. MIH Application Timers Because the contents of certain MIH messages are more sensitive to delay than others, the values of the timers should be different for the three MIH message types. For example, messages that contain information (such as a list of neighboring network operators) can be sent periodically to update the mobile nodes and can have the longest timer. On the other hand, in a network controlled handover scenario for example, the MM may issue a command to a mobile node to handover to a target access technology. Since this node manages the available network resources, such a message would be required to arrive as fast as possible. Thus, the timer associated with command messages should be shorter than those of messages with information. Thus, three timers should be used depending on the type of MIH message that is sent: 1. Information Timer that is set after the transmission of a message that is related to Information Elements. 2. Event Timer that is set after the transmission of a message that is related to Events. 3. Command Timer that is set after the transmission of a message that is related to Commands. Rahman, et al. Expires - December 9, 2006 [Page 9] Internet Draft Transport of MIH Messages June 9, 2006 Shown below are the maximum timer values associated with the various types of messages: Message Content Timer Example Value Notes --------------- ----- ------------- ----- IS Information 6 Seconds T1 > T2 (Least Timer (T1) time sensitive) ES Event 4 Seconds T3 < T2 < T1 Timer (T2) CS Command 2 Seconds T3 < T2 (Most Timer (T3) time sensitive) 6.4. Signaling Scenario Example 1: Direct MIH Signaling over UDP/IP Figure 5 shows a signaling scenario, between an MN and an MM, illustrating the concepts developed earlier in this document. Note that UDP is used as the transport protocol for all IP based messages shown in the figure. MN Cellular WLAN MM | | | | (1) |<--Power on: Connect to WLAN--->| | | | | | (2) |--------Request for IS------------------------->| | | | | ACK not received | | | Timeout after T1 | | | | | | | (3) |--------Retransmit request--------------------->| | | | | |<------------Send ACK---------------------------| (4) | | | | |<---------Send IS response----------------------| (5) | | | | (6) |-------------Send ACK-------------------------->| | | | | Rahman, et al. Expires - December 9, 2006 [Page 10] Internet Draft Transport of MIH Messages June 9, 2006 | +++++++++++++++++++++++++++++++++++++++++ | ++++++++++ Case I- Network Controlled Handover ++++++++++++ | +++++++++++++++++++++++++++++++++++++++++ | | | | | (7) |-----Send ES----------------------------------->| | | | | ACK not received | | | Timeout after T2 | | | | | | | (8) |------Retransmit ES---------------------------->| | | | | |<------------Send ACK---------------------------| (9) | | | | |<------Send CS----------------------------------| (10) | | | | | | | ACK not received | | | Timeout after T3 | | | | |<--------Retransmit CS--------------------------| (11) | | | | (12) |-------------Send ACK-------------------------->| | | | | (13) |--------Send ES-------------------------------->| | | | | |<------------Send ACK---------------------------| (14) | | | | (15) |<--Continue--->| | | session over Cellular | | | | | | +++++++++++++++++++++++++++++++++++++++++ ++++++++++ Case II- Mobile Controlled Handover ++++++++++++ | +++++++++++++++++++++++++++++++++++++++++ | | | | | (7) |--------Send ES-------------------------------->| | | | | |<-----------------Send ACK----------------------| (8) | | | | (9) |<--Continue--->| | | session over cellular Figure 5: Direct Signaling Between an MN and an MM Over UDP/IP The signaling steps are explained below: 1. The MN powers up and connects to WLAN. Rahman, et al. Expires - December 9, 2006 [Page 11] Internet Draft Transport of MIH Messages June 9, 2006 2. The MIH Application sends a message containing a request for IS - the list of neighboring operators for the cellular link. It sets its Information Timer as soon as it sends the message. 3. Since the message contained a request for IS, the timer is set to T1 seconds. In this example the MN does not receive an ACK during this time and therefore retransmits the request and resets its Information Timer. 4. The MM transmits an ACK message to the MN which arrives before the Information Timer at the MN expires. 5. The MM sends a response message to the MN containing the list of neighboring cellular operators and sets its Information Timer. 6. The MN sends an ACK to the MM and it arrives before the Information Timer at the MM expires. After Step 6, there can be different actions that can be taken depending if a handover is network controlled or mobile controlled. Both cases are considered below: Case I - Network Controlled Handover 7. The MN informs the MM that its WLAN link is degrading and that it has detected a cellular link, by sending an MIH "Link Going Down" ES and "New Link Detected" ES. It then sets its Event Timer. 8. The MN’s timer expires after T2 seconds during which it does not receive an ACK from the MM. It then retransmits the ES and resets its Event Timer. 9. The MM sends an ACK message to the MN which receives it before the MN’s Event Timer expires. 10. The MM sends an MIH "Handover Command" to the MN indicating that the MN should handover to the detected cellular link. It sets its Command Timer. 11. The MM’s Command Timer expires after T3 since it did not receive an ACK. It therefore retransmits the MIH Command and resets its Command Timer. 12. The MN then sends an ACK which arrives before the MM’s Command Timer expires. Rahman, et al. Expires - December 9, 2006 [Page 12] Internet Draft Transport of MIH Messages June 9, 2006 13. The MN, after performing the necessary actions that completed the handover to the cellular link, sends an MIH "Link UP" ES to inform the MM about its completion of the handover process. It sets its Event Timer and waits for an ACK message. 14. The MM sends an ACK message to the MN and it arrives before the MN’s Event Timer expires. 15. The MN continues its IP connection over the cellular link. Case II - Mobile Controlled Handover 7. The MN sends an MIH "Link UP" ES to inform the MM about its completion of the handover process. It sets its Event Timer and waits for an ACK message. 8. The MM sends an ACK message to the MN and it arrives before the MN’s Event Timer expires. 9. The MN continues its IP connection over the cellular link. 6.5. Signaling Scenario 2: MIH Signaling via WLAN MIH Proxy Figure 6 shows the sequence of message exchanges between the UE and the MM with the MIH Application enabled WLAN acting as a Proxy. Every time a message is received from either the MM or the MN, the MIH Proxy in the WLAN is triggered and takes the necessary actions. See Section 6.6 for detailed functions of the MIH Proxy in the WLAN. The same reliability mechanism for UDP/IP transport that was previously discussed will be used between the WLAN and the MM. MN Cellular WLAN MM | | | | (1) |<--Power on: Connect to WLAN--->| | | | | | (2) |----Request for IS------------->| | | | | | | | +---------------------+ | | | +Inter-work L2 Message+ | | | +to UDP/IP Message + | | | +---------------------+ | | | | | (3) | | |---Forward---->| | | | IS request | Rahman, et al. Expires - December 9, 2006 [Page 13] Internet Draft Transport of MIH Messages June 9, 2006 | | | | | | | ACK not received | | | Timeout after T1 | | | | (4) | | |--Retransmit-->| | | | IS request | | | | | | | |<--Send ACK----| (5) | | | | | | |<--Send IS-----| (6) | | | response | | | | | (7) | | |---Send ACK--->| | | | | | | +---------------------+ | | | +Inter-work UDP/IP + | | | +Message to L2 Message+ | | | +---------------------+ | | | | | |<-----Forward IS response-------| | (8) | | | | (9) |------Send ES------------------>| | | | | | | | +---------------------+ | | | +Inter-work L2 Message+ | | | +to UDP/IP Message + | | | +---------------------+ | | | | | (10) | | |--Forward ES-->| | | | | | | | ACK not received | | | Timeout after T2 | | | | (11) | | |--Resend ES--->| | | | | | | |<---Send ACK---| (12) | | | | | | |<-Send CS------| (13) | | | | | | | ACK not received | | | Timeout after T3 | | | | | | |<--Resend CS---| (14) | | | | (15) | | |---Send ACK--->| | | | | Rahman, et al. Expires - December 9, 2006 [Page 14] Internet Draft Transport of MIH Messages June 9, 2006 | | +---------------------+ | | | +Inter-work UDP/IP + | | | +Message to L2 Message+ | | | +---------------------+ | | | | | |<-----Forward CS----------------| | (16) | | | | (17) |------Send ES------------------>| | | | | | | | +---------------------+ | | | +Inter-work L2 Message+ | | | +to UDP/IP Message + | | | +---------------------+ | | | | | (18) | | |--Forward ES-->| | | | | | | |<---Send ACK---| (19) | | | | (20) |<--Continue--->| | | session over cellular Figure 6: Signaling Between an MN and an MM via a WLAN Proxy The signaling steps are explained below for the network controlled handover case: 1. The MN powers up and connects to WLAN. 2. The MIH Application sends an L2 message containing a request for IS - the list of neighboring operators for the cellular link. The MN is aware that the WLAN supports MIH functionality through L2 signaling. 3. The WLAN inter-works the L2 message to UDP/IP message and sends the MIH message to the MM. It then sets its Information Timer. 4. An ACK does not arrive at the WLAN within T1 seconds. The WLAN thus retransmits the message to the MM and resets its Information Timer. 5. The MM sends an ACK message to the WLAN which receives it before the Information Timer expires. 6. The MM sends a response message to the WLAN that is to be delivered to the MN. The MM sets its Information Timer. Rahman, et al. Expires - December 9, 2006 [Page 15] Internet Draft Transport of MIH Messages June 9, 2006 7. The WLAN sends an ACK to acknowledge the receipt of the MIH message. The ACK arrives at the MM before its Information Timer expires. The WLAN performs the necessary steps to inter-work the message to the MN. 8. The message is inter-worked from the WLAN to the MN and sent via L2 Signaling. 9. The MN sends an MIH "Link Going Down" ES and "New Link Detected ES to the WLAN via L2 signaling. 10. The WLAN inter-works the ES to the MM, over UDP/IP, and sets its Event Timer. 11. An ACK does not arrive at the WLAN within T2 seconds. The WLAN thus retransmits the message to the MM and resets its Event Timer. 12. The MM sends an ACK to the WLAN to acknowledge receipt of the MIH message. The ACK arrives at the WLAN before the Event Timer expires. 13. The MM performs some internal actions and decides that the UE should handover to a cellular operator. The MM sends an MIH "Handover to Cellular Command" to WLAN which is to redirect the message to the MN. The MM sets its Command Timer. 14. An ACK does not arrive at the MM within T3 seconds. The MM thus retransmits the message to the WLAN and resets its Command Timer. 15. The WLAN sends an ACK to the MM. The ACK arrives before the MM’s Command Timer expires. 16. The WLAN inter-works the CS to the MN via L2 signaling. 17. The MN takes the necessary handover actions and completes the handover process to a cellular link. The MN sends an MIH "Link Handover Complete" ES via L2 signaling to the MM via the WLAN Proxy. 18. The WLAN inter-works the ES from the MN to the MM and sets its Event Timer. 19. The MM sends an ACK message to the WLAN which receives it before its Event Timer expires. 20. The MN continues its IP connection over the cellular link. Rahman, et al. Expires - December 9, 2006 [Page 16] Internet Draft Transport of MIH Messages June 9, 2006 The above scenarios show how reliability is implemented using timers (with different values corresponding to different MIH messages) and ACK messages at the application layer i.e. the MIH Application. Note however that the assumption I the examples was that each time a message is sent, the ACK Request bit in the MIH message frame was set, indicating that the receiver has to acknowledge receipt of the message. Implementers can choose not to set an ACK Request bit for every MIH message that is sent. Instead, an ACK Request bit can only be set as needed, for example, when sending an IS; this bit may not be set. On the other hand, when sending ES and CS, the ACK Request bit might be set because these messages are more sensitive relative to IS messages and thus require acknowledgement of receipt. 6.6. MIH Proxy Entity If an access network (e.g. WLAN) implements an MIH Application, it may inter-work (Proxy) L2 messages that it receives from the MN. It can also inter-work UDP/IP messages that it receives from the MM. When the Proxy Function in the access network receives L2 frames or UDP/IP packets, it checks to see if the underlying message is an MIH message or not. If the L2 frame or UDP/IP packet contains an MIH message, the MIH Application in the access network is then triggered to process the message. If the underlying message is not an MIH message, it is touted to its destination and the MIH Application is not triggered. The following steps are involved in inter-working L2 messages to UDP/IP messages in a WLAN network: 1. A WLAN frame containing the MIH message is received via the WLAN interface (L2 signaling) in the WLAN network. 2. The L1/L2 processing removes the WLAN frame header. 3. The encapsulated data is passed to the Proxy Function which recognizes it as an MIH message. The Proxy Function then triggers the MIH Application to which it then passes the message. 4. The MIH Application decodes the message and decides about the next actions to be executed. Knowing the message type, the MIH Application associates an application timer that is to be set when the message is redirected to the MM. The MIH message is then passed back to the Proxy Function. 5. The Proxy Function recognizes that the message is to be redirected to the MM. It then passes the message to the UDP/IP layer for encapsulation. Rahman, et al. Expires - December 9, 2006 [Page 17] Internet Draft Transport of MIH Messages June 9, 2006 6. The MIH message is encapsulated in a UDP Datagram, which in turn is inserted into an IP packet. The IP packet is then sent to the lower layers for transmission into the network. 7. The lower layers perform the necessary frame encapsulation of the IP packet and transmit the final data into the network. The above steps are represented by the “Inter-work L2 message to UDP/IP message” rectangles in Figure 6. When the WLAN receives an MIH message in an IP packet from the MM (that is to be directed to the MN), the reverse steps take place. This is represented by the “Inter- work UDP/IP message to L2 message” rectangles in Figure 6. 7. Interaction of MIH with Other Protocols It is important to note that the MIH does not provide IP Mobility. IP Mobility will be provided by Layer 3 (L3) protocols such as Mobile IP (MIP) or Session Initiation Protocol (SIP). What MIH provides is support of L3 mobility protocols by coordinating the actions of the lower layers in a standardized manner. For example, the MIH Application in an MN can trigger a MIP client to perform network discovery, as soon as possible, after the establishment of a new link layer connection. Also an MIH Application can set up multiple link layers in a coordinated fashion to allow true "make-before-break" handovers. 8. Security Considerations MIH remote messaging obviously involves the sending and receiving of messages. As a result, the security problems related to messaging in general are relevant here. MMs and MNS should use the appropriate IPSec features for all MIH message exchanges. 9. IANA Considerations IANA is requested to assign a value for the MIH Application Port Number in accordance with [6]. References [1] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D00.05, January 2006. [2] Hepworth, E., "Media Independent Handovers: Problem Statement", draft-hepworth-mipshop-mih-problem-statement-01 (work in progress), March 2006. Rahman, et al. Expires - December 9, 2006 [Page 18] Internet Draft Transport of MIH Messages June 9, 2006 [3] Sreemanthula, S., "Requirements for a Handover Information Service", draft-faccin-mih-infoserv-02 (work in progress), March 2006. [4] Sreemanthula, S., "Problem Statement and Requirements for Event and Command Services in Media Independent Handovers", draft- sreemanthula-es-cs-problem-02 (work in progress), March 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000. [7] Park, et al., "DHCP Option for Discovering IEEE 802.21 Information Service Location", draft-daniel-dhc-mihis-opt-01.txt", February 2006. Authors' Addresses Akbar Rahman InterDigital Communications Address: 1000 Sherbrooke West, 10th Floor Montreal, Quebec, Canada, H3A 3G4 Phone: 514-904-6270 Email: Akbar.Rahman@InterDigital.com Ulises Olvera-Hernandez InterDigital Communications Address: 1000 Sherbrooke West, 10th Floor Montreal, Quebec, Canada, H3A 3G4 Phone: 514-904-6282 Email: Ulises.Olvera-Hernandez@InterDigital.com Mahmoud Watfa InterDigital Communications Address: 1000 Sherbrooke West, 10th Floor Montreal, Quebec, Canada, H3A 3G4 Phone: 514-904-6257 Email: Mahmoud.Watfa@InterDigital Rahman, et al. Expires - December 9, 2006 [Page 19] Internet Draft Transport of MIH Messages June 9, 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Rahman, et al. Expires - December 9, 2006 [Page 20]