Re: [Mipshop] WG last call on MIH solution document (draft-ietf-mipshop-mstp-solution-01.txt)
Yoshihiro Ohba <yohba@tari.toshiba.com> Mon, 03 March 2008 03:40 UTC
Return-Path: <mipshop-bounces@ietf.org>
X-Original-To: ietfarch-mipshop-archive@core3.amsl.com
Delivered-To: ietfarch-mipshop-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7594228C45B; Sun, 2 Mar 2008 19:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.468
X-Spam-Level:
X-Spam-Status: No, score=0.468 tagged_above=-999 required=5 tests=[AWL=-1.695, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKumHDCU18OC; Sun, 2 Mar 2008 19:40:07 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8D43A69F2; Sun, 2 Mar 2008 19:40:07 -0800 (PST)
X-Original-To: mipshop@core3.amsl.com
Delivered-To: mipshop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071B928C405 for <mipshop@core3.amsl.com>; Sun, 2 Mar 2008 19:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Glvr6qQTRcdF for <mipshop@core3.amsl.com>; Sun, 2 Mar 2008 19:39:45 -0800 (PST)
Received: from mail.globalsuite.net (mail.globalsuite.net [69.46.103.200]) by core3.amsl.com (Postfix) with SMTP id D58113A698A for <mipshop@ietf.org>; Sun, 2 Mar 2008 19:39:44 -0800 (PST)
X-AuditID: c0a8013c-ab0bebb0000019a0-cf-47cb72f3240d
Received: from steelhead.localdomain (unknown [87.204.240.2]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 513324DC006; Sun, 2 Mar 2008 20:39:31 -0700 (MST)
Received: from ohba by steelhead.localdomain with local (Exim 4.69) (envelope-from <yohba@tari.toshiba.com>) id 1JW1WN-00031z-Kj; Sun, 02 Mar 2008 22:39:23 -0500
Date: Sun, 02 Mar 2008 22:39:23 -0500
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
To: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
Message-ID: <20080303033923.GG6955@steelhead.localdomain>
References: <47B37F17.5000902@azairenet.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <47B37F17.5000902@azairenet.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
X-Brightmail-Tracker: AAAAAA==
Cc: 'Mipshop' <mipshop@ietf.org>
Subject: Re: [Mipshop] WG last call on MIH solution document (draft-ietf-mipshop-mstp-solution-01.txt)
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <mipshop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org
Here is my review.
----------------------------------------------------------
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, MIH Event messages, and MIH
command messages.
[YO] MIH Information Service messages are missing here. Suggested change:
"
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 cross-layer 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.
[YO] s/defined by the IEEE 802.21 working group/defined by IEEE 802.21
[IEEE80221]/.
MIHF User an MIH client that uses the MIH SAPs to access MIHF
services, and which is responsible for initiating and terminating
MIH signaling
[YO] The term "MIH client" is not defined. Suggested change: s/an MIH
client/an entity/. Also, the above sentence is not complete.
MN Mobile Node: an Internet device whose location changes, along with
its point of connection to the network.
NN Network Node: an Internet device whose location and network point
of attachment do not change
[YO] This term is unused in this document and should be removed.
MSTP Mobility Services Transport Protocol: a protocol that is used
to deliver MIH signaling messages from an MIHF to other MIH-aware
nodes in a network.
[YO] s/MIH signaling messages/MIH protocol messages/, throughout the
document.
IS Information Service: a MoS that originates at the lower or upper
layers and sends information to the local or remote upper or lower
layers. It can use secure or insecure ports to transport
information elements (IEs) and information about various
neighboring nodes. Its architecture is outside the scope of the
IEEE 802.21 draft document.
[YO] I am not sure this description is aligned with the description in
IEEE 802.21 specification. This may need to be revised. I have the
same comment for ES and CS.
ES Event Service: a MoS that originates at a remote MIHF or the lower
layers 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 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. hostname.domain.org)
[YO] Incomplete sentense.
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.
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.
AAA home AAA server: an AAA server located on the MN's home network
[YO] s/AAA home AAA server/Home AAA (AAAh)/.
AAA visited AAA server: an AAA server located a visited network that
is not the MN's home network
[YO] s/AAA visited AAA server/Visited AAA (AAAv)/.
[YO] Incomplete sentence.
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
[YO] Incomplete sentence.
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
[YO] Incomplete sentence.
UDP 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
[YO] Incomplete sentence.
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: a 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.
[YO] s/a estimation/an estimation/.
MTU Maximum Transmission Unit: the largest size packet that can be
sent on a network without requiring fragmentation [RFC1191].
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
resource discovery as well as the performance of the MIH signaling
service.
[YO] s/resource discovery/MoS discovery/.
s/MIH signaling service/MIH services/.
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 point 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.
+--------------+
| 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 hom enad in visited).
[YO] s/hom enad/home and/.
+--------------+
| 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 types be co-
located. However, while IS tends to involve large amounts of static
information, ES and CS are dynamic services and some relationship
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. Resource
discovery is discussed in more detail in Section 5.
[YO] s/Resource discovery/MoS discovery/.
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.
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 thereafter.
The MN could know or not the realm of the MoS to be discovered. In
any case after the acquisition of the target realm (e.g. via
Information Server or statically configured) the MN could either be
pre-configured with the address of the MoS, or this address could be
obtained through DHCP or DNS. The dynamic assignation 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 trasnport protocol such as UDP or
[YO] s/trasnport/transport/.
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 such
operations as maintaining MIH databases associated with the IS,
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 set 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 resolution functions.
+--------------------------+
| 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 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)
An 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 invariant to interface IP addresses. 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
3rd party remote network that is neither the home network nor the
visited network.
In case MoS is provided locally (scenarios S1 and S2) , the discovery
techniques described in [I-D.bajko-mos-dhcp-options] and
[I-D.bajko-mos-dns-discovery] are both applicable and either one MAY
be used to discover the MoS.
In case 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.bajko-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 specified in
[I-D.ietf-mip6-bootstrapping-integrated-dhc] . This latter case
assumes that MoS assignment is performed during access authentication
and authorization.
In case MoS is provided in a remote network other than visited or
home network (scenario S4), only the DNS based discovery method
described in [I-D.bajko-mos-dns-discovery] is applicable.
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.bajko-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, 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 6b.
[YO] s/Figure 6b/Figure 6a/.
Alternatively, the MN MAY use the DHCP options for MoS
discovery[I-D.bajko-mos-dhcp-options] as shown inFigure 6a.
[YO] s/Figure 6a/Figure 6b/.
+-------+
+----+ |Domain |
| MN |-------->|Name |
+----+ |Server |
+-------+
MN@xyz.com
(a) using DNS Query
+-----+ +------+
+----+ | | |DHCP |
| MN |<----->| DHCP|<---->|Server|
+----+ |Relay| | |
+-----+ +------+
(b) Using DHCP Option
Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option
5.2. MoS Discovery when MIN is in visited network and MoSv is also in
visited network (Scenario S2)
[YO] s/MIN/MN/.
To discover an MoS in the visited network, the MN SHOULD attempt to
use the DHCP options for MoS discovery [I-D.bajko-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.bajko-mos-dns-discovery] as shown in Figure 7b. In order to
[YO] Remove one '['.
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 [RFC1533]. 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
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
It should be noted, that the usage of DHCP options to discover an MoS
in this particular scenario is recommended because of its simplicity
over the DNS based discovery method: the DNS discovery method
requires the MN to learn the domain name of the local network first,
possibly using DHCP, and then perform the DNS query. The usage of
the DHCP based discovery method does not require any additional
procedure.
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.bajko-mos-dns-discovery] and the DHCP based
discovery method described in [I-D.bajko-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 Section 5.1
Alternatively, the MN MAY also use the DHCP based discovery method.
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. Similarly 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 bootstrap 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 similarly to
[I-D.ietf-dime-mip6-integrated] and described in [REF TO NEW DOC].
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 the AAAh 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.bajko-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.bajko-mos-dhcp-options]. If a NAS
implementation does not store the received information as long as the
MN's session remains in the visited, 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
home agent 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 home agent information from the IPv6 Relay
Agent Sub-Option and includes it in the MoS Information Option
[I-D.bajko-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.bajko-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). In an
integrated scenario, where the network access authentication is
performed by the home network the MoS information will anyway be 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.bajko-mos-dhcp-options].
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
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.bajko-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 pre-configuration and DHCP
methods can not be used. 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
[YO] a/inFigure/in Figure/.
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 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, as described in
[I-D.rahman-mipshop-mih-transport]. The client MAY use the DNS
discovery mechanism to discover which transport protocols are
supported by the server in addition to TCP and UDP. 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
[YO] The last sentence is incomplete.
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 to100 bytes [IEEE80221].
[YO] s/to100/to 100/.
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
utilization. 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.
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 of
multiple MIH nodes requesting 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.
[YO] Just a note that in the comment resolution of 802.21 Sponsor
Ballot recirculation #2, use of MIH ACK is becoming mandatory when
unreliable MIH transport protocol such as UDP is used.
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.
Additionally, instead of retransmitting an unacknowledged message,
the MIH may choose to update the information and transmit a new
message.
[YO] I am not sure if this additional behavior is described in IEEE
802.21 specification.
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
[YO] s/MoS/PoS/.
failures and implement mechanisms to re-establish their UDP sessions.
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..
[YO] Remove one '.'.
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.bajko-mos-dns-discovery] to discover additional
transport protocols supported by the server.
[YO] s/MOS server/A PoS/.
s/the server/the PoS/.
[YO] I am not sure if the requirements in the first and second
paragraphs are consistent. The first paragraph says UDP is a SHOULD
for ES/CS and TCP is a SHOULD for IS, while the second paragraph says
UDP and TCP are a MUST for MOS server and TCP is a MUST for MN. So
which transport MN should actually use for ES/CS, TCP or UDP? If MN
uses TCP, then it is not recommended in the first paragraph. If MN
uses UDP, then the use of UDP is not mandated or recommended in the
second paragraph.
[YO] Which transport should be used for Service Management messages
such as MIH_Capability_Discover request/response, MIH_(De)Register
request/response and MIH_Event_(Un)Subscribe request/response
messages?
7. Operation Flows
Figure 10 gives an example operation flow between MIHF peers when an
MIH user requests for 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]
[YO] s/the MOS/the PoS for the MoS/ in the above paragraph.
In this example, 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.bajko-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.
[YO] s/IP address of the MOS/IP address of the PoS for the MoS/ in the
above paragraph.
s/The MOS address/The IP address of the PoS/.
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 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 to
the source MIHF which passes the IS response on to the corresponding
MIH user.
MN MoS
[YO] s/MoS/PoS/.
|====================================| |======| |===================|
+ ---------+ + ---------+
| MIH USER | +------+ +------+ +------+ +------+ | MIH USER |
| +------+ | | TCP | |DHCP | |DHCP | | TCP | | +------+ |
| | MIHF | | |Client| |Client| |Server| |Server| | | MIHF | |
+----------+ +------+ +------+ +------+ +------+ +----------+
| | | | | |
|MIH Discovery | | | | |
|Request | | | | |
[YO] s/MIH Discovery Request/MIH_Capability_Discover.request/.
|(MIH User-> MIHF)| | | | |
|======> | | | | |
| | | | | |
|Invoke DHCP Client | | | |
|(Internal process with MoS)|DHCP INFORM| | |
|==========================>|==========>| | |
| | | | | |
| | | | | |
| | | DHCP ACK | | |
| | |<==========| | |
[YO] This invocation of DHCP INFORM needs to happen before
MIH_Capability_Discover.request because MIH User on the MN needs to
know the MIHF-ID of the PoS to issue an
MIH_Capability_Discover.request remote primitive. Also, an
MIH_Capability_Discover request message needs to be generated and sent
to the PoS as a consequence.
| Inform MoS address | | | |
|<==========================| | | |
| (internal process) | | | |
[YO] s/MoS address/PoS address/.
| | | | |
|Discovery | | | | |
|Response | | | | |
|<====== | | | | |
|(MIH User<- MIHF)| | | | |
| | | | | |
|IS Query | | | | |
|=======> | | | | |
|(MIH User-> MIHF)| | | | |
| | | | | |
|Invoke TCP Client| | | | |
|================>| | | | |
|(Internal process| | | | |
|with MOS) | | | | |
| | | | | |
| | TCP connection established | |
| |<==============================>| |
| | | | | |
| | | | | |
| | | | | |
| IS QUERY REQUEST (via MIH protocol) |
|============================================================>|
| | | | | |
| | | | | |
| | | | | |
| | | | | IS QUERY|
| | | | | REQUEST|
| | | | |=========>|
| | | | (MIHF-> MIH User)|
| | | | | |
| | | | | QUERY|
| | | | | RESPONSE|
| | | | | <======|
| | | | |(MIHF <-MIH User) |
| | | | | |
| | IS QUERY RESPONSE (via MIH protoco |
|<============================================================|
| | | | | |
| 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 [I-D.ietf-mipshop-mis-ps]
In case where DHCP is used for node discovery and authentication of
the source and content of DHCP messages are required, it is
recommended that network administrators should use DHCP
authentication option described in [RFC3118], where available or rely
upon link layer security. This will also protect the denial of
service attacks to DHCP server.[RFC3118] provides mechanisms for both
entity authentication and message authentication.
In 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
DoS, it is recommended that DNS service providers use the Domain Name
[YO] Is this a RECOMMENDED or recommended?
System Security Extensions (DNSSEC) as described in [RFC4033].
Readers may also refer to [RFC4641] to consider the aspects of DNSSEC
Operational Practices.
In case where reliable transport protocol such as TCP is used for
transport connection between two MIHF peers, TLS [RFC4346] should be
[YO] Is this a SHOULD or should?
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 case where unreliable transport protocol such as UDP is used for
transport connection between two MIHF peers, DTLS [RFC4347] should be
[YO] Is this a SHOULD or should?
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 [RFC2401] may
[YO] Is this a MAY or may?
be used where neither transport layer security for a specific >
[YO] Remove '>'.
transport is available nor server only authentication is required.
----------------------------------------------------------
Best Regards,
Yoshihiro Ohba
On Wed, Feb 13, 2008 at 03:36:55PM -0800, Vijay Devarapalli wrote:
> Hello folks,
>
> This is to announce a working group last call for the MIH
> solution document (draft-ietf-mipshop-mstp-solution). You
> can find the document at the following URL.
>
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-01.txt
>
> The last call expires on March 5 2008. (Its a three week
> last call because of Internet Draft submission deadlines
> on the 18th and 25th).
>
> The intended status for this document is Standards Track.
>
> Please post any issues or comments on this document to the
> MIPSHOP WG mailing list. In case you have reviewed the
> document and found no issues, please send an email saying
> you support advancing this document.
>
> Vijay
> _______________________________________________
> Mipshop mailing list
> Mipshop@ietf.org
> http://www.ietf.org/mailman/listinfo/mipshop
>
>
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www.ietf.org/mailman/listinfo/mipshop
- [Mipshop] WG last call on MIH solution document (… Vijay Devarapalli
- Re: [Mipshop] WG last call on MIH solution docume… Vijay Devarapalli
- Re: [Mipshop] WG last call on MIH solution docume… Behcet Sarikaya
- Re: [Mipshop] WG last call on MIH solution docume… Yoshihiro Ohba
- Re: [Mipshop] [MIPSHOP-MIH-DT] WG last call on MI… Noll, Kevin
- Re: [Mipshop] WG last call on MIH solutiondocumen… Gabor.Bajko
- Re: [Mipshop] WG last call on MIH solution docume… Ashutosh Dutta
- Re: [Mipshop] WG last call on MIHsolutiondocument… Telemaco Melia (tmelia)
- Re: [Mipshop] WG last call on MIH solutiondocumen… Telemaco Melia (tmelia)
- Re: [Mipshop] WG last call on MIH solutiondocumen… Yoshihiro Ohba