Subject: Re: [Mipshop] WG last call on MIH solution document (draft-ietf-mipshop-mstp-solution-01.txt)

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 2 Mar 2008 22:39:23 -0500

Here is my review.

----------------------------------------------------------

2.  Terminology

   The following acronyms and terminology are used in this document:

   MIH  Media Independent Handover: the handover support architecture
      defined by the IEEE 802.21 working group that consists of the MIH
      Function (MIHF), MIH Network Entities, MIH Event messages, and MIH
      command messages.

[YO] MIH Information Service messages are missing here.  Suggested change:

"
   MIH  Media Independent Handover: the handover support architecture
      defined by the IEEE 802.21 working group that consists of the MIH
      Function (MIHF), MIH Network Entities and MIH protocol messages.
"

   MIHF  Media Independent Handover Function: a cross-layer function
      that provides handover services including the Event Service (ES),
      Information Service (IS), and Command Service (CS), through
      service access points (SAPs) defined by the IEEE 802.21 working
      group.

[YO] s/defined by the IEEE 802.21 working group/defined by IEEE 802.21
[IEEE80221]/.

   MIHF User  an MIH client that uses the MIH SAPs to access MIHF
      services, and which is responsible for initiating and terminating
      MIH signaling

[YO] The term "MIH client" is not defined.  Suggested change: s/an MIH
client/an entity/.  Also, the above sentence is not complete.

   MN Mobile Node: an Internet device whose location changes, along with
      its point of connection to the network.

   NN Network Node: an Internet device whose location and network point
      of attachment do not change

[YO] This term is unused in this document and should be removed.

   MSTP  Mobility Services Transport Protocol: a protocol that is used
      to deliver MIH signaling messages from an MIHF to other MIH-aware
      nodes in a network.

[YO] s/MIH signaling messages/MIH protocol messages/, throughout the
document.

   IS Information Service: a MoS that originates at the lower or upper
      layers and sends information to the local or remote upper or lower
      layers.  It can use secure or insecure ports to transport
      information elements (IEs) and information about various
      neighboring nodes.  Its architecture is outside the scope of the
      IEEE 802.21 draft document.

[YO] I am not sure this description is aligned with the description in
IEEE 802.21 specification.  This may need to be revised.  I have the
same comment for ES and CS.

   ES Event Service: a MoS that originates at a remote MIHF or the lower
      layers and sends information to the local MIHF or local higher
      layers.  The purpose of the ES is to report changes in link status
      (e.g.  Link Going Down messages) and transmission status.

   CS Command Service: a MoS that sends commands from the remote MIHF or
      local upper layers to the local lower layers to switch links or to
      get link status.

   FQDN  Fully-Qualified Domain Name: a complete domain name for a host
      on the Internet, consisting of a host name followed by a domain
      name (e.g. hostname.domain.org)

[YO] Incomplete sentense.

   NAI  Network Access Identifier: the user ID that a user submits
      during PPP authentication.  For mobile users, the NAI identifies
      the user and helps to route the authentication request message.

   NAT  Network Address Translator: A device that implements the Network
      Address Translation function described in [RFC3022], in which
      local or private network layer addresses are mapped to valid
      network addresses and port numbers.

   DHCP  Dynamic Host Configuration Protocol: a protocol described in
      [RFC2131] that allows Internet devices to obtain IP addresses,
      subnet masks, default gateway addresses, and other IP
      configuration information from DHCP servers.

   DNS  Domain Name System: a protocol described in [RFC1035] that
      translates domain names to IP addresses.

   AAA  Authentication, Authorization and Accounting: a set of network
      management services that respectively determine the validity of a
      user's ID, determine whether a user is allowed to use network
      resources, and track users' use of network resources.

   AAA home  AAA server: an AAA server located on the MN's home network

[YO] s/AAA home  AAA server/Home AAA (AAAh)/.

   AAA visited  AAA server: an AAA server located a visited network that
      is not the MN's home network

[YO] s/AAA visited  AAA server/Visited AAA (AAAv)/.
[YO] Incomplete sentence.

   MIH ACK  MIH Acknowledgement Message: a MIH signaling message that a
      MIHF sends in response to an MIH message from a sending MIHF, when
      UDP is used as the MSTP.

   PoS  Point of Service, a network-side MIHF instance that exchanges
      MIH messages with a MN-based MIHF

[YO] Incomplete sentence.

   NAS  Network Access Server: a server to which a MN initially connects
      when it is trying to gain a connection to a network and which
      determines whether the MN is allowed to connect to the NAS's
      network

[YO] Incomplete sentence.

   UDP  Network Access Server: a server to which a MN initially connects
      when it is trying to gain a connection to a network and which
      determines whether the MN is allowed to connect to the NAS's
      network

[YO] Incomplete sentence.

   TCP  Transmission Control Protocol: a stream-oriented transport layer
      protocol that provides a reliable delivery service with congestion
      control, defined in RFC 793.

   RTT  Round-Trip Time: a estimation of the time required for a segment
      to travel from a source to a destination and an acknowledgement to
      return to the source that is used by TCP in connection with timer
      expirations to determine when a segment is considered lost and
      should be resent.

[YO] s/a estimation/an estimation/.  

   MTU  Maximum Transmission Unit: the largest size packet that can be
      sent on a network without requiring fragmentation [RFC1191].

   TLS  Transport Layer Security Protocol: an application layer protocol
      that assures privacy and data integrity between two communicating
      network entities [RFC4346].

3.  Deployment Scenarios

   This section describes the various possible deployment scenarios for
   the MN and the MoS.  The relative positioning of MN and MoS affects
   resource discovery as well as the performance of the MIH signaling
   service.

[YO] s/resource discovery/MoS discovery/.  
     s/MIH signaling service/MIH services/.

3.1.  Scenario S1: Home Network MoS

   In this scenario, the MN and the services are located in the home
   network.  We refer to this set of services as MoSh as in Figure 1.
   The MoSh can be located at the access point the MN uses to connect to
   the home network, or it can be located elsewhere.

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

                     Figure 1: MoS in the Home network

3.2.  Scenario S2: Visited Network MoS

   In this scenario, the MN is in the visited network and mobility
   services are provided by the visited network.  We refer to this as
   MoSv as shown in Figure 2.

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

                   Figure 2: MoSV in the Visited Network

3.3.  Scenario S3: Roaming MoS

   In this scenario, the MN is located in the visited network and all
   MIH services are provided by the home network, as shown in Figure 3.

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

            Figure 3: MoS provided by the home while in visited

3.4.  Scenario S4: Third party MoS

   In this scenario, the MN is in its home network or in a visited
   network and services are provided by a 3rd party network.  We refer
   to this situation as MoS3 as shown in Figure 4.  (Note that MoS can
   exist both in hom enad in visited).

[YO] s/hom enad/home and/.

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

                    Figure 4: MoS form a third party

   Different types of MoS can be provided independently of other types
   and there is no strict relationship between ES, CS and IS, nor is
   there a requirement that the entities that provide these types be co-
   located.  However, while IS tends to involve large amounts of static
   information, ES and CS are dynamic services and some relationship
   between them can be expected, e.g. a handover command (CS) could be
   issued upon reception of a link event (ES).  Hence, while in theory
   MoS can be implemented in different locations, it is expected that ES
   and CS will be co-located, whereas IS can be co-located with ES/CS or
   located elsewhere.  Therefore, having the flexibility at the MSTP to
   discover different services in different locations is an important
   feature that can be used to optimize handover performance.  Resource
   discovery is discussed in more detail in Section 5.

