Subject: [MIPSHOP-MIH-DT] Version Thu 13th

From: Telemaco Melia <[email-masked]>
Date: Thu, 13 Sep 2007 11:00:26 +0200

Guys,

According to our action points from the AC only section 7 is missing.
Please Subir send it to me as soon as possible, so I can integrate.
We still need to address Sam's concern about mobility.
References and contacts will be updated later.
Also I'd like to acknowledge Patrick for the long discussions we had 
here.Anybody else from your side?

Let me know
Tele

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC
Intended status: Standards Track                                  S. Xia
Expires: January 25, 2008                                         Huawei
                                                               N. Golmie
                                                                    NIST
                                                                  S. Das
                                                               Telcordia
                                                                G. Bajko
                                                                   Nokia
                                                              JC. Zuniga
                                                            InterDigital
                                                           July 24, 2007

              Mobility Services Transport Protocol Design
                   draft-xxx-mipshop-mstp-solution-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

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

   This Internet-Draft will expire on January 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Melia, et al.           Expires January 25, 2008                [Page 1]

Internet-Draft                    MSTP                         July 2007

Abstract

   To be edited.

Requirements Language

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  4
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . .  7
   5.  MoS Discovery  . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  MoS Discovery in the home network while attached to
           the home link  . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  MoS Discovery in the local network and Services are
           local  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  MOS Discovery in a roaming Network and Services are at
           Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  MoS discovery in a remote network  . . . . . . . . . . . . 11
   6.  MIH Transport  . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  MIH Message size . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  MIH Message rate . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . . 13
     6.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 14
     6.5.  General guidelines . . . . . . . . . . . . . . . . . . . . 14
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     11.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

Melia, et al.           Expires January 25, 2008                [Page 2]

Internet-Draft                    MSTP                         July 2007

1.  Introduction

   This document proposes a solution to the issues indetified in the
   problem statement document [I-D.ietf-mipshop-mis-ps] for the
   transport of IEEE 802.21 MIH protocols.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of mobility services (MoS) and the transport of the
   information between MN and MoS.  The discovery process is required
   for MIH function located in the MN to discover the peer MIHF (e.g.
   the IP address) of the MoS in the network (e.g. the Point of Service,
   PoS) either during attachment or during handover.  Upon succesfull
   discovery, the MIH peers can then exchange information in the form of
   MIH messages.

   This document considers firstly standard track IETF-based solutions
   for the design and recommendations of the discovery and transport
   protocol components.

2.  Terminology

   The following terminology is being used:

   MIH  Media Independent Handover

   MIHF  Media Independent Handover Function

   MIHF USER  MIH client initiating and terminating MIH signalling

   MIHFID  Media Independent Handover Function Identifier

   MoS  As defined in the problem statement documetn it includes IS, CS,
      ES services defined by the IEEE 802.21 standard.

   MoSh  Mobility Services assigned in the Home Network

   MoSv  Mobility Services assigned in the Visited Network

   MoS3  Mobility Services assigned in a 3rd Party Network

   MN Mobile Node

   NN Network Node

Melia, et al.           Expires January 25, 2008                [Page 3]

Internet-Draft                    MSTP                         July 2007

3.  Deployment Scenarios

   The following scenarios have been identified:

   S1 Home Network MoS, the MN and the services are located in the home
      network.  We refer to this as MoSh as in Figure 1.

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

                      Figure 1: MoS in the Home network

   S2 Visisted Network MoS, MN is in the visited network and mobility
      services are also provided by the visited network.  We refer to
      this as MoSv ans in Figure 2.

             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/
    +====+ +-----------------+
    |MoSv| | VISITED NETWORK |
    +====+ +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

                    Figure 2: MoSV in the Visited Network

   S3 Roaming MoS, MN is in the visited network and all services are
      provided by the home network.

Melia, et al.           Expires January 25, 2008                [Page 4]

Internet-Draft                    MSTP                         July 2007

    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

             Figure 3: MoS provided by the home while in visited

   S4 Third party MoS, MN is in home or visited network and services are
      provided by a 3rd party network.  We refer to this as MoS3
      Figure 4

                                      +--------------+
                                      | HOME NETWORK |
   +====+    +--------------+         +--------------+
   |MoS3|    | THIRD PARTY  |  <===>        /\
   +====+    +--------------+               ||
                                            \/
                                    +-----------------+
                                    | VISITED NETWORK |
                                    +-----------------+
                                            /\
                                            ||
                                            \/
                                        +--------+
                                        |   MN   |
                                        +--------+

                       Figure 4: MoS form a third party

   MoS can be provided independently and there is no strict relationship
   between ES, CS and IS.  However, while IS contain more a static sort
   of information, ES and CS are services of a dynamic nature and
   sometimes some relationships between them could be expected, e.g. a
   handover command could be issued upon reception of a link event.
   Hence, while in theory services can be implemented in different
   locations, it is expected that ES and CS will be collocated, whereas
   IS can either be collocated with ES/CS or not.  Therefore, having the

Melia, et al.           Expires January 25, 2008                [Page 5]

Internet-Draft                    MSTP                         July 2007

   flexibility at the MSTP to discover different services in different
   locations is an important feature

4.  Solution Overview

   As mentioned in section Section 1 the solution space is being divided
   in discovery and transport.  The follwoing assumptions have been
   made:

   o  The solution is aimed at supporting 802.21 MIH services, namely
      Information Services (IS), Event Services (ES), and Command
      Services (CS).

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.  The recommentdation to the IEEE
      802.21 WG is to restrict to only these two.

   o  The solutions are choosen to cover all possible deployment
      scenarios as described in section Section 3.

   o  MIHF discovery can be performed during initial network attachment
      or thereafeter.

   For the discovering the location of an MoS, the MN could either be
   pre-configured with the address of the MoS, or this address could be
   dynamilcally assigned through DHCP or DNS by the network.  The
   dynamic assignation methods are described in section Section 5.

   The configuration of the MoS could be executed either upon network
   attachment or after succesfull IP configuration.  The methodology to
   be used depends on the considered deployment scenario.

   Once the MIHF peer has been discovered, MIH information can be
   exchanged between peers over UDP and TCP.  The usage of these
   protocols is described in section Section 6.

4.1.  Architecture

   The following Figure 5 depicts the MSTP reference model and its
   components within a node.

Melia, et al.           Expires January 25, 2008                [Page 6]

Internet-Draft                    MSTP                         July 2007

    +--------------------------+
    |       MIHF USER          |
    +--------------------------+
                 ||
    +--------------------------+
    |           MIHF           |
    +--------------------------+
        ||         ||       ||
    +---------+ +------+ +-----+
    | TCP/UDP | | DHCP | | DNS |
    +---------+ +------+ +-----+

                            Figure 5: MN stack

   As it can be seen, the MIHF relies on the services provided by TCP
   and UDP for transport, as well as DHCP and DNS for peer discovery.
   In cases where peer MIHF IP address is not preconfigured, source MIHF
   needs to discover it either via DHCP or DNS or using a combination of
   both as described in Section 5.  Once peer MIHF is discovered, MIHF
   must exchange messages with its peer over either UDP or TCP.
   Specific recommendations on choice of transport protocols are
   provided in section Section 6.

   The above reference architecture however does not provide the model
   for other services such as, fragmentation and security.  Depending
   upon the MIH services (e.g., ES, CS and IS) the message size can be
   very large.  In cases where underlying layer does not support
   fragmentation, this may be an issue.  There is no security available
   currently at the MIH protcol level.  However, security can be
   provided either at the transport or IP layer where it is necessary.
   Section Section 8 provides some guidelines and recommedations for
   security.

4.2.  MIHF Identifiers (FQDN, NAI)

   An MIHFID is an identifier required to uniquely identify the MIHF end
   points for delivering the mobility services (MoS).  Thus an MIHF
   identifier needs to be unique within a domain whereby mobility
   services are provided and invariant to interface IP addresses.  An
   MIHFID MUST be represented either in the form of an FQDN [RFC2181] or
   NAI [RFC2486].  An MIHFID can be pre-configured or discovered through
   the discovery methods as described in Section Section 5.

5.  MoS Discovery

   The MoS discovery method depends on whether the MN wants to discover
   an MoS in the local network, home network or a remote network other

Melia, et al.           Expires January 25, 2008                [Page 7]

Internet-Draft                    MSTP                         July 2007

   than home network.

   In case MoS assignment is provided locally (S1 and S2)
   [draft-gabor-dhcp] and [draft-gabor-dns] could be used to transfer
   MoS information from the network to the MN (via DHCP or DNS).  In
   case MoS assignment is provided in the home while the MN is attached
   in visited (S3) an interaction between the DHCP and AAA
   infrastructure is required similarly to what specified in
   [draft-bootstrapping-integrated].  It is assumed therefore that MoS
   assignment is performed during access authentication and
   authorization.

5.1.  MoS Discovery in the home network while attached to the home link

   To discover an MoS in the home network, the MN SHOULD use the DNS
   based MoS discovery method described in
   [I-D.bajko-mos-dns-discovery].  In order to use that, the MN MUST
   first find out the domain name of its home network.  Home domains are
   usually preconfigured in the MNs, thus the MN can simply read its
   configuration data to find out the home domain name (scenario S1).
   Alternatively, the MN MAY use the dhcp options for MoS
   discovery[I-D.bajko-mos-dhcp-options].  Figure 6 provides such model.

Melia, et al.           Expires January 25, 2008                [Page 8]

