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

From: Telemaco Melia <[email-masked]>
Date: Wed, 25 Apr 2007 18:43:57 +0200

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: [email-masked]

   Eleanor Hepworth
   Siemens Roke Manor Research
   Roke Manor
   Romsey,   SO51 5RE
   UK

   Email: [email-masked]

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

   Email: [email-masked]

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: [email-masked]

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

   Phone: +1 503 712 1754
   Email: [email-masked]

   Jouni Korhonen
   TeliaSonera Corporation.
   P.O.Box 970
   FIN-00051 Sonera
   FINLAND

   Phone: +358 40 534 4455
   Email: [email-masked]

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

   Phone: +351 234 377900
   Email: [email-masked]

   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: [email-masked]

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
   [email-masked].

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Telemaco Melia <[email-masked]>
Date: Fri, 27 Apr 2007 09:13:13 +0200

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

-- 
Dr. Telemaco Melia			[email-masked]
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

---

From: Sam Xia <[email-masked]>
Date: Fri, 27 Apr 2007 21:19:11 +0800

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: 
      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:[email-masked]] 
Sent: Friday, April 27, 2007 3:13 PM
To: [email-masked]
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

                                                         S. Sreemanthula

                                                   Nokia Research Center

                                                                 Y. Ohba

                                                                 Toshiba

                                                                G. Vivek

                                                                   Intel

                                                             J. Korhonen

                                                             TeliaSonera

                                                               R. Aguiar

                                                                      IT

                                                       Sam(Zhongqi). Xia

                                                                  HUAWEI

                                                          April 25, 2007

Status of this Memo

   Drafts.

Copyright Notice



Abstract



Table of Contents



1.  Introduction

       structure.

   IEEE 802.21.

2.  Terminology



   o  MN: mobile node

      reside anywhere).

      between nodes.



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

           |  MN  |                              |  NN  |

           | (EP) |                              | (EP) |

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

                        Information Exchange

              <          Transport over IP           >

   Server.

           |  MN  |           |  NN  |           |  NN  |

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

                        Information Exchange



                       Information Exchange

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

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

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

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



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

                 |  NN  |          |  NN  |

                 | (EP) |          | (EP) |

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

                    Information Exchange

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

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

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

                   <    Transport     >

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

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

                          |Mobility Support|          |

                          |   Service 2    |          |

       |                |    |Mobility Support|       |

                             |                |       |

                             +----------------+       V

        |                   IP                  |



   Command services.



         attached.

         solution.



          information.

          transport layer).



   Figure 7) .



|                                  |

| |    MIH     |  |   MIH     |    |

|      \                /          |   \__ :    MIH     :

|     |   MIH Function    |        |

|     |    (e.g. MIS)     |        |

|               /\                 |

|               ||                 |          ..............

|               ||                 |          : Transport  :

|               \/                 |          :Multiplexing:

|               /\                 |                            |.........|

|               ||                 |                       _____|   IP    |

|               ||                 |                      /     +=========+

|               ||                 |                     /

|                                  |                   |     \__|   IP    |

                                                       |             :

                                                       |             :

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

                                                       |        |   MIH   |

                                                       |        |.........|

                                                       |        |Transport|

                                                       |        |.........|

                                                       |________|   IP    |

                                                                +=========+



   for handover services.

   establishing SAs.



7.  Conclusions

8.  References

        August 2002.



        RFC 4555, June 2006.

        February 2006.

        July 2005.