[YO] s/Resource discovery/MoS discovery/.

4.  Solution Overview

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

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

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.

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

   o  MoS discovery can be performed during initial network attachment
      or thereafter.

   The MN could know or not the realm of the MoS to be discovered.  In
   any case after the acquisition of the target realm (e.g. via
   Information Server or statically configured) the MN could either be
   pre-configured with the address of the MoS, or this address could be
   obtained through DHCP or DNS.  The dynamic assignation methods are
   described in 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.

   Once the MIHF peer has been discovered, MIH information can be
   exchanged between MIH peers over a trasnport protocol such as UDP or

[YO] s/trasnport/transport/.

   TCP.  The usage of transport protocols is described in Section 6.

4.1.  Architecture

   Figure 5 depicts the MSTP reference model and its components within a
   node.  The topmost layer is the MIHF user.  This set of applications
   consists of one or more MIH clients that are responsible for such
   operations as maintaining MIH databases associated with the IS,
   processing Layer 2 triggers as part of the ES, and initiating and
   carrying out handover operations as part of the CS.  Beneath the MIHF
   user set is the MIHF itself.  This function is responsible for MoS
   discovery, as well as creating, maintaining, modifying, and
   destroying MIH signaling associations with other MIHFs located in MIH
   peer nodes.  Below the MIHF are various transport layer protocols as
   well as address resolution functions.

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

                            Figure 5: MN stack

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

   The above reference architecture however does not include other
   services such as message fragmentation and security.  Depending upon
   the MIH service type (e.g., ES, CS and IS) the message size can be
   very large.  In case where the underlying layers do not support
   fragmentation, this may be an issue.  There are no security features
   currently defined as part of the MIH protocol level.  However,
   security can be provided either at the transport or IP layer where it
   is necessary.  Section 8 provides some guidelines and recommendations
   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 where 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
   [RFC4282].  An MIHFID can be pre-configured or discovered through the
   discovery methods described in Section 5.

5.  MoS Discovery

   The MoS discovery method depends on whether the MN attempts to
   discover an MoS in the home network, in the visited network, or in a
   3rd party remote network that is neither the home network nor the
   visited network.

   In case MoS is provided locally (scenarios S1 and S2) , the discovery
   techniques described in [I-D.bajko-mos-dhcp-options] and
   [I-D.bajko-mos-dns-discovery] are both applicable and either one MAY
   be used to discover the MoS.

   In case MoS is provided in the home network while the MN is in the
   visited network (scenario S3), the DNS based discovery described in
   [I-D.bajko-mos-dns-discovery] is applicable, while the DHCP based
   discovery method would require an interaction between the DHCP and
   the AAA infrastructure, similarly to what specified in
   [I-D.ietf-mip6-bootstrapping-integrated-dhc] .  This latter case
   assumes that MoS assignment is performed during access authentication
   and authorization.

   In case MoS is provided in a remote network other than visited or
   home network (scenario S4), only the DNS based discovery method
   described in [I-D.bajko-mos-dns-discovery] is applicable.

5.1.  MoS Discovery when MN and MoSh are in the home network (Scenario
      S1)

   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 mechanism, 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).  The DNS query option is shown in Figure 6b.

[YO] s/Figure 6b/Figure 6a/.

   Alternatively, the MN MAY use the DHCP options for MoS
   discovery[I-D.bajko-mos-dhcp-options] as shown inFigure 6a.

[YO] s/Figure 6a/Figure 6b/.

                              +-------+
               +----+         |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 when MIN is in visited network and MoSv is also in
      visited network (Scenario S2)

[YO] s/MIN/MN/.

   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]
   as shown in Figure 7a.  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] as shown in Figure 7b.  In order to

[YO] Remove one '['.

   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].  A 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
      visited network.  Note, that when a NAT device exists between the
      MN and the visited 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 has determined the external IP
      address of the NAT device, it MUST use that address in the reverse
      DNS query.

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

                   (a) MOS Discovery using DHCP options

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

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

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

   It should be noted, that the usage of DHCP options to discover an MoS
   in this particular scenario is recommended because of its simplicity
   over the DNS based discovery method: the DNS discovery method
   requires the MN to learn the domain name of the local network first,
   possibly using DHCP, and then perform the DNS query.  The usage of
   the DHCP based discovery method does not require any additional
   procedure.

5.3.  MOS Discovery when the MN is in a visited Network and Services are
      at the Home network (Scenario S3)

   To discover an MoS in the visited network when MIH services are
   provided by the home network, both the DNS based discovery method
   described in [I-D.bajko-mos-dns-discovery] and the DHCP based
   discovery method described in [I-D.bajko-mos-dhcp-options] are
   applicable.

   To discover the MoS at home while in a visited network using DNS, the
   MN SHOULD use the procedures described in section Section 5.1

   Alternatively, the MN MAY also use the DHCP based discovery method.
   Using the DHCP based discovery may be required in deployments where
   the usage of MoS located in the home network is enforced and included
   in the subscription profile.  Similarly to
   [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated
   scenario the mobile node is required to perform network access
   authentication before it can bootstrap MoS information.  This allows
   for MoS discovery at the time of access authentication and
   authorization.  Also, the mechanism defined in this document requires
   the NAS to support MIH specific AAA attributes and a collocated DHCP
   relay agent.  In order to provide the mobile node with information
   about the assigned MoS, the AAAh conveys the assigned MoS's
   information to the NAS via AAA protocol similarly to
   [I-D.ietf-dime-mip6-integrated] and described in [REF TO NEW DOC].

   In these deployment scenarios the AAAh sends the MoS address at home
   to the AAAv during the network access authentication.  The relation
   beween functional components supporting such procedure is shown in
   Figure 8.

   The mobile node executes the network access authentication procedure
   (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS.  The NAS
   is in the visited and it interacts with the AAAh to authenticate the
   mobile node.  In the process of authorizing the mobile node, the AAAh
   verifies in the AAA profile that the mobile node is allowed to use
   MoS services.  The AAAh assigns the MoS in the home and returns this
   information to the NAS.  The NAS may keep the received information
   for a configurable duration or it may keep the information for as
   long as the MN is connected to the NAS.

   The mobile node sends a DHCPv6 Information Request message [RFC3315]
   to the All_DHCP_Relay_Agents_and_Servers multicast address.  In this
   message the mobile node (DHCP client) MUST include the Option Code
   for MoS Identifier Option [I-D.bajko-mos-dhcp-options] in the
   OPTION_ORO.  The mobile node MUST also include the OPTION_CLIENTID to
   identify itself to the DHCP server.

   The Relay Agent intercepts the Information-request from the mobile
   node and forwards it to the DHCP server.  The Relay Agent also
   includes the received MoS information from the AAAh in the IPv6 Relay
   Agent MoS Option [I-D.bajko-mos-dhcp-options].  If a NAS
   implementation does not store the received information as long as the
   MN's session remains in the visited, and if the MN delays sending
   DHCP request, the NAS/DHCP relay does not include the IPv6 Relay
   Agent MoS Option in the Relay Forward message.

   The DHCP server identifies the client by looking at the DUID for the
   client in the OPTION_CLIENTID.  The DHCP server determines that the
   home agent is allocated by the AAAh by looking at the IPv6 Relay
   Agent Sub-Option in the IPv6 Relay Agent MoS Option.  The DHCP server
   extracts the allocated home agent information from the IPv6 Relay
   Agent Sub-Option and includes it in the MoS Information Option
   [I-D.bajko-mos-dhcp-options] in the Reply Message.  If the requested
   information is not available in the DHCP server, it follows the
   behavior described in [RFC3315].

   The Relay Agent relays the Reply Message from the DHCP server to the
   mobile node.  At this point, the mobile node has the MoS information
   that it requested.

   In should be noted, that using the DHCP Options and procedures
   defined in [I-D.bajko-mos-dhcp-options] the MN can not specify the
   network (local or home) where it wants the MoS address from.  Whether
   the MN receives an MoS address from local or home network will depend
   on the actual network deployment (scenario S2 or S3).  In an
   integrated scenario, where the network access authentication is
   performed by the home network the MoS information will anyway be sent
   to the AAAV, then stored in the relay agent and ultimately sent to
   the MN if the MN asks for it, using the procedures defined in
   [I-D.bajko-mos-dhcp-options].

                           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 when MIH services are in a 3rd party remote network
      (scenario S4)

   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].  The MN MUST first learn the domain
   name of the network containing the MoS it is searching for.  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 MUST use DNS queries to find MoS in the
   remote network as inFigure 9 part(c).  It should be noted that step c

[YO] a/inFigure/in Figure/.

   can only be performed upon obtaining the domain name of the remote
   network.

                                   +-------+
                    +----+         |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) DHCP Options, (b) IS Query to a
                        known Server, (c) DNS Query