Internet-Draft                    MSTP                         July 2007

                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+
                [email-masked]

                             (a) using DNS Query

                            +-----+      +------+
               +----+       |     |      |DHCP  |
               | MN |<----->| DHCP|<---->|Server|
               +----+       |Relay|      |      |
                            +-----+      +------+

                             (b)  Using DHCP Option

    Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option

5.2.  MoS Discovery in the local network and Services are local

   To discover an MoS in the visited network, the MN SHOULD attempt to
   use the dhcp options for MoS discovery [I-D.bajko-mos-dhcp-options].
   If the dhcp method fails, the MN SHOULD attempt to use the DNS based
   MoS discovery method described in [[I-D.bajko-mos-dns-discovery].  In
   order to use that, the MN MUST first learn the domain name of the
   local network.  There are a number of ways how the domain name of a
   network can be learned:

   DHCP  In order to find out the domain name of the local network, the
      MN SHOULD use the dhcpv4 option 15 for learning the domain name
      [RFC1533].  Similar solution is available for dhcpv6
      [draft-ietf-dhc-dhcpv6-opt-dnsdomain].

   Reverse dns query  When dhcp does not provide the required domain
      name, the MN MAY use reverse dns (dns PTR record) to find the
      domain name associated with the IP address it is using in the
      local network.  Note, that when a NAT device exists between the MN
      and the local network, the MN will first need to find out the
      external IP address of the NAT device.  Some possible methods for
      determining the NAT's external IP address are STUN [RFC3489] or
      UPnP [UPnP_IDG_DCP].  Once the MN determined the external IP
      address of the NAT device, it MUST use that address in the reverse
      DNS query.

Melia, et al.           Expires January 25, 2008                [Page 9]

Internet-Draft                    MSTP                         July 2007

   Figure 7 provides such model.

                            +-----+      +------+
               +----+       |     |      |DHCP  |
               | MN |<----->| DHCP|<---->|Server|
               +----+       |Relay|      |      |
                            +-----+      +------+

                      (a) MOS Discovery using DHCP options

                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+

                       (b) Reverse DNS Query

         Figure 7: Discovery (a) using DHCP option, (b) Using DNS

5.3.  MOS Discovery in a roaming Network and Services are at Home

   To discover an MoS in the roaming network when services are provided
   by the home network MN SHOULD use the DHCP option along with network
   access authentication.  Upon network access authentication and
   interaction with the NAS the AAAh verifies in the AAA profile that
   the MN is allowed to use the MoS in home.  The AAAh assigns the MoS
   in the home and sends back the information to the NAS.  MN sends a
   DHCP information request as per RFC3315 containing Home Network
   Identifier Option indicating the the need to allocate the MoS in the
   home.  The relay agent intercepts the Information request from the MN
   and it forwards to the DHCP server inserting the MIH Relay Agent
   Option containing the info received by the AAAh.  The DHCP server can
   then reply to the MN by sending the Home Network Information Option.
   The MN receives the MoS address.

   It should be noted that the AAAh does not know what are the
   preferences of the MN, i.e. whether the MoS should be allocated in
   the home or in visited.  The MoS info is stored at the relay agent
   and forwarded to the MN according to the flags in the Home Network
   Identifier Option.  Figure 8 describes the such a model.

Melia, et al.           Expires January 25, 2008               [Page 10]

Internet-Draft                    MSTP                         July 2007

                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |
                           |AAAV   |-----------|--------|AAAH   |
                           |       |           |        |       |
                           |       |           |        |       |
                           +-------+           |        +-------+
                               |               |
                               |               |
                               |               |
                               |               |
                               |               |       +--------+
                               |               |       |        |
                               |               |       |  MoSh  |
                           +-----+    +------+ |       +--------+
               +----+      |     |    |DHCP  | |
               | MN |------| NAS/|----|Server| |
               +----+      | DHCP|    |      | |
                           |Relay|    |      | |
                           +-----+    +------+ |
                                               |

          AAAv -- Visited AAA
          AAAH -- Home AAA
          NAS  -- Network Access Server

   Figure 8: MOS Discovery using Network Access Authentication and DHCP
                                  options

5.4.  MoS discovery in a remote network

   To discover an MoS in a remote network other than home network, the
   MN MUST use the DNS based MoS discovery method described in
   [I-D.bajko-mos-dns-discovery].  In order to use that, the MN MUST
   first learn the domain name of the network it is looking for an MoS
   in.  If the MN does not yet know the domain name of the network,
   learning it may require more than one operation, as pre-configuration
   and dhcp can not be used.  The MN MAY attempt to first discover an
   MoS in either the local or home network and query that MoS to find
   out the domain name of a specific network or the domain name of a
   network at a specific location.  Alternatively, the MN MAY query an
   MoS previously known to learn the domain name of the desired network
   (e.g., via an IS Query).  Figure 9 shows the presented mechanism.

Melia, et al.           Expires January 25, 2008               [Page 11]

Internet-Draft                    MSTP                         July 2007

                                   +-------+
                    +----+         |DHCP   |
                    | MN |-------->|       |
                    +----+         |Server |
                                   +-------+
                     [email-masked]

           (a) Discover MoS in local network with DHCP
                               +------------+
                +----+         |            |
                |    |         |Information |
                | MN |-------->| Server     |
                |    |         |(previously |
                +----+         |discovered) |
                               +------------+

      (b) Using IS query to find the FQDN on the remote network

                                 +-------+
                  +----+         |Domain |
                  | MN |-------->|Name   |
                  +----+         |Server |
                                 +-------+
                   [email-masked]

            (c) using DNS Query in the remote network

   Figure 9: MOS Discovery using (a) DNS Query, (b) IS Query to a known
                                  Server

6.  MIH Transport

   Once the Mobility Services have been discovered, MIH peers MUST
   exchange information over either TCP or UDP.  While either protocol
   can provide the basic transport functionality required, there are
   performance trade-offs and unique characteristics with each that need
   to be considered in the context of the MIH services for different
   network loss and congestion conditions.  Thus, the objectives of this
   section are to discuss these trade-offs for different MIH settings
   such as the MIH message size and rate, and the retransmission
   parameters.  In addition, factors such as NAT traversal are also
   discussed.  Given the reliability requirements for the MIH transport,
   it is assumed in this discussion that the MIH ACK mechanism is to be
   used in conjunction with UDP, while it is preferred to avoid using
   with TCP since TCP includes a similar functionality.

Melia, et al.           Expires January 25, 2008               [Page 12]

Internet-Draft                    MSTP                         July 2007

6.1.  MIH Message size

   Although the MIH message size varies widely from about 30 bytes (for
   a broadcast capability discovery request) to around 65000 bytes (for
   an IS MIH_Get_Information response primitive), a typical MIH message
   size for the ES/CS service ranges between 50 to100 bytes.  Thus,
   considering the effects of the MIH message size on the performance of
   the transport protocol brings us to discussing two main issues,
   related to fragmentation of long messages in the context of UDP and
   the concatenation of short messages in the context of TCP.  Since
   transporting long MIH messages may require fragmentation that is not
   available in UDP, using UDP a limit MUST be set on the size of the
   MIH message, unless fragmentation functionality is added to the MIH
   layer or IP layer fragmentation is used instead.  In this latter
   case, the loss of an IP fragment leads to the retransmission of an
   entire MIH message, which in turn leads to poor end-to-end delay
   performance in addition to wasted bandwidth utilization.  Additional
   recommendations in [I-D.ietf-tsvwg-udp-guidelines] apply for limiting
   the size of the MIH message when using UDP and assuming IP layer
   fragmentation.  In terms of dealing with short messages, TCP has the
   capability to concatenate very short messages in order to reduce the
   overall bandwidth overhead.  However, this reduced overhead comes at
   the cost of additional delay to complete an MIH transaction, which
   may not be acceptable for CS and ES services.

6.2.  MIH Message rate

   The frequency of MIH messages varies according to the MIH service
   type.  It is expected that CS/ES message arrive at a rate of one in
   hundreds of milliseconds in order to capture quick changes in the
   environment and/ or process handover commands.  On the other hand, IS
   messages are exchanged mainly every time a new network is visited
   which may be in order of hours or days.  Therefore a burst of either
   short CS/ES messages or long IS message exchanges (in the case of
   multiple MIH nodes requesting information) may lead to network
   congestion.  While the built-in rate-limiting controls available in
   TCP may be well suited for dealing with these congestion conditions,
   this may result in large transmission delays that may be unacceptable
   for the timely delivery of ES/CS messages.  On the other hand, if UDP
   is used, a rate-limiting effect similar to the one obtained with TCP
   may be obtained by adequately adjusting the token bucket parameters
   defined in the MIH specifications.  Recommendations for parameter
   settings are specific to the scenario considered.

6.3.  Retransmission

   For TCP, the retransmission timeout is adjusted according to the
   measured RTT.  However due to the exponential backoff mechanism, the

Melia, et al.           Expires January 25, 2008               [Page 13]

Internet-Draft                    MSTP                         July 2007

   retransmission timeouts may increase significantly with increased
   packet loss.

   For UDP, the MIH ACK provides a certain level of reliability and the
   maximum retransmission is set to 2.  The MIHF has control over the
   retransmission timeout, which SHOULD be set greater than RTT.
   Recommendations in [RFC1536], [RFC2988] and
   [I-D.ietf-tsvwg-udp-guidelines] about estimating the RTT when using
   UDP apply.

   Also, this method provides some flexibility when retransmitting some
   time-related MIH messages.  For instance, for ES measurements, the
   MIHF could decide whether to retransmit the same old measurement
   information, or whether to drop that retransmission and transmit an
   updated measurement in case that this new measurement is already
   available.

6.4.  NAT Traversal

   There are no known issues for NAT traversal when using TCP.  The
   default connection timeout of 24 hours is considered adequate for MIH
   transport purposes.  However, issues with NAT traversal using UDP are
   documented in [I-D.ietf-tsvwg-udp-guidelines].  Communication
   failures are experienced when middleboxes destroy the per-flow state
   associated with an application session during periods when the
   application does not exchange any UDP traffic.  Hence, communication
   between the MN and the MoS SHOULD be able to gracefully handle such
   failures and implement mechanisms to re-establish their UDP sessions.
   In addition and in order to avoid such failures, MIH messages MAY be
   sent periodically, similarly to keep-alive messages, to attempt to
   refresh middlebox state (e.g.  ES reports could be used for this
   purpose).  As [RFC4787] requires a minimum state timeout of two
   minutes or more, MIH messages using UDP as transport SHOULD be sent
   once every two minutes.

6.5.  General guidelines

   Since ES and CS messages are small in nature and have tight latency
   requirements, UDP in combination with MIH acknowledgement SHOULD be
   used for transporting ES and CS messages.  On the other hand, IS
   messages are more resilient in terms of latency constraints and some
   long IS messages could exceed the MTU of the path to the destination.
   Therefore, TCP SHOULD be used for transporting IS messages.  For both
   UDP and TCP cases, if a port number is not explicitly assigned (e.g.
   by the DNS SRV), MIH messages sent over UDP or TCP MUST use the
   default port number.

Melia, et al.           Expires January 25, 2008               [Page 14]

Internet-Draft                    MSTP                         July 2007

7.  Operation Flows

                           MIH ENABLED MN
        +---------------+     +-------------+
        |  DHCP SERVER  |     | DHCP CLIENT |
        +---------------+     +------|------+
                |                    |
                |    DHCP DISCOVER   |
                |<===================|DHCP DISCOVER
                |                    |WITH MoS option
                |                    |
                |    DHCP OFFER      |
                |===================>|DHCP OFFER
                |                    |WITH MoS
                |   DHCP REQUEST     |
                |<===================|
                |     DHCPACK        |
                |===================>|
                |                    |

               Using DHCP 4-way handshake

                    Figure 10: Discovering MoS function

   Upon layer-two network attachement the MN broadcasts DHCP DISCOVER
   messages according to standard [RFC2132].  According to standard
   behavior the MN can wait to receive multiple replies from DHCP
   servers.  In any case the MN adds the MoS option to the discover
   message.  The DHCP offer message will then contain the IP address of
   the MoS.

Melia, et al.           Expires January 25, 2008               [Page 15]

Internet-Draft                    MSTP                         July 2007

                             MIH ENABLED MN
       +---------------+     +-------------+
       |  DHCP SERVER  |     | DHCP CLIENT |
       +---------------+     +------|------+
               |                    |
               |    DHCP INFORM     |
               |<===================|DHCP INFORM
               |                    |WITH MoS option
               |     DHCPACK        |
               |===================>|
               |                    |

             Using DHCP 2-way handshake

                Figure 11: Discovering MoS Function (MIHF)

   Figure 11shows the 2 way handshake operation with MoS option enabled.

   For DHCPv6 based solutions we should distinguish between having
   stateless autoconfiguration and DHCP two messages based exchange or
   stateful configuration, thus four messages based exchange.  The
   follwoing figure shows how discovery of the MoS can be done through
   the first method.

      +--------------+     +--------------+
      |  DHCP CLIENT |     |  DHCP SERVER |
      +------|-------+     +-------|------+
             |                     |
             |                     |
             | INFORMATION-REQUEST |
             |====================>|
             |                     |
             |   REPLY             |
             |<====================|
             |                     |
             |                     |

                  Figure 12: DHCPv6 two messages exchange

   The INFORMATION REQUEST message is sent to the multicast FF02::1:2
   address containing an "Option Request" option.  Based on the "Client
   identifier" option the DHCP server can send a REPLY message including
   the option requested by the client.  In this case the option will
   refer to the MoS IP address being discovered.

   Figure 10, Figure 11and (Figure 12) meet the requirements imposed by
   scenarios S1 and S2.  S3 needs tight interaction with the AAA
   infrastructure and Figure 13 captures such a case.

Melia, et al.           Expires January 25, 2008               [Page 16]

Internet-Draft                    MSTP                         July 2007

   +-----------+        +----------------+   +----------+    +----------------+
   |    MN     |        |Access Gateway/ |   |  DHCP    |    |                |
   |DHCP Client|        |DHCP Relay      |   |  Server  |    |Home AAA Server |
   +----|------+        +------|---------+   +----|------+   +-------|--------+
        |                      |                  |                  |
        | Access Authentication| Access Authentica|tion Request      |
        |  Request with NAI    | forwarded to Home| Domain           |
        |=====================>|==================|=================>|
        |                      |                  |                  |
        |                      | Access Autneticat|ion success       |
        |Authentication Success| with MoS informat|ion               |
        |<=====================|<=================|==================|
        |                      |                  |                  |
        |    DHCP DISCOVER     |                  |                  |
        |  with MOS option     |                  |                  |
        |=====================>|=================>|                  |
        |                      |                  |                  |
        |    DHCP OFFER        |                  |                  |
        | with MOS information |                  |                  |
        |<=====================|<=================|                  |
        |                      |                  |                  |
        |   DHCP REQUEST       |                  |                  |
        |======================|=================>|                  |
        |                      |                  |                  |
        |   DHCPACK            |                  |                  |
        |<=====================|==================|                  |
        |                      |                  |                  |
        |                      |                  |                  |

      Figure 13: Discovering MoS Function (MIHF) coupled with Network
                           Access Authentication

8.  Security Considerations

   There are a number of security issues that need to be taken into
   account during node discovery and information exchange via a
   transport connection [I-D.ietf-mipshop-mis-ps]

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
   recommended that network administrators should use DHCP
   authentication option described in [RFC3118].  This will also protect
   the denial of service attacks to DHCP server.[RFC3118] provides
   mechanisms for both entity authentication and message authentication.

   In case where DNS is used for discovering MoS, fake DNS requests and
   responses may cause DoS and the inability of the MN to perform a

Melia, et al.           Expires January 25, 2008               [Page 17]

Internet-Draft                    MSTP                         July 2007

   proper handover, respectively.  Where networks are exposed to such
   DoS, it is recommended that DNS service providers use the Domain Name
   System Security Extensions (DNSSEC) as decsribed in [RFC4033].
   Readers may also refer to
   [I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects
   of DNSSEC Operational Practices.

   In case where reliable transport protocol such as TCP is used for
   transport connection between two MIHF peers, TLS [RFC4346] should be
   used for message confidentiality and data integrity.  In particular,
   TLS is designed for client/server applications and to prevent
   eavesdropping, tampering, or message forgery.  Readers should also
   follow the recommendations in [RFC4366] that provides generic
   extension mechanisms for the TLS protocol suitable for wireless
   environments.

   In case where unreliable transport protocol such as UDP is used for
   transport connection between two MIHF peers, no transport layer
   security is currently available.  In such cases if message
   confidentiality and data integrity are necessary, it should use IP
   layer security such as IPSec .[RFC2401] IPSec provides message
   authentication in addition to message confidentiality and data
   integrity.

9.  IANA Considerations

   This document registers the following TCP and UDP port(s) with IANA:

   Keyword     Decimal    Description
   -------     -------    -----------
   ieee-mih    XXX/tcp    IEEE Media Independent Handover (MIH)Protocol
   ieee-mih    XXX/udp    IEEE Media Independent Handover (MIH)Protocol

10.  Acknowledgements

   ....

11.  References

11.1.  Normative References

   [I-D.bajko-mos-dhcp-options]
              Bajko, G., "Dynamic Host Configuration Protocol (DHCPv4
              and DHCPv6) Options for Mobility  Servers (MoS)",
              draft-bajko-mos-dhcp-options-00 (work in progress),

Melia, et al.           Expires January 25, 2008               [Page 18]

Internet-Draft                    MSTP                         July 2007

              August 2007.

   [I-D.bajko-mos-dns-discovery]
              Bajko, G., "Locating Mobility Servers",
              draft-bajko-mos-dns-discovery-00 (work in progress),
              August 2007.

   [I-D.ietf-dnsop-dnssec-operational-practices]
              Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
              draft-ietf-dnsop-dnssec-operational-practices-08 (work in
              progress), March 2006.

   [I-D.ietf-mipshop-mis-ps]
              Melia, T., "Mobility Services Transport: Problem
              Statement", draft-ietf-mipshop-mis-ps-03 (work in
              progress), August 2007.

   [I-D.ietf-tsvwg-udp-guidelines]
              Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
              Application Designers", draft-ietf-tsvwg-udp-guidelines-02
              (work in progress), July 2007.

   [RFC1533]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 1533, October 1993.

   [RFC1536]  Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
              Miller, "Common DNS Implementation Errors and Suggested
              Fixes", RFC 1536, October 1993.

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

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
              Timer", RFC 2988, November 2000.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP

