wdiff rfc5164.original rfc5164.txt

MIPSHOP
Network Working Group T. Melia
Internet-Draft Melia, Ed.
Request for Comments: 5164 NEC
Intended status:
Category: Informational E. Hepworth
Expires: May 15, March 2008 Siemens Roke Manor Research
S. Sreemanthula
Nokia Research Center
Y. Ohba
Toshiba
G. Vivek
Intel
J. Korhonen
TeliaSonera
R. Aguiar
IT
S. Xia
HUAWEI
November 12, 2007

Mobility Services Transport: Problem Statement
draft-ietf-mipshop-mis-ps-05

Status of this 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

This memo provides information for 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. community. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list does
not specify an Internet standard of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list any kind. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 15, 2008.

Abstract

There are on-going ongoing 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 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
problem, which is within the scope of the IETF. This draft document
presents a problem statement for this core problem.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 .....................................................3
2.1. Requirements Language ......................................3
3. Definition of Mobility Services . . . . . . . . . . . . . . . 5 .................................4
4. Deployment Scenarios for MoS . . . . . . . . . . . . . . . . . 5 ....................................4
4.1. End-to-End Signalling and Transport over IP . . . . . . . 6 ................5
4.2. End-to-End Signalling and Partial Transport over IP . . . 6 ........5
4.3. End-to-End Network-to-Network Signalling . . . . . . . . . 7 ...................6
5. MoS Transport Protocol Splitting . . . . . . . . . . . . . . . 7 ................................7
5.1. Payload Formats and Extensibility Considerations . . . . . 8 ...........8
5.2. Requirements on the Mobility Service Transport Layer . . . 9 .......8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. ........................................11
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. ....................................................12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. General requirements . . . . . . . . . . . . . . . . . . . 14
10.2. IETF transport protocol requirements . . . . . . . . . . . 15
10.3. IETF discovery protocol requirements . . . . . . . . . . . 15
10.4. IETF security requirements . . . . . . . . . . . . . . . . 16
11. ...............................................13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. .....................................................13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. ......................................13
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 20 ....................................13
Contributors ......................................................14

1. Introduction

This Internet Draft document provides a problem statement for the exchange of
information to support handover in heterogeneous link environments
[1] .
[1]. 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 are complementary to IP mobility mechanisms [4], [5], [6],
[7], [8], [9] 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 a different nature, such as information,
commands to perform an action, or events informing of a change,
potentially being defined following a common structure.

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.

The initial requirement for this protocol comes from the need to
provide a transport for the Media Independent Handover (MIH) protocol
being defined by IEEE 802.21[1] 802.21 [1], which is not bound to any specific
link layer and can operate over more that one network-layer hop. The
solution should be flexible to accommodate evolution in the MIH
standard, and should also be applicable for other new mobility
signalling protocols which that have similar message patterns and discovery
and transport requirements.

The structure of this document is as follows. Section 3 defines
mobility services.
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 service-specific parts and a generic transport part.
Section 5.2 describes more detailed requirements for the transport
component. Section 7 6 provides security considerations, and considerations. Section 8 7
summarizes the conclusions and open issues.

2. Terminology

The following abbreviations are used in the document:

MIH: media independent handover Media Independent Handover

MN: mobile node Mobile Node

NN: network node, Network Node, intended to represent some device in the network
(the location of the node e.g. node, e.g., in the access network, the home
network is not specified, and for the moment it is assumed that
they can reside anywhere).

EP: endpoint, Endpoint, intended to represent the terminating endpoints of
the transport protocol used to support the signalling exchanges
between nodes.

3. Definition of Mobility Services

As mentioned in the introduction mobility (handover) support in
heterogeneous wireless environments requires functional components
located either in the mobile terminal

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].

3. Definition of Mobility 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 network to exchange
information and eventually to take make decisions upon this information
exchange. For instance instance, traditional host-based handover solutions
could be complemented with more sophisticated network-centric
solutions. Also, neighborhood discovery, potentially a complex
operation in heterogeneous wireless scenarios, can result in a
simpler step if implemented with an a unified interface towards the
access network.

In this document document, the different supporting functions for media
independent handover Media
Independent Handover (MIH) management are generally referred to as
Mobility Services (MoS) having that have different requirements for the
transport protocol. These requirements and associated
functionalities are the focus of this document. Speaking 802.21
terminology
terminology, MoS can be regarded as Infomation Information Services (IS), Event
Services (ES), and Command Service (CS).

4. Deployment Scenarios for MoS

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.

