MIPSHOP Working Group A. Rahman Internet-Draft U. Olvera-Hernandez Expires: August 28, 2007 JC. Zuniga M. Watfa InterDigital Communications H.W. Kim SK Telecom February 28, 2007 Transport of Media Independent Handover Messages Over IP draft-rahman-mipshop-mih-transport-02.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 August 28, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Rahman, et al. Expires - August 28, 2007 [Page 1] Internet Draft Transport of MIH Messages February 28, 2007 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. Table of Contents 1. Introduction...............................................3 2. Terminology................................................3 3. Background on MIH Messages.................................4 4. UDP as Transport Mechanism.................................7 5. Network Model..............................................7 6. Discovery..................................................8 7. Encapsulation Model........................................8 8. Host Environment...........................................9 9. MIH Proxy Entity..........................................11 10. Transport Mechanism Details...............................12 10.1. MIH Message Encapsulation..............................12 10.2. MIH Message Delivery...................................13 10.3. MIH Application Retransmission Timers..................14 10.4. Signaling Scenario 1: Direct MIH Signaling over UDP/IP.15 10.5. Signaling Scenario 2: MIH Signaling via WLAN MIH Proxy.18 11. Interaction of MIH with Other Protocols...................22 12. NAT Traversal.............................................22 13. Fragmentation.............................................24 14. Security Considerations...................................24 15. IANA Considerations.......................................25 References......................................................25 Authors' Addresses..............................................26 Intellectual Property and Copyright Statements..................27 Rahman, et al. Expires – August 28, 2007 [Page 2] Internet Draft Transport of MIH Messages February 28, 2007 1. Introduction IEEE 802.21 working group is developing lower layer (i.e. below IP) services to enable seamless handover across different access technologies. Services are termed Information Services (IS), Event Services(ES), and Command Services (CS) [1]. These services are used by an MIH Application that can be located either in a Mobile Node (MN) or a Mobility Manager (MM) node. An important concept in [1] 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 described in [2]. An example of remote message exchange is when an 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 an 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 WMAN 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 [3]. The following terminology and abbreviations are used in this document. 802.21 A draft IEEE 802 standard for inter-technology mobility. Access Point (AP) A Layer 2 device that offers WLAN connectivity to an MN. Base Station (BS) Radio Frequency termination point for cellular and WMAN access technology. MIH Media Independent Handover. Rahman, et al. Expires – August 28, 2007 [Page 3] Internet Draft Transport of MIH Messages February 28, 2007 MIH Application Media Independent Handover Application that supports various services and intelligence for handover across multiple access technologies. 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. Mobile Node (MN) A mobile device that supports an MIH Application and multiple access technologies. WLAN Wireless Local Area Network, such as the ones defined in the IEEE 802.11 standard for wireless local area networks. WMAN Wireless Metropolitan Area Network, such as the ones defined in the IEEE 802.16 standard for broadband wireless metropolitan area networks. 3. Background on MIH Messages It is important to understand what fields the MIH message frames provide (as specified in IEEE 802.21) so as to re-use as much functionality as possible and focus mainly on solving transport related problems. MIH message frames use a common header for all types of services i.e. Information, Command, and Event. However, by setting some fields in this header to specific values, an MIH message can be identified as carrying a payload related to a specific service. Thus, there is no need to re-define specific headers for specific service type, and this existing common MIH header should be re- used at the MIH “layer” and is hence out of the transport solution scope. There are three relevant MIH protocol identifiers that are present in MIH message frames: 1. MIHF ID - uniquely defines MIHF endpoints and its use enables the MIH protocol to be transport agnostic. 2. Session ID - a 32-bit unique random number within a pair of MIHFs of a source and destination of a session request. Rahman, et al. Expires – August 28, 2007 [Page 4] Internet Draft Transport of MIH Messages February 28, 2007 3. Transaction ID - an identifier that is used with every MIH initiator and its response message. It is required to match each request, response or indication message and its acknowledgment. No new headers at the transport layer should be defined to accomplish the same goals that these identifiers already serve to meet. Instead, they should be re-used thereby eliminating such requirements from the transport layer. Other important fields that are present in the MIH frames are ACK Request and ACK Response that are used to optionally request for acknowledgements, and to acknowledge the receipt of messages respectively. Thus, a connectionless-oriented transport can be complemented with reliability by the re-use of these existing acknowledgement fields in MIH message frames. Another important requirement to consider is multiplexing – MIH multiplexing and transport multiplexing - as shown in Figure 1. Rahman, et al. Expires – August 28, 2007 [Page 5] Internet Draft Transport of MIH Messages February 28, 2007 +==========================+ | | |+---------+ +---------+ | ||MIH | |MIH | | ||User 1 | |User 2 |...| ||e.g. MIP | |e.g. SIP | | |+++++++++++ +++++++++++ | _ .............. | \ / | \__ : MIH : | \ / | _/ :Multiplexing: | +++++++++++++++++++++ | :............: | | MIH Function | | | | (IS, ES, CS) | | | +++++++++++++++++++++ | | /\ | .............. | || | : Transport : | || | :Multiplexing: | \/ | :............: | +++++++++++++++++++++ | --^-- | | Transport | | / \ +---------+ | | e.g. TCP, UDP | | | MIH | | +++++++++++++++++++++ | |.........| | /\ | |Transport| | || | |.........| | || | ---> | IP | | \/ | -------- / +---------+ | +++++++++++++++++++++ | / \ / | | IP |---|--- Internet - | +++++++++++++++++++++ | \ / \ +---------+ | | -------- \ | MIH | | | \ |.........| +==========================+ | |Transport| | |.........| \-> | IP | +---------+ Figure 1: MIH Multiplexing and Transport Mulitplexing MIH multiplexing is a requirement on the MIH layer, specifically between the MIH Function and an MIH User (as shown in Figure 1) and is therefore not a responsibility of the transport layer. In other words, it is the MIH Function that is locally responsible for relaying MIH messages to the appropriate user. Transport multiplexing involves sending a specific MIH message to the right MIH peer amongst several communicating peers. In IEEE 802.21, every MIH capable node is uniquely identified by its MIHF Identifier hence making the MIH protocol transport agnostic. Rahman, et al. Expires – August 28, 2007 [Page 6] Internet Draft Transport of MIH Messages February 28, 2007 Sending an MIH message (over IP) to a peer involves discovering the MIHF Identifier of the peer and its associated IP address; and then sending the message (in an IP packet) to the associated address. The traveling of this IP packet to the destination is nothing but regular IP routing. Thus, MIH transport multiplexing is taken care of at the IP layer and there is no need to further implement any functionality at the MIH transport layer. 4. UDP as Transport Mechanism UDP is widely used by many control protocols because it provides a very simple and fast transport mechanism. Since UDP does not provide for reliability, retransmission algorithms can be defined at the application layer to complement UDP if required. One example of UDP transport for a control protocol is the widely used Session Initiation Protocol (SIP), which commonly makes use of UDP as a transport mechanism. SIP implements reliability by making use of retransmissions and acknowledgement messages. The Simple Network Management Protocol (SNMP) is another control protocol that relies on UDP as a transport mechanism. UDP has also been proposed as the transport mechanism in the Network-based Localized Mobility Management (NETLMM) Working Group in IETF. Because of the proven advantages stated before and its wide adoption as transport for control protocols, this document proposes the use of UDP as transport for MIH messages. Moreover, the MIH protocol already provides several options that can be re-used with UDP to implement a simple, fast, and reliable (optional) transport mechanism for MIH messages. 5. 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 2 shows a representative network with cellular, WLAN and WMAN access technologies which are all connected to the Internet. Also shown is an MN 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. Rahman, et al. Expires – August 28, 2007 [Page 7] Internet Draft Transport of MIH Messages February 28, 2007 +--------+ | MM | +--------+ | /-----------------------------------+-----\ / Internet \ \ / \--+-------------+--------------+---------/ | | | ( ) ( ) ( ) (Cellular) (WLAN) (WMAN) (Network) (Network) (Network) ( ) ( ) ( ) ( ) ( ) ( ) | | | +---------+ +---------+ +---------+ |Cell. BS | | WLAN AP | | WMAN BS | +---------+ +---------+ +---------+ <--Mobility--> +--+ |MN| +--+ Figure 2: MIH Network Model 6. Discovery Prior to the exchange of MIH remote messages between peers, the discovery of a peer MIH node in the network must be done. Depending on the network architecture different discovery mechanisms may be possible. For example, if a network operator has an integrated network made up of cellular and WMAN technologies, there might not be a need for many MM nodes, thus only one such node can be deployed and an MIH peer can interact with the MM node via IP regardless if the underlying connection is cellular or WMAN. If this is the case, the address of an MM may be hard coded in an MIH enabled device. If there is a need for multiple MM nodes (e.g. there is one MM per access technology type), the discovery of MM nodes may be done using DHCP as proposed in [4]. 7. Encapsulation Model Figure 3 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. Rahman, et al. Expires – August 28, 2007 [Page 8] Internet Draft Transport of MIH Messages February 28, 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + +--------+--------+--------+--------+ + | | | | + IP | | + | Packet + UDP +----+----+----+----+ + | + | Datagram | MIH | | + | | | Message | | | + + | | + + | | +----+----+----+----+ | | + | | + | +-----------------------------------+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Structure of a UDP/IP Packet with an MIH Message 8. Host Environment Figure 4 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 a unique UDP port, which number shall be registered and obtained from IANA [5]. It is assumed that the MM's IP address will be discovered as discussed in Section 6. Rahman, et al. Expires – August 28, 2007 [Page 9] Internet Draft Transport of MIH Messages February 28, 2007 ------------------------------- | | | ------------- ------------ | | |MIH App. | |Other App.| | | ------@------ ------------ | | New \ | | Port \ | | Number\ | | -------- | | | UDP | | | -------- | | | | | -------- | | | IP | | | -------- | | | | | | | | | | ------ ------- | | |WLAN| |Cell.| | | ------ ------- | -----------|---------|--------- | | WLAN Interface <-----o o------> Cellular Interface Figure 4: An MIH Application Enabled MN The following steps are involved in processing an MIH message that is transmitted from an MN: 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 shall be then sent to the Network Layer (IP) where it shall in turn be encapsulated in an IP packet and all the header fields of the packet shall be set accordingly. This packet shall then be sent to the appropriate lower layer for transmission through the network. The steps taken by the MN to receive an MIH message are symmetric to the steps explained above and the flow shall be in the reverse path as follows: 1. Upon reception of a packet, the Network layer (IP) shall strip Rahman, et al. Expires – August 28, 2007 [Page 10] Internet Draft Transport of MIH Messages February 28, 2007 off the IP header, process it and forward it to the transport protocol (UDP). 2. Upon reception of the UDP datagram, the transport layer (UDP) shall process the packet and shall forward the contents of its data field it to the MIH Application. Since the MIH Application shall have a newly defined port number, the MIH message would be forwarded to the MIH Application through that port. 3. The MIH Application shall then decode the MIH message according to the IEEE 802.21 specification [1] and shall then react as required. A network node such as an MM shall follow a similar process. 9. 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. Similarly, it can also inter-work UDP/IP messages that it receives from the MM. Thus, when the Proxy Function in the access network receives L2 frames or UDP/IP packets, it shall verify 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 shall then be triggered to process the message. If the underlying message is not an MIH message, it shall be routed to its destination and the MIH Application shall not be 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. The MIH message is then passed back to the Proxy Function. 5. The Proxy Function recognizes that the message is to be Rahman, et al. Expires – August 28, 2007 [Page 11] Internet Draft Transport of MIH Messages February 28, 2007 redirected to the MM. It then passes the message to the UDP/IP layer for encapsulation. 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 7. 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 7. 10. Transport Mechanism 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. 10.1. MIH Message Encapsulation Figure 5 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 – August 28, 2007 [Page 12] Internet Draft Transport of MIH Messages February 28, 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 5: IPv6 Packet Encapsulation of a UDP Datagram with a MIH Message 10.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 retransmission 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 retransmission timer is then set Rahman, et al. Expires – August 28, 2007 [Page 13] Internet Draft Transport of MIH Messages February 28, 2007 just after the transmission. If an ACK message arrives to the sender before the 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 (a few times as described in Section 9.3) until an ACK arrives. 2. The receiver (i.e. the MIH Application in the receiving node), upon receipt of a message (whose ACK Request bit field is set to 1), 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 retransmission timer expires. The next section discusses the values of the retransmission timers based on the type of MIH message that is sent. 10.3. MIH Application Retransmission Timers Because the contents of certain MIH messages are more sensitive to delay than others, the values of the retransmission 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 retransmission 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 retransmission timer associated with command messages should be shorter than those of messages with information. Thus, three retransmission 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. Rahman, et al. Expires – August 28, 2007 [Page 14] Internet Draft Transport of MIH Messages February 28, 2007 3. Command Timer that is set after the transmission of a message that is related to Commands. Shown below are example retransmission timer values associated with the various types of messages. They represent the round-trip time i.e. the time in which a message is sent and its corresponding ACK is received. Message Content Timer Example Value Notes --------------- ----- ------------- ----- Information Information 1000 ms T1 > T2 (Least Service (IS) Timer (T1) time sensitive) Event Event 500 ms T3 < T2 < T1 Service (ES) Timer (T2) Command Command 100 ms T3 < T2 (Most Service (CS) Timer (T3) time sensitive) In order to prevent congestion, a sending node should attempt only a certain number of retransmissions. For example, if a sender does not receive an ACK for a previously sent message, it may retransmit the same message a few times. In the case the sender does not receive an ACK after the last retransmission, it could perform a back off process before starting another retry session. 10.4. Signaling Scenario Example 1: Direct MIH Signaling over UDP/IP Figure 6 shows a signaling scenario, between an MN and an MM, illustrating the concepts developed earlier in this document. Note that UDP is assumed to be 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--------------------->| | | | | Rahman, et al. Expires – August 28, 2007 [Page 15] Internet Draft Transport of MIH Messages February 28, 2007 |<------------Send ACK---------------------------| (4) | | | | |<---------Send IS response----------------------| (5) | | | | (6) |-------------Send ACK-------------------------->| | | | | | +++++++++++++++++++++++++++++++++++++++++ | ++++++++++ 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) Rahman, et al. Expires – August 28, 2007 [Page 16] Internet Draft Transport of MIH Messages February 28, 2007 | | | | (9) |<--Continue--->| | | session over cellular | | | | | | Figure 6: 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. 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 retransmission 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. Rahman, et al. Expires – August 28, 2007 [Page 17] Internet Draft Transport of MIH Messages February 28, 2007 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. 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. 10.5. Signaling Scenario 2: MIH Signaling via WLAN MIH Proxy Figure 7 shows the sequence of message exchanges between the MN 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--->| | | | | | Rahman, et al. Expires – August 28, 2007 [Page 18] Internet Draft Transport of MIH Messages February 28, 2007 (2) |----Request for IS------------->| | | | | | | | +---------------------+ | | | +Inter-work L2 Message+ | | | +to UDP/IP Message + | | | +---------------------+ | | | | | (3) | | |---Forward---->| | | | IS request | | | | | | | | 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) Rahman, et al. Expires – August 28, 2007 [Page 19] Internet Draft Transport of MIH Messages February 28, 2007 | | | | | | | ACK not received | | | Timeout after T3 | | | | | | |<--Resend CS---| (14) | | | | (15) | | |---Send ACK--->| | | | | | | +---------------------+ | | | +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 7: 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. Rahman, et al. Expires – August 28, 2007 [Page 20] Internet Draft Transport of MIH Messages February 28, 2007 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. 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. Rahman, et al. Expires – August 28, 2007 [Page 21] Internet Draft Transport of MIH Messages February 28, 2007 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. The above scenarios show how reliability is implemented using retransmission 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 in 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. 11. 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. 12. NAT Traversal Nodes in private networks or behind NATs can have problems with peer to peer communication because they do not use globally routable IP addresses. The most common NAT problem is that a NAT only allows packets associated with outbound sessions to traverse the NAT. Incoming packets will be dropped unless identified as part of an ongoing session that was initiated from within the private network. Since NAT behavior is not standardized, vendor specific NATs can act differently in this regard. For example, some NATs implement endpoint-independent mapping where the same public IP address and port are used for communication with any host on the Internet. Other Rahman, et al. Expires – August 28, 2007 [Page 22] Internet Draft Transport of MIH Messages February 28, 2007 NATs implement address-dependent and port-dependent mappings where the NAT reuses the same public IP and port for successive packets to a specific external IP and port. Moreover, NATs tend to delete the binding of tuple to if packets are not exchanged between the peers during a certain configurable time interval. NATs can have different keep-alive time depending on their implementation or configuration. It is important to note that MIH payload (to be transported over IP) does not carry IP address or port related information, hence no Application Layer Gateway is required on the NAT. Therefore, the faced NAT challenge related to MIH transport is to setup a peer-to- peer communication between MIH enabled nodes. Because NATs’ functionalities vary, the best NAT solution should be adopted from the existing NAT traversal techniques. The following section discusses two main scenarios of the NAT deployment and possible traversal solution – the initiator (MIH enabled MN) of a communication is behind a NAT, and both the MIH enabled nodes (MN and MM) are behind NATs. In the network model shown in Section 5, the MM is a discrete entity which provides services once an MN discovers and starts a session with it. Since the MM provides MIH services to many MNs, the MM should be easily reachable (by MNs), thus in a typical deployment scenario, an MM would not be behind a NAT. In the case where an MN behind a NAT initiates a session with the MM (which is not behind a NAT), incoming packets from the MM (to the MN) will traverse the NAT with no problems. This is because these packets will be identified as part of an ongoing session that was initiated from within the NAT. Therefore no changes should be done to NATs to support MIH remote message exchange. However, the MN should send keep-alive messages to the MM in order to ensure that the NAT keeps the same binding of tuple to the tuple. Even though it is not foreseen that MM may also be behind a NAT, this possibility is nevertheless considered. There are several solutions for clients, behind NATs, that want to establish peer-to-peer communication (over UDP/IP). One widely used solution is the “UDP Hole Punching” technique which uses a server (third party, usually a STUN [6] server) with a reachable public IP address to establish direct (un-relayed) communication between clients behind NATs. Another solution is to use a third party relay server that relays MIH messages between two peers in question. This is useful when NATs have Rahman, et al. Expires – August 28, 2007 [Page 23] Internet Draft Transport of MIH Messages February 28, 2007 an address and port dependent mapping behavior. A STUN server can be used as a relay server as discussed in [7]. It is evident that NATs’ behaviors are not standardized and therefore particular NAT traversal solutions might not work with certain NATs. However, [8] defines a set of requirements that (expectedly) makes NATs generally more “friendly” to applications. For both scenarios i.e. whether one or both MIH capable nodes are behind NATs, the most suitable NAT traversal solution should be adopted, and this depends on the type of NATs that are deployed within networks. 13. Fragmentation There are three MIH services (as specified in IEEE 802.21), Event, Command, and Information Services. Event and Command Service messages are usually small in size and therefore a UDP datagram carrying such a message will not require fragmentation. The size of Information Service message can be larger than that of Event or Command Service messages; however the recommendation in IEEE 802.21 is to use Information Services that are as small as possible to satisfy a handover operation. In the case where a message carrying an Information Service is larger than the MTU, fragmentation may be done at the IP layer. In IP fragmentation, the loss of one IP fragment requires the retransmission of the original UDP datagram. Thus, the application retransmission timers defined in this document could be used with IP fragmentation (if needed) to trigger retransmissions in the event of lost IP fragments. 14. 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. IPSec provides security (at the network layer) for the application and transport layers and its main features are authentication, confidentiality, integrity, and anti-replay. IPsec is obligatory for IPv6 and is optional for IPv4. After the discovery of the MM by an MN, both peers can perform the Internet Key Exchange (IKE) protocol which is an important step of the IPSec security protocol. It allows the MM and MN to agree on the authentication and encryption methods. The peers also agree on a security key to use and the duration of its use before replacing the key with a new one. The IPSec Encapsulation Security Payload (ESP) can thus be used to authenticate MIH messages, provide confidentiality, integrity, and protection against replay attacks. Also, the IPSec Authentication Header (AH) can be used to provide Rahman, et al. Expires – August 28, 2007 [Page 24] Internet Draft Transport of MIH Messages February 28, 2007 authentication, integrity, and anti-replay, but no confidentiality. Also, ESP and AH can be used in combination at the same time. However, if an MIH capable node is behind a NAT, IPSec AH must not be used since it protects the outer IP address and is thus incompatible with NATs. In such a scenario, IPSec ESP should be used and should be encapsulated in UDP as discussed in [9]. 15. IANA Considerations IANA is requested to assign a value for the UDP MIH Application Port Number in accordance with [5]. References [1] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D04.00, February 2007. [2] Melia, et al., "Mobility Independent Services: Problem Statement", draft-ietf-mipshop-mis-ps-00, (work in progress), July 11, 2007. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Park, et al., "DHCP Option for Discovering IEEE 802.21 Information", draft-daniel-dhc-mihis-opt-02.txt, (work in progress), March 10, 2007. [5] Narten & Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [6] Rosenberg, et al., "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", Standards Track, RFC 3489, March 2003. [7] Rosenberg, et al., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", draft-ietf-behave-turn-02, (work in progress), April 9, 2007. [8] Audet & Jennings, “Network Address Translation (NAT) Behavioral Requirement for Unicast UDP”, BCP 127, RFC 4787, January 2007. [9] Huttunen, et al, "UDP Encapsulation of IPsec ESP Packets", Standards Track, RFC 3948, January 2005. Rahman, et al. Expires – August 28, 2007 [Page 25] Internet Draft Transport of MIH Messages February 28, 2007 Authors' Addresses Akbar Rahman InterDigital Communications Address: 1000 Sherbrooke West, 10th Floor Montreal, Quebec, Canada, H3A 3G4 Phone: +1-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: +1-514-904-6282 Email: Ulises.Olvera-Hernandez@InterDigital.com Juan Carlos Zuniga InterDigital Communications Address: 1000 Sherbrooke West, 10th Floor Montreal, Quebec, Canada, H3A 3G4 Phone: +1-514-904-6251 Email: JuanCarlos.Zuniga@InterDigital.com Mahmoud Watfa InterDigital Communications Address: 1000 Sherbrooke West, 10th Floor Montreal, Quebec, Canada, H3A 3G4 Phone: +1-514-904-6257 Email: Mahmoud.Watfa@InterDigital Hyun-Wook Kim SK Telecom Address: Terminal Device and Access Network R&D Center, South Korea Phone: +82-2-6100-5677 Email: hwkim@sktelecom.com Rahman, et al. Expires – August 28, 2007 [Page 26] Internet Draft Transport of MIH Messages February 28, 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Rahman, et al. Expires – August 28, 2007 [Page 27]