Daniel,
We will be submitting another version of existing draft and therefore
the deadline is March 6th. Yes, pl. do send your comments.
Thanks,
-Subir
Soohong Daniel Park wrote:
Subir - Good job and I will make comments on that
after taking a look at it quickly.
Remind: IETF initial submission due is 27th not Mar. 6th.
This draft is a revised one ? if yes, let me know the initial
version and change log...
Thanks,
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
----- Original Message -----
From: "Subir Das" <subir@RESEARCH.TELCORDIA.COM>
To: <STDS-802-21@listserv.ieee.org>
Sent: Thursday, February 23, 2006 10:13 AM
Subject: [802.21] Tomorrow's Telecon material
Pl. find the document for tomorrow's telecon. We will discuss the
slides. Also attaching
a drafty draft. Folks are working on it. The IETF draft submission
deadline is on March 6,
9:00 EST. Hopefully we will have a stable version by then.
Regards,
-Subir
--------------------------------------------------------------------------------
Media independent Information Service (MIIS) and Its Higher
Layer Transport Requirements
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 xx, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Media Independent Information Service (MIS) Information Services provides a framework by which a MIH (Media Independent Handover) function both in the mobile node and in the network can discover and obtain network information (both homogeneous and heterogeneous) within a geographical region to facilitate handovers. MIS includes support for various Information Elements (IEs). These IEs provide information that is essential for a handover function to make intelligent handover decision. The MIH function in a mobile node or network can obtain such network information (e.g., IEs) via both lower as well as higher layers.
This document is an effort to describe use cases and requirements for higher layers Information Service while the information is transported over IP and above layers.
1. Introduction
Media Independent Handover Services are a class of network services,
which aim to improve the quality of handovers available to mobile
devices. In order to support more intelligent handover services it
is often necessary to be able to exchange information between mobile
and fixed nodes within the network.
IEEE 802.21 working group is currently defining three broad classes of
such services to facilitate the handover. They require passing of
information within hosts, as well as between them:
1.1 Media Independent Event Services (MIES) provide indications from
lower layers about changes in the connectivity state [802.21 draft].
Events are of two kinds: local and remote. In case of local events,
information typically propagate upwards from L2 to MIH
function and MIH function to upper layers within a local stack. In
case of remote events, however, information may propagate from MIH
or upper layers in one stack to MIH or upper layers in another stack.
1.2 Media Independent Command Services (MICS) provide mechanisms for
Controlling handovers [802.21 draft]. It includes the commands from
upper layer to MIH and from MIH to lower layer. These commands mainly
carry the upper layer decisions to the lower layers.
1.3 Media Independent Information Service (MIIS) Information Services
provides a framework by which a MIHF (Media Independent Handover Function)
both in the mobile node and in the network can discover and
obtain homogeneous and heterogeneous network information within
a geographical region to facilitate handovers [802.21 draft]. MIIS
includes support for various Information Elements (IEs). These IEs
provide information that is essential for a handover function to make
intelligent handover decision. The information can be made available
via both lower as well as higher layers.
1.1 Higher Layer Information Services
Higher layer Information Services are considered to be an important component
of handover services for both horizontal and vertical handovers. Depending
upon the type of mobility support, different IEs may be necessary for
performing handovers. In cases where these IEs are not available natively by
the access network, higher layer information service is the only means to
obtain such information. Also for vertical handovers, information about
heterogeneous networks is essential for mobile devices to decide the best
network to handover that preserve the service and session continuity [802.21
draft]. These services are typically provided by information servers that are
either available locally or can be contacted remotely.
Information provided varies dependent on the purpose and operation of the information service, but may consist of: list of neighboring access networks, network operator list, roaming partners, wireless channel information (e.g., data rate, MAC type) etc. In particular, [802.21 Draft] document defines four classes of information elements: i) General access network information such as,
List of operators, List of networks, etc; ii) Information about Point of Attachment (PoA) such as, location of PoA, address of PoA, etc; and iii) Higher layer information such as, subnet information, capability information, and iv) Vendor specific IEs. The delivery of such information relies upon the following reference model as defined by IEEE 802.21.
2. Information Service Reference Model
Entities involved with handover information services perform the roles of an
Information Services client (IS client), Information Services Proxy and an
Information Services server (IS-Server). Relative positions of client and
server, and the interfaces between them may produce different requirements,
depending on the type of communication.
Figure 1 presents a reference model for both for single and mutihop
Communication. The reference model shows both client-server and
client-proxy-server models. In the client-server model, an IS client
is communicating with the IS server via an interface Ia which is similar to
R1 or R3 as defined in Section 5.3.1 (MIH communication model)[802.21 draft].
In case of client-proxy-server model, the interface Ia` is similar to R4 or
R5 in section 5.3.1 [802.21 Draft]. This new IS-Server may reside either
within its administrative domain, or in another domain.
------------ -----------
| IS-client|<-------|------>|IS-Server|
------------ R1/R3 -----------
------------ ----------- -----------
| IS-Client|<-------|------>|IS-Proxy | <-----|------> | IS-Server|
------------ R1/R3 ----------- R4/R5 -----------
Figure 1: Information Service Reference Model and Interfaces
In order to support the above models, an Information Service system would need to provide more than transport such as, discovery of proxy and Information servers, security association between client-server and client-proxy-server in a variety of deployment scenarios. However, this document only addresses the transport requirements of information services over IP. Several such scenarios are described below.
3. Use Cases
The models described above for information services allow deployment
of IS Information Servers anywhere within the visited or home network
domain. In this section example scenarios are described indicating where
information services are likely to be deployed. Descriptions of
particular characteristics of these deployments are made, especially
where the deployments place requirements on any information service
transportation deployed over IP.
In each of the figures (Figure2, Figure 3 and Figure 4) below, a
mobile device is currently connected to a particular wireless access network,
serviced by an Access Point. In order to gain information about
other wireless cells (homogeneous or heterogeneous) in the vicinity,
it contacts an information server within the fixed network.
In Figure 2, the information service has been deployed on a wireless
Access Point. This is considered to be a likely scenario, as
wireless devices themselves may be aware of local information and also
may have information about administratively adjacent devices
(such as first-hop routers) and other access points or base stations within
the same subnet.
In this scenario, transport of information services over IP may not
strictly necessary, as the IS-Server may be the MAC peer of the wireless
host. On the other hand if information server is an IP peer, higher
transport is required.
/--------\
/ \
------- -------- -------- /----/ \----\
|IS | | |--+--| |---/ \
|Client|<----->|IS | | | | / \
| | |Server| | | | \ /
------- -------- | -------- \ /
Host Access | Router \----\ /----/
Point | \ /
| -------- / \--------/
+--| | / Core
| |-------/ Network
| |
--------
Router
Figure 2: IS-Server on Access Point
Figure 3 shows another scenario whereby the IS-server is co-located in the
router. There the router has access to the upper layer information required
assisting handovers.
/----------\
/ \
-------- -------- -------- /--/ \---\
|IS | | |--+--| |---/ \
|Client |<-----------------|->| IS | / \
| | | | | |Server| \ /
--------- -------- | -------- \ /
Host Access | Router \----\ /-----/
Point | \ /
| -------- / \--------/
+--| | / Core
| IS |-------/ Network
|Server|
--------
Router
Figure 3: IS-Server on Subnet Router
Figures 4 and 5 present the scenarios whereby Information Servers are
deployed outside the mobile node's subnet. It presents both advantages
and challenges. For example, the server is in a position to serve
many access subnets simultaneously, which reduces administrative
overheads. Conversely, network support for discovering the IS-Server
becomes critically important. Since a mobile device may roam within
a domain though, it may not be necessary to discover the server each
time it changes subnet, so long as the mobile remains in the set of
networks covered by the server. For other cases, discovery mechanisms
are important, however, it is currently outside the scope of this document.
/--------\
/ \
------ -------- -------- /----/ -------- \----\
| IS | | |-----| |---/ | | \
|Client|<-------------------------------------->| IS | \
| | | | | | \ |Server| /
-------\ -------- -------- \ -------- /
Host \ Access Router \----\ /----/
\ Point / \ /
\ -------- -------- / \--------/
\ | |-----| | / Core
\ | | | |-------/ Network
\| | | |
-------- --------
Access Router
Point
Visited Network
Figure 3: IS-Server In the Network
/--------\
/ \
----- -------- -------- /----/ \----\
| IS | | |-----| |---/ | ---- | \
|Client|<---------------------------------------> IS | \
| | | | | | \ |Server| /
----- -------- -------- \ -------- /
Host \ Access Router \----\ /----/
\ Point \ /
\ \--------/
\ | Core
\ | Network
\ |
\ |
\ /--------\
\ / \
\-------- -------- /---/ \----\
| |-----| |---/ |-------| \
| | | | | IS | \
| | | |---\ | Server| /
-------- -------- \ | Server| /
Access Router \---\ /----/
Point \ /
\-------/
Visited Network Core
Network
Figure 4: IS-Server In the Network
3.1 Transport-Layer Issues
The existing ready use of IETF developed transport layer protocols is
a compelling reason to develop information services transported over
IP. Particularly, it is valuable to determine if IS requirements
match existing transport models and protocols.
While higher layer information services are non-real time, in some
scenarios (IS-Server within a subnet), the lifetimes of communications
with a particular server may be too short. As such, the sequenced delivery
of packets using TCP may be too complicated for this application heavy
handed [2]. TCP fast recovery relies upon delivery of additional
packets to stimulate additional transmissions of acknowledgements
from a receiver back to a transmitter. Where packet exchanges are
short and sporadic, loss of a packet may not be detected except using
long retransmission timeouts [xx].
3.2 Information Service Discovery Issues
Discovery by the mobile device of the IS-Server either requires
Information Server participation in a discovery protocol, network
entity discovery support or use of a directory service. The
directory service can then refer mobiles to an appropriate server for
their location.
Discovery mechanisms need to provide IP layer contact information for
the IS-Server. Such a discovery system should provide protection
against spoofing, to prevent attackers substituting bogus information
servers.
In IP networks, numerous directory and configuration services already
exist. Use of these services either requires support from locally
discoverable resources within the same IP hop [xx], or rely on
prior configuration of the unicast address of the directory service
[xx]. Prior configuration itself may be performed dynamically, along
with other host services [4][15].
Network entity discovery, such as Router Discovery [9] could allow
discovery of an IS server during routing configuration operations.
If server discovery can be achieved through existing configuration
discovery procedures, no additional packet exchanges would be
required to perform discovery.
As mentioned earlier, discovery of IS server is outside the scope of
this document and therefore no requirements on discovery will be
discussed.
3.3 Reliability Issues
Reliability of IS message exchanges is important and should be supported.
For example, if the messages exchanged for the information service
are assumed to be processed in-order for particular exchanges,
reordering of packets over the Internet may cause problems for IS
function. In that case, transport-layer reliability services may be
required.
Alternatively, where message sequence numbers are incorporated into
the Information Service messages, ordering of packets may be possible
using application-layer information. In this case, it may also be
possible to provide message reliability, on top of a datagram
oriented transport service.
Therefore, reliability may be assumed to be supported either by
the IS protocol or by the user application.
3.4 Congestion Control Issues
Transport protocol like TCP has congestion control mechanism and therefore in such cases this is a non issue. Where existing transport protocols do not incorporate their own congestion control and rate limitation, basic mechanisms for network protection and congestion recovery may need to be added to the IS application protocols.
3.5 Security Issues
Security is important in IP networks, since there is a danger that
attacking devices can attempt to adopt roles as information service
devices. Such bogus devices could cause service degradation through
spurious message exchanges, or by providing false information to
mobile devices.
IS-Servers need both to protect themselves from attack, and to
provide mobile clients provable trust, in order that they can
exchange the information securely and make their handover
decisions without fear of malicious inaccuracies or mischief.
4. Requirements for Transport over IP
Following are the very high level requirements for IS transport over IP and above layers.
4.1 The IS transport MUST work both for IPv4 and IPv6 networks
The choice of transport mechanism should work with both IPv4 and IPv6 networks.
4.2 The IS protocol requires that security MUST be provided at the transport layer
The MIIS message exchanges are critical to handover decision process. Therefore it has to be trusted. However, IS protocol framework does not add security at every message level. Thus it relies upon the underlying security. In such cases, the transport mechanism MUST support the necessary security.
4.2.1 The IS transport MUST provide peer authentication
4.2.2 The IS transport MUST provide message authentication and may provide confidentiality
4.2.3 The IS transport MUST provide replay protection
4.3 The IS transport MUST support the NAT traversal
The transport protocol should allow the communication between MIHFs if they are behind the NAT box.
4.4 The IS transport MUST support the firewall traversal
The transport protocol should allow the communication between MIHFs if they are behind the firewall.
4.5 Changes to the header fields, IEs and structure messages should not affect the security mechanisms defined for underlying transmission.
MIIS defines the IE and MIH protocol formats that are processed by only MIHF peer entities. Any changes to these formats and fields MUST not require modifying the underlying security mechanisms in future.
5. Security Considerations
6. Acknowledgement
|