One document matched: draft-rahman-mipshop-mih-transport-03.txt
Differences from draft-rahman-mipshop-mih-transport-02.txt
MIPSHOP Working Group A. Rahman
Internet-Draft U. Olvera-Hernandez
Expires: January 1, 2008 JC. Zuniga
M. Watfa
InterDigital Communications
H.W. Kim
SK Telecom
July 5, 2007
Transport of Media Independent Handover Messages Over IP
draft-rahman-mipshop-mih-transport-03.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 January 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Rahman, et al. Expires Januaray 1, 2008 [Page 1]
Internet-Draft Transport of MIH Messages July 5, 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 Function 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
Disclaimer of Validity..........................................27
Copyright Statement.............................................27
Rahman, et al. Expires January 1, 2008 [Page 2]
Internet-Draft Transport of MIH Messages July 5, 2007
1. Introduction
The IEEE 802.21 working group is focused upon 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 Function 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 January 1, 2008 [Page 3]
Internet-Draft Transport of MIH Messages July 5, 2007
Mobility Manager (MM)
An MIH-capable 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 Function 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 which 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. 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
Rahman, et al. Expires January 1, 2008 [Page 4]
Internet-Draft Transport of MIH Messages July 5, 2007
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.
+==========================+
|+---------+ +---------+ |
||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 |
| | | | | Function|
| +++++++++++++++++++++ | |.........|
| /\ | |Transport|
| || | |.........|
| || | ---> | IP |
| \/ | -------- / +---------+
| +++++++++++++++++++++ | / \ /
| | IP |---|--- Internet -
| +++++++++++++++++++++ | \ / \ +---------+
| | -------- \ | MIH |
| | \ | Function|
| | \ |.........|
+==========================+ | |Transport|
| |.........|
\-> | IP |
+---------+
Figure 1: MIH Multiplexing and Transport Mulitplexing
Rahman, et al. Expires January 1, 2008 [Page 5]
Internet-Draft Transport of MIH Messages July 5, 2007
MIH multiplexing is a requirement on the MIH layer, specifically
between the MIH Function and an MIH User (as shown in Figure 1).
The MIH Function is, therefore, responsible for directing any
MIH messages to the MIH User.
In IEEE 802.21, every MIH-capable node is uniquely identified
by its MIH Function Identifier. Therefore, sending an MIH message
to a peer involves discovery of the peer's MIHF and its associated
IP address. Furthermore, sending the message (in an IP packet) to
the associated address involves traditional IP routing (i.e.
transport multiplexing).
Therefore the MIH multiplexing occurs locally within an MIH-
capable node between the MIH Function and the MIH Users. Whereas
Transport multiplexing refers to regular IP routing.
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.
Due to the proven advantages stated above 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 where several access technologies exist within a geographical
area. This mix of technologies makes seamless mobility more
challenging, as it requires the mobility protocols to account for the
Rahman, et al. Expires January 1, 2008 [Page 6]
Internet-Draft Transport of MIH Messages July 5, 2007
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 (Note: a given
network can contain more than one MM entity). Both the MM and MN
contain an MIH Function and will be able to communicate via MIH
remote messages using UDP/IP transport protocols.
+--------+
| 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 (such as WiMAX),
there might not be a need for many MM nodes, thus only one such node
can be deployed. Hence an MIH peer can interact with the MM node via
IP regardless of whether the underlying connection is cellular or
WMAN.
Rahman, et al. Expires January 1, 2008 [Page 7]
Internet-Draft Transport of MIH Messages July 5, 2007
In the case where there is only one MM, then its IP 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] or using DNS
address resolution methods.
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.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +--------+--------+--------+--------+ +
| | | |
+ 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 Function enabled MN. The MN
supports both WiMAX and cellular technologies. The MIH Function sends
and receives MIH messages through a unique UDP port, for which the
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 January 1, 2008 [Page 8]
Internet-Draft Transport of MIH Messages July 5, 2007
-------------------------------
| |
| ------------- ------------ |
| |MIH Func. | |Other App.| |
| ------------- ------------ |
| New \ |
| Port \ |
| Number\ |
| @------- |
| | UDP | |
| -------- |
| | |
| -------- |
| | IP | |
| -------- |
| | | |
| | | |
| ------- ------- |
| |WiMAX| |Cell.| |
| ------- ------- |
-----------|---------|---------
| |
WiMAX Interface <-----o o------> Cellular Interface
Figure 4: An MIH Function Enabled MN
The following steps are involved in processing an MIH message that is
transmitted from an MN:
1. The MIH Function 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:
Rahman, et al. Expires January 1, 2008 [Page 9]
Internet-Draft Transport of MIH Messages July 5, 2007
1. Upon reception of a packet, the Network layer (IP) shall strip
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 Function. Since the MIH Function
shall have a newly defined port number, the MIH message would be
forwarded to the MIH Function through that port.
3. The MIH Function 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 Function, 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 Function 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 Function 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 Function to which it then passes the message.
4. The MIH Function 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 January 1, 2008 [Page 10]
Internet-Draft Transport of MIH Messages July 5, 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 January 1, 2008 [Page 11]
Internet-Draft Transport of MIH Messages July 5, 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 Function) by using 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]. A retransmission timer is then set
Rahman, et al. Expires January 1, 2008 [Page 12]
Internet-Draft Transport of MIH Messages July 5, 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 Function 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 Function 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 January 1, 2008 [Page 13]
Internet-Draft Transport of MIH Messages July 5, 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--------------------->|
| | | |
|<------------Send ACK---------------------------| (4)
| | | |
Rahman, et al. Expires January 1, 2008 [Page 14]
Internet-Draft Transport of MIH Messages July 5, 2007
|<---------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)
| | | |
(9) |<--Continue--->| | |
session over cellular | |
| | | |
Figure 6: Direct Signaling Between an MN and an MM over UDP/IP
Rahman, et al. Expires January 1, 2008 [Page 15]
Internet-Draft Transport of MIH Messages July 5, 2007
The signaling steps are explained below:
1. The MN powers up and connects to WLAN.
2. The MIH Function 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.
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.
Rahman, et al. Expires January 1, 2008 [Page 16]
Internet-Draft Transport of MIH Messages July 5, 2007
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 Function 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 + |
| | +---------------------+ |
Rahman, et al. Expires January 1, 2008 [Page 17]
Internet-Draft Transport of MIH Messages July 5, 2007
| | | |
(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)
| | | |
| | | ACK not received
| | | Timeout after T3
| | | |
| | |<--Resend CS---| (14)
| | | |
(15) | | |---Send ACK--->|
| | | |
Rahman, et al. Expires January 1, 2008 [Page 18]
Internet-Draft Transport of MIH Messages July 5, 2007
| | +---------------------+ |
| | +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 Function 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.
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.
Rahman, et al. Expires January 1, 2008 [Page 19]
Internet-Draft Transport of MIH Messages July 5, 2007
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.
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 Function. 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
Rahman, et al. Expires January 1, 2008 [Page 20]
Internet-Draft Transport of MIH Messages July 5, 2007
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 Function
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 Function 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
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 <private IP, private
port> tuple to <public IP, public port> 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.
Rahman, et al. Expires January 1, 2008 [Page 21]
Internet-Draft Transport of MIH Messages July 5, 2007
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 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.
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 <private IP, private port> tuple to the <public
IP, public port> tuple. Keep-alive messages can be any periodic
message sent to generate NAT activity. Such activity forces the NAT
to assume that a session is still active and that the tuple should
not be deleted. As specified in [8], keep-alive messages must be
sent within 2 minutes of the previously sent keep-alive message.
Another scenario may be defined such that the MM is also be behind
a NAT. 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 an address and
port dependent mapping behavior. (Note: 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.
Rahman, et al. Expires January 1, 2008 [Page 22]
Internet-Draft Transport of MIH Messages July 5, 2007
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.
A typical MTU can carry 1500 bytes of information. Hence a message
carrying Event or Command Service content, which can typically reach
up to 70 bytes, will not require any fragmentation. However, in the
case where a message carrying Information Service content is larger
than the specified amount, fragmentation may be performed at the IP
layer.
In IP fragmentation, the loss of one IP fragment requires the
retransmission of the original UDP datagram. Retransmissions are
triggered using the application retransmission timers defined in this
document.
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
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
Rahman, et al. Expires January 1, 2008 [Page 23]
Internet-Draft Transport of MIH Messages July 5, 2007
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 Function 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/D06.00, June 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 January 1, 2008 [Page 24]
Internet-Draft Transport of MIH Messages July 5, 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 January 1, 2008 [Page 25]
Internet-Draft Transport of MIH Messages July 5, 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Rahman, et al. Expires January 1, 2008 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-24 06:05:50 |