[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]
Versions: (draft-melia-mipshop-mstp-solution)
00 01 02 03 04 05 06 07 08 09 10 11
12 RFC 5677
Mipshop WG T. Melia, Ed.
Internet-Draft CISCO
Intended status: Standards Track G. Bajko
Expires: November 13, 2008 Nokia
S. Das
Telcordia Technologies Inc.
N. Golmie
NIST
JC. Zuniga
InterDigital Communications, LLC
May 12, 2008
Mobility Services Framework Design
draft-ietf-mipshop-mstp-solution-04
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 November 13, 2008.
Abstract
This document describes a design solution for the IEEE 802.21 Media
Independent Handover (MIH) protocol that addresses identified issues
associated with the transport of MIH messages. The document
describes mechanisms for mobility service (MoS) discovery and
transport layer mechanisms for the reliable delivery of MIH messages.
Melia, et al. Expires November 13, 2008 [Page 1]
Internet-Draft MSFD May 2008
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 6
3.1. Scenario S1: Home Network MoS . . . . . . . . . . . . . . 6
3.2. Scenario S2: Visited Network MoS . . . . . . . . . . . . . 6
3.3. Scenario S3: Roaming MoS . . . . . . . . . . . . . . . . . 7
3.4. Scenario S4: Third party MoS . . . . . . . . . . . . . . . 7
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 10
5. MoS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. MoS Discovery when MN and MoSh are in the home network
(Scenario S1) . . . . . . . . . . . . . . . . . . . . . . 11
5.2. MoS Discovery when MN is in visited network and MoSv
is also in visited network (Scenario S2) . . . . . . . . . 12
5.3. MOS Discovery when the MN is in a visited Network and
Services are at the Home network (Scenario S3) . . . . . . 13
5.4. MoS discovery when MIH services are in a 3rd party
remote network (scenario S4) . . . . . . . . . . . . . . . 16
6. MIH Transport Options . . . . . . . . . . . . . . . . . . . . 17
6.1. MIH Message size . . . . . . . . . . . . . . . . . . . . . 18
6.2. MIH Message rate . . . . . . . . . . . . . . . . . . . . . 19
6.3. Retransmission . . . . . . . . . . . . . . . . . . . . . . 19
6.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 19
6.5. General guidelines . . . . . . . . . . . . . . . . . . . . 20
7. Operation Flows . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Melia, et al. Expires November 13, 2008 [Page 2]
Internet-Draft MSFD May 2008
1. Introduction
This document proposes a solution to the issues identified in the
problem statement document [RFC5164] for the layer 3 transport of
IEEE 802.21 MIH protocols.
The MIH Layer 3 transport problem is divided in two main parts: the
discovery of a node that supports specific Mobility Services (MoS)
and the transport of the information between a mobile node (MN) and
the discovered node. The discovery process is required for the MN to
obtain the information needed for MIH protocol communication with a
peer node. The information includes the transport address (e.g., the
IP address) of the peer node and the types of MoS provided by the
peer node.
This document lists the major MoS deployment scenarios. It describes
the solution architecture, including the MSTP reference model and
MIHF identifiers. MoS discovery procedures explain how the MN
discovers MoS both in its home network or while being connected to a
remote network. The remainder of this document describes the MIH
transport architecture, example message flows for several signaling
scenarios, and security issues.
2. Terminology
The following acronyms and terminology are used in this document:
MIH Media Independent Handover: the handover support architecture
defined by the IEEE 802.21 working group that consists of the MIH
Function (MIHF), MIH Network Entities and MIH protocol messages.
MIHF Media Independent Handover Function: a switching function that
provides handover services including the Event Service (ES),
Information Service (IS), and Command Service (CS), through
service access points (SAPs) defined by the IEEE 802.21 working
group [IEEE80221].
MIHF User An entity that uses the MIH SAPs to access MIHF services,
and which is responsible for initiating and terminating MIH
signaling.
MIHFID Media Independent Handover Function Identifier: an identifier
required to uniquely identify the MIHF endpoints for delivering
mobility services (MoS); it is implemented as either a FQDN or
NAI.
Melia, et al. Expires November 13, 2008 [Page 3]
Internet-Draft MSFD May 2008
MoS Mobility Services: those services, as defined in the MIH problem
statement document [RFC5164] , which includes the MIH IS, CS, and
ES services defined by the IEEE 802.21 standard.
MoSh: Mobility Services assigned in the mobile node's Home Network
MoSv: Mobility Services assigned in the Visited Network, which is
any network other than the mobile node's home network
MoS3: Mobility Services assigned in a 3rd Party Network, which is a
network that is neither the Home Network nor the current Visited
Network.
MN Mobile Node: an Internet device whose location changes, along with
its point of connection to the network.
MSTP Mobility Services Transport Protocol: a protocol that is used
to deliver MIH protocol messages from an MIHF to other MIH-aware
nodes in a network.
IS Information Service: a MoS that originates at the lower or upper
layers of the protocol stack and sends information to the local or
remote upper or lower layers of the protocol stack. It can use
secure or insecure ports to transport information elements (IEs)
and information about various neighboring nodes.
ES Event Service: a MoS that originates at a remote MIHF or the lower
layers of protocol stack and sends information to the local MIHF
or local higher layers. The purpose of the ES is to report
changes in link status (e.g. Link Going Down messages) and
transmission status.
CS Command Service: a MoS that sends commands from the remote MIHF or
local upper layers to the local lower layers of the protocol stack
to switch links or to get link status.
FQDN: Fully-Qualified Domain Name: a complete domain name for a host
on the Internet, consisting of a host name followed by a domain
name (e.g. myexample.example.org)
NAI Network Access Identifier: the user ID that a user submits
during PPP authentication. For mobile users, the NAI identifies
the user and helps to route the authentication request message.
NAT Network Address Translator: A device that implements the Network
Address Translation function described in [RFC3022], in which
local or private network layer addresses are mapped to valid
network addresses and port numbers.
Melia, et al. Expires November 13, 2008 [Page 4]
Internet-Draft MSFD May 2008
DHCP Dynamic Host Configuration Protocol: a protocol described in
[RFC2131] that allows Internet devices to obtain IP addresses,
subnet masks, default gateway addresses, and other IP
configuration information from DHCP servers.
DNS Domain Name System: a protocol described in [RFC1035] that
translates domain names to IP addresses.
AAA Authentication, Authorization and Accounting: a set of network
management services that respectively determine the validity of a
user's ID, determine whether a user is allowed to use network
resources, and track users' use of network resources.
Home AAA AAAh: an AAA server located on the MN's home network.
Visited AAA AAAv: an AAA server located a visited network that is
not the MN's home network.
MIH ACK MIH Acknowledgement Message: a MIH signaling message that a
MIHF sends in response to an MIH message from a sending MIHF, when
UDP is used as the MSTP.
PoS Point of Service, a network-side MIHF instance that exchanges
MIH messages with a MN-based MIHF.
NAS Network Access Server: a server to which a MN initially connects
when it is trying to gain a connection to a network and which
determines whether the MN is allowed to connect to the NAS's
network.
UDP User Datagram Protocol: a connectionless transport layer
protocol used to send datagrams between a source and a destination
at a given port, defined in RFC 768.
TCP Transmission Control Protocol: a stream-oriented transport layer
protocol that provides a reliable delivery service with congestion
control, defined in RFC 793.
RTT Round-Trip Time: an estimation of the time required for a
segment to travel from a source to a destination and an
acknowledgement to return to the source that is used by TCP in
connection with timer expirations to determine when a segment is
considered lost and should be resent.
MTU Maximum Transmission Unit: the largest size packet that can be
sent on a network without requiring fragmentation [RFC1191].
Melia, et al. Expires November 13, 2008 [Page 5]
Internet-Draft MSFD May 2008
TLS Transport Layer Security Protocol: an application layer protocol
that assures privacy and data integrity between two communicating
network entities [RFC4346].
3. Deployment Scenarios
This section describes the various possible deployment scenarios for
the MN and the MoS. The relative positioning of MN and MoS affects
MoS discovery as well as the performance of the MIH signaling
service.
3.1. Scenario S1: Home Network MoS
In this scenario, the MN and the services are located in the home
network. We refer to this set of services as MoSh as in Figure 1.
The MoSh can be located at the access network the MN uses to connect
to the home network, or it can be located elsewhere.
+--------------+ +====+
| HOME NETWORK | |MoSh|
+--------------+ +====+
/\
||
\/
+--------+
| MN |
+--------+
Figure 1: MoS in the Home network
3.2. Scenario S2: Visited Network MoS
In this scenario, the MN is in the visited network and mobility
services are provided by the visited network. We refer to this as
MoSv as shown in Figure 2.
Melia, et al. Expires November 13, 2008 [Page 6]
Internet-Draft MSFD May 2008
+--------------+
| HOME NETWORK |
+--------------+
/\
||
\/
+====+ +-----------------+
|MoSv| | VISITED NETWORK |
+====+ +-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 2: MoSV in the Visited Network
3.3. Scenario S3: Roaming MoS
In this scenario, the MN is located in the visited network and all
MIH services are provided by the home network, as shown in Figure 3.
+====+ +--------------+
|MoSh| | HOME NETWORK |
+====+ +--------------+
/\
||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 3: MoS provided by the home while in visited
3.4. Scenario S4: Third party MoS
In this scenario, the MN is in its home network or in a visited
network and services are provided by a 3rd party network. We refer
to this situation as MoS3 as shown in Figure 4. (Note that MoS can
exist both in home and in visited networks).
Melia, et al. Expires November 13, 2008 [Page 7]
Internet-Draft MSFD May 2008
+--------------+
| HOME NETWORK |
+====+ +--------------+ +--------------+
|MoS3| | THIRD PARTY | <===> /\
+====+ +--------------+ ||
\/
+-----------------+
| VISITED NETWORK |
+-----------------+
/\
||
\/
+--------+
| MN |
+--------+
Figure 4: MoS form a third party
Different types of MoS can be provided independently of other types
and there is no strict relationship between ES, CS and IS, nor is
there a requirement that the entities that provide these services
should be co-located. However, while IS tends to involve a large
amounts of static information, ES and CS are dynamic services and
some relationships between them can be expected, e.g., a handover
command (CS) could be issued upon reception of a link event (ES).
Hence, while in theory MoS can be implemented in different locations,
it is expected that ES and CS will be co-located, whereas IS can be
co-located with ES/CS or located elsewhere. Therefore, having the
flexibility at the MSTP to discover different services in different
locations is an important feature that can be used to optimize
handover performance. MoS discovery is discussed in more detail in
Section 5.
4. Solution Overview
As mentioned in Section 1, the solution space is being divided into
two functional domains: discovery and transport. The following
assumptions have been made:
o The solution is aimed at supporting IEEE 802.21 MIH services,
namely Information Service (IS), Event Service (ES), and Command
Service (CS).
o If the MIHFID is available, FQDN or NAI's realm is used for
mobility service discovery.
Melia, et al. Expires November 13, 2008 [Page 8]
Internet-Draft MSFD May 2008
o The solutions are chosen to cover all possible deployment
scenarios as described in Section 3.
o MoS discovery can be performed during initial network attachment
or at any time thereafter.
The MN may know the realm of the MoS to be discovered. The MN may
also be pre-configured with the address of the MoS to be used. In
case the MN does not know what realm/MoS to query dynamic assignment
methods are described in Section 5.
The configuration of the MoS could be executed either upon network
attachment or after successful IP configuration. The methodology to
be used depends on the considered deployment scenario.
Once the MIHF peer has been discovered, MIH information can be
exchanged between MIH peers over a transport protocol such as UDP or
TCP. The usage of transport protocols is described in Section 6.
4.1. Architecture
Figure 5 depicts the MSTP reference model and its components within a
node. The topmost layer is the MIHF user. This set of applications
consists of one or more MIH clients that are responsible for
operations such as generating query and response, processing Layer 2
triggers as part of the ES, and initiating and carrying out handover
operations as part of the CS. Beneath the MIHF user is the MIHF
itself. This function is responsible for MoS discovery, as well as
creating, maintaining, modifying, and destroying MIH signaling
associations with other MIHFs located in MIH peer nodes. Below the
MIHF are various transport layer protocols as well as address
discovery functions.
Melia, et al. Expires November 13, 2008 [Page 9]
Internet-Draft MSFD May 2008
+--------------------------+
| MIHF User |
+--------------------------+
||
+--------------------------+
| MIHF |
+--------------------------+
|| || ||
+---------+ +------+ +-----+
| TCP/UDP | | DHCP | | DNS |
+---------+ +------+ +-----+
Figure 5: MN stack
The MIHF relies on the services provided by TCP and UDP for
transporting MIH messages, and relies on DHCP and DNS for peer
discovery. In cases where the peer MIHF IP address is not pre-
configured, the source MIHF needs to discover it either via DHCP or
DNS or a combination of both as described in Section 5. Once the
peer MIHF is discovered, MIHF must exchange messages with its peer
over either UDP or TCP. Specific recommendations regarding the
choice of transport protocols are provided in Section 6.
The above reference architecture however does not include other
services such as message fragmentation and security. Depending upon
the MIH service type (e.g., ES, CS and IS) the message size can be
very large. In the case where the underlying layers do not support
fragmentation, this may be an issue. There are no security features
currently defined as part of the MIH protocol level. However,
security can be provided either at the transport or IP layer where it
is necessary. Section 8 provides some guidelines and recommendations
for security.
4.2. MIHF Identifiers (FQDN, NAI)
MIHFID is an identifier required to uniquely identify the MIHF end
points for delivering the mobility services (MoS). Thus an MIHF
identifier needs to be unique within a domain where mobility services
are provided and independent of the configured IP addresse(s). An
MIHFID MUST be represented either in the form of an FQDN [RFC2181] or
NAI [RFC4282]. An MIHFID can be pre-configured or discovered through
the discovery methods described in Section 5.
5. MoS Discovery
The MoS discovery method depends on whether the MN attempts to
discover an MoS in the home network, in the visited network, or in a
Melia, et al. Expires November 13, 2008 [Page 10]
Internet-Draft MSFD May 2008
3rd party remote network that is neither the home network nor the
visited network.
In the case where MoS is provided locally (scenarios S1 and S2) , the
discovery techniques described in [I-D.ietf-mipshop-mos-dhcp-options]
and [I-D.ietf-mipshop-mos-dns-discovery] are both applicable and
either one MAY be used to discover the MoS.
In the case where MoS is provided in the home network while the MN is
in the visited network (scenario S3), the DNS based discovery
described in [I-D.ietf-mipshop-mos-dns-discovery] is applicable,
while the DHCP based discovery method would require an interaction
between the DHCP and the AAA infrastructure, similarly to what is
specified in [I-D.ietf-mip6-bootstrapping-integrated-dhc] . This
latter case assumes that MoS assignment is performed during access
authentication and authorization.
In the case where MoS is provided by a third party network which is
different from the current visited network (scenario S4), only the
DNS based discovery method described in
[I-D.ietf-mipshop-mos-dns-discovery] is applicable.
It should be noted that authorization of a MN to use a specific MoS
server is not in scope of this document and is specified in
[IEEE80221] . Only in scenario S3 MoS discovery/assignment is
performed during network access.
5.1. MoS Discovery when MN and MoSh are in the home network (Scenario
S1)
To discover an MoS in the home network, the MN SHOULD use the DNS
based MoS discovery method described in
[I-D.ietf-mipshop-mos-dns-discovery]. In order to use that
mechanism, the MN MUST first find out the domain name of its home
network. Home domains are usually pre-configured in the MNs (i.e.
subscription is tied to a network), thus the MN can simply read its
configuration data to find out the home domain name (scenario S1).
The DNS query option is shown in Figure 6a. Alternatively, the MN
MAY use the DHCP options for MoS
discovery[I-D.ietf-mipshop-mos-dhcp-options] as shown inFigure 6b.
Melia, et al. Expires November 13, 2008 [Page 11]
Internet-Draft MSFD May 2008
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
+-------+
MN@xyz.com
(a) using DNS Query
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
(b) Using DHCP Option (in some deployments DHCP relay may no tbe present)
Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option
5.2. MoS Discovery when MN is in visited network and MoSv is also in
visited network (Scenario S2)
To discover an MoS in the visited network, the MN SHOULD attempt to
use the DHCP options for MoS discovery
[I-D.ietf-mipshop-mos-dhcp-options] as shown in Figure 7a. If the
DHCP method fails, the MN SHOULD attempt to use the DNS based MoS
discovery method described in [I-D.ietf-mipshop-mos-dns-discovery] as
shown in Figure 7b. In order to use that, the MN MUST first learn
the domain name of the local network. There are a number of ways how
the domain name of a network can be learned:
DHCP -- In order to find out the domain name of the local network,
the MN SHOULD use the dhcpv4 option 15 for learning the domain
name [RFC2132]. A similar solution is available for dhcpv6
[I-D.ietf-dhc-dhcpv6-opt-dnsdomain] .
Reverse dns query -- When DHCP does not provide the required domain
name, the MN MAY use reverse DNS (DNS PTR record) to find the
domain name associated with the IP address it is using in the
visited network. Note, that when a NAT device exists between the
MN and the visited network, the MN will first need to find out the
external IP address of the NAT device. Some possible methods for
determining the NAT's external IP address are STUN [RFC3849] or
UPnP [UPnP_IDG_DCP]. Once the MN has determined the external IP
address of the NAT device, it MUST use that address in the reverse
Melia, et al. Expires November 13, 2008 [Page 12]
Internet-Draft MSFD May 2008
DNS query.
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
(a) MoS Discovery using DHCP options
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
+-------+
(b) Reverse DNS Query (starting from the IP address)
Figure 7: Discovery (a) using DHCP option, (b) Using DNS
A MN SHOULD always try DHCP first. In the case where a network has
MoS(s) deployed but no DHCP mechanisms to discover these servers,
DHCP query from the MN will fail. The MN SHOULD then perform a DNS
lookup after acquiring the domain name of the local network.
When the discovery of an MoS at the visited network, using the FQDN
returned in the reverse DNS query, is not successful, the MN MAY
attempt to remove portions from the left side of the FQDN and attempt
discovery again. The process MAY be repeated iteratively until a
successful discovery.
5.3. MOS Discovery when the MN is in a visited Network and Services are
at the Home network (Scenario S3)
To discover an MoS in the visited network when MIH services are
provided by the home network, both the DNS based discovery method
described in [I-D.ietf-mipshop-mos-dns-discovery] and the DHCP based
discovery method described in [I-D.ietf-mipshop-mos-dhcp-options] are
applicable.
To discover the MoS at home while in a visited network using DNS, the
MN SHOULD use the procedures described in Section 5.1
Alternatively, the MN MAY also use the DHCP based discovery method.
Melia, et al. Expires November 13, 2008 [Page 13]
Internet-Draft MSFD May 2008
Using the DHCP based discovery may be required in deployments where
the usage of MoS located in the home network is enforced and included
in the subscription profile. Similar to
[I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated
scenario the mobile node is required to perform network access
authentication before it can obtain the MoS information. This allows
for MoS discovery at the time of access authentication and
authorization. Also, the mechanism defined in this document requires
the NAS to support MIH specific AAA attributes and a collocated DHCP
relay agent. In order to provide the mobile node with information
about the assigned MoS, the AAAh conveys the assigned MoS's
information to the NAS via AAA protocol as defined in
[I-D.ietf-dime-mip6-integrated] and described in
[I-D.stupar-dime-mos-options].
In these deployment scenarios the AAAh sends the MoS address at home
to the AAAv during the network access authentication. The relation
beween functional components supporting such procedure is shown in
Figure 8.
The mobile node executes the network access authentication procedure
(e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. The NAS
is in the visited and it interacts with AAAh via AAAv to authenticate
the mobile node. In the process of authorizing the mobile node, the
AAAh verifies in the AAA profile that the mobile node is allowed to
use MoS services. The AAAh assigns the MoS in the home and returns
this information to the NAS. The NAS may keep the received
information for a configurable duration or it may keep the
information for as long as the MN is connected to the NAS.
The mobile node sends a DHCPv6 Information Request message [RFC3315]
to the All_DHCP_Relay_Agents_and_Servers multicast address. In this
message the mobile node (DHCP client) MUST include the Option Code
for MoS Identifier Option [I-D.ietf-mipshop-mos-dhcp-options] in the
OPTION_ORO. The mobile node MUST also include the OPTION_CLIENTID to
identify itself to the DHCP server.
The Relay Agent intercepts the Information-request from the mobile
node and forwards it to the DHCP server. The Relay Agent also
includes the received MoS information from the AAAh in the IPv6 Relay
Agent MoS Option [I-D.ietf-mipshop-mos-dhcp-options]. If a NAS
implementation does not store the received information as long as the
MN's session remains in the visited network, and if the MN delays
sending DHCP request, the NAS/DHCP relay does not include the IPv6
Relay Agent MoS Option in the Relay Forward message.
The DHCP server identifies the client by looking at the DUID for the
client in the OPTION_CLIENTID. The DHCP server determines that the
Melia, et al. Expires November 13, 2008 [Page 14]
Internet-Draft MSFD May 2008
MoS is allocated by the AAAh by looking at the IPv6 Relay Agent Sub-
Option in the IPv6 Relay Agent MoS Option. The DHCP server extracts
the allocated MoS information from the IPv6 Relay Agent Sub-Option
and includes it in the MoS Information Option
[I-D.ietf-mipshop-mos-dhcp-options] in the Reply Message. If the
requested information is not available in the DHCP server, it follows
the behavior described in [RFC3315].
The Relay Agent relays the Reply Message from the DHCP server to the
mobile node. At this point, the mobile node has the MoS information
that it requested.
In should be noted, that using the DHCP Options and procedures
defined in [I-D.ietf-mipshop-mos-dhcp-options] the MN can not specify
the network (local or home) where it wants the MoS address from.
Whether the MN receives an MoS address from local or home network
will depend on the actual network deployment (scenario S2 or S3) and
operator policy. In an integrated scenario, where the network access
authentication is performed by the home network the MoS information
will be always sent to the AAAv, then stored in the relay agent and
ultimately sent to the MN if the MN asks for it, using the procedures
defined in [I-D.ietf-mipshop-mos-dhcp-options].
Melia, et al. Expires November 13, 2008 [Page 15]
Internet-Draft MSFD May 2008
Visited | Home
|
|
+-------+ | +-------+
| | | | |
|AAAV |-----------|--------|AAAH |
| | | | |
| | | | |
+-------+ | +-------+
| |
| |
| |
| |
| | +--------+
| | | |
| | | MoSh |
+-----+ +------+ | +--------+
+----+ | | |DHCP | |
| MN |------| NAS/|----|Server| |
+----+ | DHCP| | | |
|Relay| | | |
+-----+ +------+ |
|
AAAv -- Visited AAA
AAAH -- Home AAA
NAS -- Network Access Server
Figure 8: MOS Discovery using Network Access Authentication and DHCP
options
This section assumes the use of IPv6 and DHCPv6 based mechanisms to
discover MoS services in home while the MN is in visited network. If
similar functionalities are desired for IPv4 additional DHCPv4
extensions would be required. Since use cases requiring these
extensions were not identified at the time of writing this document,
they were excluded from the scope of the document.
5.4. MoS discovery when MIH services are in a 3rd party remote network
(scenario S4)
To discover an MoS in a remote network other than home network, the
MN MUST use the DNS based MoS discovery method described in
[I-D.ietf-mipshop-mos-dns-discovery]. The MN MUST first learn the
domain name of the network containing the MoS it is searching for.
If the MN does not yet know the domain name of the network, learning
it may require more than one operation, as DHCP based discovery can
Melia, et al. Expires November 13, 2008 [Page 16]
Internet-Draft MSFD May 2008
not be used and pre-configuration is not a feasible solution in case
of an arbitrary remote network. The MN MAY attempt to first discover
an MoS in either the local or home network (as in Figure 9 part (a))
and query that MoS to find out the domain name of a specific network
or the domain name of a network at a specific location (as in
Figure 9 part (b)). Alternatively, the MN MAY query an MoS
previously known to learn the domain name of the desired network
(e.g., via an IS Query). Finally, the MN MUST use DNS queries to
find MoS in the remote network as inFigure 9 part(c). It should be
noted that step c can only be performed upon obtaining the domain
name of the remote network.
+-------+
+----+ |DHCP |
| MN |-------->| |
+----+ |Server |
+-------+
MN@xyz.com
(a) Discover MoS in local network with DHCP
+------------+
+----+ | |
| | |Information |
| MN |-------->| Server |
| | |(previously |
+----+ |discovered) |
+------------+
(b) Using IS query to find the FQDN on the remote network
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
+-------+
MN@xyz.com
(c) using DNS Query in the remote network
Figure 9: MOS Discovery using (a) DHCP Options, (b) IS Query to a
known IS Server, (c) DNS Query
6. MIH Transport Options
Once the Mobility Services have been discovered, MIH peers MAY
exchange information over TCP, UDP or any other transport supported
by both the server and client. The client MAY use the DNS discovery
Melia, et al. Expires November 13, 2008 [Page 17]
Internet-Draft MSFD May 2008
mechanism to discover which transport protocols are supported by the
server in addition to TCP and UDP that are recommended in this
document. While either protocol can provide the basic transport
functionality required, there are performance trade-offs and unique
characteristics associated with each that need to be considered in
the context of the MIH services for different network loss and
congestion conditions. The objectives of this section are to discuss
these trade-offs for different MIH settings such as the MIH message
size and rate, and the retransmission parameters. In addition,
factors such as NAT traversal are also discussed. Given the
reliability requirements for the MIH transport, it is assumed in this
discussion that the MIH ACK mechanism is to be used in conjunction
with UDP, while it is preferred to avoid using MIH ACKs with TCP
since TCP includes acknowledgement and retransmission functionality.
6.1. MIH Message size
Although the MIH message size varies widely from about 30 bytes (for
a broadcast capability discovery request) to around 65000 bytes (for
an IS MIH_Get_Information response primitive), a typical MIH message
size for the ES/CS service ranges between 50 to 100 bytes
[IEEE80221]. Thus, considering the effects of the MIH message size
on the performance of the transport protocol brings us to discussing
two main issues, related to fragmentation of long messages in the
context of UDP and the concatenation of short messages in the context
of TCP. Since transporting long MIH messages may require
fragmentation that is not available in UDP, if MIH is using UDP a
limit MUST be set on the size of the MIH message, unless
fragmentation functionality is added to the MIH layer or IP layer
fragmentation is used instead. In this latter case, the loss of an
IP fragment leads to the retransmission of an entire MIH message,
which in turn leads to poor end-to-end delay performance in addition
to wasted bandwidth. Additional recommendations in
[I-D.ietf-tsvwg-udp-guidelines] apply for limiting the size of the
MIH message when using UDP and assuming IP layer fragmentation. In
terms of dealing with short messages, TCP has the capability to
concatenate very short messages in order to reduce the overall
bandwidth overhead. However, this reduced overhead comes at the cost
of additional delay to complete an MIH transaction, which may not be
acceptable for CS and ES services. Note also that TCP is a stream
oriented protocol and measures data flow in terms of bytes, not
messages. Thus it is possible to split messages across multiple TCP
segments if they are long enough. Even short messages can be split
across two segments. This can also cause unacceptable delays,
especially if the link quality is severely degraded as is likely to
happen when the MN is exiting a wireless access coverage area.
Melia, et al. Expires November 13, 2008 [Page 18]
Internet-Draft MSFD May 2008
6.2. MIH Message rate
The frequency of MIH messages varies according to the MIH service
type. It is expected that CS/ES message arrive at a rate of one in
hundreds of milliseconds in order to capture quick changes in the
environment and/ or process handover commands. On the other hand, IS
messages are exchanged mainly every time a new network is visited
which may be in order of hours or days. Therefore a burst of either
short CS/ES messages or long IS message exchanges (in the case where
multiple MIH nodes request information) may lead to network
congestion. While the built-in rate-limiting controls available in
TCP may be well suited for dealing with these congestion conditions,
this may result in large transmission delays that may be unacceptable
for the timely delivery of ES/CS messages. On the other hand, if UDP
is used, a rate-limiting effect similar to the one obtained with TCP
may be obtained by adequately adjusting the parameters of a token
bucket regulator as defined in the MIH specifications [IEEE80221].
Recommendations for tocken bucket parameter settings are specific to
the scenario considered.
6.3. Retransmission
For TCP, the retransmission timeout is adjusted according to the
measured RTT. However due to the exponential backoff mechanism, the
delay associated with retransmission timeouts may increase
significantly with increased packet loss.
If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.
An MIH message is retransmitted if its corresponding MIH ACK is not
received by the generating node within a timeout interval set by the
MIHF. This approach does not include an exponential backoff and
therefore tends to degrade more gracefully than TCP when the packet
loss rate becomes large, in the sense that the expected delay does
not increase exponentially. The number of retransmissions is
limited, which reduces head-of-line blocking of other MIH messages,
but this can cause important ES/CS messages to be lost.
6.4. NAT Traversal
There are no known issues for NAT traversal when using TCP. The
default connection timeout of 24 hours is considered adequate for MIH
transport purposes. However, issues with NAT traversal using UDP are
documented in [I-D.ietf-tsvwg-udp-guidelines]. Communication
failures are experienced when middleboxes destroy the per-flow state
associated with an application session during periods when the
application does not exchange any UDP traffic. Hence, communication
between the MN and the MoS SHOULD be able to gracefully handle such
failures and implement mechanisms to re-establish their UDP sessions.
Melia, et al. Expires November 13, 2008 [Page 19]
Internet-Draft MSFD May 2008
In addition and in order to avoid such failures, MIH messages MAY be
sent periodically, similarly to keep-alive messages, to attempt to
refresh middlebox state (e.g. ES reports could be used for this
purpose). As [RFC4787] requires a minimum state timeout of two
minutes or more, MIH messages using UDP as transport SHOULD be sent
once every two minutes.
6.5. General guidelines
Since ES and CS messages are small in nature and have tight latency
requirements, UDP in combination with MIH acknowledgement SHOULD be
used for transporting ES and CS messages. On the other hand, IS
messages are more resilient in terms of latency constraints and some
long IS messages could exceed the MTU of the path to the destination.
Therefore, TCP SHOULD be used for transporting IS messages. For both
UDP and TCP cases, if a port number is not explicitly assigned (e.g.
by the DNS SRV), MIH messages sent over UDP, TCP or other supported
transport MUST use the default port number defined for that
particular transport.
MoS server MUST support both UDP and TCP for MIH transport and the MN
MUST support TCP. Additionally, the server and MN MAY support
additional transport mechanisms. The MN MAY use the procedures
defined in [I-D.ietf-mipshop-mos-dns-discovery] to discover
additional transport protocols supported by the server.
7. Operation Flows
Figure 10 gives an example operation flow between MIHF peers when an
MIH user requests an IS service. Scenario 1 is in effect, i.e. the
MoS and the MN are both in the MN's home network. Thus DHCP is used
for MoS discovery and TCP is used for establishing a transport
connection to carry the IS messages. When MoS is not pre-configured,
the MIH user needs to discover the IP address of MoS to communicate
with the remote MIHF. Therefore the MIH user sends a discovery
request message to the local MIHF as defined in [IEEE80221].
In this example (one could draw similar mechanisms with DHCPv6), we
assume that MoS discovery is performed before a transport connection
is established with the remote MIHF, and the DHCP client process is
invoked via some internal APIs. DHCP Client sends DHCP INFORM
message according to standard DHCP and with the MoS option as defined
in [I-D.ietf-mipshop-mos-dhcp-options]. DHCP server replies via DHCP
ACK message with the IP address of the MoS. The MoS address is then
passed to the MIHF locally via some internal APIs. MIHF generates
the discovery response message and passes it on to the corresponding
MIH user. The MIH user generates an IS query addressed to the remote
Melia, et al. Expires November 13, 2008 [Page 20]
Internet-Draft MSFD May 2008
MoS. MIHF invokes the underlying TCP client which establishes a
transport connection with the remote peer. Once the transport
connection is established, MIHF sends the IS query via MIH protocol
REQUEST message. The message and query arrive at the destination
MIHF and MIH user respectively. The MoS MIH user responds to the
corresponding IS query and the MoS MIHF sends the IS response via MIH
protocol RESPONSE message. The message arrives at the source MIHF
which passes the IS response on to the corresponding MIH user.
MN MoS
|===================================| |======| |===================|
+ ---------+ + ---------+
| MIH USER | +------+ +------+ +------+ +------+ | MIH USER |
| +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ |
| | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | |
+----------+ +------+ +------+ +------+ +------+ +----------+
| | | | | |
|MIH Discovery | | | | |
|Request | | | | |
|(MIH User-> MIHF)| | | | |
|======> | | | | |
| | | | | |
|Invoke DHCP Client | | | |
|(Internal process with MoS)|DHCP INFORM| | |
|==========================>|==========>| | |
| | | | | |
| | | | | |
| | | DHCP ACK | | |
| | |<==========| | |
| Inform MoS address | | | |
|<==========================| | | |
| (internal process) | | | |
| | | | |
|Discovery | | | | |
|Response | | | | |
|<====== | | | | |
|(MIH User<- MIHF)| | | | |
| | | | | |
|IS Query | | | | |
|=======> | | | | |
|(MIH User-> MIHF)| | | | |
| | | | | |
|Invoke TCP Client| | | | |
|================>| | | | |
|(Internal process| | | | |
|with MOS) | | | | |
| | | | | |
| | TCP connection established | |
Melia, et al. Expires November 13, 2008 [Page 21]
Internet-Draft MSFD May 2008
| |<=============================>| |
| | | | | |
| | | | | |
| | | | | |
| IS QUERY REQUEST (via MIH protocol) |
|===========================================================>|
| | | | | |
| | | | | |
| | | | | |
| | | | | IS QUERY|
| | | | | REQUEST|
| | | | |=========>|
| | | | (MIHF-> MIH User)|
| | | | | |
| | | | | QUERY|
| | | | | RESPONSE|
| | | | | <======|
| | | | (MIHF <-MIH User) |
| | | | | |
| | IS QUERY RESPONSE (via MIH protocol) |
|<===========================================================|
| | | | | |
| IS | | | | |
|RESPONSE | | | | |
|<======== | | | | |
|(MIH User <-MIHF)| | | | |
| | | | | |
Figure 10: Example Flow of Operation Involving MIH User
8. Security Considerations
There are a number of security issues that need to be taken into
account during node discovery and information exchange via a
transport connection [RFC5164]
In the case where DHCP is used for node discovery and authentication
of the source and content of DHCP messages is required, network
administrators SHOULD use DHCP authentication option described in
[RFC3118], where available or rely upon link layer security. This
will also protect the DHCP server against denial of service attacks
to. [RFC3118] provides mechanisms for both entity authentication and
message authentication.
In the case where DNS is used for discovering MoS, fake DNS requests
and responses may cause DoS and the inability of the MN to perform a
proper handover, respectively. Where networks are exposed to such
Melia, et al. Expires November 13, 2008 [Page 22]
Internet-Draft MSFD May 2008
DoS, it is RECOMMENDED that DNS service providers use the Domain Name
System Security Extensions (DNSSEC) as described in [RFC4033].
Readers may also refer to [RFC4641] to consider the aspects of DNSSEC
Operational Practices.
In the case where reliable transport protocol such as TCP is used for
transport connection between two MIHF peers, TLS [RFC4346] SHOULD be
used for message confidentiality and data integrity. In particular,
TLS is designed for client/server applications and to prevent
eavesdropping, tampering, or message forgery. Readers should also
follow the recommendations in [RFC4366] that provides generic
extension mechanisms for the TLS protocol suitable for wireless
environments.
In the case where unreliable transport protocol such as UDP is used
for transport connection between two MIHF peers, DTLS [RFC4347]
SHOULD be used for message confidentiality and data integrity. The
DTLS protocol is based on the Transport Layer Security (TLS) protocol
and provides equivalent security guarantees.
Alternatively, generic IP layer security, such as IPSec [RFC4301] MAY
be used where neither transport layer security for a specific
transport is available nor server only authentication is required.
9. IANA Considerations
This document registers the following TCP and UDP port(s) with IANA:
Keyword Decimal Description
------- ------- -----------
ieee-mih-IS XXX/tcp Media Independent Handover Information Services
ieee-mih-IS XXX/udp Media Independent Handover Information Services
ieee-mih-ES XXX/tcp Media Independent Handover Event Services
ieee-mih-ES XXX/udp Media Independent Handover Event Services
ieee-mih-CS XXX/tcp Media Independent Handover Command Services
ieee-mih-CS XXX/udp Media Independent Handover Command Services
10. Acknowledgements
The authors would like to thank Yoshihiro Ohba, David Griffith, Kevin
Noll, Vijay Devarapalli, Patrick Stupar and Sam Xia for their
valuable comments, reviews and fruitful discussions.
11. References
Melia, et al. Expires November 13, 2008 [Page 23]
Internet-Draft MSFD May 2008
11.1. Normative References
[I-D.ietf-mipshop-mos-dhcp-options]
Bajko, G. and S. Das, "Dynamic Host Configuration Protocol
(DHCPv4 and DHCPv6) Options for Mobility Server (MoS)
discovery", draft-ietf-mipshop-mos-dhcp-options-00 (work
in progress), April 2008.
[I-D.ietf-mipshop-mos-dns-discovery]
Bajko, G., "Locating Mobility Servers using DNS",
draft-ietf-mipshop-mos-dns-discovery-00 (work in
progress), April 2008.
[I-D.stupar-dime-mos-options]
Korhonen, J. and T. Melia, "Diameter extensions for MoS
discovery", draft-stupar-dime-mos-options-00 (work in
progress), February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
11.2. Informative References
[I-D.ietf-dhc-dhcpv6-opt-dnsdomain]
Yan, R., "Domain Suffix Option for DHCPv6",
draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress),
June 2007.
Melia, et al. Expires November 13, 2008 [Page 24]
Internet-Draft MSFD May 2008
[I-D.ietf-dime-mip6-integrated]
Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction",
draft-ietf-dime-mip6-integrated-08 (work in progress),
February 2008.
[I-D.ietf-mip6-bootstrapping-integrated-dhc]
Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in
progress), April 2008.
[I-D.ietf-tsvwg-udp-guidelines]
Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
Application Designers", draft-ietf-tsvwg-udp-guidelines-06
(work in progress), April 2008.
[IEEE80221]
"Draft IEEE Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services", IEEE LAN/
MAN Draft IEEE P802.21/D07.00, July 2007.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", RFC 3849, July 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
Melia, et al. Expires November 13, 2008 [Page 25]
Internet-Draft MSFD May 2008
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5164] Melia, T., "Mobility Services Transport: Problem
Statement", RFC 5164, March 2008.
Authors' Addresses
Telemaco Melia (editor)
CISCO
Email: tmelia@cisco.com
Gabor Bajko
Nokia
Email: Gabor.Bajko@nokia.com
Subir Das
Telcordia Technologies Inc.
Email: subir@research.telcordia.com
Nada Golmie
NIST
Email: nada.golmie@nist.gov
Juan Carlos Zuniga
InterDigital Communications, LLC
Email: j.c.zuniga@ieee.org
Melia, et al. Expires November 13, 2008 [Page 26]
Internet-Draft MSFD May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Melia, et al. Expires November 13, 2008 [Page 27]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/