The following scenarios are discussed for understanding the overall
problem of transporting MIH protocol. Although these are all
possible scenarios and MIH services can be delivered through link-
layer
link-layer specific solutions and/or through a "layer 3 or above"
protocol, this problem statement focuses on the delivery of
information for mobility services Mobility Services only for the latter case only. case.

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 end-to-end.

+------+ +------+
| MN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
<------------------------------------>

/------------------------------------\
< Transport over IP >
\------------------------------------/

Figure 1: End-to-end 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
other than IP is are 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 protocol, such as RADIUS Remote Authentication Dial-In
User Service (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 Network-to-Network Signalling

In this case case, NN to NN signalling is envisioned. Such a 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 make decisions and instruct mobile terminals of
operation
operations to be executed.

+------+ +------+
| NN | | NN |
| (EP) | | (EP) |
+------+ +------+
Information Exchange
------------------->
<-------------------

/----------------\
< Transport >
\----------------/

Figure 3: Information Exchange between different NN Different NNs

Network nodes exchange information about the status of connected terminals status.
terminals.

5. MoS Transport Protocol Splitting

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).

Figure 4: Handover Services over IP

The Mobility Service Transport Layer provides certain functionality
(outlined in Section 5.2) to the higher layer higher-layer mobility support
services in order to support the exchange of information between
communicating mobility service 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 communication, without regard to the protocol
semantics and data carried in the specific mobility services. Mobility Services.

The Mobility Support Services themselves may also define certain
protocol exchanges to support the exchange of service specific
Information Elements. service-specific
information elements. It is likely that the responsibility for
defining the contents and significance of the Information Elements information elements is
the responsibility of other standards bodies other than the IETF. Example mobility services
Mobility Services include the Information Services, Event Services,
and Command services. Services.

5.1. Payload Formats and Extensibility Considerations

The format of the Mobility Service Transport Protocol (MSTP) is as
follows:

Figure 5: Protocol Structure

This figure shows the case for a an MIH message that is smaller than
the MTU of the path to the destination. A larger payload may require
the transport protocol to transparently fragment and reassemble the
MIH message.

Figure 5: Protocol Structure