Melia, et al.           Expires January 25, 2008               [Page 19]

Internet-Draft                    MSTP                         July 2007

              Messages", RFC 3118, June 2001.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

11.2.  Informative References

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 20]

Internet-Draft                    MSTP                         July 2007

   Nada Golmie
   NIST

   Phone:
   Fax:
   Email:
   URI:

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Gabor Bajko
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Juan Carlos Zuniga
   InterDigital

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 21]

Internet-Draft                    MSTP                         July 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 January 25, 2008               [Page 22]


_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: Subir Das <[email-masked]>
Date: Thu, 13 Sep 2007 12:59:57 -0400

Tele,
I am running little late. Will send you by today.

-Subir

Telemaco Melia wrote:
> ------------------------------------------------------------------------
>

---

From: Subir Das <[email-masked]>
Date: Thu, 13 Sep 2007 21:45:45 -0400

Tele,
Sending the call flow. Could not spend much time onto this.
It needs some editing. Pl. feel free to change it.

Thanks,
-Subir

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC

Status of this Memo

Copyright Notice



Abstract

   To be edited.

Requirements Language

Table of Contents



1.  Introduction

2.  Terminology

   MN Mobile Node

   NN Network Node



3.  Deployment Scenarios

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/



    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

                                      +--------------+
                                      | HOME NETWORK |



