| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello participants,
Sorry for the delay in conf information.
But, here is the adhoc telecon information for tomorrow ( 3/ 2) regarding ES/CS
information.
Tentative
Agenda:
1.
Agree on the registration contribution for March
meeting.
2. Go
over ES/CS v2 draft for
comments
3.
Discussion on session-id, to resolve open
issues
Regards,
Srini
PS: I have
also enclosed minutes from last
meeting.
Name of the conference: IEEE 802.21 ES/CS Discussions Time: 8-10am CT Conference ID: 59976, PIN: 387105 US Phone Number: 972-894-6500 EU Phone Number: +358 7180 71870 Type of reservation: Single reservation: 02 .03 .2006 (GMT-06:00) Central Time (US & Canada) Number of participants: 20 Instructions language: English Features: participant's identification |
21-05-xxx-00-0000-Feb16_2006_Telecon_Meeting_Minutes.doc
MIPSHOP Working Group S. Sreemanthula
Internet-Draft S. Faccin
Expires: September 7, 2006 Nokia
E. Hepworth
Siemens Roke Manor
G. Daley
Panasonic
march 06, 2006
A Problem Statement for Event Services and Command Services for Media
Independent Handovers
draft-sreemanthula-es-cs-problem-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses the usage scenarios and usage models of event
services and command services involving inter-system IP mobility,
specifically media independent handovers. The discussion is intended
Sreemanthula, et al. Expires September 7, 2006 [Page 1]
Internet-Draft ES/CS for MIH march 2006
to aid the MIPSHOP WG in understanding the problem domain of the
event and command services in the Internet.
Sreemanthula, et al. Expires September 7, 2006 [Page 2]
Internet-Draft ES/CS for MIH march 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Remote Command Service (CS) . . . . . . . . . . . . . . . 5
2.2. Local Command Service . . . . . . . . . . . . . . . . . . 6
2.3. Remote Event Service (ES) . . . . . . . . . . . . . . . . 6
2.4. Local Event Service . . . . . . . . . . . . . . . . . . . 6
2.5. Information Service (IS) . . . . . . . . . . . . . . . . . 6
2.6. Inter-technology Handover . . . . . . . . . . . . . . . . 6
2.7. Media Independent Handover Function (MIHF) . . . . . . . . 7
2.8. Mobility Management Entity (MME) . . . . . . . . . . . . . 7
2.9. Network node . . . . . . . . . . . . . . . . . . . . . . . 7
2.10. Access Network Node . . . . . . . . . . . . . . . . . . . 7
2.11. Core Network Node . . . . . . . . . . . . . . . . . . . . 7
2.12. Proxy Network Node . . . . . . . . . . . . . . . . . . . . 7
2.13. Network-Controlled Handover . . . . . . . . . . . . . . . 7
2.14. Station (STA) . . . . . . . . . . . . . . . . . . . . . . 8
3. Architectural Issues . . . . . . . . . . . . . . . . . . . . . 8
3.1. Network Controlled Mobility Scenarios . . . . . . . . . . 8
3.2. Remote Event Services . . . . . . . . . . . . . . . . . . 9
3.2.1. Event Services Classification . . . . . . . . . . . . 10
3.3. Remote Command Services . . . . . . . . . . . . . . . . . 11
3.4. Information Services . . . . . . . . . . . . . . . . . . . 12
4. Usage Models for Event Services . . . . . . . . . . . . . . . 12
5. Usage Models for Command Services . . . . . . . . . . . . . . 14
6. Usage Scenarios for Remote Events and Commands . . . . . . . . 15
6.1. Network-Controlled Handover Scenarios . . . . . . . . . . 15
6.2. Network Selection . . . . . . . . . . . . . . . . . . . . 16
6.3. Handover Control . . . . . . . . . . . . . . . . . . . . . 18
7. Enabling Event and Command Services . . . . . . . . . . . . . 20
7.1. Feasibility of Remote Events and Commands . . . . . . . . 21
7.1.1. Explicit Signaling for Remote Event/Command
Services . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.2. Mitigation of Security Issues and Validation of
Transported Indications . . . . . . . . . . . . . . . 21
7.1.3. Mapping of Identifiers . . . . . . . . . . . . . . . . 23
7.2. Transport Selection Requirements . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8.1. Event Service Considerations . . . . . . . . . . . . . . . 26
8.2. Command Service Considerations . . . . . . . . . . . . . . 26
8.3. Security Considerations for Transport . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Sreemanthula, et al. Expires September 7, 2006 [Page 3]
Internet-Draft ES/CS for MIH march 2006
1. Introduction
Handover services are a class of network services, which aim at
providing service continuity and transparency to users during changes
in network point of attachments and assist the quality of handovers
available to wireless 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. Such
information include reporting events by a mobile node to the network
and vice versa, as well as issuing inter-technology handover commands
by the network to the mobile node.
Performing inter-technology handover management requires homogeneity
in information exchange mechanisms between mobile node and network
for all of the involved systems. In most 3GPP systems, such
information exchange happens using existing protocols on the
signaling plane that are specific to 3GPP. In IEEE 802 systems, and
especially in WLAN, appropriate information exchange between the
mobile nodes and the network for handover control by the network does
not exist. In general, there is currently no mechanism that can be
applied to various technologies (e.g. 3GPP wireless links, IEEE 802
wireless links, etc.) to enable the exchange of information between
mobile nodes and the network to support management and control of
inter-technology handover.
Potentially, standardization fora (e.g. 3GPP) may define solutions to
support the exchange of information between mobile nodes and the
network to support management and control of inter-technology
handover in a way that is applicable to 3GPP systems for various
access technologies. However, several parties believe that an
alternative that shall be considered is to adopt solutions being
developed in IEEE 802.21 and enable the use of IP transport
mechanisms for such solutions, since this would facilitate the
deployment of seamless mobility services in networks where access-
technology specific solutions do not exist or the equipment has not
been updated to include such solutions. It is certain that
performances considerations will have to be well understood. It is
also worthwhile mentioning that not all seamless mobility scenarios
require extremely high performance in terms of latency reduction, as
described in this draft.
At this time, three broad classes of services for handover
assistance, particularly aiming at improving the inter-technology,
are under consideration within the IEEE 802.21 Working Group. They
require passing of information within hosts, locally and between
different hosts, remotely. The services are Event Services (ES),
Command Services (CS), and Information Services (IS). Specifically:
Sreemanthula, et al. Expires September 7, 2006 [Page 4]
Internet-Draft ES/CS for MIH march 2006
o Event Services (ES) provide indications from one layer or
functionality to another about changes in the connectivity state.
This is particularly relevant to wireless interfaces.
o Command Services (CS) provide mechanisms for controlling handovers
or functions aiding handovers. They provide mechanisms to
establish, redirect, or remove state in either the network or
mobile node, so that handovers occur smoothly.
For details on the IS, [1] contains a detailed description.
Each service carry L2-specific information that may be processed
locally or require communication with peer services on other nodes,
and this communication may be transported over IP, to communicate
with peer services on other nodes. The main relevance of ES and CS
to IETF and the MIPSHOP WG is the exchange of information related to
ES and CS between peer nodes. This is referred to as Remote ES and
Remote CS.
The IETF has been working on how handover services can be used to
assist mobility signaling protocols, and has been analyzing
interactions between handover services and network/transport layers.
At the same time, other groups (e.g. IEEE 802.21) have been taking a
more generally applicable view.
This document provides a view of the authors, and does not represent
the official view of either IEEE 802.21 or an IETF WG. Assistance is
sought to improve this document, in order to reflect consensus
viewpoints from the appropriate groups.
2. Terminology and Definitions
This section defines terminology used in this draft. Where not
defined, refer to [6] for Mobility Related Terminology - RFC 3753.
2.1. Remote Command Service (CS)
Remote command service is a protocol exchange mechanism between
network nodes to instruct the recipient network nodes to execute a
specific function. Execution of a command service at the mobile node
or a node in the network may result in loss of current link
connectivity and/or change in the network point of attachment.
Receipt and processing of a command belonging to the CS generates an
expected response in the receiving node (e.g. create a new link layer
connection, disconnect a link layer connection, etc).
Sreemanthula, et al. Expires September 7, 2006 [Page 5]
Internet-Draft ES/CS for MIH march 2006
2.2. Local Command Service
Local command service is a communication facility within a host
enabling one functionality to request execution of certain commands
in certain other functionality (e.g. the IP function may request to
establish a connection over a link layer).
2.3. Remote Event Service (ES)
Remote event service is a protocol exchange mechanism between network
nodes to inform of recently happened or impending change in link or
network status information. The event notification can originate
either from a mobile node or a node in the network. Receipt and
processing of an event belonging to the ES may generate a reaction in
the receiving node (e.g. trigger IP layer mobility).
2.4. Local Event Service
Local event service is a communication facility within a host for one
functionality to provide indications or notifications of certain
state changes pertaining to the network to a certain other
functionality (e.g. IEEE 802.11 MAC layer may inform the IP function
that the wireless signal is lost). In [2], indication of local event
services is referred to as link indications. In this document, local
event services include indications generated at other layers than
link layer (e.g. IP layer or layers above the IP layer).
2.5. Information Service (IS)
Information service is a protocol exchange mechanism between network
nodes to provide or query information related to specific networks.
For more information see [1].
2.6. Inter-technology Handover
In this document the term Inter-Technology Handover refers to
handover of communications between different wireless technologies.
Specifically, the following cases are considered:
o Handover between 3GPP wireless links and IEEE 802.11
o Handover between 3GPP wireless links and IEEE 802.16
o Handover between IEEE 802.11 and and IEEE 802.16
Other scenarios involving IEEE 802 technology may also be considered.
Handover between different wireless technologies defined in 3GPP and
with GSM are defined in 3GPP and are not considered to be inter-
Sreemanthula, et al. Expires September 7, 2006 [Page 6]
Internet-Draft ES/CS for MIH march 2006
technology handover in this document. Similarly, 3GPP inter-GGSN
handover is out of scope.
2.7. Media Independent Handover Function (MIHF)
Media independent handover function is a shim layer in the mobility
management protocol stack of the mobile nodes or network element that
provide media independent or inter-technology mobility, specifically
handovers (e.g. as defined in IEEE 802.21). MIHF utilizes the event
services and command services. "MIHF(CS)" and "MIHF(ES)" refer to
command services and event services part of the MIHF, respectively.
2.8. Mobility Management Entity (MME)
A mobility management entity implements network selection and
handover decision algorithms and utilizes mobility signaling
protocols and other protocols that aid in mobility functions. MME
functionality utilizes MIHF.
2.9. Network node
It is any node that is part of the network. It includes mobile
nodes, link layer nodes (e.g IEEE 802.11 AP, IEEE 802.16 BS) and IP
or higher layer nodes (e.g. routers, servers, etc.).
2.10. Access Network Node
Access network node is a Network Node that provides link layer
services to the mobile nodes (e.g. AP or base station).
2.11. Core Network Node
A core network node is node in the network beyond an/the access
network that is reachable by mobile nodes only by IP based protocols.
The core network node can only originate or terminate protocol
messages.
2.12. Proxy Network Node
A proxy network node is node in the network in or beyond an/the
access network that can neither originate nor terminate protocol
messages, but can only pass or proxy protocol messages to a different
network node.
2.13. Network-Controlled Handover
In this document the term Network-Controlled Handover refers to an
Inter-Technology Handover where a function in the network makes the
Sreemanthula, et al. Expires September 7, 2006 [Page 7]
Internet-Draft ES/CS for MIH march 2006
handover decision (e.g. based on information from the mobile node,
network policies, etc.)
2.14. Station (STA)
See the definition of mobile node in [6]. This is a specific term
used in IEEE 802.11 wireless technologies.
3. Architectural Issues
This section covers several architectural issues involved with Media
Independent Handovers. These issues are not all tightly coupled
together, but form parts of the overall problem space for Media
Independent Handovers.
3.1. Network Controlled Mobility Scenarios
Several operators or network service providers, including those
deploying multiple access technologies, view their network resources
as a single resource pool. These resources are used to maximize
their network efficiency and improve the performance, thus providing
a better user experience. This can be viewed as something analogous
to a network pool of multiple routers for network balance and
redundancy and increased capacity to reroute traffic and relieve
congestion under heavy loads in their network.
For access involving radio technologies, the available network
bandwidth is directly related to the available frequency spectrum.
For a given cost, radio technologies provide varied degrees of QoS
affecting the user experience. This is due to the varied cost of
spectrum acquisition and network deployment of various radio
technologies. Also at any given instant, the service providers,
including those with multiple access technologies, would like to see
that no specific part their network, is operating under heavy loads
and prefer to balance the traffic across all the available network
paths for optimum performance. Generally speaking, the network
wishes to exercise control over the mobile nodes to make use of a
certain network path for mutual benefit of the users and the service
providers themselves.
The network, therefore, reserves the right to make handover decisions
at the MME, for mobile nodes to utilize a more optimized network
path. When multiple link technologies are involved, this could also
mean that the network may instruct the mobile nodes to handover from
current link technology to handover to another link technology. MME
may make use of several parameters like subscription agreement, user
device capabilities, network policies, roaming agreements, network
Sreemanthula, et al. Expires September 7, 2006 [Page 8]
Internet-Draft ES/CS for MIH march 2006
load conditions, overall cost to the user and of course, the user
experience to arrive at a certain handover decision.
3.2. Remote Event Services
Remote event services are the exchange of notification or indication
messages of certain network status changes between peer network nodes
at the same layer (above IP in this draft context). The state change
refers to either the conditions of the existing link (e.g. a link
layer connectivity is lost) or of the newly detected links (e.g. the
mobile node can detect the presence of a new link technology, e.g. it
receives beacons from an IEEE 802.11 AP that was previously not
visible). Remote event services are different from link indications
as defined in [2] in that link indications are defined to carry
information from the link layer to the upper layer like local event
services. However, the remote event services can utilize link
indications as one triggering mechanism to send event information to
the same layer on a peer network node. There can be other triggering
mechanisms, perhaps from other layers in the node that may also
result in event notifications.
Remote event services can be originated by a mobile node and
transported to a peer network node and vice versa. It is also
possible for remote event services to be exchanged between two nodes
in the network. In the same capacity, the events originated by a
network node can be proxied by another node and terminated at a
different node. It should be highlighted that the remote event
services are envisioned to be used as an opt-in feature, meaning that
a requesting entity would register for specific event types that it
is interested in and provide the appropriate filter rules when that
specific event type must be matched. These features will ensure that
the protocol does not result in excessive load on either the network
or the network node processing the event notification reports from
multiple event generating nodes.
Figure 1 shows a high-level usage model for the event services. Link
layers at any network node can provide triggers or link indications
to notify the state change to the upper layers. The triggers can
also be originated from other sources at various layers or
functionality within the same host. These trigger indications are
checked and scoped based on the filters set by the requesting entity.
Trigger indications that do not match the existing filter sets are
discarded and for those that match, a corresponding event indication
is sent to the requesting node.
Sreemanthula, et al. Expires September 7, 2006 [Page 9]
Internet-Draft ES/CS for MIH march 2006
|-------------------------| |---------------------------|
+-------+ Other +--------+Remote Event+--------+ Other +-------+
| Other |------->| MIHF |<---------->| MIHF |<-------|Other |
|Sources|triggers| (ES) | Services | (ES) |triggers|Sources|
+-------+ +--------+ +--------+ +-------+
^ ^
Link | | Link
Indications | | Indications
| |
+-------+ +-------+
| Link | | Link |
| Layer | | Layer |
+-------+ +-------+
|-------------------------| |----------------------------|
Network Network
Node Node
Fig.1 Event Service Model.
3.2.1. Event Services Classification
Event services can be broadly classified to incorporate two different
types of network notifications, Micro and Macro. While the event
services discussed in this draft include both of these types, it
mainly details those to be used specifically for macro network
events. This is based on the view from earlier studies compiled by
[2] which show that some link indications can result in unreliable
information and also that the transport of such micro events would
result in a higher network load.
3.2.1.1. Micro Network Events
Micro network events refer to event notifications corresponding to
microscopic changes in the network state information. The reporting
of events between two nodes can be scoped or filtered to provide
minute changes in the network state information. Examples of such
events are Link-Parameters-Change, Link-Going-Down, Link-Threshold-
Exceeded etc. Perhaps, within an example implementation, Link-Up and
Link-Down could also be considered as micro network events with
varying degrees, if the event reporting is scoped for state changes
within the same AP, same subnet or same access technology.
Generally, these network events may be characterized by frequent
exchange of messages between the peer nodes to report minute changes
in the state information.
Sreemanthula, et al. Expires September 7, 2006 [Page 10]
Internet-Draft ES/CS for MIH march 2006
3.2.1.2. Macro Network Events
Macro network events refer to macroscopic changes in the network
state information. Here, the reporting of events between two nodes
is scoped or filtered to provide only macroscopic changes in the
network. These can be triggered due to link indications such as
Link-Detect, Link-Up, Link-Down involving subnet changes across same
or multiple access networks. As explained before, it is also
possible for other sources to generate the triggers. Generally,
these network notifications may be characterized by an infrequent
exchange of messages between the peer nodes, depending on the nature
of the mobility of the mobile node itself.
The choice of triggering indications in combination with the filters
(e.g. a set of parameter and/or measurements), set by the requesting
nodes, can be used to unambiguously trigger the macro network events.
E.g. only a new link-detect indication with a filter for strong
signal strength would result in an event notification for
Link_Detect.
3.3. Remote Command Services
Remote command services form a request-response mechanism utilized by
the nodes in the network to instruct other network nodes to carry out
or execute a specific function affecting the current link or a
different link. Commands can also impact other layers, e.g. IP
layer. The result of the command execution is provided in a response
back to the originating node. The nodes receiving and executing the
commands can either be a node in the network or a mobile node. In
the same capacity, it is possible for one node to originate the
service and another node to pass or proxy the service to a different
node that terminates and executes the command. The remote command
services are utilized as part of the MIHF which is in turn employed
by the MME that implements handover decision algorithms for various
mobile nodes. The functionality of MME or the handover decision
algorithms are outside the scope of this draft.
As compared to remote event services, the remote command services do
not use opt-in features, meaning there is no registration needed to
receive commands. However, the command services may use filtering
information to scope the extent of execution of commands. E.g. the
MME may command the mobile node to scan for specific access
technologies in its vicinity.
Some basic examples for remote command service are listed below:
1. Link-switch to switch from one link to another link
Sreemanthula, et al. Expires September 7, 2006 [Page 11]
Internet-Draft ES/CS for MIH march 2006
2. Link-scan to scan for specific links in the vicinity
Figure 2 shows a high level usage model for the remote command
services. MME may initiate command requests based on certain
handover decision algorithms addressing a specific mobile node to the
MIHF(CS). The request is translated to a CS request and forwarded to
the MIHF(CS) in the target node where the c ommand will be executed.
Depending on the type of the command, the execution may affect the
link layer or other functionality in the same host. After the
command is executed the result of command is carried back in a CS
response to the originating node and finally to the MME.
|------------------------------| |--------|
+---------+ Commands +--------+ Remote Command +--------+
| Other |<-------->| MIHF |<-------------->| MIHF |
| Layers/ | req/resp | (CS) | Service | (CS) |
|Functions| +--------+ +--------+
+---------+ | |
Link | |Commands
Commands | |req/resp
V V
+-------+ +-------+
| Link | | MME |
| Layer | | |
+-------+ +-------+
|------------------------------| |-------|
Network Network
Node Node
Fig.2 Command Service Model.
3.4. Information Services
Information services are covered in detail in [1]. Information
services, in a nut shell, provide a information query mechanism for
network nodes to obtain information about specific networks and their
capabilities. The event and command services covered in this draft
work in conjunction with the information services. The information
service plays a critical role in the network selection at the mobile
node or in the network. Section 9 on usage scenarios will show the
extent of their interworking and how they complement each other to
achieve a common goal of enabling such scenarios.
4. Usage Models for Event Services
The following usage models are shown as examples of possible models
Sreemanthula, et al. Expires September 7, 2006 [Page 12]
Internet-Draft ES/CS for MIH march 2006
that the event services are expected to enable. The list is not
exhaustive and furthermore it is possible to derive new models using
a combination of these models.
-----> wireless link
/
+-------+ Remote ES / +-------+
| MIHF |-------------->| MIHF |
| (ES) | Services | (ES) |
+-------+ +-------+
Mobile Access, Proxy or Core
Node Network Node
Fig.3 ES: Mobile Node to Access, Proxy or Core Network Node.
-----> wireless link
/
+-------+ Remote ES / +-------+
| MIHF |-------------->| MIHF |
| (ES) | Services | (ES) |
+-------+ +-------+
Mobile Access or Core
Node Network Node
Fig.4 ES: Mobile Node to Access or Core Network Node.
+-------+ Remote ES / +-------+
| MIHF |-------------->| MIHF |
| (ES) | Services | (ES) |
+-------+ +-------+
Access Network Core Network
Node Node
Fig.5 ES: Access Network Node to Core Network Node.
+-------+Remote ES+-------+Remote ES+-------+
| MIHF |-------->| MIHF |-------->| MIHF |
| (ES) |Services | (ES) | Services| (ES) |
+-------+ +-------+ +-------+
Access Network Proxy Core Network
Sreemanthula, et al. Expires September 7, 2006 [Page 13]
Internet-Draft ES/CS for MIH march 2006
or Mobile Node Network Node Node
Fig.6 ES: Network Node to Proxy Network Node to Core Network Node.
5. Usage Models for Command Services
The following usage models are shown as some of the possible models
that the command services are expected to enable. The list is not
exhaustive and further, it is possible to derive new models using a
combination of these models.
-----> wireless link
/
+-------+ Remote CS / +-------+
| MIHF |<--------------| MIHF |
| (CS) | Services | (CS) |
+-------+ +-------+
Mobile Access, Proxy or Core
Node Network Node
Fig.7 CS: Access or Core Network Node to Mobile Node.
+-------+ Remote CS / +-------+
| MIHF |<--------------| MIHF |
| (CS) | Services | (CS) |
+-------+ +-------+
Access Network Core Network
Node Node
Fig.8 CS: Core Network Node to Access Network Node.
+-------+Remote CS+-------+Remote CS+-------+
| MIHF |<--------| MIHF |<--------| MIHF |
| (CS) |Services | (CS) | Services| (CS) |
+-------+ +-------+ +-------+
Access Network Proxy Core Network
or Mobile Node Network Node Node
Fig.9 CS: Network Node to Proxy Network Node to Network Node.
Sreemanthula, et al. Expires September 7, 2006 [Page 14]
Internet-Draft ES/CS for MIH march 2006
6. Usage Scenarios for Remote Events and Commands
While the authors of this draft agree with most of the comments
raised in [2], the authors believe that remote transport of events
for ES is feasible under specific conditions.
The intention behind ES and CS is not to cater for every possible
scenario, but to target specific scenarios. In particular, the focus
is on network architectures deploying multiple access technologies,
where inter-technology handover is required.
6.1. Network-Controlled Handover Scenarios
Remote ES and CS can be used as enablers for network-controlled
handover scenarios between different access technologies. The
discussion of network-controlled can easily raise a long list of
questions regarding the feasibility of e.g. sending information in
real-time between the mobile node and the MME, and of sending
commands between the MME and the mobile node. The issue considered
in these cases is typically the delay that can be introduced by the
transport and that may make the overall handover delay quite
considerable. This document does not discuss these specific issues,
and does not argue in favor or against such issues. However, in
order to identify some of the scenarios of applicability for Remote
ES and CS for network-controlled handover, we need to consider the
following classification of handovers. There are two main reasons to
perform an handover:
1. degradation of current link/connection quality: the quality of
the link is degrading and it is necessary to perform an handover
to avoid losing the current connection;
2. "opportunistic" handover: due to a set of events and based on
specific policies, it is preferable to move the communication to
another link.
In order to support inter-technology network-controlled handovers the
first case, the delay between the moment the handover decision is
made and the moment the command to perform the handover is received
by the mobile node needs to be considered carefully. However, for
"opportunistic" handover the impact of such delay is less
significant, since the mobile node is not having any degradation over
the current link, and the handover will be performed because the
network has policies indicating that it is preferable to move to the
new link.
One motivation for performing opportunistic network-controlled
handover is load sharing, in scenarios where a network exercises
Sreemanthula, et al. Expires September 7, 2006 [Page 15]
Internet-Draft ES/CS for MIH march 2006
tight control of various wireless link technologies to distribute the
load of communications according to network policies.
The network may perform a network-controlled handover decision in at
least two steps.
1. Network selection, and
2. Handover control.
The two steps are described in the following sections
6.2. Network Selection
Network selection is a process of selecting a favorable network for a
mobile node to transfer or handover the ongoing services to the
selected network. The selected network may be a different link
technology from the previous one. It may also be possible that the
mobile node, after handover, may not experience exactly the same
level of QoS as the current link due to this network selection. But,
in general, it may result in some user benefit in one way or another
e.g. cost savings, higher bandwidth etc. MME in the network may have
access to subscriber profile, contracts, and device capabilities to
make use of the network selection algorithms for a certain subscriber
or mobile node.
Figure 10 shows a simple network selection procedure with the help of
the mobile node. This example call flow diagram employs remote event
services and information services. Remote command services are not
used in this particular example, however, they can also be useful in
the network selection mechanisms under certain scenarios. E.g.
depending on user geographical location, the network may command the
mobile node to perform a scan for a specific 802.11 network and
report the results that can be used in the network selection process.
In the scenario shown, the mobile node initially performs a
registration or attachment to the network on any link, e.g. 3GPP
network. The MME and the mobile node are able to discover each other
in the same or following step. MME may then register for specific
remote event services, e.g. ES-link-detect by sending a registration
request and filter information for both 802.16 and 802.11 networks.
The mobile node accepts the request with a positive reply. From time
to time, the mobile node may receive broadcast information from
802.11 and 802.16 networks. In this scenario, the 802.16 broadcast
is received and a link-detect is sent by the 802.16 MAC layer to the
MIHF(ES). The MIHF(ES) translates this to an ES-link-detect message
to the MIHF(ES) in the network (collocated in the MME) with the basic
network information received in the broadcast.
Sreemanthula, et al. Expires September 7, 2006 [Page 16]
Internet-Draft ES/CS for MIH march 2006
The MME requests for more information about the network via the IS
query to an IS server to check the suitability of the detected
network due to roaming agreements [1]. The MME decides that this
particular 802.16 network is not a favorable network and takes no
action. The mobile node also takes no action and does not report the
detection of same network more than once. At a later time, the
mobile node may receive beacon information from 802.11 AP and the MAC
layer in the mobile node reports the to the MIHF(ES) along with the
SSID information. The MIHF(ES) provides this information to the MME
in the network. The MME may perform an IS query based on the SSID
information and determines that this SSID belongs to a favorable
network. The network selection process, thereby, is completed.
Sreemanthula, et al. Expires September 7, 2006 [Page 17]
Internet-Draft ES/CS for MIH march 2006
Mobile Node
|----------------------|
+--------+ +-------+ +-------+ +------+ +------+ +------+
|MIHF(ES)| | Link | | MME | | IS | |802.16| |802.11|
| | | Layers| | | | | | | | |
+--------+ +-------+ +-------+ +------+ +------+ +------+
| | | | | |
+------------------------------+ | | |
| Discovery & Registration | | | |
+------------------------------+ | | |
| 1.ES-reg-req | | | |
|<========================| | | |
| 2.ES-reg-resp | | | |
|========================>| | | |
~ ~ ~ ~ ~
| |3.DL-burst| | | |
| 4.link-detect|<--------------------------------| |
|<-------------| | | | |
| 5.ES-link-detect | | | |
|========================>|6.IS-query| | |
| | |--------->| | |
| | +-------------+ | | |
| | |not favorable| | | |
| | +-------------+ | | |
~ ~ ~ ~ ~ ~
| |7.Beacon | | | |
|8.link-detect |<-------------------------------------------|
|<-------------| | | | |
| 9.ES-link-detect | | | |
|========================>|10.IS-query | |
| | |--------->| | |
| | +-----------+ | | |
| | | favorable | | | |
| | +-----------+ | | |
| | | | | |
+--------+ +-------+ +-------+ +------+ +------+ +------+
|----------------------|
Legend: ===== Remote ES over current link
Fig.10 Network Selection in Network.
6.3. Handover Control
Handover control procedure follows a network selection process as
explained in the previous section. The following scenario in Figure
11 shows a network-controlled handover procedure with fast MIP
handover signaling [3]. Here, the MME in the network utilizes
Sreemanthula, et al. Expires September 7, 2006 [Page 18]
Internet-Draft ES/CS for MIH march 2006
MIHF(CS) and generates a link switch command with CS-switch-reg to
the mobile node. The parameters in the message may include that a
make-before-break mechanism is to be performed along with the target
link information e.g. 802.11 network as shown from the network
selection procedure earlier.
The MICH(CS) indicates the Mobile IP function of the impending link
switch along with new link information. The Mobile IP functionality,
If necessary, i.e., it does not have a valid Access Router Tuple-Info
[3], it sends a Proxy Router Solicitation (PrRtrSol) with the new
link information (e.g. MAC address of AP) and the Proxy Router
Advertisement (PrRtrAdv) provides the relevant L3 information for the
mobile node to use on the new link. The MIHF(CS) in the mobile node
executes the command by sending an "associate" request to the 802.11
MAC which will perform all necessary L2 association and
authentication procedures for the new link. For completeness, steps
3 and 4 in figure 11 can take place in parallel to steps 3 and 4.
A link-up indication is sent to the interested parties including
Mobile-IP functionality. Mobile-IP sends a Fast Binding Update (FBU)
to the old FA over the old link so that old FA could switch (tunnel)
the packets to the new FA. The mobile node now is able to receive
packets from new FA that are tunneled from old FA. At a later time,
the mobile node performs an Mobile IP update procedure to update the
binding in the HA and reroute the tunnels directly from HA to the new
FA in the new network corresponding to the 802.11 link. Once the
traffic uses the new link, the MIHF(CS) releases the old link by
sending a request to that MAC layer, here the 3GPP radio link. A CS-
switch-resp is sent back to the MME upon completion of the command.
The following signaling flow shows how the network controlled handoff
can work with fast MIP handover signaling [3]. It shows a make-
before-break mechanism, so that the mobile node sends the FBU on the
old link after the setup of the new link to minize the latency due to
L2 association and authentication procedures. For completeness,
steps 3 and 4 in figure 11 can take place in parallel to steps 2 and
3.
Sreemanthula, et al. Expires September 7, 2006 [Page 19]
Internet-Draft ES/CS for MIH march 2006
Mobile Node
|--------------------------------|
+--------+ +--------+ +-------+ +-----+ +------+ +------+ +-----+
|MobileIP| |MIHF(CS)| | Link | | MME | |802.11| | FA | | HA |
| | | | | Layers| | | | | | | | |
+--------+ +--------+ +-------+ +-----+ +------+ +------+ +-----+
| | | | | | |
| | | +-----------+ | | |
| | | | Network | | | |
| | | | Selection | | | |
| | | |(sect. 9.1)| | | |
| | | +-----------+ | | |
| | 1.CS-switch-req | | | |
|2.switch-ind|<======================| | | |
|<-----------| 3. PrRtrSol | | | |
|=========================================================>| |
| | 4. PrRtrAdv | | | |
|<=========================================================| |
| |3.associate| | | | |
| |---------->| 4.L2 Association | | |
| 5.link-up | |<-------------------->| | |
|<-----------------------| | | | |
| | 6. FBU | | | |
|=========================================================>| |
+---------------------------------------------------------------------------+
| Mobile IP update procedure over new link |
+---------------------------------------------------------------------------+
| |7.release | | | | |
| |---------->| | | | |
| | 8.CS-switch-resp | | | |
| |>>>>>>>>>>>>>>>>>>>>>>>| | | |
| | | | | | |
+-------+ +-------+ +------+ +-----+ +------+ +------+ +-----+
|-------------------------------|
Legend: ===== over current link, >>>>>> over new link
Fig.11 Network-Controlled Handover Procedure.
7. Enabling Event and Command Services
This section analyzes the feasibility of remote events and commands,
and describes a set of requirements to enable remote ES and CS. The
section discusses some potential solutions to solve some issues
typically associated with remote events and explicit signaling.
However, such solutions are discussed just to provide example of how
drawbacks and limitations identified e.g. in [2] can be overcome.
Sreemanthula, et al. Expires September 7, 2006 [Page 20]
Internet-Draft ES/CS for MIH march 2006
This draft does not propose any specific solutions.
7.1. Feasibility of Remote Events and Commands
[2] contains a set of observations on requirements that solutions
need to fulfill to justify and enable transport of events between
peer entities over the media (e.g. wireless link). This section
addresses these observations in order to assess the feasibility of
remote ES and CS.
7.1.1. Explicit Signaling for Remote Event/Command Services
[2] indicates that alternatives not requiring explicit signaling are
preferred, and that explicit signaling proposals must prove that
existing explicit signaling mechanisms are inadequate.
Implicit signaling (e.g. path change processing and link-aware
routing metrics) has been considered for the scenarios described in
this draft. However, implicit signaling may not work in several
cases of inter-technology handover. As an example, in certain
scenarios the handover is executed but the mobile node does not move
between subnets (e.g. in 3GPP networks where the GGSN and the PDG are
located in the same subnet). In other scenarios, explicit signaling
is required between the mobile node and a network node to report
events related to an access link different from the one currently
being used by the mobile node (e.g. a mobile node using a 3GPP link
detects the availability of a WLAN link). Such events would not be
visible to the network node without explicit signaling.
Various wireless technologies already have defined mobility
management solutions that deploy explicit signaling to support
handover (e.g. 3GPP, 3GPP2, IEEE 802.16, etc.), or are at present
developing new solutions (e.g. IEEE 802.11 Fast BSS Transition).
However, such solutions are clearly defined for intra-technology
handover (e.g. 3GPP solutions apply to handover between 3GPP
technologies). However, none of these wireless technologies has
defined a solution that is applicable to inter-technology handover
(e.g. between different IEEE 802 access links, or between a 3GPP
access link and an IEEE 802 access link).
7.1.2. Mitigation of Security Issues and Validation of Transported
Indications
The validity of the information delivered through explicit signaling
in the Remote Event Service and the Remote Command Service is
essential to guarantee that the mobile node or the network node make
handover decision and perform handover based on valid conditions. In
[2] the issue of validity of the indications is correctly raised,
Sreemanthula, et al. Expires September 7, 2006 [Page 21]
Internet-Draft ES/CS for MIH march 2006
since in a generic model the receiver of the indication (e.g. the
mobile node) may not have the ability to verify if the indication has
e.g. been sent by a host off the actual path in use, and therefore
possibly not capable of providing accurate indications.
With the specific model for Remote Event Services and Remote Command
Services described in this document, as described in section 9 a
"relationship" is generated between the mobile node and an MME
through a process of discovery and registration. Authentication can
be part of such process (possibly mutual authentication), as
described in the security considerations. Considering this specific
model, information in Remote Event Service and Remote Command Service
a re generated by a node with which the recipient of the Remote Event
Service and Remote Command Service has setup a relationship before
hand. It is up to the recipient to ensure during the discovery and
registration process that the source of Remote Event Service and
Remote Command Service is reputable and can provide accurate
information. An example of how this can be achieved is based on
authentication mechanisms and the adoption of a trust model similar
to those adopted in current networks for authentication of roaming
users. The mobile node can authenticate with a home domain/network
based on a subscription with such domain/network. If the MME is
located e.g. in the home network, the MME can authenticate with the
MME based on credentials the mobile node possesses as a result of the
subscription. If the MME is e.g. in the visited domain, a transitive
trust model can be adopted, where the mobile node authenticates with
the home domain/network based on a subcription and through the
visited domain. As a result, a security association is established
between the mobile node and the MME. A model similar to the one
adopted in AAA can be adopted.
Sreemanthula, et al. Expires September 7, 2006 [Page 22]
Internet-Draft ES/CS for MIH march 2006
Mobile Node Network
|-------------------------------------| |---------|
+----------+ +--------+ +--------+ +-------+
| Appl./ | | | | | | |
| Trasnp./ | |MIHF(ES/| | Link | | MME |
| Network | | CS) | | Layers | | |
| Layers | | | | | | |
+----------+ +--------+ +--------+ +-------+
| | | |
+---------------------------------+ |
| +-----------------+ | |
| | Mapping of | | |
| |Local Identifiers| | |
| +-----------------+ | |
+---------------------------------+ |
| | | |
+--------------------------------------------------------+
| Discovery |
+--------------------------------------------------------+
| | | |
+--------------------------------------------------------+
| Registration |
| +----------------------------------------------------+ |
| | Authentication | |
| +----------------------------------------------------+ |
| |
+--------------------------------------------------------+
| | | |
| Security Association |
|<==============================================>|
| | | |
| Media Independent Host ID |
|<==============================================>|
| | | |
+----------+ +--------+ +--------+ +-------+
|-------------------------------------| |---------|
Legend: ===== shared between
Fig.12 Mobile Node - MME Relationship and Mapping of Identifiers.
7.1.3. Mapping of Identifiers
[2] raises a legitimate issue regarding the fact that typically the
IP layer, the link layer, the transport layer and the application
layer use different identifiers, and therefore reporting of
information regarding these layers to a remote node may require
matching the various identifiers.
Sreemanthula, et al. Expires September 7, 2006 [Page 23]
Internet-Draft ES/CS for MIH march 2006
When local event services generate indications within a host (e.g.
the mobile node), the host has detailed knowledge of the various
identifiers used at the different layers (e.g. the IP address, the
MAC addresses for the various IEEE 802 accesses, etc.). As depicted
in figure 12, an MIHF located in the mobile node can maintain a local
mapping of the various identifiers. When the mobile node discovers
and registers with another network node (e.g. an MME), an identifier
specific to Remote Event Services and Remote Command Services can be
adopted to uniquely identify the mobile node , e.g. a Media
Independent Host Identifier. The Media Independent Host Identifier
can be e.g. assigned to the mobile node by the home network as part
of a set of subcription credentials. The Media Independent Host
Identifier could be a new identifier, or an existing identifier could
be reused (e.g. NAI). Subsequently, all the remote even
notifications and remote command exchanges can be based on the Media
Independent Host Identifier, therefore limiting the need to maintain
the mapping between different identifiers at different layers local
to the host.
7.2. Transport Selection Requirements
A transport MUST be selected for the event and command services based
on general protocol requirements discussed in this draft.
o Provide a remote ES/CS service transport mechanism which works
with both IPv6 and IPv4.
o Enable efficient, optimized and timely delivery of ES/CS
information.
o Distinguish between the packet source and query source (allow
proxies).
o Enable NAT traversal for IPv4 networks.
o Enable Firewall traversal for IPv4 and IPv6 networks.
o Optionally allow for multiple queries per transport session.
o Optionally ensure compatability between the ES/CS transport and
those required for information services transport.
o Describe an ES/CS discovery mechansism for IPv4 and IPv6 hosts.
o Provide a common discovery method regardless of whether the ES/
CS-Server is on the same subnet, or deep within the network.
Sreemanthula, et al. Expires September 7, 2006 [Page 24]
Internet-Draft ES/CS for MIH march 2006
o Optionally ensure compatability between the Event and Command
Services over IP, and those required for information services
discovery mechansisms.
o Allow for more than one ES or CS Server to be discovered at a
time.
o Provide a common SA negotiation method regardless of whether the
ES/CS-Server is on the same subnet, or deep within the network.
o Protect against ES/CS-Server and wireless device impersonation
(with authentication).
o Protect against data insertion and modification (provide message
authentication).
o Protect against replay attacks.
o Provide confidentiality of query and response contents.
o Protect the identity of a querier against eavesdroppers.
o Protect ES/CS-Server and discovery resources against denial of
service.
o Minimize computational and transmission resources for mobile
clients.
o Provide compatability with Address or Security Association
Mobility management, to allow use of an ES/CS server after host
movements without renegotiating an SA.
o Allow for security services to be diabled.
o Changes to the ES/CS payload should not affect the security
mechanisms defined in the underlying transport mechanism to ensure
protocol modifications and evolutions defined in payload.
8. Security Considerations
When exchanging events and commands between hosts, extreme caution
needs to be exercised in establishing communications securely.
Unless endpoints are identified and authorized for communications,
one or more service entities may be affected by state changes as a
result of inappropriate registration, event or command reception.
Sreemanthula, et al. Expires September 7, 2006 [Page 25]
Internet-Draft ES/CS for MIH march 2006
8.1. Event Service Considerations
When receiving events, their impact on entities in their target layer
(for example the link-layer for link-indications) may be well
defined. Their effect on other protocol layers may be unclear
though. This may be the case because changes to protocol entities at
one layer do not cause changes in another, or because the event is
not considered trustable or authoritative [2].
Event indications are therefore likely to be interpreted as hints by
other protocol layers, without necessarily modifying protocol state.
Where unauthorized third parties impersonating legitimate ES entities
can generate hints, attackers can cause damage to communications to
or from a mobile node. Such bogus hints can potentially cause
additional packet transmissions at other layers, cause a host to be
denied service or cause non-preferred services to be selected.
Unless appropriate security mechanism and a security model are
adopted, attacks may be particularly simple on a wireless medium,
where even valid event messages may be replayed at a later stage by
an attacker.
As event services allow events to be delivered across multiple IP
forwarding hops, spoofed ES messages potentially may arrive from
anywhere on the Internet. In order to mitigate this issue, where
signaling is constrained to be within an IP subnet, link-local
signaling may be appropriate [4][5].
For event services generated beyond the local link, security
mechanisms need to be in place to ensure that the node receiving an
ES message can verify the source of the message and the validity of
the message (e.g. to avoid tampering or injection of bogus ES
messages).
Events sent to network side ES entities may cause changes to services
provided to a wireless terminal. Such events could then generate
further events and commands to be generated. Also, the mobile node
to which the bogus events referred may be unaware of the event
delivery, or indeed of any reaction to the event within the network.
8.2. Command Service Considerations
Command services experience most of the same attacks as event
services, although their effects may be even more severe. CS deal
with impending, typically mandatory, state changes which control the
association and allocated resources of the network or mobile node.
Therefore, a recipient of a command may feel compelled to comply with
Sreemanthula, et al. Expires September 7, 2006 [Page 26]
Internet-Draft ES/CS for MIH march 2006
a requested state change, even if the change is not legitimate or
useful. This can be used to force disconnection or poor service
selection. This level of control over remote services requires very
careful monitoring and access control.
8.3. Security Considerations for Transport
Remote Command and Event services using a transport at IP level or
above need in several cases to traverse network boundaries.
Considering that transport for Remote Command and Event services
should not be restricted to IPv4-only or IPv6-only, crossing
boundaries implies that the messages for Remote Command and Event
services need to traverse both firewall and NATs. It is essential
for Remote Command and Event services to maintain the security of
existing networks and not create new threats when crossing
boundaries. At the same time, it must be ensured that Remote Command
and Event services using a transport at IP level can cross NATs and
firewalls.
9. IANA Considerations
The IANA provide registry services for a large number of protocol
identifiers used within IETF-related protocols.
The IEEE standards association maintains its own registries for
organizationally unique identifiers, ethertypes, and logical link
control identifiers.
This document does not in itself cause changes or demands to be
placed upon the IANA or IEEE registries.
Subsequent development of standards which may reference or create
IANA or IEEE registries have the potential induce changes of loads
particular registries.
Proposals for Remote Event Services and Remote Command Services need
to ensure that any envisaged use development of registries are
compatible with the registry operation's charter and resources.
10. Conclusions
The scenarios describing the problem in the draft show the possible
usage extent of event and command services in aiding the inter-system
mobility. Event and command services can serve inter-system
handovers by providing an interface between the multi-access handover
logic to the functional entities that executes mobility signaling in
Sreemanthula, et al. Expires September 7, 2006 [Page 27]
Internet-Draft ES/CS for MIH march 2006
the mobile node or in the network.
11. Acknowledgments
The author would like to acknowledge and thank the participants of
this working group and IEEE 802.21 community for openly discussing
the problem and showing interest to solve it.
12. References
[1] Daley, G. and S. Faccin, "Requirements for a Media Independent
Handover Information Service draft-faccin-mih-infoserv-00.txt",
June 2005.
[2] Adoba, B., "Architectural Implications of Link Indications
draft-iab-link-indications-03.txt", June 2005.
[3] Koodli, R., "RFC4068: Fast Handovers for Mobile IPv6",
July 2005.
[4] Deering, S. and R. Hinden, "RFC2460: Internet Protocol, Version
6 (IPv6) Specification", December 1998.
[5] Hinden, R. and S. Deering, "RFC3513: Internet Protocol Version 6
(IPv6) Addressing Architecture", April 2003.
[6] Manner, J. and M. Kojo, "RFC3753: Mobility Related Terminology",
June 2004.
Sreemanthula, et al. Expires September 7, 2006 [Page 28]
Internet-Draft ES/CS for MIH march 2006
Authors' Addresses
Srinivas Sreemanthula
Nokia
NH3:400
6000 Connection Dr.
Irving, TX 75039
USA
Phone: +1 9728945000
Email: srinivas.sreemanthula@nokia.com
Stefano Faccin
Nokia
NH3:400
6000 Connection Dr.
Irving, TX 75039
USA
Phone: +1 9728945000
Email: stefano.faccin@nokia.com
Eleanor Hepworth
Siemens Roke Manor
Romsey
Hants S051 0ZN
UK
Phone:
Email: eleanor.hepworth@roke.co.uk
Greg Daley
Panasonic Digital Networking Laboratory
2 Research Way
Princeton, New Jersey 08540
USA
Phone: +1 609 734 7334
Email: greg.daley@research.panasonic.com
Sreemanthula, et al. Expires September 7, 2006 [Page 29]
Internet-Draft ES/CS for MIH march 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sreemanthula, et al. Expires September 7, 2006 [Page 30]
21-06-0503-03-0000-es-cs-hl-reqs.doc