[MIPSHOP-MIH-DT] RE: comments on initial verison inline(mainly for discovery)

Hi,

Valid comments from Sam at least to section 5. Digging back in emails to
find how that text ended up in section 5, I found I sent the wrong text
to Tele some time ago.
Below is the text which should replace any existing text in section5.
Regarding draft-bajko-mos-dhcp-discovey and
draft-bajko-mos-dns-discovery, these should be available in the ietf
directories within a day or two. 

Here's the text to section 5:
=====================================================================
5.  MoS Discovery

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

5.1 MoS discovery in the home network

To discover an MoS in the home network, the MN SHOULD use the DNS based
MoS discovery method described in [draft-bajko-dns-discovery]. In order
to use that, the MN MUST first find out the domain name of its home
network. Home domains are usually preconfigured in the MNs, thus the MN
can simply read its configuration data to find out the home domain name
(scenario s1).

Alternatively, the MN MAY use the dhcp options for MoS discovery
[draft-bajko-dhcp-mos]. When the MN is roaming, using this dhcp options
may require the MN to first perform network access authentication
(scenario s3).

5.2 MoS discovery in the local network

(scenario s2)
To discover an MoS in the local network, the MN SHOULD attempt to use
the dhcp options for MoS discovery [draft-bajko-dhcp-mos]. 

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

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

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

5.3 MoS discovery in a 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
[draft-bajko-dns-discovery]. In order to use that, the MN MUST first
learn the domain name of the network it is looking for an MoS in.

If the MN does not yet know the domain name of the network, learning it
may require more than one operation, as pre-configuration and dhcp can
not be used. The MN MAY attempt to first discover an MoS in either the
local or home network and query that MoS to find out the domain name of
a specific network or the domain name of a network at a specific
location. Alternatively, the MN MAY query an MoS previously known to
learn the domain name of the desired network.

=====================================================================

-----Original Message-----
From: ext Sam Xia [mailto:xiazhongqi@huawei.com] 
Sent: Friday, August 17, 2007 12:20 AM
To: mipshop-mih-dt@ietf.org
Cc: Bajko Gabor (Nokia-SIR/MtView)
Subject: comments on initial verison inline(mainly for discovery)

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

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

Status of this Memo

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

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

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

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

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

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

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Melia, et al.           Expires January 25, 2008                [Page 1]

Internet-Draft                    MSTP                         July 2007

Abstract

   To be edited.

Requirements Language

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  3
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Architecture (functional elements?)  . . . . . . . . . . .  8
       4.1.1.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . .  9
   5.  Node Discovery . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  MIH Transport  . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Message specifications . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     12.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Melia, et al.           Expires January 25, 2008                [Page 2]

Internet-Draft                    MSTP                         July 2007

1.  Introduction

   This document proposes a solution to the issues indetified in the
   problem statement document [ref to PS] for the transport of IEEE
   802.21 protocol.

   The MIH layer three transport problem is divided in two main parts:
   the discovery of mobility services and the transpotation of the
   information between mobility services.  The discovery process is
   required for MIH function located in the MN to discover the peer MIHF
   (e.g. the IP address) of the MoS in teh network (e.g. the Point of
   Service, PoS) either during attachment or during handover.  Upon
   succesfull discovery, the MIH peers need to exchange information.
   The transport should carry over the communication between the peers
   and should account for security aspects.

   This document considers standard track IETF-based solutions to design
   the missing protcol components.

2.  Terminology

   The following terminology is being used:

   MIH  Media Independent Handover

   MN Mobile Node

   NN Network Node

   MIHFID  MIHFID

   MIHF  MIHF

   MoSh  MoSh

   MoSv  MoSv

3.  Deployment Scenarios

   The follwoing scenarios have been identified:

Melia, et al.           Expires January 25, 2008                [Page 3]

Internet-Draft                    MSTP                         July 2007

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

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

                      Figure 1: MoS in the Home network

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

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

                    Figure 2: MoSV in the Visited Network

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

Melia, et al.           Expires January 25, 2008                [Page 4]