4.  Solution Overview

4.1.  Architecture



                            Figure 5: MN stack

5.  MoS Discovery



   than home network.



                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+
                [email-masked]

                             (a) using DNS Query

                            +-----+      +------+
               +----+       |     |      |DHCP  |

                             (b)  Using DHCP Option



                            +-----+      +------+
               +----+       |     |      |DHCP  |

                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+

                       (b) Reverse DNS Query



                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |

          AAAv -- Visited AAA
          AAAH -- Home AAA



                                   +-------+
                    +----+         |DHCP   |
                    | MN |-------->|       |
                    +----+         |Server |
                                   +-------+
                     [email-masked]

                                 +-------+
                  +----+         |Domain |
                  | MN |-------->|Name   |
                  +----+         |Server |
                                 +-------+
                   [email-masked]

6.  MIH Transport



6.1.  MIH Message size

6.2.  MIH Message rate

6.3.  Retransmission



6.4.  NAT Traversal

6.5.  General guidelines



7.  Operation Flows

    Following figure xx gives an example operation flow between MIHF peers 
    when an MIH user requests for an IS service. Scenario  1 is chosen whereby
    DHCP is used for MoS discovery and TCP is used for establishing a transport
    connection. When MOS is not preconfigured, MIH user needs to discover the 
    Ip address of MOS to communicate with the remote MIHF. Therefore MIH user 
    requests the local MIHF via a discovery message as defined in IEEE 802.21 [].
    In this example, we assume that MoS discovery is performed 
    before a transport connection is established with the remore MIHF and the 
    DHCP client process is invoked via some internal APIs. DHCP Client 
    sends DHCP INFORM message according to Standard DHCP[] and with the MOS option as 
    defines in [Draft-Bajko---]. DHCP server replies via DHCP ACK message with the IP 
    address of the MoS. The MOS address is then passed to the MIHF locally via some 
    internal APIs. MIHF generates the discovery response message 
    and passes it on  to the corresponding MIH user. MIH user then generates an IS query 
    addressed to the remote MoS. MIHF invokes the underlying TCP client  which then 
    establishes a transport connection with the 
    remote peer. Once transport connection is available, MIHF sends the IS query via MIH protocol 
    REQUEST message. The message arrives to the destination MIHF and MIH user respectively. 
    MIH user responds to the corresponding IS query and the remote MIHF sends the IS response 
    via MIH protocol RESPONSE message. Thus it arrives to the source MIHF which passes it on to the 
    corresponding MIH user. 

    +------+   +-----+   +------+   +------+         +------+   +------+  +-----+   +-----+
    | MIH  |   |MIHF |   | TCP  |   |DHCP  |         |DHCP  |   | TCP  |  |MIHF |   | MIH | 
    | User |   |     |   |Client|   |Client|         |Server|   |Server|  |     |   | User|
    +------+   +-----+   +------+   +------+         +------+   +------+  +-----+   +-----+ 
        |         |          |          |                |          |        |         | 
        |Discovery|          |          |                |          |        |         |
        | Request |Invoke DHCP Client   |DHCP INFORM     |          |        |         |
        |========>|====================>|===============>|          |        |         |     
        |         |  (internal process) | with MOS Option|          |        |         |
        |         |          |          |                |          |        |         |
        |         |          |          |                |          |        |         | 
        |         |          |          |   DHCP ACK     |          |        |         |
        |         |          |          |<===============|          |        |         |
        |         | Inform MoS address  |                |          |        |         |
        |         |<====================|                |          |        |         |
        |         | (internal process)  |                |          |        |         | 
        |Discovery|          |          |                |          |        |         |
        |response |          |          |                |          |        |         |
        |<========|          |          |                |          |        |         |
        |         |          |          |                |          |        |         | 
        |IS Query |          |          |                |          |        |         |        
        |========>|          |          |                |          |        |         |
        |         |          |          |                |          |        |         |
        |         |Invoke TCP|          |                |          |        |         |
        |         |=========>|          |                |          |        |         |
        |         | client   |        TCP connection established    |        |         |        
        |         |          |<====================================>|        |         |            
        |         |          |          |                |          |        |         | 
        |         |          |          |                |          |        |         |
        |         |          |          |                |          |        |         |  
        |         |                 IS  QUERY REQUEST (via MIH protocol)     |         |
        |         |=========================================================>|         |
        |         |          |          |                |          |        |IS QUERY |                                              |         |          |          |                |          |        | REQUEST |    
        |         |          |          |                |          |        |========>|
        |         |          |          |                |          |        |         |
        |         |          |          |                |          |        |  QUERY  |
        |         |          |          |                |          |        | RESPONSE|
        |         |          |          |                |          |        |<========|
        |         |          |          |                |          |        |         |
        |         |          |       IS QUERY RESPONSE (via MIH protocol)    |         |
        |         |<=========================================================|         |
        |         |          |          |                |          |        |         |
        |    IS   |          |          |                |          |        |         |         
        |RESPONSE |          |          |                |          |        |         |                             
        |<========|          |          |                |          |        |         |
        |         |          |          |                |          |        |         |
        |         |          |          |                |          |        |         |               

                    Figure xx: EXample Flow of Operation Involving MIH User 



9.  IANA Considerations

10.  Acknowledgements

   ....

11.  References



              August 2007.



Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:



   Nada Golmie
   NIST

   Phone:
   Fax:
   Email:
   URI:

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Gabor Bajko
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Juan Carlos Zuniga
   InterDigital

   Phone:
   Fax:
   Email:
   URI:



Full Copyright Statement

Intellectual Property

Acknowledgment

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 13 Sep 2007 22:56:38 -0400

Not to confuse people, we should specify in the figure that the first 4
boxes are in the MN, the fifth is a DCHP server, and the 6th, 7th and
8th are in the MoS Server (i.e. DHCP server and MoS are not necessarily
collocated).

Jc

-----Original Message-----
From: Subir Das [mailto:[email-masked]] 
Sent: September 13, 2007 9:46 PM
To: Telemaco Melia
Cc: Patrick Stupar; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Version Thu 13th

Tele,

Thanks,
-Subir

---

From: <[email-masked]>
Date: Fri, 14 Sep 2007 01:35:04 -0500

Some more issues:

Section 5, this sentence is confusing: "In case MoS assignment is
provided locally (S1 and S2)
   [draft-gabor-dhcp] and [draft-gabor-dns] could be used to transfer
   MoS information from the network to the MN (via DHCP or DNS). " 

I do not know what did you intend to say with this, but it has to be
reformulated. The DNS based discovery is used also in 5.4 (scenario s4)
not only in s1 and s2. The 'transfer MoS information from the network to
the MN' is the 'discovery'. Also s1 and s2 should not just hung around,
must be preceeded with the word 'scenario'.

Figure 9 I intended to be one call flow, and not three different
figures. The steps need to be described and the figure subtitle should
say eg 'Discovery of MoS in a remote network'.

Figure 7b is not good. It is not about a simple DNS query, it is either
a PTR query or a two step operation, where you first find out the IP
address of the other side of the NAT (using eg STUN or UPnP) then you do
the PTR query.

I think the conclusion of yesterday's AC was that if we can not agree on
the 2nd paragraph of section 6.3, then we leave it out. I think it
should be removed from the time being.

Some formatting/editorial issues:

DNS should always be with capitals when it is not in brackets []
Same for DHCP

There are two bullets in section 5.2, but the formatting is not good.
Can you put a 'o' in front of those bullets?

Names in alphabetical order and email addresses to be added.

Please do NOT submit the draft without handling the above issues.

Thanks.
- gabor

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Thursday, September 13, 2007 2:00 AM
To: [email-masked]
Cc: Patrick Stupar
Subject: [MIPSHOP-MIH-DT] Version Thu 13th

Guys,

Let me know
Tele

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 17 Sep 2007 17:08:51 +0200

Guys,

I could not finalize the work today, will do so tomorrow.

Tele

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.
NEC Laboratories Europe
Network Division			
Kurfürsten-Anlage 36		
69115 Heidelberg
GERMANY	  

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

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 18 Sep 2007 16:11:35 +0200

Guys,

Here it goes.
I have been trying to address your comments.
Please check the text. I did not modify picture 7b, rather I clarified 
the text.
So I did for 9 (the format of the other pictures of the section would 
have been different then..).
I hope I corrected the major editorial issues. I also run a spell check. 
Let me know anything wrong you see in the document.
Before submission would be interesting to get a brief review from non 
DT-members. Do you think it is possible?

I will ask Patrick if he has time.

Sorry for the delay

