Subject: [MIPSHOP-MIH-DT] Next couple of weeks

From: Telemaco Melia <[email-masked]>
Date: Fri, 10 Aug 2007 18:30:19 +0200

Guys,

Next couple of weeks I ll be out of office with limited email access.
I asked Juan Carlos to take over the editorial work and he kindly 
accepted. Thanks for this, I ll be sending you the xml sources in a 
separate email.
The status is as follow.
Nada will provide first input from the simulation study by September. 
Considerations will be integrated by then.
Gabor provided first input about the extensions to DHCP and DNS.
The document itself (attached here) needs the input from JC and Subir. 
Notes are included in the text.
Please send comments to JC, he will then integrate them.

cheers
telemaco

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

   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.

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?

   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.

   S4 can be supported only via DNS discovery.

   NOTE: add an example of how we intend to support discovery via DNS.

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

   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

   ....

12.  References

12.1.  Normative References

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

12.2.  Informative References

   [Anchor]   "", 2005.

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

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Phone:
   Fax:
   Email:
   URI:

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:

   Nada Golmie
   NIST

   Phone:
   Fax:
   Email:
   URI:

   Heejin Jang
   Samsung

   Phone:
   Fax:
   Email:
   URI:

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

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Gabor Bajko
   Nokia

   Phone:
   Fax:
   Email:
   URI:

   Juan Carlos Zuniga
   InterDigital

   Phone:
   Fax:
   Email:
   URI:

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

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

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

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

---

From: Subir Das <[email-masked]>
Date: Mon, 13 Aug 2007 20:58:38 -0400

Tele,
Enjoy your vacation.

JC:  I will get back to you soon.

-Subir

Telemaco Melia wrote:
> ------------------------------------------------------------------------
>
>
>
>
> Mipshop WG                                                 T. Melia, Ed.
> Internet-Draft                                                       NEC
> ------------------------------------------------------------------------
>

---

From: Sam Xia <[email-masked]>
Date: Fri, 17 Aug 2007 15:19:40 +0800

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

Status of this Memo

Copyright Notice



Abstract

   To be edited.

Requirements Language

Table of Contents



1.  Introduction

2.  Terminology

   MN Mobile Node

   NN Network Node

   MIHFID  MIHFID

   MIHF  MIHF

   MoSh  MoSh

   MoSv  MoSv

3.  Deployment Scenarios



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

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



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

      (preamble)
                                      +--------------+
                                      | HOME NETWORK |

4.  Solution Overview



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



                                             MIH ENABLED MN

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



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

   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?



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

                            Figure 7: MN stack

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

/****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]?



6.  MIH Transport

7.  Operation Flows

9.  IANA Considerations

   Requests to IANA .

11.  Acknowledgements

   ....

---

From: <[email-masked]>
Date: Fri, 17 Aug 2007 12:29:55 -0500

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:[email-masked]] 
Sent: Friday, August 17, 2007 12:20 AM
To: [email-masked]
Cc: Bajko Gabor (Nokia-SIR/MtView)
Subject: comments on initial verison inline(mainly for discovery)

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

Status of this Memo

Copyright Notice



Abstract

   To be edited.

Requirements Language

Table of Contents



1.  Introduction

2.  Terminology

   MN Mobile Node

   NN Network Node

   MIHFID  MIHFID

   MIHF  MIHF

   MoSh  MoSh

   MoSv  MoSv

3.  Deployment Scenarios



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

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



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

      (preamble)
                                      +--------------+
                                      | HOME NETWORK |

4.  Solution Overview



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



                                             MIH ENABLED MN

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



   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.



    |           MSTP           |          /**what about the framework
inside

                            Figure 7: MN stack

5.  Node Discovery

 The MN can

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



6.  MIH Transport

7.  Operation Flows

9.  IANA Considerations

   Requests to IANA .

11.  Acknowledgements

   ....

---

From: Sam Xia <[email-masked]>
Date: Mon, 20 Aug 2007 10:05:16 +0800

Gabor,
I can NOT find your referred draft from bajko in IETF website and Google.
so I asked where they are.
And since the two draft are not RFC/WG drafts(maybe expired), why not to
describe the discovery mechanism in our draft?

 Best Regards, Sam Xia 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Saturday, August 18, 2007 1:30 AM
> To: [email-masked]; [email-masked]
> Subject: 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.
> draft-bajko-mos-dns-discovery, these should be available in 
> the ietf directories within a day or two. 
> 
> 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.
> 
> 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).
> 
> 
> 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.
> 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].
> 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 
> 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.
> 
> Mipshop WG                                                 T. 
> Melia, Ed.
> Internet-Draft                                                
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >

---

From: <[email-masked]>
Date: Sun, 19 Aug 2007 21:24:17 -0500

I told you to be a bit patient, the ietf editor is surely doing its best
to upload submitted documents.

-----Original Message-----
From: ext Sam Xia [mailto:[email-masked]] 
Sent: Sunday, August 19, 2007 7:05 PM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]
Subject: RE: comments on initial verison inline(mainly for discovery)

Gabor,
I can NOT find your referred draft from bajko in IETF website and
Google.
so I asked where they are.
And since the two draft are not RFC/WG drafts(maybe expired), why not to
describe the discovery mechanism in our draft?

 Best Regards, Sam Xia 

> 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.
> 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.
> 
> 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).
> 
> [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).
> 
> 
> 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.
> 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].
> reverse dns (dns PTR record) to find the domain name associated with 
> the IP address it is using in the local network.

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

> 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.
> 
>             discovery dhcp server id by solication message firstly, 
> then to send