6.  MIH Transport Options

   Once the Mobility Services have been discovered, MIH peers MAY
   exchange information over TCP, UDP or any other transport supported
   by both the server and client, as described in
   [I-D.rahman-mipshop-mih-transport].  The client MAY use the DNS
   discovery mechanism to discover which transport protocols are
   supported by the server in addition to TCP and UDP.  While either
   protocol can provide the basic transport functionality required,
   there are performance trade-offs and unique characteristics
   associated with each that need to be considered in the context of the
   MIH services for different network loss and congestion conditions.
   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 MIH ACKs with TCP since TCP includes
   acknowledgement and retransmission functionality

[YO] The last sentence is incomplete.

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 [IEEE80221].

[YO] s/to100/to 100/.

   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, if MIH is 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.  Note also that TCP is a stream
   oriented protocol and measures data flow in terms of bytes, not
   messages.  Thus it is possible to split messages across multiple TCP
   segments if they are long enough.  Even short messages can be split
   across two segments.  This can also cause unacceptable delays,
   especially if the link quality is severely degraded as is likely to
   happen when the MN is exiting a wireless access coverage area.

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 parameters of a token
   bucket regulator as defined in the MIH specifications [IEEE80221].
   Recommendations for tocken bucket 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
   delay associated with retransmission timeouts may increase
   significantly with increased packet loss.

   If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.

[YO] Just a note that in the comment resolution of 802.21 Sponsor
Ballot recirculation #2, use of MIH ACK is becoming mandatory when
unreliable MIH transport protocol such as UDP is used.

   An MIH message is retransmitted if its corresponding MIH ACK is not
   received by the generating node within a timeout interval set by the
   MIHF.  This approach does not include an exponential backoff and
   therefore tends to degrade more gracefully than TCP when the packet
   loss rate becomes large, in the sense that the expected delay does
   not increase exponentially.  The number of retransmissions is
   limited, which reduces head-of-line blocking of other MIH messages,
   but this can cause important ES/CS messages to be lost.

   Additionally, instead of retransmitting an unacknowledged message,
   the MIH may choose to update the information and transmit a new
   message.

[YO] I am not sure if this additional behavior is described in IEEE
802.21 specification.

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

[YO] s/MoS/PoS/.

   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, TCP or other supported
   transport MUST use the default port number defined for that
   particular transport..

[YO] Remove one '.'.

   MOS server MUST support both UDP and TCP for MIH transport and the MN
   MUST support TCP.  Additionally, the server and MN MAY support
   additional transport mechanisms.  The MN MAY use the procedures
   defined in [I-D.bajko-mos-dns-discovery] to discover additional
   transport protocols supported by the server.

[YO] s/MOS server/A PoS/. 
     s/the server/the PoS/.

[YO] I am not sure if the requirements in the first and second
paragraphs are consistent. The first paragraph says UDP is a SHOULD
for ES/CS and TCP is a SHOULD for IS, while the second paragraph says
UDP and TCP are a MUST for MOS server and TCP is a MUST for MN.  So
which transport MN should actually use for ES/CS, TCP or UDP?  If MN
uses TCP, then it is not recommended in the first paragraph.  If MN
uses UDP, then the use of UDP is not mandated or recommended in the
second paragraph.

[YO] Which transport should be used for Service Management messages
such as MIH_Capability_Discover request/response, MIH_(De)Register
request/response and MIH_Event_(Un)Subscribe request/response
messages?

7.  Operation Flows

   Figure 10 gives an example operation flow between MIHF peers when an
   MIH user requests for an IS service.  Scenario 1 is in effect, i.e.
   the MoS and the MN are both in the MN's home network.  Thus DHCP is
   used for MoS discovery and TCP is used for establishing a transport
   connection to carry the IS messages.  When MOS is not pre-configured,
   the MIH user needs to discover the IP address of MOS to communicate
   with the remote MIHF.  Therefore the MIH user sends a discovery
   request message to the local MIHF as defined in [IEEE80221]

[YO] s/the MOS/the PoS for the MoS/ in the above paragraph.

   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
   option as defined 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.

[YO] s/IP address of the MOS/IP address of the PoS for the MoS/ in the
above paragraph.

     s/The MOS address/The IP address of the PoS/.

   MIHF generates the discovery response message and passes it on to the
   corresponding MIH user.  The MIH user generates an IS query addressed
   to the remote MoS.  MIHF invokes the underlying TCP client which
   establishes a transport connection with the remote peer.  Once the
   transport connection is established, MIHF sends the IS query via MIH
   protocol REQUEST message.  The message and query arrive at the
   destination MIHF and MIH user respectively.  The MoS MIH user
   responds to the corresponding IS query and the MoS MIHF sends the IS
   response via MIH protocol RESPONSE message.  The message arrives to
   the source MIHF which passes the IS response on to the corresponding
   MIH user.

                MN                                             MoS

[YO] s/MoS/PoS/.

|====================================|    |======|   |===================|
 + ---------+                                                 + ---------+
 | MIH USER |       +------+  +------+    +------+   +------+ | MIH USER |
 | +------+ |       | TCP  |  |DHCP  |    |DHCP  |   | TCP  | | +------+ |
 | | MIHF | |       |Client|  |Client|    |Server|   |Server| | | MIHF | |
 +----------+       +------+  +------+    +------+   +------+ +----------+
     |                 |         |           |          |          |
     |MIH Discovery    |         |           |          |          |
     |Request          |         |           |          |          |

[YO] s/MIH Discovery Request/MIH_Capability_Discover.request/.

     |(MIH User-> MIHF)|         |           |          |          |
     |======>          |         |           |          |          |
     |                 |         |           |          |          |
     |Invoke DHCP Client         |           |          |          |
     |(Internal process with MoS)|DHCP INFORM|          |          |
     |==========================>|==========>|          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |  DHCP ACK |          |          |
     |                 |         |<==========|          |          |

[YO] This invocation of DHCP INFORM needs to happen before
MIH_Capability_Discover.request because MIH User on the MN needs to
know the MIHF-ID of the PoS to issue an
MIH_Capability_Discover.request remote primitive.  Also, an
MIH_Capability_Discover request message needs to be generated and sent
to the PoS as a consequence.

     |    Inform MoS address     |           |          |          |
     |<==========================|           |          |          |
     |    (internal process)     |           |          |          |

[YO] s/MoS address/PoS address/.

     |                           |           |          |          |
     |Discovery        |         |           |          |          |
     |Response         |         |           |          |          |
     |<======          |         |           |          |          |
     |(MIH User<- MIHF)|         |           |          |          |
     |                 |         |           |          |          |
     |IS Query         |         |           |          |          |
     |=======>         |         |           |          |          |
     |(MIH User-> MIHF)|         |           |          |          |
     |                 |         |           |          |          |
     |Invoke TCP Client|         |           |          |          |
     |================>|         |           |          |          |
     |(Internal process|         |           |          |          |
     |with MOS)        |         |           |          |          |
     |                 |         |           |          |          |
     |                 |  TCP connection established    |          |
     |                 |<==============================>|          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 IS  QUERY REQUEST (via MIH protocol)        |
     |============================================================>|
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |          |
     |                 |         |           |          |  IS QUERY|
     |                 |         |           |          |   REQUEST|
     |                 |         |           |          |=========>|
     |                 |         |           |    (MIHF-> MIH User)|
     |                 |         |           |          |          |
     |                 |         |           |          |     QUERY|
     |                 |         |           |          |  RESPONSE|
     |                 |         |           |          |   <======|
     |                 |         |           |  |(MIHF <-MIH User) |
     |                 |         |           |          |          |
     |                 | IS QUERY RESPONSE (via MIH protoco        |
     |<============================================================|
     |                 |         |           |          |          |
     |    IS           |         |           |          |          |
     |RESPONSE         |         |           |          |          |
     |<========        |         |           |          |          |
     |(MIH User <-MIHF)|         |           |          |          |
     |                 |         |           |          |          |

          Figure 10: Example Flow of Operation Involving MIH User

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], where available or rely
   upon link layer security.  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
   proper handover, respectively.  Where networks are exposed to such
   DoS, it is recommended that DNS service providers use the Domain Name

[YO] Is this a RECOMMENDED or recommended?

   System Security Extensions (DNSSEC) as described in [RFC4033].
   Readers may also refer to [RFC4641] 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

[YO] Is this a SHOULD or should?

   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, DTLS [RFC4347] should be

[YO] Is this a SHOULD or should?

   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

[YO] Is this a MAY or may?

   be used where neither transport layer security for a specific >

[YO] Remove '>'.

   transport is available nor server only authentication is required.

----------------------------------------------------------

Best Regards,
Yoshihiro Ohba

On Wed, Feb 13, 2008 at 03:36:55PM -0800, Vijay Devarapalli wrote:
> Hello folks,
> 
> This is to announce a working group last call for the MIH
> solution document (draft-ietf-mipshop-mstp-solution). You
> can find the document at the following URL.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-01.txt
> 
> The last call expires on March 5 2008. (Its a three week
> last call because of Internet Draft submission deadlines
> on the 18th and 25th).
> 
> The intended status for this document is Standards Track.
> 
> Please post any issues or comments on this document to the
> MIPSHOP WG mailing list. In case you have reviewed the
> document and found no issues, please send an email saying
> you support advancing this document.
> 
> Vijay
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/mipshop
> 
> 
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Noll, Kevin" <[email-masked]>
Date: Mon, 3 Mar 2008 13:22:59 -0500

Comments inline... 

--
Kevin A. Noll, CCIE
Sr. Wireless Engineer
Time Warner Cable
13241 Woodland Park
Herndon, VA 20171
o: +1-703-345-3666
m: +1-717-579-4738
AIM: knollpoi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 29, 2008 6:31 PM
To: Noll, Kevin; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] [Mipshop] WG last call on MIHsolution
document(draft-ietf-mipshop-mstp-solution-01.txt)

Hello Kevin,

Thanks for your comments. Since I wrote most of section 5, I try to
address your comments to that section: 

-- snip --

I also skip the editorial comments, I will correct the text as you
suggested.

>> 7. Sect. 5 para. 4 - clarify
>> "In case MoS is provided in a remote network other than visited or 
>> home network (scenario S4)" might be better stated as "In the case 
>> that MoS is provided by a third-party network (scenario S4)"

Ok, I'll change the sentence to "In case MoS is provided by a
third-party network, which is different from the current visited
network, ..."

[KAN] I think this is still redundant. If your MoS is provided by a
third party network, then by definition it *is* different than the
current visited network.
However, it seems that it could be highly likely that the MN might roam
from (for example) the current visited network to a new visited network
and have the MoS remain in the old visited network. This scenario would
fit your proposed statement.

>> 9. Sect. 5.1 para. 1 - technical
>> I'm not sure I agree with the statement that "Home domains are 
>> usually pre-configured in the MN". On what basis is this assumption 
>> made? Even if it is a correct assumption, shouldn't there be a 
>> provision for the scenario where the MN does *NOT* have the home
domain pre-configured?

If the home domain is not preconfigured, how would the MN find it out?
The subscription is tight to a network, which is the home. If there is
no home network, there is no subscription.

[KAN] I asked myself the same question. I know that some information
about the home network must be pre-configured on the device in order to
seed the whole bootstrapping process. This is where my experience falls
short, so I'll ask - what is a typical MN pre-configured with today? I'm
sure the answer is different for each type of network that you might
connect to.