Tele

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC
Intended status: Standards Track                                G. Bajko
Expires: March 21, 2008                                            Nokia
                                                                  S. Das
                                                               Telcordia
                                                               N. Golmie
                                                                    NIST
                                                                  S. Xia
                                                                  Huawei
                                                              JC. Zuniga
                                                            InterDigital
                                                      September 18, 2007

              Mobility Services Transport Protocol Design
                  draft-melia-mipshop-mstp-solution-00

Status of this Memo

   This Internet-Draft will expire on March 21, 2008.

Copyright Notice

Melia, et al.            Expires March 21, 2008                 [Page 1]

Internet-Draft                    MSTP                    September 2007

Abstract

   To be edited.

Requirements Language

Table of Contents

     6.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . . 14
     6.6.  Mobility and Multihoming . . . . . . . . . . . . . . . . . 14

Melia, et al.            Expires March 21, 2008                 [Page 2]

Internet-Draft                    MSTP                    September 2007

1.  Introduction

   This document proposes a solution to the issues identified in the
   problem statement document [I-D.ietf-mipshop-mis-ps] for the
   transport of IEEE 802.21 MIH protocols.

   PoS) either during attachment or during handover.  Upon successful

2.  Terminology

   MoS  As defined in the problem statement document it includes IS, CS,
      ES services defined by the IEEE 802.21 standard.

   MN Mobile Node

   NN Network Node

Melia, et al.            Expires March 21, 2008                 [Page 3]

Internet-Draft                    MSTP                    September 2007

3.  Deployment Scenarios

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

   S2 Visited Network MoS, MN is in the visited network and mobility
      services are also provided by the visited network.  We refer to
      this as MoSv ans in Figure 2.

             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/

Melia, et al.            Expires March 21, 2008                 [Page 4]

Internet-Draft                    MSTP                    September 2007

    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

   S4 Third party MoS, MN is in home or visited network and services are
      provided by a 3rd party network.  We refer to this as MoS3 as in
      Figure 4

                                      +--------------+
                                      | HOME NETWORK |

Melia, et al.            Expires March 21, 2008                 [Page 5]

Internet-Draft                    MSTP                    September 2007

4.  Solution Overview

   As mentioned in section Section 1 the solution space is being divided
   in discovery and transport.  The following assumptions have been
   made:

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.  The recommendation to the IEEE 802.21
      WG is to restrict to only these two.

   o  The solutions are chosen to cover all possible deployment
      scenarios as described in section Section 3.

      or thereafter.

   For the discovering the location of an MoS, the MN could either be
   pre-configured with the address of the MoS, or this address could be
   dynamically assigned through DHCP or DNS by the network.  The dynamic
   assignation methods are described in section Section 5.

   The configuration of the MoS could be executed either upon network
   attachment or after successful IP configuration.  The methodology to
   be used depends on the considered deployment scenario.

4.1.  Architecture

Melia, et al.            Expires March 21, 2008                 [Page 6]

Internet-Draft                    MSTP                    September 2007

                            Figure 5: MN stack

   As it can be seen, the MIHF relies on the services provided by TCP
   and UDP for transport, as well as DHCP and DNS for peer discovery.
   In cases where peer MIHF IP address is not pre-configured, source
   MIHF needs to discover it either via DHCP or DNS or using a
   combination of both as described in Section 5.  Once peer MIHF is
   discovered, MIHF must exchange messages with its peer over either UDP
   or TCP.  Specific recommendations on choice of transport protocols
   are provided in section Section 6.

   The above reference architecture however does not provide the model
   for other services such as, fragmentation and security.  Depending
   upon the MIH services (e.g., ES, CS and IS) the message size can be
   very large.  In cases where underlying layer does not support
   fragmentation, this may be an issue.  There is no security available
   currently at the MIH protocol level.  However, security can be
   provided either at the transport or IP layer where it is necessary.
   Section Section 8 provides some guidelines and recommendations for
   security.

5.  MoS Discovery

Melia, et al.            Expires March 21, 2008                 [Page 7]

Internet-Draft                    MSTP                    September 2007

   than home network.

   In case MoS is provided locally (scenarios S1 and S2)
   [I-D.bajko-mos-dhcp-options] and [I-D.bajko-mos-dns-discovery] could
   be used to transfer MoS information from the network to the MN (via
   DHCP or DNS).  In case MoS is provided in the home while the MN is
   attached in visited (scenario S3) an interaction between the DHCP and
   AAA infrastructure is required similarly to what specified in
   [I-D.ietf-mip6-bootstrapping-integrated-dhc].  It is assumed
   therefore that MoS assignment is performed during access
   authentication and authorization.  In case MoS is provided in a
   remote network other than visited or home (scenario S4) only DNS
   based methods apply.

   To discover an MoS in the home network, the MN SHOULD use the DNS
   based MoS discovery method described in
   [I-D.bajko-mos-dns-discovery].  In order to use that, the MN MUST
   first find out the domain name of its home network.  Home domains are
   usually pre-configured in the MNs, thus the MN can simply read its
   configuration data to find out the home domain name (scenario S1).
   Alternatively, the MN MAY use the DHCP options for MoS
   discovery[I-D.bajko-mos-dhcp-options].  Figure 6 provides such model.

Melia, et al.            Expires March 21, 2008                 [Page 8]