Authors' Addresses

   Telemaco Melia

   Kufuerstenanlage 36

   Heidelberg  69115

   Germany

   Phone: +49 6221 90511 42

   Eleanor Hepworth

   Roke Manor

   Romsey,   SO51 5RE

   UK

   Srivinas Sreemanthula

   Nokia Research Center

   6000 Connection Dr.

   Irving,   TX 75028

   USA



   Yoshihiro Ohba

   1 Telcordia Drive

   Piscateway  NJ 08854

   USA

   Vivek Gupta

   Intel Corporation

   2111 NE 25th Avenue

   Hillsboro, OR  97124

   USA

   Phone: +1 503 712 1754

   Jouni Korhonen

   TeliaSonera Corporation.

   P.O.Box 970

   FIN-00051 Sonera

   FINLAND

   Phone: +358 40 534 4455

   Rui L.A. Aguiar

   Aveiro  3810

   Portugal

   Phone: +351 234 377900

   Email: [email-masked]

   Sam(Zhongqi) Xia

   HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base,Hai-Dian
District Beijing

   100085

   P.R. China

   Phone: +86-10-82836136



Full Copyright Statement

   retain all their rights.

Intellectual Property

   http://www.ietf.org/ipr.

   [email-masked].

Acknowledgment



  _____  

[email-masked]

-- 

Kurfuersten-Anlage 36			       

69115 Heidelberg

GERMANY   

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

---

From: "Robert Hancock" <[email-masked]>
Date: Fri, 27 Apr 2007 16:31:36 +0100

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:[email-masked]] 
Sent: 27 April 2007 14:19
To: 'Telemaco Melia'
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version

hi, tele,

 
3: 

 Best Regards, Sam Xia 

  _____  

Hi folks,

telemaco

Telemaco Melia wrote: 

Hi all, 

cheers, 
telemaco 

  _____  

MIPSHOP                                                         T. Melia

Internet-Draft                                                       NEC

                                                         S. Sreemanthula

                                                   Nokia Research Center

                                                                 Y. Ohba

                                                                 Toshiba

                                                                G. Vivek

                                                                   Intel

                                                             J. Korhonen

                                                             TeliaSonera

                                                               R. Aguiar

                                                                      IT

                                                       Sam(Zhongqi). Xia

                                                                  HUAWEI

                                                          April 25, 2007

Status of this Memo

   Drafts.

Copyright Notice



Abstract



Table of Contents



1.  Introduction

       structure.

   IEEE 802.21.

2.  Terminology



   o  MN: mobile node

      reside anywhere).

      between nodes.



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

           |  MN  |                              |  NN  |

           | (EP) |                              | (EP) |

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

                        Information Exchange

              <          Transport over IP           >

   Server.

           |  MN  |           |  NN  |           |  NN  |

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

                        Information Exchange



                       Information Exchange

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

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

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

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



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

                 |  NN  |          |  NN  |

                 | (EP) |          | (EP) |

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

                    Information Exchange

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

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

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

                   <    Transport     >

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

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

                          |Mobility Support|          |

                          |   Service 2    |          |

       |                |    |Mobility Support|       |

                             |                |       |

                             +----------------+       V

        |                   IP                  |



   Command services.



         attached.

         solution.



          information.

          transport layer).



   Figure 7) .



|                                  |

| |    MIH     |  |   MIH     |    |

|      \                /          |   \__ :    MIH     :

|     |   MIH Function    |        |

|     |    (e.g. MIS)     |        |

|               /\                 |

|               ||                 |          ..............

|               ||                 |          : Transport  :

|               \/                 |          :Multiplexing:

|               /\                 |                            |.........|

|               ||                 |                       _____|   IP    |

|               ||                 |                      /     +=========+

|               ||                 |                     /

|                                  |                   |     \__|   IP    |

                                                       |             :

                                                       |             :

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

                                                       |        |   MIH   |

                                                       |        |.........|

                                                       |        |Transport|

                                                       |        |.........|

                                                       |________|   IP    |

                                                                +=========+



   for handover services.

   establishing SAs.



7.  Conclusions

8.  References

        August 2002.



        RFC 4555, June 2006.

        February 2006.

        July 2005.

