Internet DRAFT - draft-hepworth-mipshop-mih-problem-statement
draft-hepworth-mipshop-mih-problem-statement
MIPSHOP E. Hepworth
Internet-Draft Siemens Roke Manor Research
Expires: December 28, 2006 S. Sreemanthula
Nokia
S. Faccin
Intel
Y. Ohba
Toshiba
June 26, 2006
Media Independent Handovers: Problem Statement
draft-hepworth-mipshop-mih-problem-statement-02
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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
There are on-going activities in the networking community to develop
solutions that aid in IP handover mechanisms between heterogeneous
wired and wireless access systems including, but not limited to, IEEE
Hepworth, et al. Expires December 28, 2006 [Page 1]
Internet-Draft MIH Problem Statement June 2006
802.21. Intelligent access selection, taking into account link layer
attributes, requires the delivery of a variety of different
information types to the terminal from different sources within the
network and vice-versa. The protocol requirements for this
signalling have both transport and security issues that must be
considered. The signalling must not be constrained to specific link
types, so there is at least a common component to the signalling
problem which is within the scope of the IETF. This draft presents a
problem statement for this core problem.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction to IEEE 802.21 . . . . . . . . . . . . . . . . . 4
2.1. Information Services . . . . . . . . . . . . . . . . . . . 4
2.2. Event Services . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Command Services . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Entities . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5
4.1. End-to-End Signalling and Transport over IP . . . . . . . 5
4.2. End-to-End Signalling and Partial Transport over IP . . . 6
4.3. End-to-End Signalling with a Proxy . . . . . . . . . . . . 6
5. Solution Components . . . . . . . . . . . . . . . . . . . . . 7
5.1. Payload Formats and Extensibility Considerations . . . . . 8
5.2. Official IEEE 802.21 Requirements for IP-based
transport . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Other Considerations on the Mobility Service Transport
Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. Security Considerations . . . . . . . . . . . . . . . . . 12
5.5. Conclusions and Open Issues . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Enabling Event and Command Services . . . . . . . . . 14
A.1. Explicit Signaling for Remote Event/Command Services . . . 14
A.2. Mitigation of Security Issues and Validation of
Transported Indications . . . . . . . . . . . . . . . . . 15
A.3. Mapping of Identifiers . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Hepworth, et al. Expires December 28, 2006 [Page 2]
Internet-Draft MIH Problem Statement June 2006
1. Introduction
This Internet Draft provides a problem statement for the exchange of
information to support handover in heterogeneous link environments.
This mobility support service allows more sophisticated handover
operations by making available information about network
characteristics, neighbouring networks and associated
characteristics, indications that a handover should take place, and
suggestions for suitable target networks to which to handover. The
mobility support services work complementarily with IP mobility
mechanisms to enhance the overall performance and usability
perception.
There are two key attributes to the handover support service problem
for inter-technology handovers:
1. The Information and Information Exchange mechanism: this includes
the information elements or data that describe the information,
and any signalling exchanges that are required to support the
transfer of this data. IEEE 802.21 WG has undertaken this
problem of defining the protocol semantics, data formats in a
manner that is independent of transport which carries this
information.
2. The Underlying Transport: this supports the above Information
Exchange between devices in the network. The requirements on
this transfer mechanism include transport issues, because of the
volume of data to be sent, as well as discovery and security
issues for this transport, as the signalling may cross
administrative boundaries and is interdependent with AAA aspects.
This draft has been motivated by on-going work within IEEE 802.21,
but the following description intentionally describes the problem
from a more general perspective. This document represents the views
of the IEEE 802.21 WG and presents official requirements for an IP
transport to support the Information Exchange discussed above.
The structure of this document is as follows. Section 2 provides a
brief overview of the mobility handover services as defined in IEEE
802.21. Section 4 provides a simple model for the protocol entities
involved in the signalling and their possible relationships.
Section 5 describes a decomposition of the signalling problem into
service specific parts and a generic transport part. Section 5.2
describes more detailed requirements for the transport component.
Section 5.4 provides security considerations, and Section 5.5
summarizes the conclusions and open issues.
Hepworth, et al. Expires December 28, 2006 [Page 3]
Internet-Draft MIH Problem Statement June 2006
2. Introduction to IEEE 802.21
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 [1].
They require passing of information within hosts, locally and between
different hosts, remotely. The services are Information Services
(IS), Event Services (ES) and Command Services (CS).
2.1. Information Services
Information Services (IS) are one part of handover services used to
provide network related information about the current or neighboring
networks with same or different access link technology. This allows
the network or host to make informed decisions of which network to
handover to or handover operations to undertake either in response to
certain events, or when planning controlled or commanded handovers.
The IS work complementary to the mobility management protocols in the
capacity that they are utilized before making decisions for handovers
in the aspect of network selection.
2.2. Event Services
Event Services (ES) provide indications from one layer or one
functionality to another about status changes in the connectivity
state. This is particularly relevant to wireless interfaces. It
should be noted that the events of one link technology can be carried
over current or another link technology. Remote event service is a
protocol exchange mechanism between two different network nodes to
inform of ES. 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.3. Command Services
Command Services (CS) provide mechanisms for controlling handovers or
functions aiding handovers either locally or between two functions.
They provide mechanisms to establish, redirect, or remove state in
either the network or mobile node, so that handovers occur smoothly.
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).
Hepworth, et al. Expires December 28, 2006 [Page 4]
Internet-Draft MIH Problem Statement June 2006
3. Protocol Entities
The following section provides an overview of the network entities
that is expected to be involved in the signalling exchanges to
support the handover operation. The following abbreviations are used
in this section:
o MN: mobile node
o NN: network node, intended to represent some device in the network
(the location of the node e.g. in the access network, home network
is not specified, and for the moment it is assumed that they can
reside anywhere).
o EP: endpoint, intended to represent the terminating endpoints of
the transport protocol used to support the signalling exchanges
between nodes.
o 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.
4. Deployment Scenarios
The deployment scenarios are outlined in the following sections.
Note: while MN-to-MN signalling exchanges are theoretically possible,
these are not currently being considered, and are out-of-scope.
The following scenarios are discussed for understanding the overall
problem of transporting MIH protocol and is not intended to show the
scenarios are part of the requirements in the transport design.
4.1. End-to-End Signalling and Transport over IP
In this case, the end-to-end signalling used to exchange the handover
information elements (the Information Exchange) runs end-to-end
between MN and NN. The underlying transport is also end-to-end
Hepworth, et al. Expires December 28, 2006 [Page 5]
Internet-Draft MIH Problem Statement June 2006
+------+ +------+
| MN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
<------------------------------------>
/------------------------------------\
< Transport over IP >
\------------------------------------/
Figure 1: End-to-end Signalling and Transport
4.2. End-to-End Signalling and Partial Transport over IP
As before, the Information Exchange runs end-to-end between the MN
and the second NN. However, in this scenario, some other transport
means is used from the MN to the first NN, and the transport over IP
is used only between NNs. This is analogous to the use of EAP end-
to-end between Supplicant and Authentication Server, with an upper-
layer multihop protocol such as RADIUS used as a backhaul transport
protocol between an Access Point and the Authentication Server.
+------+ +------+ +------+
| MN | | NN | | NN |
| | | (EP) | | (EP) |
+------+ +------+ +------+
Information Exchange
<------------------------------------>
(Transport over /------------------\
<--------------->< Transport over IP >
e.g. L2) \------------------/
Figure 2: Partial Transport
4.3. End-to-End Signalling with a Proxy
In the final case, a number of proxies are inserted along the path
between the two transport endpoints. The use of proxies is possible
in both cases 1 and 2 above, but distinguished here as there are a
number of options as to how the proxy may behave with regard to the
transport and end-to-end signalling exchange.
Hepworth, et al. Expires December 28, 2006 [Page 6]
Internet-Draft MIH Problem Statement June 2006
In this case, the proxy performs some processing on the Information
Exchange before forwarding the information on. This can be viewed as
concatenating signalling exchanges between a number of EPs.
+------+ +---------+ +------+
| MN | | ProxyNN | | NN |
| (EP) | | (EP) | | (EP) |
+------+ +---------+ +------+
Information Exchange
------------------>
------------------->
<-------------------
<------------------
/---------------\ /----------------\
< Transport > < Transport >
\---------------/ \----------------/
Figure 3: Information Exchange Approach
The Proxy NN processes all layers of the protocol suite in the same
way as an ordinary EP.
There is a possibility for realizing other proxy scenarios.
5. Solution Components
Figure 4 shows a model where the Information Exchanges are
implemented by a signalling protocol specific to a particular
mobility service, and these are relayed over a generic transport
layer (the Mobility Service Transport Layer).
Hepworth, et al. Expires December 28, 2006 [Page 7]
Internet-Draft MIH Problem Statement June 2006
+----------------+ ^
|Mobility Support| |
| Service 2 | |
+----------------+ | (e.g. ES) | | Mobility Service
|Mobility Support| +----------------+ | Signaling
| Service 1 | +----------------+ | Layer
| (e.g. IS) | |Mobility Support| |
+----------------+ | Service 3 | |
| (other) | |
+----------------+ V
================================================
+---------------------------------------+ ^ Mobility Service
| Mobility Service Transport Protocol | | Transport
+---------------------------------------+ V Layer
================================================
+---------------------------------------+
| IP |
+---------------------------------------+
Figure 4: Handover Services over IP
The Mobility Service Transport Layer provides certain functionality
(outlined in Section 5.2) to the higher layer mobility support
services in order to support the exchange of information between
communicating mobility service functions. The transport layer
effectively provides a container capability to mobility support
services, as well as any required transport and security operations
required to provide communication without regard to the protocol
semantics and data carried in the specific mobility services.
The Mobility Support Services themselves may also define certain
protocol exchanges to support the exchange of service specific
Information Elements. It is likely that the responsibility for
defining the contents and significance of the Information Elements is
the responsibility of other standards bodies other than the IETF.
Example mobility services include the Information Services, Event and
Command services.
5.1. Payload Formats and Extensibility Considerations
Hepworth, et al. Expires December 28, 2006 [Page 8]
Internet-Draft MIH Problem Statement June 2006
The format of the Mobility Service Transport Protocol is as follows:
+----------------+----------------------------------------+
|Mobility Service| Opaque Payload |
|Transport Header| (Mobility Support Service) |
+----------------+----------------------------------------+
Figure 5: Protocol Structure
The opaque payload encompasses the Mobility Support Service
information that is to be transported. The definition of the
Mobility Service Transport Header is something that is best addressed
within the IETF.
There are a number of issues with regard to the Mobility Support
Service header and payload definition. These include:
1. Responsibility for defining the header: where should the contents
of the Mobility Support Service header be defined, and should
there be one or multiple header definitions (i.e. will a common
header definition for all mobility support services be
adequate?). Where there are commonalities, it may indicate that
these aspects should actually be included in the Mobility Service
Transport Header.
2. Payload Format: the format or the Mobility Support Service Data
payload could be represented in a number of formats, e.g. TLV,
ASN/1, XML or text. Ideally, a single payload representation
should be defined, as support for multiple formats leads to
unnecessary complexity. It is expected that a set of Data
Objects will be defined for the Mobility Support Services to
exchange.
3. Sharing of Data Objects: which refers to sharing the definitions
of Data Objects between Mobility Support Services, e.g. if a
Capabilities object is defined that is used by multiple Mobility
Support Services, should the same definition be used by all of
them. If this is the case, then a common identifier space is
needed to identify the different Data Objects. There is a
question about where the definition of Data Objects and the
management of the identifier space should take place.
The answers to some of the above issues may in part depend on how
many standards groups are interested in defining their own Mobility
Support Services.
Hepworth, et al. Expires December 28, 2006 [Page 9]
Internet-Draft MIH Problem Statement June 2006
5.2. Official IEEE 802.21 Requirements for IP-based transport
o The transport protocol must work regardless of the network
location of the MIH Protocol Entity e.g. on the same subnet, or
deep in the network belonging to same or different IP
administrative domain.
o The transport protocol must be capable to support both IPv4 and
IPv6 versions.
o The transport protocol must be capable of delivering time-
sensitive MIH information.
o The transport protocol must enable Network address Translation
(NAT) traversal for IPv4 networks.
o The transport protocol must enable Firewall pass-through for IPv4
and IPv6 networks.
o The discovery protocol must work regardless of the network
location of the MIH Protocol Entity e.g. on the same subnet, or
deep in the network belonging to same or different IP
administrative domain.
o The discovery protocol must work for IPv4 and IPv6 hosts.
o The discovery protocol must allow for more than one MIH Protocol
Entity to be discovered at a time.
o The discovery protocol must enable Network Address Translator
(NAT) traversal for IPv4 networks.
o The discovery protocol must enable Firewall pass-through for IPv4
and IPv6 networks.
o The security mechanism must provide a common security association
(SA) negotiation method regardless of the network location of the
MIH Protocol Entity e.g. on the same subnet, or deep within the
network.
o The security mechanism must provide mutual authentication of MIH
end nodes.
o The security mechanism may provide one way authentication of
either of MIH end nodes.
o The security mechanism must provide integrity protection for MIH
Protocol exchanges.
Hepworth, et al. Expires December 28, 2006 [Page 10]
Internet-Draft MIH Problem Statement June 2006
o The security mechanism may provide confidentiality for the MIH
Protocol exchanges.
o The security mechanism must protect against replay attacks.
o The security mechanism may protect MIH service entities and
discovery resources against denial of service
o attacks.
o The security mechanism must not be dependent on the MIH protocol.
o The security mechanism may provide means to reuse or fast
reestablishment the SA due to host mobility.
5.3. Other Considerations on the Mobility Service Transport Layer
The following section outlines some of other considerations for
design of the Mobility Service Transport Protocol. Analysis within
IEEE 802.21 has suggested that at least the following need to be
taken into account:
Congestion Control: A Mobility Service may wish to transfer large
amounts of data, placing a requirement for congestion control in
the transport. There is an interaction between this requirement
and that of the requirement for low latency since ways to deal
with timely delivery of smaller asynchronous messages around the
larger datagrams is required (mitigation of head of line blocking
etc.).
Multiplexing: The transport service needs to be able to support
different mobility services. This may require multiplexing and
the ability to manage multiple discovery operations and peering
relationships in parallel.
Multihoming: For some information services exchanged with the MN,
there is a possibility that the request and response messages can
be carried over two different links e.g. a handover command
request is on the current link while the response could be
delivered on the new link. Depending on the IP mobility
mechanism, there is some impact on the transport option for the
mobility information services. This may potentially have some
associated latency and security issues, for example, if the
transport is over IP there is some transparency but Mobile IP may
introduce additional delay and both TCP and UDP must use the
permanent address of the MN.
In addition to the above, it may be necessary for the transport to
Hepworth, et al. Expires December 28, 2006 [Page 11]
Internet-Draft MIH Problem Statement June 2006
support multiple applications (or modes of operation) to support the
particular requirements of the Information Exchange being carried out
between nodes. This may require the ability to multiplex multiple
information exchanges into a single transport exchange.
5.4. Security Considerations
Network supported mobility services aim at improving decision making
and management of dynamically connected hosts. The control and
maintenance of mobile nodes becomes challenging where authentication
and authorization credentials used to access a network are
unavailable for the purpose of bootstrapping a security association
for handover services.
Information Services may not require authorization of the client, but
both event and command services must authenticate message sources,
particularly if they are mobile. Network side service entities will
typically need to provide proof of authority to serve visiting
devices. Where signalling or radio operations can result from
received messages, significant disruption may result from processing
bogus or modified messages. The effect of processing bogus messages
depends largely upon the content of the message payload, which is
handled by the handover services application. Regardless of the
variation in effect, message delivery mechanisms need to provide
protection against tampering, and spoofing.
Sensitive and identifying information about a mobile device may be
exchanged during handover service message exchange. Since handover
decisions are to be made based upon message exchanges, it may be
possible to trace an user's movement between cells, or predict future
movements, by inspecting handover service messages. In order to
prevent such tracking, message confidentiality should be available.
This is particularly important since many mobile devices are
associated with only one user, as divulgence of such information may
violate the user's privacy. Additionally, identifying information
may be exchanged during security association construction. As this
information may be used to trace users across cell boundaries,
identity protection should be available if possible, when
establishing SAs.
In addition, the user should not have to disclose its identity to the
network (any more than it needed to during authentication) in order
to access the Mobility Support Services. For example, if the local
network is just aware that an anonymous user with a subscription to
operatorXYX.com is accessing the network, the user should not have to
divulge their true identity in order to access the Mobility Support
Services available locally.
Hepworth, et al. Expires December 28, 2006 [Page 12]
Internet-Draft MIH Problem Statement June 2006
Finally, the network nodes themselves will potentially be subject to
denial of service attacks from MNs and these problems will be
exacerbated if operation of the mobility service protocols imposes a
heavy computational load on the NNs. The overall design has to
consider at what stage (e.g. discovery, transport layer
establishment, service specific protocol exchange) denial of service
prevention or mitigation should be built in.
5.5. Conclusions and Open Issues
This Internet draft outlined a broad problem statement for the
signalling of information elements across a network to support media
independent handover services. In order to enable this type of
signalling service, a need for a generic transport solution with
certain transport and security properties were outlined. Whilst the
motivation for considering this problem has come from work within
IEEE 802.21, a desirable goal is to ensure that solutions to this
problem are applicable to a wider range of mobility services.
It would be valuable to establish realistic performance goals for the
solution to this common problem (i.e. transport and security aspects)
using experience from previous IETF work in this area and knowledge
about feasible deployment scenarios. This information could then be
used as an input to other standards bodies in assisting them to
design mobility services with feasible performance requirements.
Much of the functionality required for this problem is available from
existing IETF protocols or combination thereof. This document takes
no position on whether an existing protocol can be adapted for the
solution or whether new protocol development is required. In either
case, we believe that the appropriate skills for development of
protocols in this area lie in the IETF.
6. Acknowledgements
Thanks to Greg Daley and Subir Das for engaging in good discussions.
Thanks to Robert Hancock, Andrew McDonald and Jari Arkko for their
inputs. Thanks to the IEEE 802.21 chair, Vivek Gupta for
coordinating the work and supporting the IETF liaison.
7. References
[1] "Draft IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE LAN/MAN Draft IEEE
P802.21/D01.00, March 2006.
[2] Adoba, B., "Architectural Implications of Link Indications
Hepworth, et al. Expires December 28, 2006 [Page 13]
Internet-Draft MIH Problem Statement June 2006
draft-iab-link-indications-03.txt", June 2005.
Appendix A. 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.
This draft does not propose any specific solutions.
[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.
A.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).
Hepworth, et al. Expires December 28, 2006 [Page 14]
Internet-Draft MIH Problem Statement June 2006
A.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,
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 briefly described in this document and IEEE 802.21 [1], 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
are 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 subscription 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.
Hepworth, et al. Expires December 28, 2006 [Page 15]
Internet-Draft MIH Problem Statement June 2006
Mobile Node Network
|-------------------------------------| |---------|
+----------+ +--------+ +--------+ +-------+
| Appl./ | | | | | | |
| Transp./ | |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.
A.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.
Hepworth, et al. Expires December 28, 2006 [Page 16]
Internet-Draft MIH Problem Statement June 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 subscription 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.
Hepworth, et al. Expires December 28, 2006 [Page 17]
Internet-Draft MIH Problem Statement June 2006
Authors' Addresses
Eleanor Hepworth
Siemens Roke Manor Research
Roke Manor
Romsey, SO51 5RE
UK
Email: eleanor.hepworth@roke.co.uk
Srinivas Sreemanthula
Nokia
6000 Connection Dr.
Irving, TX 75028
USA
Email: srinivas.sreemanthula@nokia.com
Stefano Faccin
Intel
2200 Mission College Blvd
Santa Clara, CA 95054
USA
Email: stefano.faccin@intel.com
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway NJ 08854
USA
Email: yohba@tari.toshiba.com
Hepworth, et al. Expires December 28, 2006 [Page 18]
Internet-Draft MIH Problem Statement June 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.
Hepworth, et al. Expires December 28, 2006 [Page 19]