Internet-Draft                    MSTP                    September 2007

                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+
                [email-masked]

                             (a) using DNS Query

                            +-----+      +------+
               +----+       |     |      |DHCP  |

                             (b)  Using DHCP Option

   To discover an MoS in the visited network, the MN SHOULD attempt to
   use the DHCP options for MoS discovery [I-D.bajko-mos-dhcp-options].
   If the DHCP method fails, the MN SHOULD attempt to use the DNS based
   MoS discovery method described in [[I-D.bajko-mos-dns-discovery].  In
   order to use that, the MN MUST first learn the domain name of the
   local network.  There are a number of ways how the domain name of a
   network can be learned:

   DHCP --  In order to find out the domain name of the local network,
      the MN SHOULD use the dhcpv4 option 15 for learning the domain
      name [RFC1533].  Similar solution is available for dhcpv6
      [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] .

   Reverse dns query --  When DHCP does not provide the required domain
      name, the MN MAY use reverse DNS (DNS PTR record) to find the
      domain name associated with the IP address it is using in the
      local network.  Note, that when a NAT device exists between the MN
      and the local network, the MN will first need to find out the
      external IP address of the NAT device.  Some possible methods for
      determining the NAT's external IP address are STUN [RFC3849] or
      UPnP [UPnP_IDG_DCP].  Once the MN determined the external IP
      address of the NAT device, it MUST use that address in the reverse
      DNS query.

Melia, et al.            Expires March 21, 2008                 [Page 9]

Internet-Draft                    MSTP                    September 2007

                         +-----+      +------+
            +----+       |     |      |DHCP  |

                           +-------+
            +----+         |Domain |
            | MN |-------->|Name   |
            +----+         |Server |
                           +-------+

                    (b) Reverse DNS Query (starting from the IP address)

   DHCP information request as per [RFC3315] containing Home Network
   Identifier Option indicating the need to allocate the MoS in the

   Identifier Option.  Figure 8 describes such a model.

Melia, et al.            Expires March 21, 2008                [Page 10]

Internet-Draft                    MSTP                    September 2007

                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |

          AAAv -- Visited AAA
          AAAH -- Home AAA

   To discover an MoS in a remote network other than home network, the
   MN MUST use the DNS based MoS discovery method described in
   [I-D.bajko-mos-dns-discovery].  In order to use that, the MN MUST
   first learn the domain name of the network it is looking for an MoS
   in.  If the MN does not yet know the domain name of the network,
   learning it may require more than one operation, as pre-configuration
   and DHCP methods can not be used.  The MN MAY attempt to first
   discover an MoS in either the local or home network (as in Figure 9
   part (a)) and query that MoS to find out the domain name of a
   specific network or the domain name of a network at a specific
   location (as in Figure 9 part (b)).  Alternatively, the MN MAY query
   an MoS previously known to learn the domain name of the desired
   network (e.g., via an IS Query).  Finally the MN can use DNS queries
   to find MoS in the remote network as inFigure 9 part(c).  It should

Melia, et al.            Expires March 21, 2008                [Page 11]

Internet-Draft                    MSTP                    September 2007

   be noted that step c can only be performed upon obtaining the domain
   name of the remote network.

                                   +-------+
                    +----+         |DHCP   |
                    | MN |-------->|       |
                    +----+         |Server |
                                   +-------+
                     [email-masked]

                                 +-------+
                  +----+         |Domain |
                  | MN |-------->|Name   |
                  +----+         |Server |
                                 +-------+
                   [email-masked]

6.  MIH Transport

Melia, et al.            Expires March 21, 2008                [Page 12]

Internet-Draft                    MSTP                    September 2007

6.1.  MIH Message size

6.2.  MIH Message rate

Melia, et al.            Expires March 21, 2008                [Page 13]

Internet-Draft                    MSTP                    September 2007

6.3.  Retransmission

6.4.  NAT Traversal

6.5.  General guidelines

6.6.  Mobility and Multihoming

   When handover happens, maybe MN want to keep MIH session connection
   continuity.  In case that MN has different interfaces, maybe MN want
   to transfer an ongoing MIH session from one interface to the other.
   Just as [I-D.ietf-mipshop-mis-ps] described, MSTP should cope with
   mobility and multihoming Issues.  Because MIHF is used to facilitate
   handover and serves mobility management users, i.e.  SIP, Mobile IP
   etc., it is reasonable for MSTP to cope with mobility and multihoming
   itself, instead of depending on the other mobility mechanisms.

Melia, et al.            Expires March 21, 2008                [Page 14]

Internet-Draft                    MSTP                    September 2007

               MN                              MoS
     +--------------------------+    +--------------------------+
     |         MSTP             |    |         MSTP             |
     |  +--------------------+  |    |  +--------------------+  |
     |  |     MIHF ID        +--+----+--+     MIHF ID        |  |
     |  +--------------------+  |    |  +--------------------+  |
     |  +--------+  +--------+  |    |  +--------+  +--------+  |
     |  | socket |  | socket |  |    |  | socket |  | socket |  |
     |  +---+----+  +---+----+  |    |  +---+----+  +----+---+  |
     +------+-----------+-------+    +------+------------+------+
            |           |         1         |            |
            |           +-------------------+            |
            |                     2                      |
            +--------------------------------------------+

          Figure 10: MSTP framework for multihoming and mobility

   Proposed method is to separate MIHF ID from actual IP address just as
   depicted in Figure 10.  MSTP users utilize MIHF ID to set up MIH
   session.  While handover or multihoming transfer happens, MIHF ID
   keeps invariable and underlying transport connection will be
   recreated.  For MIH session using TCP, MN needs to utilize new socket
   (new IP source address and port number) to reconnect mobility service
   provider and to create new TCP connection, just as specified in
   Figure 10, transferring MIH session from socket connection 1 to
   connection 2.  For MIH session using UDP, MN needs to utilize new
   socket to send or receive IP packets; but for mobility service
   provider, it's not necessary to change socket.

   Because MSTP just provides transport service and MIHF ensure session
   consistency, no additional security issues are introduced from MSTP
   framework for multihoming and mobility.

7.  Operation Flows

   Following Figure 11 gives an example operation flow between MIHF
   peers when an MIH user requests for an IS service.  Scenario 1 is
   chosen whereby DHCP is used for MoS discovery and TCP is used for
   establishing a transport connection.  When MOS is not pre-configured,
   MIH user needs to discover the IP address of MOS to communicate with
   the remote MIHF.  Therefore MIH user requests the local MIHF via a
   discovery message as defined in IEEE 802.21.

   In this example, we assume that MoS discovery is performed before a
   transport connection is established with the remote MIHF and the DHCP
   client process is invoked via some internal APIs.  DHCP Client sends
   DHCP INFORM message according to standard DHCP and with the MoS

Melia, et al.            Expires March 21, 2008                [Page 15]

Internet-Draft                    MSTP                    September 2007

   option as defines in [I-D.bajko-mos-dhcp-options].  DHCP server
   replies via DHCP ACK message with the IP address of the MoS.  The MOS
   address is then passed to the MIHF locally via some internal APIs.
   MIHF generates the discovery response message and passes it on to the
   corresponding MIH user.  MIH user then generates an IS query
   addressed to the remote MoS.  MIHF invokes the underlying TCP client
   which then establishes a transport connection with the remote peer.
   Once transport connection is available, MIHF sends the IS query via
   MIH protocol REQUEST message.  The message arrives to the destination
   MIHF and MIH user respectively.  MIH user responds to the
   corresponding IS query and the remote MIHF sends the IS response via
   MIH protocol RESPONSE message.  Thus it arrives to the source MIHF
   which passes it on to the corresponding MIH user.

                   MN                                             MoS
|======================================|    |======|   |======================|
+------+   +-----+   +------+  +------+     +------+   +------+  +----+  +----+
| MIH  |   |MIHF |   | TCP  |  |DHCP  |     |DHCP  |   | TCP  |  |MIHF|  |MIH |
| User |   |     |   |Client|  |Client|     |Server|   |Server|  |    |  |User|
+------+   +-----+   +------+  +------+     +------+   +------+  +----+  +----+
    |         |          |         |            |          |        |       |
    |Discovery|          |         |            |          |        |       |
    | Request |Invoke DHCP Client  |DHCP INFORM |          |        |       |
    |========>|===================>|===========>|          |        |       |
    |         |  (internal process)| with MOS   |          |        |       |
    |         |          |         | option     |          |        |       |
    |         |          |         |            |          |        |       |
    |         |          |         |   DHCP ACK |          |        |       |
    |         |          |         |<===========|          |        |       |
    |         | Inform MoS address |            |          |        |       |
    |         |<===================|            |          |        |       |
    |         | (internal process) |            |          |        |       |
    |Discovery|          |         |            |          |        |       |
    |response |          |         |            |          |        |       |
    |<========|          |         |            |          |        |       |
    |         |          |         |            |          |        |       |
    |IS Query |          |         |            |          |        |       |
    |========>|          |         |            |          |        |       |
    |         |          |         |            |          |        |       |
    |         |Invoke TCP|         |            |          |        |       |
    |         |=========>|         |            |          |        |       |
    |         | client   |    TCP connection established    |        |       |
    |         |          |<===============================>|        |       |
    |         |          |         |            |          |        |       |
    |         |          |         |            |          |        |       |
    |         |          |         |            |          |        |       |
    |         |          | IS  QUERY REQUEST (via MIH protocol)     |       |
    |         |====================================================>|       |

Melia, et al.            Expires March 21, 2008                [Page 16]

Internet-Draft                    MSTP                    September 2007

    |         |          |         |             |         |        |IS     |
    |         |          |         |             |         |        |QUERY  |
    |         |          |         |             |         |        |REQUEST|
    |         |          |         |             |         |        |======>|
    |         |          |         |             |         |        |       |
    |         |          |         |             |         |        |QUERY  |
    |         |          |         |             |         |        |RESPONSE
    |         |          |         |             |         |        |<======|
    |         |          |         |             |         |        |       |
    |         |          |  IS QUERY RESPONSE (via MIH protocol)    |       |
    |         |<====================================================|       |
    |         |          |         |             |         |        |       |
    |    IS   |          |         |             |         |        |       |
    |RESPONSE |          |         |             |         |        |       |
    |<========|          |         |             |         |        |       |
    |         |          |         |             |         |        |       |
    |         |          |         |             |         |        |       |

          Figure 11: Example Flow of Operation Involving MIH User

   System Security Extensions (DNSSEC) as described in [RFC4033].

Melia, et al.            Expires March 21, 2008                [Page 17]

Internet-Draft                    MSTP                    September 2007

9.  IANA Considerations

 Keyword        Decimal    Description
 -------        -------    -----------
 ieee-mih-IS    XXX/tcp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-IS    XXX/udp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-ES    XXX/tcp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-ES    XXX/udp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-CS    XXX/tcp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-CS    XXX/udp    IEEE Media Independent Handover (MIH)Protocol

10.  Acknowledgements

   The authors would like to thank Patrick Stupar for his valuable
   comments and fruitful discussions.

11.  References

Melia, et al.            Expires March 21, 2008                [Page 18]

Internet-Draft                    MSTP                    September 2007

   [I-D.ietf-dhc-dhcpv6-opt-dnsdomain]
              Yan, R., "Domain Suffix Option for DHCPv6",
              draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress),
              June 2007.

   [I-D.ietf-mip6-bootstrapping-integrated-dhc]
              Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
              Integrated Scenario",
              draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
              progress), July 2007.

Melia, et al.            Expires March 21, 2008                [Page 19]

Internet-Draft                    MSTP                    September 2007

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849, July 2004.

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Email: [email-masked]

   Gabor Bajko
   Nokia

   Email: [email-masked]

Melia, et al.            Expires March 21, 2008                [Page 20]

Internet-Draft                    MSTP                    September 2007

   Subir Das
   Telcordia

   Email: [email-masked]

   Nada Golmie
   NIST

   Email: [email-masked]

   Sam Xia
   Huawei

   Email: [email-masked]

   Juan Carlos Zuniga
   InterDigital

   Email: [email-masked]

Melia, et al.            Expires March 21, 2008                [Page 21]

Internet-Draft                    MSTP                    September 2007

Full Copyright Statement

Intellectual Property

Acknowledgment

Melia, et al.            Expires March 21, 2008                [Page 22]

---

From: Telemaco Melia <[email-masked]>
Date: Tue, 18 Sep 2007 19:29:35 +0200

Telemaco Melia wrote:
> I hope I corrected the major editorial issues. I also run a spell 
> check. Let me know anything wrong you see in the document.
Please guys provide feedback asap.

tele

---

From: Subir Das <[email-masked]>
Date: Tue, 18 Sep 2007 17:35:26 -0400

Tele,
There were some inconsistencies  in security consideration section. I 
have fixed it
and added the corresponding reference. Thanks to Gabor for pointing this 
out!!
I will go over the rest of the document.

-Subir 

Telemaco Melia wrote:
>> Please check the text. I did not modify picture 7b, rather I 
>> clarified the text.

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC
                                                                 H. Jang
                                                                 Samsung
                                                                  S. Das
                                                               Telcordia
                                                                G. Bajko
                                                                   Nokia
                                                              JC. Zuniga
                                                            InterDigital
                                                           July 24, 2007

Status of this Memo

Copyright Notice



Abstract

   To be edited.

Requirements Language

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Architecture (functional elements?) . . . . . . . . . . . . 3
       2.1.1.  MIHF Identifiers (FQDN, NAI)  . . . . . . . . . . . . . 3
     2.2.  Deployment Scenarios  . . . . . . . . . . . . . . . . . . . 3
   3.  Node Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  MIH Transport . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  Operation Flows . . . . . . . . . . . . . . . . . . . . . . . . 3
   6.  Message specifications  . . . . . . . . . . . . . . . . . . . . 3
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 4
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 4
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7



