[MIPSHOP-MIH-DT] RE: comments on initial verison inline(mainly for discovery)
Sam Xia <xiazhongqi@huawei.com> Mon, 20 August 2007 02:06 UTC
Return-path: <mipshop-mih-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMweh-0005XE-59; Sun, 19 Aug 2007 22:06:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMweg-0005X5-I0 for mipshop-mih-dt@ietf.org; Sun, 19 Aug 2007 22:06:10 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMwec-0006O0-T1 for mipshop-mih-dt@ietf.org; Sun, 19 Aug 2007 22:06:10 -0400
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN100M3BV50C6@szxga02-in.huawei.com> for mipshop-mih-dt@ietf.org; Mon, 20 Aug 2007 10:05:25 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JN1008VHV4XK5@szxga02-in.huawei.com> for mipshop-mih-dt@ietf.org; Mon, 20 Aug 2007 10:05:24 +0800 (CST)
Received: from x49105 ([10.111.12.54]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JN10000AV4TLR@szxml04-in.huawei.com> for mipshop-mih-dt@ietf.org; Mon, 20 Aug 2007 10:05:21 +0800 (CST)
Date: Mon, 20 Aug 2007 10:05:16 +0800
From: Sam Xia <xiazhongqi@huawei.com>
In-reply-to: <E5E76343C87BB34ABC6C3FDF3B31272701608694@daebe103.NOE.Nokia.com>
To: Gabor.Bajko@nokia.com
Message-id: <001d01c7e2ce$8df73fc0$360c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Thread-index: Acfba8jJY8+1zdqWS3OeAmII9JADqwFMo53wABUz4YAAdcWF8A==
X-Spam-Score: 1.2 (+)
X-Scan-Signature: 3c84bd88e6bbcc6464f782162bb7ae94
Cc: mipshop-mih-dt@ietf.org
Subject: [MIPSHOP-MIH-DT] RE: comments on initial verison inline(mainly for discovery)
X-BeenThere: mipshop-mih-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <mipshop-mih-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/mipshop-mih-dt>
List-Post: <mailto:mipshop-mih-dt@ietf.org>
List-Help: <mailto:mipshop-mih-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=subscribe>
Errors-To: mipshop-mih-dt-bounces@ietf.org
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
- [MIPSHOP-MIH-DT] Next couple of weeks Telemaco Melia
- Re: [MIPSHOP-MIH-DT] Next couple of weeks Subir Das
- [MIPSHOP-MIH-DT] comments on initial verison inli… Sam Xia
- [MIPSHOP-MIH-DT] RE: comments on initial verison … Gabor.Bajko
- [MIPSHOP-MIH-DT] RE: comments on initial verison … Sam Xia
- [MIPSHOP-MIH-DT] RE: comments on initial verison … Gabor.Bajko