Internet-Draft                    MSTP                         July 2007

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

             Figure 3: MoS provided by the home while in visited

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

      (preamble)
                                      +--------------+
                                      | HOME NETWORK |
   +====+    +--------------+         +--------------+
   |MoS3|    | THIRd PARTY  |  <===>        /\
   +====+    +--------------+               ||
                                            \/
                                    +-----------------+
                                    | VISITED NETWORK |
                                    +-----------------+
                                            /\
                                            ||
                                            \/
                                        +--------+
                                        |   MN   |
                                        +--------+
      (postamble)

                       Figure 4: MoS form a third party

4.  Solution Overview

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

Melia, et al.           Expires January 25, 2008                [Page 5]

Internet-Draft                    MSTP                         July 2007

      The solution is aimed at supporting 802.21 MIH services, namely
      IS, ES, CS

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

      The solutions are choosen to cover all possible deployment
      scenarios which are introduced later in this section

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

   For the discovery and selection problem the MN has two different
   options.  The configuration of the MoS could be executed either upon
   network attachment or after succesfull IP configuration.  The
   methodology to be used depends on the considered scenario.  Following
   the recomendation to select standard track IETF-based solution two
   well deployed options are available: DHCP based methods and DNS based
   methods.

   NOTE: Should we add a comment on why RAs are not used to disseminate
   the MoS IP address?  (I received an email from a guy asking if we use
   RAs).

/*****comments******/
   Sam.Xia> DHCP based or DNS based solutions are just recommended
soution 
            by this draft. Any other methods should be not excluded.
Anyway,
            selection is made by operators, not by us.

   For DHCPv4 based solutions the following example holds.

Melia, et al.           Expires January 25, 2008                [Page 6]

Internet-Draft                    MSTP                         July 2007

                                             MIH ENABLED MN
                   +--------------+          +-------------+
                   |  DHCP SERVER1|          | DHCP CLIENT |
             +-----+-----------|--+          +------|------+
             |  DHCP SERVER2|  |                    |
     +-------+--------|-----+  |                    |
     |  DHCP SERVER3| |        |    DHCP DISCOVER   |
     +------|-------+ |        |<===================|DHCP OFFER
            |         |        |===================>|WITHOUT MoS
            |         |        | DHCP OFFER         |
            |         |<============================|DHCP OFFER
            |         |============================>|WITHOUT MoS
            |         |        |                    |
            |         |        | DHCP OFFER         |
            |<======================================|DHCP OFFER
            |======================================>|WITH MoS
            |         |        |                    |
            |         |        |           MN SELECTS THE TARGET
            |         |        |             BASED ON AVAILABLE
            |         |        |                MIH OPTION
            |         |        |                 PRESENT
            |         |  DHCP REQUEST               |
            |<======================================|
            |         |  DHCPACK                    |
            |======================================>|

           Figure 5: Selection of DHCP server based on the offer

   Upon layer-two network attachement the MN broadcasts DHCP DISCOVER
   messages according to standard [RFC 2132].  According to standard
   behavior the MN can wait to receive multiple replies from DHCP
   servers and pick up a preferred target.  This would allow an MIH
   enabled terminal to configure its IP stack based on the availability
   of the MoS option.

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

/*****comments********/
   Sam.Xia> According to [RFC3315], there are two variants for twe
messages
            based exchange(One is request-reply pair, the other is
solicitation
            -reply pair). From [RFC3315], I don't see any specification
that
            stateless autoconfiguration are binded to two messages
mechanism.
            I mean that even having stateless autoconfiguration, MN has
to 
            discovery dhcp server id by solication message firstly, then
to send
            information-request message.

Melia, et al.           Expires January 25, 2008                [Page 7]

Internet-Draft                    MSTP                         July 2007

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

                  Figure 6: DHCPv6 two messages exchange

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

   Should we add and informative flow for the case where the address is
   assigned via stateless autoconf?

/********comments*******/
   Sam.Xia> I don't see any necessity.

   Figure (Figure 5) and figure (Figure 6) meets the requiremetns
   imposed by scenarios S1 and S2.  S3 needs tight interaction with the
   AAA infrastructure.  The follwoing picture show show the system i
   ssupposed to work.

   NOTE: add the picture for DHCP/AAA discovery.
/****comments***/
   Sam.xia> I suggest that we could refer to DHCP/AAA framework in
            draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt.
            if gabor agrees, i can do the work.

   S4 can be supported only via DNS discovery.