1.  Introduction

   Introduce the document, its structure and scope of the solution.

2.  Solution Overview

   Give a general overview of how the MN and network nodes are supposed
   to work.  Divide the problem space in node discovery and transport.

2.1.  Architecture (functional elements?)

   Not sure if it is a subsection or not, but we need to describe the MN
   and the NN.

2.1.1.  MIHF Identifiers (FQDN, NAI)

2.2.  Deployment Scenarios

   From the slides.

3.  Node Discovery

   DHCP, DNS, IS

4.  MIH Transport

   MIH transport considerations (latency, congestion control and
   reliability)

5.  Operation Flows

   Include here flows for each of the scenarios we want to support.

6.  Message specifications

   propose extensions for the missing parts (we can have them here for
   the time being and split later on)

7.  IANA Considerations

   Requests to IANA .



   Information from a trusted source, Security association management,
   Security association management

9.  Acknowledgements

   ....

10.  References

10.1.  Normative References

10.2.  Informative References

   [Anchor]   "", 2005.

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:



   Nada Golmie
   NIST

   Phone:
   Fax:
   Email:
   URI:

   Heejin Jang
   Samsung

   Phone:
   Fax:
   Email:
   URI:

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Gabor Bajko
   Nokia

   Phone:
   Fax:
   Email:
   URI:



   Juan Carlos Zuniga
   InterDigital

   Phone:
   Fax:
   Email:
   URI:



Full Copyright Statement

Intellectual Property

Acknowledgment

---

From: "Stefano Faccin" <[email-masked]>
Date: Tue, 18 Sep 2007 14:55:36 -0700

Hello guys,
What is the current estimate for completion of the draft?
Stefano

