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

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:xiazhongqi@huawei.com] 
Sent: Sunday, August 19, 2007 7:05 PM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: mipshop-mih-dt@ietf.org
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 

> -----Original Message-----
> From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
> Sent: Saturday, August 18, 2007 1:30 AM
> To: xiazhongqi@huawei.com; mipshop-mih-dt@ietf.org
> 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.
> 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