The opaque payload encompasses the Mobility Support Service (MSTP)
information that is to be transported. The definition of the
Mobility Service Transport Header is something that is best addressed
within the IETF. MSTP does not inspect the payload payload, and any required
information will be provided by the MSTP users.

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 either discover nodes that
support certain services, services or discover services provided by a
certain node. The service discovery can be dealt with messages using
messsages as defined in [1]. This section refers to node-discovery node-
discovery in either scenario. There are no assumptions about the
location of these
mobility services node Mobility Service nodes within the network, therefore 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 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, via DHCP or 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 node, 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. (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 example, IEEE 802.21
specifies three different type types of Mobility services Services (Information
Services, Command Services Services, and Event Services) that can be
located in different portion portions of the network. A An MN could
therefore run a discovery procedure of any service running in the
(home or visited) network or could run a discovery procedure for a
specific service.

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 requirement should
reuse trust relationships that have already been established in
the network, for example, on the relationships established by the
AAA
Authentication, Authorization, and Accounting (AAA) infrastructure
after a mutual authentication, or on the certificate
infrastructure required to support SEND [10]. Section 7 6 provides
a more complete analysis.

Security association management: A common security association
negotiation method, independent of any specific MSTP user, should
be implemented. implemented between the endpoints of the MSTP. The solution
must also work in the case on of MN mobility.

Secure delivery: The Mobility Service information must be delivered
securely (integrity and confidentiality) between trusted peers,
where the transport may pass though untrusted intermediate nodes
and networks. The Mobility Service information should also be
protected against replay attacks and denial of service denial-of-service attacks.

Low latency: Some of the Mobility Services generate time sensitive 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. (As short-lived. As an example, the
frequency of messages defined in [1] varies according to the MIH
service type. It is expected that Events and Commands messages
arrive at a rate an interval of hundreds of milliseconds in order to
capture quick changes in the environment and/ or and/or process handover
commands. On the other hand, Information service Service messages are
mainly exchanged each time a new network is visited which that may be in
the order of hours or days). days. For reliable delivery, short-
lived 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 requirements, such
as reliable delivery.

Reliability: Reliable delivery for some of the mobility services 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 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 a reliability mechanism (at the MIH level)
to allow communicating endpoints to acknowledge receipt of
information.

2. Assume the underlying transport will provide reliable delivery.
There is no need in this case to provide reliability at the MIH
level.

Guidelines provided in [3] are being considered while writing this
document.

Congestion Control: A Mobility Service may wish to transfer small or
large amounts of data, placing different requirements for
congestion control in the transport. (As As an example, the MIH
message [1] size varies widely from about 30 bytes (for a
broadcast capability discovery request) to around 65000 bytes be normally less than
64 KB, but may be greater than 64KB (for an IS MIH_Get_Information
response primitive). A typical MIH message size for the Events
and Commands services Services service ranges between 50 to 100 bytes). bytes. The
solution should consider different congestion control mechanisms
depending on the amount of data generated by the application (MIH)
as suggested in [3].

Fragmentation and reassembly: ES and CS messages are small in
nature, are sent frequently, and may wish trade reliability in
order to satisfy the tight latency requirements. On the other
hand, IS messages are more resilient in terms of latency
constraints
constraints, and some long IS messages could exceed the MTU of the
path to the destination. Depending on the choice of the transport
protocol
protocol, different fragmentation and reassembly strategies are
required.

Multihoming: For some information services Information Services exchanged with the MN,
there is a possibility that the request and response messages can
could be carried over two different links e.g. links. For example, a
handover command request is on the current link while the response
could be delivered on the new link. It is expected that the
transport protocol is capable of receiving information via
multiple links
and links. It is also expected that the MSTP user to combine combines
information belonging to the same session/transaction. When
mobility is applied applied, the undelaying IP mobility mechanism should
provide session continuty continuity when required.

IPv4 and IPv6 support: The MSTP must support both IPv4 and IPv6
including NAT traversal for IPv4 networks and firewall pass-
through
pass-through for IPv4 and IPv6 networks.

6. IANA Considerations

This document makes no request of IANA.

7. Security Considerations

Network supported mobility services

Network-supported Mobility Services aim at improving decision making
and management of dynamically connected hosts.

Information Services may not require authorization of the client, but
both event Event and command services Command Services may authenticate message sources,
particularly if they are mobile. Network side 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, spoofing, and replay attacks (see
(Section 10)). attacks.

Sensitive and identifying information about a mobile device may be
exchanged during handover service handover-service message exchange. Since handover
decisions are to be made based upon message exchanges, it may be
possible to trace an a user's movement between cells, or predict future
movements, by inspecting handover service messages. In order to
prevent such tracking, message confidentiality and message integrity
should be available. This is particularly important since because many
mobile devices are associated with only one user, since divulging 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 available, if
possible, when establishing SAs. source addresses (SAs).

In addition, the user should not have to disclose its identity to the
network (any more (anymore 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
"example.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 NNs themselves will potentially be subject to
denial of service
denial-of-service attacks from MNs MNs, and these problems will be
exacerbated if operation of the mobility service Mobility Service protocols imposes a
heavy computational load on the NNs. The overall design has to
consider at what stage (e.g. (e.g., discovery, transport layer
establishment, service specific and service-specific protocol exchange) denial of denial-of-
service prevention or mitigation should be built in.

7. Conclusions

This Internet draft document outlined a broad problem statement for the signalling
of information elements across a network to support
mobility services. Mobility
Services. In order to enable this type of signalling service, a need
for a generic transport solution with certain transport and security
properties were was 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. Mobility Services.

It would be valuable to establish realistic performance goals for the
solution to this common problem (i.e. (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 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.

9. Acknowledgements

Thanks to Subir Das, Juan Carlos Zuniga, Robert Hancock and Yoshihiro
Ohba for their inputs. Thanks to the IEEE 802.21 chair Vivek Gupta
for coordinating the work and supporting the IETF liaison. Thanks to
all IEEE 802.21 WG folks who indirectly contributed to this document.

10. Appendix

The following list of requirements is an informative section of the
IEEE 802.21 draft standard [1] "Requirements to support 802.21 by L3
and above transport".

10.1. General requirements

The following set of requirements is applicable generically to any L3
or above transport protocol:

o GR1.The transport mechanism shall provide means for communications
between a sending MIH Protocol Entity and a receiving MIH Protocol
Entity regardless of their network location, e.g., on the same
subnet, or deep in the network belonging to the same or a
different network administrative domain.

o GR2.The transport mechanism shall be capable of delivering time-
sensitive information.

o GR3.The transport mechanism shall allow the use of effective
security for MIH Protocol exchanges, including:

* mutual authentication between the communicating nodes;

* message authentication;
* message integrity;

* message confidentiality

o GR4.The transport mechanism framework shall allow the use of
discovery protocols as part of the L3 and above solution.

10.2. IETF transport protocol requirements

The following set of requirements is applicable specifically to IETF
transport protocol:

o TR1.The transport protocol shall 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 TR2.The transport protocol shall be capable to support both IPv4
and IPv6 versions.

o TR3.The transport protocol shall be capable of delivering time-
sensitive MIH information.

o TR4.The transport protocol shall enable Network address
Translation (NAT) traversal for IPv4 networks.

o TR5.The transport protocol shall enable firewall pass-through for
IPv4 and IPv6 networks.

10.3. IETF discovery whether new protocol requirements

The following set of requirements development is applicable specifically to IETF
discovery protocol:

o DR1.The discovery protocol shall work regardless of required. In either
case, we believe that the network
location appropriate skills for development of the MIH Protocol Entity e.g. on the same subnet, or
deep
protocols in this area lie in the network belonging IETF.

8. Acknowledgements

Thanks to same or different IP
administrative domain.

o DR2.The discovery protocol shall work for IPv4 Subir Das, Juan Carlos Zuniga, Robert Hancock, and IPv6 hosts.

o DR3.The discovery protocol shall allow
Yoshihiro Ohba for more than one MIH
Protocol Entity their input. Thanks to be discovered at a time.

o DR4.The discovery protocol shall enable Network Address Translator
(NAT) traversal for IPv4 networks.

o DR5.The discovery protocol shall enable Firewall pass-through for
IPv4 and IPv6 networks.

10.4. IETF security requirements

o SR1.The security mechanism shall 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 SR2.The security mechanism shall provide mutual authentication of
MIH end nodes.

o SR3.The security mechanism may provide one way authentication of
either of MIH end nodes.

o SR4.The security mechanism shall provide integrity protection for
MIH Protocol exchanges.

o SR5.The security mechanism may provide confidentiality IEEE 802.21 chair,
Vivek Gupta, for coordinating the MIH
Protocol exchanges.

o SR6.The security mechanism shall protect against replay attacks.

o SR7.The security mechanism may protect MIH service entities work and
discovery resources against denial of service attacks.

o SR8.The security mechanism shall not be dependent on supporting the MIH
protocol.

o SR9.The security mechanism may provide means IETF
liaison. Thanks to reuse or fast
reestablishment the SA due all IEEE 802.21 WG folks who contributed to host mobility.

11. this
document indirectly.

9. References

11.1.

9.1. Normative References

[1] "Draft IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE LAN/MAN Draft IEEE
P802.21/D07.00, July 2007.

[2] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 2007.

11.2. 1997.

9.2. Informative References

[3] Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
Application Designers", draft-ietf-tsvwg-udp-guidelines-03
(work Work in progress), September 2007. Progress.

[4] 3GPP, "3GPP system architecture evolution (SAE): Report on
technical options and conclusions", 3GPP TR 23.882 0.10.1,
February 2006.

[5] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.

[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.

[7] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
Architecture", RFC 4423, May 2006.

[8] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.

[9] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.

[10] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.

Authors'

Contributors' 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:

EMail: eleanor.hepworth@roke.co.uk

Srivinas Sreemanthula
Nokia Research Center
6000 Connection Dr.
Irving, TX 75028
USA

Email:

EMail: srinivas.sreemanthula@nokia.com

Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway NJ 08854
USA

Email:

EMail: yohba@tari.toshiba.com

Vivek Gupta
Intel Corporation
2111 NE 25th Avenue
Hillsboro, OR 97124
USA

Phone: +1 503 712 1754
Email:
EMail: vivek.g.gupta@intel.com
Jouni Korhonen
TeliaSonera Corporation.
P.O.Box 970
FIN-00051 Sonera
FINLAND

Phone: +358 40 534 4455
Email:
EMail: jouni.korhonen@teliasonera.com

Rui L.A. Aguiar
Instituto de Telecomunicacoes Universidade de Aveiro
Aveiro 3810
Portugal

Phone: +351 234 377900
Email:
EMail: ruilaa@det.ua.pt

Sam(Zhongqi) Xia
Huawei Technologies Co.,Ltd Co., Ltd
HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base
100085
Hai-Dian District Beijing, P.R. China

Phone: +86-10-82836136
Email:
EMail: xiazhongqi@huawei.com

Authors' Addresses

Telemaco Melia, Editor
NEC Europe Network Laboratories
Kufuerstenanlage 36
Heidelberg 69115
Germany

Phone: +49 6221 90511 42
EMail: telemaco.melia@gmail.com

Full Copyright Statement

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, THE IETF TRUST 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).