Authors' Addresses

   Telemaco Melia

   Kufuerstenanlage 36

   Heidelberg  69115

   Germany

   Phone: +49 6221 90511 42

   Eleanor Hepworth

   Roke Manor

   Romsey,   SO51 5RE

   UK

   Srivinas Sreemanthula

   Nokia Research Center

   6000 Connection Dr.

   Irving,   TX 75028

   USA



   Yoshihiro Ohba

   1 Telcordia Drive

   Piscateway  NJ 08854

   USA

   Vivek Gupta

   Intel Corporation

   2111 NE 25th Avenue

   Hillsboro, OR  97124

   USA

   Phone: +1 503 712 1754

   Jouni Korhonen

   TeliaSonera Corporation.

   P.O.Box 970

   FIN-00051 Sonera

   FINLAND

   Phone: +358 40 534 4455

   Rui L.A. Aguiar

   Aveiro  3810

   Portugal

   Phone: +351 234 377900

   Email: [email-masked]

   Sam(Zhongqi) Xia

   100085

   P.R. China

   Phone: +86-10-82836136



Full Copyright Statement

   retain all their rights.

Intellectual Property

   http://www.ietf.org/ipr.

   [email-masked].

Acknowledgment



  _____  

[email-masked]

-- 

Kurfuersten-Anlage 36			       

69115 Heidelberg

GERMANY

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 27 Apr 2007 13:29:06 -0400

Hello,

Thanks for the good work Tele. 

The only question that I have is if we could relax the security
requirements from "must" to "could or may". 

In 802.21 there are talks about carrying out some security tasks in the
future, so I think that is best if we do not reinforce it here, in case
that the function is carried out elsewhere (i.e. in the MIH itself).

This is how it reads now:

In 5.2:

      The security mechanism must provide mutual authentication of MN
and NN
      and it may provide one way authentication of either of MN and NN.

In 6:

   particularly if they are mobile.  

Anyone else from 21 would like to comment on this?

Besides that, it looks fine to me.

Regards,

Jc

________________________________

From: Robert Hancock [mailto:[email-masked]] 
Sent: April 27, 2007 11:32 AM
To: 'Sam Xia'; 'Telemaco Melia'
Cc: [email-masked]
Subject: 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.

________________________________

	hi, tele,

	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:[email-masked]] 
		Sent: Friday, April 27, 2007 3:13 PM
		To: [email-masked]
		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.

		Copyright Notice

		Melia, et al.           Expires October 27, 2007
[Page 1]
		 
		Internet-Draft         Mobility Services Transport
April 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

		 

		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.

		   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

		   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

		   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

		               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

		 

		Melia, et al.           Expires October 27, 2007
[Page 6]
		 
		Internet-Draft         Mobility Services Transport
April 2007

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

		   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.

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

		   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.

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

+----------------+----------------------------------------+
		   |Mobility Service|           Opaque Payload
|
		   |Transport Header|     (Mobility Support Service)
|

		 
		   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    |
	
+=========+

		 

		Melia, et al.           Expires October 27, 2007
[Page 13]
		 
		Internet-Draft         Mobility Services Transport
April 2007

		   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
		 
		   Phone: +49 6221 90511 42

		   Eleanor Hepworth

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

		 

		 
		Melia, et al.           Expires October 27, 2007
[Page 16]
		 
		Internet-Draft         Mobility Services Transport
April 2007

		   Yoshihiro Ohba

		   Vivek Gupta
		   Intel Corporation
		   2111 NE 25th Avenue
		   Hillsboro, OR  97124
		   USA
		 
		   Phone: +1 503 712 1754

		   Jouni Korhonen
		   TeliaSonera Corporation.
		   P.O.Box 970
		   FIN-00051 Sonera
		   FINLAND
		 
		   Phone: +358 40 534 4455

		   Rui L.A. Aguiar
		 
		   Phone: +351 234 377900
		   Email: [email-masked]

		   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

		Melia, et al.           Expires October 27, 2007
[Page 17]
		 
		Internet-Draft         Mobility Services Transport
April 2007

		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
		   [email-masked].

		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]

		
________________________________

		

		-- 
		Dr. Telemaco Melia
