MIPSHOP T. Melia
Internet-Draft NEC
Intended status: Informational E. Hepworth
Expires: July 11, 2007 Siemens Roke Manor Research
S. Sreemanthula
Nokia Research Center
Y. Ohba
Toshiba
G. Vivek
Intel
J. Korhonen
TeliaSonera
R. Aguiar
IT
Sam(Zhongqi). Xia
HUAWEI
January 7, 2007
Mobility Independent Services: Problem Statement
draft-ietf-mipshop-mis-ps-00
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 July 11, 2007.
Copyright Notice
Melia, et al. Expires July 11, 2007 [Page 1]
Internet-Draft Mobility Services January 2007
Copyright (C) The Internet Society (2007).
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
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.
Melia, et al. Expires July 11, 2007 [Page 2]
Internet-Draft Mobility Services January 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Mobility Independent Services . . . . . . . . . 5
4. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5
4.1. End-to-End Signalling and Transport over IP . . . . . . . 6
4.2. End-to-End Signalling and Partial Transport over IP . . . 6
4.3. End-to-End Signalling with a Proxy . . . . . . . . . . . . 7
4.4. End-to-End Network-to-Network Signalling . . . . . . . . . 8
5. Solution Components . . . . . . . . . . . . . . . . . . . . . 8
5.1. Payload Formats and Extensibility Considerations . . . . . 9
5.2. Requirements on the Mobility Service Transport Layer . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Melia, et al. Expires July 11, 2007 [Page 3]
Internet-Draft Mobility Services January 2007
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, neighboring 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: the information elements being exchanged. The
messages could be of different nature, such as Information,
Command or Event, potentially being defined following a common
structure as defined.
2. The Underlying Transport: the transport mechanism to support
exchange of the information elements mentioned above. This
transport mechanism includes information transport, discovery of
peers, and the securing of this information over the network.
This draft has been motivated by on-going work within IEEE 802.21
[1], but the following description intentionally describes the
problem from a more general perspective. This document represents
the views of the authors, and does not represent the official view of
IEEE 802.21.
The structure of this document is as follows. Section 3 defines
mobility services. 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 6 provides security considerations, and Section 7
summarizes the conclusions and open issues.
2. Terminology
The following abbreviations are used in the document:
o MIH: media independent handover
Melia, et al. Expires July 11, 2007 [Page 4]
Internet-Draft Mobility Services January 2007
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.
Generalizing, we call this functional entity Policy Decision Point
which acts upon events and combines required actions with user
profiles. The MME is able to collect information either from
other network nodes or from the MN.
3. Definition of Mobility Independent Services
As mentioned in the introduction mobility (handover) support in
heterogeneous wireless environments requires functional components
located either in the mobile terminal or in the (access) network to
exchange information and eventually to take decisions upon this
information exchange. For instance traditional host-based handover
solutions could be complemented with more sophisticated network-
centric solutions reducing terminal complexity. Also, neighborhood
discovery, potentially a complex operation in heterogeneous wireless
scenarios, can result in a more simple step if implemented with an
unified interface towards the access network.
In this document the different supporting functions for media
independent handover (MIH) management are generally referred as
Mobility Independent Services (MIS) having in common different
requirements for the transport protocol. These requirements and
associated functionalities are the focus of this document
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. Although these are all
Melia, et al. Expires July 11, 2007 [Page 5]
Internet-Draft Mobility Services January 2007
possible scenarios and MIH services can be delivered through link-
layer specific solutions and/or through a "layer 3 or above"
protocol, this problem statement focuses on the delivery of
information for MIH services for the latter case only.
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
+------+ +------+
| 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 than IP 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.
Melia, et al. Expires July 11, 2007 [Page 6]
Internet-Draft Mobility Services January 2007
+------+ +------+ +------+
| 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.
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.
Melia, et al. Expires July 11, 2007 [Page 7]
Internet-Draft Mobility Services January 2007
4.4. End-to-End Network-to-Network Signalling
In this case NN to NN signalling is envisioned. Such model should
allow different network components to gather information from each
other. This is useful for instance in conditions where network
components need to take decisions and instruct mobile terminals of
operation to be executed.
+------+ +------+
| NN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
------------------->
<-------------------
/----------------\
< Transport >
\----------------/
Figure 4: Information Exchange between different NN
Network nodes exchange information about connected terminals status.
5. Solution Components
Figure 5 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).
Melia, et al. Expires July 11, 2007 [Page 8]
Internet-Draft Mobility Services January 2007
+----------------+ ^
|Mobility Support| |
| Service 2 | |
+----------------+ | | | Mobility Service
|Mobility Support| +----------------+ | Signaling
| Service 1 | +----------------+ | Layer
| | |Mobility Support| |
+----------------+ | Service 3 | |
| | |
+----------------+ V
================================================
+---------------------------------------+ ^ Mobility Service
| Mobility Service Transport Protocol | | Transport
+---------------------------------------+ V Layer
================================================
+---------------------------------------+
| IP |
+---------------------------------------+
Figure 5: 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
Melia, et al. Expires July 11, 2007 [Page 9]
Internet-Draft Mobility Services January 2007
The format of the Mobility Service Transport Protocol is as follows:
+----------------+----------------------------------------+
|Mobility Service| Opaque Payload |
|Transport Header| (Mobility Support Service) |
+----------------+----------------------------------------+
Figure 6: 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.
Melia, et al. Expires July 11, 2007 [Page 10]
Internet-Draft Mobility Services January 2007
5.2. Requirements on the Mobility Service Transport Layer
The following section outlines some of the general transport
requirements that should be supported by the Mobility Service
Transport Protocol. Analysis has suggested that at least the
following need to be taken into account:
Discovery: MNs need the ability to locate nodes that support
particular mobility services in the network. There are no
assumptions about the location of these mobility services within
the network, therefore the discovery mechanism needs to operate
across administrative boundaries. Issues such as speed of
discovery, protection against spoofing, when discovery needs to
take place, and the length of time over which the discovery
information may remain valid all need to be considered.
Approaches include:
* Hard coding information into the MN, indicating either the IP
address of the NN, or information about the NN that can be
resolved onto an IP address. The configuration information
could be managed dynamically, but assumes that the NN is
independent of the access network to which the MN is currently
attached.
* Pushing information to the MN, where the information is
delivered to the MN as part of other configuration operations,
for example, in a Router Discovery exchange. The benefit of
this approach is that no additional exchanges with the network
would be required, but the limitations associated with
modifying these protocols may limit applicability of the
solution.
* MN dynamically requesting information about a service, which
may require both MN and NN support for a particular service
discovery mechanism. This may require additional support by
the access network (e.g. multicast or anycast) even when it may
not be supporting the service directly itself.
Numerous directory and configuration services already exist, and
reuse of these mechanisms may be appropriate. There is an open
question about whether multiple methods of discovery would be
needed, and whether NNs would also need to discover other NNs.
The definition of a service also needs to be determined, including
the granularity of the description (for example, should the MN
look for an "IS" service, or "IS-local information", and "IS-home
network information" services.
Melia, et al. Expires July 11, 2007 [Page 11]
Internet-Draft Mobility Services January 2007
Information from a trusted source: The MN uses the Mobility Service
information to make decisions about what steps to take next. It
is essential that there is some way to ensure that the information
received is from a trustworthy source. This includes cases where
trusted proxies along the path have access to, and may modify,
parts of the Mobility Service information. This requirement
should reuse trust relationships that have already been
established in the network, for example, on the relationships
established by the AAA infrastructure after a mutual
authentication, or on the certificate infrastructure required to
support SEND [9].
Low latency: Some of the Mobility Services generate time sensitive
information. Therefore, there is a need to deliver the
information over quite short timescales, and the required lifetime
of a connection might be quite short lived. For reliable
delivery, short-lived connections could be set up as and when
needed, although there is a connection setup latency associated
with this approach. Alternatively, a long-lived connection could
be used, but this requires advanced warning of being needed and
some way to maintain the state associated with the connection. It
also assumes that the relationships between devices supporting the
mobility service are fairly stable. Another alternative is
connectionless operation, but this has interactions with other
requirements such as reliable delivery.
Reliability: Reliable delivery for some of the mobility services may
be essential, but it is difficult to trade this off against the
low latency requirement. It is also quite difficult to design a
robust, high performance mechanism that can operate in
heterogeneous environments, especially one where the link
characteristics can vary quite dramatically. There are two main
approaches that could be adopted:
1. Assume the transport cannot be guaranteed to support reliable
delivery. In this case, the Mobility Support Service itself
will have to provide some sort of reliability mechanism to
allow communicating endpoints to acknowledge receipt of
information.
2. Assume the underlying transport will deal with most error
situations, and provide a very basic acknowledgement mechanism
that (if no acknowledgement is received) will indicate that
something more serious has occurred than a packet drop (since
these other types of error conditions are dealt with at the
transport layer).
Option 1 has a number of disadvantages associated with it, namely
Melia, et al. Expires July 11, 2007 [Page 12]
Internet-Draft Mobility Services January 2007
that ultimately the protocol design ends up re-inventing a lot of
the functionality already available in lower layers at a higher
layer where access to information about what is going on in the
network is restricted. For example, how will the higher layer
determine the cause of the error, if a message is lost due to
network congestion, it is pointless sending the message again. It
also adds to the complexity of the higher layer protocol, and
makes successful deployment less certain (the protocol will have
to be trialed in a number of network situations instead of re-
using a protocol that has already been tested).
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.).
Secure delivery: The Mobility Service information must be delivered
securely between trusted peers, where the transport may pass
though untrusted intermediate nodes and networks. Design
considerations include whether session based or host based
security associations are required along the chain of NNs, and
what the rate limitation requirements of requests/responses might
be.
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
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
Melia, et al. Expires July 11, 2007 [Page 13]
Internet-Draft Mobility Services January 2007
information exchanges into a single transport exchange (see figure
Figure 7) .
+==================================+
| |
| +------------+ +-----------+ |
| | MIH | | MIH | |
| | User 1 | | User 2 |... |
| | e.g. MIP | | e.g. SIP | |
| ++++++++++++++ +++++++++++++ | _ ..............
| \ / | \__ : MIH :
| \ / | _/ :Multiplexing:
| +++++++++++++++++++++ | :............:
| | MIH Function | |
| | (e.g. MIS) | |
| +++++++++++++++++++++ |
| /\ |
| || | ..............
| || | : Transport :
| \/ | :Multiplexing:
| +++++++++++++++++++++ | :............: +---------+
| | Transport | | ____/\____ | MIH |
| | (e.g. TCP, UDP) | | / \ |.........|
| +++++++++++++++++++++ | |Transport|
| /\ | |.........|
| || | _____| IP |
| || | / +=========+
| || | /
| \/ | ^+++++++++^ / +---------+
| +++++++++++++++++++++ | / \ / | MIH |
| | IP |--------|--< Internet > ----- |.........|
| +++++++++++++++++++++ | \ / | \ |Transport|
| | v+++++++++v | \ |.........|
| | | \__| IP |
+==================================+ | +=========+
| :
| :
| +---------+
| | MIH |
| |.........|
| |Transport|
| |.........|
|________| IP |
+=========+
Figure 7: Multiplexing examples
Melia, et al. Expires July 11, 2007 [Page 14]
Internet-Draft Mobility Services January 2007
6. 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.
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
Melia, et al. Expires July 11, 2007 [Page 15]
Internet-Draft Mobility Services January 2007
establishment, service specific protocol exchange) denial of service
prevention or mitigation should be built in.
7. Conclusions
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.
8. References
[1] "Draft IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE LAN/MAN Draft IEEE
P802.21/D03.00, November 2006.
[2] Adoba, B., "Architectural Implications of Link Indications
draft-iab-link-indications-03.txt", June 2005.
[3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.
Melia, et al. Expires July 11, 2007 [Page 16]
Internet-Draft Mobility Services January 2007
[6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
RFC 4555, June 2006.
[7] 3GPP, "3GPP system architecture evolution (SAE): Report on
technical options and conclusions", 3GPP TR 23.882 0.10.1,
February 2006.
[8] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[9] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
Authors' Addresses
Telemaco Melia
NEC Europe Network Laboratories
Kufuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511 42
Email: telemaco.melia@netlab.nec.de
Eleanor Hepworth
Siemens Roke Manor Research
Roke Manor
Romsey, SO51 5RE
UK
Email: eleanor.hepworth@roke.co.uk
Srivinas Sreemanthula
Nokia Research Center
6000 Connection Dr.
Irving, TX 75028
USA
Email: srinivas.sreemanthula@nokia.com
Melia, et al. Expires July 11, 2007 [Page 17]
Internet-Draft Mobility Services January 2007
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway NJ 08854
USA
Email: yohba@tari.toshiba.com
Vivek Gupta
Intel Corporation
2111 NE 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503 712 1754
Email: vivek.g.gupta@intel.com
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FIN-00051 Sonera
FINLAND
Phone: +358 40 534 4455
Email: jouni.korhonen@teliasonera.com
Rui L.A. Aguiar
Instituto de Telecomunicacoes Universidade de Aveiro
Aveiro 3810
Portugal
Phone: +351 234 377900
Email: ruilaa@det.ua.pt
Sam(Zhongqi) Xia
Huawei Technologies Co.,Ltd
HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base,Hai-Dian District Beijing
100085
P.R. China
Phone: +86-10-82836136
Email: xiazhongqi@huawei.com
Melia, et al. Expires July 11, 2007 [Page 18]
Internet-Draft Mobility Services January 2007
Full Copyright Statement
Copyright (C) The Internet Society (2007).
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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Melia, et al. Expires July 11, 2007 [Page 19]