/*****comments*********/   
   Sam.Xia> if we make some static configuration in DHCP server in
advance, 
            figure 5 and figure 6 maybe meets the requirements imposed
by
            s4 to some extent.

   NOTE: add an example of how we intend to support discovery via DNS.
/*****comments*****/
   what is our choice between DNS SRV and DNS NAPTR? why?

   Once the Mobility Services have been discovered MIH peers exchange
   information according to the follwoing recommendations.

   NOTE: Nada is preparing first output for the beginning of September.
   JC can you start on this?

4.1.  Architecture (functional elements?)

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

Melia, et al.           Expires January 25, 2008                [Page 8]

Internet-Draft                    MSTP                         July 2007

    +--------------------------+
    |           MIHF           |
    +--------------------------+
                 ||
    +--------------------------+
    |           MSTP           |          /**what about the framework
inside
of MSTP? this is just what we should do.*/
    +--------------------------+
        ||         ||       ||
    +---------+ +------+ +-----+
    | TCP/UDP | | DHCP | | DNS |
    +---------+ +------+ +-----+

                            Figure 7: MN stack

4.1.1.  MIHF Identifiers (FQDN, NAI)

   NOTE: to be filled, Subir, JC can you do this?

5.  Node Discovery

   Before performing MIHF discovery, the MN MUST find out the domain
   name of the network in which it is looking for an MoS. 
/***comments****/
   Sam.Xia> Why do the MN MUST find out the domain
            name of the network in which it is looking for an MoS?
            I don't think so. For DNS based solution, it is MUST. 
            For DHCP, it is just an option. DHCP can return IP address
            of MoS without exact domain name of MoS from MN because 
            DHCP can do this work for MN. For example, DHCP can return
            local MoS without domain name of MoS from MN.

 The MN can
   use a local MoS (scenarios s1 and s2 from section 3) or a remote MoS
   (scenarios s3 and s4 from section 3).  Home domains are usually
   preconfigured in the MNs, thus when the MN wants to use a home MoS
   while connnected to its home network, it can simply read its
   configuration data to find out the home domain name (where it wants
   to locate the MoS).

   For networks other than its home network, the MN MUST use other means
   to find out the domain name of the network it is looking for MoS.  In
   order to find out the domain name of the local network, the MN MAY
   use the DHCP option for learning the domain name [dhcp-option
   reference here].  To learn the domain name of a remote network, the
   MN can use other means, eg it could query an MoS previously known to
   learn the domain name of a network at a specific location.  Once the
   MN knows the domain name of the network it is looking for an MoS, it
   MAY use the dhcp options for MoS discovery [draft-bajko-dhcp-mos] to
   discover a server which hosts an IS, ES or CS service.  Note, that
   using dhcp to discover an MoS has its limitations.  It can not be
   used in scenario s4 and in scenario s3 it might require the MN to
   perform network access authentication with its home domain.
/****comments***/
   Sam.Xia> Just as I said above, DHCP may be useful for s4 when we make
            static configuration on DHCP server which provides MoS
information
            about the third party networks.

   Sam.Xia> where are [draft-bajko-dhcp-mos] &
[draft-bajko-dns-discovery]?

   The MN MAY also use the DNS based MoS discovery method described in
   [draft-bajko-dns-discovery].  The DNS based discovery method is
   applicable in all scenarios described in section 3, but it requires
   that the DNS be configured with the required NAPTR and SRV records.

Melia, et al.           Expires January 25, 2008                [Page 9]

Internet-Draft                    MSTP                         July 2007

6.  MIH Transport

   NOTE: See comment above, JC can you start on this?.  MIH transport
   considerations (latency, congestion control and reliability)

7.  Operation Flows

   NOTE: Include here flows for each of the scenarios we want to
   support.  Not yet assigned

8.  Message specifications

   NOTE: Gabor needs to complete ths part

9.  IANA Considerations

   Requests to IANA .

10.  Security Considerations

   NOTE: to be filled, Subir can you do this?

11.  Acknowledgements

   ....

_______________________________________________
MIPSHOP-MIH-DT mailing list
MIPSHOP-MIH-DT@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt