Re: [802.21] Tomorrow's Telecon material
Ok, let me give some of comments on that first, then
we will talk about further details during teleconf.
Comments are inline with [daniel]
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
--------------------------------------------------------------------------------
[daniel] "if available, pls use an xml2rfc format to compile a document, it
would be very readable for folks."
Media independent Information Service (MIIS) and Its Higher
Layer Transport Requirements
<snipped>
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.
[daniel] "s/MIS/MIIS"
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.
[daniel] "as you wrote above, we can use both signal as lower layer and higher layer, and obviously
this document is just focusing on higher layer. However, I encourage you to explain why lower
layer signal (MIH format) is not suitable for legacy internet architecture. I think it can be described
in Introduction section in brief. Without this concern, it can cause some of misunderstanding for
IETF folks why existing lower layer signal is not useful, and why a new higher layer signal should
be designed in IETF..."
1. Introduction
[daniel] " Bofore jumping to illustrating MIHS stuff, I encourage you to add some of
general text, why 802.21 is needed in terms of mobility / what's trend of
mobility / and related something for easy understanding of non-802.21 guys."
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.
<snipped>
/--------\
/ \
------ -------- -------- /----/ -------- \----\
| IS | | |-----| |---/ | | \
|Client|<-------------------------------------->| IS | \
| | | | | | \ |Server| /
-------\ -------- -------- \ -------- /
Host \ Access Router \----\ /----/
\ Point / \ /
\ -------- -------- / \--------/
\ | |-----| | / Core
\ | | | |-------/ Network
\| | | |
-------- --------
Access Router
Point
Visited Network
Figure 3: IS-Server In the Network
[daniel] "s/Figure 3/Figure 4"
/--------\
/ \
----- -------- -------- /----/ \----\
| 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
[daniel] "s/Figure 4/Figure 5"
<snipped>
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.
[daniel] "Unclear, is there any congestion issue in terms of of MIIS ? It is entirely up to
transport protocol such as TCP/DCCP/etc...not to be resolved by higher IS protoco.
Are you supposed to replace existing congestion control mechanisms with IS protocol ?
It seems too much complex and not reasonable apporoach to me. "
<snipped>
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.
[daniel] "Note: this document does not consider IPv4/IPv6 combined networks. In order
words, There is no guarantee IPv4 (or IPv6) mobile node to communicate with IS
server located in IPv6 (or IPv4) networks."
<snipped>
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
[daniel] "MUST is too much strict if you are refering to Figure 2. No requirement is there
for traversal NAT and FW. And even Figure 3 may not require these requirements. So,
SHOULD would be enough instead."
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.
[daniel] "some requirements seem reasonable at least to me.
4.6 Service Continuity
IS protocol SHOULD allow the service continuity of mobile node's ongoing application
for both homogeneous handover and heterogeneous handover.
4.7 Compromising with IETF Mobility Protocol
IS protocol SHOULD collaborate with existing IETF mobility protocol (IP layer mobility,
transport layer mobility, and even application layer mobility) to maintain mobile
node's IP connectivity.
4.8 Protocol Reusability
IS protocol SHOULD reuse existing IETF protocols whenever available.I.e., security,
authentication, mobility, congestion control, and whatever..."
5. Security Considerations
[daniel] " this section can refer to the 3.5 Security Issues "
6. Acknowledgement