>> 13. Sect. 5.2 para. 3 and 4 - technical Perhaps the authors can 
>> clarify what the expected result of the reverse DNS query should be.
>> It seems to me that it would not be uncommon for the reverse query 
>> (if it doesn't fail altogether) to return a domain name that is not 
>> the same as the desired MoS realm name. For example, what if the 
>> reverse query returns something like 
>> node1234.dulles.va.myprovider.net, but the MoS realm should be 
>> myprovider.net? Should the MN attempt to contact the MoS based on the

>> returned domain name and remove portions of the domain name 
>> iteratively until it successfully finds an MoS?

I don't know the answer to this question. I need to investigate how
other specs handle this or implementations deal with it. 

[KAN] I've seen several different solutions to this ranging from the
"iterative" approach - which places the burden on the MN to do the
iterations and queries - to the total opposite approach requiring that
the the SP provide an SRV record for all of the possible domains or
"realms". There is a middle ground using DHCP, but I think that might
defeat the purpose of this particular section of the draft.

>> 16. Sect 5.3 para 4 - technical
>> What is the document references by "[REF TO NEW DOC]"?

It is a new I.D, which was submitted last week. We need to put the name
of that I.D there (draft-stupar-mos-diameter-options).

>> 18. Sect 5.3 - technical
>> This discovery method seems to assume the use of IPv6 and DHCPv6, but

>> does not state that assumption anywhere that I can find. Even if this

>> is the correct assumption, what happens if only IPv4 and DHCPv4 are 
>> available to the MN?

I-D.bajko-mos-dhcp-options defines extensions to discover MoS only in
visited network for the dhcpv4 case. If the MN is using MIPv4, then the
bootstrapping can happen using AAA. If the MN is only using dhcpv4, then
according to the current status of the work, it can only discover an MoS
in the visited network. To support MoS discovery in the home network
while roaming, using dhcpv4, we would need additional work (define a few
additional dhcpv4 extensions). The question is, do we have or foresee a
deployment scenario which would require this? 

[KAN] I understand the reasoning, and Nada and Subir clarified that
there is an assumption of IPv6 here. However, I think it would be
helpful to have that stated and possibly reference the I-D for IPv4.
With respect to forseeing deployment on IPv4 network... I think it's
highly probable, but that's my own opinion.

>> 19. Sect. 5.4 - technical
>> Why can the MoS domain name not be pre-configured?

It can, but all 3rd party domain names cannot be preconfigured, it is
not feasible. I will clarify the text.

>> 21. Sect. 5.4 - technical
>> Would an alternative method of discovering the third party MoS be 
>> similar to that described in sect. 5.3 where the AAAh and/or AAAv are

>> able to return the third party MoS information?

Well, what the MN discovers using the procedures in section 5.3 is an
MoS address provided to the MN by the home network. That MoS may
virtually be anywhere (in visited, in home, in a preconfigured 3rd
party), but it is provided to the MN as per the policy in the
subscription. In section 5.4 we define a scenario when the MN does want
an MoS address from a specific 3rd party (maybe in addition of the home
MoS).

[KAN] Hmmm.... it seems like policy would dictate whether the MN uses
home-based or other MoS, but I suppose policy could be defined by the
service provider or the MN, and resolving which takes precedence is
probably beyond the scope of this draft.

Thanks for the good catches.
- gabor

[KAN] You're welcome! Glad to be involved and provide whatever help I
can.
This E-mail and any of its attachments may contain Time Warner
Cable proprietary information, which is privileged, confidential,
or subject to copyright belonging to Time Warner Cable. This E-mail
is intended solely for the use of the individual or entity to which
it is addressed. If you are not the intended recipient of this
E-mail, you are hereby notified that any dissemination,
distribution, copying, or action taken in relation to the contents
of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify
the sender immediately and permanently delete the original and any
copy of this E-mail and any printout.

---

From: <[email-masked]>
Date: Wed, 5 Mar 2008 16:15:59 -0600

Hello Yoshi,

Some answers inline:

<Gabor> it is not, and even if it was, this description shouldn't be in
this document. I already asked this to be removed, hopefully the
sentence won't be there in the next version.

6.5.  General guidelines

[YO] Remove one '.'.

[YO] I am not sure if the requirements in the first and second
paragraphs are consistent. The first paragraph says UDP is a SHOULD for
ES/CS and TCP is a SHOULD for IS, while the second paragraph says UDP
and TCP are a MUST for MOS server and TCP is a MUST for MN.  So which
transport MN should actually use for ES/CS, TCP or UDP?  If MN uses TCP,
then it is not recommended in the first paragraph.  If MN uses UDP, then
the use of UDP is not mandated or recommended in the second paragraph.

<Gabor> this is the result of a compromise. We could say instead of
"...and the MN MUST support TCP..." "the MN MUST support at least TCP".
Then, if the MN only supports TCP, then there is a good reason not to
follow the recommandation in the first paragraph (i.e. UDP in
combination with MIH acknowledgement SHOULD be used for transporting ES
and CS messages).

- gabor

[YO] Which transport should be used for Service Management messages such
as MIH_Capability_Discover request/response, MIH_(De)Register
request/response and MIH_Event_(Un)Subscribe request/response messages?

On Wed, Feb 13, 2008 at 03:36:55PM -0800, Vijay Devarapalli wrote:
> Hello folks,
> 
> This is to announce a working group last call for the MIH solution 
> document (draft-ietf-mipshop-mstp-solution). You can find the document

> at the following URL.
> The last call expires on March 5 2008. (Its a three week last call 
> because of Internet Draft submission deadlines on the 18th and 25th).
> 
> Please post any issues or comments on this document to the MIPSHOP WG 
> mailing list. In case you have reviewed the document and found no 
> issues, please send an email saying you support advancing this 
> document.
> 
> Vijay

---

From: Ashutosh Dutta <[email-masked]>
Date: Wed, 05 Mar 2008 23:24:24 -0500

Vijay,
       I think Yoshi and Kevin have given some useful comments and 
covered most of it, here are some of mine that start with AD>

Regards
Ashutosh

1.  Introduction

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

    The MIH Layer 3 transport problem is divided in two main parts: the
    discovery of a node that supports specific Mobility Services (MoS)
    and the transport of the information between a mobile node (MN) and
    the discovered node.  The discovery process is required for the MN to
    obtain the information needed for MIH protocol communication with a
    peer node.  The information includes the transport address (e.g., the
    IP address) of the peer node and the types of MoS provided by the
    peer node.

    This document lists the major MoS deployment scenarios.  It next
    describes the solution architecture, including the MSTP reference
    model and MIHF identifiers.  A description follows of MoS discovery
    procedures when the MN is in a home or remote network.

    AD> Sentence structure above is not correct.

    The remainder
    of the document describes the MIH transport architecture, example
    message flows for several signaling scenarios, and security issues.

    AD> What is meant by signaling scenarios here?

2.  Terminology

  AD> What is the definition of MIH entities above, we also need to 
mention Information Service Messages.

AD> Do we need to say cross-layer function here. Instead cannot we just
say logical function or just function?

    MIHFID  Media Independent Handover Function Identifier: an identifier
       required to uniquely identify the MIHF endpoints for delivering
       mobility services (MoS); it is implemented as either a FQDN or
       NAI.

Melia, et al.            Expires August 15, 2008                [Page 4]

Internet-Draft                    MSFD                     February 2008

    MoS  Mobility Services: those services, as defined in the MIH problem
       statement document [I-D.ietf-mipshop-mis-ps] , which include the
       MIH IS, CS, and ES services defined by the IEEE 802.21 standard.

    MoSh  Mobility Services assigned in the mobile node's Home Network

    MoSv  Mobility Services assigned in the Visited Network, which is any
       network other than the mobile node's home network

    MoS3  Mobility Services assigned in a 3rd Party Network, which is a
       network that is neither the Home Network nor the current Visited
       Network.

AD> Add protocol stack after lower or upper layers (e.g., lower or upper 
layers of a protocol stack)

AD> change lower layers to (lower layers of protocol stack) unless it is 
implicit

Melia, et al.            Expires August 15, 2008                [Page 5]

Internet-Draft                    MSFD                     February 2008

AD> The sentence is ambiguous, should be AAAH Home AAA server

AD> The sentence is ambiguous, suggested change AAAV Visited AAA Server

AD> Is it a standard IETF definition, if not can we improve the definition?

AD> The definition does not sounds correct, seems like repetition of the 
previous sentence

Melia, et al.            Expires August 15, 2008                [Page 6]

Internet-Draft                    MSFD                     February 2008

       should be resent.

3.  Deployment Scenarios

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

AD> Please change "Access Point" above to "Access Network"

Melia, et al.            Expires August 15, 2008                [Page 7]

Internet-Draft                    MSFD                     February 2008

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

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

AD> Typo "both in home and in visited"

Melia, et al.            Expires August 15, 2008                [Page 8]

Internet-Draft                    MSFD                     February 2008

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

4.  Solution Overview

Melia, et al.            Expires August 15, 2008                [Page 9]

Internet-Draft                    MSFD                     February 2008

    The MN could know or not the realm of the MoS to be discovered.

AD> MN may or may not know

  In

4.1.  Architecture

AD> suggested change, for operations such as generating query and response

    processing Layer 2 triggers as part of the ES, and initiating and
    carrying out handover operations as part of the CS.  Beneath the MIHF
    user set is the MIHF itself.

AD> Above sentence is not very clear

   This function is responsible for MoS

Melia, et al.            Expires August 15, 2008               [Page 10]

Internet-Draft                    MSFD                     February 2008

                             Figure 5: MN stack

AD. Not sure if An is needed here

5.  MoS Discovery

Melia, et al.            Expires August 15, 2008               [Page 11]

Internet-Draft                    MSFD                     February 2008

Melia, et al.            Expires August 15, 2008               [Page 12]

Internet-Draft                    MSFD                     February 2008

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

                              (a) using DNS Query

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

                              (b)  Using DHCP Option

Melia, et al.            Expires August 15, 2008               [Page 13]

Internet-Draft                    MSFD                     February 2008

       DNS query.

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

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

Melia, et al.            Expires August 15, 2008               [Page 14]

Internet-Draft                    MSFD                     February 2008

    [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated
    scenario the mobile node is required to perform network access
    authentication before it can bootstrap MoS information.

AD: Suggested change, before it can obtain the MOS information

    This allows

AD> suggested change: as defined in
    [I-D.ietf-dime-mip6-integrated] and described in 
[draft-stupar-mos-diameter-options-00. The relation
    between functional components supporting such procedure is shown in
    Figure 8.

AD> The above sentence can be take out in view of the previous one

AD> visited network, interacts with  AAAh via AAAv

    MN's session remains in the visited,

AD> Change the visited to visited network

and if the MN delays sending
    DHCP request, the NAS/DHCP relay does not include the IPv6 Relay
    Agent MoS Option in the Relay Forward message.

AD> What is home agent, should it be MOS instead?

Melia, et al.            Expires August 15, 2008               [Page 15]

Internet-Draft                    MSFD                     February 2008

    on the actual network deployment (scenario S2 or S3).

AD> You may want to add and operator policy

   In an

Melia, et al.            Expires August 15, 2008               [Page 16]

Internet-Draft                    MSFD                     February 2008

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

           AAAv -- Visited AAA
           AAAH -- Home AAA

Melia, et al.            Expires August 15, 2008               [Page 17]

Internet-Draft                    MSFD                     February 2008

AD> as described in Figure 9 ..
                                    +-------+
                     +----+         |DHCP   |
                     | MN |-------->|       |
                     +----+         |Server |
                                    +-------+
                      [email-masked]

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

AD> IS Query to a known IS Server

6.  MIH Transport Options

Melia, et al.            Expires August 15, 2008               [Page 18]

Internet-Draft                    MSFD                     February 2008

6.1.  MIH Message size

6.2.  MIH Message rate

Melia, et al.            Expires August 15, 2008               [Page 19]

Internet-Draft                    MSFD                     February 2008

6.3.  Retransmission

6.4.  NAT Traversal

Melia, et al.            Expires August 15, 2008               [Page 20]

Internet-Draft                    MSFD                     February 2008

6.5.  General guidelines

7.  Operation Flows

Melia, et al.            Expires August 15, 2008               [Page 21]

Internet-Draft                    MSFD                     February 2008

                 MN                                             MoS

Melia, et al.            Expires August 15, 2008               [Page 22]

Internet-Draft                    MSFD                     February 2008

AD> What do you mean by internal process with MOS?

Melia, et al.            Expires August 15, 2008               [Page 23]

Internet-Draft                    MSFD                     February 2008

9.  IANA Considerations

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

  Keyword         Decimal   Description
  -------        -------    -----------
  ieee-mih-IS    XXX/tcp    Media Independent Handover Information Services
  ieee-mih-IS    XXX/udp    Media Independent Handover Information Services
  ieee-mih-ES    XXX/tcp    Media Independent Handover Event Services
  ieee-mih-ES    XXX/udp    Media Independent Handover Event Services
  ieee-mih-CS    XXX/tcp    Media Independent Handover Command Services
  ieee-mih-CS    XXX/udp    Media Independent Handover Command Services

10.  Acknowledgements

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

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 August 15, 2008               [Page 24]

Internet-Draft                    MSFD                     February 2008

               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-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-dime-mip6-integrated]
               Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
               and K. Chowdhury, "Diameter Mobile IPv6: Support for
               Network Access Server to Diameter Server  Interaction",
               draft-ietf-dime-mip6-integrated-07 (work in progress),
               November 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.

    [I-D.ietf-mip6-hiopt]
               Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
               Option for Home Information Discovery in MIPv6",
               draft-ietf-mip6-hiopt-10 (work in progress), January 2008.

    [I-D.ietf-mipshop-mis-ps]
               Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y.,
               Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services
               Transport: Problem Statement",
               draft-ietf-mipshop-mis-ps-05 (work in progress),
               November 2007.

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

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

    [RFC1533]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor

Melia, et al.            Expires August 15, 2008               [Page 25]

Internet-Draft                    MSFD                     February 2008

               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.

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

    [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
               Messages", RFC 3118, June 2001.

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

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

    [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
               Network Access Identifier", RFC 4282, December 2005.

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

    [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
               Security", RFC 4347, April 2006.

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

Melia, et al.            Expires August 15, 2008               [Page 26]

Internet-Draft                    MSFD                     February 2008

    [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
               RFC 4641, September 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

    [I-D.rahman-mipshop-mih-transport]
               Rahman, A., "Transport of Media Independent Handover
               Messages Over IP", draft-rahman-mipshop-mih-transport-03
               (work in progress), July 2007.

Authors' Addresses

    Telemaco Melia (editor)
    CISCO

    Email: [email-masked]

    Gabor Bajko
    Nokia

    Email: [email-masked]

    Subir Das
    Telcordia

    Email: [email-masked]

    Nada Golmie
    NIST

    Email: [email-masked]

    Sam Xia
    Huawei

    Email: [email-masked]

Melia, et al.            Expires August 15, 2008               [Page 27]

Internet-Draft                    MSFD                     February 2008

    Juan Carlos Zuniga
    InterDigital

    Email: [email-masked]

Melia, et al.            Expires August 15, 2008               [Page 28]

Internet-Draft                    MSFD                     February 2008

Full Copyright Statement

    Copyright (C) The IETF Trust (2008).

    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 August 15, 2008               [Page 29]

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Fri, 7 Mar 2008 13:33:11 +0100

Some additional comments

telemaco 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, March 05, 2008 11:16 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Mipshop] WG last call on MIHsolutiondocument
(draft-ietf-mipshop-mstp-solution-01.txt)

Hello Yoshi,

Some answers inline:

[tele] I agree, this is an implementation issue, still a useful feature.
Yoshi, could IEEE instead recommend this?

6.5.  General guidelines

[YO] Remove one '.'.

[tele] similar issue raised by Kevin. Do we need to clarify the text?
During the last presentation people were happy with this paragraph.

[tele] Do we need to add a paragraph on this? I do not think this has an
impact on the current specs. Would you mind shedding some light here
Yoshi?

---

From: "Telemaco Melia (tmelia)" <[email-masked]>
Date: Fri, 7 Mar 2008 13:41:18 +0100

Thanks Ashutosh for your comments.
We will address them in the next version of the draft.

Telemaco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ashutosh Dutta
Sent: Thursday, March 06, 2008 5:24 AM
To: Vijay Devarapalli
Cc: 'Mipshop'
Subject: Re: [Mipshop] WG last call on MIH solutiondocument
(draft-ietf-mipshop-mstp-solution-01.txt)

Vijay,

Regards
Ashutosh

1.  Introduction

    The MIH Layer 3 transport problem is divided in two main parts: the
    discovery of a node that supports specific Mobility Services (MoS)
    and the transport of the information between a mobile node (MN) and
    the discovered node.  The discovery process is required for the MN
to
    obtain the information needed for MIH protocol communication with a
    peer node.  The information includes the transport address (e.g.,
the
    IP address) of the peer node and the types of MoS provided by the
    peer node.

    The remainder

2.  Terminology

    MIH  Media Independent Handover: the handover support architecture
       defined by the IEEE 802.21 working group that consists of the MIH
       Function (MIHF), MIH Network Entities, MIH Event messages, and
MIH
       command messages.

    MIHFID  Media Independent Handover Function Identifier: an
identifier
       required to uniquely identify the MIHF endpoints for delivering
       mobility services (MoS); it is implemented as either a FQDN or
       NAI.



    MoS  Mobility Services: those services, as defined in the MIH
problem
       statement document [I-D.ietf-mipshop-mis-ps] , which include the
       MIH IS, CS, and ES services defined by the IEEE 802.21 standard.

    MoSv  Mobility Services assigned in the Visited Network, which is
any
       network other than the mobile node's home network

    MN Mobile Node: an Internet device whose location changes, along
with
       its point of connection to the network.

       layers and sends information to the local or remote upper or
lower

    ES Event Service: a MoS that originates at a remote MIHF or the
lower
       layers and sends information to the local MIHF or local higher
       layers.  The purpose of the ES is to report changes in link
status
       (e.g.  Link Going Down messages) and transmission status.

implicit

    CS Command Service: a MoS that sends commands from the remote MIHF
or
       local upper layers to the local lower layers to switch links or
to
       get link status.



    NAT  Network Address Translator: A device that implements the
Network
       Address Translation function described in [RFC3022], in which
       local or private network layer addresses are mapped to valid
       network addresses and port numbers.

    AAA visited  AAA server: an AAA server located a visited network
that
       is not the MN's home network

    MIH ACK  MIH Acknowledgement Message: a MIH signaling message that a
       MIHF sends in response to an MIH message from a sending MIHF,
when
       UDP is used as the MSTP.

    NAS  Network Access Server: a server to which a MN initially
connects
       when it is trying to gain a connection to a network and which
       determines whether the MN is allowed to connect to the NAS's
       network

AD> Is it a standard IETF definition, if not can we improve the
definition?

    UDP  Network Access Server: a server to which a MN initially
connects
       when it is trying to gain a connection to a network and which
       determines whether the MN is allowed to connect to the NAS's
       network

previous sentence

    TCP  Transmission Control Protocol: a stream-oriented transport
layer
       protocol that provides a reliable delivery service with
congestion
       control, defined in RFC 793.

    RTT  Round-Trip Time: a estimation of the time required for a
segment
       to travel from a source to a destination and an acknowledgement
to
       return to the source that is used by TCP in connection with timer
       expirations to determine when a segment is considered lost and



       should be resent.

    TLS  Transport Layer Security Protocol: an application layer
protocol
       that assures privacy and data integrity between two communicating
       network entities [RFC4346].

3.  Deployment Scenarios

    In this scenario, the MN and the services are located in the home
    network.  We refer to this set of services as MoSh as in Figure 1.
    The MoSh can be located at the access point the MN uses to connect
to
    the home network, or it can be located elsewhere.

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



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

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



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

    Different types of MoS can be provided independently of other types
    and there is no strict relationship between ES, CS and IS, nor is
    there a requirement that the entities that provide these types be
co-
    located.  However, while IS tends to involve large amounts of static
    information, ES and CS are dynamic services and some relationship
    between them can be expected, e.g. a handover command (CS) could be
    issued upon reception of a link event (ES).  Hence, while in theory
    MoS can be implemented in different locations, it is expected that
ES
    and CS will be co-located, whereas IS can be co-located with ES/CS
or
    located elsewhere.  Therefore, having the flexibility at the MSTP to
    discover different services in different locations is an important
    feature that can be used to optimize handover performance.  Resource
    discovery is discussed in more detail in Section 5.

4.  Solution Overview



  In

4.1.  Architecture

    Figure 5 depicts the MSTP reference model and its components within
a
    node.  The topmost layer is the MIHF user.  This set of applications
    consists of one or more MIH clients that are responsible for such
    operations as maintaining MIH databases associated with the IS,

AD> suggested change, for operations such as generating query and
response

    processing Layer 2 triggers as part of the ES, and initiating and
    carrying out handover operations as part of the CS.  Beneath the
MIHF
    user set is the MIHF itself.

    destroying MIH signaling associations with other MIHFs located in
MIH



                             Figure 5: MN stack

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

    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 where 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
    [RFC4282].  An MIHFID can be pre-configured or discovered through
the
    discovery methods described in Section 5.

5.  MoS Discovery



    In case MoS is provided locally (scenarios S1 and S2) , the
discovery
    techniques described in [I-D.bajko-mos-dhcp-options] and
    [I-D.bajko-mos-dns-discovery] are both applicable and either one MAY
    be used to discover the MoS.

    assumes that MoS assignment is performed during access
authentication
    and authorization.

    domains are usually pre-configured in the MNs, thus the MN can
simply



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

                              (a) using DNS Query

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

                              (b)  Using DHCP Option

    network.  There are a number of ways how the domain name of a
network
    can be learned:

    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
       visited network.  Note, that when a NAT device exists between the
       MN and the visited 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 has determined the external IP
       address of the NAT device, it MUST use that address in the
reverse



       DNS query.

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

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

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

    It should be noted, that the usage of DHCP options to discover an
MoS

    To discover the MoS at home while in a visited network using DNS,
the
    MN SHOULD use the procedures described in section Section 5.1

    Alternatively, the MN MAY also use the DHCP based discovery method.
    Using the DHCP based discovery may be required in deployments where
    the usage of MoS located in the home network is enforced and
included
    in the subscription profile.  Similarly to



    This allows
    authorization.  Also, the mechanism defined in this document
requires

    mobile node.  In the process of authorizing the mobile node, the
AAAh

    OPTION_ORO.  The mobile node MUST also include the OPTION_CLIENTID
to

    The Relay Agent intercepts the Information-request from the mobile
    node and forwards it to the DHCP server.  The Relay Agent also
    includes the received MoS information from the AAAh in the IPv6
Relay
    Agent MoS Option [I-D.bajko-mos-dhcp-options].  If a NAS
    implementation does not store the received information as long as
the
    MN's session remains in the visited,

    Agent Sub-Option in the IPv6 Relay Agent MoS Option.  The DHCP
server
    extracts the allocated home agent information from the IPv6 Relay
    Agent Sub-Option and includes it in the MoS Information Option



    In should be noted, that using the DHCP Options and procedures
    defined in [I-D.bajko-mos-dhcp-options] the MN can not specify the
    network (local or home) where it wants the MoS address from.
Whether
    the MN receives an MoS address from local or home network will
depend
    on the actual network deployment (scenario S2 or S3).

   In an
    performed by the home network the MoS information will anyway be
sent



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

           AAAv -- Visited AAA
           AAAH -- Home AAA

    methods can not be used.  The MN MAY attempt to first discover an
MoS



    remote network as inFigure 9 part(c).  It should be noted that step
c
    can only be performed upon obtaining the domain name of the remote
    network.

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

6.  MIH Transport Options

    associated with each that need to be considered in the context of
the



    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 MIH ACKs with TCP since TCP includes
    acknowledgement and retransmission functionality

6.1.  MIH Message size

    size for the ES/CS service ranges between 50 to100 bytes
[IEEE80221].
    main issues, related to fragmentation of long messages in the
context
    of UDP and the concatenation of short messages in the context of
TCP.
    added to the MIH layer or IP layer fragmentation is used instead.
    bandwidth overhead.  However, this reduced overhead comes at the
cost

6.2.  MIH Message rate

    environment and/ or process handover commands.  On the other hand,
IS



    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

6.3.  Retransmission

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



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, TCP or other supported
    transport MUST use the default port number defined for that
    particular transport..

    MOS server MUST support both UDP and TCP for MIH transport and the
MN

7.  Operation Flows

    connection to carry the IS messages.  When MOS is not
pre-configured,

    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
    option as defined 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.  The MIH user generates an IS query
addressed
    to the remote MoS.  MIHF invokes the underlying TCP client which
    establishes a transport connection with the remote peer.  Once the
    transport connection is established, MIHF sends the IS query via MIH
    protocol REQUEST message.  The message and query arrive at the
    destination MIHF and MIH user respectively.  The MoS MIH user



                 MN                                             MoS
|====================================|    |======|
|===================|
  + ---------+                                                 +
---------+
  | MIH USER |       +------+  +------+    +------+   +------+ | MIH
USER |
  | +------+ |       | TCP  |  |DHCP  |    |DHCP  |   | TCP  | |
+------+ |
  | | MIHF | |       |Client|  |Client|    |Server|   |Server| | | MIHF
| |
  +----------+       +------+  +------+    +------+   +------+
+----------+
      |                 |         |           |          |          |
      |MIH Discovery    |         |           |          |          |
      |Request          |         |           |          |          |
      |(MIH User-> MIHF)|         |           |          |          |
      |======>          |         |           |          |          |
      |                 |         |           |          |          |
      |Invoke DHCP Client         |           |          |          |
      |(Internal process with MoS)|DHCP INFORM|          |          |
      |==========================>|==========>|          |          |
      |                 |         |           |          |          |
      |                 |         |           |          |          |
      |                 |         |  DHCP ACK |          |          |
      |                 |         |<==========|          |          |
      |    Inform MoS address     |           |          |          |
      |<==========================|           |          |          |
      |    (internal process)     |           |          |          |
      |                           |           |          |          |
      |Discovery        |         |           |          |          |
      |Response         |         |           |          |          |
      |<======          |         |           |          |          |
      |(MIH User<- MIHF)|         |           |          |          |
      |                 |         |           |          |          |
      |IS Query         |         |           |          |          |
      |=======>         |         |           |          |          |
      |(MIH User-> MIHF)|         |           |          |          |
      |                 |         |           |          |          |
      |Invoke TCP Client|         |           |          |          |
      |================>|         |           |          |          |
      |(Internal process|         |           |          |          |
      |with MOS)        |         |           |          |          |
      |                 |         |           |          |          |
      |                 |  TCP connection established    |          |
      |                 |<==============================>|          |
      |                 |         |           |          |          |
      |                 |         |           |          |          |
      |                 |         |           |          |          |



    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], where available or
rely
    upon link layer security.  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
    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 described in [RFC4033].
    Readers may also refer to [RFC4641] to consider the aspects of
DNSSEC
    Operational Practices.



    transport connection between two MIHF peers, DTLS [RFC4347] should
be

    Alternatively, generic IP layer security, such as IPSec [RFC2401]
may
    be used where neither transport layer security for a specific >
    transport is available nor server only authentication is required.

9.  IANA Considerations

  Keyword         Decimal   Description
  -------        -------    -----------
  ieee-mih-IS    XXX/tcp    Media Independent Handover Information
Services
  ieee-mih-IS    XXX/udp    Media Independent Handover Information
Services
  ieee-mih-ES    XXX/tcp    Media Independent Handover Event Services
  ieee-mih-ES    XXX/udp    Media Independent Handover Event Services
  ieee-mih-CS    XXX/tcp    Media Independent Handover Command Services
  ieee-mih-CS    XXX/udp    Media Independent Handover Command Services

10.  Acknowledgements

11.  References



               August 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-hiopt]
               Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
               Option for Home Information Discovery in MIPv6",
               draft-ietf-mip6-hiopt-10 (work in progress), January
2008.

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

    [IEEE80221]

    [RFC1533]  Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor



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

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



    [RFC4641]  Kolkman, O. and R. Gieben, "DNSSEC Operational
Practices",
               RFC 4641, September 2006.

Authors' Addresses

    Telemaco Melia (editor)
    CISCO

    Email: [email-masked]

    Gabor Bajko
    Nokia

    Subir Das
    Telcordia

    Nada Golmie
    NIST

    Sam Xia
    Huawei



    Juan Carlos Zuniga
    InterDigital



Full Copyright Statement

    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.

Acknowledgment



> can find the document at the following URL.
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-mstp-solution-01.
txt

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 10 Mar 2008 11:00:45 -0400

Hi Gabor,

> combination with MIH acknowledgement SHOULD be used for transporting ES

I understand the intent.  I agree with your suggested change.

Thanks,
Yoshihiro Ohba