RE: [MIPSHOP-MIH-DT] PS doc -- 01 version

tele,

we have some minor comments. i can't formalise them right now but will try
to send something over the weekend.

r.

  _____  

From: Sam Xia [mailto:xiazhongqi@huawei.com] 
Sent: 27 April 2007 14:19
To: 'Telemaco Melia'
Cc: mipshop-mih-dt@ietf.org
Subject: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version

hi, tele,
 i have 3 comments as follows:

1: there is typos error in the paragraph about discovery requirement.
"dscovery" is duplicated.

2: i think that the list of requirements is not arranged in order. for
example, we should put transportation requirements togeter, security
requirements together, discovery requriement togethter, just as .21 does.

3: 
 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.

i think how to deliver the mobility service information is determined by the
MIH user. the MSTP must provide security mechanism to protect service
information. but this does not mean that the mobility service information
must be delivered securely.

 Best Regards, Sam Xia 

  _____  

From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de] 
Sent: Friday, April 27, 2007 3:13 PM
To: mipshop-mih-dt@ietf.org
Subject: Re: [MIPSHOP-MIH-DT] PS doc -- 01 version

Hi folks,

Sorry to insist but we need to push this forward.
Can we get consensus soon (today?) about the introduced changes, especially
section 5.2?

telemaco

Telemaco Melia wrote: 

Hi all, 

Please find attached a revised version of the PS document. Comments from
people should be hopefully  reflected. 
I told Stefano that a final version for submission will be ready by Friday,
so please send comments with proposed text to avoid lengthly discussions. 
Please pay particular attention to section 5.2 (see Yoshi's email). Also the
title of the doc is changed according to Alper's comment (it is in line with
the terminology agreed in Prague). 

cheers, 
telemaco 

  _____  

MIPSHOP                                                         T. Melia

Internet-Draft                                                       NEC

Intended status: Informational                               E. Hepworth

Expires: October 27, 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

                                                          April 25, 2007

             Mobility Services Transport: Problem Statement

                      draft-ietf-mipshop-mis-ps-01

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 October 27, 2007.

Copyright Notice

Melia, et al.           Expires October 27, 2007                [Page 1]

Internet-Draft         Mobility Services Transport            April 2007

   Copyright (C) The IETF Trust (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 October 27, 2007                [Page 2]

Internet-Draft         Mobility Services Transport            April 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Definition of Mobility Services  . . . . . . . . . . . . . . .  5

   4.  Deployment Scenarios for MoS . . . . . . . . . . . . . . . . .  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 . . . . . . . . .  7

   5.  MoS Transport Protocol Splitting . . . . . . . . . . . . . . .  8

     5.1.  Payload Formats and Extensibility Considerations . . . . .  9

     5.2.  Requirements on the Mobility Service Transport Layer . . .  9

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

   7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 15

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Melia, et al.           Expires October 27, 2007                [Page 3]

Internet-Draft         Mobility Services Transport            April 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.

   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 October 27, 2007                [Page 4]

Internet-Draft         Mobility Services Transport            April 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.

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 (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 Services (MoS) having in common different requirements for

   the transport protocol.  These requirements and associated

   functionalities are the focus of this document

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

Melia, et al.           Expires October 27, 2007                [Page 5]

Internet-Draft         Mobility Services Transport            April 2007

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.

           +------+           +------+           +------+

           |  MN  |           |  NN  |           |  NN  |

           |      |           | (EP) |           | (EP) |

           +------+           +------+           +------+

                        Information Exchange

               <------------------------------------>

                (Transport over  /------------------\

               <--------------->< Transport over IP  >

                    e.g. L2)     \------------------/

                        Figure 2: Partial Transport

Melia, et al.           Expires October 27, 2007                [Page 6]

Internet-Draft         Mobility Services Transport            April 2007

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 might process all layers of the protocol suite in the

   same way as an ordinary EP.

   There is a possibility for realizing other proxy scenarios.

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.

Melia, et al.           Expires October 27, 2007                [Page 7]

Internet-Draft         Mobility Services Transport            April 2007

                 +------+          +------+

                 |  NN  |          |  NN  |

                 | (EP) |          | (EP) |

                 +------+          +------+

                    Information Exchange

                    ------------------->

                    <-------------------

                    /----------------\

                   <    Transport     >

                    \----------------/

            Figure 4: Information Exchange between different NN

   Network nodes exchange information about connected terminals status.

5.  MoS Transport Protocol Splitting

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

                          +----------------+          ^

                          |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

Melia, et al.           Expires October 27, 2007                [Page 8]

Internet-Draft         Mobility Services Transport            April 2007

   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

   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.  MSTP does not inspect the 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:  Discovery: MNs need the ability to either discover nodes

      that support certain services, or discover services provided by a

      certain node.  The service discovery can be dealt with messages as

      defined in [1].  This section refers to node-discovery in either

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

Melia, et al.           Expires October 27, 2007                [Page 9]

Internet-Draft         Mobility Services Transport            April 2007

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

   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 infrastructure after a mutual authentication, or on the

      certificate infrastructure required to support SEND [9].  The

      security mechanism must provide mutual authentication of MN and NN

      and it may provide one way authentication of either of MN and NN.

   Security association management:  A common security association

      negotiation method, independent of any specific MSTP user, must be

      implemented.  The solution must also work in case on MN mobility.

Melia, et al.           Expires October 27, 2007               [Page 10]

Internet-Draft         Mobility Services Transport            April 2007

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

   Congestion Control:  A Mobility Service may optionally 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 (integrity and confidentiality) between trusted peers,

      where the transport may pass though untrusted intermediate nodes

      and networks.  The Mobility Service information must also be

      protected against replay attacks and denial of service attacks.

Melia, et al.           Expires October 27, 2007               [Page 11]

Internet-Draft         Mobility Services Transport            April 2007

   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.

   IPv4 and IPv6 support:  The MSTP must support both IPv4 and IPv6

      including NAT traversal for IPv4 networks and firewall pass-

      through for IPv4 and IPv6 networks.

   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

   information exchanges into a single transport exchange (see figure

   Figure 7) .

Melia, et al.           Expires October 27, 2007               [Page 12]

Internet-Draft         Mobility Services Transport            April 2007

+==================================+

|                                  |

| +------------+  +-----------+    |

| |    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 October 27, 2007               [Page 13]

Internet-Draft         Mobility Services Transport            April 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 October 27, 2007               [Page 14]

Internet-Draft         Mobility Services Transport            April 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/D05.00, April 2007.

   [2]  Aboba, B., "Architectural Implications of Link Indications",

        draft-iab-link-indications-10 (work in progress), March 2007.

   [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 October 27, 2007               [Page 15]

Internet-Draft         Mobility Services Transport            April 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 October 27, 2007               [Page 16]

Internet-Draft         Mobility Services Transport            April 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 October 27, 2007               [Page 17]

Internet-Draft         Mobility Services Transport            April 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (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, 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).

Melia, et al.           Expires October 27, 2007               [Page 18]

  _____  

_______________________________________________

MIPSHOP-MIH-DT mailing list

MIPSHOP-MIH-DT@ietf.org

https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

-- 

Dr. Telemaco Melia			telemaco.melia@netlab.nec.de

Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142

NEC Europe Ltd.				Fax: +49 (0) 6221 4342- 155

Network Laboratories			Web: http://www.netlab.nec.de

Kurfuersten-Anlage 36			       

69115 Heidelberg

GERMANY   

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London
W3 6BL | Registered in England 2832014 