-----Original Message-----
From: Subir Das [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 2:35 PM
To: Telemaco Melia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Version Thu 13th

Tele,

out!!

-Subir

---

From: <[email-masked]>
Date: Tue, 18 Sep 2007 22:10:01 -0500

This looks good now. I had a comment on the security section, and Subir kindly proposed new text already. 

The other comment I have is with the newly added section 6.6. First, the wording has to be improved. Secondly, I think that a connection to the MIHF is just a 'usual' session the MN has, just as any other session it may have. Thus, socket recreation shouldn't be any different that any other socket recreation, so I am not sure we need to address the socket staff at all. Any other thoughts?

- gabor 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 7:12 AM
To: Bajko Gabor (Nokia-SIR/MtView); [email-masked]
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Version Thu 13th

Guys,

Here it goes.
I have been trying to address your comments.
Please check the text. I did not modify picture 7b, rather I clarified the text.
So I did for 9 (the format of the other pictures of the section would have been different then..).
I hope I corrected the major editorial issues. I also run a spell check. 
Let me know anything wrong you see in the document.
Before submission would be interesting to get a brief review from non DT-members. Do you think it is possible?

Sorry for the delay

Tele

[email-masked] wrote:
> reformulated. The DNS based discovery is used also in 5.4 (scenario 
> s4) not only in s1 and s2. The 'transfer MoS information from the 
> network to the MN' is the 'discovery'. Also s1 and s2 should not just 
> hung around, must be preceeded with the word 'scenario'.
>
> Figure 7b is not good. It is not about a simple DNS query, it is 
> either a PTR query or a two step operation, where you first find out 
> the IP address of the other side of the NAT (using eg STUN or UPnP) 
> then you do the PTR query.
>
> I think the conclusion of yesterday's AC was that if we can not agree 
> on the 2nd paragraph of section 6.3, then we leave it out. I think it 
> DNS should always be with capitals when it is not in brackets [] Same 
> for DHCP
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Tue, 18 Sep 2007 23:27:36 -0400

To be honest, Section 6.6 (Mobility and Multihoming) looked confusing to me and I was expecting some other feedback (or clarification) before providing my views. Now that I read Gabor's comment, I can say that I agree that this section should be improved a lot before including it in the document. 
The mapping between the text and the figure is unclear and the added value is questionable, as indeed having one or two sockets should not be any different in this case. It seems to me that the example is making assumptions such as multi-radio, make-before-break and a lot of other ones that should be independent of the MSTP solution.

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: September 18, 2007 5:10 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Version Thu 13th

- gabor 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 7:12 AM
To: Bajko Gabor (Nokia-SIR/MtView); [email-masked]
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Version Thu 13th

Guys,

Here it goes.

Sorry for the delay

Tele

---

From: Sam Xia <[email-masked]>
Date: Wed, 19 Sep 2007 11:47:51 +0800

> This looks good now. I had a comment on the security section, 
> and Subir kindly proposed new text already. 
> 
> The other comment I have is with the newly added section 6.6. 
> First, the wording has to be improved. 
Please Tele improve the wording.

>Secondly, I think that 
> a connection to the MIHF is just a 'usual' session the MN 
> has, just as any other session it may have. Thus, socket 
> recreation shouldn't be any different that any other socket 
> recreation, so I am not sure we need to address the socket 
> staff at all. Any other thoughts?
Yes, you are right that MIHF session a usual session not different than  the
others.  Socket is used just for describing recommended internal
implementation of MSTP . it is useful to make reader understand clearer.
And socket is an general representation for TCP and UDP end points, easily
used to generalize the framework. so Why not? 

> So I did for 9 (the format of the other pictures of the 
> section would have been different then..).
> Before submission would be interesting to get a brief review 
> from non DT-members. Do you think it is possible?
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014 
> 
>

---

From: Sam Xia <[email-masked]>
Date: Wed, 19 Sep 2007 12:08:51 +0800

> To be honest, Section 6.6 (Mobility and Multihoming) looked 
> confusing to me and I was expecting some other feedback (or 
> clarification) before providing my views. Now that I read 
> Gabor's comment, I can say that I agree that this section 
> should be improved a lot before including it in the document. 

> The mapping between the text and the figure is unclear and 
> the added value is questionable, as indeed having one or two 
> sockets should not be any different in this case. It seems to 
> me that the example is making assumptions such as 
> multi-radio, make-before-break and a lot of other ones that 
> should be independent of the MSTP solution.

The mapping is from MIHF ID to actual IP address or vice versa.  The MSTP
user utilizes MIHF ID, instead of actual IP address , as a input parameter
to MSTP so that MSTP user can ignore MN's handover and keep MIH session
continuity. This is just PROPOSED internal implemenation dealing with
mobility and multihoming issues that MUST be specifed[See PS]. Any other
better solutions?

> First, the wording has to be improved. Secondly, I think that

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 19 Sep 2007 10:28:15 +0200

Subir,

I guess you attached the wrong version. Can you send the right one?

Tele

Subir Das wrote:
> and added the corresponding reference. Thanks to Gabor for pointing 
> this out!!
>>> Before submission would be interesting to get a brief review from 
>>> non DT-members. Do you think it is possible?
>>>

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 19 Sep 2007 10:33:03 +0200

Since this section seems to be controversial (as the 2nd paragraph for 
6.3) I would suggest to leave it out for the time being.
We can work on the text while posting -00 version and incorporate an 
enhanced version next time.
Also Sam, with all my respect, all the authors here provided good text, 
to be harmonized of course,
but each author took care of providing clear input. I have no problem in 
rewording your input
to fit it to the overall document, but I guess you first must provide a 
clear paragraph.
Could you do so?

Thanks
Tele

Sam Xia wrote:
>>>    [draft-gabor-dhcp] and [draft-gabor-dns] could be used 
>>>       
>> to transfer
>>     
>>> I do not know what did you intend to say with this, but it 
>>>       
>> has to be 
>>     
>>> network to the MN' is the 'discovery'. Also s1 and s2 
>>>       
>> should not just 
>>     
>>> figures. The steps need to be described and the figure 
>>>       
>> subtitle should 
>>     
>>> either a PTR query or a two step operation, where you first 
>>>       
>> find out 
>>     
>>> I think the conclusion of yesterday's AC was that if we can 
>>>       
>> not agree 
>>     
>>> on the 2nd paragraph of section 6.3, then we leave it out. 
>>>       
>> I think it 
>>     
>>> DNS should always be with capitals when it is not in 
>>>       
>> brackets [] Same 
>>     
>>> for DHCP
>>>
>>> There are two bullets in section 5.2, but the formatting is 
>>>       
>> not good.
>>     
>>> According to our action points from the AC only section 7 
>>>       
>> is missing.
>>     
>>> Also I'd like to acknowledge Patrick for the long 
>>>       
>> discussions we had 
>>

---

From: Telemaco Melia <[email-masked]>
Date: Wed, 19 Sep 2007 10:36:11 +0200

Stefano,

I guess as soon as I get the last input from Subir I can post the ID.
At the latest tomorrow should be available.

Tele

---

From: Sam Xia <[email-masked]>
Date: Wed, 19 Sep 2007 16:52:59 +0800

Gabor and Carlos,

I have modified the text and figure based on your comments. I hope that the
update will meet your requirement and clarify your confusion. If you have
better suggestion, please let me/Tele know.

/////////////////////////////////////
6.6.  Mobility and Multihoming

   When handover happens, maybe MN want to keep MIH session connection
   continuity.  In case that MN has several interfaces, maybe MN want
   to transfer an ongoing MIH session from one interface to the other.
   Just as [I-D.ietf-mipshop-mis-ps] described, MSTP should cope with
   mobility and multihoming Issues.  Because MIHF is used to facilitate
   handover and serves mobility management users(i.e.  SIP, Mobile IP
   etc.), it is reasonable for MSTP to cope with mobility and multihoming
   itself, instead of depending on the other mobility mechanisms.



           MN                                   MoS
  +---------------------+              +---------------------+
  |     MSTP User       |              |     MSTP User       |
  | +-----------------+ |              | +-----------------+ |
  | |    MIHF ID      +-+--------------+-+    MIHF ID      | |
  | +-----------------+ |              | +-----------------+ |
  | |    MAPPING      | |              | |    MAPPING      | |
  | +-----------------+ |              | +-----------------+ |
  | +-------+ +-------+ |              | +-------+ +-------+ |
  | | UDP   | |  TCP  | |              | |  TCP  | | UDP   | |
  | +---+---+ +---+---+ |              | +---+---+ +----+--+ |
  +-----+---------+-----+              +-----+----------+----+
        |         +--------------------------+          |
        |                                               |
        +-----------------------------------------------+

   Propsed method is to separeate MIHF ID from actual IP address just as
   depicted in Figure 10. In Figure 10, MSTP users mean the other parts of 
   MIHF except MSTP part, such as IS, ES and CS. MSTP users utilize MIHF
   ID to identify the peer MIHF and to establish MIH session. For actual
   underlying transport protocols(TCP and UDP), IP address is the only
   valid identity to identify the peer endpoint; there is a mapping function
   from MIHF ID to IP address and vice versa between MIHF ID layer and
actual
   underlying transport protocol layer, which is derived from dynamic
   MoS discovery procedure or pre-configuration. While handover or
multihoming
   transfer happens, TCP connection will be re-establihed and
source/destination
   for UDP will alter; but MIH session will keep continuity and survive the 
   IP address alteration event because MIH session is set up based on MIHF
ID
   which should be stable during the whole procedure.

   Because MSTP just provides transport service and MSTP users(ES, CS and
IS)
   ensure session consistency, no additional security issues are introduced 
   from MSTP framework for multihoming and mobility.

 Best Regards, Sam Xia

---

From: Sam Xia <[email-masked]>
Date: Wed, 19 Sep 2007 18:42:00 +0800

New update is available. The version should be better than before.

 Best Regards, Sam Xia 

  _____  

From: Telemaco Melia [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2007 4:33 PM
To: Sam Xia
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Version Thu 13th

Since this section seems to be controversial (as the 2nd paragraph for 6.3)
I would suggest to leave it out for the time being.
We can work on the text while posting -00 version and incorporate an
enhanced version next time.
Also Sam, with all my respect, all the authors here provided good text, to
be harmonized of course,
but each author took care of providing clear input. I have no problem in
rewording your input 
to fit it to the overall document, but I guess you first must provide a
clear paragraph.
Could you do so?

Thanks
Tele

Sam Xia wrote: 

  

Secondly, I think that 

  

- gabor 

-----Original Message-----

Guys,

Here it goes.

clarified the text.

I hope I corrected the major editorial issues. I also run a 

spell check. 

Sorry for the delay

Tele

Some more issues:

to transfer

has to be 

should not just 

subtitle should 

find out 

not agree 

I think it 

brackets [] Same 

for DHCP

not good.

Thanks.

- gabor

-----Original Message-----

Cc: Patrick Stupar

Guys,

is missing.

discussions we had 

Let me know

Tele

-- 

NEC Europe Ltd.

NEC Laboratories Europe

Network Division			

Kurfürsten-Anlage 36		

69115 Heidelberg

GERMANY	  

[email-masked]

    

-- 

NEC Europe Ltd.

NEC Laboratories Europe

Network Division			

Kurfürsten-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: Wed, 19 Sep 2007 14:54:37 -0400

Sorry, my bad. Here is it. Pl. check.

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC

Status of this Memo

Copyright Notice



Abstract

   To be edited.

Requirements Language

Table of Contents



1.  Introduction

2.  Terminology

   MN Mobile Node

   NN Network Node



3.  Deployment Scenarios

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/



    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

                                      +--------------+
                                      | HOME NETWORK |



4.  Solution Overview

4.1.  Architecture



                            Figure 5: MN stack

5.  MoS Discovery



   than home network.



                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+
                [email-masked]

                             (a) using DNS Query

                            +-----+      +------+
               +----+       |     |      |DHCP  |

                             (b)  Using DHCP Option



                         +-----+      +------+
            +----+       |     |      |DHCP  |

                           +-------+
            +----+         |Domain |
            | MN |-------->|Name   |
            +----+         |Server |
                           +-------+



                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |

          AAAv -- Visited AAA
          AAAH -- Home AAA



                                   +-------+
                    +----+         |DHCP   |
                    | MN |-------->|       |
                    +----+         |Server |
                                   +-------+
                     [email-masked]

                                 +-------+
                  +----+         |Domain |
                  | MN |-------->|Name   |
                  +----+         |Server |
                                 +-------+
                   [email-masked]

6.  MIH Transport



6.1.  MIH Message size

6.2.  MIH Message rate



6.3.  Retransmission

6.4.  NAT Traversal

6.5.  General guidelines



               MN                              MoS

7.  Operation Flows



                   MN                                             MoS



    |         |          |         |             |         |        |IS     |
    |         |          |         |             |         |        |QUERY  |
    |         |          |         |             |         |        |REQUEST|
    |         |          |         |             |         |        |======>|
    |         |          |         |             |         |        |       |
    |         |          |         |             |         |        |QUERY  |
    |         |          |         |             |         |        |RESPONSE
    |         |          |         |             |         |        |<======|
    |         |          |         |             |         |        |       |



   In case where unreliable transport protocol such as UDP is used for
   transport connection between two MIHF peers, DTLS [RFC 4347] should be 
   used for message confidentiality and data integrity. The DTLS protocol is
   based on the Transport Layer Security (TLS) protocol and provides
   equivalent security guarantees.

   Alternatively, generic IP layer security, such as IPSec [RFC2401] may be 
   used instead of a specific transport layer secuity for a specific transport. 

9.  IANA Considerations

10.  Acknowledgements

11.  References





   [RFC 4347] E. Rescorla, N. Modadugu, "Datagram Transport Layer Security
              (DTLS)", RFC 4347, April 2006

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Gabor Bajko
   Nokia



   Subir Das
   Telcordia

   Nada Golmie
   NIST

   Sam Xia
   Huawei

   Juan Carlos Zuniga
   InterDigital



Full Copyright Statement

Intellectual Property

Acknowledgment

---

From: Subir Das <[email-masked]>
Date: Wed, 19 Sep 2007 15:18:45 -0400

Sam,
Sorry for the delay. I went through the section proposed by you. I am 
sorry, I didn't
understand what is this mapping and why do we need it in this document?  
If the purpose of
keeping just a mapping between MIHFID and IP address that is kept in 
DNS. Are you considering
that MIHFID is changing during handover?  A use case  scenario may be 
helpful to understand.

regards,
-Subir

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 19 Sep 2007 15:46:35 -0400

The MIHFID won't change. If the MN wants to keep communication with the
old server, it can do so since it has previously discovered its IP
address. If it wants to connect to a new server, it can perform
discovery once more.
If it decides to keep connected to the old sever and the MN's address
changes, the server will still receive MIH packets with a known source
MIFHID, so it will know that it is the same old MN just with a new IP
address.

Jc

-----Original Message-----
From: Subir Das [mailto:[email-masked]] 
Sent: September 19, 2007 9:19 AM
To: Sam Xia
Cc: Zuniga, Juan Carlos; [email-masked];
[email-masked]

Sam,

If the purpose of

regards,
-Subir

---

From: Sam Xia <[email-masked]>
Date: Thu, 20 Sep 2007 08:36:35 +0800

> 
> The MIHFID won't change. If the MN wants to keep 
> communication with the old server, it can do so since it has 
> previously discovered its IP address. If it wants to connect 
> to a new server, it can perform discovery once more.
> If it decides to keep connected to the old sever and the MN's 
> address changes, the server will still receive MIH packets 
> with a known source MIFHID, so it will know that it is the 
> same old MN just with a new IP address.

Yes, thank Carlos. This is just what i want to say.   MIHF ID does not
change while handover or multihoming transfer. So MIH session based on MIHF
ID keep continuity even though IP address does changes. This idea just comes
from a lot of WGs in IETF, seperating Identity from locator.  :-)

And it seems that the seperation fits .21 draft, the primitive of network
transport.

> Sorry for the delay. I went through the section proposed by 
> you. I am sorry, I didn't understand what is this mapping and 
> why do we need it in this document?
> 
> If the purpose of
> keeping just a mapping between MIHFID and IP address that is 
> kept in DNS. Are you considering that MIHFID is changing 
> during handover?  A use case  scenario may be helpful to understand.
> 
> regards,
> -Subir
> 
> Sam Xia wrote:
> > Gabor and Carlos,
> >
> >    Propsed method is to separeate MIHF ID from actual IP 
> address just
> as
> >    IP address alteration event because MIH session is set 
> up based on
> MIHF
> > ID
> >    Because MSTP just provides transport service and MSTP 
> users(ES, CS
> and
> > IS)

---

From: Sam Xia <[email-masked]>
Date: Thu, 20 Sep 2007 08:52:15 +0800

> during handover?  A use case  scenario may be helpful to understand.

I gusess the text and figure in the new updated verion should be clear.   Do
you understand what i mean, subir?  If not, i can add a use case even i
think the new text should be clear.  Everyone caring about new internet
architecture in ietf knows the idea sperating id from locator.