[email-masked]
		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

---

From: Subir Das <[email-masked]>
Date: Mon, 30 Apr 2007 11:47:08 -0400

Tele,
Sorry for the delay. Hope it is not too late.
Inserted below with a few comments/suggestions.
Search by my name.

thanks,
-Subir

>> is in line with the terminology agreed in Prague).
       Subir>comment; I  would  say more than just access network above. 
                   Suggestion: Either we delete "(access)" or add 
"(access or core)"
>>    Mobility Services (MoS) having in common different requirements for
           Subir> Comment: Do we need both "common" and "different" above?
>>    information for MIH services for the latter case only. 
         Subir>Suggestion: I would say "the delivery of information for 
mobility services"
                   instead of "delivery of information for MIH services"
>>    between MN and NN.  The underlying transport is also end-to-end
             Subir> editorial: add (MSTP)  after Mobility Support Service
>>       certain node.  
          Subir> comment: why not  both node and service discovery? I 
understand the service discovery is
                     not our scope but the first statement is generic.
>> The service discovery can be dealt with messages as
>>       mobility services within the network, 
          Subir> editorial: may add "node" after mobility services above...
>> therefore the discovery
         Subir> Comment: In general the following approaches fall into 
solution category. Do we need
                     them in the problem statement document? May be I 
made this comment earlier. However,
                     if the group feels that it will improve the 
clarity, I am fine.
>>       network information" services.
         Subir> editorial: (for example, should the MN look for an "IS" 
service, or "IS-local information", and "IS-home
      network information" services?)

>>       and it may provide one way authentication of either of MN and NN.
             Subir> The last part of the above sentence is not clear to 
me. Are we saying either  mutual 
                         or one way authentication?
>>       implemented.  
             Subir>comment: I am not sure whether we can say "must  be  
implemented"?  In some cases, 
                       security association may be needed.
                       suggestion: should is better. Or else, we should 
say if  SAs are required, it should use the
                       common one...
>> The solution must also work in case on MN mobility.
>>
>>
>>
>>
            Subir> comment: 'must' have is too strong here. I am not 
sure how easy it will be to prevent
                       DoS?
                       Suggestion: 'Should'
>> Internet-Draft         Mobility Services Transport            April 2007
            Subir> comment: How do we conclude the above?  The 
authorization part is not clear to me. Also
                       having message authentication is a good idea but 
I am not sure if we need to say
                       'must' if they are mobile.
                        suggestion; 'Should' is better.
>> Network side service entities will
>>    independent handover services.  
           Subir> editorial; may change above to "mobility services" 
instead of MIH services...
>> In order to enable this type of

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 30 Apr 2007 18:06:57 +0200

Hi all,

As far as I know only Robert is missing. Tomorrow in Germany is bank 
holiday.
I ll be back in the office on Wednesday and I ll compile the final version.

cheers
Tele

Subir Das wrote:
>>> 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
>>>                                                          S. 
>>> Sreemanthula
>>>                                                    Nokia Research 
>>> Center
>>>                                                                  Y. 
>>> Ohba
>>>                                                                 G. 
>>> Vivek
>>>                                                              J. 
>>> Korhonen
>>>                                                                R. 
>>> Aguiar
>>>                                                        Sam(Zhongqi). 
>>> Xia
>>>                                                           April 25, 
>>> 2007
>       Subir>comment; I  would  say more than just access network 
> above.                   Suggestion: Either we delete "(access)" or 
> add "(access or core)"
> me. Are we saying either  mutual                         or one way 
> authentication?
> implemented"?  In some cases,                       security 
> association may be needed.
>>> |               ||                 |                       _____|   
>>> IP    |
>>> |                                  |                   |     \__|   
>>> IP    |
>>> MIH   |
>>>                                                        |________|   
>>> IP    |
>> Kurfuersten-Anlage 36                   69115 Heidelberg
>> GERMANY  
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
>> London W3 6BL | Registered in England 2832014