From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 1 08:23:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06193 for ; Fri, 1 Jun 2001 08:23:02 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12037; Fri, 1 Jun 2001 05:19:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00207; Fri, 1 Jun 2001 05:19:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51CHHu14391 for mobile-ip-dist; Fri, 1 Jun 2001 05:17:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51CGVe14376; Fri, 1 Jun 2001 05:16:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29930; Fri, 1 Jun 2001 05:16:38 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16032; Fri, 1 Jun 2001 05:16:38 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 951BFF59; Fri, 1 Jun 2001 05:19:46 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 23623D4A; Fri, 1 Jun 2001 05:19:46 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Fri, 1 Jun 2001 08:16:37 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D6950961A@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] MN's packet reception Date: Fri, 1 Jun 2001 08:16:37 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I disagree. The "as if" clause applies only to processing done "by upper-layer protocols within the mobile node", such as TCP and above. The processing described in [2] happens below TCP. Ken > -----Original Message----- > From: Jiwoong Lee [mailto:porce@ktf.co.kr] > Sent: Wednesday, May 30, 2001 2:06 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] MN's packet reception > > > All > > In addtion to the original mail, I suggest to remove the last > subordinate > clause (*) starting with "as if.." of the below paragraph in > MobileIPv6-13, > because > > [1] Generic Packet Tunneling in IPv6 spec does not state that kind of > statement and > [2] the MN's BU condition (#) seems to be outof accord with > (*), perhaps > from the view point of implementation. > > comment please. > > Jiwoong > > > > > For packets received by either the first or last of these three > methods, the mobile node SHOULD send a Binding Update to > the original > sender of the packet, as described in Section 10.8, subject to the > rate limiting defined in Section 10.11. The mobile node SHOULD > also process the received packet in the manner defined for IPv6 > encapsulation [4], which will result in the encapsulated (inner) > packet being processed normally by upper-layer protocols within the > mobile node, (*)as if it had been addressed (only) to the > mobile node's > home address. > > and > > In addition, when a mobile node receives a packet for which the > mobile node can deduce that the original sender of the packet has > no Binding Cache entry for the mobile node, or for which the mobile > node can deduce that the original sender of the packet has an > out-of-date care-of address for the mobile node in its > Binding Cache, > the mobile node SHOULD return a Binding Update to the sender giving > its current care-of address (subject to the rate limiting defined > in Section 10.11). In particular, the mobile node SHOULD return a > Binding Update in response to receiving a packet that meets all of > the following tests: > > (#) - The packet was tunneled using IPv6 encapsulation. > ... > > > > > ----- Original Message ----- > From: "Jiwoong Lee" > To: > Sent: Tuesday, May 29, 2001 9:44 AM > Subject: [mobile-ip] MN's packet reception > > > > All, > > > > Becasue CN's requirement to use Binding Cache when it sends > > a packet to MN is "SHOULD", the corresponding possibilities > > in which a MN receives a packet while away from home also > > should be described legitimately. > > > > A MN MAY receive a packet > > addressed to its home address, which is sent by a CN that DOES > > have a Binding Cache entry for the MN, if the CN does NOT like > > to use Routing Header. > > > > Jiwoong > > -- > > > > > > 8.9. Sending Packets to a Mobile Node > > > > Before sending any packet, the sending node SHOULD examine its > > Binding Cache for an entry for the destination address > to which the > > packet is being sent. If the sending node has a Binding > Cache entry > > for this address, the sending node SHOULD use a Routing header to > > route the packet to this mobile node (the destination > node) by way > > of the care-of address in the binding recorded in that > Binding Cache > > entry. ... > > > > > > 10.3. Receiving Packets While Away from Home > > > > While away from home, a mobile node will receive packets > addressed to > > its home address, by one of three methods: > > > > - Packets sent by a correspondent node that does not have a > > Binding Cache entry for the mobile node, will be sent by the > > correspondent node in the same way as any normal IP > packet. Such > > packets will then be intercepted by the mobile > node's home agent, > > encapsulated using IPv6 encapsulation [4], and > tunneled to the > > mobile node's primary care-of address. ... > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 1 09:00:01 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07170 for ; Fri, 1 Jun 2001 09:00:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01129; Fri, 1 Jun 2001 06:59:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05441; Fri, 1 Jun 2001 05:58:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51Cvpw14489 for mobile-ip-dist; Fri, 1 Jun 2001 05:57:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51Cvle14482; Fri, 1 Jun 2001 05:57:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26746; Fri, 1 Jun 2001 05:57:55 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00254; Fri, 1 Jun 2001 06:57:53 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.co.kr [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.3 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved. Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f51CsWP25751; Fri, 1 Jun 2001 21:54:32 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id VAA15743; Fri, 1 Jun 2001 21:55:30 +0900 (KST) Message-ID: <006001c0ea9a$133b2400$ae0a060a@words> From: "Jiwoong Lee" To: Cc: , References: <88BD5A70CA8BFA4CA15D0ED053E49D6950961A@tayexc14.americas.cpqco> Subject: Re: [mobile-ip] MN's packet reception Date: Fri, 1 Jun 2001 21:55:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Ken, I re-reviewed the questionable statement in MIPv6-13 and I think your point was right. And now I think that sentence was quite perplexingly tricky,- because there are two subjects for a predicate verb 'process' in one sentence. The first half part in the sentence is saying the node's IPv6 encap/decap module processing, while the latter is saying the node's transport layer processing - trickily with two commas. Sooo amusing! :> Big thanks, Jiwoong ----- Original Message ----- From: "Powell, Ken" To: Cc: Sent: Friday, June 01, 2001 9:16 PM Subject: RE: [mobile-ip] MN's packet reception > I disagree. The "as if" clause applies only to processing > done "by upper-layer protocols within the mobile node", such > as TCP and above. The processing described in [2] happens > below TCP. > > Ken > > > -----Original Message----- > > From: Jiwoong Lee [mailto:porce@ktf.co.kr] > > Sent: Wednesday, May 30, 2001 2:06 AM > > To: mobile-ip@sunroof.eng.sun.com > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] MN's packet reception > > > > > > All > > > > In addtion to the original mail, I suggest to remove the last > > subordinate > > clause (*) starting with "as if.." of the below paragraph in > > MobileIPv6-13, > > because > > > > [1] Generic Packet Tunneling in IPv6 spec does not state that kind of > > statement and > > [2] the MN's BU condition (#) seems to be outof accord with > > (*), perhaps > > from the view point of implementation. > > > > comment please. > > > > Jiwoong > > > > > > > > > > For packets received by either the first or last of these three > > methods, the mobile node SHOULD send a Binding Update to > > the original > > sender of the packet, as described in Section 10.8, subject to the > > rate limiting defined in Section 10.11. The mobile node SHOULD > > also process the received packet in the manner defined for IPv6 > > encapsulation [4], which will result in the encapsulated (inner) > > packet being processed normally by upper-layer protocols within the > > mobile node, (*)as if it had been addressed (only) to the > > mobile node's > > home address. > > > > and > > > > In addition, when a mobile node receives a packet for which the > > mobile node can deduce that the original sender of the packet has > > no Binding Cache entry for the mobile node, or for which the mobile > > node can deduce that the original sender of the packet has an > > out-of-date care-of address for the mobile node in its > > Binding Cache, > > the mobile node SHOULD return a Binding Update to the sender giving > > its current care-of address (subject to the rate limiting defined > > in Section 10.11). In particular, the mobile node SHOULD return a > > Binding Update in response to receiving a packet that meets all of > > the following tests: > > > > (#) - The packet was tunneled using IPv6 encapsulation. > > ... > > > > > > > > > > ----- Original Message ----- > > From: "Jiwoong Lee" > > To: > > Sent: Tuesday, May 29, 2001 9:44 AM > > Subject: [mobile-ip] MN's packet reception > > > > > > > All, > > > > > > Becasue CN's requirement to use Binding Cache when it sends > > > a packet to MN is "SHOULD", the corresponding possibilities > > > in which a MN receives a packet while away from home also > > > should be described legitimately. > > > > > > A MN MAY receive a packet > > > addressed to its home address, which is sent by a CN that DOES > > > have a Binding Cache entry for the MN, if the CN does NOT like > > > to use Routing Header. > > > > > > Jiwoong > > > -- > > > > > > > > > 8.9. Sending Packets to a Mobile Node > > > > > > Before sending any packet, the sending node SHOULD examine its > > > Binding Cache for an entry for the destination address > > to which the > > > packet is being sent. If the sending node has a Binding > > Cache entry > > > for this address, the sending node SHOULD use a Routing header to > > > route the packet to this mobile node (the destination > > node) by way > > > of the care-of address in the binding recorded in that > > Binding Cache > > > entry. ... > > > > > > > > > 10.3. Receiving Packets While Away from Home > > > > > > While away from home, a mobile node will receive packets > > addressed to > > > its home address, by one of three methods: > > > > > > - Packets sent by a correspondent node that does not have a > > > Binding Cache entry for the mobile node, will be sent by the > > > correspondent node in the same way as any normal IP > > packet. Such > > > packets will then be intercepted by the mobile > > node's home agent, > > > encapsulated using IPv6 encapsulation [4], and > > tunneled to the > > > mobile node's primary care-of address. ... > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 1 11:53:40 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10496 for ; Fri, 1 Jun 2001 11:53:40 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11813; Fri, 1 Jun 2001 09:50:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00665; Fri, 1 Jun 2001 08:50:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51Fn8c14755 for mobile-ip-dist; Fri, 1 Jun 2001 08:49:08 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51Fn5e14748 for ; Fri, 1 Jun 2001 08:49:06 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18042 for ; Fri, 1 Jun 2001 11:49:12 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA18621 for mobile-ip@sunroof.eng.sun.com; Fri, 1 Jun 2001 11:49:30 -0400 (EDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51CQbe14444 for ; Fri, 1 Jun 2001 05:26:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01021 for ; Fri, 1 Jun 2001 05:26:44 -0700 (PDT) Received: from marjan.fesb.hr (marjan.fesb.hr [161.53.166.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19258 for ; Fri, 1 Jun 2001 05:26:42 -0700 (PDT) Received: from localhost (softcom@localhost) by marjan.fesb.hr (8.9.3/8.9.3) with ESMTP id OAA15746; Fri, 1 Jun 2001 14:15:29 +0200 (MET DST) Date: Fri, 1 Jun 2001 14:15:29 +0200 (MET DST) From: SoftCOM To: softcom@fesb.hr Subject: [mobile-ip] CfP: Workshop on Future Wireless Communications Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: CALL FOR PAPERS SoftCOM 2001 IEEE International Conference on Software, Telecommunications and Computer Networks Workshop on Future Wireless Communications October 09-12, 2001 Split, Dubrovnik (Croatia) Ancona, Bari (Italy) Workshop on Future Wireless Communications will be held aboard the ship Marko Polo travelling on the route Split (Croatia) Ancona (Italy) Bari (Italy) Dubrovnik (Croatia) in the frame of the 9 th International Conference on Software, Telecommunications and Computer Networks SoftCOM 2001. The increasing popularity of wireless networks indicates that most of future networking structures will be based on wireless networking technologies (Satellite, Ad Hoc, UMTS, ..). Wireless communication poses some problems that do not exist in wired networks, such as limited resources and fading due to mobility. This has generated an enormous interest for new communication protocols and enhanced traffic/resource management mechanisms. This Workshop on Future Wireless Communications will cover both theoretical and pratical aspects and will provide an opportunity for researchers to meet and discuss aspects of their work in an informal setting. Papers presenting new results in (but not limited to) the following areas are invited: * Emerging Satellite Systems * Protocols for Ad Hoc Wireless Networks * Transport/Data Link Protocols for Mobile Satellite Communications * QoS in Wireless Networks * Heterogeneous Wireless Networks * Traffic & Resource Management in Satellite Networks * Integration between Wired and Wireless (Satellite, Ad Hoc, UMTS,..) Networks * Services and Applications for Wireless Communications Each day of the conference the ship will be anchored in one of the ports on the route, and overnight it will sail towards the next destination. This provides participants with the opportunity to share ideas in close contact with their coleagues and to enjoy the pleasant and inspiring ambience while visiting the ports along the beautiful Adriatic coast. During the conference the car deck will serve as an exhibition arena for exhibitors of software and telecommunication products. Schedule Complete manuscript to be received by July 1, 2001 Notification of acceptance mailed out by September 1, 2001 Camera-ready manuscript to be received by September 15, 2001 More information about the Conference including details on the submission process and authors kit are available on the website http://www.fesb.hr/SoftCOM Workshop Chair: Mario De Blasi, University of Lecce, Italy (mario.deblasi@unile.it) Conference Secretary: Hrvoje Dujmic, University of Split, Croatia (softcom@fesb.hr) From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 13:38:16 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13979 for ; Mon, 4 Jun 2001 13:38:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21049; Mon, 4 Jun 2001 11:36:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01317; Mon, 4 Jun 2001 10:36:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54HZPZ20148 for mobile-ip-dist; Mon, 4 Jun 2001 10:35:25 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54HZNe20141 for ; Mon, 4 Jun 2001 10:35:23 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29298 for ; Mon, 4 Jun 2001 13:35:31 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA00629 for mobile-ip@sunroof.eng.sun.com; Mon, 4 Jun 2001 13:35:49 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5465Oe18793 for ; Sun, 3 Jun 2001 23:05:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA09636 for ; Sun, 3 Jun 2001 23:05:31 -0700 (PDT) Received: from mail0.yrp.nttdocomo.co.jp (mail0.yrp.nttdocomo.co.jp [202.245.184.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27106 for ; Mon, 4 Jun 2001 00:06:01 -0600 (MDT) Received: from mlab.yrp.nttdocomo.co.jp (mlab.yrp.nttdocomo.co.jp [172.21.34.30]) by mail0.yrp.nttdocomo.co.jp (8.9.0/YRPHUB0-8819980304) with ESMTP id PAA05611 for ; Mon, 4 Jun 2001 15:05:28 +0900 (JST) Received: from ichiro ([172.21.43.66]) by mlab.yrp.nttdocomo.co.jp (8.9.0/YRPDOMAIN-8819980304) with ESMTP id PAA18830 for ; Mon, 4 Jun 2001 15:05:23 +0900 (JST) Message-Id: <4.2.0.58.J.20010604151042.00a6bc30@mlab.yrp.nttdocomo.co.jp> X-Sender: okajima@mlab.yrp.nttdocomo.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 04 Jun 2001 15:11:21 +0900 To: mobile-ip@sunroof.eng.sun.com From: Ichiro Okajima Subject: [mobile-ip] How does HA use routing table? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello all, I would appreciate it if anyone would answer my question. I think that the HA of Mobile IPv6 has a routing table as well as Binding Cache since it is a kind of router. It seems to me that Mobile IPv6 I-D does not say the relationship between the Binding Cache and the routing table, and how to use the routing table. My guess is as follows: 1) When the HA receives a packet, it firstly checks the Binding Cache whether a binding for the destination address of the packet exists or not. 2) If no binding exist in the Binding Cache, it secondly checks the routing table to find the best route for the packet. Is my understanding correct? Ichiro From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 14:00:32 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14643 for ; Mon, 4 Jun 2001 14:00:32 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09026; Mon, 4 Jun 2001 10:57:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05792; Mon, 4 Jun 2001 10:56:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54Ht4p20328 for mobile-ip-dist; Mon, 4 Jun 2001 10:55:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Ht0e20321 for ; Mon, 4 Jun 2001 10:55:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20542 for ; Mon, 4 Jun 2001 10:55:09 -0700 (PDT) Received: from hub.ecutel.com ([65.201.154.134]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25440 for ; Mon, 4 Jun 2001 10:55:07 -0700 (PDT) Received: from qiangzhang [192.168.50.11] by hub.ecutel.com (SMTPD32-5.05) id AEC358C20154; Mon, 04 Jun 2001 14:09:07 -0400 Message-ID: <0d4801c0ed28$11ada000$0b32a8c0@ecutel.com> From: "Qiang Zhang" To: References: <4.2.0.58.J.20010604151042.00a6bc30@mlab.yrp.nttdocomo.co.jp> Subject: Re: [mobile-ip] How does HA use routing table? Date: Mon, 4 Jun 2001 13:56:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think for Agent to deliever the packet, the implication is that it should follow the routing table, even there is a binding cache for a packet. Does MIP have to address the issue? ----- Original Message ----- From: "Ichiro Okajima" To: Sent: Monday, June 04, 2001 1:11 AM Subject: [mobile-ip] How does HA use routing table? > Hello all, > > I would appreciate it if anyone would answer my question. > I think that the HA of Mobile IPv6 has a routing table as well as > Binding Cache since it is a kind of router. It seems to me that > Mobile IPv6 I-D does not say the relationship between the Binding > Cache and the routing table, and how to use the routing table. > My guess is as follows: > > 1) When the HA receives a packet, it firstly checks the Binding > Cache whether a binding for the destination address of the packet > exists or not. > > 2) If no binding exist in the Binding Cache, it secondly checks > the routing table to find the best route for the packet. > > Is my understanding correct? > > Ichiro > From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 14:03:55 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14726 for ; Mon, 4 Jun 2001 14:03:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15696; Mon, 4 Jun 2001 12:02:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07599; Mon, 4 Jun 2001 11:02:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54I1MF20383 for mobile-ip-dist; Mon, 4 Jun 2001 11:01:22 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54I1Je20376 for ; Mon, 4 Jun 2001 11:01:19 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA11413 for ; Mon, 4 Jun 2001 11:01:25 -0700 (PDT) Message-Id: <200106041801.LAA11413@heliopolis.eng.sun.com> Date: Mon, 4 Jun 2001 11:01:25 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] How does HA use routing table? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 89rRwR9aNiInqFK/Yq/ebw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think the spec ought to be clear that the two should not offer contradictory information. If the binding cache says that there is a remote binding, then the routing table should not say that there is a local one, and vice versa. Hence, it should not matter which source is consulted first. jak >From: "Qiang Zhang" >To: >Subject: Re: [mobile-ip] How does HA use routing table? >Date: Mon, 4 Jun 2001 13:56:31 -0500 >X-Priority: 3 >X-MSMail-Priority: Normal >X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 > >I think for Agent to deliever the packet, the implication is that it should >follow the routing table, even there is a binding cache for a packet. Does >MIP have to address the issue? > >----- Original Message ----- >From: "Ichiro Okajima" >To: >Sent: Monday, June 04, 2001 1:11 AM >Subject: [mobile-ip] How does HA use routing table? > > >> Hello all, >> >> I would appreciate it if anyone would answer my question. >> I think that the HA of Mobile IPv6 has a routing table as well as >> Binding Cache since it is a kind of router. It seems to me that >> Mobile IPv6 I-D does not say the relationship between the Binding >> Cache and the routing table, and how to use the routing table. >> My guess is as follows: >> >> 1) When the HA receives a packet, it firstly checks the Binding >> Cache whether a binding for the destination address of the packet >> exists or not. >> >> 2) If no binding exist in the Binding Cache, it secondly checks >> the routing table to find the best route for the packet. >> >> Is my understanding correct? >> >> Ichiro >> > From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 14:35:08 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15387 for ; Mon, 4 Jun 2001 14:35:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27729; Mon, 4 Jun 2001 11:33:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26270; Mon, 4 Jun 2001 11:31:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54IU4220559 for mobile-ip-dist; Mon, 4 Jun 2001 11:30:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54IU0e20552 for ; Mon, 4 Jun 2001 11:30:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14397 for ; Mon, 4 Jun 2001 11:30:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19669 for ; Mon, 4 Jun 2001 11:29:59 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24970 for ; Mon, 4 Jun 2001 11:29:58 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f54ITvw28163 for ; Mon, 4 Jun 2001 11:29:57 -0700 X-mProtect: Mon, 4 Jun 2001 11:29:57 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdIV0Tui; Mon, 04 Jun 2001 11:29:56 PDT Message-ID: <3B1BD3A4.59A0156E@iprg.nokia.com> Date: Mon, 04 Jun 2001 11:29:56 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How does HA use routing table? References: <4.2.0.58.J.20010604151042.00a6bc30@mlab.yrp.nttdocomo.co.jp> <0d4801c0ed28$11ada000$0b32a8c0@ecutel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, First, I concur with Ichiro Okajima's assessment of the intention of the home agent procedure. If the home agent has a binding for the mobile node, then that is authoritative. If there is a clash between the home agent's routing table and its Binding Cache entry for the mobile node, then that means something has gone wrong. In fact, if the home agent doesn't have a binding cache entry for the mobile node, it typically shouldn't get the packet at all except insofar as the home agent is a default router for the home network. In that case, then its action is well defined, and typically it still wouldn't have a host-specific route for the mobile node. I usually consider the Binding Cache to be like a part of the routing table anyway, with special flags. Can someone suggest an improvement to the wording of the Mobile IPv6 specification to clarify this? Regards, Charlie P. Qiang Zhang wrote: > > I think for Agent to deliever the packet, the implication is that it should > follow the routing table, even there is a binding cache for a packet. Does > MIP have to address the issue? > > ----- Original Message ----- > From: "Ichiro Okajima" > To: > Sent: Monday, June 04, 2001 1:11 AM > Subject: [mobile-ip] How does HA use routing table? > > > Hello all, > > > > I would appreciate it if anyone would answer my question. > > I think that the HA of Mobile IPv6 has a routing table as well as > > Binding Cache since it is a kind of router. It seems to me that > > Mobile IPv6 I-D does not say the relationship between the Binding > > Cache and the routing table, and how to use the routing table. > > My guess is as follows: > > > > 1) When the HA receives a packet, it firstly checks the Binding > > Cache whether a binding for the destination address of the packet > > exists or not. > > > > 2) If no binding exist in the Binding Cache, it secondly checks > > the routing table to find the best route for the packet. > > > > Is my understanding correct? > > > > Ichiro > > From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 15:09:43 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15924 for ; Mon, 4 Jun 2001 15:09:43 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17271; Mon, 4 Jun 2001 12:08:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09695; Mon, 4 Jun 2001 12:07:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54J5Cl20625 for mobile-ip-dist; Mon, 4 Jun 2001 12:05:12 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54J58e20618 for ; Mon, 4 Jun 2001 12:05:08 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA03059 for ; Mon, 4 Jun 2001 12:05:15 -0700 (PDT) Message-Id: <200106041905.MAA03059@heliopolis.eng.sun.com> Date: Mon, 4 Jun 2001 12:05:15 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] How does HA use routing table? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2trqttnvOf6aA/mwc8JDaw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: How about; The Home Agent MUST assure that the information in the binding cache is consistent with routing tables for the local subnet. If the Mobile Node as an entry in the routing table for the local subnet, then it MUST not have an entry in the binding cache, and vice versa. jak >X-Delivered-For: >X-mProtect: Mon, 4 Jun 2001 11:29:57 -0700 Nokia Silicon Valley Messaging Protection >Date: Mon, 04 Jun 2001 11:29:56 -0700 >From: "Charles E. Perkins" >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] How does HA use routing table? > >Hello, > >First, I concur with Ichiro Okajima's assessment of the intention >of the home agent procedure. > >If the home agent has a binding for the mobile node, then that is >authoritative. If there is a clash between the home agent's >routing table and its Binding Cache entry for the mobile node, >then that means something has gone wrong. In fact, if the >home agent doesn't have a binding cache entry for the mobile >node, it typically shouldn't get the packet at all except insofar >as the home agent is a default router for the home network. >In that case, then its action is well defined, and typically it >still wouldn't have a host-specific route for the mobile node. > >I usually consider the Binding Cache to be like a part of >the routing table anyway, with special flags. > >Can someone suggest an improvement to the wording of the >Mobile IPv6 specification to clarify this? > >Regards, >Charlie P. > > >Qiang Zhang wrote: >> >> I think for Agent to deliever the packet, the implication is that it should >> follow the routing table, even there is a binding cache for a packet. Does >> MIP have to address the issue? >> >> ----- Original Message ----- >> From: "Ichiro Okajima" >> To: >> Sent: Monday, June 04, 2001 1:11 AM >> Subject: [mobile-ip] How does HA use routing table? >> >> > Hello all, >> > >> > I would appreciate it if anyone would answer my question. >> > I think that the HA of Mobile IPv6 has a routing table as well as >> > Binding Cache since it is a kind of router. It seems to me that >> > Mobile IPv6 I-D does not say the relationship between the Binding >> > Cache and the routing table, and how to use the routing table. >> > My guess is as follows: >> > >> > 1) When the HA receives a packet, it firstly checks the Binding >> > Cache whether a binding for the destination address of the packet >> > exists or not. >> > >> > 2) If no binding exist in the Binding Cache, it secondly checks >> > the routing table to find the best route for the packet. >> > >> > Is my understanding correct? >> > >> > Ichiro >> > From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 17:51:27 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19925 for ; Mon, 4 Jun 2001 17:51:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00582; Mon, 4 Jun 2001 14:48:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26642; Mon, 4 Jun 2001 14:47:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54Lk7d20838 for mobile-ip-dist; Mon, 4 Jun 2001 14:46:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Lk3e20831 for ; Mon, 4 Jun 2001 14:46:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15209 for ; Mon, 4 Jun 2001 14:46:12 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19462 for ; Mon, 4 Jun 2001 15:46:10 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f54Lk9N13845 for ; Mon, 4 Jun 2001 23:46:09 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jun 04 23:46:09 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 23:46:08 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEAA@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Timings for FMIPv4 and FMIPv6 Date: Mon, 4 Jun 2001 23:46:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, A couple of comments on your mail: 1. MIPv6 does not run over UDP like MIPv4, so I don't know why you add 8 bytes for the UDP header. 2. I really question the assumption that MIP signalling can not run over the signalling channel. we ought to have some very good reasons before we can make a conclusion like that. Especially if we're judging the handover speed based on that assumption. This is purely an implementation issue and ultimately the IETF will not be the body making this decision. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 18:00:59 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20109 for ; Mon, 4 Jun 2001 18:00:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06243; Mon, 4 Jun 2001 15:00:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29200; Mon, 4 Jun 2001 14:58:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54LvH820892 for mobile-ip-dist; Mon, 4 Jun 2001 14:57:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54LvDe20885 for ; Mon, 4 Jun 2001 14:57:13 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10392 for ; Mon, 4 Jun 2001 14:57:15 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13274 for ; Mon, 4 Jun 2001 14:57:10 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f54Lv8N14724 for ; Mon, 4 Jun 2001 23:57:08 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jun 04 23:57:08 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 23:57:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEAB@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: [Q] Routing header Date: Mon, 4 Jun 2001 23:57:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mike, > > > This is mostly a mipv6 issue, but suppose you have: > > > > > > MN------->MR------------------------>CN > > > > > > When the mobile node moves, it sends a BU to the CN. > > > When the mobile router moves, it too sends a BU to the CN. > > > > This is only your scenario. You could think of any scenario you want. > > Anyway, this is something I have already raised in the MIP WG and this > > is presumably a case where MIPv6 would fail. > > I'm aware that this is only my scenario, but this is > what I think a naive implementation would do. Ie, > the mobile router would think it's supposed to send > a BU when it see something come in from its home agent > tunnel interface, the MN (or another MR) would > think it's supposed to send a BU... > => There is nothing naive about the implementation you're referring to. In fact it is so far from naive that it's inventing it's own standard. Nothing in any of the MIP specs allows a MN/MR to send a BU on behalf of another MN. _If_ the WG were to accept a proposal like this we would have to make sure that there is some delegation of athority from the MN to the MR to do so. I have no idea how to do that though. I think what Thierry's draft is sufficient, if we want route optimisation I think we should keep it end to end as the MIPv6 draft requires it to be. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 18:34:03 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20654 for ; Mon, 4 Jun 2001 18:34:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19593; Mon, 4 Jun 2001 15:32:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06753; Mon, 4 Jun 2001 15:32:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54MVVh21193 for mobile-ip-dist; Mon, 4 Jun 2001 15:31:31 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54MVSe21186 for ; Mon, 4 Jun 2001 15:31:28 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA14141 for ; Mon, 4 Jun 2001 15:31:35 -0700 (PDT) Message-Id: <200106042231.PAA14141@heliopolis.eng.sun.com> Date: Mon, 4 Jun 2001 15:31:35 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Timings for FMIPv4 and FMIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: l1R5bcRrIKDzQvqhpAh8oA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, >1. MIPv6 does not run over UDP like MIPv4, so I don't know >why you add 8 bytes for the UDP header. > Got it. I'll adjust the numbers. Thanx >2. I really question the assumption that MIP signalling >can not run over the signalling channel. we ought to have >some very good reasons before we can make a conclusion like >that. Especially if we're judging the handover speed based on that >assumption. This is purely an implementation issue and ultimately >the IETF will not be the body making this decision. > Well, I think we need to be realistic. If we are talking about current 3G protocols (which is what these numbers are designed to address), then I think we can't make any assumptions about using signalling channels, since they are strictly reserved for current radio link protocol signalling. The attraction of MIP to the mobile operators and wireless ISPs is that it fits into their networks without any change in the radio link protocol, which is practically impossible to do. That said, I think we can make a good case for doing the change in the radio link protocol if they want to integrate better with IP. There may be some interest in 3GPP2, probably none in 3GPP. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 18:50:59 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20920 for ; Mon, 4 Jun 2001 18:50:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06439; Mon, 4 Jun 2001 16:50:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10746; Mon, 4 Jun 2001 15:50:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54MnNP21336 for mobile-ip-dist; Mon, 4 Jun 2001 15:49:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54MnJe21329 for ; Mon, 4 Jun 2001 15:49:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21302 for ; Mon, 4 Jun 2001 15:49:26 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08106 for ; Mon, 4 Jun 2001 15:49:25 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f54MnON19725 for ; Tue, 5 Jun 2001 00:49:24 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Jun 05 00:49:24 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 00:44:04 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEAF@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Timings for FMIPv4 and FMIPv6 Date: Tue, 5 Jun 2001 00:49:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi James, > >2. I really question the assumption that MIP signalling > >can not run over the signalling channel. we ought to have > >some very good reasons before we can make a conclusion like > >that. Especially if we're judging the handover speed based on that > >assumption. This is purely an implementation issue and ultimately > >the IETF will not be the body making this decision. > > > > Well, I think we need to be realistic. If we are talking about current > 3G protocols (which is what these numbers are designed to address), > then I think we can't make any assumptions about using signalling > channels, since they are strictly reserved for current radio link protocol > signalling. The attraction of MIP to the mobile operators and wireless > ISPs is that it fits into their networks without any change in the > radio link protocol, which is practically impossible to do. > => As I was saying there may not be anything to change in the signalling channel depending on what system you're referring to. It might simply e an implementation issue. The idea is not so unreaslistic and in fact people do consider it for IP signalling. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 20:36:44 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22121 for ; Mon, 4 Jun 2001 20:36:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11451; Mon, 4 Jun 2001 18:36:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21951; Mon, 4 Jun 2001 17:36:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f550ZG221680 for mobile-ip-dist; Mon, 4 Jun 2001 17:35:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f550ZDe21673 for ; Mon, 4 Jun 2001 17:35:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17868 for ; Mon, 4 Jun 2001 17:35:20 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23944 for ; Mon, 4 Jun 2001 18:35:51 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA25397 for ; Mon, 4 Jun 2001 17:35:18 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f550ZHN32550 for ; Mon, 4 Jun 2001 17:35:17 -0700 X-mProtect: Mon, 4 Jun 2001 17:35:17 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdoPBwD1; Mon, 04 Jun 2001 17:35:15 PDT Message-ID: <3B1C2944.66D1DD56@iprg.nokia.com> Date: Mon, 04 Jun 2001 17:35:16 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IP address option, Fast Handoff draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, I have a question on the IP address option in the Fast Handoff draft (page 28). What is the need for a 32 bit reserved field there? the option just contains an IP address. and if for some reason, we do need a reserved field, can we eliminate the Length field from the option and make that the reserved field (8 bits)? the length of the IP address option is fixed. there is no need for the length field in this option. vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 4 21:49:51 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23921 for ; Mon, 4 Jun 2001 21:49:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22947; Mon, 4 Jun 2001 18:48:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11302; Mon, 4 Jun 2001 18:47:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f551kBV21848 for mobile-ip-dist; Mon, 4 Jun 2001 18:46:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f551k8e21841 for ; Mon, 4 Jun 2001 18:46:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01421 for ; Mon, 4 Jun 2001 18:46:16 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14385 for ; Mon, 4 Jun 2001 18:46:15 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f551kDN04371 for ; Tue, 5 Jun 2001 03:46:13 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jun 05 03:46:13 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 03:40:53 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEB7@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IP address option, Fast Handoff draft Date: Tue, 5 Jun 2001 03:46:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > can we > eliminate the Length field from the option and make that the > reserved field (8 bits)? the length of the IP address option > is fixed. there is no need for the length field in this option. > => The length field is included in every IPv6 option. The is explained in detail in RFC2460. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 06:55:47 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14436 for ; Tue, 5 Jun 2001 06:55:47 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09938; Tue, 5 Jun 2001 03:54:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18215; Tue, 5 Jun 2001 03:54:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55Ar4P22348 for mobile-ip-dist; Tue, 5 Jun 2001 03:53:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55Ar0e22341; Tue, 5 Jun 2001 03:53:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18097; Tue, 5 Jun 2001 03:53:05 -0700 (PDT) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18184; Tue, 5 Jun 2001 04:53:35 -0600 (MDT) Received: from yjkim2 (kimyj.etri.re.kr [129.254.164.113]) by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f55AsUZ02052; Tue, 5 Jun 2001 19:54:30 +0900 (KST) Message-ID: <02df01c0edaf$60a7e710$71a4fe81@yjkim2> From: "Dr. Yong-Jin Kim" To: , <6winit@cs.ucl.ac.uk>, , , , Subject: [mobile-ip] Global IPv6 Summit in Seoul Date: Tue, 5 Jun 2001 20:05:05 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DC_01C0EDFA.D0587980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_02DC_01C0EDFA.D0587980 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoaXMgaXMgYSByZW1pbmRlciB0aGF0IHRoZSBuZXh0IEdsb2JhbCBJUHY2 IFN1bW1pdCB3aWxsIGJlIGhlbGQgaW4NClNlb3VsIEp1bHkgMyAtIDYuIA0KDQpGb3IgdGhlIGNv bmZlcmVuY2UgcHJvZ3JhbSwgbmV3IHByZS1jb25mZXJlbmNlIHR1dG9yaWFsLCBhbmQgcmVnaXN0 cmF0aW9uDQpzZWUgaHR0cDovL3d3dy5pcHY2Lm9yLmtyL2lwdjZzdW1taXQNCg0KSW4ga2VlcGlu ZyB3aXRoIElQdjYgRm9ydW0ncyBtaXNzaW9uIHRvIGluY3JlYXNlIGF3YXJlbmVzcyBvZiBJUHY2 LCBwbGVhc2UNCnRha2UgYSBtaW51dGUgdG8gY29uc2lkZXIgd2hvIGFtb25nIHlvdXIgY29sbGVh Z3VlcyANCmNvdWxkIGJlbmVmaXQgZnJvbSB0aGlzIFN1bW1pdCBvcHBvcnR1bml0eSwgYW5kIGZv cndhcmQgdGhlbSB0aGlzIGNvbmZlcmVuY2UgaW5mb3JtYXRpb24uIA0KDQpSZWdhcmRzLA0KDQpZ b25nLUppbiBLaW0NCklQdjYgRm9ydW0NClByZXNpZGVudCBvZiBJUHY2IEZvcnVtIEtvcmVhDQoN Cg== ------=_NextPart_000_02DC_01C0EDFA.D0587980 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1rc19jXzU2MDEtMTk4NyI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwg NS41MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9ND48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05UIA0Kc2l6ZT0z PkRlYXIgYWxsLDwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTQ+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48 Rk9OVCANCnNpemU9Mz48L0ZPTlQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT00PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3 IFJvbWFuJyI+PEZPTlQgDQpzaXplPTM+VGhpcyBpcyBhIHJlbWluZGVyIHRoYXQgdGhlIG5leHQg R2xvYmFsIElQdjYgU3VtbWl0IHdpbGwgYmUgaGVsZCANCmluPEJSPlNlb3VsIEp1bHkgMyAtIDYu IDxCUj48QlI+Rm9yIHRoZSBjb25mZXJlbmNlIHByb2dyYW0sIG5ldyBwcmUtY29uZmVyZW5jZSAN CnR1dG9yaWFsLCBhbmQgcmVnaXN0cmF0aW9uPEJSPnNlZSA8L0ZPTlQ+PEEgDQpocmVmPSJodHRw Oi8vd3d3LmZvcmV0ZWMuY29tL0lQdjYtaW5kZXguaHRtIj48Rk9OVCBzaXplPTM+PEEgDQpocmVm PSJodHRwOi8vd3d3LmlwdjYub3Iua3IvaXB2NnN1bW1pdCI+aHR0cDovL3d3dy48L0ZPTlQ+PC9B PjxGT05UIA0Kc2l6ZT0zPmlwdjYub3Iua3IvaXB2NnN1bW1pdDwvQT48QlI+PEJSPkluIGtlZXBp bmcgd2l0aCZuYnNwO0lQdjYgRm9ydW0ncyANCm1pc3Npb24gdG8gaW5jcmVhc2UgYXdhcmVuZXNz IG9mIElQdjYsIHBsZWFzZTxCUj50YWtlIGEgbWludXRlIHRvIGNvbnNpZGVyIHdobyANCmFtb25n IHlvdXIgY29sbGVhZ3VlcyA8QlI+Y291bGQgYmVuZWZpdCBmcm9tIHRoaXMgU3VtbWl0IG9wcG9y dHVuaXR5LCBhbmQgDQpmb3J3YXJkIHRoZW0gdGhpcyBjb25mZXJlbmNlIGluZm9ybWF0aW9uLiA8 QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj5Zb25nLUppbiANCktpbTwvRk9OVD48L1NQQU4+PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTQ+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48Rk9OVCANCnNpemU9Mz5JUHY2IEZvcnVtPC9GT05U PjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9ND48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05UIA0Kc2l6ZT0zPlBy ZXNpZGVudCBvZiBJUHY2IEZvcnVtIA0KS29yZWE8L0ZPTlQ+PEJSPjwvU1BBTj48L0ZPTlQ+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_02DC_01C0EDFA.D0587980-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 07:10:27 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14950 for ; Tue, 5 Jun 2001 07:10:26 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14803; Tue, 5 Jun 2001 04:08:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19670; Tue, 5 Jun 2001 04:08:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55B4ih22442 for mobile-ip-dist; Tue, 5 Jun 2001 04:04:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55B4fe22435 for ; Tue, 5 Jun 2001 04:04:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23549 for ; Tue, 5 Jun 2001 04:04:47 -0700 (PDT) Received: from quicksilver.ukc.ac.uk (quicksilver.ukc.ac.uk [129.12.21.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28381 for ; Tue, 5 Jun 2001 05:04:45 -0600 (MDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by quicksilver.ukc.ac.uk with esmtp (Exim 3.22 #4) id 157Eda-0000wJ-00 for mobile-ip@sunroof.eng.sun.com; Tue, 05 Jun 2001 12:04:38 +0100 Received: from pccomm6.ukc.ac.uk ([129.12.50.121] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 157Edi-0001Kz-00 for mobile-ip@sunroof.eng.sun.com; Tue, 05 Jun 2001 12:04:46 +0100 Message-ID: <3B1CBCCD.33588D96@ukc.ac.uk> Date: Tue, 05 Jun 2001 12:04:45 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Many BS to a Single MN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Is it possible for a mobile node to be connected to more than one BS at a time, however only receiving transmission from one base station. Well this scenario exist when the mobile node is a the cell edge, but how about when the mobile node is in any position of the cell. Would there be a performance issues, for example, would this generate too much interference to other mobile nodes within the cell. Are there any papers that discusses this issue. Can someone point me in the right direction. Thanks INdran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Electronics Engineering Laboratory \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \ Telephone(Mobile): +44 (0)7765 007016 / \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 08:52:31 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18417 for ; Tue, 5 Jun 2001 08:52:28 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16457; Tue, 5 Jun 2001 05:52:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28116; Tue, 5 Jun 2001 05:51:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55CoRu22620 for mobile-ip-dist; Tue, 5 Jun 2001 05:50:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55CoNe22613 for ; Tue, 5 Jun 2001 05:50:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02653 for ; Tue, 5 Jun 2001 05:50:30 -0700 (PDT) Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21559 for ; Tue, 5 Jun 2001 06:51:00 -0600 (MDT) Received: by mx02.melco.co.jp (mx02) id VAA29824; Tue, 5 Jun 2001 21:50:26 +0900 (JST) Received: by mr02.melco.co.jp (mr02) id VAA01114; Tue, 5 Jun 2001 21:50:26 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id VAA09254; Tue, 5 Jun 2001 21:50:25 +0900 (JST) Received: from ishitp570 by islgw.isl.melco.co.jp (8.8.8/3.6W) id VAA04714; Tue, 5 Jun 2001 21:50:24 +0900 (JST) Message-ID: <015b01c0edbe$442be370$1a084a0a@ishitp570> From: "Koichi Ishibashi" To: Cc: "Ishibashi" Subject: [mobile-ip] behavior on Mobility Agent during Mobile IP handoff Date: Tue, 5 Jun 2001 21:51:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello all, I have a question on Low Latency Handoff in Mobile IPv4. This is as follows. In the , the old FA MUST bi-cast all packets destined to the MN to both the L2 to which the MN is currently connected and by tunneling to the new FA. However, when the MN has some microflows (for example, one microflow supports a real-time service, and the other supports non-real-time service), should the FA apply the same procedure on bi-casting & forwarding to all microflows? Here, I read the Perkins's comment that the Mobile IP should be considered to be a protocol that deals (solely) with terminal mobility. On the other hand, proposes the session specific extension that is used to differentiate the multiple microflows from the same MN. In my opinion, I think that a future network should support a QoS mechanism and a mobile network should need to support a QoS also. When the mobile network supports a QoS, I think that a mobility agent should also support a QoS and differentiate the microflows. And the above support of QoS should be applied to a Handoff procedure as well as a Tunneling and Forwarding procedure. For example, according to an implicit or explicit configuration, a mobility agent should decide whether to bi-cast the packets for each microflow or not. Is that correct? Any comments will be good enough to me. Thanks you in advance. Ishibashi From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 10:28:39 2001 Received: from patan.sun.com ([192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22244 for ; Tue, 5 Jun 2001 10:28:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04320; Tue, 5 Jun 2001 08:26:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23760; Tue, 5 Jun 2001 07:26:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55EPBx22749 for mobile-ip-dist; Tue, 5 Jun 2001 07:25:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55EP8e22742 for ; Tue, 5 Jun 2001 07:25:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13786 for ; Tue, 5 Jun 2001 07:25:14 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24131 for ; Tue, 5 Jun 2001 07:25:12 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f55EPAO29225 for ; Tue, 5 Jun 2001 16:25:11 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jun 05 16:25:10 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 16:25:09 +0200 Message-ID: <795A014AF92DD21182AF0008C7A404320C5203FF@esealnt117> From: "Karim El-Malki (ERA)" To: "'Koichi Ishibashi '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] behavior on Mobility Agent during Mobile IP hando ff Date: Tue, 5 Jun 2001 16:25:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello >In the , >the old FA MUST bi-cast all packets destined to the MN >to both the L2 to which the MN is currently connected >and by tunneling to the new FA. > >However, when the MN has some microflows (for example, >one microflow supports a real-time service, and >the other supports non-real-time service), >should the FA apply the same procedure on >bi-casting & forwarding to all microflows? For the basic low latency handoff we've assumed this. Doing otherwise would require a protocol with which the MN informs the FA what to do with each traffic flow or having the FA independently sniff and decide what to do with each packet. For the moment I think it is appropriate that this was not considered so as to solve basic handoff improvement first. Once we conclude on a basic solution we can get to these enhancements. Currently all traffic flows get the same (best) treatment. >In my opinion, I think that a future network should >support a QoS mechanism and a mobile network should >need to support a QoS also. >When the mobile network supports a QoS, >I think that a mobility agent should also support 0>a QoS and differentiate the microflows. >And the above support of QoS should be applied to >a Handoff procedure as well as a Tunneling and >Forwarding procedure. >For example, according to an implicit or explicit configuration, >a mobility agent should decide whether to bi-cast the packets >for each microflow or not. I'd say that can be considered but only simulations can tell us how much gain can come out of differentiating the FA behaviour during a fast handoff. If you don't bicast on some flows will that gain you much compared to the added FA complexity? It's quite important to find out before adding this function. Regards /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 11:52:59 2001 Received: from mercury.Sun.COM ([192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24018 for ; Tue, 5 Jun 2001 11:52:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13685; Tue, 5 Jun 2001 08:50:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08848; Tue, 5 Jun 2001 08:48:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55FloK22877 for mobile-ip-dist; Tue, 5 Jun 2001 08:47:50 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55Flke22870 for ; Tue, 5 Jun 2001 08:47:46 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA29259; Tue, 5 Jun 2001 08:47:53 -0700 (PDT) Message-Id: <200106051547.IAA29259@heliopolis.eng.sun.com> Date: Tue, 5 Jun 2001 08:47:53 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] behavior on Mobility Agent during Mobile IP handoff To: mobile-ip@sunroof.eng.sun.com Cc: ishi@isl.melco.co.jp MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: BzINLKeW9uLHWRld5/GXIw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The tunnelling has strictly to do with terminal mobility. When the mobile node moves to the new FA, there may be a period of time in which it does not yet have a new CoA or cannot use the new CoA. During that period of time, it should be able to send/receive with the old CoA. Naturally, this is important primarily for real time traffic, but there is no reason why other traffic shouldn't be afforded the same benefit. I don't see what QoS has to do with this. Within the edge wired network, I don't think capacity will limiting, or, at least, if good network engineering principles are applied, it should not be. I suppose one could set up classes of service and afford mobiles that have subscribed to a higher class the benefit of tunnels while mobiles that subscribe to best effort don't get them, but I think that is an independent issue and is up to the network provider. BTW, both GPRS and IOS use this technique currently, but at L2. In IOS, for example, if a mobile node moves to a new PDSN while a data session is up, it extends the PPP tunnel to the new PDSN until it has time to obtain a new CoA. jak >From: "Koichi Ishibashi" >To: >Cc: "Ishibashi" >Subject: [mobile-ip] behavior on Mobility Agent during Mobile IP handoff >Date: Tue, 5 Jun 2001 21:51:40 +0900 >X-Priority: 3 >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 > >Hello all, > >I have a question on Low Latency Handoff in Mobile IPv4. >This is as follows. > >In the , >the old FA MUST bi-cast all packets destined to the MN >to both the L2 to which the MN is currently connected >and by tunneling to the new FA. > >However, when the MN has some microflows (for example, >one microflow supports a real-time service, and >the other supports non-real-time service), >should the FA apply the same procedure on >bi-casting & forwarding to all microflows? > >Here, >I read the Perkins's comment that the Mobile IP should >be considered to be a protocol that deals (solely) >with terminal mobility. >On the other hand, >proposes the session specific extension that is used to >differentiate the multiple microflows from the same MN. > >In my opinion, I think that a future network should >support a QoS mechanism and a mobile network should >need to support a QoS also. >When the mobile network supports a QoS, >I think that a mobility agent should also support >a QoS and differentiate the microflows. >And the above support of QoS should be applied to >a Handoff procedure as well as a Tunneling and >Forwarding procedure. >For example, according to an implicit or explicit configuration, >a mobility agent should decide whether to bi-cast the packets >for each microflow or not. > >Is that correct? > >Any comments will be good enough to me. >Thanks you in advance. > >Ishibashi > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 17:51:37 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00446 for ; Tue, 5 Jun 2001 17:51:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04088; Tue, 5 Jun 2001 15:43:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08031; Tue, 5 Jun 2001 14:43:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55LfnN23732 for mobile-ip-dist; Tue, 5 Jun 2001 14:41:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55Lfje23722 for ; Tue, 5 Jun 2001 14:41:45 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27096 for ; Tue, 5 Jun 2001 14:41:53 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04132 for ; Tue, 5 Jun 2001 14:41:47 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA27354 for ; Tue, 5 Jun 2001 14:41:46 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA23401 for ; Tue, 5 Jun 2001 14:41:46 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 16:41:46 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C71@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" , "'James.Kempf@Sun.COM'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Tue, 5 Jun 2001 16:41:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, Thanks for sending the analysis and sorry for my late response, I am still catching up with the list. The analysis made me go and read the new version of the draft! So now I am even more behind on the list, sorry if there has been more exchange on this. I have one question and a few comments. First, shouldn't you include the propagation delay from the oldAR to the MN and back into the calculation? Speed of light is 1 ns/foot=3ns/meter=3ms/km, so in a CDMA cell of about 3Km in radius, you have 10 ms propagation delay in each direction, which mean 20 ms total. Also, I don't know what WCDMA does these days, but don't they add some padding to the layer 3 signal (maybe that is not too big :) ) Now, my question isn't HI/HACK between oldAR/ newAR included in stateful case, aren't those messages in critical path? I saw your comment about Mobile determined case (that HI/HACK should be included). Doesn't the same apply to Network determined stateful? Again the HI/HACK has both transmission delay and propagation delay. Thanks, Madjid Nakhjiri -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Monday, May 14, 2001 4:40 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff As an interesting exercise, I went through some calculations about how long an IPv6 low latency handoff would take in some of the scenerios described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the following cases: - Network determined, stateless with the following two subcases: - F-BU/F-BACK received before handoff - F-BU/F-BACK received after handoff - Network deterimed, stateful - Mobile determined, with the following two subcases: - F-BU/F-BACK received before handoff - F-BU/F-BACK received after handoff I also made the following assumptions: - Prior to handoff, the header compressor on the old AR is "hot" enough to compress the basic 40 byte IPv6 header down to 1 byte, but after handoff, the header compressor is "cold" and so the full IPv6 header needs to be sent. Currently, there is some debate about whether the compressor could be partially restarted on the new AR using context transfer, so this could introduce an additional optimization and also a potential area of timing uncertainty involving the context transfer time itself. - The BU/BACK pair completes on either side of the handoff. In actuality, it may span the handoff and Section 3.3 may come into play if the MN doesn't get a BACK back (so to speak) fast enough. Or, an additional BU may need to be sent. I view the assumptions made here as being fairly optimistic, since over the air signalling after L2 has indicated that handover is pending is likely to be subject to a considerably higher error rate due to deteriorating radio conditions in the old cell and not-yet improved radio conditions in the new. - The radio link layer is using its lowest bit rate for signalling. This assumption is based on either using a multiplexed common channel for signalling, in which case the MN would have to share the channel with other MNs in the cell, or using a dedicated channel but not wanting to charge the user much or nothing at all, and therefore not wanting to use a higher bandwidth. Of course, this will be radio-specific, but it seems like a good assumption for cellular systems. The value I used was 7.5 kbps (940 bytes/sec), which is the minimum for a wCDMA dedicated channel from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. - The wired link ARs use Ethernet (48 bit MAC address link layer) and the wireless link is using 15 byte IMSIs (International Mobile Station Identifiers) sent as ASCII digits. - The MN can neither send or receive traffic on the new AR until the old AR has confirmed the new CoA via a F-BACK. Here's the results. Network Determined, Stateless ----------------------------- As near as I can tell, the following messages get exchanged over the air: PrRtAdv, F-BU, F-BACK. Sizes of these are: hdr msg lnkAddrOpt prxLnkAddrOpt newCoA Total PrRtAdv 1 8 9 9 24 51 F-BU before 1 10 11 F-BU after 40 10 50 F-BACK before 1 9 10 F-BACK after 40 9 49 Total over the air sizes: F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes F-BU/F-BACK after: 51 + 50 + 49 = 150 bytes Times: F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec. F-BU/F-BACK after: 150 bytes/ 940 bytes/sec = 0.160 sec = 160 msec. However, total handoff time will consist of the above plus a nondeterministic amount of time involved in L2 handoff and the amount of processing time required on new AR to perform DAD and process the HI/HACK pair. Perhaps one could use the maximum of L2 handover time and HI/HACK processing time as an estimate to add to the above. Network Determined, Stateful ---------------------------- Messages exchanged over the air- PrRtAdv prior to handoff. Byte counts the same as the above. No F-BU/F-BACK needed, so the only over the air message required is the PrRtAdv. Total over the air size: PrRtAdv size: 51 bytes Time: 51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec. L2 handover time needs to be added. Mobile Determined ----------------- Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK. Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr sent by MN is done prior to L2 handoff. hdr RtSolPr MNlnkAddrOpt newAttPtLnkOpt Total RtSolPr 1 8 18 9 36 Total over the air sizes: F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes F-BU/F-BACK after: 36 + 51 + 50 + 49 = 186 bytes Times: F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms F-BU/F-BACK after: 198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms Again, the maximum of L2 handoff time and HI/HACK processing time would need to be included. Conclusions ----------- What conclusions to draw? These time range from respectible (55 ms for network determined, stateful) to the clearly questionable (198 ms for mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms maximum for delay before the user notices with real time voice traffic. Depending on the amount of time required for the L2 handover, the HI/HACK processing time, and any time required to send buffered traffic to the MN if buffering is used on the old AR, the mobile determined, F-BU/F-BACK sent after case could easily exceed the ITU guideline, as almost 2/3 of the noticable delay time is taken up by the L3 handoff. The others require less L3 handoff time, but only the network determined, stateless, F-BU/F-BACK before and the network determined, stateful are less than or equal to about 1/4 of the ITU guideline. Clearly, header compression on the new AR could help a lot. IPv6 headers are big, and if there were some way the header compressors on MN and new AR could be jump started prior to handoff, the 40 byte header overhead could be eliminated. Alternatively, if the link layer can guarantee that the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't occur. Using a higher bandwidth channel could help also. Please send any comments or corrections (in case my math is wrong). jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 17:53:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00468 for ; Tue, 5 Jun 2001 17:53:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11439; Tue, 5 Jun 2001 15:51:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09777; Tue, 5 Jun 2001 14:51:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55LoSf23793 for mobile-ip-dist; Tue, 5 Jun 2001 14:50:28 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55LoOe23786 for ; Tue, 5 Jun 2001 14:50:25 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA20663; Tue, 5 Jun 2001 14:50:33 -0700 (PDT) Message-Id: <200106052150.OAA20663@heliopolis.eng.sun.com> Date: Tue, 5 Jun 2001 14:50:33 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff To: mobile-ip@sunroof.eng.sun.com, James.Kempf@Sun.COM, Madjid.Nakhjiri@motorola.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZrIO3nhV7ucgT/q0g4OqRQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >First, shouldn't you include the propagation delay from the oldAR to >the MN and back into the calculation? >Speed of light is 1 ns/foot=3ns/meter=3ms/km, so >in a CDMA cell of about 3Km in radius, you have 10 ms >propagation delay in each direction, which mean 20 ms total. > I assume that is built into the user level bit rate figures Holma and Toskala give for WCDMA. >Also, I don't know what WCDMA does these days, but don't they add >some padding to the layer 3 signal (maybe that is not too big :) ) > Typically, radio frames are much smaller than IP packets (on the order of 40 bytes). It is possible that there may be padding if a packet won't fit into an even number of frames, but, again, I was using the user level throughput figures. >Now, my question isn't HI/HACK between oldAR/ newAR included in stateful >case, aren't >those messages in critical path? I saw your comment about Mobile >determined case (that HI/HACK should be included). Doesn't the same >apply to Network determined stateful? > >Again the HI/HACK has both transmission delay and propagation delay. > Signalling across the wired backbone is typically less than 10 ms. I believe I calculated something in the submillisecond range for T1 on the HI/HACK. So it's basically in the noise, as far as the radio link is concerned. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 18:18:42 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00710 for ; Tue, 5 Jun 2001 18:18:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27536; Tue, 5 Jun 2001 15:15:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14969; Tue, 5 Jun 2001 15:15:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55ME0x23883 for mobile-ip-dist; Tue, 5 Jun 2001 15:14:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55MDue23876 for ; Tue, 5 Jun 2001 15:13:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02886 for ; Tue, 5 Jun 2001 15:14:02 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08004; Tue, 5 Jun 2001 15:14:02 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f55ME4U19616; Tue, 5 Jun 2001 15:14:05 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHT00859; Tue, 5 Jun 2001 15:14:00 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA09626; Tue, 5 Jun 2001 15:14:00 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15133.22951.961734.300541@thomasm-u1.cisco.com> Date: Tue, 5 Jun 2001 15:13:59 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: "'James.Kempf@Sun.COM'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B1B7C71@IL27EXM10.cig.mot.com> References: <35DBB8B7AC89D4118E98009027B1009B1B7C71@IL27EXM10.cig.mot.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Er Madjid, my physics book sez that c ~= 3x10^8 m/s. that makes a km about 1/3x10^5 (in vacuum) so even allowing for wire/fiber, you seem to be off by a couple of orders of magnitude. Mike Nakhjiri Madjid-MNAKHJI1 writes: > James, > > Thanks for sending the analysis and sorry for my late response, > I am still catching up with the list. The analysis made me > go and read the new version of the draft! So now I am even more > behind on the list, sorry if there has been more exchange on this. > > I have one question and a few comments. > > First, shouldn't you include the propagation delay from the oldAR to > the MN and back into the calculation? > Speed of light is 1 ns/foot=3ns/meter=3ms/km, so > in a CDMA cell of about 3Km in radius, you have 10 ms > propagation delay in each direction, which mean 20 ms total. > > Also, I don't know what WCDMA does these days, but don't they add > some padding to the layer 3 signal (maybe that is not too big :) ) > > Now, my question isn't HI/HACK between oldAR/ newAR included in stateful > case, aren't > those messages in critical path? I saw your comment about Mobile > determined case (that HI/HACK should be included). Doesn't the same > apply to Network determined stateful? > > Again the HI/HACK has both transmission delay and propagation delay. > > Thanks, > Madjid Nakhjiri > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Monday, May 14, 2001 4:40 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff > > > As an interesting exercise, I went through some calculations about how > long an IPv6 low latency handoff would take in some of the scenerios > described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the > following cases: > > - Network determined, stateless with the following two subcases: > - F-BU/F-BACK received before handoff > - F-BU/F-BACK received after handoff > > - Network deterimed, stateful > > - Mobile determined, with the following two subcases: > - F-BU/F-BACK received before handoff > - F-BU/F-BACK received after handoff > > I also made the following assumptions: > > - Prior to handoff, the header compressor on the old AR is > "hot" enough to compress the basic 40 byte IPv6 header down > to 1 byte, but after handoff, the header compressor is "cold" > and so the full IPv6 header needs to be sent. Currently, there > is some debate about whether the compressor could be partially > restarted on the new AR using context transfer, so this could > introduce an additional optimization and also a potential > area of timing uncertainty involving the context transfer > time itself. > > - The BU/BACK pair completes on either side of the handoff. > In actuality, it may span the handoff and Section 3.3 may > come into play if the MN doesn't get a BACK back (so to > speak) fast enough. Or, an additional BU may need to be sent. > I view the assumptions made here as being fairly optimistic, > since over the air signalling after L2 has indicated that > handover is pending is likely to be subject to a considerably > higher error rate due to deteriorating radio conditions in > the old cell and not-yet improved radio conditions in the new. > > - The radio link layer is using its lowest bit rate for signalling. > This assumption is based on either using a multiplexed common > channel for signalling, in which case the MN would have to share > the channel with other MNs in the cell, or using a dedicated > channel but not wanting to charge the user much or nothing at > all, and therefore not wanting to use a higher bandwidth. Of > course, this will be radio-specific, but it seems like a good > assumption for cellular systems. The value I used was 7.5 kbps > (940 bytes/sec), which is the minimum for a wCDMA dedicated channel > from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > > - The wired link ARs use Ethernet (48 bit MAC address link > layer) and the wireless link is using 15 byte IMSIs (International > Mobile Station Identifiers) sent as ASCII digits. > > - The MN can neither send or receive traffic on the new AR until > the old AR has confirmed the new CoA via a F-BACK. > > Here's the results. > > Network Determined, Stateless > ----------------------------- > > As near as I can tell, the following messages get exchanged over the > air: PrRtAdv, F-BU, F-BACK. > > Sizes of these are: > > hdr msg lnkAddrOpt prxLnkAddrOpt newCoA Total > > PrRtAdv 1 8 9 9 24 51 > > F-BU > before 1 10 11 > > F-BU > after 40 10 50 > > F-BACK > before 1 9 10 > > F-BACK > after 40 9 49 > > Total over the air sizes: > > F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes > F-BU/F-BACK after: 51 + 50 + 49 = 150 bytes > > Times: > > F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec. > F-BU/F-BACK after: 150 bytes/ 940 bytes/sec = 0.160 sec = 160 msec. > > However, total handoff time will consist of the above plus a > nondeterministic amount of time involved in L2 handoff and the > amount of processing time required on new AR to perform DAD and > process the HI/HACK pair. Perhaps one could use the maximum > of L2 handover time and HI/HACK processing time as an estimate > to add to the above. > > Network Determined, Stateful > ---------------------------- > > Messages exchanged over the air- PrRtAdv prior to handoff. > > Byte counts the same as the above. No F-BU/F-BACK needed, so the > only over the air message required is the PrRtAdv. > > Total over the air size: > > PrRtAdv size: 51 bytes > > Time: > > 51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec. > > L2 handover time needs to be added. > > Mobile Determined > ----------------- > > Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK. > > Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr > sent by MN is done prior to L2 handoff. > > hdr RtSolPr MNlnkAddrOpt newAttPtLnkOpt Total > > RtSolPr 1 8 18 9 36 > > Total over the air sizes: > > F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes > F-BU/F-BACK after: 36 + 51 + 50 + 49 = 186 bytes > > Times: > > F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms > F-BU/F-BACK after: 198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms > > Again, the maximum of L2 handoff time and HI/HACK processing time > would need to be included. > > Conclusions > ----------- > > What conclusions to draw? These time range from respectible (55 ms > for network determined, stateful) to the clearly questionable (198 ms for > mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms > maximum for delay before the user notices with real time voice traffic. > Depending on the amount of time required for the L2 handover, the HI/HACK > processing time, and any time required to send buffered traffic to > the MN if buffering is used on the old AR, the mobile determined, > F-BU/F-BACK > sent after case could easily exceed the ITU guideline, as almost 2/3 > of the noticable delay time is taken up by the L3 handoff. The others > require less L3 handoff time, but only the network determined, stateless, > F-BU/F-BACK before and the network determined, stateful are less than > or equal to about 1/4 of the ITU guideline. > > Clearly, header compression on the new AR could help a lot. IPv6 headers > are big, and if there were some way the header compressors on MN and new AR > could be jump started prior to handoff, the 40 byte header overhead could be > eliminated. Alternatively, if the link layer can guarantee that > the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't > occur. Using a higher bandwidth channel could help also. > > Please send any comments or corrections (in case my math is wrong). > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 5 18:26:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00813 for ; Tue, 5 Jun 2001 18:26:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07480; Tue, 5 Jun 2001 16:24:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17563; Tue, 5 Jun 2001 15:24:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55MNbM24024 for mobile-ip-dist; Tue, 5 Jun 2001 15:23:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55MNXe24017 for ; Tue, 5 Jun 2001 15:23:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14425 for ; Tue, 5 Jun 2001 15:23:40 -0700 (PDT) Received: from mailsys01.intnet.net (antares.intnet.net [198.252.32.143]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07178 for ; Tue, 5 Jun 2001 16:24:10 -0600 (MDT) Received: from [206.112.126.114] ([206.112.126.114] verified) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 9260639; Tue, 05 Jun 2001 18:22:41 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: ahmrphd@pop3.attglobal.net Message-Id: In-Reply-To: <200106052150.OAA20663@heliopolis.eng.sun.com> Date: Tue, 5 Jun 2001 15:22:08 -0700 To: mobile-ip@sunroof.eng.sun.com, James.Kempf@Sun.COM, Madjid.Nakhjiri@motorola.com From: Arthur Ross Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: At 14:50 -0700 06/05/2001, James Kempf wrote: >> >>First, shouldn't you include the propagation delay from the oldAR to >>the MN and back into the calculation? >>Speed of light is 1 ns/foot=3ns/meter=3ms/km, so >>in a CDMA cell of about 3Km in radius, you have 10 ms >>propagation delay in each direction, which mean 20 ms total. >> Shame on you Madjid - A slap of the ol' grammar school teachers ruler! That's 3 MICROseconds (roughly) per km. [C=299.792458 m/microsec] > >Signalling across the wired backbone is typically less than 10 ms. >I believe I calculated something in the submillisecond range for >T1 on the HI/HACK. So it's basically in the noise, as far as >the radio link is concerned. > Typically a LOT less than 10 ms, I would guess. Old BTL measurements of the REAL prop delay (i.e. group delay in the 300-3000 Hz band) in the voice network showed, IIRC, typically about 25% of C, calculated using the airline distance between the endpoints, which winds up being circa 50 ms for a transit of the entire US of A. The 25% accounted for all the PCM sample buffering, analog group delays, etc. ... everything - it was a pretty good, statistically sound measurement. Seconding Jim's comments, the major contributions to the signaling will be the L2-ish things - framing (if used), interleaving, coding, transmission time, decoding, etc - most of which are proportional to message length, not the EM prop delay. I haven't been paying much attention to this lately, but I think it's time to get caught up .... -- Best, ahmr From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 08:46:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28535 for ; Wed, 6 Jun 2001 08:46:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06534; Wed, 6 Jun 2001 06:44:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18912; Wed, 6 Jun 2001 05:43:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56Ch1A25328 for mobile-ip-dist; Wed, 6 Jun 2001 05:43:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Cgwe25321 for ; Wed, 6 Jun 2001 05:42:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18785 for ; Wed, 6 Jun 2001 05:43:05 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05788 for ; Wed, 6 Jun 2001 06:43:03 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f56CfRg00210; Wed, 6 Jun 2001 14:41:27 +0200 (MEST) Message-ID: <3B1E2556.DBD29C1B@inrialpes.fr> Date: Wed, 06 Jun 2001 14:43:02 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP , NS Subject: [mobile-ip] NS-2.1b6 Mobile IPv6 release Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear all, As many people asked for it, I am glad to announce the release of our NS-2.1b6 enhancements to simulate Mobile IPv6 in large Wide-Area networks. This code has been developed by MOTOROLA Labs Paris and INRIA Rhone-Alpes PLANETE team. For information, and to download the code, please check http://www.inrialpes.fr/planete/mobiwan/ Presently, the tar file comprises: - Mobile IPv6 and simple IPv6 extensions needed by Mobile IPv6 - A library to create, configure, and manipulate large topologies in a very easy manner (TOPOMAN) - A new translator from GT-ITM to NS-2 which output TOPOMAN procedure calls. - Embedded extensions to allow the simultaneous use of wireless features, mobility, and multicast. Mobile IPv6 is available, in two modes: 1. Local mobility (i.e. within an administrative domain, i.e. within a bounded area) 2. Global mobility (crossing administrative domains, i.e. moving from one side of the topology to another). Hierarchical Mobile IPv6 will later be included in the distribution and will be used to demonstrate global mobility. This code comes without guaranties and may have bugs. If you find some, please tell me and also include the patch if you have one. If you cannot download the code, please email me and tell me why, I will try to be helpful whenever possible, but I might always have the time to be very responsive. Any feedback about the code is also very much appreciated. I hope you could make good use of this contribution. Regards, Thierry -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 08:49:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28714 for ; Wed, 6 Jun 2001 08:49:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08970; Wed, 6 Jun 2001 06:47:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19470; Wed, 6 Jun 2001 05:47:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56Cklu25378 for mobile-ip-dist; Wed, 6 Jun 2001 05:46:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Ckie25371 for ; Wed, 6 Jun 2001 05:46:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19331 for ; Wed, 6 Jun 2001 05:46:51 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13344 for ; Wed, 6 Jun 2001 06:47:22 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f56CjDg00356 for ; Wed, 6 Jun 2001 14:45:13 +0200 (MEST) Message-ID: <3B1E2639.7B2EF46C@inrialpes.fr> Date: Wed, 06 Jun 2001 14:46:49 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? References: <3B122BB0.E1DADB5@netas.com.tr> <3B122E38.AFAF5EE2@inrialpes.fr> <004e01c0e94a$ed7e1a10$50fba78f@borg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The code and some information is now available on http://www.inrialpes.fr/planete/mobiwan/. Make good use of it ! Thierry. cny wrote: > > Hi Thierry > > I am also very interested in this as well. > > Cheers Man > Chern Nam Yap > > ----- Original Message ----- > From: "Thierry Ernst" > To: ; "Oner Tekin" > Sent: Monday, May 28, 2001 12:53 PM > Subject: Re: [mobile-ip] Mobile IPv6 simulation tool? > > > Oner Tekin wrote: > > > Do you know any simulator which supports to MobileIPv6? > > > > I do have one. > > We have (MOTORLA Labs and INRIA Rhone Alpes Project PLANETE) have > > developped NS-2.1b6 extensions to support Mobile IPv6 - it is not yet > > contributed to the NS distribution suite, but we will do it very > > recently. > > > > Please contact me if you are interested. > > > > > > Thierry. > > > > > > -- > > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > > * and MOTOROLA Labs Paris > > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 10:11:01 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01493 for ; Wed, 6 Jun 2001 10:11:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10073; Wed, 6 Jun 2001 08:09:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02572; Wed, 6 Jun 2001 07:09:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56E8CS25464 for mobile-ip-dist; Wed, 6 Jun 2001 07:08:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56E89e25457 for ; Wed, 6 Jun 2001 07:08:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09188 for ; Wed, 6 Jun 2001 07:08:15 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08757 for ; Wed, 6 Jun 2001 08:08:14 -0600 (MDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA18650 for ; Wed, 6 Jun 2001 09:08:14 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f56E8ED18875 for ; Wed, 6 Jun 2001 09:08:14 -0500 (CDT) Message-ID: <3B1E394D.DD409F75@usa.alcatel.com> Date: Wed, 06 Jun 2001 09:08:13 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NS-2.1b6 Mobile IPv6 release References: <3B1E2556.DBD29C1B@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I tried to install Mobile-IPv6 from your website.But, many files in that package have some peculiar names which ca be viewed with Netscape, but not on the shell....When the say "ls" at my shell , the shell just hangs...What should I do with such files... Thierry Ernst wrote: > Dear all, > > As many people asked for it, I am glad to announce the release of our > NS-2.1b6 enhancements to simulate Mobile IPv6 in large Wide-Area > networks. This code has been developed by MOTOROLA Labs Paris and INRIA > Rhone-Alpes PLANETE team. > > For information, and to download the code, please check > http://www.inrialpes.fr/planete/mobiwan/ > > Presently, the tar file comprises: > - Mobile IPv6 and simple IPv6 extensions needed by Mobile IPv6 > - A library to create, configure, and manipulate large topologies in a > very easy manner (TOPOMAN) > - A new translator from GT-ITM to NS-2 which output TOPOMAN procedure > calls. > - Embedded extensions to allow the simultaneous use of wireless > features, mobility, and multicast. > > Mobile IPv6 is available, in two modes: > 1. Local mobility (i.e. within an administrative domain, i.e. within a > bounded area) > 2. Global mobility (crossing administrative domains, i.e. moving from > one side of the topology to another). > > Hierarchical Mobile IPv6 will later be included in the distribution and > will be used to demonstrate global mobility. > > This code comes without guaranties and may have bugs. If you find > some, please tell me and also include the patch if you have one. If you > cannot download the code, please email me and tell me why, I will try to > be helpful whenever possible, but I might always have the time to be > very responsive. Any feedback about the code is also very much > appreciated. > > I hope you could make good use of this contribution. > Regards, > Thierry > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html -- Sridhar Guriviredddy, Alcatel Newtwok Systems, Richardson, Texas,US-75080 Ph:972.996.2048 From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 10:30:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01952 for ; Wed, 6 Jun 2001 10:30:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27947; Wed, 6 Jun 2001 08:29:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06515; Wed, 6 Jun 2001 07:29:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56ES5g25521 for mobile-ip-dist; Wed, 6 Jun 2001 07:28:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56ES1e25514 for ; Wed, 6 Jun 2001 07:28:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06346 for ; Wed, 6 Jun 2001 07:28:08 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15185 for ; Wed, 6 Jun 2001 07:28:06 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f56EQRg04042 for ; Wed, 6 Jun 2001 16:26:27 +0200 (MEST) Message-ID: <3B1E3DF3.E8CE1CDD@inrialpes.fr> Date: Wed, 06 Jun 2001 16:28:03 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NS-2.1b6 Mobile IPv6 release References: <3B1E2556.DBD29C1B@inrialpes.fr> <3B1E394D.DD409F75@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sridhar Gurivireddy wrote: > > I tried to install Mobile-IPv6 from your website.But, many files in that > package have some peculiar names which ca be viewed with Netscape, but not > on the shell....When the say "ls" at my shell , the shell just hangs...What > should I do with such files... Can you send me an example of what you see on Netscape (????) I don't know what files you are refering to ... I don't have anything strange on my system. What system are you working on ? Thierry From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 10:44:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02337 for ; Wed, 6 Jun 2001 10:44:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28769; Wed, 6 Jun 2001 07:43:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08989; Wed, 6 Jun 2001 07:42:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56EfrO25577 for mobile-ip-dist; Wed, 6 Jun 2001 07:41:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Efne25570 for ; Wed, 6 Jun 2001 07:41:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08802 for ; Wed, 6 Jun 2001 07:41:56 -0700 (PDT) Received: from netdns.netas.com.tr ([195.142.217.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16182 for ; Wed, 6 Jun 2001 08:42:26 -0600 (MDT) Received: from netas.com.tr (47.165.145.36 [47.165.145.36]) by netdns.netas.com.tr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KW3G6MFQ; Wed, 6 Jun 2001 17:40:18 +0300 Message-ID: <3B1E426D.DD94143A@netas.com.tr> Date: Wed, 06 Jun 2001 17:47:09 +0300 From: Oner Tekin X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NS-2.1b6 Mobile IPv6 release References: <3B1E2556.DBD29C1B@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Thierry, Thanks for your work on mobile IPv6 support for ns-2. I think it will be very useful for our studies. Best regards. Oner. Thierry Ernst wrote: > Dear all, > > As many people asked for it, I am glad to announce the release of our > NS-2.1b6 enhancements to simulate Mobile IPv6 in large Wide-Area > networks. This code has been developed by MOTOROLA Labs Paris and INRIA > Rhone-Alpes PLANETE team. > > For information, and to download the code, please check > http://www.inrialpes.fr/planete/mobiwan/ > > Presently, the tar file comprises: > - Mobile IPv6 and simple IPv6 extensions needed by Mobile IPv6 > - A library to create, configure, and manipulate large topologies in a > very easy manner (TOPOMAN) > - A new translator from GT-ITM to NS-2 which output TOPOMAN procedure > calls. > - Embedded extensions to allow the simultaneous use of wireless > features, mobility, and multicast. > > Mobile IPv6 is available, in two modes: > 1. Local mobility (i.e. within an administrative domain, i.e. within a > bounded area) > 2. Global mobility (crossing administrative domains, i.e. moving from > one side of the topology to another). > > Hierarchical Mobile IPv6 will later be included in the distribution and > will be used to demonstrate global mobility. > > This code comes without guaranties and may have bugs. If you find > some, please tell me and also include the patch if you have one. If you > cannot download the code, please email me and tell me why, I will try to > be helpful whenever possible, but I might always have the time to be > very responsive. Any feedback about the code is also very much > appreciated. > > I hope you could make good use of this contribution. > Regards, > Thierry > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 10:47:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02391 for ; Wed, 6 Jun 2001 10:47:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12612; Wed, 6 Jun 2001 08:46:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09980; Wed, 6 Jun 2001 07:45:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56Ej2A25619 for mobile-ip-dist; Wed, 6 Jun 2001 07:45:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Eiwe25611 for ; Wed, 6 Jun 2001 07:44:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09609 for ; Wed, 6 Jun 2001 07:45:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11322 for ; Wed, 6 Jun 2001 08:45:02 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA17757 for ; Wed, 6 Jun 2001 07:44:54 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f56Eir029052 for ; Wed, 6 Jun 2001 07:44:53 -0700 X-mProtect: Wed, 6 Jun 2001 07:44:53 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdWbbMQq; Wed, 06 Jun 2001 07:44:51 PDT Message-ID: <3B1E41E4.6BA2A67E@iprg.nokia.com> Date: Wed, 06 Jun 2001 07:44:52 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] NS-2.1b6 Mobile IPv6 release References: <3B1E2556.DBD29C1B@inrialpes.fr> <3B1E394D.DD409F75@usa.alcatel.com> <3B1E3DF3.E8CE1CDD@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Guys, these are NS issues...could you take them on the NS list? That should help us also track the right mails in the right groups... Thanks Theo UCL/ Mobile Systems Thierry Ernst wrote: > Sridhar Gurivireddy wrote: > > > > I tried to install Mobile-IPv6 from your website.But, many files in that > > package have some peculiar names which ca be viewed with Netscape, but not > > on the shell....When the say "ls" at my shell , the shell just hangs...What > > should I do with such files... > > Can you send me an example of what you see on Netscape (????) I don't > know what files you are refering to ... I don't have anything strange > on my system. > > What system are you working on ? > > Thierry From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 13:04:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05643 for ; Wed, 6 Jun 2001 13:04:07 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16571; Wed, 6 Jun 2001 10:00:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11485; Wed, 6 Jun 2001 09:52:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56GoiL25795 for mobile-ip-dist; Wed, 6 Jun 2001 09:50:44 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Goge25788 for ; Wed, 6 Jun 2001 09:50:42 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02123 for ; Wed, 6 Jun 2001 12:50:48 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA17168 for mobile-ip@sunroof.eng.sun.com; Wed, 6 Jun 2001 12:51:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f567Sqe24932 for ; Wed, 6 Jun 2001 00:28:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23822 for ; Wed, 6 Jun 2001 00:28:59 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19582 for ; Wed, 6 Jun 2001 01:29:32 -0600 (MDT) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f567SoN15525; Wed, 6 Jun 2001 09:28:50 +0200 (MEST) Received: from lt.eth.ericsson.se by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id JAA07527; Wed, 6 Jun 2001 09:28:47 +0200 (MET DST) Message-ID: <3B1DDBAF.228C5303@lt.eth.ericsson.se> Date: Wed, 06 Jun 2001 09:28:47 +0200 From: Andras Valko X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, manet@itd.nrl.navy.mil Subject: [mobile-ip] CFP : RSRCP Journal - Mobility and Internet Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id KAA16571 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05643 [Apologies if you receive multiple copies.] CALL for PAPERS SPECIAL ISSUE MOBILITY AND INTERNET of RSRCP Journal http://www-r2.u-strasbg.fr/rsrcp/mintcfp.html The RSRCP journal, which is now specialized on thematic issues on Network and Distributed System is pleased to announce a special issue on "Mobility and Internet". This special issue is sponsored by IEEE Distributed Systems and the French IEEE Computer Chapter. Wireless mobile access to the Internet will add new dimensions to the way we access information and communicate. Currently, several network protocols are being studied to maintain communication between a mobile host and its correspondents during the mobile host's movements. This special issue is devoted to the presentation of recent research on network protocols and services for mobile hosts and wireless communication on the Internet. We solicit high quality papers reporting original work in theoretical or experimental research. Topics of interest include, but are not limited to the following : - Ad hoc networks - Cellular IP networks - Distributed system aspects of mobile systems - Handoffs in IP networks - Header compression in wireless networks - Hierarchical mobility - IP-based third generation mobile and wireless networks - Micro-mobility architectures and protocols - Multicast communications for mobile hosts - Mobility and IPv6 - Mobile management - Network protocols for mobile nodes - QoS in a wireless/mobile environment - Security and authentication - Service location in wireless environnement - Wireless LAN Important dates: 1. Submission deadline: June 30, 2001; 2. Notifications to the authors: September, 30, 2001; 3. Publication : December 2001; Submissions: Contributions should follow the instructions and the format of the journal edited by Hermes. (see http://www-r2.u-strasbg.fr/rsrcp/authorsguidelines.pdf) Contributions should be original ones and should not be longer than 25 pages. Submissions should be forwarded to the Guest Editors (rsrcp@clarinet.u-strasbg.fr - PS or PDF format, compressed). Guest Editors : Thomas Noel Andras Valko Universite Louis Pasteur - LSIIT Ericsson Research Pole API - Boulevard Sébastien Brant Traffic Laboratory F- 67400 - Illkirch H-1037 Budapest, Laborc u 1. France Hungary Editorial Board : Scott Corson Francis Dupont Flarion Technologies ENST - Bretagne USA France Philip Eardley Thierry Ernst British Telecom INRIA UK France Andras Farago Hong-Yon Lach University of Texas - Dallas Motorola - Paris USA France Phil Neumiller Thomas Noel 3Com LSIIT USA France Hesham Soliman Tapio Suihko Ericsson VTT Technical Research Center Australia Finland C.K. Toh Michel Trehel Georgia Institute of Technology University of Franche-Comté USA France Andras Valko Ericsson Hungary From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 13:22:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06042 for ; Wed, 6 Jun 2001 13:22:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27976; Wed, 6 Jun 2001 10:20:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11937; Wed, 6 Jun 2001 09:54:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56GrHH25821 for mobile-ip-dist; Wed, 6 Jun 2001 09:53:17 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56GrEe25814 for ; Wed, 6 Jun 2001 09:53:14 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02708 for ; Wed, 6 Jun 2001 12:53:21 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id MAA17212 for mobile-ip@sunroof.eng.sun.com; Wed, 6 Jun 2001 12:53:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56ERVe25502 for ; Wed, 6 Jun 2001 07:27:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14318 for ; Wed, 6 Jun 2001 07:27:37 -0700 (PDT) Received: from lrcsun15.epfl.ch (lrcsun15.epfl.ch [128.178.156.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14868 for ; Wed, 6 Jun 2001 07:27:34 -0700 (PDT) Received: from lrc.di.epfl.ch (giordano@lrcsun15.epfl.ch [128.178.156.77]) by lrcsun15.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id QAA15349; Wed, 6 Jun 2001 16:27:24 +0200 (MET DST) Message-Id: <200106061427.QAA15349@lrcsun15.epfl.ch> X-Mailer: exmh version 1.6.9 8/22/96 To: spects02@comp.leeds.ac.uk, news-announce-conferences@uunet.uu.net, end2end-interest@isi.edu, int-serv@isi.edu, cost264@lip6.fr, mobile-ip@sunroof.eng.sun.com, confctrl@isi.edu, aaa-wg@merit.edu Subject: [mobile-ip] Preliminary Announcement and Call for Papers: NETWORKING 2002 X-Face: ")YL-h@"&:Ur_,S{#8mRN-B,tM<4b'^A][=FBR\,RRKX@Jxi;$CLV1t0y=N;iY2rIMLYl5l qnw6)Kg@%$kCs3o7$Ue_(OFu-YO'8Ie~^GIq4'joA&;FeRoNItjTG:e\#2b0'u/S&,#Wf&H_W1hX}O yU,j~1tAM Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ***Accept our sincere apologies if you receive multiple copies*** Please feel free to distribute a copy of this call to those who might be interested. Preliminary Announcement and Call for Papers NETWORKING 2002 The Second IFIP-TC6 Networking Conference http://www.cnuce.pi.cnr.it/Networking2002 May 19-24 2002, Pisa - Italy Networking is the biennial Conference on Networking of the IFIP Technical Committee on Communication Systems (TC6). Networking 2002 is the second conference of this series --the first event was held in Paris, May 2000-- and is sponsored by the IFIP working groups on Network and Internetwork Architectures (WG 6.2), Performance of Communication Systems (WG 6.3), and Wireless Communications (WG 6.8). Networking 2002 is organized into three tracks: i) Networking Technologies, Services and Protocols; ii) Performance of Computer and Communication Networks; iii) Mobile and Wireless Communications Systems. The Networking 2002 technical program committee is soliciting papers describing original, previously unpublished, completed research, not currently under review by another conference or journal, addressing state-of-the-art research and development in all areas of computer networking and data communications. Special sessions will be dedicated to hot topics such as: Mobile Internet, QoS in Internet, wireless local and personal area networks, 3G wireless systems, mobile ad-hoc networks. A detailed list of topics of interest can be found at: http://www.cnuce.pi.cnr.it/Networking2002/CFP.htm PAPER SUBMISSION AND PUBLICATION ================================= Papers must be submitted electronically according to the instructions described in http://www.cnuce.pi.cnr.it/Networking2002 . All papers will be reviewed by the program committee. Accepted papers will appear in the conference proceedings published by Springer-Verlag in the LNCS series. Authors of selected papers will be invited to submit extended version of their papers for possible publication in special issues of ACM/Kluwer Wireless Networks (WINET) and Performance Evaluation journals. IMPORTANT DATES =============== Full papers due: October 15, 2001 Notification: January 30, 2002 Camera Ready due: March 15, 2002 EXECUTIVE COMMITTEE =================== GENERAL CHAIR: Enrico Gregori, National Research Council, Italy GENERAL VICE-CHAIR: Ioannis Stavrakakis, University of Athens, Greece TECHNICAL PROGRAM CHAIR: Marco Conti, National Research Council, Italy SPECIAL TRACK CHAIR for Networking Technologies, Services and Protocols: Andrew T. Campbell, Columbia University, USA SPECIAL TRACK CHAIR for Performance of Computer and Communication Networks: Moshe Zukerman, University of Melbourne, Australia SPECIAL TRACK CHAIR for Mobile and Wireless Communications Systems: Guy Omidyar, National University of Singapore TUTORIAL PROGRAM CHAIRS: Giuseppe Anastasi, University of Pisa, Italy Stefano Basagni, University of Texas at Dallas, USA ORGANIZATION CHAIR: Stefano Giordano, University of Pisa, Italy PUBLICITY CHAIRS: Silvia Giordano Ecole Politecnicque Losanna, Switzerland Laura Feeney, SICS, Sweden STEERING COMMITTEE CHAIR: Harry Perros, North Carolina State University, USA STEERING COMMITTEE MEMBERS: Augusto Casaca, IST/INESC, Portugal S. K. Das, The University of Texas at Arlington, USA Erol Gelenbe, University of Central Florida, USA Harry Perros, NCSU, USA (Chair) Guy Pujolle, University of Paris 6, France Harry Rudin, Switzerland Jan Slavik, TESTCOM, Czech Republic Hideaki Takagi, University of Tsukuba, Japan Samir Thome, ENST, France Adam Wolisz, TU-Berlin, Germany From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 13:25:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06139 for ; Wed, 6 Jun 2001 13:25:57 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09034; Wed, 6 Jun 2001 11:24:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20629; Wed, 6 Jun 2001 10:24:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56HN0j25968 for mobile-ip-dist; Wed, 6 Jun 2001 10:23:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56HMue25961 for ; Wed, 6 Jun 2001 10:22:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18516 for ; Wed, 6 Jun 2001 10:23:04 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10903 for ; Wed, 6 Jun 2001 10:23:03 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA27510 for ; Wed, 6 Jun 2001 10:16:32 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA13477 for ; Wed, 6 Jun 2001 10:23:01 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 12:23:00 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C74@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Wed, 6 Jun 2001 12:23:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Yes, I was off by 1^3. BAD mistake for an ex physical layer guy :) Madjid -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, June 05, 2001 5:14 PM To: mobile-ip@sunroof.eng.sun.com Cc: 'James.Kempf@Sun.COM' Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Er Madjid, my physics book sez that c ~= 3x10^8 m/s. that makes a km about 1/3x10^5 (in vacuum) so even allowing for wire/fiber, you seem to be off by a couple of orders of magnitude. Mike Nakhjiri Madjid-MNAKHJI1 writes: > James, > > Thanks for sending the analysis and sorry for my late response, > I am still catching up with the list. The analysis made me > go and read the new version of the draft! So now I am even more > behind on the list, sorry if there has been more exchange on this. > > I have one question and a few comments. > > First, shouldn't you include the propagation delay from the oldAR to > the MN and back into the calculation? > Speed of light is 1 ns/foot=3ns/meter=3ms/km, so > in a CDMA cell of about 3Km in radius, you have 10 ms > propagation delay in each direction, which mean 20 ms total. > > Also, I don't know what WCDMA does these days, but don't they add > some padding to the layer 3 signal (maybe that is not too big :) ) > > Now, my question isn't HI/HACK between oldAR/ newAR included in stateful > case, aren't > those messages in critical path? I saw your comment about Mobile > determined case (that HI/HACK should be included). Doesn't the same > apply to Network determined stateful? > > Again the HI/HACK has both transmission delay and propagation delay. > > Thanks, > Madjid Nakhjiri > > -----Original Message----- > From: James Kempf [mailto:James.Kempf@Sun.COM] > Sent: Monday, May 14, 2001 4:40 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Times for Low-Latency IPv6 Handoff > > > As an interesting exercise, I went through some calculations about how > long an IPv6 low latency handoff would take in some of the scenerios > described in draft-ietf-mobileip-fast-mipv6-01.txt. I looked at the > following cases: > > - Network determined, stateless with the following two subcases: > - F-BU/F-BACK received before handoff > - F-BU/F-BACK received after handoff > > - Network deterimed, stateful > > - Mobile determined, with the following two subcases: > - F-BU/F-BACK received before handoff > - F-BU/F-BACK received after handoff > > I also made the following assumptions: > > - Prior to handoff, the header compressor on the old AR is > "hot" enough to compress the basic 40 byte IPv6 header down > to 1 byte, but after handoff, the header compressor is "cold" > and so the full IPv6 header needs to be sent. Currently, there > is some debate about whether the compressor could be partially > restarted on the new AR using context transfer, so this could > introduce an additional optimization and also a potential > area of timing uncertainty involving the context transfer > time itself. > > - The BU/BACK pair completes on either side of the handoff. > In actuality, it may span the handoff and Section 3.3 may > come into play if the MN doesn't get a BACK back (so to > speak) fast enough. Or, an additional BU may need to be sent. > I view the assumptions made here as being fairly optimistic, > since over the air signalling after L2 has indicated that > handover is pending is likely to be subject to a considerably > higher error rate due to deteriorating radio conditions in > the old cell and not-yet improved radio conditions in the new. > > - The radio link layer is using its lowest bit rate for signalling. > This assumption is based on either using a multiplexed common > channel for signalling, in which case the MN would have to share > the channel with other MNs in the cell, or using a dedicated > channel but not wanting to charge the user much or nothing at > all, and therefore not wanting to use a higher bandwidth. Of > course, this will be radio-specific, but it seems like a good > assumption for cellular systems. The value I used was 7.5 kbps > (940 bytes/sec), which is the minimum for a wCDMA dedicated channel > from Holma and Toskala, "WCDMA for UMTS", Wiley, 2000. > > - The wired link ARs use Ethernet (48 bit MAC address link > layer) and the wireless link is using 15 byte IMSIs (International > Mobile Station Identifiers) sent as ASCII digits. > > - The MN can neither send or receive traffic on the new AR until > the old AR has confirmed the new CoA via a F-BACK. > > Here's the results. > > Network Determined, Stateless > ----------------------------- > > As near as I can tell, the following messages get exchanged over the > air: PrRtAdv, F-BU, F-BACK. > > Sizes of these are: > > hdr msg lnkAddrOpt prxLnkAddrOpt newCoA Total > > PrRtAdv 1 8 9 9 24 51 > > F-BU > before 1 10 11 > > F-BU > after 40 10 50 > > F-BACK > before 1 9 10 > > F-BACK > after 40 9 49 > > Total over the air sizes: > > F-BU/F-BACK before: 51 + 11 + 10 = 72 bytes > F-BU/F-BACK after: 51 + 50 + 49 = 150 bytes > > Times: > > F-BU/F-BACK before: 72 bytes / 940 bytes/sec = 0.077 sec = 77 msec. > F-BU/F-BACK after: 150 bytes/ 940 bytes/sec = 0.160 sec = 160 msec. > > However, total handoff time will consist of the above plus a > nondeterministic amount of time involved in L2 handoff and the > amount of processing time required on new AR to perform DAD and > process the HI/HACK pair. Perhaps one could use the maximum > of L2 handover time and HI/HACK processing time as an estimate > to add to the above. > > Network Determined, Stateful > ---------------------------- > > Messages exchanged over the air- PrRtAdv prior to handoff. > > Byte counts the same as the above. No F-BU/F-BACK needed, so the > only over the air message required is the PrRtAdv. > > Total over the air size: > > PrRtAdv size: 51 bytes > > Time: > > 51 bytes/ 940 bytes/sec = 0.054 sec = 54 msec. > > L2 handover time needs to be added. > > Mobile Determined > ----------------- > > Messages exchanged over the air: RtSolPr, PrRtAdv, F-BU, F-BACK. > > Byte counts for PrRtAdv and F-BU/F-BACK the same as above. RtSolPr > sent by MN is done prior to L2 handoff. > > hdr RtSolPr MNlnkAddrOpt newAttPtLnkOpt Total > > RtSolPr 1 8 18 9 36 > > Total over the air sizes: > > F-BU/F-BACK before: 36 + 51 + 18 + 10 = 115 bytes > F-BU/F-BACK after: 36 + 51 + 50 + 49 = 186 bytes > > Times: > > F-BU/F-BACK before: 115 bytes/ 940 bytes/sec. = 0.122 sec = 122 ms > F-BU/F-BACK after: 198 bytes/ 940 bytes/sec. = 0.198 sec = 198 ms > > Again, the maximum of L2 handoff time and HI/HACK processing time > would need to be included. > > Conclusions > ----------- > > What conclusions to draw? These time range from respectible (55 ms > for network determined, stateful) to the clearly questionable (198 ms for > mobile determined, F-BU/F-BACK sent after). The ITU recommends 300 ms > maximum for delay before the user notices with real time voice traffic. > Depending on the amount of time required for the L2 handover, the HI/HACK > processing time, and any time required to send buffered traffic to > the MN if buffering is used on the old AR, the mobile determined, > F-BU/F-BACK > sent after case could easily exceed the ITU guideline, as almost 2/3 > of the noticable delay time is taken up by the L3 handoff. The others > require less L3 handoff time, but only the network determined, stateless, > F-BU/F-BACK before and the network determined, stateful are less than > or equal to about 1/4 of the ITU guideline. > > Clearly, header compression on the new AR could help a lot. IPv6 headers > are big, and if there were some way the header compressors on MN and new AR > could be jump started prior to handoff, the 40 byte header overhead could be > eliminated. Alternatively, if the link layer can guarantee that > the F-BU/F-BACK occurs before the L2 handoff, the header overhead won't > occur. Using a higher bandwidth channel could help also. > > Please send any comments or corrections (in case my math is wrong). > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 13:33:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06339 for ; Wed, 6 Jun 2001 13:33:55 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05158; Wed, 6 Jun 2001 10:32:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20320; Wed, 6 Jun 2001 10:23:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56HLeP25950 for mobile-ip-dist; Wed, 6 Jun 2001 10:21:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56HLae25943 for ; Wed, 6 Jun 2001 10:21:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24757 for ; Wed, 6 Jun 2001 10:21:44 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21456 for ; Wed, 6 Jun 2001 11:22:15 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA28027 for ; Wed, 6 Jun 2001 10:21:42 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA01722 for ; Wed, 6 Jun 2001 10:21:42 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 12:21:41 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C73@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'James Kempf'" , mobile-ip@sunroof.eng.sun.com, Nakhjiri Madjid-MNAKHJI1 Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff Date: Wed, 6 Jun 2001 12:21:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Tuesday, June 05, 2001 4:51 PM To: mobile-ip@sunroof.eng.sun.com; James.Kempf@Sun.COM; Madjid.Nakhjiri Subject: RE: [mobile-ip] Times for Low-Latency IPv6 Handoff > >First, shouldn't you include the propagation delay from the oldAR to >the MN and back into the calculation? >Speed of light is 1 ns/foot=3ns/meter=3ms/km, so >in a CDMA cell of about 3Km in radius, you have 10 ms >propagation delay in each direction, which mean 20 ms total. > I assume that is built into the user level bit rate figures Holma and Toskala give for WCDMA. MN>> ops, I saw the mistake (I guess I have been reading too many drafts for too long :) ) thanks Art for the slap, and Mike it should read Speed of light is 1 ns/foot=3ns/meter=3us/km, so it comes down to 20 micro sec, which is negligible. However, not knowing the channeling of WCDMA, it is still kind of odd that 7.5 kbps comes down to only 940 bytes/ sec. >Also, I don't know what WCDMA does these days, but don't they add >some padding to the layer 3 signal (maybe that is not too big :) ) > Typically, radio frames are much smaller than IP packets (on the order of 40 bytes). It is possible that there may be padding if a packet won't fit into an even number of frames, but, again, I was using the user level throughput figures. MN>>Well, yes you do need to do L2 segmentation to fit the size of L2 frames, but what I meant was the L2 headers that will be added to each frames and the channel coding that L2 does, and those add up the bytes that you calculated, but as you said maybe these are all baked into the 7.5 kbps to 940 bytes/sec conversion! >Now, my question isn't HI/HACK between oldAR/ newAR included in stateful >case, aren't >those messages in critical path? I saw your comment about Mobile >determined case (that HI/HACK should be included). Doesn't the same >apply to Network determined stateful? > >Again the HI/HACK has both transmission delay and propagation delay. > Signalling across the wired backbone is typically less than 10 ms. I believe I calculated something in the submillisecond range for T1 on the HI/HACK. So it's basically in the noise, as far as the radio link is concerned. MN>> thanks, it makes sense. Madjid From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 14:02:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07103 for ; Wed, 6 Jun 2001 14:02:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11529; Wed, 6 Jun 2001 12:00:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29789; Wed, 6 Jun 2001 10:59:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56Hw3x26171 for mobile-ip-dist; Wed, 6 Jun 2001 10:58:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Hvwe26164 for ; Wed, 6 Jun 2001 10:57:58 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00590 for ; Wed, 6 Jun 2001 10:58:05 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20851 for ; Wed, 6 Jun 2001 10:58:04 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA01407 for ; Wed, 6 Jun 2001 10:58:04 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA28189 for ; Wed, 6 Jun 2001 10:58:04 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Jun 2001 12:58:03 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C76@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] questions on fast handoffs for MIPv6 Date: Wed, 6 Jun 2001 12:58:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, I guess I continue my trend of asking silly question :) I have the following questions on the MIPv6 fast handover draft. I appreciate if I could get answers on the following questions. Regards, Madjid Q1-Neighbor advertisement and L2 connectivity It says in the draft (page 5) that the newAR will deliver packets to the mobile when it receive indication from access network or NA from Mobile. In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 connectivity trigger. Could there be a race condition where newAR can start delivering packets (based on L2 indication) before receiving an NA from MN? if not why is the text written that way? Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR receives a BU from MN or an F-BU + HACk. The newAR delivers the packets to the MN as soon as it receives an NA or F-NA from the MN (apart from Q1 above). This means that during this time the MN's packets must be buffered at newAR (whether it helps real time traffic or not, is another issue). There was also a discussion about buffering at oldAR or at newAR, but I think what I missed on the discussion was that " is buffering at newAR supported or is it left to implementers, (Should/ MUST/ May question?)" 3- This question was asked on the list, I am not sure if I saw a convincing answer other than comparing F-BU with BU. The MN cannot use its newCoA as source address until it has received F-Back from oldAR. Then how does it use newCoA as source address in F-BU? Isn't this a chicken and egg problem? What am I missing? Also what about ingress filtering issue at oldAR? From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 15:13:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08043 for ; Wed, 6 Jun 2001 15:13:23 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13665; Wed, 6 Jun 2001 13:11:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18436; Wed, 6 Jun 2001 12:11:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56JA4T26416 for mobile-ip-dist; Wed, 6 Jun 2001 12:10:04 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56JA1e26409 for ; Wed, 6 Jun 2001 12:10:01 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f56JA6Q249873 for ; Wed, 6 Jun 2001 12:10:06 -0700 (PDT) Message-Id: <200106061910.f56JA6Q249873@jurassic.eng.sun.com> Date: Wed, 6 Jun 2001 12:10:08 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4EyABOHZ+YMBOW+5ase2tg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Madjid, > Q1-Neighbor advertisement and L2 connectivity > It says in the draft (page 5) that the newAR will deliver packets to the mobile > when it receive indication from access network or NA from Mobile. > In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 connectivity > trigger. Could there be a race condition where newAR can start delivering packets > (based on L2 indication) before receiving an NA from MN? if not why is the text > written that way? I don't see a problem even when newAR detects arrival of MN, and at the same time MN sends a F-NA to newAR. Do you see a problem? > > Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR > receives a BU from MN or an F-BU + HACk. > The newAR delivers the packets to the MN as soon as it receives an NA or > F-NA from the MN (apart from Q1 above). > This means that during this time the MN's packets must be buffered at > newAR (whether it helps real time traffic or not, is another issue). > There was also a discussion about buffering at oldAR or at newAR, but > I think what I missed on the discussion was that > " is buffering at newAR supported or is it left to implementers, > (Should/ MUST/ May question?)" We have a 'U' Buffer Flag in HA message. And I think this makes it an optional feature. oldAR MAY turn this flag on. Do you think we should spell this out in the draft? > > > 3- This question was asked on the list, I am not sure if I saw a convincing > answer other than comparing F-BU with BU. > The MN cannot use its newCoA as source address until it has received > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > Isn't this a chicken and egg problem? What am I missing? > Also what about ingress filtering issue at oldAR? > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA as the source address, and include a alternate CoA suboption. (I'm not sure if this is already stated in the draft. If not, we should add this.) alper From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 16:02:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08530 for ; Wed, 6 Jun 2001 16:02:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18386; Wed, 6 Jun 2001 13:01:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01604; Wed, 6 Jun 2001 13:00:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56JuR226504 for mobile-ip-dist; Wed, 6 Jun 2001 12:56:27 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56JuOe26497 for ; Wed, 6 Jun 2001 12:56:25 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11321 for ; Wed, 6 Jun 2001 15:56:31 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id PAA20247 for mobile-ip@sunroof.eng.sun.com; Wed, 6 Jun 2001 15:56:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56JDAe26443 for ; Wed, 6 Jun 2001 12:13:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24858 for ; Wed, 6 Jun 2001 12:13:17 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26202 for ; Wed, 6 Jun 2001 13:13:50 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA07864 for ; Wed, 6 Jun 2001 12:13:15 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f56JDE117200 for ; Wed, 6 Jun 2001 12:13:14 -0700 X-mProtect: Wed, 6 Jun 2001 12:13:14 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdvaS3B6; Wed, 06 Jun 2001 12:13:12 PDT Message-ID: <3B1E80C9.DAB8A52F@iprg.nokia.com> Date: Wed, 06 Jun 2001 12:13:13 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <35DBB8B7AC89D4118E98009027B1009B1B7C76@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit answer for question 3. it will work if the following happens. when the MN sends a F-BU when at the oldAR, the source address of the packet is oldCoA. the newCoA is included in the alt-CoA sub-option. answer for question 2. Yes, buffering should be supported at the newAR. otherwise you would be dropping packets. vijay Nakhjiri Madjid-MNAKHJI1 wrote: > > Hi all, > > I guess I continue my trend of asking silly question :) > I have the following questions on the MIPv6 fast handover draft. > I appreciate if I could get answers on the following questions. > > Regards, > Madjid > > Q1-Neighbor advertisement and L2 connectivity > It says in the draft (page 5) that the newAR will deliver packets to the mobile > when it receive indication from access network or NA from Mobile. > In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 connectivity > trigger. Could there be a race condition where newAR can start delivering packets > (based on L2 indication) before receiving an NA from MN? if not why is the text > written that way? > > Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR > receives a BU from MN or an F-BU + HACk. > The newAR delivers the packets to the MN as soon as it receives an NA or > F-NA from the MN (apart from Q1 above). > This means that during this time the MN's packets must be buffered at > newAR (whether it helps real time traffic or not, is another issue). > There was also a discussion about buffering at oldAR or at newAR, but > I think what I missed on the discussion was that > " is buffering at newAR supported or is it left to implementers, > (Should/ MUST/ May question?)" > > 3- This question was asked on the list, I am not sure if I saw a convincing > answer other than comparing F-BU with BU. > The MN cannot use its newCoA as source address until it has received > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > Isn't this a chicken and egg problem? What am I missing? > Also what about ingress filtering issue at oldAR? From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 16:14:58 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08705 for ; Wed, 6 Jun 2001 16:14:58 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23571; Wed, 6 Jun 2001 13:12:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03109; Wed, 6 Jun 2001 13:07:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56K6Ma26576 for mobile-ip-dist; Wed, 6 Jun 2001 13:06:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56K6He26569 for ; Wed, 6 Jun 2001 13:06:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07271 for ; Wed, 6 Jun 2001 13:06:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03672 for ; Wed, 6 Jun 2001 13:06:15 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA11002 for ; Wed, 6 Jun 2001 13:06:15 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f56K6Em24912 for ; Wed, 6 Jun 2001 13:06:14 -0700 X-mProtect: Wed, 6 Jun 2001 13:06:14 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdCAaP0S; Wed, 06 Jun 2001 13:06:12 PDT Message-ID: <3B1E8D34.EF77C3E6@iprg.nokia.com> Date: Wed, 06 Jun 2001 13:06:12 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106061910.f56JA6Q249873@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Alper, > We have a 'U' Buffer Flag in HA message. And I think this makes it an optional > feature. oldAR MAY turn this flag on. Do you think we should spell this out in > the draft? it is slightly different. by setting the 'U' flag, the oldAR basically tells the newAR, that i have been buffering packets for this particular MN. you should also do it. and in the scenario, Madjid was talking about, the newAR is receiving packets forwarded by the oldAR to the MN. but the MN hasnt shown up yet. here it MUST buffer packets, whether the 'U' flag in the HI was set or not. if it doesnt buffer, it has to drop the packets till the MN shows up. vijay > > > > > > > 3- This question was asked on the list, I am not sure if I saw a convincing > > answer other than comparing F-BU with BU. > > The MN cannot use its newCoA as source address until it has received > > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > > Isn't this a chicken and egg problem? What am I missing? > > Also what about ingress filtering issue at oldAR? > > > > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA > as the source address, and include a alternate CoA suboption. (I'm not sure if > this is already stated in the draft. If not, we should add this.) > > alper From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 22:22:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA12938 for ; Wed, 6 Jun 2001 22:22:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA16799; Wed, 6 Jun 2001 20:20:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16637; Wed, 6 Jun 2001 19:20:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f572JGv27168 for mobile-ip-dist; Wed, 6 Jun 2001 19:19:16 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f572JCe27161 for ; Wed, 6 Jun 2001 19:19:13 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f572JHQ337810 for ; Wed, 6 Jun 2001 19:19:17 -0700 (PDT) Message-Id: <200106070219.f572JHQ337810@jurassic.eng.sun.com> Date: Wed, 6 Jun 2001 19:19:19 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CGu2bKPtALCeuS5dpmyfng== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Vijay, > hi Alper, > > > We have a 'U' Buffer Flag in HA message. And I think this makes it an optional > > feature. oldAR MAY turn this flag on. Do you think we should spell this out in > > the draft? > > it is slightly different. by setting the 'U' flag, the oldAR basically > tells the newAR, that i have been buffering packets for this particular > MN. you should also do it. Do you mean when U flag is turned on, that means both oldAR and newAR would be buffering? I'm not aware of that. I'm not aware of buffering at oldAR. If this is in the draft, I must be missing it. Can you point me where is this in the draft? > and in the scenario, Madjid was talking about, the newAR is receiving > packets forwarded by the oldAR to the MN. but the MN hasnt shown up > yet. here it MUST buffer packets, whether the 'U' flag in the HI was > set or not. if it doesnt buffer, it has to drop the packets till the > MN shows up. So, here you are saying newAR MUST buffer independent of U flag. I don't think we said that in the draft. Can I get a pointer for this one as well? Yes, if newAR doesn't buffer, it must drop the packets. That's why we have U flag. alper > > vijay > > > > > > > > > > > > 3- This question was asked on the list, I am not sure if I saw a convincing > > > answer other than comparing F-BU with BU. > > > The MN cannot use its newCoA as source address until it has received > > > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > > > Isn't this a chicken and egg problem? What am I missing? > > > Also what about ingress filtering issue at oldAR? > > > > > > > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA > > as the source address, and include a alternate CoA suboption. (I'm not sure if > > this is already stated in the draft. If not, we should add this.) > > > > alper alper From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 6 22:55:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14254 for ; Wed, 6 Jun 2001 22:55:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01166; Wed, 6 Jun 2001 20:51:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA19469; Wed, 6 Jun 2001 19:51:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f572oKQ27238 for mobile-ip-dist; Wed, 6 Jun 2001 19:50:20 -0700 (PDT) Date: Wed, 6 Jun 2001 19:50:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f572oGe27231 for ; Wed, 6 Jun 2001 19:50:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15250 for ; Wed, 6 Jun 2001 19:50:23 -0700 (PDT) Received: from mail.ict.ac.cn ([159.226.39.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA00397 for ; Wed, 6 Jun 2001 20:50:22 -0600 (MDT) Received: (qmail 31626 invoked from network); 7 Jun 2001 02:44:56 -0000 Received: from unknown (HELO ken) (159.226.39.72) by 159.226.39.4 with SMTP; 7 Jun 2001 02:44:56 -0000 Message-ID: <008501c0eefd$11361ef0$4827e29f@ken> From: "ken" To: Subject: [mobile-ip] Date: Thu, 7 Jun 2001 10:53:41 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01C0EF40.1D920C70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0082_01C0EF40.1D920C70 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUNCg== ------=_NextPart_000_0082_01C0EF40.1D920C70 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w MC4yOTIwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj51bnN1YnNjcmliZTwvRk9OVD48 L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0082_01C0EF40.1D920C70-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 06:11:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02913 for ; Thu, 7 Jun 2001 06:11:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13845; Thu, 7 Jun 2001 03:11:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08768; Thu, 7 Jun 2001 03:11:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57AAAM28186 for mobile-ip-dist; Thu, 7 Jun 2001 03:10:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57AA7e28179 for ; Thu, 7 Jun 2001 03:10:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08697 for ; Thu, 7 Jun 2001 03:10:13 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19018 for ; Thu, 7 Jun 2001 03:10:12 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Jun 2001 06:10:10 -0400 Message-ID: From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Thu, 7 Jun 2001 06:10:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Thursday, June 07, 2001 3:19 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Hi Vijay, > hi Alper, > > > We have a 'U' Buffer Flag in HA message. And I think this makes it an optional > > feature. oldAR MAY turn this flag on. Do you think we should spell this out in > > the draft? > > it is slightly different. by setting the 'U' flag, the oldAR basically > tells the newAR, that i have been buffering packets for this particular > MN. you should also do it. Do you mean when U flag is turned on, that means both oldAR and newAR would be buffering? I'm not aware of that. I'm not aware of buffering at oldAR. If this is in the draft, I must be missing it. Can you point me where is this in the draft? > and in the scenario, Madjid was talking about, the newAR is receiving > packets forwarded by the oldAR to the MN. but the MN hasnt shown up > yet. here it MUST buffer packets, whether the 'U' flag in the HI was > set or not. if it doesnt buffer, it has to drop the packets till the > MN shows up. So, here you are saying newAR MUST buffer independent of U flag. I don't think we said that in the draft. Can I get a pointer for this one as well? Yes, if newAR doesn't buffer, it must drop the packets. That's why we have U flag. GT> I think that it is up to the operator to buffer or not whenever he wants! The U flag just states a preference/request which can always be overwritten by an operator due to local capacity issues or whatever....The point is that lack of U flag does not mean that the newAR MUST drop packets it just suggests that it MAY...On the other hand the presence of the U flag does not mean the newAR MUST buffer packets it just suggest that it SHOULD. George From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 07:11:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03555 for ; Thu, 7 Jun 2001 07:11:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13628; Thu, 7 Jun 2001 05:10:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13228; Thu, 7 Jun 2001 04:09:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57B8Wx28292 for mobile-ip-dist; Thu, 7 Jun 2001 04:08:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57B8Se28285 for ; Thu, 7 Jun 2001 04:08:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07168 for ; Thu, 7 Jun 2001 04:08:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22340 for ; Thu, 7 Jun 2001 04:08:33 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03456; Thu, 7 Jun 2001 07:08:05 -0400 (EDT) Message-Id: <200106071108.HAA03456@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-06.txt Date: Thu, 07 Jun 2001 07:08:04 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : AAA Registration Keys for Mobile IP Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-aaa-key-06.txt Pages : 14 Date : 06-Jun-01 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to create such security information at the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-aaa-key-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-aaa-key-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010606123035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-key-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-key-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010606123035.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 10:10:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07736 for ; Thu, 7 Jun 2001 10:10:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07147; Thu, 7 Jun 2001 07:07:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22862; Thu, 7 Jun 2001 07:06:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57E58l28645 for mobile-ip-dist; Thu, 7 Jun 2001 07:05:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57E54e28638 for ; Thu, 7 Jun 2001 07:05:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25757 for ; Thu, 7 Jun 2001 07:05:10 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from del2.vsnl.net.in (del2.vsnl.net.in [202.54.15.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28727 for ; Thu, 7 Jun 2001 07:05:08 -0700 (PDT) Received: from vishnu.vishnu (unknown [203.197.193.57]) by del2.vsnl.net.in (Postfix) with ESMTP id 396E53F304 for ; Thu, 7 Jun 2001 19:35:54 +0530 (IST) Received: from vishnu.vishnu (VISHNU [192.168.1.15]) by vishnu.vishnu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id MLZP8K2G; Thu, 7 Jun 2001 19:34:23 +0530 Received: by vishnu.vishnu (Microsoft Exchange Connector for POP3 Mailboxes 4.50.2113) with SMTP (Global POP3 Download) id MSG06072001-193141-246.MMD@vishnu; Thu, 7 Jun 2001 19:31:41 +0530 Delivered-To: sandy@amdale.com Received: (qmail 17285 invoked by uid 104); 7 Jun 2001 13:22:10 -0000 Delivered-To: amdale.com-sandeepj@AMDALE.COM Received: (qmail 17252 invoked by alias); 7 Jun 2001 13:22:09 -0000 Received: from unknown (HELO loki.ietf.org) (132.151.1.177) by 0 with SMTP; 7 Jun 2001 13:22:09 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA29201 for ietf-123-outbound.01@ietf.org; Thu, 7 Jun 2001 08:25:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA28780 for ; Thu, 7 Jun 2001 07:08:09 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03456; Thu, 7 Jun 2001 07:08:05 -0400 (EDT) Message-Id: <200106071108.HAA03456@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-key-06.txt Date: Thu, 07 Jun 2001 07:08:04 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : AAA Registration Keys for Mobile IP Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-aaa-key-06.txt Pages : 14 Date : 06-Jun-01 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to create such security information at the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-aaa-key-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-aaa-key-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010606123035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-key-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-key-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010606123035.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 12:41:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10106 for ; Thu, 7 Jun 2001 12:41:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05744; Thu, 7 Jun 2001 10:34:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27049; Thu, 7 Jun 2001 09:34:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57GWxq29075 for mobile-ip-dist; Thu, 7 Jun 2001 09:32:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57GWte29068 for ; Thu, 7 Jun 2001 09:32:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03860 for ; Thu, 7 Jun 2001 09:33:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06991 for ; Thu, 7 Jun 2001 10:33:35 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA09843 for ; Thu, 7 Jun 2001 09:32:59 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57GWw713366 for ; Thu, 7 Jun 2001 09:32:58 -0700 X-mProtect: Thu, 7 Jun 2001 09:32:58 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdPlKqYy; Thu, 07 Jun 2001 09:32:56 PDT Message-ID: <3B1FACB8.52C47981@iprg.nokia.com> Date: Thu, 07 Jun 2001 09:32:56 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > GT> I think that it is up to the operator to buffer or not whenever he > wants! The U flag just states a preference/request which can always be > overwritten by an operator due to local capacity issues or whatever....The > point is that lack of U flag does not mean that the newAR MUST drop packets > it just suggests that it MAY...On the other hand the presence of the U flag > does not mean the newAR MUST buffer packets it just suggest that it SHOULD. Can you add the following text to the draft then? When the newAR is receiving packets forwarded by the oldAR for the MN, and the MN hasnt shown up yet, the newAR SHOULD buffer packets. If the newAR does not buffer packets, it would the packets meant for the MN. 'shown up yet' can be expanded to 'the newAR has received neither a NA nor a F-NA from the MN (nor a link level trigger)'. vijay > > George From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 12:44:40 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10199 for ; Thu, 7 Jun 2001 12:44:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23223; Thu, 7 Jun 2001 09:42:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29271; Thu, 7 Jun 2001 09:42:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57GfIv29136 for mobile-ip-dist; Thu, 7 Jun 2001 09:41:18 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57GfFe29129 for ; Thu, 7 Jun 2001 09:41:15 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA23386 for ; Thu, 7 Jun 2001 09:41:22 -0700 (PDT) Message-Id: <200106071641.JAA23386@heliopolis.eng.sun.com> Date: Thu, 7 Jun 2001 09:41:22 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7mDZk1NOoNp3hrpKnNcvMQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >Can you add the following text to the draft then? > > When the newAR is receiving packets forwarded by the > oldAR for the MN, and the MN hasnt shown up yet, the > newAR SHOULD buffer packets. If the newAR does not > buffer packets, it would the packets meant for the MN. > I don't think this text should be added. It is entirely unclear at this point whether buffering will work without causing user-perceivable artifacts in real time streams. In fact, I know of at least one experiment with buffering (in IPv4) that showed it cannot be done. This experiment was not definitive, of course, but I think it is not wise to write buffering into the standard until more is known about whether it will work or not. There are other alternatives to handoff smoothing, for example bicasting, that could handle some portion of the handoff smoothing task without introducing artifacts. We need to leave the standard open on this until there is more evidence. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:03:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10618 for ; Thu, 7 Jun 2001 13:03:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03408; Thu, 7 Jun 2001 09:59:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28438; Thu, 7 Jun 2001 09:57:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57GuVR29201 for mobile-ip-dist; Thu, 7 Jun 2001 09:56:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57GuRe29194 for ; Thu, 7 Jun 2001 09:56:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03199 for ; Thu, 7 Jun 2001 09:56:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19878 for ; Thu, 7 Jun 2001 09:56:33 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA11422 for ; Thu, 7 Jun 2001 09:55:52 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57Gtp118804 for ; Thu, 7 Jun 2001 09:55:51 -0700 X-mProtect: Thu, 7 Jun 2001 09:55:51 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdYBcExm; Thu, 07 Jun 2001 09:55:46 PDT Message-ID: <3B1FB213.1ED2FD48@iprg.nokia.com> Date: Thu, 07 Jun 2001 09:55:47 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106071641.JAA23386@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, James Kempf wrote: > > >Can you add the following text to the draft then? > > > > When the newAR is receiving packets forwarded by the > > oldAR for the MN, and the MN hasnt shown up yet, the > > newAR SHOULD buffer packets. If the newAR does not > > buffer packets, it would the packets meant for the MN. > > > > I don't think this text should be added. > > It is entirely unclear at this point whether buffering will work without causing > user-perceivable artifacts in real time streams. In fact, I know of > at least one experiment with buffering (in IPv4) that showed it cannot be done. > This experiment was not definitive, of course, but I think it is > not wise to write buffering into the standard until more is known > about whether it will work or not. > > There are other alternatives to handoff smoothing, for example bicasting, > that could handle some portion of the handoff smoothing task without > introducing artifacts. We need to leave the standard open on this > until there is more evidence. you didnt get it. consider this scenario. the MN has sent a F-BU to the oldAR. lost the link connection. the oldAR starts forwarding packets to the newAR. MN hasnt shown up yet at the newAR. it hasnt sent a F-NA or a NA to the newAR yet. (there is some delay in the MN moving and establishing a link layer connection). if the newAR does not buffer these packets it would have to drop it. bicasting does not help here. vijay > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:07:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10740 for ; Thu, 7 Jun 2001 13:07:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05045; Thu, 7 Jun 2001 11:04:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00659; Thu, 7 Jun 2001 10:03:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57H2v129271 for mobile-ip-dist; Thu, 7 Jun 2001 10:02:57 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57H2qe29255 for ; Thu, 7 Jun 2001 10:02:52 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA24493 for ; Thu, 7 Jun 2001 10:03:00 -0700 (PDT) Message-Id: <200106071703.KAA24493@heliopolis.eng.sun.com> Date: Thu, 7 Jun 2001 10:03:00 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NY2lZtPPVMSlwpcu18NZjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> I don't think this text should be added. >> >> It is entirely unclear at this point whether buffering will work without causing >> user-perceivable artifacts in real time streams. In fact, I know of >> at least one experiment with buffering (in IPv4) that showed it cannot be done. >> This experiment was not definitive, of course, but I think it is >> not wise to write buffering into the standard until more is known >> about whether it will work or not. >> >> There are other alternatives to handoff smoothing, for example bicasting, >> that could handle some portion of the handoff smoothing task without ^^^^^^^^^^^^ please note! >> introducing artifacts. We need to leave the standard open on this >> until there is more evidence. > >you didnt get it. consider this scenario. the MN has sent a F-BU >to the oldAR. lost the link connection. the oldAR starts forwarding >packets to the newAR. MN hasnt shown up yet at the newAR. it hasnt >sent a F-NA or a NA to the newAR yet. (there is some delay in >the MN moving and establishing a link layer connection). if the >newAR does not buffer these packets it would have to drop it. >bicasting does not help here. > As I said, "some portion". I agree that there may be need for buffering on newAR, but currently the draft does not mention any handoff smoothing technique. I don't believe it should mention any, unless it clarifies that bicasting can be used too. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:12:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10879 for ; Thu, 7 Jun 2001 13:12:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07352; Thu, 7 Jun 2001 11:06:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01309; Thu, 7 Jun 2001 10:06:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57H5Y729325 for mobile-ip-dist; Thu, 7 Jun 2001 10:05:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57H5Ue29314 for ; Thu, 7 Jun 2001 10:05:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01089 for ; Thu, 7 Jun 2001 10:05:33 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06295 for ; Thu, 7 Jun 2001 11:05:32 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA05397 for ; Thu, 7 Jun 2001 10:05:32 -0700 (MST)] Received: [from qub10ex01.corp.mot.com (qub10ex01.corp.mot.com [199.5.201.3]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA19030 for ; Thu, 7 Jun 2001 10:05:32 -0700 (MST)] Received: by qub10ex01.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Jun 2001 13:05:31 -0400 Message-ID: From: Diha Marcellin-Y17557 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Problems relative to Mobility Management and real time with Mobil e IP Date: Thu, 7 Jun 2001 13:04:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Just want to know if any one can point me to some documents relative to actual unsolved problems in mobility management and also some documents (if any) that deal with real time issue in Mobile IP. Thanks in advance _________________________________ Marcellin Diha Software Designer MCSC 1200 McGill College Avenue, Montreal Tel: 514-394-7907 Fax: 514-394-7864 E-mail: marcellin.diha@motorola.com From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:25:50 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11035 for ; Thu, 7 Jun 2001 13:25:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16806; Thu, 7 Jun 2001 10:23:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06040; Thu, 7 Jun 2001 10:23:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57HMFb29402 for mobile-ip-dist; Thu, 7 Jun 2001 10:22:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57HMBe29395 for ; Thu, 7 Jun 2001 10:22:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10744; Thu, 7 Jun 2001 10:22:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21559; Thu, 7 Jun 2001 11:22:18 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14260; Thu, 7 Jun 2001 10:22:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57HMHo26570; Thu, 7 Jun 2001 10:22:17 -0700 X-mProtect: Thu, 7 Jun 2001 10:22:17 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsta5cv; Thu, 07 Jun 2001 10:22:16 PDT Message-ID: <3B1FB848.E416B29C@iprg.nokia.com> Date: Thu, 07 Jun 2001 10:22:16 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106071641.JAA23386@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jim, There are already familiar cases where buffering occurs with IP, with good effects. For instance, typically a packet will be buffered today if there isn't an ARP cache entry for a node on the same network as the sender. I find it very difficult to believe your statement that an experiment has shown that buffering cannot be done. Can you provide a citation for this work? My guess is that some unnecessary assumption is being made to cause the particular buffering scheme not to work. In fact, I can "prove" that buffering can be made to work, by a really simple-minded argument that is so silly that I don't want to repeat it here. That would cause a lot of argument about the "proof", and deflect discussion away from the real point. Which is, that whether buffering can work or not depends entirely on the restrictions being made. I support Vijay's suggestion to incorporate some very minimal buffering at the new access router during the time until which a positive indication of link establishment can be detected. It seems almost intuitively obvious that it can work on the tiny timescale that is implied. Regards, Charlie P. James Kempf wrote: > > >Can you add the following text to the draft then? > > > > When the newAR is receiving packets forwarded by the > > oldAR for the MN, and the MN hasnt shown up yet, the > > newAR SHOULD buffer packets. If the newAR does not > > buffer packets, it would the packets meant for the MN. > > > > I don't think this text should be added. > > It is entirely unclear at this point whether buffering will work without causing > user-perceivable artifacts in real time streams. In fact, I know of > at least one experiment with buffering (in IPv4) that showed it cannot be done. > This experiment was not definitive, of course, but I think it is > not wise to write buffering into the standard until more is known > about whether it will work or not. > > There are other alternatives to handoff smoothing, for example bicasting, > that could handle some portion of the handoff smoothing task without > introducing artifacts. We need to leave the standard open on this > until there is more evidence. > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:34:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11164 for ; Thu, 7 Jun 2001 13:34:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21158; Thu, 7 Jun 2001 10:32:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08706; Thu, 7 Jun 2001 10:31:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57HUcw29492 for mobile-ip-dist; Thu, 7 Jun 2001 10:30:38 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57HUYe29484 for ; Thu, 7 Jun 2001 10:30:34 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA25297; Thu, 7 Jun 2001 10:30:41 -0700 (PDT) Message-Id: <200106071730.KAA25297@heliopolis.eng.sun.com> Date: Thu, 7 Jun 2001 10:30:41 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: James.Kempf@Sun.COM, charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tvPLJI+7d0yi4Exe3aESjQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, >There are already familiar cases where buffering occurs with >IP, with good effects. For instance, typically a packet >will be buffered today if there isn't an ARP cache entry >for a node on the same network as the sender. > Sure, I wasn't saying that it wouldn't work, I was saying that it is still not clear that it is the only solution. The draft currently doesn't mention handoff smoothing techniques, I think it should be left that way, unless bicasting is mentioned too. >I find it very difficult to believe your statement that >an experiment has shown that buffering cannot be done. >Can you provide a citation for this work? My guess is The work was never published. It was communicated to me by one of the engineers who were involved in the study (personal communication). >that some unnecessary assumption is being made to cause >the particular buffering scheme not to work. In fact, >I can "prove" that buffering can be made to work, by a >really simple-minded argument that is so silly that I >don't want to repeat it here. That would cause a lot of >argument about the "proof", and deflect discussion away >from the real point. Which is, that whether buffering can >work or not depends entirely on the restrictions being made. > >I support Vijay's suggestion to incorporate some very >minimal buffering at the new access router during the >time until which a positive indication of link establishment >can be detected. It seems almost intuitively obvious that >it can work on the tiny timescale that is implied. > I would rather see the draft kept neutral with respect to handoff smoothing, unless all possibilities are mentioned. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:34:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11177 for ; Thu, 7 Jun 2001 13:34:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01218; Thu, 7 Jun 2001 11:32:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08884; Thu, 7 Jun 2001 10:32:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57HVDa29517 for mobile-ip-dist; Thu, 7 Jun 2001 10:31:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57HV5e29505 for ; Thu, 7 Jun 2001 10:31:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21501; Thu, 7 Jun 2001 10:31:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21309; Thu, 7 Jun 2001 11:31:36 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14839; Thu, 7 Jun 2001 10:31:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57HV1w07470; Thu, 7 Jun 2001 10:31:01 -0700 X-mProtect: Thu, 7 Jun 2001 10:31:01 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdxdKURo; Thu, 07 Jun 2001 10:30:59 PDT Message-ID: <3B1FBA54.BF09D81E@iprg.nokia.com> Date: Thu, 07 Jun 2001 10:31:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106071703.KAA24493@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again, > As I said, "some portion". I agree that there may be need for buffering > on newAR, but currently the draft does not mention any handoff smoothing > technique. I don't believe it should mention any, unless it clarifies > that bicasting can be used too. But I believe that bicasting is problematic in many ways that do not apply to proper buffering techniques. For instance, there is the problem of how to handle multple levels of wireless IP routers. We should be very careful to avoid standardizing techniques for general protocols that are only applicable to specific scenarios. Then there are the control issues (when to start? when to stop?), TCP issues, and at least two or three others that I can't remember right now. Buffering, on the other hand, can be made to be deterministic and precise, as well as delay-bounded and time-limited. I am not wholly against bicasting, because I think it can be made into a useful addition to the set of smooth handover tools. However, it needs to have a lot of work I think before it can be considered as part of network-layer standards. The considerations seem to be somewhat different at the physical layer. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:35:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11197 for ; Thu, 7 Jun 2001 13:35:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21216; Thu, 7 Jun 2001 10:32:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08742; Thu, 7 Jun 2001 10:31:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57HUa029491 for mobile-ip-dist; Thu, 7 Jun 2001 10:30:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57HUVe29476 for ; Thu, 7 Jun 2001 10:30:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21866 for ; Thu, 7 Jun 2001 10:30:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29394 for ; Thu, 7 Jun 2001 11:30:38 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14772 for ; Thu, 7 Jun 2001 10:30:35 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57HUYJ05720 for ; Thu, 7 Jun 2001 10:30:34 -0700 X-mProtect: Thu, 7 Jun 2001 10:30:34 -0700 Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdl7m2DM; Thu, 07 Jun 2001 10:30:32 PDT Message-ID: <3B1FBA39.4D917B41@iprg.nokia.com> Date: Thu, 07 Jun 2001 10:30:33 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106070219.f572JHQ337810@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper Yegin wrote: > Yes, if newAR doesn't buffer, it must drop the packets. That's why we have U > flag. > I guess this was Vijay's point. There is a scenario when the packets start arriving at new AR before the MN has established connecitivity with new AR. Perhaps, you could make the intent of 'U' flag more clear (with the above scenario in mind) ? Regards, -Rajeev > > alper > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:43:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11415 for ; Thu, 7 Jun 2001 13:43:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26819; Thu, 7 Jun 2001 10:42:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11328; Thu, 7 Jun 2001 10:41:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57Hegi29731 for mobile-ip-dist; Thu, 7 Jun 2001 10:40:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57Hece29724 for ; Thu, 7 Jun 2001 10:40:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23936 for ; Thu, 7 Jun 2001 10:40:46 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24145; Thu, 7 Jun 2001 10:40:45 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15547; Thu, 7 Jun 2001 10:40:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57Hehw23058; Thu, 7 Jun 2001 10:40:43 -0700 X-mProtect: Thu, 7 Jun 2001 10:40:43 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdFJer2t; Thu, 07 Jun 2001 10:40:41 PDT Message-ID: <3B1FBC9A.10BEEB2@iprg.nokia.com> Date: Thu, 07 Jun 2001 10:40:42 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106071730.KAA25297@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again Jim, > Sure, I wasn't saying that it wouldn't work, I was saying that > it is still not clear that it is the only solution. The draft > currently doesn't mention handoff smoothing techniques, I think > it should be left that way, unless bicasting is mentioned too. This was the intention all along; the fast handover draft was specifically limited by choice of the design committee to avoid issues of smoothing handovers. >> I find it very difficult to believe your statement that >> an experiment has shown that buffering cannot be done. >> Can you provide a citation for this work? My guess is > > The work was never published. It was communicated to me by > one of the engineers who were involved in the study (personal > communication). I believe I am familiar with the work you mention, and I think that the difficulty that was established was not intrinsic to buffering but had more to do with tunnel establishment and a particular race condtion with Mobile IPv4 at that very fine timescale. >> I support Vijay's suggestion to incorporate some very >> minimal buffering at the new access router during the >> time until which a positive indication of link establishment >> can be detected. It seems almost intuitively obvious that >> it can work on the tiny timescale that is implied. >> > > I would rather see the draft kept neutral with respect to handoff > smoothing, unless all possibilities are mentioned. As noted above, I agree with this also. My solution would be to have a new draft, dealing with smooth handovers. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 13:49:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11478 for ; Thu, 7 Jun 2001 13:49:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10720; Thu, 7 Jun 2001 11:43:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11832; Thu, 7 Jun 2001 10:43:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57HgKJ29753 for mobile-ip-dist; Thu, 7 Jun 2001 10:42:20 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57HgHe29746 for ; Thu, 7 Jun 2001 10:42:17 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA25777; Thu, 7 Jun 2001 10:42:20 -0700 (PDT) Message-Id: <200106071742.KAA25777@heliopolis.eng.sun.com> Date: Thu, 7 Jun 2001 10:42:20 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: James.Kempf@Sun.COM, charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: EBVzpy0hO6xokB/TEHwlNg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, >> As I said, "some portion". I agree that there may be need for buffering >> on newAR, but currently the draft does not mention any handoff smoothing >> technique. I don't believe it should mention any, unless it clarifies >> that bicasting can be used too. > >But I believe that bicasting is problematic in many ways that do not >apply to proper buffering techniques. For instance, there is the >problem of how to handle multple levels of wireless IP routers. We >should be very careful to avoid standardizing techniques for general >protocols that are only applicable to specific scenarios. Then there >are the control issues (when to start? when to stop?), TCP issues, >and at least two or three others that I can't remember right now. > >Buffering, on the other hand, can be made to be deterministic and >precise, as well as delay-bounded and time-limited. > I'd rather not get into a point by point discussion on bicasting v.s. buffering. Actually, I think a combination of bicasting and buffering may be the best solution, together with an L2 trigger that tells the AR when the L2 handover has started. The trick is to keep the buffering restricted to the time in which the L2 link to the mobile is well and truely gone. Otherwise, you run the risk of introducing artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) is probably a better solution in the end. >I am not wholly against bicasting, because I think it can be made >into a useful addition to the set of smooth handover tools. However, >it needs to have a lot of work I think before it can be considered >as part of network-layer standards. The considerations seem to >be somewhat different at the physical layer. > IMHO, this draft currently deals exclusively with latency reduction. There is nothing in it currently about handoff smoothing, in contrast with the v4 draft where both were put into the same draft. If you want to discuss handoff smoothing, then I think all alternatives should be discussed. Otherwise, I think that a reference should be put into the existing draft to a new draft that discusses handoff smoothing. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 15:00:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12594 for ; Thu, 7 Jun 2001 15:00:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17018; Thu, 7 Jun 2001 12:57:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14657; Thu, 7 Jun 2001 11:57:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57Itkd00097 for mobile-ip-dist; Thu, 7 Jun 2001 11:55:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57Itge00090 for ; Thu, 7 Jun 2001 11:55:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12905 for ; Thu, 7 Jun 2001 11:55:48 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20303; Thu, 7 Jun 2001 11:55:43 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA19232; Thu, 7 Jun 2001 13:55:42 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f57Itgp26370; Thu, 7 Jun 2001 13:55:42 -0500 (CDT) Message-ID: <3B1FBF8E.F7906271@usa.alcatel.com> Date: Thu, 07 Jun 2001 13:53:18 -0400 From: Behcet Sarikaya X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: James Kempf Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106071730.KAA25297@heliopolis.eng.sun.com> <3B1FBC9A.10BEEB2@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, "Charles E. Perkins" wrote: > My solution would > be to have a new draft, dealing with smooth handovers. > > Regards, > Charlie P. I second this. But at the same time there is the question of why in the first place this was not included in the fast handover draft for mipv6? The answer is (my guess) there was no agreement on which regional registration protocol to use in the DT. Maybe now there is an agreement. This leads me to suggest that DT could extend its life a bit longer to come up with a single draft for fast and smooth handover. What do you think? -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 7 16:01:06 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13520 for ; Thu, 7 Jun 2001 16:01:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04082; Thu, 7 Jun 2001 12:52:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15458; Thu, 7 Jun 2001 12:51:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57JnO400724 for mobile-ip-dist; Thu, 7 Jun 2001 12:49:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57JnLe00717 for ; Thu, 7 Jun 2001 12:49:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14845 for ; Thu, 7 Jun 2001 12:49:27 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28415 for ; Thu, 7 Jun 2001 12:49:27 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA27298; Thu, 7 Jun 2001 12:49:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f57JnPI09403; Thu, 7 Jun 2001 12:49:25 -0700 X-mProtect: Thu, 7 Jun 2001 12:49:25 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHF8Obj; Thu, 07 Jun 2001 12:49:23 PDT Message-ID: <3B1FDAC3.E277C5A0@iprg.nokia.com> Date: Thu, 07 Jun 2001 12:49:23 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106071730.KAA25297@heliopolis.eng.sun.com> <3B1FBC9A.10BEEB2@iprg.nokia.com> <3B1FBF8E.F7906271@usa.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Behcet, You wrote: > ............ there is the question of why in the > first place this was not included in the fast handover draft for > mipv6? The answer is (my guess) there was no agreement on which regional > registration protocol to use in the DT. No, this issue was not important in the decision. The agreement to concentrate on fast handover instead of smooth handover came because we realized they were different problems. There is a relationship, because the faster the handover, the less time there is to lose packets. But the problems are different. Furthermore, the choice of localized mobility management protocol is not closely related (in my mind) to either problem. This can be seen by considering that handovers (can) depend on a "local" address, and localized mobility management depends on a "remote" address. Alternatively, one could say that fast handover deals with tunnel extension, and localized mobility management deals with localized signaling for tunnel re-establishment. Nevertheless, the problems are not completely independent. They are different but loosely related. > Maybe now there > is an agreement. This leads me to suggest that DT could extend its life > a bit longer to come up with a single draft for fast and smooth > handover. I think that there are still enough issues with the fast handover draft, that we need to focus on that one thing and get it right. Keeping smooth handovers in a separate draft document will help to maintain focus. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 05:23:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07987 for ; Fri, 8 Jun 2001 05:23:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA05914; Fri, 8 Jun 2001 02:21:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22681; Fri, 8 Jun 2001 02:21:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f589KKx02174 for mobile-ip-dist; Fri, 8 Jun 2001 02:20:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f589KHe02167 for ; Fri, 8 Jun 2001 02:20:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18313 for ; Fri, 8 Jun 2001 02:20:25 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27232 for ; Fri, 8 Jun 2001 03:21:00 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f589KMN24674 for ; Fri, 8 Jun 2001 11:20:23 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Jun 08 11:20:13 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 11:20:13 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEED@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 11:19:45 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie and Jim, > > As I said, "some portion". I agree that there may be need for buffering > > on newAR, but currently the draft does not mention any handoff smoothing > > technique. I don't believe it should mention any, unless it clarifies > > that bicasting can be used too. > > But I believe that bicasting is problematic in many ways that do not > apply to proper buffering techniques. For instance, there is the > problem of how to handle multple levels of wireless IP routers. We > should be very careful to avoid standardizing techniques for general > protocols that are only applicable to specific scenarios. > => I believe we need to be specific about the application that is being considered here. If the aim is to minimise the perceived interruption of services during a handover then I clearly support Jim's suggestion. For real time traffic I haven't seen _any_ proof that buffering is a good idea. Please correct me here if you can show the opposite. As far as wireless routers are concerned, I believe your assumption here was that packets will be duplicated first by ARs and then by the wireless routers. Some comments on your assumptions: - You do _not_ receive every packet twice when you're bicasting and I can't see how that would be possible in a "break before make" scenario. Clearly you wouldn't use it as a smoothing technique if you can recive traffic simultaneously from two different routers. - A wireless router does not have to bicast if it sees that as a danger. The entire draft hasn't considered wireless (I guess you mean mobile ) routers anyway. I don't think we've considered mobile routers scenarios at all, so depending on the solutions for that scenario we can discuss the impacts of buffering / bicasting. > Then there > are the control issues (when to start? when to stop?), > => The BU has a lifetime field. There is no difference here. The same issue exists for every BU. If we follow the MIPv6 spec, the lifetime value is effectively negotiated between the MN and the HA/AR/MAP. The receiver of the BU will send back a lower value if needed. The same applies whether bicasting is used or not. Different values can be used for bicasting. > TCP issues, > => see http://search.ietf.org/internet-drafts/draft-ietf-tsvwg-tcp-eifel-alg-00.txt I beleive this will address your concerns. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 05:27:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08024 for ; Fri, 8 Jun 2001 05:27:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05232; Fri, 8 Jun 2001 03:26:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23160; Fri, 8 Jun 2001 02:26:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f589PE902218 for mobile-ip-dist; Fri, 8 Jun 2001 02:25:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f589PAe02211 for ; Fri, 8 Jun 2001 02:25:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07789 for ; Fri, 8 Jun 2001 02:25:19 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18921 for ; Fri, 8 Jun 2001 02:25:18 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f589PGN28624 for ; Fri, 8 Jun 2001 11:25:16 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jun 08 11:25:15 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 11:25:15 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEEE@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 11:25:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > >But I believe that bicasting is problematic in many ways that do not > >apply to proper buffering techniques. For instance, there is the > >problem of how to handle multple levels of wireless IP routers. We > >should be very careful to avoid standardizing techniques for general > >protocols that are only applicable to specific scenarios. Then there > >are the control issues (when to start? when to stop?), TCP issues, > >and at least two or three others that I can't remember right now. > > > >Buffering, on the other hand, can be made to be deterministic and > >precise, as well as delay-bounded and time-limited. > > > > Actually, I think a combination of bicasting and buffering may be > the best solution, together with an L2 trigger that tells the AR > when the L2 handover has started. The trick is to keep the buffering > restricted to the time in which the L2 link to the mobile > is well and truely gone. Otherwise, you run the risk of introducing > artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) is > probably a better solution in the end. > => This would be the best way of handling the smoothing of the handover. I fully agree with that. > >I am not wholly against bicasting, because I think it can be made > >into a useful addition to the set of smooth handover tools. However, > >it needs to have a lot of work I think before it can be considered > >as part of network-layer standards. The considerations seem to > >be somewhat different at the physical layer. > > > > IMHO, this draft currently deals exclusively with latency reduction. There is > nothing in it currently about handoff smoothing, in contrast with > the v4 draft where both were put into the same draft. If you > want to discuss handoff smoothing, then I think all alternatives > should be discussed. Otherwise, I think that a reference should > be put into the existing draft to a new draft that discusses handoff smoothing. > => Agreed again. This has been my point all along. The v4 draft covers the entire space and I don't understand why we can't do the same thing for v6. I don't see any fundamental differences that would stop us from using the smoothing techniques in v4 or ping pong avoidance. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 05:32:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08112 for ; Fri, 8 Jun 2001 05:32:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09280; Fri, 8 Jun 2001 02:31:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23649; Fri, 8 Jun 2001 02:31:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f589UiI02275 for mobile-ip-dist; Fri, 8 Jun 2001 02:30:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f589Uee02268 for ; Fri, 8 Jun 2001 02:30:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23576 for ; Fri, 8 Jun 2001 02:30:49 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08400 for ; Fri, 8 Jun 2001 03:30:47 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f589UkN03280 for ; Fri, 8 Jun 2001 11:30:46 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jun 08 11:30:45 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 11:30:45 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEEF@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 11:30:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Behcet, > > My solution would > > be to have a new draft, dealing with smooth handovers. > > > > Regards, > > Charlie P. > > I second this. But at the same time there is the question of why in the > first place this was not included in the fast handover draft for > mipv6? The answer is (my guess) there was no agreement on which regional > registration protocol to use in the DT. Maybe now there > is an agreement. > => This was not related to the Fast handoffs draft and we never discussed it in the DT. The idea was that the draft will coexist, but, not depend on, any of the LMM techniques. > This leads me to suggest that DT could extend its life > a bit longer to come up with a single draft for fast and smooth > handover. > What do you think? > => Well, the draft already had the smoothing techniques before and they were removed in the last minute. So it would be really simple to reintroduce them. Having them in another draft doesn't make sense to me. We have one draft for low latency handovers for v4 and if you implement it you will get a complete solution, i don't see why we should distribute the Fast Handoffs draft for v6 over several drafts. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 06:26:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08615 for ; Fri, 8 Jun 2001 06:26:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA26212; Fri, 8 Jun 2001 03:24:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27322; Fri, 8 Jun 2001 03:23:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58AM8b02412 for mobile-ip-dist; Fri, 8 Jun 2001 03:22:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58AM5e02405 for ; Fri, 8 Jun 2001 03:22:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18360 for ; Fri, 8 Jun 2001 03:22:10 -0700 (PDT) Received: from mx02.melco.co.jp (mx01.melco.co.jp [192.218.140.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06603 for ; Fri, 8 Jun 2001 04:22:08 -0600 (MDT) Received: by mx02.melco.co.jp (mx02) id TAA18924; Fri, 8 Jun 2001 19:22:06 +0900 (JST) Received: by mr01.melco.co.jp (mr01) id TAA06561; Fri, 8 Jun 2001 19:22:06 +0900 (JST) Received: from islgw.isl.melco.co.jp by elgw.isl.melco.co.jp (8.8.8/3.6W) id TAA05103; Fri, 8 Jun 2001 19:22:05 +0900 (JST) Received: from ishitp570 by islgw.isl.melco.co.jp (8.8.8/3.6W) id TAA27325; Fri, 8 Jun 2001 19:22:05 +0900 (JST) Message-ID: <01cb01c0f005$0a1d29c0$1a084a0a@ishitp570> From: "Koichi Ishibashi" To: Cc: "Ishibashi" References: <795A014AF92DD21182AF0008C7A404320C5203FF@esealnt117> Subject: Re: [mobile-ip] behavior on Mobility Agent during Mobile IP handoff Date: Fri, 8 Jun 2001 19:23:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Karim, My comments are following, > >In my opinion, I think that a future network should > >support a QoS mechanism and a mobile network should > >need to support a QoS also. > >When the mobile network supports a QoS, > >I think that a mobility agent should also support > >a QoS and differentiate the microflows. > >And the above support of QoS should be applied to > >a Handoff procedure as well as a Tunneling and > >Forwarding procedure. > >For example, according to an implicit or explicit configuration, > >a mobility agent should decide whether to bi-cast the packets > >for each microflow or not. > > I'd say that can be considered but only simulations can tell us > how much gain can come out of differentiating the FA behaviour > during a fast handoff. If you don't bicast on some flows will that > gain you much compared to the added FA complexity? It's quite > important to find out before adding this function. I agree as to the need of a simulation. But I have not simulated for comparing each efficiency. However, I also have a doubt about the efficiency of bi-casting when considering the TCP behavior. And I think that a FA is a edge wired Router. So, in my opinion, the FA may implement some QoS mechanism. Regards. Ishibashi From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 06:45:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08866 for ; Fri, 8 Jun 2001 06:45:32 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17099; Fri, 8 Jun 2001 04:45:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13410; Fri, 8 Jun 2001 03:45:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58AiHs02475 for mobile-ip-dist; Fri, 8 Jun 2001 03:44:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58AiEe02468 for ; Fri, 8 Jun 2001 03:44:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24150 for ; Fri, 8 Jun 2001 03:44:19 -0700 (PDT) Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr [193.49.124.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA16659 for ; Fri, 8 Jun 2001 04:44:18 -0600 (MDT) Received: by p-voyageur.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 12:44:16 +0200 Received: from francetelecom.com (p-dico.rd.francetelecom.fr [139.100.18.135]) by p-grive.rd.francetelecom.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ML90XRJM; Fri, 8 Jun 2001 12:44:14 +0200 Message-ID: <3B20AC24.A26D1131@francetelecom.com> Date: Fri, 08 Jun 2001 12:42:45 +0200 From: Jean-Michel COMBES Organization: France =?iso-8859-1?Q?T=E9l=E9com?= R&D X-Mailer: Mozilla 4.75 [fr] (Windows NT 5.0; U) X-Accept-Language: fr MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <35DBB8B7AC89D4118E98009027B1009B1B7C76@IL27EXM10.cig.mot.com> <3B1E80C9.DAB8A52F@iprg.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id EAA17099 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA08866 Hi Vijay and Alper, Vijay Devarapalli a écrit : > answer for question 3. > > it will work if the following happens. JMC : I don't think so. > > > when the MN sends a F-BU when at the oldAR, the source address > of the packet is oldCoA. the newCoA is included in the alt-CoA > sub-option. JMC : What happens if ESP is used ? Alt-CoA will be encrypted and you couldn't do filtering ... > > > > 3- This question was asked on the list, I am not sure if I saw a convincing > > answer other than comparing F-BU with BU. > > The MN cannot use its newCoA as source address until it has received > > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > > Isn't this a chicken and egg problem? What am I missing? > > Also what about ingress filtering issue at oldAR? JMC. -- France Telecom R&D - DTL/SSR Jean-Michel COMBES, Internet/Intranet Security E-Mail : jeanmichel.combes@francetelecom.com Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 13:15:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17279 for ; Fri, 8 Jun 2001 13:15:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12283; Fri, 8 Jun 2001 11:14:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08637; Fri, 8 Jun 2001 10:13:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58HCsX02985 for mobile-ip-dist; Fri, 8 Jun 2001 10:12:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58HCpe02978 for ; Fri, 8 Jun 2001 10:12:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28526 for ; Fri, 8 Jun 2001 10:12:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28833 for ; Fri, 8 Jun 2001 10:12:57 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03964 for ; Fri, 8 Jun 2001 10:12:57 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58HCv802483 for ; Fri, 8 Jun 2001 10:12:57 -0700 X-mProtect: Fri, 8 Jun 2001 10:12:57 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd0Kq9nc; Fri, 08 Jun 2001 10:12:56 PDT Message-ID: <3B210798.D1B0C23A@iprg.nokia.com> Date: Fri, 08 Jun 2001 10:12:56 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <35DBB8B7AC89D4118E98009027B1009B1B7C76@IL27EXM10.cig.mot.com> <3B1E80C9.DAB8A52F@iprg.nokia.com> <3B20AC24.A26D1131@francetelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, Jean-Michel COMBES wrote: > JMC : > I don't think so. it will work. > > when the MN sends a F-BU when at the oldAR, the source address > > of the packet is oldCoA. the newCoA is included in the alt-CoA > > sub-option. > > JMC : > What happens if ESP is used ? Alt-CoA will be encrypted and you couldn't do filtering ... what filtering? the source address of the F-BU is the oldCoA and it is still attached to oldAR. so ingress filtering is fine. the altCoA is needed only when you start processing the BU option. when you start processing the BU, you would have already decrypted the packet. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 13:28:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17578 for ; Fri, 8 Jun 2001 13:28:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25208; Fri, 8 Jun 2001 11:27:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11692; Fri, 8 Jun 2001 10:26:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58HPxH03046 for mobile-ip-dist; Fri, 8 Jun 2001 10:25:59 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58HPte03039 for ; Fri, 8 Jun 2001 10:25:56 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA23813 for ; Fri, 8 Jun 2001 10:26:03 -0700 (PDT) Message-Id: <200106081726.KAA23813@heliopolis.eng.sun.com> Date: Fri, 8 Jun 2001 10:26:03 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Kn/q2MujaV+B1sugu0Ov9A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Vijay, >> JMC : >> What happens if ESP is used ? Alt-CoA will be encrypted and you couldn't do filtering ... > >what filtering? the source address of the F-BU is the oldCoA >and it is still attached to oldAR. so ingress filtering is fine. > This is only if everything goes as planned. It is also possible that the F-BU could get sent after the L2 handover. And there are lots of possibilities for things to go wrong. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 14:09:14 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18329 for ; Fri, 8 Jun 2001 14:09:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01647; Fri, 8 Jun 2001 12:07:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19746; Fri, 8 Jun 2001 11:07:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58I6Pi03164 for mobile-ip-dist; Fri, 8 Jun 2001 11:06:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58I6Je03157 for ; Fri, 8 Jun 2001 11:06:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10494 for ; Fri, 8 Jun 2001 11:06:23 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from zircon.3com.com (zircon.3com.com [192.156.136.159]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25776 for ; Fri, 8 Jun 2001 11:06:23 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by zircon.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f58I7Gf10192 for ; Fri, 8 Jun 2001 11:07:16 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f58I5VI00151 for ; Fri, 8 Jun 2001 11:05:31 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A65.00635E25 ; Fri, 8 Jun 2001 11:05:21 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A65.00635B0D.00@hqoutbound.ops.3com.com> Date: Fri, 8 Jun 2001 11:05:35 -0700 Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I agree. It is also not clear on "mobile has not arrived". Has the mobile been authenticated by the new AR? If not, how the new AR can receive packets for un-authenticated mobile. We need to check security issues here. Barani. James Kempf on 06/07/2001 09:41:22 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: James Kempf To: mobile-ip@sunroof.eng.sun.com cc: (Barani Subbiah/HQ/3Com) Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 >Can you add the following text to the draft then? > > When the newAR is receiving packets forwarded by the > oldAR for the MN, and the MN hasnt shown up yet, the > newAR SHOULD buffer packets. If the newAR does not > buffer packets, it would the packets meant for the MN. > I don't think this text should be added. It is entirely unclear at this point whether buffering will work without causing user-perceivable artifacts in real time streams. In fact, I know of at least one experiment with buffering (in IPv4) that showed it cannot be done. This experiment was not definitive, of course, but I think it is not wise to write buffering into the standard until more is known about whether it will work or not. There are other alternatives to handoff smoothing, for example bicasting, that could handle some portion of the handoff smoothing task without introducing artifacts. We need to leave the standard open on this until there is more evidence. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 14:18:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18510 for ; Fri, 8 Jun 2001 14:18:32 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02819; Fri, 8 Jun 2001 11:13:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20485; Fri, 8 Jun 2001 11:11:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58IAZB03214 for mobile-ip-dist; Fri, 8 Jun 2001 11:10:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58IAQe03203 for ; Fri, 8 Jun 2001 11:10:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29639 for ; Fri, 8 Jun 2001 11:10:31 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04257 for ; Fri, 8 Jun 2001 12:10:30 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA08415 for ; Fri, 8 Jun 2001 11:10:31 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58IAU009522 for ; Fri, 8 Jun 2001 11:10:30 -0700 X-mProtect: Fri, 8 Jun 2001 11:10:30 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpduXtEvo; Fri, 08 Jun 2001 11:10:29 PDT Message-ID: <3B211515.86B58139@iprg.nokia.com> Date: Fri, 08 Jun 2001 11:10:29 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <200106081726.KAA23813@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > > Hi Vijay, > > >> JMC : > >> What happens if ESP is used ? Alt-CoA will be encrypted and you couldn't do > filtering ... > > > >what filtering? the source address of the F-BU is the oldCoA > >and it is still attached to oldAR. so ingress filtering is fine. > > > > This is only if everything goes as planned. It is also possible that > the F-BU could get sent after the L2 handover. And there are > lots of possibilities for things to go wrong. > thats right. but we were talking about sending F-BU when still attached to the oldAR. at the newAR there is a problem. the MN still uses the oldCoA as the source address (because it cannot start using its newCoA), but the newAR knows about oldCoA (it came in the HI message from the oldAR). the newAR also has the link layer address of the MN (this also from the HI message). it can be made to work. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 14:19:11 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18525 for ; Fri, 8 Jun 2001 14:19:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11374; Fri, 8 Jun 2001 12:18:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21917; Fri, 8 Jun 2001 11:18:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58IH7Q03263 for mobile-ip-dist; Fri, 8 Jun 2001 11:17:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58IH4e03256 for ; Fri, 8 Jun 2001 11:17:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12591 for ; Fri, 8 Jun 2001 11:17:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25537 for ; Fri, 8 Jun 2001 12:17:43 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA09223 for ; Fri, 8 Jun 2001 11:17:04 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58IH4X21101 for ; Fri, 8 Jun 2001 11:17:04 -0700 X-mProtect: Fri, 8 Jun 2001 11:17:04 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdQ53GFo; Fri, 08 Jun 2001 11:17:02 PDT Message-ID: <3B21169E.1FD127E3@iprg.nokia.com> Date: Fri, 08 Jun 2001 11:17:02 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <88256A65.00635B0D.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Barani_Subbiah@3com.com wrote: > > I agree. It is also not clear on "mobile has not arrived". Has the mobile been the newAR has not received any NA or a F_NA (as defined in the fast handoff draft, which i assume you havent read yet). if a link level trigger exists, the newAR hasnt received this trigger yet. this means the mobile has not arrived yet. authentication is after that. you dont do authentication before establishing a link level connection and sending a NA. and the fast handoff draft is not trying to solve authentication between the MN and the access router. vijay > authenticated by the new AR? If not, how the new AR can receive packets for > un-authenticated mobile. We need to check security issues here. > > Barani. > > James Kempf on 06/07/2001 09:41:22 AM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: James Kempf > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > >Can you add the following text to the draft then? > > > > When the newAR is receiving packets forwarded by the > > oldAR for the MN, and the MN hasnt shown up yet, the > > newAR SHOULD buffer packets. If the newAR does not > > buffer packets, it would the packets meant for the MN. > > > > I don't think this text should be added. > > It is entirely unclear at this point whether buffering will work without causing > user-perceivable artifacts in real time streams. In fact, I know of > at least one experiment with buffering (in IPv4) that showed it cannot be done. > This experiment was not definitive, of course, but I think it is > not wise to write buffering into the standard until more is known > about whether it will work or not. > > There are other alternatives to handoff smoothing, for example bicasting, > that could handle some portion of the handoff smoothing task without > introducing artifacts. We need to leave the standard open on this > until there is more evidence. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 14:45:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18863 for ; Fri, 8 Jun 2001 14:45:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15751; Fri, 8 Jun 2001 11:44:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27474; Fri, 8 Jun 2001 11:44:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58IhNr05468 for mobile-ip-dist; Fri, 8 Jun 2001 11:43:24 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58IhKe05457 for ; Fri, 8 Jun 2001 11:43:20 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA25714 for ; Fri, 8 Jun 2001 11:28:40 -0700 (PDT) Message-Id: <200106081828.LAA25714@heliopolis.eng.sun.com> Date: Fri, 8 Jun 2001 11:28:40 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9xXxe6QsVgYXVcUSh2yYtw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> >> JMC : >> >> What happens if ESP is used ? Alt-CoA will be encrypted and you couldn't do >> filtering ... >> > >> >what filtering? the source address of the F-BU is the oldCoA >> >and it is still attached to oldAR. so ingress filtering is fine. >> > >> >> This is only if everything goes as planned. It is also possible that >> the F-BU could get sent after the L2 handover. And there are >> lots of possibilities for things to go wrong. >> > >thats right. but we were talking about sending F-BU when still >attached to the oldAR. > Might not get there. Remember, we're in a handover situation, so the radio L2 may not be the best. Also, even if MN sends it when thinks its attached to oldAR, it might actually be in transit or already arrived at newAR. The draft says nothing about how MN knows whether or not its attached to oldAR, nor about the timing of L3 v.s. L2 handover. >at the newAR there is a problem. the MN still uses the oldCoA >as the source address (because it cannot start using its >newCoA), but the newAR knows about oldCoA (it came in the HI >message from the oldAR). the newAR also has the link layer >address of the MN (this also from the HI message). it can be >made to work. > Right, if newAR does a reverse tunnel back to oldAR. The draft doesn't talk about this, though. In subsequent email, Alper made clear that was intended, but the draft needs revision. But your point about newAR knowing oldCoA is made. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 14:58:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19124 for ; Fri, 8 Jun 2001 14:58:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16390; Fri, 8 Jun 2001 12:57:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18695; Fri, 8 Jun 2001 11:57:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58IuJl05571 for mobile-ip-dist; Fri, 8 Jun 2001 11:56:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58IuFe05564 for ; Fri, 8 Jun 2001 11:56:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18515 for ; Fri, 8 Jun 2001 11:56:21 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18224 for ; Fri, 8 Jun 2001 11:56:21 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f58IsP321375 for ; Fri, 8 Jun 2001 11:54:25 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f58IuKI06205 for ; Fri, 8 Jun 2001 11:56:20 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A65.0068049D ; Fri, 8 Jun 2001 11:56:09 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A65.0068000D.00@hqoutbound.ops.3com.com> Date: Fri, 8 Jun 2001 11:56:19 -0700 Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: comments below. Barani Vijay Devarapalli on 06/08/2001 11:17:02 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Vijay Devarapalli To: mobile-ip@sunroof.eng.sun.com cc: (Barani Subbiah/HQ/3Com) Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Barani_Subbiah@3com.com wrote: > > I agree. It is also not clear on "mobile has not arrived". Has the mobile been the newAR has not received any NA or a F_NA (as defined in the fast handoff draft, which i assume you havent read yet). if a link level trigger exists, the newAR hasnt received this trigger yet. this means the mobile has not arrived yet. >>> There is both logical and physical way of looking whether a mobile has arrived. Old AR can inform the new AR that a mobile has logically handed over ("arrived") so that the new AR can accept the packets before any physical identification of the mobile with new AR. Do not assume too much. I see that your proposing a solution with out looking at other possibilities or issues. authentication is after that. you dont do authentication before establishing a link level connection and sending a NA. >> I was asking about how the new AR is authorised to receive the packets for the new mobile node before mobile is physically attached. One way is that old AR informs new AR and new AR can get an authentication for mobile from network before it arrives. This would allow the new AR to receive the packets with out any security problems. We are talking about buffering packets not just receive and discard. and the fast handoff draft is not trying to solve authentication between the MN and the access router. >> yes, however it should not create any holes either. vijay > authenticated by the new AR? If not, how the new AR can receive packets for > un-authenticated mobile. We need to check security issues here. > > Barani. > > James Kempf on 06/07/2001 09:41:22 AM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: James Kempf > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > >Can you add the following text to the draft then? > > > > When the newAR is receiving packets forwarded by the > > oldAR for the MN, and the MN hasnt shown up yet, the > > newAR SHOULD buffer packets. If the newAR does not > > buffer packets, it would the packets meant for the MN. > > > > I don't think this text should be added. > > It is entirely unclear at this point whether buffering will work without causing > user-perceivable artifacts in real time streams. In fact, I know of > at least one experiment with buffering (in IPv4) that showed it cannot be done. > This experiment was not definitive, of course, but I think it is > not wise to write buffering into the standard until more is known > about whether it will work or not. > > There are other alternatives to handoff smoothing, for example bicasting, > that could handle some portion of the handoff smoothing task without > introducing artifacts. We need to leave the standard open on this > until there is more evidence. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:03:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19236 for ; Fri, 8 Jun 2001 15:03:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21837; Fri, 8 Jun 2001 12:00:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18621; Fri, 8 Jun 2001 11:56:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58Ittp05562 for mobile-ip-dist; Fri, 8 Jun 2001 11:55:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58Itpe05555 for ; Fri, 8 Jun 2001 11:55:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18464 for ; Fri, 8 Jun 2001 11:55:56 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15076 for ; Fri, 8 Jun 2001 12:55:55 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA13388 for ; Fri, 8 Jun 2001 11:55:55 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA00183 for ; Fri, 8 Jun 2001 11:49:24 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 13:55:54 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C8B@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 13:55:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks Vijay, Yes, my question was what you stated below. Also could you please let me know where U flag is described? Madjid -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Wednesday, June 06, 2001 3:06 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 hi Alper, > We have a 'U' Buffer Flag in HA message. And I think this makes it an optional > feature. oldAR MAY turn this flag on. Do you think we should spell this out in > the draft? it is slightly different. by setting the 'U' flag, the oldAR basically tells the newAR, that i have been buffering packets for this particular MN. you should also do it. and in the scenario, Madjid was talking about, the newAR is receiving packets forwarded by the oldAR to the MN. but the MN hasnt shown up yet. here it MUST buffer packets, whether the 'U' flag in the HI was set or not. if it doesnt buffer, it has to drop the packets till the MN shows up. vijay > > > > > > > 3- This question was asked on the list, I am not sure if I saw a convincing > > answer other than comparing F-BU with BU. > > The MN cannot use its newCoA as source address until it has received > > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > > Isn't this a chicken and egg problem? What am I missing? > > Also what about ingress filtering issue at oldAR? > > > > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA > as the source address, and include a alternate CoA suboption. (I'm not sure if > this is already stated in the draft. If not, we should add this.) > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:03:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19252 for ; Fri, 8 Jun 2001 15:03:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21518; Fri, 8 Jun 2001 13:02:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20283; Fri, 8 Jun 2001 12:02:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58J1Rj05645 for mobile-ip-dist; Fri, 8 Jun 2001 12:01:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58J1Me05638 for ; Fri, 8 Jun 2001 12:01:22 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f58J1PQ733900 for ; Fri, 8 Jun 2001 12:01:26 -0700 (PDT) Message-Id: <200106081901.f58J1PQ733900@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 12:01:27 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5aiUiiWadtM0RBnOD58dtA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > Actually, I think a combination of bicasting and buffering may be > > the best solution, together with an L2 trigger that tells the AR > > when the L2 handover has started. The trick is to keep the buffering > > restricted to the time in which the L2 link to the mobile > > is well and truely gone. Otherwise, you run the risk of introducing > > artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) is > > probably a better solution in the end. > > > => This would be the best way of handling the smoothing > of the handover. I fully agree with that. If the L2 trigger mentioned above is the capability on the AR to say "MN has detached" or "MN has attached", then I don't see why we would also need bi-casting. This L2 feature itself is sufficient to direct the traffic either towards the current link on oldAR (MN is still attached), or towards the newAR (as soon as MN detaches). I don't think we need bi-casting if we have this L2 feature. alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:09:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19337 for ; Fri, 8 Jun 2001 15:09:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24608; Fri, 8 Jun 2001 12:07:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20682; Fri, 8 Jun 2001 12:04:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58J3bA05700 for mobile-ip-dist; Fri, 8 Jun 2001 12:03:37 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58J3Xe05693 for ; Fri, 8 Jun 2001 12:03:33 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f58J3bQ734427 for ; Fri, 8 Jun 2001 12:03:37 -0700 (PDT) Message-Id: <200106081903.f58J3bQ734427@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 12:03:38 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: DEL29cXcNHH3AjCX8AZKYA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f58J3Ye05694 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id MAA24608 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA19337 > Hi Vijay and Alper, > > Vijay Devarapalli a écrit : > > > answer for question 3. > > > > it will work if the following happens. > > JMC : > I don't think so. > > > > > > > when the MN sends a F-BU when at the oldAR, the source address > > of the packet is oldCoA. the newCoA is included in the alt-CoA > > sub-option. > > JMC : > What happens if ESP is used ? Alt-CoA will be encrypted and you couldn't do filtering ... The recepient of this BU, oldAR, would know how to decrypt this packet, and retrieve the alt-CoA. alper > > > > > > > 3- This question was asked on the list, I am not sure if I saw a convincing > > > answer other than comparing F-BU with BU. > > > The MN cannot use its newCoA as source address until it has received > > > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > > > Isn't this a chicken and egg problem? What am I missing? > > > Also what about ingress filtering issue at oldAR? > > JMC. > > -- > > France Telecom R&D - DTL/SSR > Jean-Michel COMBES, Internet/Intranet Security > E-Mail : jeanmichel.combes@francetelecom.com > Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 > PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214 > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:10:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19387 for ; Fri, 8 Jun 2001 15:10:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27088; Fri, 8 Jun 2001 13:08:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21649; Fri, 8 Jun 2001 12:08:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58J7pM05774 for mobile-ip-dist; Fri, 8 Jun 2001 12:07:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58J7le05767 for ; Fri, 8 Jun 2001 12:07:47 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f58J7pQ735461; Fri, 8 Jun 2001 12:07:51 -0700 (PDT) Message-Id: <200106081907.f58J7pQ735461@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 12:07:53 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ycRVgY3uxkCk+T+GDSroGg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I agree. It is also not clear on "mobile has not arrived". Has the mobile been > authenticated by the new AR? If not, how the new AR can receive packets for > un-authenticated mobile. We need to check security issues here. F-BU authenticates MN to oldAR. HI authenticates oldAR to newAR. If you are asking "how can newAR trust MN and release the buffers", that's outside the scope of this draft. Even without buffering, some other node on the same link can steal your traffic by overwriting neighbor cache of the AR. alper > > Barani. > > > > > James Kempf on 06/07/2001 09:41:22 AM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: James Kempf > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > >Can you add the following text to the draft then? > > > > When the newAR is receiving packets forwarded by the > > oldAR for the MN, and the MN hasnt shown up yet, the > > newAR SHOULD buffer packets. If the newAR does not > > buffer packets, it would the packets meant for the MN. > > > > I don't think this text should be added. > > It is entirely unclear at this point whether buffering will work without causing > user-perceivable artifacts in real time streams. In fact, I know of > at least one experiment with buffering (in IPv4) that showed it cannot be done. > This experiment was not definitive, of course, but I think it is > not wise to write buffering into the standard until more is known > about whether it will work or not. > > There are other alternatives to handoff smoothing, for example bicasting, > that could handle some portion of the handoff smoothing task without > introducing artifacts. We need to leave the standard open on this > until there is more evidence. > > jak > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:14:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19451 for ; Fri, 8 Jun 2001 15:14:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26448; Fri, 8 Jun 2001 12:11:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21688; Fri, 8 Jun 2001 12:08:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58J7g305761 for mobile-ip-dist; Fri, 8 Jun 2001 12:07:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58J7be05754 for ; Fri, 8 Jun 2001 12:07:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02803 for ; Fri, 8 Jun 2001 12:07:43 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25332 for ; Fri, 8 Jun 2001 13:08:16 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id MAA04053 for ; Fri, 8 Jun 2001 12:07:41 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id MAA27142 for ; Fri, 8 Jun 2001 12:07:40 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 14:07:40 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C8C@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 14:07:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, I can understand if the draft does not want to mandate or recommend buffering, specifically for real time application, where buffering a lot of data does not solve user problems. However, it was not clear to me what drafts' position on buffering is, specially since one of its prime goals is reducing latency for real time application: Is buffering optional (when buffering helps, says 1-2 voice packets) supported, not supported? Does the draft provide guidelines or talk about tradeoffs? I think buffering is an important issues. Regards, Madjid -----Original Message----- From: James Kempf [mailto:James.Kempf@Sun.COM] Sent: Thursday, June 07, 2001 11:41 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 >Can you add the following text to the draft then? > > When the newAR is receiving packets forwarded by the > oldAR for the MN, and the MN hasnt shown up yet, the > newAR SHOULD buffer packets. If the newAR does not > buffer packets, it would the packets meant for the MN. > I don't think this text should be added. It is entirely unclear at this point whether buffering will work without causing user-perceivable artifacts in real time streams. In fact, I know of at least one experiment with buffering (in IPv4) that showed it cannot be done. This experiment was not definitive, of course, but I think it is not wise to write buffering into the standard until more is known about whether it will work or not. There are other alternatives to handoff smoothing, for example bicasting, that could handle some portion of the handoff smoothing task without introducing artifacts. We need to leave the standard open on this until there is more evidence. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:19:40 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19536 for ; Fri, 8 Jun 2001 15:19:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04851; Fri, 8 Jun 2001 13:18:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23432; Fri, 8 Jun 2001 12:17:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58JFF305853 for mobile-ip-dist; Fri, 8 Jun 2001 12:15:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58JFBe05846 for ; Fri, 8 Jun 2001 12:15:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25274 for ; Fri, 8 Jun 2001 12:15:17 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23684 for ; Fri, 8 Jun 2001 12:15:17 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Jun 2001 15:07:58 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] WG Last Call Date: Fri, 8 Jun 2001 15:07:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a Mobile IP WG last call for the I-D draft-ietf-mobileip-aaa-key-06.txt AAA Registration Keys for Mobile IP. This draft will be sent to the IESG requesting a proposed standard status to be associated with it at the end of the last call period. Please send your comments to the WG discussion list. WG Last call issued on : Jun 8, 2001 Expires on : Jun 22, 2001 Basavaraj Patil Phil Roberts From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:20:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19559 for ; Fri, 8 Jun 2001 15:20:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29791; Fri, 8 Jun 2001 12:19:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23419; Fri, 8 Jun 2001 12:17:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58JFfx05865 for mobile-ip-dist; Fri, 8 Jun 2001 12:15:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58JFbe05858 for ; Fri, 8 Jun 2001 12:15:38 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f58JFcQ736927 for ; Fri, 8 Jun 2001 12:15:40 -0700 (PDT) Message-Id: <200106081915.f58JFcQ736927@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 12:15:39 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MZCgLeMOyrAKmRH9llr4Ug== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, > >> >> JMC : > >> >> What happens if ESP is used ? Alt-CoA will be encrypted and you couldn't > do > >> filtering ... > >> > > >> >what filtering? the source address of the F-BU is the oldCoA > >> >and it is still attached to oldAR. so ingress filtering is fine. > >> > > >> > >> This is only if everything goes as planned. It is also possible that > >> the F-BU could get sent after the L2 handover. And there are > >> lots of possibilities for things to go wrong. > >> > > > >thats right. but we were talking about sending F-BU when still > >attached to the oldAR. > > > > Might not get there. Remember, we're in a handover situation, so > the radio L2 may not be the best. > > Also, even if MN sends it when thinks its attached to oldAR, it > might actually be in transit or already arrived at newAR. The draft says Wouldn't you say MN's L2 should be aware of this? (we should clarify this in the draft) > nothing about how MN knows whether or not its attached to oldAR, nor about > the timing of L3 v.s. L2 handover. > > >at the newAR there is a problem. the MN still uses the oldCoA > >as the source address (because it cannot start using its > >newCoA), but the newAR knows about oldCoA (it came in the HI > >message from the oldAR). the newAR also has the link layer > >address of the MN (this also from the HI message). it can be > >made to work. > > > > > Right, if newAR does a reverse tunnel back to oldAR. The draft > doesn't talk about this, though. In subsequent email, Alper made > clear that was intended, but the draft needs revision. Yes, this was already noted for next revision. > > But your point about newAR knowing oldCoA is made. > > jak > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:34:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19686 for ; Fri, 8 Jun 2001 15:34:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04093; Fri, 8 Jun 2001 12:30:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15922; Fri, 8 Jun 2001 12:30:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58JSxR05973 for mobile-ip-dist; Fri, 8 Jun 2001 12:28:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58JSue05966 for ; Fri, 8 Jun 2001 12:28:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06804 for ; Fri, 8 Jun 2001 12:29:02 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01029 for ; Fri, 8 Jun 2001 12:29:01 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f58JR3324550 for ; Fri, 8 Jun 2001 12:27:03 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f58JSwI09141 for ; Fri, 8 Jun 2001 12:28:58 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A65.006B00E6 ; Fri, 8 Jun 2001 12:28:45 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A65.006B0068.00@hqoutbound.ops.3com.com> Date: Fri, 8 Jun 2001 12:29:07 -0700 Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks. it woud not be bad idea to include issues out of scope in this draft. Barani. Alper Yegin on 06/08/2001 12:07:53 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Alper Yegin To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com (Barani Subbiah/HQ/3Com) Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > I agree. It is also not clear on "mobile has not arrived". Has the mobile been > authenticated by the new AR? If not, how the new AR can receive packets for > un-authenticated mobile. We need to check security issues here. F-BU authenticates MN to oldAR. HI authenticates oldAR to newAR. If you are asking "how can newAR trust MN and release the buffers", that's outside the scope of this draft. Even without buffering, some other node on the same link can steal your traffic by overwriting neighbor cache of the AR. alper > > Barani. > > > > > James Kempf on 06/07/2001 09:41:22 AM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: James Kempf > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > >Can you add the following text to the draft then? > > > > When the newAR is receiving packets forwarded by the > > oldAR for the MN, and the MN hasnt shown up yet, the > > newAR SHOULD buffer packets. If the newAR does not > > buffer packets, it would the packets meant for the MN. > > > > I don't think this text should be added. > > It is entirely unclear at this point whether buffering will work without causing > user-perceivable artifacts in real time streams. In fact, I know of > at least one experiment with buffering (in IPv4) that showed it cannot be done. > This experiment was not definitive, of course, but I think it is > not wise to write buffering into the standard until more is known > about whether it will work or not. > > There are other alternatives to handoff smoothing, for example bicasting, > that could handle some portion of the handoff smoothing task without > introducing artifacts. We need to leave the standard open on this > until there is more evidence. > > jak > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:42:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19780 for ; Fri, 8 Jun 2001 15:42:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25233; Fri, 8 Jun 2001 13:41:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18482; Fri, 8 Jun 2001 12:41:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58JdI606035 for mobile-ip-dist; Fri, 8 Jun 2001 12:39:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58JdEe06028 for ; Fri, 8 Jun 2001 12:39:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08862 for ; Fri, 8 Jun 2001 12:39:20 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22977 for ; Fri, 8 Jun 2001 13:39:19 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA09805 for ; Fri, 8 Jun 2001 12:39:19 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA15242 for ; Fri, 8 Jun 2001 12:39:19 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 14:39:18 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C8D@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 14:39:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, Hate to bring security issues in here, since this was about buffering but, you brought it up :) Sorry. 1-Why does MN need to authenticate itself to oldAR, while it is saying "goodbye" to it. It has been receiving service from oldAR so far, hasn't it? 2-authentication of oldAR to newAR does not solve all the security problems, what about authentication of newAR to oldAR, what about authorization of newAR to receive MN's packets? Madjid -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Friday, June 08, 2001 2:08 PM To: mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > I agree. It is also not clear on "mobile has not arrived". Has the mobile been > authenticated by the new AR? If not, how the new AR can receive packets for > un-authenticated mobile. We need to check security issues here. F-BU authenticates MN to oldAR. HI authenticates oldAR to newAR. If you are asking "how can newAR trust MN and release the buffers", that's outside the scope of this draft. Even without buffering, some other node on the same link can steal your traffic by overwriting neighbor cache of the AR. alper > > Barani. > > > > > James Kempf on 06/07/2001 09:41:22 AM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: James Kempf > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > >Can you add the following text to the draft then? > > > > When the newAR is receiving packets forwarded by the > > oldAR for the MN, and the MN hasnt shown up yet, the > > newAR SHOULD buffer packets. If the newAR does not > > buffer packets, it would the packets meant for the MN. > > > > I don't think this text should be added. > > It is entirely unclear at this point whether buffering will work without causing > user-perceivable artifacts in real time streams. In fact, I know of > at least one experiment with buffering (in IPv4) that showed it cannot be done. > This experiment was not definitive, of course, but I think it is > not wise to write buffering into the standard until more is known > about whether it will work or not. > > There are other alternatives to handoff smoothing, for example bicasting, > that could handle some portion of the handoff smoothing task without > introducing artifacts. We need to leave the standard open on this > until there is more evidence. > > jak > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 15:51:04 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19882 for ; Fri, 8 Jun 2001 15:51:03 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12166; Fri, 8 Jun 2001 12:49:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19196; Fri, 8 Jun 2001 12:44:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58JfqI06066 for mobile-ip-dist; Fri, 8 Jun 2001 12:41:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58Jfme06055 for ; Fri, 8 Jun 2001 12:41:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09481 for ; Fri, 8 Jun 2001 12:41:53 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25197 for ; Fri, 8 Jun 2001 13:41:51 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA12547 for ; Fri, 8 Jun 2001 12:41:51 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA06621 for ; Fri, 8 Jun 2001 12:41:51 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 14:41:51 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C8E@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 14:41:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Don't know why this one didn't make it to the list? Send it again. -----Original Message----- From: Nakhjiri Madjid-MNAKHJI1 Sent: Friday, June 08, 2001 1:53 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Hi Alper, Thanks for the email. See my comments below: -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Wednesday, June 06, 2001 2:10 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Hi Madjid, > Q1-Neighbor advertisement and L2 connectivity > It says in the draft (page 5) that the newAR will deliver packets to the mobile > when it receive indication from access network or NA from Mobile. > In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 connectivity > trigger. Could there be a race condition where newAR can start delivering packets > (based on L2 indication) before receiving an NA from MN? if not why is the text > written that way? I don't see a problem even when newAR detects arrival of MN, and at the same time MN sends a F-NA to newAR. Do you see a problem? MN>> I am not sure when the MN "gets ready" to receive package, right after L2 connectivity or after its done sending F-NA or NA. Also I am guessing that L2 indication comes from an AP (if AP and AR are not collocated) to both AR and MN. So newAR and MN can possibly get their indications at different times (wireless/ wired link bandwidth and error characteristics are different).So it could happen that newAR starts delivering packets, while MN is not ready. Maybe, I am stretching it but this is how the current text reads. > > Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR > receives a BU from MN or an F-BU + HACk. > The newAR delivers the packets to the MN as soon as it receives an NA or > F-NA from the MN (apart from Q1 above). > This means that during this time the MN's packets must be buffered at > newAR (whether it helps real time traffic or not, is another issue). > There was also a discussion about buffering at oldAR or at newAR, but > I think what I missed on the discussion was that > " is buffering at newAR supported or is it left to implementers, > (Should/ MUST/ May question?)" We have a 'U' Buffer Flag in HA message. And I think this makes it an optional feature. oldAR MAY turn this flag on. Do you think we should spell this out in the draft? MN>>Sorry, I am not sure what you mean by HA message and U flag, could you please lead me to the place in the draft? > > > 3- This question was asked on the list, I am not sure if I saw a convincing > answer other than comparing F-BU with BU. > The MN cannot use its newCoA as source address until it has received > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > Isn't this a chicken and egg problem? What am I missing? > Also what about ingress filtering issue at oldAR? > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA as the source address, and include a alternate CoA suboption. (I'm not sure if this is already stated in the draft. If not, we should add this.) MN>> That is acceptable, but as it is stated in the draft (page 2) "The mobile node sends a Fast Binding Update using its newly formed COA as the last message before it executes the handover." is a bit ambiguous. BR, Madjid From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 16:55:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20525 for ; Fri, 8 Jun 2001 16:55:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23418; Fri, 8 Jun 2001 14:53:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17789; Fri, 8 Jun 2001 11:53:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58IqjN05528 for mobile-ip-dist; Fri, 8 Jun 2001 11:52:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58Iqfe05521 for ; Fri, 8 Jun 2001 11:52:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17677 for ; Fri, 8 Jun 2001 11:52:46 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11923 for ; Fri, 8 Jun 2001 12:52:45 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA23857 for ; Fri, 8 Jun 2001 11:52:45 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA16942 for ; Fri, 8 Jun 2001 11:52:44 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Jun 2001 13:52:44 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B1B7C8A@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 8 Jun 2001 13:52:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Alper, Thanks for the email. See my comments below: -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Wednesday, June 06, 2001 2:10 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Hi Madjid, > Q1-Neighbor advertisement and L2 connectivity > It says in the draft (page 5) that the newAR will deliver packets to the mobile > when it receive indication from access network or NA from Mobile. > In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 connectivity > trigger. Could there be a race condition where newAR can start delivering packets > (based on L2 indication) before receiving an NA from MN? if not why is the text > written that way? I don't see a problem even when newAR detects arrival of MN, and at the same time MN sends a F-NA to newAR. Do you see a problem? MN>> I am not sure when the MN "gets ready" to receive package, right after L2 connectivity or after its done sending F-NA or NA. Also I am guessing that L2 indication comes from an AP (if AP and AR are not collocated) to both AR and MN. So newAR and MN can possibly get their indications at different times (wireless/ wired link bandwidth and error characteristics are different).So it could happen that newAR starts delivering packets, while MN is not ready. Maybe, I am stretching it but this is how the current text reads. > > Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR > receives a BU from MN or an F-BU + HACk. > The newAR delivers the packets to the MN as soon as it receives an NA or > F-NA from the MN (apart from Q1 above). > This means that during this time the MN's packets must be buffered at > newAR (whether it helps real time traffic or not, is another issue). > There was also a discussion about buffering at oldAR or at newAR, but > I think what I missed on the discussion was that > " is buffering at newAR supported or is it left to implementers, > (Should/ MUST/ May question?)" We have a 'U' Buffer Flag in HA message. And I think this makes it an optional feature. oldAR MAY turn this flag on. Do you think we should spell this out in the draft? MN>>Sorry, I am not sure what you mean by HA message and U flag, could you please lead me to the place in the draft? > > > 3- This question was asked on the list, I am not sure if I saw a convincing > answer other than comparing F-BU with BU. > The MN cannot use its newCoA as source address until it has received > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > Isn't this a chicken and egg problem? What am I missing? > Also what about ingress filtering issue at oldAR? > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA as the source address, and include a alternate CoA suboption. (I'm not sure if this is already stated in the draft. If not, we should add this.) MN>> That is acceptable, but as it is stated in the draft (page 2) "The mobile node sends a Fast Binding Update using its newly formed COA as the last message before it executes the handover." is a bit ambiguous. BR, Madjid From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 17:13:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20683 for ; Fri, 8 Jun 2001 17:13:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20374; Fri, 8 Jun 2001 14:12:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17736; Fri, 8 Jun 2001 14:12:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58LBOI06213 for mobile-ip-dist; Fri, 8 Jun 2001 14:11:24 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58LBLe06206 for ; Fri, 8 Jun 2001 14:11:21 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA01308 for ; Fri, 8 Jun 2001 14:11:28 -0700 (PDT) Message-Id: <200106082111.OAA01308@heliopolis.eng.sun.com> Date: Fri, 8 Jun 2001 14:11:28 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ibZ1+0x4kSf5GH+wxb6Eag== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, Bicasting is needed for ping-ponging. jak >Date: Fri, 8 Jun 2001 12:01:27 -0700 (PDT) >From: Alper Yegin >Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 >To: mobile-ip@sunroof.eng.sun.com >Content-MD5: 5aiUiiWadtM0RBnOD58dtA== > >> > Actually, I think a combination of bicasting and buffering may be >> > the best solution, together with an L2 trigger that tells the AR >> > when the L2 handover has started. The trick is to keep the buffering >> > restricted to the time in which the L2 link to the mobile >> > is well and truely gone. Otherwise, you run the risk of introducing >> > artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) is >> > probably a better solution in the end. >> > >> => This would be the best way of handling the smoothing >> of the handover. I fully agree with that. > >If the L2 trigger mentioned above is the capability on the AR to say "MN has >detached" or "MN has attached", then I don't see why we would also need >bi-casting. This L2 feature itself is sufficient to direct the traffic either >towards the current link on oldAR (MN is still attached), or towards the newAR >(as soon as MN detaches). > >I don't think we need bi-casting if we have this L2 feature. > >alper > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 17:18:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20740 for ; Fri, 8 Jun 2001 17:18:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11990; Fri, 8 Jun 2001 15:16:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18826; Fri, 8 Jun 2001 14:16:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58LElY06255 for mobile-ip-dist; Fri, 8 Jun 2001 14:14:47 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58LEie06248 for ; Fri, 8 Jun 2001 14:14:44 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA01376 for ; Fri, 8 Jun 2001 14:14:52 -0700 (PDT) Message-Id: <200106082114.OAA01376@heliopolis.eng.sun.com> Date: Fri, 8 Jun 2001 14:14:52 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: nVcAC9PFOSojTSrv4AS48g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >I can understand if the draft does not want to mandate or recommend >buffering, specifically for real time application, where buffering a >lot of data does not solve user problems. >However, it was not clear to me what drafts' position on buffering is, >specially since one of its prime goals is reducing latency for real time >application: > >Is buffering optional (when buffering helps, says 1-2 voice packets) >supported, not supported? >Does the draft provide guidelines or talk about tradeoffs? I think >buffering is an important issues. > If the authors want to talk about handoff smoothing, then they should. But they need to consider bicasting too. As it is, the draft says nothing about smoothing, and, as Charlie mentioned, the plan is for that to be in another draft. jak >Regards, >Madjid > >-----Original Message----- >From: James Kempf [mailto:James.Kempf@Sun.COM] >Sent: Thursday, June 07, 2001 11:41 AM >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > >>Can you add the following text to the draft then? >> >> When the newAR is receiving packets forwarded by the >> oldAR for the MN, and the MN hasnt shown up yet, the >> newAR SHOULD buffer packets. If the newAR does not >> buffer packets, it would the packets meant for the MN. >> > >I don't think this text should be added. > >It is entirely unclear at this point whether buffering will work without >causing >user-perceivable artifacts in real time streams. In fact, I know of >at least one experiment with buffering (in IPv4) that showed it cannot be >done. >This experiment was not definitive, of course, but I think it is >not wise to write buffering into the standard until more is known >about whether it will work or not. > >There are other alternatives to handoff smoothing, for example bicasting, >that could handle some portion of the handoff smoothing task without >introducing artifacts. We need to leave the standard open on this >until there is more evidence. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 19:09:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21553 for ; Fri, 8 Jun 2001 19:09:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06270; Fri, 8 Jun 2001 16:07:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12958; Fri, 8 Jun 2001 16:06:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58N5eh06468 for mobile-ip-dist; Fri, 8 Jun 2001 16:05:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58N5be06461 for ; Fri, 8 Jun 2001 16:05:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00074 for ; Fri, 8 Jun 2001 16:05:43 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22890 for ; Fri, 8 Jun 2001 16:05:43 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA03386 for ; Fri, 8 Jun 2001 16:05:42 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58N5fb04483 for ; Fri, 8 Jun 2001 16:05:41 -0700 X-mProtect: Fri, 8 Jun 2001 16:05:41 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHMDSbb; Fri, 08 Jun 2001 16:05:40 PDT Message-ID: <3B215A45.716EA1CE@iprg.nokia.com> Date: Fri, 08 Jun 2001 16:05:41 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <88256A65.0068000D.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Barani_Subbiah@3com.com wrote: > > >>> There is both logical and physical way of looking whether a mobile has > arrived. Old AR can inform the new AR that a mobile has logically handed over > ("arrived") this is already there. this is the HI message > so that the new AR can accept the packets before any physical > identification of the mobile with new AR. the whole discussion was about whether you should buffer such packets which come before the MN physically attaches to the newAR. what are you trying to say? this is what we have been discussing. > Do not assume too much. I see that your proposing a solution with out looking at > other possibilities or issues. ????? > > authentication is after that. you dont do authentication before > establishing a link level connection and sending a NA. > > >> I was asking about how the new AR is authorised to receive the packets for > the new mobile node before mobile is physically attached. One way is that old AR > informs new AR and new AR can get an authentication for mobile from network > before it arrives. This would allow the new AR to receive the packets with out > any security problems. We are talking about buffering packets not just receive > and discard. here the text i sent in another mail. it should answer your question. in the mobile controlled handoff case, its the MN which says i want to move to this particular AR. so here there is no question of authorization of the newAR to receive MN's packets. in the network controlled handover, its again some network entity which decides that this particular MN should be handed over to this AR. there is no question of authorization of the newAR in this case either. the newAR also receives a HI from the oldAR protected by an authentication header. the oldAR receives a HAck from the newAR protected by an authentication header. vijay > > and the fast handoff draft is not trying to solve authentication > between the MN and the access router. > > >> yes, however it should not create any holes either. > > vijay > > > authenticated by the new AR? If not, how the new AR can receive packets for > > un-authenticated mobile. We need to check security issues here. > > > > Barani. > > > > James Kempf on 06/07/2001 09:41:22 AM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: James Kempf > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > >Can you add the following text to the draft then? > > > > > > When the newAR is receiving packets forwarded by the > > > oldAR for the MN, and the MN hasnt shown up yet, the > > > newAR SHOULD buffer packets. If the newAR does not > > > buffer packets, it would the packets meant for the MN. > > > > > > > I don't think this text should be added. > > > > It is entirely unclear at this point whether buffering will work without > causing > > user-perceivable artifacts in real time streams. In fact, I know of > > at least one experiment with buffering (in IPv4) that showed it cannot be > done. > > This experiment was not definitive, of course, but I think it is > > not wise to write buffering into the standard until more is known > > about whether it will work or not. > > > > There are other alternatives to handoff smoothing, for example bicasting, > > that could handle some portion of the handoff smoothing task without > > introducing artifacts. We need to leave the standard open on this > > until there is more evidence. > > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 19:12:30 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21576 for ; Fri, 8 Jun 2001 19:12:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA05513; Fri, 8 Jun 2001 16:05:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12625; Fri, 8 Jun 2001 16:05:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58N4Xi06447 for mobile-ip-dist; Fri, 8 Jun 2001 16:04:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58N4Ue06440 for ; Fri, 8 Jun 2001 16:04:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12324 for ; Fri, 8 Jun 2001 16:04:36 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22321 for ; Fri, 8 Jun 2001 16:04:34 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA03277 for ; Fri, 8 Jun 2001 16:04:33 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58N4X402139 for ; Fri, 8 Jun 2001 16:04:33 -0700 X-mProtect: Fri, 8 Jun 2001 16:04:33 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdOsOLVF; Fri, 08 Jun 2001 16:04:31 PDT Message-ID: <3B2159FF.CC63E336@iprg.nokia.com> Date: Fri, 08 Jun 2001 16:04:31 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] authentication and authorization ( was questions on fast handoffs for MIPv6) References: <35DBB8B7AC89D4118E98009027B1009B1B7C8D@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Nakhjiri Madjid-MNAKHJI1 wrote: > > Alper, > > Hate to bring security issues in here, since this was about buffering > but, you brought it up :) Sorry. > > 1-Why does MN need to authenticate itself to oldAR, while it > is saying "goodbye" to it. It has been receiving service from > oldAR so far, hasn't it? > what Alper meant was the F-BU needs to have an authentication header. this authentication header would make use of the existing security association between the MN and the oldAR. > 2-authentication of oldAR to newAR does not solve all the > security problems, what about > authentication of newAR to oldAR, what about authorization of > newAR to receive MN's packets? > oldAR and newAR share a pair of security associations which protect the HI and HAck. the HAck has to come back before the oldAR starts forwarding the packets meant for the MN to the newAR. in the mobile controlled handoff case, its the MN which says i want to move to this particular AR. so here there is no question of authorization of the newAR to receive MN's packets. in the network controlled handover, its again some network entity which decides that this particular MN should be handed over to this AR. there is no question of authorization of the newAR in this case either. Barani, this answers your question too. Vijay > Madjid > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] > Sent: Friday, June 08, 2001 2:08 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > I agree. It is also not clear on "mobile has not arrived". Has the mobile > been > > authenticated by the new AR? If not, how the new AR can receive packets > for > > un-authenticated mobile. We need to check security issues here. > > F-BU authenticates MN to oldAR. > HI authenticates oldAR to newAR. > > If you are asking "how can newAR trust MN and release the buffers", that's > outside the scope of this draft. Even without buffering, some other node on > the > same link can steal your traffic by overwriting neighbor cache of the AR. > > alper > > > > > Barani. > > > > > > > > > > James Kempf on 06/07/2001 09:41:22 AM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: James Kempf > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > >Can you add the following text to the draft then? > > > > > > When the newAR is receiving packets forwarded by the > > > oldAR for the MN, and the MN hasnt shown up yet, the > > > newAR SHOULD buffer packets. If the newAR does not > > > buffer packets, it would the packets meant for the MN. > > > > > > > I don't think this text should be added. > > > > It is entirely unclear at this point whether buffering will work without > causing > > user-perceivable artifacts in real time streams. In fact, I know of > > at least one experiment with buffering (in IPv4) that showed it cannot be > done. > > This experiment was not definitive, of course, but I think it is > > not wise to write buffering into the standard until more is known > > about whether it will work or not. > > > > There are other alternatives to handoff smoothing, for example bicasting, > > that could handle some portion of the handoff smoothing task without > > introducing artifacts. We need to leave the standard open on this > > until there is more evidence. > > > > jak > > > > > > > > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 19:18:28 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21627 for ; Fri, 8 Jun 2001 19:18:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09874; Fri, 8 Jun 2001 16:18:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15448; Fri, 8 Jun 2001 16:18:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58NHCo06556 for mobile-ip-dist; Fri, 8 Jun 2001 16:17:12 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58NH9e06549 for ; Fri, 8 Jun 2001 16:17:09 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f58NHBQ793821; Fri, 8 Jun 2001 16:17:11 -0700 (PDT) Message-Id: <200106082317.f58NHBQ793821@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 16:17:13 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com Cc: G.Tsirtsis@flarion.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: J0BbB8VsPXhpNk8uAkn3Sg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Madjid, > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] > Sent: Wednesday, June 06, 2001 2:10 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > Hi Madjid, > > > Q1-Neighbor advertisement and L2 connectivity > > It says in the draft (page 5) that the newAR will deliver packets to the > mobile > > when it receive indication from access network or NA from Mobile. > > In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 > connectivity > > trigger. Could there be a race condition where newAR can start delivering > packets > > (based on L2 indication) before receiving an NA from MN? if not why is the > text > > written that way? > > I don't see a problem even when newAR detects arrival of MN, and at the same > time MN sends a F-NA to newAR. Do you see a problem? > > MN>> I am not sure when the MN "gets ready" to receive package, right after > L2 connectivity or after its done sending F-NA or NA. Also I am guessing Abstractly speaking, L2 connected MN is ready to receive packets (as long as sender knows where to send). > that L2 indication comes from an AP (if AP and AR are not collocated) > to both AR and MN. So newAR and MN can possibly get their indications > at different times (wireless/ wired link bandwidth and error characteristics > are different).So it could happen that newAR starts delivering packets, while > MN is not ready. Maybe, I am stretching it but this is how the current text reads. > I'm not sure about this example. It sounds like data packets from AR are ahead of L2 attachment indication to MN. This didn't make sense to me. > > > > > Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR > > receives a BU from MN or an F-BU + HACk. > > The newAR delivers the packets to the MN as soon as it receives an NA or > > F-NA from the MN (apart from Q1 above). > > This means that during this time the MN's packets must be buffered at > > newAR (whether it helps real time traffic or not, is another issue). > > There was also a discussion about buffering at oldAR or at newAR, but > > I think what I missed on the discussion was that > > " is buffering at newAR supported or is it left to implementers, > > (Should/ MUST/ May question?)" > > We have a 'U' Buffer Flag in HA message. And I think this makes it an optional > feature. oldAR MAY turn this flag on. Do you think we should spell this out in > the draft? > > MN>>Sorry, I am not sure what you mean by HA message and U flag, could you please > lead me to the place in the draft? Sorry. I meant "HI" message. > > > > > > > 3- This question was asked on the list, I am not sure if I saw a convincing > > answer other than comparing F-BU with BU. > > The MN cannot use its newCoA as source address until it has received > > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > > Isn't this a chicken and egg problem? What am I missing? > > Also what about ingress filtering issue at oldAR? > > > > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA > as the source address, and include a alternate CoA suboption. (I'm not sure if > this is already stated in the draft. If not, we should add this.) > > MN>> That is acceptable, but as it is stated in the draft (page 2) > > "The mobile node sends a Fast Binding Update using its newly formed > COA as the last message before it executes the handover." > > is a bit ambiguous. Thanks for this catch. We should make this clear in the draft. > > BR, > Madjid alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 19:24:02 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21692 for ; Fri, 8 Jun 2001 19:24:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15233; Fri, 8 Jun 2001 17:22:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16272; Fri, 8 Jun 2001 16:22:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58NLNY06597 for mobile-ip-dist; Fri, 8 Jun 2001 16:21:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58NLJe06590 for ; Fri, 8 Jun 2001 16:21:19 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f58NLOQ794798 for ; Fri, 8 Jun 2001 16:21:24 -0700 (PDT) Message-Id: <200106082321.f58NLOQ794798@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 16:21:26 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: huQKaa8jrx2uPFXa8UNRUg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Madjid, > > Alper, > > Hate to bring security issues in here, since this was about buffering > but, you brought it up :) Sorry. > > 1-Why does MN need to authenticate itself to oldAR, while it > is saying "goodbye" to it. It has been receiving service from > oldAR so far, hasn't it? This is the standard Binding Update authentication. Nothing new. > > 2-authentication of oldAR to newAR does not solve all the > security problems, what about > authentication of newAR to oldAR, what about authorization of > newAR to receive MN's packets? > Both HI and HACK are authenticated, therefore oldAR is authenticated to newAR, and vice-versa. > > > Madjid alper > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] > Sent: Friday, June 08, 2001 2:08 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > I agree. It is also not clear on "mobile has not arrived". Has the mobile > been > > authenticated by the new AR? If not, how the new AR can receive packets > for > > un-authenticated mobile. We need to check security issues here. > > > F-BU authenticates MN to oldAR. > HI authenticates oldAR to newAR. > > If you are asking "how can newAR trust MN and release the buffers", that's > outside the scope of this draft. Even without buffering, some other node on > the > same link can steal your traffic by overwriting neighbor cache of the AR. > > alper > > > > > > > Barani. > > > > > > > > > > James Kempf on 06/07/2001 09:41:22 AM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: James Kempf > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > >Can you add the following text to the draft then? > > > > > > When the newAR is receiving packets forwarded by the > > > oldAR for the MN, and the MN hasnt shown up yet, the > > > newAR SHOULD buffer packets. If the newAR does not > > > buffer packets, it would the packets meant for the MN. > > > > > > > I don't think this text should be added. > > > > It is entirely unclear at this point whether buffering will work without > causing > > user-perceivable artifacts in real time streams. In fact, I know of > > at least one experiment with buffering (in IPv4) that showed it cannot be > done. > > This experiment was not definitive, of course, but I think it is > > not wise to write buffering into the standard until more is known > > about whether it will work or not. > > > > There are other alternatives to handoff smoothing, for example bicasting, > > that could handle some portion of the handoff smoothing task without > > introducing artifacts. We need to leave the standard open on this > > until there is more evidence. > > > > jak > > > > > > > > > > > > alper alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 19:26:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21723 for ; Fri, 8 Jun 2001 19:26:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17552; Fri, 8 Jun 2001 17:25:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16883; Fri, 8 Jun 2001 16:25:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58NOr306643 for mobile-ip-dist; Fri, 8 Jun 2001 16:24:53 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58NOoe06636 for ; Fri, 8 Jun 2001 16:24:50 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f58NOsQ795413 for ; Fri, 8 Jun 2001 16:24:54 -0700 (PDT) Message-Id: <200106082324.f58NOsQ795413@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 16:24:56 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: klM1OHGeg0Iyp6cMxmo7nA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > > Alper, > > Bicasting is needed for ping-ponging. > > jak Even for ping-ponging, if oldAR can detect that MN is back (ponged :), then it can start forwarding traffic through its link. If MN pings again (gone to new link), the oldAR can detect this and start tunneling to newCoA. Therefore this L2 feature can be used to handle ping-ponging without requiring bi-casting. alper > > > >Date: Fri, 8 Jun 2001 12:01:27 -0700 (PDT) > >From: Alper Yegin > >Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > >To: mobile-ip@sunroof.eng.sun.com > >Content-MD5: 5aiUiiWadtM0RBnOD58dtA== > > > >> > Actually, I think a combination of bicasting and buffering may be > >> > the best solution, together with an L2 trigger that tells the AR > >> > when the L2 handover has started. The trick is to keep the buffering > >> > restricted to the time in which the L2 link to the mobile > >> > is well and truely gone. Otherwise, you run the risk of introducing > >> > artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) > is > >> > probably a better solution in the end. > >> > > >> => This would be the best way of handling the smoothing > >> of the handover. I fully agree with that. > > > >If the L2 trigger mentioned above is the capability on the AR to say "MN has > >detached" or "MN has attached", then I don't see why we would also need > >bi-casting. This L2 feature itself is sufficient to direct the traffic either > >towards the current link on oldAR (MN is still attached), or towards the newAR > >(as soon as MN detaches). > > > >I don't think we need bi-casting if we have this L2 feature. > > > >alper > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 19:36:39 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21798 for ; Fri, 8 Jun 2001 19:36:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15825; Fri, 8 Jun 2001 16:36:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18662; Fri, 8 Jun 2001 16:36:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58NZRm06700 for mobile-ip-dist; Fri, 8 Jun 2001 16:35:27 -0700 (PDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58NZOe06693 for ; Fri, 8 Jun 2001 16:35:24 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA05306 for ; Fri, 8 Jun 2001 16:35:31 -0700 (PDT) Message-Id: <200106082335.QAA05306@heliopolis.eng.sun.com> Date: Fri, 8 Jun 2001 16:35:30 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7f7tS9gUxhED572Xau3D1g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, >Even for ping-ponging, if oldAR can detect that MN is back (ponged :), then it >can start forwarding traffic through its link. > >If MN pings again (gone to new link), the oldAR can detect this and start >tunneling to newCoA. > >Therefore this L2 feature can be used to handle ping-ponging without requiring >bi-casting. > Sure, it's possible to switch the L3 back and forth, but coupling that with L3 buffering gets complicated. Suppose newAR is buffering. When the MN pongs, how does it pick up the buffered packets? jak From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 8 20:01:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22112 for ; Fri, 8 Jun 2001 20:01:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09042; Fri, 8 Jun 2001 18:01:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00995; Fri, 8 Jun 2001 17:01:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5900Td06766 for mobile-ip-dist; Fri, 8 Jun 2001 17:00:29 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5900Qe06759 for ; Fri, 8 Jun 2001 17:00:26 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5900VQ802419 for ; Fri, 8 Jun 2001 17:00:31 -0700 (PDT) Message-Id: <200106090000.f5900VQ802419@jurassic.eng.sun.com> Date: Fri, 8 Jun 2001 17:00:33 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YWY4TvQAzQacKHeVGxT7tw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > Alper, > > >Even for ping-ponging, if oldAR can detect that MN is back (ponged :), then it > >can start forwarding traffic through its link. > > > >If MN pings again (gone to new link), the oldAR can detect this and start > >tunneling to newCoA. > > > >Therefore this L2 feature can be used to handle ping-ponging without requiring > >bi-casting. > > > > Sure, it's possible to switch the L3 back and forth, but coupling > that with L3 buffering gets complicated. Suppose newAR is buffering. > When the MN pongs, how does it pick up the buffered packets? I am just saying, in the existence of this L2 feature, we don't need bi-casting. So, we don't need "this L2 feature + bi-casting", "this L2 feature" does the job. I don't know where the buffering gets involved here. alper From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 10 16:45:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13655 for ; Sun, 10 Jun 2001 16:45:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14065; Sun, 10 Jun 2001 13:45:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07915; Sun, 10 Jun 2001 13:45:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AKihWi009263 for ; Sun, 10 Jun 2001 13:44:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AKihXb009262 for mobile-ip-dist; Sun, 10 Jun 2001 13:44:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AKieWi009255 for ; Sun, 10 Jun 2001 13:44:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27387 for ; Sun, 10 Jun 2001 13:44:47 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13343 for ; Sun, 10 Jun 2001 14:45:21 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5AKiiN24107 for ; Sun, 10 Jun 2001 22:44:44 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Jun 10 22:44:43 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Jun 2001 22:44:43 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEFF@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Sun, 10 Jun 2001 22:44:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper > > > Actually, I think a combination of bicasting and buffering may be > > > the best solution, together with an L2 trigger that tells the AR > > > when the L2 handover has started. The trick is to keep the buffering > > > restricted to the time in which the L2 link to the mobile > > > is well and truely gone. Otherwise, you run the risk of introducing > > > artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) is > > > probably a better solution in the end. > > > > > => This would be the best way of handling the smoothing > > of the handover. I fully agree with that. > > If the L2 trigger mentioned above is the capability on the AR to say "MN has > detached" or "MN has attached", then I don't see why we would also need > bi-casting. This L2 feature itself is sufficient to direct the traffic either > towards the current link on oldAR (MN is still attached), or towards the newAR > (as soon as MN detaches). > > I don't think we need bi-casting if we have this L2 feature. > => And what if we don't ? Even if we do, I don'tthink we need such level of complexity to determine whether a packet should be forwarded or not on the IP layer. Most decent routers implement fowarding in HW, we don't want to modify HW to implement a Fast Handoff mechanism. If the capability you're talking about exists in some cases then the packets will be dropped on L2 layer anyway since there is no one to send it to. Hesham From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 10 17:06:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13812 for ; Sun, 10 Jun 2001 17:06:24 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17953; Sun, 10 Jun 2001 14:06:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28464; Sun, 10 Jun 2001 14:06:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AL5TWi009313 for ; Sun, 10 Jun 2001 14:05:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AL5Slh009312 for mobile-ip-dist; Sun, 10 Jun 2001 14:05:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AL5PWi009305 for ; Sun, 10 Jun 2001 14:05:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11339 for ; Sun, 10 Jun 2001 14:05:33 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00181 for ; Sun, 10 Jun 2001 15:05:30 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5AL5TO01911 for ; Sun, 10 Jun 2001 23:05:29 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Sun Jun 10 23:05:13 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Jun 2001 23:05:28 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF00@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Sun, 10 Jun 2001 23:05:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > > >Even for ping-ponging, if oldAR can detect that MN is back (ponged :), then > it > > >can start forwarding traffic through its link. > > > > > >If MN pings again (gone to new link), the oldAR can detect this and start > > >tunneling to newCoA. > > > > > >Therefore this L2 feature can be used to handle ping-ponging without > requiring > > >bi-casting. > > > > > > > Sure, it's possible to switch the L3 back and forth, but coupling > > that with L3 buffering gets complicated. Suppose newAR is buffering. > > When the MN pongs, how does it pick up the buffered packets? > > I am just saying, in the existence of this L2 feature, we don't need bi-casting. > So, we don't need "this L2 feature + bi-casting", "this L2 feature" does the > job. > => Further to my last mail, I don't think you could really convince router designers to implement this when there is another L2 independant mechanism for forwarding packets (bicasting). BTW, while we're on the topic, Karim and I will issue a draft shortly on this. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 13:25:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15331 for ; Mon, 11 Jun 2001 13:25:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21370; Mon, 11 Jun 2001 10:25:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28807; Mon, 11 Jun 2001 10:25:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BHOTWi010206 for ; Mon, 11 Jun 2001 10:24:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BHOTSk010205 for mobile-ip-dist; Mon, 11 Jun 2001 10:24:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BHOQWi010198 for ; Mon, 11 Jun 2001 10:24:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12490 for ; Mon, 11 Jun 2001 10:24:33 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29612 for ; Mon, 11 Jun 2001 11:25:12 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5BHMY309875 for ; Mon, 11 Jun 2001 10:22:34 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5BHOVI01982 for ; Mon, 11 Jun 2001 10:24:31 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A68.005F9B98 ; Mon, 11 Jun 2001 10:24:17 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A68.005F999A.00@hqoutbound.ops.3com.com> Date: Mon, 11 Jun 2001 10:24:36 -0700 Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: snip for clarity... =================== here the text i sent in another mail. it should answer your question. in the mobile controlled handoff case, its the MN which says i want to move to this particular AR. >> How does the MN informs this to Old AR when the MN has not "arrived" or not connected or not exhanged any packets with the new AR? so here there is no question of authorization of the newAR to receive MN's packets. >> New AR has to authenticate the MN before it can store packets for the MN. If not, it will opne many issues. in the network controlled handover, its again some network entity >> can you point out which entity? or Are we going to leave this out of this draft. which decides that this particular MN should be handed over to this AR. there is no question of authorization of the newAR in this case either. the newAR also receives a HI from the oldAR protected by an authentication header. the oldAR receives a HAck from the newAR protected by an authentication header. >> I am not interested to reopen the fast handoff and buffering. My concern is, the scenario where we allow the new AR to buffer packets before the mobile can attach itself to new AR. 1. Security issues as pointed out 2. Ping pong effect - when the mobile is not able to attach to new AR after Hi-HACK (between ARs). Either the mobile returns to old AR or selects a different AR. What happens to buffered packets at the anticipated new AR? 3. Timing issues - How long and how much buffer has to allocated, What happens if the MN has not attached itself with in the time limit. Eventhough above issues have been raised earlier, I like to see them resolved in this draft. for various reasons, IMHO even if buffering is good choice we should avoid buffering packets for un attached MNs. Barani. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 13:41:28 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15682 for ; Mon, 11 Jun 2001 13:41:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03885; Mon, 11 Jun 2001 11:41:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16504; Mon, 11 Jun 2001 10:41:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BHe8Wi010246 for ; Mon, 11 Jun 2001 10:40:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BHe8uo010245 for mobile-ip-dist; Mon, 11 Jun 2001 10:40:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BHe4Wi010238 for ; Mon, 11 Jun 2001 10:40:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08350 for ; Mon, 11 Jun 2001 10:40:12 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02658 for ; Mon, 11 Jun 2001 11:40:10 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5BHe8N06081 for ; Mon, 11 Jun 2001 19:40:08 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Jun 11 19:40:06 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 19:40:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF0C@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Mon, 11 Jun 2001 19:39:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barani, Your authorisation questions (at the new AR) are orthogonal to this draft. This is what Alper said earlier. Authorisation (to get access to the Internet) is needed even without mobility. See comments below. > here the text i sent in another mail. it should answer your question. > > in the mobile controlled handoff case, its the MN which says > i want to move to this particular AR. > > >> How does the MN informs this to Old AR when the MN has not "arrived" or not > connected or not exhanged any packets with the new AR? > => Which part of the draft isn't clear ? The MN sends a BU to the old AR. > so here there is no > question of authorization of the newAR to receive MN's > packets. > > >> New AR has to authenticate the MN before it can store packets for the MN. If > not, it will opne many issues. > => Again this is orthogonal to the draft. This has to happen for any node connected to a router. > in the network controlled handover, its again some > network entity > > >> can you point out which entity? or Are we going to leave this out of this > draft. > => How about we read the draft :) It's the old AR. > which decides that this particular MN should > be handed over to this AR. there is no question of > authorization of the newAR in this case either. > > the newAR also receives a HI from the oldAR protected by > an authentication header. the oldAR receives a HAck from > the newAR protected by an authentication header. > > > >> I am not interested to reopen the fast handoff and buffering. My concern is, > the scenario where we allow the new AR to buffer packets before the > mobile can attach itself to new AR. > > 2. Ping pong effect - when the mobile is not able to attach to new AR after > Hi-HACK (between ARs). Either the mobile returns to old AR or selects a > different AR. What happens to buffered packets at the anticipated new AR? > => They get dropped. > 3. Timing issues - How long and how much buffer has to allocated, What > happens if the MN has not attached itself with in the time limit. > => This is system and implementation dependant. > for various reasons, IMHO even if buffering is good choice we should avoid > buffering packets for un attached MNs. > => RFC 2461 says that if the default router receives a packet addressed to a node on its link, it attempts to resolve the address several times. In the mean time packets are buffered. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 14:51:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16737 for ; Mon, 11 Jun 2001 14:51:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04748; Mon, 11 Jun 2001 12:51:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19492; Mon, 11 Jun 2001 11:51:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BIoGWi010326 for ; Mon, 11 Jun 2001 11:50:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BIoG6O010325 for mobile-ip-dist; Mon, 11 Jun 2001 11:50:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BIoCWi010318 for ; Mon, 11 Jun 2001 11:50:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19291 for ; Mon, 11 Jun 2001 11:50:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02993 for ; Mon, 11 Jun 2001 11:50:09 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA09730 for ; Mon, 11 Jun 2001 11:50:05 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5BIo4208059 for ; Mon, 11 Jun 2001 11:50:04 -0700 X-mProtect: Mon, 11 Jun 2001 11:50:04 -0700 Nokia Silicon Valley Messaging Protection Received: from nokdab005134.americas.nokia.com (172.18.5.134, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd7tMsER; Mon, 11 Jun 2001 11:49:48 PDT Message-ID: <3B2512C7.77D0929B@iprg.nokia.com> Date: Mon, 11 Jun 2001 11:49:43 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <88256A68.005F999A.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I wish you would read the fast handoff draft again. it clearly says what the assumptions are and what the limitations are. the draft would answer all your questions. if you still have these questions after that, lets take them offline. Vijay Barani_Subbiah@3com.com wrote: > > snip for clarity... > =================== > > here the text i sent in another mail. it should answer your question. > > in the mobile controlled handoff case, its the MN which says > i want to move to this particular AR. > > >> How does the MN informs this to Old AR when the MN has not "arrived" or not > connected or not exhanged any packets with the new AR? > > so here there is no > question of authorization of the newAR to receive MN's > packets. > > >> New AR has to authenticate the MN before it can store packets for the MN. If > not, it will opne many issues. > > in the network controlled handover, its again some > network entity > > >> can you point out which entity? or Are we going to leave this out of this > draft. > > which decides that this particular MN should > be handed over to this AR. there is no question of > authorization of the newAR in this case either. > > the newAR also receives a HI from the oldAR protected by > an authentication header. the oldAR receives a HAck from > the newAR protected by an authentication header. > > >> I am not interested to reopen the fast handoff and buffering. My concern is, > the scenario where we allow the new AR to buffer packets before the > mobile can attach itself to new AR. > > 1. Security issues as pointed out > 2. Ping pong effect - when the mobile is not able to attach to new AR after > Hi-HACK (between ARs). Either the mobile returns to old AR or selects a > different AR. What happens to buffered packets at the anticipated new AR? > 3. Timing issues - How long and how much buffer has to allocated, What > happens if the MN has not attached itself with in the time limit. > > Eventhough above issues have been raised earlier, I like to see them > resolved in this draft. > > for various reasons, IMHO even if buffering is good choice we should avoid > buffering packets for un attached MNs. > > Barani. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 16:18:32 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18198 for ; Mon, 11 Jun 2001 16:18:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18377; Mon, 11 Jun 2001 13:18:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08950; Mon, 11 Jun 2001 13:18:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BKHqWi010512 for ; Mon, 11 Jun 2001 13:17:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BKHqWY010511 for mobile-ip-dist; Mon, 11 Jun 2001 13:17:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BKHmWi010504 for ; Mon, 11 Jun 2001 13:17:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21861 for ; Mon, 11 Jun 2001 13:17:55 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11170 for ; Mon, 11 Jun 2001 14:17:53 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA02802 for ; Mon, 11 Jun 2001 13:17:53 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA12855 for ; Mon, 11 Jun 2001 13:17:53 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 15:17:53 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D5F@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] authentication and authorization ( was questions on fast handoffs for MIPv6) Date: Mon, 11 Jun 2001 15:17:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Friday, June 08, 2001 6:05 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] authentication and authorization ( was questions on fast handoffs for MIPv6) Nakhjiri Madjid-MNAKHJI1 wrote: > > Alper, > > Hate to bring security issues in here, since this was about buffering > but, you brought it up :) Sorry. > > 1-Why does MN need to authenticate itself to oldAR, while it > is saying "goodbye" to it. It has been receiving service from > oldAR so far, hasn't it? > what Alper meant was the F-BU needs to have an authentication header. this authentication header would make use of the existing security association between the MN and the oldAR. MN>> Thanks Vijay, I thought about it right after I sent the email :) > 2-authentication of oldAR to newAR does not solve all the > security problems, what about > authentication of newAR to oldAR, what about authorization of > newAR to receive MN's packets? > oldAR and newAR share a pair of security associations which protect the HI and HAck. the HAck has to come back before the oldAR starts forwarding the packets meant for the MN to the newAR. MN>> Ok, If you have two SAs for mutual authentications, then that is better. in the mobile controlled handoff case, its the MN which says i want to move to this particular AR. so here there is no question of authorization of the newAR to receive MN's packets. in the network controlled handover, its again some network entity which decides that this particular MN should be handed over to this AR. there is no question of authorization of the newAR in this case either. MN>> Ok, assuming that authentication also means authorization, for network controlled HO it makes sense, if the two ARs are authenticated to each other. For mobile determined, I thought mobile only knows the layer 2 device and not AR (I guess you again mean that during HI/HACK the newAR proves to oldAR that it is authorized to get MN's packets) madjid Barani, this answers your question too. Vijay > Madjid > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] > Sent: Friday, June 08, 2001 2:08 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > I agree. It is also not clear on "mobile has not arrived". Has the mobile > been > > authenticated by the new AR? If not, how the new AR can receive packets > for > > un-authenticated mobile. We need to check security issues here. > > F-BU authenticates MN to oldAR. > HI authenticates oldAR to newAR. > > If you are asking "how can newAR trust MN and release the buffers", that's > outside the scope of this draft. Even without buffering, some other node on > the > same link can steal your traffic by overwriting neighbor cache of the AR. > > alper > > > > > Barani. > > > > > > > > > > James Kempf on 06/07/2001 09:41:22 AM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: James Kempf > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > >Can you add the following text to the draft then? > > > > > > When the newAR is receiving packets forwarded by the > > > oldAR for the MN, and the MN hasnt shown up yet, the > > > newAR SHOULD buffer packets. If the newAR does not > > > buffer packets, it would the packets meant for the MN. > > > > > > > I don't think this text should be added. > > > > It is entirely unclear at this point whether buffering will work without > causing > > user-perceivable artifacts in real time streams. In fact, I know of > > at least one experiment with buffering (in IPv4) that showed it cannot be > done. > > This experiment was not definitive, of course, but I think it is > > not wise to write buffering into the standard until more is known > > about whether it will work or not. > > > > There are other alternatives to handoff smoothing, for example bicasting, > > that could handle some portion of the handoff smoothing task without > > introducing artifacts. We need to leave the standard open on this > > until there is more evidence. > > > > jak > > > > > > > > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 16:24:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18338 for ; Mon, 11 Jun 2001 16:24:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15985; Mon, 11 Jun 2001 14:24:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10074; Mon, 11 Jun 2001 13:24:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BKNKWi010581 for ; Mon, 11 Jun 2001 13:23:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BKNKnk010580 for mobile-ip-dist; Mon, 11 Jun 2001 13:23:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BKNGWi010573 for ; Mon, 11 Jun 2001 13:23:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09932 for ; Mon, 11 Jun 2001 13:23:23 -0700 (PDT) Received: from hotmail.com (f33.law7.hotmail.com [216.33.237.33]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15290 for ; Mon, 11 Jun 2001 14:23:22 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Jun 2001 13:23:22 -0700 Received: from 63.78.179.5 by lw7fd.law7.hotmail.msn.com with HTTP; Mon, 11 Jun 2001 20:23:22 GMT X-Originating-IP: [63.78.179.5] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New Internet Draft Notification - QoS requirements for Mobile IP Date: Mon, 11 Jun 2001 20:23:22 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jun 2001 20:23:22.0866 (UTC) FILETIME=[5CA3FD20:01C0F2B4] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I am glad to notify that the discussions on the Mobile IP QoS requirements mailing list have now converged. I have compiled them in the form of a draft: "Requirements of a QoS solution for Mobile IP" draft-chaskar-mobileip-qos-requirements-00.txt Edited by Hemant Chaskar This draft now appears in the IETF I-D directory also. Please provide your comments on it. The idea behind this draft was to create an input document to NSIS working group that may be formed soon. It was made clear that the draft will not go into solution space, rather be focussed on the requirements aspects. Thanks. Hemant Chaskar Nokia _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 16:43:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18565 for ; Mon, 11 Jun 2001 16:43:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00503; Mon, 11 Jun 2001 14:43:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13966; Mon, 11 Jun 2001 13:43:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BKgMWi010657 for ; Mon, 11 Jun 2001 13:42:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BKgL7I010656 for mobile-ip-dist; Mon, 11 Jun 2001 13:42:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BKgHWi010649 for ; Mon, 11 Jun 2001 13:42:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26711 for ; Mon, 11 Jun 2001 13:42:24 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12824 for ; Mon, 11 Jun 2001 13:42:23 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA23397 for ; Mon, 11 Jun 2001 13:35:45 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA25838 for ; Mon, 11 Jun 2001 13:42:19 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Jun 2001 15:42:19 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D60@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Cc: G.Tsirtsis@flarion.com Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Mon, 11 Jun 2001 15:42:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, Thank you for your email. Please see my comments below (MN>>>>) -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Friday, June 08, 2001 6:17 PM To: mobile-ip@sunroof.eng.sun.com Cc: G.Tsirtsis@flarion.com Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Madjid, > > -----Original Message----- > From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] > Sent: Wednesday, June 06, 2001 2:10 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 > > > Hi Madjid, > > > Q1-Neighbor advertisement and L2 connectivity > > It says in the draft (page 5) that the newAR will deliver packets to the > mobile > > when it receive indication from access network or NA from Mobile. > > In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 > connectivity > > trigger. Could there be a race condition where newAR can start delivering > packets > > (based on L2 indication) before receiving an NA from MN? if not why is the > text > > written that way? > > I don't see a problem even when newAR detects arrival of MN, and at the same > time MN sends a F-NA to newAR. Do you see a problem? > > MN>> I am not sure when the MN "gets ready" to receive package, right after > L2 connectivity or after its done sending F-NA or NA. Also I am guessing Abstractly speaking, L2 connected MN is ready to receive packets (as long as sender knows where to send). MN>>>>Well, how does the sender know where to send the packets before receiving F-NA/NA from the mobile? > that L2 indication comes from an AP (if AP and AR are not collocated) > to both AR and MN. So newAR and MN can possibly get their indications > at different times (wireless/ wired link bandwidth and error characteristics > are different).So it could happen that newAR starts delivering packets, while > MN is not ready. Maybe, I am stretching it but this is how the current text reads. > I'm not sure about this example. It sounds like data packets from AR are ahead of L2 attachment indication to MN. This didn't make sense to me. MN>>>> to me neither. Tell me who sends L2 attachement to MN, AR or AP, if AR does then there would be no race condition (however, this would not be a general case, I think), but if AP does, then AP sends the signal to AR as well and there would be a time when one of AR and MN does not know about the L2 connectivity (I think MN would know later, but it is not certain) As you said earlier, newAR should deliver MN's packets when it knows that it has L2 connection for the mobile and it has MN's address and this happens when it has received F-NA from MN (MN sends F-NA after L2 connectivity) So the draft can mention the following as condition: (has received F-NA) or to be safer (received F-NA *AND* indication on L2 connectivity) NOT as it says in the draft (received NA *OR* L2 connectivity), otherwise the race condition might happen (as I said earlier: when L2 signal comes from an AP to AR and MN separately, instead of direct communication between MN and AR) > > > > > Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR > > receives a BU from MN or an F-BU + HACk. > > The newAR delivers the packets to the MN as soon as it receives an NA or > > F-NA from the MN (apart from Q1 above). > > This means that during this time the MN's packets must be buffered at > > newAR (whether it helps real time traffic or not, is another issue). > > There was also a discussion about buffering at oldAR or at newAR, but > > I think what I missed on the discussion was that > > " is buffering at newAR supported or is it left to implementers, > > (Should/ MUST/ May question?)" > > We have a 'U' Buffer Flag in HA message. And I think this makes it an optional > feature. oldAR MAY turn this flag on. Do you think we should spell this out in > the draft? > > MN>>Sorry, I am not sure what you mean by HA message and U flag, could you please > lead me to the place in the draft? Sorry. I meant "HI" message. MN>>>> Ok, thanks, I still has not found the U flag in the draft :(( Is it in the MIPv6 base draft? I did not see it there either? > > > > > > > 3- This question was asked on the list, I am not sure if I saw a convincing > > answer other than comparing F-BU with BU. > > The MN cannot use its newCoA as source address until it has received > > F-Back from oldAR. Then how does it use newCoA as source address in F-BU? > > Isn't this a chicken and egg problem? What am I missing? > > Also what about ingress filtering issue at oldAR? > > > > MN doesn't have to use newCoA as the source address of F-BU. It can use oldCoA > as the source address, and include a alternate CoA suboption. (I'm not sure if > this is already stated in the draft. If not, we should add this.) > > MN>> That is acceptable, but as it is stated in the draft (page 2) > > "The mobile node sends a Fast Binding Update using its newly formed > COA as the last message before it executes the handover." > > is a bit ambiguous. Thanks for this catch. We should make this clear in the draft. MN>>Thanks, I too feel better now :) Regards, Madjid From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 18:03:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19825 for ; Mon, 11 Jun 2001 18:03:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01980; Mon, 11 Jun 2001 16:03:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13926; Mon, 11 Jun 2001 15:03:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BM1uWi010782 for ; Mon, 11 Jun 2001 15:01:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BM1uBS010781 for mobile-ip-dist; Mon, 11 Jun 2001 15:01:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BM1rWi010774 for ; Mon, 11 Jun 2001 15:01:53 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5BM1rQ293174; Mon, 11 Jun 2001 15:01:53 -0700 (PDT) Message-Id: <200106112201.f5BM1rQ293174@jurassic.eng.sun.com> Date: Mon, 11 Jun 2001 15:01:58 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com Cc: G.Tsirtsis@flarion.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zOOaeU3umIzA2eiWQ25g6w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Madjid, > > Hi Madjid, > > > > > Q1-Neighbor advertisement and L2 connectivity > > > It says in the draft (page 5) that the newAR will deliver packets to the > > > mobile > > > when it receive indication from access network or NA from Mobile. > > > In page 1 it says MN sends NA or F-NA to newAR as soon as it receives L2 > > > connectivity > > > trigger. Could there be a race condition where newAR can start > delivering > > packets > > > (based on L2 indication) before receiving an NA from MN? if not why is > the > > text > > > written that way? > > > > I don't see a problem even when newAR detects arrival of MN, and at the > same > > time MN sends a F-NA to newAR. Do you see a problem? > > > > MN>> I am not sure when the MN "gets ready" to receive package, right > after > > L2 connectivity or after its done sending F-NA or NA. Also I am guessing > > Abstractly speaking, L2 connected MN is ready to receive packets (as long as > > sender knows where to send). > > MN>>>>Well, how does the sender know where to send the packets before > receiving > F-NA/NA from the mobile? L2 address of MN is sent in HI message from oldAR to newAR. As soon as MN attaches to new link, "if" newAR can detect this attachment and correlate this to MN, then newAR can start forwarding packets. Otherwise, newAR needs to wait for F-NA. "where to send" information is the L2 address of the mobile node, which was communicated in the HI message. > > > that L2 indication comes from an AP (if AP and AR are not collocated) > > to both AR and MN. So newAR and MN can possibly get their indications > > at different times (wireless/ wired link bandwidth and error > characteristics > > are different).So it could happen that newAR starts delivering packets, > while > > MN is not ready. Maybe, I am stretching it but this is how the current > text > reads. > > > > I'm not sure about this example. It sounds like data packets from AR are > ahead > of L2 attachment indication to MN. This didn't make sense to me. > > > MN>>>> to me neither. Tell me who sends L2 attachement to MN, > AR or AP, if AR does then there would be no race condition > (however, this would not be a general case, I think), but > if AP does, then AP sends the signal to AR as well and there > would be a time when one of AR and MN does not know about the > L2 connectivity (I think MN would know later, but it is not certain) So, what you are saying is this: there can be a case where AR thinks MN is L2 connected and starts sending packets, but MN is actually not L2 connected yet. This sounds like a L2 problem, that needs to be handled at L2. I think L2 folks should fix this :) > > As you said earlier, newAR should deliver MN's > packets when it knows that it has L2 connection for > the mobile and it has MN's address and this happens when it > has received F-NA from MN (MN sends F-NA after L2 connectivity) > So the draft can mention the following as condition: > (has received F-NA) > or to be safer > (received F-NA *AND* indication on L2 connectivity) Well, if newAR has received F-NA, who cares about L2. MN is clearly L2 connected if it were able to send this F-NA. > NOT as it says in the draft > (received NA *OR* L2 connectivity), > otherwise the race condition might happen (as I said earlier: > when L2 signal comes from an AP to AR and MN separately, instead of > direct communication between MN and AR) > > > > > > > > > > > > Q2-It seems that the oldAR forwards MN's data to newAR as soon as oldAR > > > receives a BU from MN or an F-BU + HACk. > > > The newAR delivers the packets to the MN as soon as it receives an NA > or > > > F-NA from the MN (apart from Q1 above). > > > This means that during this time the MN's packets must be buffered at > > > newAR (whether it helps real time traffic or not, is another issue). > > > There was also a discussion about buffering at oldAR or at newAR, but > > > I think what I missed on the discussion was that > > > " is buffering at newAR supported or is it left to implementers, > > > (Should/ MUST/ May question?)" > > > > We have a 'U' Buffer Flag in HA message. And I think this makes it an > optional > > feature. oldAR MAY turn this flag on. Do you think we should spell this > out in > > the draft? > > > > MN>>Sorry, I am not sure what you mean by HA message and U flag, could you > > please > > lead me to the place in the draft? > > Sorry. I meant "HI" message. > > MN>>>> Ok, thanks, I still has not found the U flag in the draft :(( > Is it in the MIPv6 base draft? I did not see it there either? > page 16 and page 21 of FMIPv^ draft. > > > > > > > > > > > > 3- This question was asked on the list, I am not sure if I saw a > convincing > > > answer other than comparing F-BU with BU. > > > The MN cannot use its newCoA as source address until it has received > > > F-Back from oldAR. Then how does it use newCoA as source address in > F-BU? > > > Isn't this a chicken and egg problem? What am I missing? > > > Also what about ingress filtering issue at oldAR? > > > > > > > MN doesn't have to use newCoA as the source address of F-BU. It can use > oldCoA > > as the source address, and include a alternate CoA suboption. (I'm not > sure if > > this is already stated in the draft. If not, we should add this.) > > > > MN>> That is acceptable, but as it is stated in the draft (page 2) > > > > "The mobile node sends a Fast Binding Update using its newly formed > > COA as the last message before it executes the handover." > > > > is a bit ambiguous. > > Thanks for this catch. We should make this clear in the draft. > > MN>>Thanks, I too feel better now :) > > Regards, > Madjid > Thanks Madjid, alper From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 18:14:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19987 for ; Mon, 11 Jun 2001 18:14:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11353; Mon, 11 Jun 2001 15:14:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16333; Mon, 11 Jun 2001 15:14:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BMDKWi010899 for ; Mon, 11 Jun 2001 15:13:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BMDKK1010898 for mobile-ip-dist; Mon, 11 Jun 2001 15:13:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BMDHWi010891 for ; Mon, 11 Jun 2001 15:13:17 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5BMDGQ296339 for ; Mon, 11 Jun 2001 15:13:16 -0700 (PDT) Message-Id: <200106112213.f5BMDGQ296339@jurassic.eng.sun.com> Date: Mon, 11 Jun 2001 15:13:21 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: eapf8wu7dwVdgwCbutO3ig== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, > > > >Even for ping-ponging, if oldAR can detect that MN is back (ponged :), then > > it > > > >can start forwarding traffic through its link. > > > > > > > >If MN pings again (gone to new link), the oldAR can detect this and start > > > >tunneling to newCoA. > > > > > > > >Therefore this L2 feature can be used to handle ping-ponging without > > requiring > > > >bi-casting. > > > > > > > > > > Sure, it's possible to switch the L3 back and forth, but coupling > > > that with L3 buffering gets complicated. Suppose newAR is buffering. > > > When the MN pongs, how does it pick up the buffered packets? > > > > I am just saying, in the existence of this L2 feature, we don't need bi-casting. > > So, we don't need "this L2 feature + bi-casting", "this L2 feature" does the > > job. > > > => Further to my last mail, I don't think you could really convince > router designers to implement this when there is another > L2 independant mechanism for forwarding packets (bicasting). I think this is taking advantage of L2 features, which I suspect they'd want to do. Well, I guess we'll see. > > BTW, while we're on the topic, Karim and I will issue a > draft shortly on this. Looking forward to it. alper From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 18:14:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20011 for ; Mon, 11 Jun 2001 18:14:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08595; Mon, 11 Jun 2001 16:12:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15836; Mon, 11 Jun 2001 15:12:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BMBLWi010854 for ; Mon, 11 Jun 2001 15:11:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BMBKK2010853 for mobile-ip-dist; Mon, 11 Jun 2001 15:11:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BMBHWi010844 for ; Mon, 11 Jun 2001 15:11:17 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5BMBFQ295863 for ; Mon, 11 Jun 2001 15:11:16 -0700 (PDT) Message-Id: <200106112211.f5BMBFQ295863@jurassic.eng.sun.com> Date: Mon, 11 Jun 2001 15:11:21 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: YYMfcDAIkZOkSAuIdcV0XQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, > > > > Actually, I think a combination of bicasting and buffering may be > > > > the best solution, together with an L2 trigger that tells the AR > > > > when the L2 handover has started. The trick is to keep the buffering > > > > restricted to the time in which the L2 link to the mobile > > > > is well and truely gone. Otherwise, you run the risk of introducing > > > > artifacts. Buffering at L2 (such as 802.11 does for dormant mode mobiles) is > > > > probably a better solution in the end. > > > > > > > => This would be the best way of handling the smoothing > > > of the handover. I fully agree with that. > > > > If the L2 trigger mentioned above is the capability on the AR to say "MN has > > detached" or "MN has attached", then I don't see why we would also need > > bi-casting. This L2 feature itself is sufficient to direct the traffic either > > towards the current link on oldAR (MN is still attached), or towards the newAR > > (as soon as MN detaches). > > > > I don't think we need bi-casting if we have this L2 feature. > > > => And what if we don't ? > Even if we do, I don'tthink we need such level of complexity > to determine whether a packet should be forwarded or not > on the IP layer. Most decent routers implement fowarding > in HW, we don't want to modify HW to implement > a Fast Handoff mechanism. > If the capability you're talking about exists in some cases > then the packets will be dropped on L2 layer anyway > since there is no one to send it to. I don't think this is that complicated. And clearly more optimized then replicating data traffic and sending two copies each time. If you see this as a problem for forwarding in the HW, I assume same problem applies to bi-casting. That HW needs to know which packets to bi-cast, where to bi-cast. If I have a L2 with this capability, while should I duplicate my traffic knowing that one would be dropped, whereas I can know exactly where to send it? It's not like bi-casting is for free. alper From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 18:24:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20116 for ; Mon, 11 Jun 2001 18:24:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15773; Mon, 11 Jun 2001 15:24:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18695; Mon, 11 Jun 2001 15:24:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BMNCWi010984 for ; Mon, 11 Jun 2001 15:23:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BMNCT7010983 for mobile-ip-dist; Mon, 11 Jun 2001 15:23:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BMN8Wi010973 for ; Mon, 11 Jun 2001 15:23:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14812 for ; Mon, 11 Jun 2001 15:23:14 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16148 for ; Mon, 11 Jun 2001 16:23:12 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5BMNBN13260 for ; Tue, 12 Jun 2001 00:23:11 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Jun 12 00:23:11 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 00:23:10 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF11@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Tue, 12 Jun 2001 00:22:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > > => And what if we don't ? > > Even if we do, I don'tthink we need such level of complexity > > to determine whether a packet should be forwarded or not > > on the IP layer. Most decent routers implement fowarding > > in HW, we don't want to modify HW to implement > > a Fast Handoff mechanism. > > If the capability you're talking about exists in some cases > > then the packets will be dropped on L2 layer anyway > > since there is no one to send it to. > > I don't think this is that complicated. And clearly more optimized then > replicating data traffic and sending two copies each time. > => You're not answering my question above. What if we don't have that capability ? Regarding your point above, I can't see how there is any replication in the case where we have an intelligent L2 that knows if a device has disconnected. How can it send something to a "non-existent" device ? > If you see this as a problem for forwarding in the HW, I assume same problem > applies to bi-casting. That HW needs to know which packets to bi-cast, where to > bi-cast. > => I wasn't talking about the forwarding itself, I was referring to these L2 triggers that will change the forwarding tables. Which btw may not be secure in case your L2 doesn't have the appropriate level of security, but that's another point. > If I have a L2 with this capability > => _what_if_you_don't ?? We design another solution ? > , while should I duplicate my traffic knowing > that one would be dropped, whereas I can know exactly where to send it? It's not > like bi-casting is for free. > => Nothing is free of course, but you're trying to have multiple solutions where I want one. In this case the one I'm referring to will have the exact same effect. So why are we trying to solve the problem twice ? Seems wasteful to me. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 11 20:18:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21161 for ; Mon, 11 Jun 2001 20:18:44 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26557; Mon, 11 Jun 2001 18:18:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA12500; Mon, 11 Jun 2001 17:18:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C0HhWi011393 for ; Mon, 11 Jun 2001 17:17:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5C0Hhd3011392 for mobile-ip-dist; Mon, 11 Jun 2001 17:17:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C0HeWi011385 for ; Mon, 11 Jun 2001 17:17:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09363 for ; Mon, 11 Jun 2001 17:17:47 -0700 (PDT) Received: from pcsprodms12.vsmail.org (provps.voicestream.com [208.14.205.98]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25053 for ; Mon, 11 Jun 2001 17:17:47 -0700 (PDT) Received: by PCSPRODMS12 with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 17:20:09 -0700 Message-ID: From: "Bilgic, Murat" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement s for Mobile IP Date: Mon, 11 Jun 2001 17:19:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hemant, A number of questions on your draft: 1. If one uses a mobility protocol complementary to mobile IP, why would additional QoS mechanisms in mobile IP be needed? I have difficulty in parsing the following sentence from your draft "However, the QoS scheme MUST have provisions to accomplish its tasks even if one or more of these mobility protocols are not used." Does it mean that in case no "complemantary" mobility protocol is used, ...? 2. What is so special about QoS that requires Mobile IP support? Why don't other end-to-end procedures, for example end-to-end security, require mobile IP support? I suspect it's because, end-to-end QoS requires the involvement of intermediary nodes, but I'd like to confirm. 3. While I consider the desire to minimize QoS interruptions be minimized as a noble cause, I also realize that this may be somewhat conflicting with some of your "obvious" requirements such as scalability, conservation of wireless bandwidth, low processing overhead, etc. Do you think some prioritization among these requirements is necessary? Also do you think, if the MN should be able to resolve such conflicts based on only local knowledge or does it require the network's assistance while making that decision? (As you may guess, I'm trying to state this as a requirement not as some form of design parameter.) 4. How should I intrepret your requirement on heterogeneous end-to-end packet paths? Does it mean that the MN has to be aware of the entire network topology, e.g., where diffserv, intserv, MPLS or any other mechanism is used and how and where it is interworked? Since I don't currently have to do that for my non-mobile host, I wonder again why is this requirement imposed for mobile hosts? Thanks in advance for your answers, Murat Bilgic > -----Original Message----- > From: Hemant Chaskar [SMTP:hchaskar@hotmail.com] > Sent: Monday, June 11, 2001 1:23 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] New Internet Draft Notification - QoS > requirements for Mobile IP > > Hi, > > I am glad to notify that the discussions on the Mobile IP QoS requirements > > mailing list have now converged. I have compiled them in the form of a > draft: > > "Requirements of a QoS solution for Mobile IP" > draft-chaskar-mobileip-qos-requirements-00.txt > Edited by Hemant Chaskar > > This draft now appears in the IETF I-D directory also. Please provide your > > comments on it. > > The idea behind this draft was to create an input document to NSIS working > > group that may be formed soon. It was made clear that the draft will not > go > into solution space, rather be focussed on the requirements aspects. > > Thanks. > > Hemant Chaskar > Nokia > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 08:17:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12594 for ; Tue, 12 Jun 2001 08:17:14 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26954; Tue, 12 Jun 2001 06:17:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19953; Tue, 12 Jun 2001 05:17:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CCFxWi012751 for ; Tue, 12 Jun 2001 05:15:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CCFxln012750 for mobile-ip-dist; Tue, 12 Jun 2001 05:15:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CCFuWi012743 for ; Tue, 12 Jun 2001 05:15:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17136 for ; Tue, 12 Jun 2001 05:15:43 -0700 (PDT) Received: from mailgw.local.ipunplugged.com ([213.88.134.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05659 for ; Tue, 12 Jun 2001 05:15:40 -0700 (PDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA07737; Tue, 12 Jun 2001 14:17:27 +0200 From: "Fredrik Johansson" To: Cc: Subject: [mobile-ip] WG Last Call Date: Tue, 12 Jun 2001 14:17:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Pat, sorry for the late comments, the draft looks alot better now but there are some issues I'd like to address. Section 1. "2. If the mobile node does not have a Mobility Security Association with the foreign agent, it includes an MN-FA Key Request extension." suggested change: "2. If the mobile node does not have a Mobility Security Association with the foreign agent, it SHOULD include an MN-FA Key Request extension." Section 1. "3. Similarly, if the mobile node does not have a Mobility Security Association with the home agent, it adds an MN-HA Key Request extension." suggested change "3. Similarly, if the mobile node does not have a Mobility Security Association with the home agent, it MUST add an MN-HA Key Request extension." Section 2. I'm not a security expert so correct me if I'm wrong. The defined algorithm identifiers includes the SHA-1 algorithm, but where does the key come in. Should it be used in prefix/sufix mode or should it be HMAC-SHA-1? perhaps it should be: "Algorithm Identifier Name Reference --------------------- ------------------ ------------ 1 MD5/prefix+suffix RFC 2002 [10] 2 HMAC MD5 RFC 2104 [5] 3 SHA-1/prefix+sufic FIPS 180-1 [9] 4 HMAC SHA-1 ?????????? " Section 4. I can't find reference 12 (Registration Keys for Route Optimization) but I can find the extension pointed to in reference 11 (Generalized Key Distribution Extensions for Mobile IP) suggested change is to remove ref 12 and use 11 instead. Section 5. The "Unsolicited MN-HA Key Material From AAA Subtype" includes a Lifetime, a Lifetime is also included in the "Genralized MN-HA Key Reply Extension" (see ref 11), i.e. the lifetime in the subtype is redundant so I suggest that it will be removed. Section 6 and 7. The "Generalized MN-FA Key Request Extension" and the "Generalized MN-HA Key Request Extension" in ref 11 both include a Mobile Node SPI which indicates which SPI the mobile node would like to use in its security association with the respective node. In section 6 and 7 a subtype is introduced to these extensions which includes a SPI which the mobile node would like to use in its security assocition with respecive node. I believe this is redundant information. Suggested change: Use the SPI in the "Generalized" extensions and have the subtype data field be zero in length. Thus the subtype indicates that it is a MN-?A Key Request from AAA Subtype and that it uses the SPI indicated by the Mobile Node SPI in the Generalized Extension. One last thing has to do with the reference section. Ref 11 is: "[11] C. Perkins and P. Calhoun. Generalized Key Distribution Extensions for Mobile IP (work in progress). draft-ietf-mobileip-gen-key-02.txt, March 2001." and I can't find the draft as wg document. However, I can find it as draft-perkins-mobileip-gen-key-03.txt. So can we make it a WG document? And does it need to be a RFC in order to be referenced from the aaa-key doc, or is it possible for a RFC to reference a draft? thanks /Fredrik >-----Original Message----- >From: owner-mobile-ip@sunroof.eng.sun.com >[mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Phil Roberts >Sent: den 8 juni 2001 21:08 >To: 'mobile-ip@sunroof.eng.sun.com' >Subject: [mobile-ip] WG Last Call > > >This is a Mobile IP WG last call for the I-D >draft-ietf-mobileip-aaa-key-06.txt >AAA Registration Keys for Mobile IP. This draft will be sent to the IESG >requesting a proposed standard status to be associated with it at >the end of >the last call >period. Please send your comments to the WG discussion list. > >WG Last call issued on : Jun 8, 2001 >Expires on : Jun 22, 2001 > >Basavaraj Patil >Phil Roberts From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 10:19:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16008 for ; Tue, 12 Jun 2001 10:19:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21944; Tue, 12 Jun 2001 08:19:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28091; Tue, 12 Jun 2001 07:19:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CEI4Wi013027 for ; Tue, 12 Jun 2001 07:18:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CEI4XG013026 for mobile-ip-dist; Tue, 12 Jun 2001 07:18:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CEI1Wi013019 for ; Tue, 12 Jun 2001 07:18:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06260 for ; Tue, 12 Jun 2001 07:18:07 -0700 (PDT) Received: from hotmail.com (f177.law7.hotmail.com [216.33.237.177]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26309 for ; Tue, 12 Jun 2001 07:18:07 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 12 Jun 2001 07:18:07 -0700 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Tue, 12 Jun 2001 14:18:06 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement s for Mobile IP Date: Tue, 12 Jun 2001 14:18:06 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jun 2001 14:18:07.0063 (UTC) FILETIME=[80379670:01C0F34A] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Murat: Here are some answers to your questions: >From: "Bilgic, Murat" >Reply-To: mobile-ip@sunroof.eng.sun.com >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement >s for Mobile IP >Date: Mon, 11 Jun 2001 17:19:54 -0700 > >Hemant, > >A number of questions on your draft: > >1. If one uses a mobility protocol complementary to mobile IP, why would >additional QoS mechanisms in mobile IP be needed? I have difficulty in >parsing the following sentence from your draft "However, the QoS scheme >MUST >have provisions to accomplish its tasks even if one or more of these >mobility protocols are not used." Does it mean that in case no >"complemantary" mobility protocol is used, ...? [HC] Yes, that is what it implies. I will reword the sentence to avoid any confusion. >2. What is so special about QoS that requires Mobile IP support? Why don't >other end-to-end procedures, for example end-to-end security, require >mobile >IP support? I suspect it's because, end-to-end QoS requires the involvement >of intermediary nodes, but I'd like to confirm. [HC] Yes, that is right. >3. While I consider the desire to minimize QoS interruptions be minimized >as >a noble cause, I also realize that this may be somewhat conflicting with >some of your "obvious" requirements such as scalability, conservation of >wireless bandwidth, low processing overhead, etc. Do you think some >prioritization among these requirements is necessary? [HC] I think of it as "trade off" rather than "conflict". It is not possible to prioratize the above requirements in a strict order, as they are difficult to quantify as well as all of them are perceived to be equally important. A solution designer must analyse his solution to justify that it gives "acceptable" performance in terms of these requirements. Afterall, trade off balancing is what engineering is about :-) >Also do you think, if >the MN should be able to resolve such conflicts based on only local >knowledge or does it require the network's assistance while making that >decision? (As you may guess, I'm trying to state this as a requirement not >as some form of design parameter.) [HC] So much of a detail tends to drive us into solution space and reduces the flexibility of solution design. > >4. How should I intrepret your requirement on heterogeneous end-to-end >packet paths? Does it mean that the MN has to be aware of the entire >network >topology, e.g., where diffserv, intserv, MPLS or any other mechanism is >used >and how and where it is interworked? Since I don't currently have to do >that >for my non-mobile host, I wonder again why is this requirement imposed for >mobile hosts? [HC] There is no QoS in Internet today, and that's why you do not have to do it for your non-mobile host. Further, if you have a static host, it is possible to configure in it the QoS functions that the access network expects the host to perform and those functions are not going to change during the ongoing session. For example, the service provider can tell you that it uses DiffServ in access and can give you a configuration file that tells what port numbers to use for say EF traffic so that the network can classify that traffic. In the mobile case, the MN may move across differnt access networks. Also, believe me that some knowledge about the end-to-end packet path is required for end-to-end QoS. The host may not have this knowledge but the network needs to have it. It could be by virtue of SLAs between DiffServ domains, or such knowledge can be acquired by RSVP signalling {RFC 2998) over a mix of IntServ and DiffServ networks. > >Thanks in advance for your answers, [HC] I hope this clarifies some of your concerns. Thanks for your comments. [Hemant] > >Murat Bilgic > > > -----Original Message----- > > From: Hemant Chaskar [SMTP:hchaskar@hotmail.com] > > Sent: Monday, June 11, 2001 1:23 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] New Internet Draft Notification - QoS > > requirements for Mobile IP > > > > Hi, > > > > I am glad to notify that the discussions on the Mobile IP QoS >requirements > > > > mailing list have now converged. I have compiled them in the form of a > > draft: > > > > "Requirements of a QoS solution for Mobile IP" > > draft-chaskar-mobileip-qos-requirements-00.txt > > Edited by Hemant Chaskar > > > > This draft now appears in the IETF I-D directory also. Please provide >your > > > > comments on it. > > > > The idea behind this draft was to create an input document to NSIS >working > > > > group that may be formed soon. It was made clear that the draft will not > > go > > into solution space, rather be focussed on the requirements aspects. > > > > Thanks. > > > > Hemant Chaskar > > Nokia > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 12:54:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19275 for ; Tue, 12 Jun 2001 12:54:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13219; Tue, 12 Jun 2001 09:54:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04255; Tue, 12 Jun 2001 09:53:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CGr0Wi013329 for ; Tue, 12 Jun 2001 09:53:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CGr0ap013328 for mobile-ip-dist; Tue, 12 Jun 2001 09:53:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CGqvWi013321 for ; Tue, 12 Jun 2001 09:52:57 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA07513 for ; Tue, 12 Jun 2001 09:53:05 -0700 (PDT) Message-Id: <200106121653.JAA07513@heliopolis.eng.sun.com> Date: Tue, 12 Jun 2001 09:53:04 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Handover to Third? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Sk1ksXEHz8i/QsLYcqyAPQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I've been looking through the FMIPv6 draft again, and a question came up. It is possible that the MN may have some traffic on newAR required to set up the newCoA. It may have to send an F-BU, and an F-NA or NA. This is in addition to the BU to the HA or hierarchical agent, which will require at least another radio link round trip, probably without full header compression. So there is some amount of time on newAR during which the MN is not in full possession of the newCoA, but is in the process of establishing it. The question is, what happens if the MN moves to a third AR before the process of establishing the newCoA is complete? For example, let's suppose the MN sends the F-BU while on the oldAR but does not receive a reply before L2 handover to newAR happens. Suppose further that the MN's location is at a place where three cells butt up against each other, and that it quickly slips into a third cell at L2, before the F-BACK arrives. Or suppose the MN is moving quickly through a small sliver of a cell between two others. This problem is similar to the ping-pong problem, but with a third cell. There are two issues here: 1) The newAR may not have enough time to complete the PrRtAdv/F-BU pair that is required for network assisted handover over the air with MN prior to the L2 handover to thirdAR, to say nothing of the RtSolPr/PrRtAdv/F-BU for mobile assisted. The HI/HACK would probably work, since that is sent over the backbone and should take no longer than 10 ms, if processing time on thirdAR is low, and 10 ms is about 1/2 of a radio frame for typical 3G radio link protocols. 2) The oldAR is now left thinking that MN has moved to newAR. It has set up a bi-directional tunnel with newAR to assure that MN's packets get to it, even if they have oCoA as the destination address. It attempts to send the F-BACK to nCoA, but MN has moved and the F-BACK doesn't get there, maybe oldAR gets an ICMP message to that effect. What should oldAR do? How does it distinguish this case from one where the MN has moved and goes into dormant mode or is lost? Should newAR set up a second tunnel to thirdAR? It seems to me like the draft needs to provide some solution for this case, as well as for ping-ponging. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 14:56:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22411 for ; Tue, 12 Jun 2001 14:56:11 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13098; Tue, 12 Jun 2001 12:56:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06019; Tue, 12 Jun 2001 11:56:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CIsnWi013803 for ; Tue, 12 Jun 2001 11:54:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CIsn2t013802 for mobile-ip-dist; Tue, 12 Jun 2001 11:54:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CIskWi013795 for ; Tue, 12 Jun 2001 11:54:46 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5CIskQ508260 for ; Tue, 12 Jun 2001 11:54:47 -0700 (PDT) Message-Id: <200106121854.f5CIskQ508260@jurassic.eng.sun.com> Date: Tue, 12 Jun 2001 11:54:52 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KeomW+ePMiDvFRtJr6SyzA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, > > > => And what if we don't ? > > > Even if we do, I don'tthink we need such level of complexity > > > to determine whether a packet should be forwarded or not > > > on the IP layer. Most decent routers implement fowarding > > > in HW, we don't want to modify HW to implement > > > a Fast Handoff mechanism. > > > If the capability you're talking about exists in some cases > > > then the packets will be dropped on L2 layer anyway > > > since there is no one to send it to. > > > > I don't think this is that complicated. And clearly more optimized then > > replicating data traffic and sending two copies each time. > > > => You're not answering my question above. What if we don't > have that capability ? Regarding your point above, I can't I'll answer this below. > see how there is any replication in the case where we have > an intelligent L2 that knows if a device has disconnected. > How can it send something to a "non-existent" device ? I wasn't saying that packets are replicated on the air. Packets are definitely replicated in the IP stack, right? This is bi-casting. Only after they are passed to L2, one copy might be dropped if this L2 knows MN is no longer attached. I don't want to replicate packets, if I know one copy is not needed at all. Why don't we communicate this "L2 not attached" information to where packets would have been replicated, stop bi-casting and forward packets to one place? > > > If you see this as a problem for forwarding in the HW, I assume same problem > > applies to bi-casting. That HW needs to know which packets to bi-cast, where to > > bi-cast. > > > => I wasn't talking about the forwarding itself, I was referring > to these L2 triggers that will change the forwarding > tables. Which btw may not be secure in case your L2 > doesn't have the appropriate level of security, but that's > another point. Not trusting your L2... I'd say this is out of scope. > > > If I have a L2 with this capability > > > => _what_if_you_don't ?? We design another solution ? > > > , while should I duplicate my traffic knowing > > that one would be dropped, whereas I can know exactly where to send it? It's not > > like bi-casting is for free. > > > => Nothing is free of course, but you're trying to have multiple > solutions where I want one. In this case the one I'm referring > to will have the exact same effect. So why are we trying to solve > the problem twice ? Seems wasteful to me. I agree that it's very desirable to have one solution that works in every case. But, we should also be aware of it's costs, and alternative solutions which are optimized in certain cases. What I'm saying is, whenever available, connection-oriented L2 features should be used, instead of bi-casting. If this feature is not available, then something else can be used. I understand it's desirable to have one solution. But I clearly see a benefit to taking advantage of this L2 feature. Do you see any technical problems with this approach, other than it using a case-specific solution? alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 17:24:57 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24902 for ; Tue, 12 Jun 2001 17:24:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00288; Tue, 12 Jun 2001 14:25:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09771; Tue, 12 Jun 2001 14:24:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CLNlWi014146 for ; Tue, 12 Jun 2001 14:23:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CLNkkU014145 for mobile-ip-dist; Tue, 12 Jun 2001 14:23:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CLNhWi014138 for ; Tue, 12 Jun 2001 14:23:43 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA16936 for ; Tue, 12 Jun 2001 14:23:52 -0700 (PDT) Message-Id: <200106122123.OAA16936@heliopolis.eng.sun.com> Date: Tue, 12 Jun 2001 14:23:51 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XnrheTOG8+jjIo23Rhhv9Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, >I wasn't saying that packets are replicated on the air. Packets are definitely >replicated in the IP stack, right? This is bi-casting. Only after they are >passed to L2, one copy might be dropped if this L2 knows MN is no longer >attached. > >I don't want to replicate packets, if I know one copy is not needed at all. Why >don't we communicate this "L2 not attached" information to where packets would >have been replicated, stop bi-casting and forward packets to one place? > There is no reason why oldAR can't stop replicating packets once it gets an L2 signal that MN is gone. There is no point in continuing to send packets on old L2 unless MN shows up again due to a ping-pong. The replication at oldAR is only needed from the time the oldAR determines that an L2 handoff is about to take place until the oldAR drops the old L2 due to an L2 handoff occuring. The reason you need that replication is because of the uncertainty involved in exactly when the L2 handoff will occur and how long it will last. During that interval, the newAR should be using a sliding window buffer at L2 to hold a few radio frames until the MN shows up on the new link. The buffer size should be calculated to give some high percentage of covering the L2 handover time on average (figure 90% coverage, for example, probably best to measure experimentally) for a particular radio link protocol and incoming bit rate. If a ping-pong occurs, the MN is back on oldAR and it may miss a few packets that arrived while the MN was in transit from and back to oldAR. This could cause an artifact in the real time transport if enough are dropped. An alternative would be for oldAR to apply the same kind of sliding window buffer for some period of time (again determined experimentally) until it is, say, 90% certain that a ping-pong won't occur, then switch off the L2. If the L2 doesn't support buffering, then perhaps a similar small L3 buffer for the duration of the L2 handover could be implemented. The kind of thing I don't think is needed is full up L3 packet buffering on newAR from the time the HACK gets sent out until the time the MN sends the F-NA. In that case, if the MN pongs back to the oldAR, there is a bigger chunk of state on newAR that newAR has to deal with (drop? forward to oldAR?), and oldAR doesn't have anything for MN unless it, too, buffers. The radio channel on newAR also gets preempted while that chunk of state is sent down to the MN. Plus it requires more state in the router. To see how much more, consider the following calculations: Case 1: The buffer is designed to accommodate only traffic while L2 handover is in progress. Suppose the L2 handover requires, on average 200 ms (sorry for the imprecision, I'm having difficulty locating exact L2 handover times). That's 240 bytes at 9.6 kbps, or 6 WCDMA frames. The data rate here could be more or slightly less, but this seems like a reasonable assumption. Case 2: The buffer is designed to accommodate all incoming L3 traffic between HACK arriving and MN sending F-NA indicating it is up on the newAR. It is difficult to estimate when the HACK might arrive, but let's say there is a 10 ms lag between HI and HACK, so the HACK arrives 10 ms after an L3 handoff begins. Some estimates for L3 handoff times were included in the previous email I sent out, so let's assume that the amount of buffering is: (L3 handover time - 10 ms) + L2 handover time. L2 handover time is 200 ms from above. The most optimistic L3 handover time at 9.6 Kbps from my previous calculations is 133 ms. The result is 387 bytes, or 62 % more buffer required. In reality, it would have to be more than 387 bytes because I assumed the most optimistic time. You would have to measure experimentally how often the various combinations of F-BU on oldAR or newAR, F-BACK on oldAR or newAR, etc occured and size the buffer so it accommodated 90% of that variability. Multiply that extra buffer size by the number of mobile nodes you want to support, and it should be clear the Case 1 is more scalable. As I think should be clear from this discussion, the situation is not one of bicasting v.s. buffering but rather how to use both in a way that will accommodate the characteristics of the radio link to provide the smoothest possible handover for the MN. In some radio links, you might not need one or the other, but for typical 3G radio links, I think you will need both. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 17:36:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25105 for ; Tue, 12 Jun 2001 17:36:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22167; Tue, 12 Jun 2001 15:36:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12838; Tue, 12 Jun 2001 14:36:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CLZWWi014251 for ; Tue, 12 Jun 2001 14:35:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CLZVhL014250 for mobile-ip-dist; Tue, 12 Jun 2001 14:35:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CLZSWi014243 for ; Tue, 12 Jun 2001 14:35:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15535 for ; Tue, 12 Jun 2001 14:35:36 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21376 for ; Tue, 12 Jun 2001 15:35:35 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA26311 for ; Tue, 12 Jun 2001 14:35:35 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA12167 for ; Tue, 12 Jun 2001 14:35:34 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 16:35:34 -0500 Message-ID: <557F0D0BBE89D411A085009027B0F7415F68EA@IL27EXM08.cig.mot.com> From: Pandurangi Venkatesh-AVP028 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mobile IPv4 implementation ?? Date: Tue, 12 Jun 2001 16:35:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I would like to know is there any mobile IPv4 implementation by Carnegie Mellon University on freeBSD 4.2. If you know anything about this, please let me know, that will help me for my development. Thanks in advance. Venkatesh From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 18:18:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25788 for ; Tue, 12 Jun 2001 18:18:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25694; Tue, 12 Jun 2001 15:19:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22673; Tue, 12 Jun 2001 15:18:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CMHvWi014314 for ; Tue, 12 Jun 2001 15:17:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CMHv1H014313 for mobile-ip-dist; Tue, 12 Jun 2001 15:17:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CMHrWi014306 for ; Tue, 12 Jun 2001 15:17:54 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17513 for ; Tue, 12 Jun 2001 15:18:00 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20034 for ; Tue, 12 Jun 2001 15:17:59 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5CMHwN17284 for ; Wed, 13 Jun 2001 00:17:58 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Jun 13 00:17:56 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 00:12:29 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF19@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Wed, 13 Jun 2001 00:17:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > > see how there is any replication in the case where we have > > an intelligent L2 that knows if a device has disconnected. > > How can it send something to a "non-existent" device ? > > I wasn't saying that packets are replicated on the air. Packets are definitely > replicated in the IP stack, right? This is bi-casting. Only after they are > passed to L2, one copy might be dropped if this L2 knows MN is no longer > attached. > > I don't want to replicate packets, if I know one copy is not needed at all. Why > don't we communicate this "L2 not attached" information to where packets would > have been replicated, stop bi-casting and forward packets to one place? > => That's clearly not free either as was discussed many times in the DT. Apart from the complexity of implementing it (we agree that there is complexity in implementing anything really), there maybe delays in detecting the MN's detachment on L2. This will add delays in packet forwarding. > > > > > => I wasn't talking about the forwarding itself, I was referring > > to these L2 triggers that will change the forwarding > > tables. Which btw may not be secure in case your L2 > > doesn't have the appropriate level of security, but that's > > another point. > > Not trusting your L2... I'd say this is out of scope. > => Huh ? Not all L2s have a different security association per device. > > > > > If I have a L2 with this capability > > > > > => _what_if_you_don't ?? We design another solution ? > > > > > , while should I duplicate my traffic knowing > > > that one would be dropped, whereas I can know exactly where to send it? It's > not > > > like bi-casting is for free. > > > > > => Nothing is free of course, but you're trying to have multiple > > solutions where I want one. In this case the one I'm referring > > to will have the exact same effect. So why are we trying to solve > > the problem twice ? Seems wasteful to me. > > > I agree that it's very desirable to have one solution that works in every case. > But, we should also be aware of it's costs, and alternative solutions which are > optimized in certain cases. > => Of course, but right now we don't have a soution after bicasting was removed from the draft. We've been over this many times now and we always discussed adding the _option_of bicasting. It was never a MUST. > What I'm saying is, whenever available, connection-oriented L2 features should > be used, instead of bi-casting. If this feature is not available, then something > else can be used. > => Like bicasting ? another solution ? nothing is in the draft right now. > I understand it's desirable to have one solution. But I clearly see a benefit to > taking advantage of this L2 feature. Do you see any technical problems with this > approach, other than it using a case-specific solution? > => Alper, if you want to implement this in your router no one will / can stop you from doing so. But if you don't want to or the solution won't work for you, then what do you do ? BTW, if we can rely on the method you mention here, why did we have the NA message to inform the new AR that the MN has appeared on link ? Ping pong is not the only reason for using bicasting, once you anticipate movement, you're ever 100 % sure about the exact time at which you will lose L2 connectivity, therefore packets will be lost in the mean time. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 12 20:22:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27291 for ; Tue, 12 Jun 2001 20:22:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA09866; Tue, 12 Jun 2001 17:22:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17732; Tue, 12 Jun 2001 17:22:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D0LMWi014490 for ; Tue, 12 Jun 2001 17:21:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5D0LMba014489 for mobile-ip-dist; Tue, 12 Jun 2001 17:21:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D0LJWi014482 for ; Tue, 12 Jun 2001 17:21:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17526 for ; Tue, 12 Jun 2001 17:21:27 -0700 (PDT) Received: from pcsprodms12.vsmail.org (provps.voicestream.com [208.14.205.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA06703 for ; Tue, 12 Jun 2001 18:21:25 -0600 (MDT) Received: by PCSPRODMS12 with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Jun 2001 17:24:51 -0700 Message-ID: From: "Bilgic, Murat" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement s for Mobile IP Date: Tue, 12 Jun 2001 17:24:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hemant, Some more follow-up on the draft and your answers inline. > -----Original Message----- > From: Hemant Chaskar [SMTP:hchaskar@hotmail.com] > Sent: Tuesday, June 12, 2001 7:18 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] New Internet Draft Notification - QoS > requirement s for Mobile IP > > Hi Murat: > > Here are some answers to your questions: > > >From: "Bilgic, Murat" > >Reply-To: mobile-ip@sunroof.eng.sun.com > >To: "'mobile-ip@sunroof.eng.sun.com'" > >Subject: RE: [mobile-ip] New Internet Draft Notification - QoS > requirement > >s for Mobile IP > >Date: Mon, 11 Jun 2001 17:19:54 -0700 > > > >Hemant, > > > >A number of questions on your draft: > > > >1. If one uses a mobility protocol complementary to mobile IP, why would > >additional QoS mechanisms in mobile IP be needed? I have difficulty in > >parsing the following sentence from your draft "However, the QoS scheme > >MUST > >have provisions to accomplish its tasks even if one or more of these > >mobility protocols are not used." Does it mean that in case no > >"complemantary" mobility protocol is used, ...? > > [HC] Yes, that is what it implies. I will reword the sentence to avoid any > > confusion. [MB] Thanks. > >2. What is so special about QoS that requires Mobile IP support? Why > don't > >other end-to-end procedures, for example end-to-end security, require > >mobile > >IP support? I suspect it's because, end-to-end QoS requires the > involvement > >of intermediary nodes, but I'd like to confirm. > > [HC] Yes, that is right. > > >3. While I consider the desire to minimize QoS interruptions be minimized > > >as > >a noble cause, I also realize that this may be somewhat conflicting with > >some of your "obvious" requirements such as scalability, conservation of > >wireless bandwidth, low processing overhead, etc. Do you think some > >prioritization among these requirements is necessary? > > [HC] I think of it as "trade off" rather than "conflict". It is not > possible > to prioratize the above requirements in a strict order, as they are > difficult to quantify as well as all of them are perceived to be equally > important. A solution designer must analyse his solution to justify that > it > gives "acceptable" performance in terms of these requirements. Afterall, > trade off balancing is what engineering is about :-) [MB] I agree "trade off" is a better term. > >Also do you think, if > >the MN should be able to resolve such conflicts based on only local > >knowledge or does it require the network's assistance while making that > >decision? (As you may guess, I'm trying to state this as a requirement > not > >as some form of design parameter.) > > [HC] So much of a detail tends to drive us into solution space and reduces > > the flexibility of solution design. [MB] I disagree on this one. But probably I should clarify my reasoning. I see the two ends of the spectrum of solutions as follows: 1. MN does not need any authorization prior to a mobility event for QoS. Therefore, the network is (over-)provisioned to accommodate such events. Obviously this does not mean that after the mobility event, the network can't force a degradation in the provided QoS, but the application demanding QoS has a much longer time to adopt itself. The benefit I see for this end of the spectrum is potentially faster and simpler mobility. BTW, this was what I was referring as "local knowledge". 2. MN needs authorization, i.e., negotiation with the network prior to a mobility event for QoS. Therefore, the network is provisioned just the "right amount". However, the mobility mechanism is most likely more complex and slower. In addition, the application has to react much faster to degradation in the provided QoS. Again, this was what I was referring to as "network assistance". In my opinion, there is a very big difference between these two approaches. If you are saying the requirement is so broad such that any solution within this spectrum would be acceptable, then I'd have difficulty accepting the value of requirements development phase. > > > >4. How should I intrepret your requirement on heterogeneous end-to-end > >packet paths? Does it mean that the MN has to be aware of the entire > >network > >topology, e.g., where diffserv, intserv, MPLS or any other mechanism is > >used > >and how and where it is interworked? Since I don't currently have to do > >that > >for my non-mobile host, I wonder again why is this requirement imposed > for > >mobile hosts? > > [HC] There is no QoS in Internet today, and that's why you do not have to > do > it for your non-mobile host. > > Further, if you have a static host, it is possible to configure in it the > QoS functions that the access network expects the host to perform and > those > functions are not going to change during the ongoing session. For example, > > the service provider can tell you that it uses DiffServ in access and can > give you a configuration file that tells what port numbers to use for say > EF > traffic so that the network can classify that traffic. In the mobile case, > > the MN may move across differnt access networks. > > Also, believe me that some knowledge about the end-to-end packet path is > required for end-to-end QoS. The host may not have this knowledge but the > network needs to have it. It could be by virtue of SLAs between DiffServ > domains, or such knowledge can be acquired by RSVP signalling {RFC 2998) > over a mix of IntServ and DiffServ networks. [MB] I don't dispute that end-to-end QoS requires some form of capability to signal what you are looking for from the MN's side or what you should use from the network side. However, as articulated quite convincingly in RFC 2990, it's quite hard to imagine one framework, i.e., a holy grail to solve this problem. If (at least as of today it's true) there is no unifying QoS framework for Internet, then I'd say the argument for one for mobile hosts is pretty weak. Instead, wouldn't it be better to put together a more limited requirement stating that a network's QoS capabilities are used in determining the mobility decision within the MN. In this case, there is no reason for a "one-size fits all" QoS solution and MNs would still make informed decisions. In addition end-to-end QoS mechanism(s) can be kept entirely separate from mobile IP. What do you think? > > > >Thanks in advance for your answers, > > [HC] I hope this clarifies some of your concerns. Thanks for your > comments. > > [Hemant] [MB] Thank you, Murat Bilgic > > > >Murat Bilgic > > > > > -----Original Message----- > > > From: Hemant Chaskar [SMTP:hchaskar@hotmail.com] > > > Sent: Monday, June 11, 2001 1:23 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: [mobile-ip] New Internet Draft Notification - QoS > > > requirements for Mobile IP > > > > > > Hi, > > > > > > I am glad to notify that the discussions on the Mobile IP QoS > >requirements > > > > > > mailing list have now converged. I have compiled them in the form of a > > > draft: > > > > > > "Requirements of a QoS solution for Mobile IP" > > > draft-chaskar-mobileip-qos-requirements-00.txt > > > Edited by Hemant Chaskar > > > > > > This draft now appears in the IETF I-D directory also. Please provide > >your > > > > > > comments on it. > > > > > > The idea behind this draft was to create an input document to NSIS > >working > > > > > > group that may be formed soon. It was made clear that the draft will > not > > > go > > > into solution space, rather be focussed on the requirements aspects. > > > > > > Thanks. > > > > > > Hemant Chaskar > > > Nokia > > > _________________________________________________________________ > > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 03:52:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17252 for ; Wed, 13 Jun 2001 03:52:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10501; Wed, 13 Jun 2001 01:52:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29462; Wed, 13 Jun 2001 00:52:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D7pIWi014928 for ; Wed, 13 Jun 2001 00:51:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5D7pHLA014927 for mobile-ip-dist; Wed, 13 Jun 2001 00:51:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D7pEWi014920 for ; Wed, 13 Jun 2001 00:51:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09542 for ; Wed, 13 Jun 2001 00:51:22 -0700 (PDT) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA07596 for ; Wed, 13 Jun 2001 00:51:21 -0700 (PDT) Received: from darmstadt.gmd.de (pc-morion [141.12.35.155]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id JAA00907; Wed, 13 Jun 2001 09:51:20 +0200 (MET DST) Message-ID: <3B271C1B.6BFBB551@darmstadt.gmd.de> Date: Wed, 13 Jun 2001 09:54:03 +0200 From: Wolfgang Schoenfeld Organization: GMD X-Mailer: Mozilla 4.7 [de] (WinNT; I) X-Accept-Language: en,de MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Handover to Third? References: <200106121653.JAA07513@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, one may imagine that MN moves (physically or by radio reachability) so fast that any data forwarded to newAR by whatsoever method arrives there only after MN has left it. (This holds for unicast forwarding only. If data is multicasted to all envisaged ARs, MN will receive it by at least one of them - if reachability time is long enough.) Couldn't it be that the problem you describe is unsolvable in general and has a solution only under reasonable assumptions on MN's moves, taking numbers into account as you computed? These would clearly depend on the (geographical) distribution of ARs. Wolfgang James Kempf schrieb: > > I've been looking through the FMIPv6 draft again, and a question came up. > > It is possible that the MN may have some traffic on newAR required > to set up the newCoA. It may have to send an F-BU, and an > F-NA or NA. This is in addition to the BU to the HA or hierarchical agent, which > will require at least another radio link round trip, probably without full > header compression. So there is some amount of time on newAR during which the MN > is not in full possession of the newCoA, but is in the process of > establishing it. > > The question is, what happens if the MN moves to a third AR before > the process of establishing the newCoA is complete? > > For example, let's suppose the MN sends the F-BU while on the oldAR > but does not receive a reply before L2 handover to newAR happens. Suppose > further that the MN's location is at a place where three cells butt > up against each other, and that it quickly slips into a third cell at L2, > before the F-BACK arrives. Or suppose the MN is moving quickly through > a small sliver of a cell between two others. This problem is similar > to the ping-pong problem, but with a third cell. > > There are two issues here: > > 1) The newAR may not have enough time to complete the PrRtAdv/F-BU pair > that is required for network assisted handover over the air with MN prior to the > L2 handover to thirdAR, to say nothing of the RtSolPr/PrRtAdv/F-BU for mobile > assisted. The HI/HACK would probably work, since that is sent over > the backbone and should take no longer than 10 ms, if processing time > on thirdAR is low, and 10 ms is about 1/2 of a radio frame for typical 3G > radio link protocols. > > 2) The oldAR is now left thinking that MN has moved to newAR. It has > set up a bi-directional tunnel with newAR to assure that MN's packets > get to it, even if they have oCoA as the destination address. It attempts > to send the F-BACK to nCoA, but MN has moved and the F-BACK doesn't get > there, maybe oldAR gets an ICMP message to that effect. What should oldAR do? > How does it distinguish this case from one where the MN has moved and goes into > dormant mode or is lost? Should newAR set up a second tunnel to thirdAR? > > It seems to me like the draft needs to provide some solution for this > case, as well as for ping-ponging. > > jak -- Prof. Dr. Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 07:10:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18506 for ; Wed, 13 Jun 2001 07:10:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19040; Wed, 13 Jun 2001 04:11:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13810; Wed, 13 Jun 2001 04:11:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DBACWi015156 for ; Wed, 13 Jun 2001 04:10:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DBAC5b015155 for mobile-ip-dist; Wed, 13 Jun 2001 04:10:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DBA8Wi015148 for ; Wed, 13 Jun 2001 04:10:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06800 for ; Wed, 13 Jun 2001 04:10:14 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26650 for ; Wed, 13 Jun 2001 04:10:13 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18322; Wed, 13 Jun 2001 07:09:41 -0400 (EDT) Message-Id: <200106131109.HAA18322@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-qos-requirements-00.txt Date: Wed, 13 Jun 2001 07:09:41 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Requirements of a QoS Solution for Mobile IP Author(s) : H. Chaskar Filename : draft-ietf-mobileip-qos-requirements-00.txt Pages : 7 Date : 12-Jun-01 Mobile IP protocol ensures correct routing of packets to mobile node as the mobile node changes its point of attachment with the Internet. However, it is also required to provide proper QoS forwarding treatment to mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements of an IP QoS mechanism for its satisfactory operation with Mobile IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-qos-requirements-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-qos-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010612113703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-qos-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-qos-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010612113703.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 10:17:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23611 for ; Wed, 13 Jun 2001 10:17:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25557; Wed, 13 Jun 2001 07:17:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01352; Wed, 13 Jun 2001 07:17:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DEGHWi015302 for ; Wed, 13 Jun 2001 07:16:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DEGHMq015301 for mobile-ip-dist; Wed, 13 Jun 2001 07:16:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DEGCWi015294 for ; Wed, 13 Jun 2001 07:16:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11824 for ; Wed, 13 Jun 2001 07:16:14 -0700 (PDT) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19781 for ; Wed, 13 Jun 2001 07:16:12 -0700 (PDT) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id RAA04180 for ; Wed, 13 Jun 2001 17:16:10 +0300 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma004176; Wed, 13 Jun 01 17:16:09 +0300 Received: from morphine.tml.hut.fi (morphine.tml.hut.fi [130.233.45.7]) by mail.tml.hut.fi (8.11.0/8.11.0) with ESMTP id f5DEG3q01300 for ; Wed, 13 Jun 2001 17:16:03 +0300 (EEST) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.11.3/8.11.3) with ESMTP id f5DEG5o14375 for ; Wed, 13 Jun 2001 17:16:05 +0300 (EET DST) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Wed, 13 Jun 2001 17:16:05 +0300 (EET DST) From: Lars Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Archive of the list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I noticed that the list archive at Nortel's site is not up to date anymore (February is the last month covered in the archive). Is there a more current archive available somewhere? Thanks, Henrik Petander From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 10:26:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23832 for ; Wed, 13 Jun 2001 10:26:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00671; Wed, 13 Jun 2001 07:27:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02332; Wed, 13 Jun 2001 07:24:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DENcWi015352 for ; Wed, 13 Jun 2001 07:23:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DENcH3015351 for mobile-ip-dist; Wed, 13 Jun 2001 07:23:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DENYWi015344 for ; Wed, 13 Jun 2001 07:23:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00601 for ; Wed, 13 Jun 2001 07:23:41 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24204 for ; Wed, 13 Jun 2001 07:23:40 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA26845 for ; Wed, 13 Jun 2001 07:23:39 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA02636 for ; Wed, 13 Jun 2001 07:23:39 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Wed, 13 Jun 2001 09:23:38 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id QAA13941 for mobile-ip@sunroof.eng.sun.com.DELIVER; Wed, 13 Jun 2001 16:23:35 +0200 (METDST) Received: from crm.mot.com (routier@durga.crm.mot.com [140.101.173.45]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id QAA13911 for ; Wed, 13 Jun 2001 16:23:34 +0200 (METDST) Message-Id: <3B277777.E9A5070A@crm.mot.com> Date: Wed, 13 Jun 2001 16:23:51 +0200 From: Damien Routier Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.74C-CRM-4.7_2.2 [en] (X11; U; Linux 2.2.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Archive of the list References: Content-Type: multipart/mixed; boundary="------------8E0F0FB96CCBD2E49333E545" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------8E0F0FB96CCBD2E49333E545 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, You may want to try this http://www.lifix.fi/extarchive/mobile-ip/ Have a nice day. Damien Lars Henrik Petander wrote: > > Hi, > > I noticed that the list archive at Nortel's site is not up to date anymore > (February is the last month covered in the archive). Is there a more > current archive available somewhere? > > Thanks, > > Henrik Petander --------------8E0F0FB96CCBD2E49333E545 Content-Type: text/x-vcard; charset=us-ascii; name="Damien.Routier.vcf" Content-Description: Card for Damien Routier Content-Disposition: attachment; filename="Damien.Routier.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; x-mozilla-html:FALSE adr:;;;;;; version:2.1 x-mozilla-cpt:;0 end:vcard --------------8E0F0FB96CCBD2E49333E545-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 14:13:25 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28634 for ; Wed, 13 Jun 2001 14:13:23 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27805; Wed, 13 Jun 2001 12:13:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15454; Wed, 13 Jun 2001 11:13:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIBmWi015851 for ; Wed, 13 Jun 2001 11:11:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DIBmpr015850 for mobile-ip-dist; Wed, 13 Jun 2001 11:11:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIBjWi015843 for ; Wed, 13 Jun 2001 11:11:45 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5DIBpG304760 for ; Wed, 13 Jun 2001 11:11:51 -0700 (PDT) Message-Id: <200106131811.f5DIBpG304760@jurassic.eng.sun.com> Date: Wed, 13 Jun 2001 11:11:51 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: is6kSbqHc/A/5O/5jFtvFQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > >I wasn't saying that packets are replicated on the air. Packets are definitely > >replicated in the IP stack, right? This is bi-casting. Only after they are > >passed to L2, one copy might be dropped if this L2 knows MN is no longer > >attached. > > > >I don't want to replicate packets, if I know one copy is not needed at all. Why > >don't we communicate this "L2 not attached" information to where packets would > >have been replicated, stop bi-casting and forward packets to one place? > > > > > There is no reason why oldAR can't stop replicating packets once it > gets an L2 signal that MN is gone. There is no point in continuing > to send packets on old L2 unless MN shows up again due to a ping-pong. Yes, we are in agreement here. > > The replication at oldAR is only needed from the time the oldAR determines that > an L2 handoff is about to take place until the oldAR drops the old L2 > due to an L2 handoff occuring. The reason you need that replication > is because of the uncertainty involved in exactly when the L2 handoff > will occur and how long it will last. During that interval, the newAR should If there's a possibility that MN might successfully attach to new link, before oldAR recevies a L2 detach notice, only then it makes sense to bi-cast until L2 detach signal. If we certainly know MN cannot attach to new link until oldAR receives the L2 detach notice, then I still don't see why we should bi-cast. If this is the uncertainity you are talking about, it'd make more sense, yet I don't know how big are the savings here. [depends on system, implementation, etc..] > be using a sliding window buffer at L2 to hold a few radio frames > until the MN shows up on the new link. The buffer size > should be calculated to give some high percentage of covering the > L2 handover time on average (figure 90% coverage, for example, probably > best to measure experimentally) for a particular radio link protocol and > incoming bit rate. > > If a ping-pong occurs, the MN is back on oldAR and it may miss a few > packets that arrived while the MN was in transit from and back to oldAR. This > could cause an artifact in the real time transport if enough are dropped. > An alternative would be for oldAR to apply the same kind of sliding > window buffer for some period of time (again determined experimentally) > until it is, say, 90% certain that a ping-pong won't occur, then > switch off the L2. Yes, if you want to smooth the handover in a way that you want to save packets which arrived at the oldAR while MN is ponging back from newAR... Further smoothing.. > > If the L2 doesn't support buffering, then perhaps a similar small > L3 buffer for the duration of the L2 handover could be implemented. > > The kind of thing I don't think is needed is full up L3 packet buffering > on newAR from the time the HACK gets sent out until the time > the MN sends the F-NA. In that case, if the MN pongs back to the > oldAR, there is a bigger chunk of state on newAR that newAR has to > deal with (drop? forward to oldAR?), and oldAR doesn't have > anything for MN unless it, too, buffers. The radio channel on newAR also gets > preempted while that chunk of state is sent down to the MN. Plus it requires > more state in the router. > > To see how much more, consider the following calculations: > > Case 1: > The buffer is designed to accommodate only traffic while L2 handover > is in progress. Suppose the L2 handover requires, on average 200 ms (sorry for > the imprecision, I'm having difficulty locating exact L2 handover times). That's > 240 bytes at 9.6 kbps, or 6 WCDMA frames. The data rate here could be > more or slightly less, but this seems like a reasonable assumption. > > Case 2: > The buffer is designed to accommodate all incoming L3 traffic between > HACK arriving and MN sending F-NA indicating it is up on the newAR. > It is difficult to estimate when the HACK might arrive, but let's say > there is a 10 ms lag between HI and HACK, so the HACK arrives 10 ms > after an L3 handoff begins. Some estimates for L3 handoff times > were included in the previous email I sent out, so let's assume > that the amount of buffering is: (L3 handover time - 10 ms) + L2 handover time. > L2 handover time is 200 ms from above. The most optimistic L3 handover > time at 9.6 Kbps from my previous calculations is 133 ms. The result > is 387 bytes, or 62 % more buffer required. > > In reality, it would have to be more than 387 bytes because I assumed > the most optimistic time. You would have to measure experimentally > how often the various combinations of F-BU on oldAR or newAR, F-BACK > on oldAR or newAR, etc occured and size the buffer so it accommodated > 90% of that variability. > > Multiply that extra buffer size by the number of mobile nodes you want > to support, and it should be clear the Case 1 is more scalable. > > As I think should be clear from this discussion, the situation is > not one of bicasting v.s. buffering but rather how to use both > in a way that will accommodate the characteristics of the radio link > to provide the smoothest possible handover for the MN. > In some radio links, you might not need one or the other, but for > typical 3G radio links, I think you will need both. That makes sense. Depending on the system, people can implement these different handoff smoothing techniques. I don't think these require a protocol specification. IMHO, these are implementation decisions. alper From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 14:22:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28822 for ; Wed, 13 Jun 2001 14:22:43 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12188; Wed, 13 Jun 2001 11:22:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17709; Wed, 13 Jun 2001 11:22:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DILYWi015897 for ; Wed, 13 Jun 2001 11:21:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DILYvI015896 for mobile-ip-dist; Wed, 13 Jun 2001 11:21:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DILUWi015889 for ; Wed, 13 Jun 2001 11:21:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23117 for ; Wed, 13 Jun 2001 11:21:36 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18404 for ; Wed, 13 Jun 2001 12:22:14 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA20742 for ; Wed, 13 Jun 2001 11:21:32 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA00684 for ; Wed, 13 Jun 2001 11:21:32 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 13:21:31 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9D82@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Wed, 13 Jun 2001 13:21:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, Thanks for the email and thanks for the ref to U flag. Please see my comments below. I did cut a lot for readability. -----Original Message----- From: Alper Yegin [mailto:Alper.Yegin@eng.sun.com] Sent: Monday, June 11, 2001 5:02 PM To: mobile-ip@sunroof.eng.sun.com Cc: G.Tsirtsis@flarion.com Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 ..... > MN>>>>Well, how does the sender know where to send the packets before > receiving > F-NA/NA from the mobile? L2 address of MN is sent in HI message from oldAR to newAR. As soon as MN attaches to new link, "if" newAR can detect this attachment and correlate this to MN, then newAR can start forwarding packets. Otherwise, newAR needs to wait for F-NA. "where to send" information is the L2 address of the mobile node, which was communicated in the HI message. MN>> Ok, Maybe I need to do some studying on the addressing issues, at this point, I am not sure what correlating in this case means, Does it mean newAR looks at its database for MN's address (stateful) what about stateless? I would say waiting for F-NA is the layer 3 way of doing things. You seem to be relying on some L2 mechanisms, am I missing something? > MN>>>> to me neither. Tell me who sends L2 attachement to MN, > AR or AP, if AR does then there would be no race condition > (however, this would not be a general case, I think), but > if AP does, then AP sends the signal to AR as well and there > would be a time when one of AR and MN does not know about the > L2 connectivity (I think MN would know later, but it is not certain) So, what you are saying is this: there can be a case where AR thinks MN is L2 connected and starts sending packets, but MN is actually not L2 connected yet. This sounds like a L2 problem, that needs to be handled at L2. I think L2 folks should fix this :) MN>> Well maybe, but the way it is written in the draft, you are making your protocol volnurable to L2 imperfections!! Especially in the solution that offerred in your first answer above. I still have a hard time to digest your "based on L2 connectivity signal OR receiving F-NA" condition. Let me know if I am confused. Madjid From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 14:25:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28884 for ; Wed, 13 Jun 2001 14:25:53 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08785; Wed, 13 Jun 2001 12:26:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18567; Wed, 13 Jun 2001 11:25:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIOaWi015932 for ; Wed, 13 Jun 2001 11:24:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DIOZXp015931 for mobile-ip-dist; Wed, 13 Jun 2001 11:24:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIOWWi015924 for ; Wed, 13 Jun 2001 11:24:32 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA12907 for ; Wed, 13 Jun 2001 11:24:39 -0700 (PDT) Message-Id: <200106131824.LAA12907@heliopolis.eng.sun.com> Date: Wed, 13 Jun 2001 11:24:38 -0700 (PDT) From: James Kempf Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: t3fsB2cz/wBLz0zRNpw9gQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, >If there's a possibility that MN might successfully attach to new link, before >oldAR recevies a L2 detach notice, only then it makes sense to bi-cast until L2 >detach signal. If we certainly know MN cannot attach to new link until oldAR >receives the L2 detach notice, then I still don't see why we should bi-cast. If >this is the uncertainity you are talking about, it'd make more sense, yet I >don't know how big are the savings here. [depends on system, implementation, >etc..] > You are talkng about make before break, and this is not typically the kind of handoff where MIP would come into play. MIP would only come into play when the connection with the old access point is broken, at L3, before it comes up on the new. But I'm curious why you feel that a make before break handoff would be the only case that would benefit from bicasting. To me, it is the other way around. The reason is because the MN breaks the old L2 before the new L2 is solid enough for L3 traffic. Typically, there is some short period of time when the MN and new AP exchange traffic to be sure the connection is solid, before L3 traffic resumes. Since the exact duration of this time period is uncertain and when the old L2 is broken, it makes sense to send the MN's traffic to newAR before there is a break in the old L2, to make sure the MN doesn't miss anything. Or? >That makes sense. Depending on the system, people can implement these different >handoff smoothing techniques. I don't think these require a protocol >specification. IMHO, these are implementation decisions. > I think there are interoperability considerations, and to the extent there are, it should be specified. Suppose I connect a Nokia router and a Motorola router, and one does smoothing as I outline and the other doesn't? jak From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 14:32:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28984 for ; Wed, 13 Jun 2001 14:32:49 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15030; Wed, 13 Jun 2001 12:33:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20740; Wed, 13 Jun 2001 11:33:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIW5Wi015998 for ; Wed, 13 Jun 2001 11:32:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DIW5r5015997 for mobile-ip-dist; Wed, 13 Jun 2001 11:32:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIW1Wi015990 for ; Wed, 13 Jun 2001 11:32:02 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5DIW8G313157 for ; Wed, 13 Jun 2001 11:32:08 -0700 (PDT) Message-Id: <200106131832.f5DIW8G313157@jurassic.eng.sun.com> Date: Wed, 13 Jun 2001 11:32:08 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hGuKph9a6rDA8EY2MHG2Jw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, > > > see how there is any replication in the case where we have > > > an intelligent L2 that knows if a device has disconnected. > > > How can it send something to a "non-existent" device ? > > > > I wasn't saying that packets are replicated on the air. Packets are definitely > > replicated in the IP stack, right? This is bi-casting. Only after they are > > passed to L2, one copy might be dropped if this L2 knows MN is no longer > > attached. > > > > I don't want to replicate packets, if I know one copy is not needed at all. Why > > don't we communicate this "L2 not attached" information to where packets would > > have been replicated, stop bi-casting and forward packets to one place? > > > => That's clearly not free either as was discussed many times > in the DT. Apart from the complexity of implementing it > (we agree that there is complexity in implementing anything > really), there maybe delays in detecting the MN's detachment > on L2. This will add delays in packet forwarding. > > > > > > > > => I wasn't talking about the forwarding itself, I was referring > > > to these L2 triggers that will change the forwarding > > > tables. Which btw may not be secure in case your L2 > > > doesn't have the appropriate level of security, but that's > > > another point. > > > > Not trusting your L2... I'd say this is out of scope. > > > => Huh ? Not all L2s have a different security association > per device. > > > > > > > > If I have a L2 with this capability > > > > > > > => _what_if_you_don't ?? We design another solution ? > > > > > > > , while should I duplicate my traffic knowing > > > > that one would be dropped, whereas I can know exactly where to send it? It's > > not > > > > like bi-casting is for free. > > > > > > > => Nothing is free of course, but you're trying to have multiple > > > solutions where I want one. In this case the one I'm referring > > > to will have the exact same effect. So why are we trying to solve > > > the problem twice ? Seems wasteful to me. > > > > > > I agree that it's very desirable to have one solution that works in every case. > > But, we should also be aware of it's costs, and alternative solutions which are > > optimized in certain cases. > > > => Of course, but right now we don't have a soution after bicasting > was removed from the draft. We've been over this many times > now and we always discussed adding the _option_of bicasting. > It was never a MUST. > > > What I'm saying is, whenever available, connection-oriented L2 features should > > be used, instead of bi-casting. If this feature is not available, then something > > else can be used. > > > => Like bicasting ? another solution ? nothing is in the draft > right now. > > > I understand it's desirable to have one solution. But I clearly see a benefit to > > taking advantage of this L2 feature. Do you see any technical problems with this > > approach, other than it using a case-specific solution? > > > => Alper, if you want to implement this in your router no one > will / can stop you from doing so. But if you don't want to > or the solution won't work for you, then what do you do ? There are a number of solutions. Bi-cast, connection oriented L2, buffering. For some systems one is better, for other others. Sometimes you want to mix them. These are all implementation specific. I don't see a protocol work here. As I said before, implementors will make their choices. For the networks in your mind, maybe bi-casting is the only solution. Fine, they can use it. For others L2 signals might be sufficient. > > BTW, if we can rely on the method you mention here, > why did we have the NA message to inform the new > AR that the MN has appeared on link ? Because, as you'd agree, not all L2's have that capability. And as a protocol, we don't want to tie FMIPv6 to a specific L2. All I was saying was "when available", this L2 faeture can be used to replace functionality of bi-casting. Implementors can choose to use anything they like. > > Ping pong is not the only reason for using bicasting, > once you anticipate movement, you're ever 100 % sure > about the exact time at which you will lose L2 connectivity, > therefore packets will be lost in the mean time. > Basically, what I'm saying is, choice of smoothing technique is implementation/system specific, and not a part of the "protocol". Implementors can use FMIPv6 protocol with any of the available smoothing techniques, and be able to interoperate with others' products. alper From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 14:57:31 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29306 for ; Wed, 13 Jun 2001 14:57:30 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29937; Wed, 13 Jun 2001 11:56:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15994; Wed, 13 Jun 2001 11:53:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIqeWi016080 for ; Wed, 13 Jun 2001 11:52:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DIqeOM016079 for mobile-ip-dist; Wed, 13 Jun 2001 11:52:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DIqbWi016072 for ; Wed, 13 Jun 2001 11:52:37 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5DIqhG317874 for ; Wed, 13 Jun 2001 11:52:43 -0700 (PDT) Message-Id: <200106131852.f5DIqhG317874@jurassic.eng.sun.com> Date: Wed, 13 Jun 2001 11:52:43 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] Handover to Third? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9sapSz8txFGscnWj6tMM7g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > > I've been looking through the FMIPv6 draft again, and a question came up. > > It is possible that the MN may have some traffic on newAR required > to set up the newCoA. It may have to send an F-BU, and an > F-NA or NA. This is in addition to the BU to the HA or hierarchical agent, which > will require at least another radio link round trip, probably without full > header compression. So there is some amount of time on newAR during which the MN > is not in full possession of the newCoA, but is in the process of > establishing it. > > The question is, what happens if the MN moves to a third AR before > the process of establishing the newCoA is complete? > > For example, let's suppose the MN sends the F-BU while on the oldAR > but does not receive a reply before L2 handover to newAR happens. Suppose > further that the MN's location is at a place where three cells butt > up against each other, and that it quickly slips into a third cell at L2, > before the F-BACK arrives. Or suppose the MN is moving quickly through > a small sliver of a cell between two others. This problem is similar > to the ping-pong problem, but with a third cell. I think this is not a common case. Do you think this is a common enough case that this protocol should handle? We can think of other not so common cases like Wolfgang mentioned. MN moves so fast that nothing works. > > There are two issues here: > > 1) The newAR may not have enough time to complete the PrRtAdv/F-BU pair > that is required for network assisted handover over the air with MN prior to the > L2 handover to thirdAR, to say nothing of the RtSolPr/PrRtAdv/F-BU for mobile > assisted. The HI/HACK would probably work, since that is sent over > the backbone and should take no longer than 10 ms, if processing time > on thirdAR is low, and 10 ms is about 1/2 of a radio frame for typical 3G > radio link protocols. > > 2) The oldAR is now left thinking that MN has moved to newAR. It has > set up a bi-directional tunnel with newAR to assure that MN's packets > get to it, even if they have oCoA as the destination address. It attempts > to send the F-BACK to nCoA, but MN has moved and the F-BACK doesn't get > there, maybe oldAR gets an ICMP message to that effect. What should oldAR do? > How does it distinguish this case from one where the MN has moved and goes into > dormant mode or is lost? Should newAR set up a second tunnel to thirdAR? > > It seems to me like the draft needs to provide some solution for this > case, as well as for ping-ponging. In an unsual case like this, I personally don't expect this protocol to work, yet it shouldn't create new problems either. In this case, seeing that MN has attached to some link other than the one it told oldAR, MN can abort fast handoff, fall back to regular handoff, and send a BU to oldAR to clear things up. I wouldn't prefer extending (complicating) the protocol to handle this rare case. This is my presonal opinion. alper From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 15:01:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29417 for ; Wed, 13 Jun 2001 15:01:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03629; Wed, 13 Jun 2001 12:02:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17984; Wed, 13 Jun 2001 12:01:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ0mWi016144 for ; Wed, 13 Jun 2001 12:00:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DJ0mLH016143 for mobile-ip-dist; Wed, 13 Jun 2001 12:00:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ0iWi016136 for ; Wed, 13 Jun 2001 12:00:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17834 for ; Wed, 13 Jun 2001 12:00:51 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09535 for ; Wed, 13 Jun 2001 13:00:49 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 14:59:49 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile IPv4" Date: Wed, 13 Jun 2001 14:59:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0F43B.025EF800" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0F43B.025EF800 Content-Type: text/plain; charset="iso-8859-1" I have submitted a new internet-draft, please find it attached. I would like some feedback. It concerns the use of NAT boxes in Mobile IPv4. Now, currently, in the Mobile Telecommunications Industry, the UMTS architecture is slated to go "all-IP" based according to the R5 of 3GPP specs. The GPRS core network is to be connected to the Internet by a Transition Gateway (TrGw). Amongst other functions, the TrGw is expected to provide NAT functions. Thus, this I-D proposes a solution to the problem of mobility management with network address translation. ------_=_NextPart_000_01C0F43B.025EF800 Content-Type: text/plain; name="draft-shahrier-mobileip-nat-00.txt" Content-Disposition: attachment; filename="draft-shahrier-mobileip-nat-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft S. M. Shahrier = Document: draft-shahrier-mobileip-nat-00.txt InterDigital = Expires: 2001 May 2001 = =20 Incorporating NAT boxes in Mobile IPv4=20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsolete by other documents=20 at any time. It is inappropriate to use Internet-Drafts as=20 reference material or to cite them other than as "work in progress." = =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [1].=20 =20 Abstract=20 In this draft, we propose an Internet architecture consisting=20 of large number private networks, individually connected to the=20 Internet backbone via NAT-routers. Hosts within the same private=20 network can communicate with one another locally, and also with=20 hosts in other networks via the Internet backbone. The routers in=20 each private network maintain their own local routing state and=20 routers in the backbone maintain their own external routing state.=20 More specifically, the routers within a particular domain are not=20 cognizant of routes outside that domain. =20 =20 We suggest some modifications to the Basic Static NAT-routers to=20 implement mobility protocols for the cases where: (a) MHs are only=20 allowed to move about their own private network, (b) MHs are=20 allowed to move around from one private network to another. We=20 provide a description of the protocols.=20 =20 Shahrier Informational - Expires September 2001 1 = =0C Integrating Basic NAT with Mobile IP May 2001=20 =20 =20 1. Introduction=20 =20 In this draft, we propose an Internet architecture consisting=20 of a large number of private networks connected to the Internet=20 backbone via NAT-routers. Hosts in different private networks can=20 communicate with one another via the public Internet backbone. The=20 routers in each private network maintain all routes locally; hidden=20 from other private networks and the Internet. In other words, these=20 routers have no knowledge of routes outside of their private domain. = Likewise, the backbone (public) routers are not cognizant of the=20 routes to any local addresses.=20 =20 =20 ----------------------------------------------------=20 | | = =20 | INTERNET BACKBONE |=20 | |=20 ----------------------------------------------------=20 | | |=20 ----- ----- -----=20 | NAT | | NAT | | NAT | NAT-enabled =20 ----- ----- ----- routers=20 | | |=20 | | |=20 ----- ----- -----=20 | | | | | | =20 | PVT | | PVT | | PVT | Private =20 | NET | | NET | | NET | Networks=20 | | | | | |=20 ----- ----- -----=20 =20 Figure 1 Multiple Private Networks Connected by an Internet Backbone=20 =20 Traditionally, NAT-enabled routers [1,2] are used for connecting=20 private networks to the Internet. This was done to try and enhance=20 the use of the address space. The whole 24-bit address space has=20 been split up into a set of registered addresses and a set of=20 unregistered addresses, by IANA [3]. There is no overlap between the = private and public addresses, which means that the private networks = can use any any one of the unregistered addresses, without prior=20 approval fro IANA. The public or global addresses are unregistered=20 addresses, and without loss of generality, we assume that exactly=20 one address from this pool is assigned each NAT-router. =20 =20 In this draft, we suggest modifications to the NAT functions=20 described above to handle the cases where: (a) MHs are only allowed=20 to move around within its own private network, (b) MHs are allowed=20 to move from one private network to another. The rest of the=20 document is organized as follows: section 2 describes how the NAT is = implemented in a system consisting of a large number of private=20 networks, connected to an external backbone; section 3 describes the = Internet Draft - Expires November 2001 2=20 =0C Integrating Basic NAT with Mobile IP May 2001=20 =20 mobility management protocol where MHs are allowed to move around=20 within its own private network; section 4 describes modifications to = the NAT where MHs are allowed to move from one private network to=20 another. The document is concluded in section 5.=20 =20 2. Terminology=20 =20 The following list of terms are defined in this document:=20 =20 NAT Network Address Translation.=20 MH Mobile Host.=20 IANA Internet Assigned Numbers Authority.=20 COA Care of Address.=20 CN Corresponding Node.=20 =20 2. System Architecture=20 =20 This section describes how private networks are connected to an=20 external backbone via NAT-enabled routers. Using such a scheme, a=20 large number of private networks can be connected to the external=20 backbone. Hosts within different private networks can communicate=20 with each other via the backbone, using one of the registered=20 addresses assigned by IANA. Hosts within a private network can=20 communicate with one another using their unregistered addresses.=20 Thus, the registered addresses are globally unique, while=20 unregistered addresses have local significance only. The local=20 addresses and the global addresses are mutually exclusive. We=20 discuss next, the operation of the NAT.=20 =20 Consider networks A and B, connected to the Internet, via NAT=20 enabled routers NAT-A and NAT-B respectively. Suppose that a packet=20 was to be sent from A to B. Before data transfer can take place,=20 The NAT tables have to be set up, to reflect the correct binding=20 between the global address of NAT-A and the local address of the=20 sender in A; the global address of NAT-B and the local address of=20 the receiver in B. The exact method by which the tables are=20 configured is outside the scope of this document. The configuration=20 sets up the binding between MH_ in A and NAT-A, and similarly the MH = in B and NAT-B. This is illustrated as follows:=20 =20 Binding for NAT-A:=20 =20 ------------------------------------------------------=20 |Global address of NAT-A | Local address of sender in A|=20 ------------------------------------------------------=20 =20 Binding for NAT-B:=20 =20 --------------------------------------------------------=20 |Global address of NAT-B | Local address of receiver in B|=20 --------------------------------------------------------=20 =20 The procedure for sending out a packet is as follows. The packet is=20 encoded with the global address of NAT-A and the global address of=20 Internet Draft - Expires November 2001 3=20 =0C Integrating Basic NAT with Mobile IP May 2001=20 =20 NAT-B. The receiving NAT-B checks the binding in its table, and=20 retrieves the local address of the host. It replaces the global=20 destination field in the header with the local address of MH in B.=20 The packet is then forwarded to that host. The reverse set of=20 actions takes place whenever B sends to A.=20 =20 3. Mobility Management within a Private Network=20 =20 Suppose that the MH wishes to move about within its private network. = It sends a dbase-binding-update to the mobile-database. This message = informs the mobile-database, about is impending COA. The new COA is=20 registered, and a dbase-binding-acknowledgement is echoed back to=20 the MH. The format of each entry in the mobile-database is as=20 follows:=20 =20 ------------------------------------------------=20 |Local IP (home) | New Global IP | New Local IP |=20 | Address | Address | Address |=20 ------------------------------------------------=20 =20 The local IP address is the pre-assigned local IP address of the MH=20 in its private home network. Thus, if the mobile is currently within = its home network, then the =93New Global IP Address=94 field = contains=20 the network=92s global IP address after the mobile has moved to its=20 new COA. Similar explanation is given for the =93Current Local IP=20 Address=94 field. At the same time as sending dbase-binding-update,=20 the MH also sends a nat-binding-update to the NAT, where the NAT=20 checks it binding table to determine if it has a binding with the=20 MH. If it has a binding then the local address portion of the entry=20 is updated, to reflect the new address of the MH. If no binding=20 currently exists, then a new binding is created and placed in the=20 database. The format of a binding is as follows:=20 =20 --------------------------------------=20 | Global IP Address | New Local IP |=20 | Of NAT | Address |=20 --------------------------------------=20 =20 In the figure, the =93New Local IP Address=94 is the new local IP=20 address of the MH. The updating of the NAT binding is necessary so=20 that sessions coming into the private network from the outside can=20 be routed to the correct MH.=20 =20 The MH then waits for nat-binding-acknowledgement to also come back, = after which it moves to its new location. Thereafter, any CN that=20 wishes to communicate with the MH has to send a mobile-location- solicitation to the mobile-database. The mobile-database may be in=20 the current network, or in a different private network. The mobile- database searches the database to determine the current location of=20 the MH, and sends back a mobile-location-advertisement, indicating=20 the current location of the MN, in terms of both its global private=20 network address and the local IP address within that network. The CN = can start forwarding packets to the MN, thus bypassing the home=20 agent altogether.=20 Internet Draft - Expires November 2001 4=20 =0C Integrating Basic NAT with Mobile IP May 2001=20 =20 =20 If the MH is receiving traffic from a source, it has to notify the=20 source of its intended move, so that it can redirect its flow to the = new COA. To accomplish this, the MH sends both its new global IP=20 address and its local IP address to the sender using the move-new- location message. The source responds back with move-new- acknowledgement message and redirects its flow. Some buffering has=20 to be provided so that no packets =93in flight=94 are lost while the = MH=20 is performing the handover. This is an important subject matter, but = lies outside the scope of this draft.=20 =20 4. Mobility Management Across Multiple Private Networks=20 =20 A MH may leave its =93private home network=94 and enter a different=20 private network, called a =93private foreign network=94. If this = occurs,=20 the MH sends a registration message, called mobile-registration.=20 This message indicates the MH=92s =93home network=94 global address, = its=20 local (assigned) address in its home network, the MH=92s foreign=20 network global address, its local address in its foreign network.=20 Thus, these four elements make up the registration message. The = MH=92s=20 private network NAT-router intercepts this message, and updates its=20 mobile-database to reflect the new global and local address of the=20 MH in the foreign network. In addition to this task, the foreign NAT = must also form a binding for the MH based on the current local=20 address of the MH in the foreign network. This binding is entered=20 into the table described previously. These steps are also suffice=20 when the MH moves from a =93private foreign network=94 back into its = =93private home network=94.=20 =20 Next, let=92s consider how packets are sent from the CN to the MH.=20 Before a packet can be sent, an enquiry is made to the MH=92s home=20 network, to be ascertain of its current location. For this, a=20 mobile-solicitation message is sent to the mobile=92s private home=20 network containing the local IP address of the MH in its home=20 network. The NAT-router performs a look-up into its table using the=20 IP address as an index and responds back with a mobile-advertisement = message, specifying the current location of the MH, in terms of its=20 current network IP address and its current local IP address.=20 Thereafter, when CN sends a packet to the MH, it inserts this=20 current global network IP address into the destination field. It=20 inserts its own network=92s global address into the source field. =20 =20 Next, we consider a situation where the MH moves to a different=20 private network while it was still receiving traffic from a CN.=20 Thus, in order for the operation to be seamless, in addition to=20 complying with all the protocol steps described above, it must=20 notify the source of the flow, and receive acknowledgement back from = the source, before it moves to its new location. It sends the=20 message move-location message to the source, indicating the global=20 IP address of its new private network and its local IP address=20 within that network. This will subsequently allow the CN to redirect = its flow to the new location. If the MH is in a foreign network,=20 this message is also sent to the MH=92s home network in order to=20 update its mobile-database. A nat-binding-update is also sent to the = Internet Draft - Expires November 2001 5=20 =0C Integrating Basic NAT with Mobile IP May 2001=20 =20 NAT, in order to update the current binding. In both cases, the MH=20 must wait to receive back a move-location-acknowledgement and nat- binding-acknowledgement, before it can move to its new location.=20 =20 5. References=20 =20 [1] T. Hain,=94Architectural Implications of NAT=94, RFC 2993.=20 =20 [2] P. Srisuresh and M. Holdrege,=94IP Network Address Translator =20 (NAT) Terminology and Consideratons=94, RFC 2663.=20 [3] Y. Rekhter et. al.,=94Address Allocation for Private = Internets=94,=20 RFC 1918.=20 =20 Sharif M. Shahrier=20 InterDigital =20 781 Third Ave. Phone: 1-610-337-4343=20 King of Prussia, PA. USA Email: sharif.shahrier@interdigital.com = =20 =20 Internet Draft - Expires November 2001 6=20 =0C ------_=_NextPart_000_01C0F43B.025EF800-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 15:02:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29428 for ; Wed, 13 Jun 2001 15:02:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03391; Wed, 13 Jun 2001 12:01:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17964; Wed, 13 Jun 2001 12:01:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ0dWi016134 for ; Wed, 13 Jun 2001 12:00:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DJ0dCd016133 for mobile-ip-dist; Wed, 13 Jun 2001 12:00:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ0aWi016126 for ; Wed, 13 Jun 2001 12:00:36 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5DJ0gG319372 for ; Wed, 13 Jun 2001 12:00:42 -0700 (PDT) Message-Id: <200106131900.f5DJ0gG319372@jurassic.eng.sun.com> Date: Wed, 13 Jun 2001 12:00:42 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: aqkMm2ayfSqFjM/sRIiiaw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jim, > >If there's a possibility that MN might successfully attach to new link, before > >oldAR recevies a L2 detach notice, only then it makes sense to bi-cast until L2 > >detach signal. If we certainly know MN cannot attach to new link until oldAR > >receives the L2 detach notice, then I still don't see why we should bi-cast. If > >this is the uncertainity you are talking about, it'd make more sense, yet I > >don't know how big are the savings here. [depends on system, implementation, > >etc..] > > > > You are talkng about make before break, and this is not typically the > kind of handoff where MIP would come into play. MIP would only come > into play when the connection with the old access point is broken, > at L3, before it comes up on the new. I didn't mean make-before-break. I'm just trying to understand where the uncertanity is. > > But I'm curious why you feel that a make before break handoff would > be the only case that would benefit from bicasting. To me, it is > the other way around. The reason is because the MN breaks the > old L2 before the new L2 is solid enough for L3 traffic. Typically, > there is some short period of time when the MN and new AP exchange traffic > to be sure the connection is solid, before L3 traffic resumes. Since > the exact duration of this time period is uncertain and when the > old L2 is broken, it makes sense to send the MN's traffic to newAR before there > is a break in the old L2, to make sure the MN doesn't miss anything. Or? OK, that makes sense. > >That makes sense. Depending on the system, people can implement these different > >handoff smoothing techniques. I don't think these require a protocol > >specification. IMHO, these are implementation decisions. > > > > I think there are interoperability considerations, and to the extent > there are, it should be specified. Suppose I connect a Nokia router > and a Motorola router, and one does smoothing as I outline and the > other doesn't? > And you get partial smoothing (lose some packets), and that's fine. That was apparently implementors or administrator's choice. Or your choice when you signed up for that service :) alper From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 15:03:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29475 for ; Wed, 13 Jun 2001 15:03:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04421; Wed, 13 Jun 2001 12:03:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18370; Wed, 13 Jun 2001 12:03:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ28Wi016171 for ; Wed, 13 Jun 2001 12:02:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DJ283D016170 for mobile-ip-dist; Wed, 13 Jun 2001 12:02:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ24Wi016163 for ; Wed, 13 Jun 2001 12:02:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27675 for ; Wed, 13 Jun 2001 12:02:11 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09386 for ; Wed, 13 Jun 2001 12:02:10 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5DJ0Bp12824 for ; Wed, 13 Jun 2001 12:00:11 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5DJ2AI04123 for ; Wed, 13 Jun 2001 12:02:10 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A6A.00687E24 ; Wed, 13 Jun 2001 12:01:20 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A6A.00687538.00@hqoutbound.ops.3com.com> Date: Wed, 13 Jun 2001 12:01:20 -0700 Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: As in the draft and this thread, I like to point out that Link layer address based verification across ARs should be avoided as much as possible. MN can have two interfaces and also move from one AR to another AR using the new L2 interface. If we want L2 identifier then there should be a way that MN can indicate to the old AR about the new Link layer ID that it will be using plus the current L2 ID. Barani. From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 15:43:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00172 for ; Wed, 13 Jun 2001 15:43:13 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14799; Wed, 13 Jun 2001 13:43:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07127; Wed, 13 Jun 2001 12:43:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJfeWi016311 for ; Wed, 13 Jun 2001 12:41:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DJfdvC016310 for mobile-ip-dist; Wed, 13 Jun 2001 12:41:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJfaWi016303 for ; Wed, 13 Jun 2001 12:41:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06920 for ; Wed, 13 Jun 2001 12:41:43 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11809 for ; Wed, 13 Jun 2001 13:42:21 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 15:40:41 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Internet Draft "Low Overhead Mobility Management Protocol in IP L ayer" Date: Wed, 13 Jun 2001 15:40:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0F440.B6C25FD0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0F440.B6C25FD0 Content-Type: text/plain; charset="iso-8859-1" Please find attached a new internet draft submission "Low Overhead Mobility Management Protocol in IP Layer". This proposes a low-overhead version of Mobile IPv6 protocol, more suitable for mobility management over the air-interface. I would appreciate som comments. -Sharif <> ------_=_NextPart_000_01C0F440.B6C25FD0 Content-Type: text/plain; name="draft-shahrier-mobileip-mmp-00.txt" Content-Disposition: attachment; filename="draft-shahrier-mobileip-mmp-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft S. M. Shahrier = Document: draft-shahrier-mobileip-mmp-00.txt InterDigital = Expires: 2001 May 2001 = =20 =20 A Low-Overhead Mobility Management Protocol in IP Layer =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that = =20 other groups may also distribute working documents as Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six months=20 and may be updated, replaced, or obsolete by other documents at any=20 time. It is inappropriate to use Internet-Drafts as reference material = or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [1].=20 =20 Abstract=20 =20 The Future Mobile Internet has to support many types of traffic =20 flows, including both real-time and non real-time=20 services. In addition, the network has to keep account of the=20 location of each mobile node (MN) as it moves around the network.=20 This draft proposes a novel protocol that combines mobility=20 management with optimal routing for use over the mobile air=20 interface. Its advantages is that it eliminates the need for IP-in- IP encapsulation from CN to MN, and still including the identity of=20 the original CN in the IP datagram; eliminating any form of=20 tunneling of packets to the MN by the CN, while the MN is away from=20 its home. The elimination of these two overheads make it amenable=20 for over the air interface communication in 3G Mobile IP networks.=20 =20 1. Introduction=20 =20 The Mobile Internet of the future are expected to be capable of a=20 high rate of data transmission. The traffic services=20 =20 Shahrier Standard Track - Expires July 2001 1 = =0C A Optimal Mobility Management Protocol May 2001=20 for 3G Wireless Internet=20 =20 supported include real-time such as video and voice and non real- time such as data. Each service will have different QoS require- ments, delay and throughput guarantees and bit-error rates (BER). =20 =20 In a mobile network, each mobile node (MN) is in communication with=20 a single access point(AP). This situation represents a single point=20 of attachment of the MN to the internet, This draft proposes a=20 method of managing the mobility of a MN within multiple=20 administrative domains. In the past, mobility management schemes=20 within the IP-layer used a two-level hierarchical approach; Mobile=20 IP [2] was generally used for managing mobility across different=20 sub-networks; authors have proposed different solutions for managing = micro-mobility within a single sub-network [3,4,5]. In this draft,=20 we propose a scheme by which to manage the mobility of a MN across=20 all administrative domains. The protocol also supports optimal=20 routing using OSPF.=20 =20 2. Improvements=20 =20 The new protocol proposes some improvements over existing mobility=20 management protocols, in particular Mobile IP [1].=20 =20 - It eliminates the need for Ip-in-IP encapsulation from CN to=20 MN, and still including the identity of the original CN in=20 the IP datagram.=20 =20 - Optimizes routing from sender to receiver, using OSPF, i.e.=20 No need to tunnel via the HA as in Mobile IP.=20 =20 Although this protocol is proposed for both wireless and wireline=20 networks, the elimination of these two overheads make it amenable=20 for over the air interface communication in 3G Mobile IP networks.=20 =20 =20 3. Reference Architecture=20 =20 Fig. 1. depicts the architecture and topology of a typical mobile = =20 network. This architecture has been adapted from [2]. Associated=20 with the diagram are terminology and definitions.=20 =20 Mobile Node (MN)=20 An IP mobile terminal capable of changing its point of=20 attachment to the internet.=20 =20 Access Point (AP)=20 Access point offering a wireless air-interface connection to=20 the MN. =20 =20 Access Router (AR)=20 IP router connected to one or more AP's. Each AP represents a = =20 single IP address.=20 =20 =20 Shahrier Standard Track - Expires July 2001 2=20 =0C A Optimal Mobility Management Protocol May 2001=20 for 3G Wireless Internet=20 =20 Access Network Gateway (ANG)=20 An IP gateway that connects the sub-networks to the internet=20 backbone. A combination of ARs connected to the same ANG belong = to the same sub-network. Conversely, ARs connected to different = ANG=92s are part of different sub-networks.=20 =20 =20 INTERNET=20 BACKBONE=20 |=20 |=20 --- --- --- |=20 | | | | | | |=20 | MN|-----| AP|-----------| AR|-- |=20 --- --- --- | | =20 | --- |=20 --| | |=20 --|ANG|-----|=20 | --- |=20 | |=20 --- --- --- | |=20 | | | | | |-- |=20 | MN|+++++| AP|-----------| AR| |=20 --- + --- --- |=20 + |=20 + |=20 --- + |=20 | |++ |=20 | MN| |=20 --- |=20 | =20 |=20 |=20 |=20 --- --- --- --- |=20 | | | | | | | | |=20 | MN|+++++++| AP|----------| AR|-----|ANG|----|=20 --- + --- --- --- |=20 + |=20 + |=20 + |=20 --- + |=20 | |+++ |=20 | MN| |=20 --- |=20 +++ air-interface connection. |=20 --- wireline-link connection. |=20 =20 =20 Fig. 1. Architecture of a Mobile IP Core Network.=20 =20 =20 Shahrier Standard Track - Expires July 2001 3=20 =0C A Optimal Mobility Management Protocol May 2001=20 for 3G Wireless Internet=20 =20 =20 Each MN is pre-designated to a single sub-network called its ``home=20 network''. Each home network is identified by an identifier called=20 the home network identifier (HNI). Within its home network, the MN=20 is connected to an access point called ``home AP=92=92, which in = turn is=20 connected to a router called ``home AR=92=92. Every AR has a unique = IP=20 address, so that the link between a MN and its home AR represents a=20 single connection point to the internet. Every MN in the network is=20 assigned a fixed value called its host-name, and it does not change=20 as the MN moves around the MCN. In particular, whenever any MN=20 connected to the AR queries the DNS server with its =20 pair, the DNS returns with the IP address of the home AR. =20 =20 Sending TCP/IP packets accomplishes the transmission of data packets = from source to target. The DESTINATION IP ADDRESS in the IP header=20 is used to route the packet to the target AR. The AR then broadcasts = it to all the AP=92s attached to it. The TCP ``destination port=20 number=92=92 field contains the host-name of the target MN. Each AP=20 registers the host-names of the MNs that are currently attached to=20 it. Thus, if it receives a packet whose port number (host-name)=20 matches one of its registered host-names, then the packet is=20 transmitted through the air-interface to that MN; otherwise the=20 packet is silently discarded.=20 =20 4. Protocol Description=20 =20 This section describes our proposed mobility management protocol for = mobile nodes migrating around a mobile core network. This protocol=20 is suitable for MNs moving within a single sub-network or across=20 multiple sub-networks. The description of the protocol is as=20 follows.=20 =20 Our protocol is fundamentally different from [2] in that instead of=20 forwarding IP datagrams from one peer to another peer via a foreign=20 agent (FA), the source is advised of the target's new location,=20 everytime it moves to a new AR. If the mobile moves to a new AP, but = it is still attached to the same BR, it means that the IP address of = the attached BR has not changed. Conversely, if MH becomes attached=20 to a different BR, the IP address had changed to indicate a new=20 route. =20 =20 4.1 Locating Target MN=20 =20 During the normal course of operation, mobile nodes may move=20 throughout the mobile core network. Thus, to assist with locating=20 the MN at any instant of time, each AR maintains a directory, called = the ``Node Location Table'' (NLT). The NLT contains a listing of=20 the node-names of all the MNs for which this AR is a home AR, and=20 their current locations. If the MN is at its home AR, then the IP=20 address is that of its home AR. However, if the mobile has moved=20 away from its home AR, then the IP address is that of a foreign AR. = =20 =20 Shahrier Standard Track - Expires July 2001 4=20 =0C A Optimal Mobility Management Protocol May 2001=20 for 3G Wireless Internet=20 =20 ---------------------------=20 | node-name-1 | ip-addr-1 |=20 ---------------------------=20 | node-name-2 | ip-addr-2 |=20 ---------------------------=20 | node-name-3 | ip-addr-3 |=20 ---------------------------=20 | =85=85=85=85=85=85=85=85 | = =85=85=85=85=85=85=85=85 |=20 ---------------------------=20 =20 Before IP datagrams can be sent to the target MN, a TCP connection=20 has to be established between the AR of the corresponding node (CN)=20 and the AR of the target. Before such an event, the source has to=20 ascertain itself of the target mobile's current location. This can be accomplished by exchanging a pair of ICMP messages between the=20 peers. =20 =20 1. The CN indexes into the NLT using the node-name of the = target,=20 and retrieves its current ip-addr. This is the DESTINATION IP=20 ADDRESS.=20 =20 2. The CN constructs an ICMP node location query message, with=20 the following field settings:=20 =20 TYPE =3D 20. Node location query.=20 IDENTIFIER =3D node-name. Node-name of target MN.=20 3. The rest of the fields are filled in and the resulting ICMP=20 message is placed in the DATA_AREA of the IP datagram frame.=20 =20 4. In the IP header, SOURCE IP ADDRESS and DESTINATION IP = ADDRESS=20 are placed into their respective fields. =20 =20 5. The resulting IP datagram is sent to the target=92s home AR.=20 =20 6. Target AR uses the node-name, indexes into the NLT, and=20 retrieves MN=92s current IP address.=20 =20 7. The AR constructs a new ICMP message and sends it back to the = CN. This message is called a node query reply message.=20 =20 TYPE =3D 21. Node location query reply.=20 OPTIONAL DATA =3D ip-addr. IP address of home/foreign = AR.=20 =20 8.The rest of the fields are filled in and the resulting ICMP =20 message is placed in the DATA AREA of the IP datagram frame.=20 =20 9.The SOURCE IP ADDRESS and DESTINATION IP ADDRESS fields are=20 reversed, and placed into their respective fields.=20 =20 10. The resulting IP datagram is sent to the CN=92s home AR. = =20 =20 =20 Shahrier Standard Track - Expires July 2001 5=20 =0C A Optimal Mobility Management Protocol May 2001=20 for 3G Wireless Internet=20 =20 The message format of the ICMP header is as follows:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |TYPE(20 or 21) | CODE | CHECKSUM | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | IDENTIFIER | SEQUENCE NUMBER | = =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | OPTIONAL DATA |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | | =20 =20 =20 The exchange of control messages between the CN and the home BR, and = the transmission of data from source to target are indicated in the=20 following signaling diagram.=20 =20 SENDER RECEIVER=20 | |=20 | ICMP |=20 |----------->|=20 | |=20 | ICMP |=20 |<-----------| =20 | |=20 | IP |=20 |----------->|=20 | |=20 | IP |=20 |----------->|=20 | |=20 | IP |=20 |----------->|=20 | |=20 =20 The process initiated by the sender and receiver peers exchanging a=20 pair of ICMP messages to determine the IP address of the AR=20 associated with the MN. Once the IP address is known a TCP=20 connection is established between the sender and receiver and the=20 data transfer takes place.=20 =20 4.2 Locating Target MN After Handoff=20 =20 Next, we consider what happens if a receiver MN handoffs to a new=20 AP, while it is still communicating with the CN. The CN will have=20 to be notified of the new location of the MN, so that it can still = continue to receive data seamlessly. If, after the handover, the=20 new AP is still connected to the same AR, i.e. the IP address=20 hasn=92t changed; then the connection can continue to proceed as=20 normal. If, on the other hand, the MN moves to a different AR,=20 i.e. the IP address has changed; the CN will need to be notified=20 =20 Shahrier Standard Track - Expires July 2001 6=20 =0C A Optimal Mobility Management Protocol May 2001=20 for 3G Wireless Internet=20 =20 of the new IP address. Thereafter, these aforementioned sources=20 must re-direct their traffic flows. The MN sends the following UDP = message back to the CN and the home BR. The home BR updates its=20 HLR accordingly:=20 =20 1. In the UDP header, the SOURCE PORT and the DESTINATION PORT=20 fields are replaced by the host-name of the MN and the target=20 respectively. =20 =20 2. The new IP address is placed in the data section of the UDP =20 header. The UDP MESSAGE LENGTH is set to 12 bytes because it is = =20 3 words long.=20 =20 3. The entire UDP packet is encapsulated into an IP datagram. The=20 SOURCE IP ADDRESS and DESTINATION IP ADDRESS are placed into =20 their respective fields in the IP header. These IP addresses =20 are obtained from the DNS using the respective =20 pairs.=20 =20 4. The IP datagram is sent back to the target, either being the CN = =20 or the home BR.=20 =20 The format of the UDP packet is as follows:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | SOURCE HOST-NAME | DESTINATION HOST-NAME | = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | UDP MESSAGE LENGTH(12) | UDP CHECKSUM | = =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | TARGET IP ADDRESS |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | | =20 =20 5. References=20 =20 [1] C. Perkins et. al.,=94IP Mobility Support=94, FC 2002.=20 =20 [2] Design Team =94Problem Statement: Reasons for Doing Context = Transfers =20 Between Mobile Nodes in IP Mobile Networks=94, Internet-Draft.=20 =20 =20 =20 Author's Addresses=20 =20 Sharif M. Shahrier=20 InterDigital =20 781 Third Ave. Phone: 1-610-337-4343=20 King of Prussia, PA. USA Email: sharif.shahrier@interdigital.com = =20 Shahrier Standard Track - Expires July 2001 7=20 =0C ------_=_NextPart_000_01C0F440.B6C25FD0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 17:18:18 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01814 for ; Wed, 13 Jun 2001 17:18:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10343; Wed, 13 Jun 2001 14:18:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18137; Wed, 13 Jun 2001 14:18:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DLHAWi016408 for ; Wed, 13 Jun 2001 14:17:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DLHAXM016407 for mobile-ip-dist; Wed, 13 Jun 2001 14:17:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DLH6Wi016400 for ; Wed, 13 Jun 2001 14:17:06 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12925 for ; Wed, 13 Jun 2001 14:17:15 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20443 for ; Wed, 13 Jun 2001 14:17:14 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id QAA05565 for ; Wed, 13 Jun 2001 16:17:14 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5DLHDp07808 for ; Wed, 13 Jun 2001 16:17:13 -0500 (CDT) Message-ID: <3B27D857.E68A4293@usa.alcatel.com> Date: Wed, 13 Jun 2001 16:17:12 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Use of Routing Header in MIpv6 References: <3B122BB0.E1DADB5@netas.com.tr> <3B122E38.AFAF5EE2@inrialpes.fr> <004e01c0e94a$ed7e1a10$50fba78f@borg> <3B1E2639.7B2EF46C@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit When a CN talks to a MN ,it uses routing header to notify MN that it is using optimized route.But, routing-header in Ipv6 is used to specify one or more intermediate nodes that should be visited on the route to the destination. My question is "why is routing header used here?" how is the routing-header processed at CN before sending it to MN? What exactly is mentioned in this routing header? Thanks in advance Sridhar From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 17:18:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01826 for ; Wed, 13 Jun 2001 17:18:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10472; Wed, 13 Jun 2001 14:18:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18276; Wed, 13 Jun 2001 14:18:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DLHZWi016418 for ; Wed, 13 Jun 2001 14:17:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DLHZnm016417 for mobile-ip-dist; Wed, 13 Jun 2001 14:17:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DLHVWi016410 for ; Wed, 13 Jun 2001 14:17:31 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA19399 for ; Wed, 13 Jun 2001 14:17:39 -0700 (PDT) Message-Id: <200106132117.OAA19399@heliopolis.eng.sun.com> Date: Wed, 13 Jun 2001 14:17:39 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover to Third? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SDaO0rJmso6pcSWjmMUkvQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, I don't know how common the case is, but it is explicitly handled in IS-41, as I mentioned in response to Wolfgang's note. We cannot seriously offer IP as an alternative to the existing cellular protocols unless we fix this. jak >Date: Wed, 13 Jun 2001 11:52:43 -0700 (PDT) >From: Alper Yegin >Subject: Re: [mobile-ip] Handover to Third? >To: mobile-ip@sunroof.eng.sun.com >Content-MD5: 9sapSz8txFGscnWj6tMM7g== > >Jim, > >> >> I've been looking through the FMIPv6 draft again, and a question came up. >> >> It is possible that the MN may have some traffic on newAR required >> to set up the newCoA. It may have to send an F-BU, and an >> F-NA or NA. This is in addition to the BU to the HA or hierarchical agent, >which >> will require at least another radio link round trip, probably without full >> header compression. So there is some amount of time on newAR during which the >MN >> is not in full possession of the newCoA, but is in the process of >> establishing it. >> >> The question is, what happens if the MN moves to a third AR before >> the process of establishing the newCoA is complete? >> >> For example, let's suppose the MN sends the F-BU while on the oldAR >> but does not receive a reply before L2 handover to newAR happens. Suppose >> further that the MN's location is at a place where three cells butt >> up against each other, and that it quickly slips into a third cell at L2, >> before the F-BACK arrives. Or suppose the MN is moving quickly through >> a small sliver of a cell between two others. This problem is similar >> to the ping-pong problem, but with a third cell. > >I think this is not a common case. Do you think this is a common enough case >that this protocol should handle? > >We can think of other not so common cases like Wolfgang mentioned. MN moves so >fast that nothing works. > > >> >> There are two issues here: >> >> 1) The newAR may not have enough time to complete the PrRtAdv/F-BU pair >> that is required for network assisted handover over the air with MN prior to >the >> L2 handover to thirdAR, to say nothing of the RtSolPr/PrRtAdv/F-BU for mobile >> assisted. The HI/HACK would probably work, since that is sent over >> the backbone and should take no longer than 10 ms, if processing time >> on thirdAR is low, and 10 ms is about 1/2 of a radio frame for typical 3G >> radio link protocols. >> >> 2) The oldAR is now left thinking that MN has moved to newAR. It has >> set up a bi-directional tunnel with newAR to assure that MN's packets >> get to it, even if they have oCoA as the destination address. It attempts >> to send the F-BACK to nCoA, but MN has moved and the F-BACK doesn't get >> there, maybe oldAR gets an ICMP message to that effect. What should oldAR do? >> How does it distinguish this case from one where the MN has moved and goes >into >> dormant mode or is lost? Should newAR set up a second tunnel to thirdAR? >> >> It seems to me like the draft needs to provide some solution for this >> case, as well as for ping-ponging. > > >In an unsual case like this, I personally don't expect this protocol to work, >yet it shouldn't create new problems either. In this case, seeing that MN has >attached to some link other than the one it told oldAR, MN can abort fast >handoff, fall back to regular handoff, and send a BU to oldAR to clear things >up. > >I wouldn't prefer extending (complicating) the protocol to handle this rare >case. This is my presonal opinion. > > >alper > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 13 20:58:54 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04066 for ; Wed, 13 Jun 2001 20:58:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05440; Wed, 13 Jun 2001 17:59:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00044; Wed, 13 Jun 2001 17:59:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5E0w2Wi016714 for ; Wed, 13 Jun 2001 17:58:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5E0w1CY016713 for mobile-ip-dist; Wed, 13 Jun 2001 17:58:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5E0vwWi016706 for ; Wed, 13 Jun 2001 17:57:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17384 for ; Wed, 13 Jun 2001 17:58:06 -0700 (PDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29779 for ; Wed, 13 Jun 2001 18:58:04 -0600 (MDT) Received: from cwc-ibxus8n62wn.cwc.nus.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.10.0/8.10.0) with ESMTP id f5E0vu515375 for ; Thu, 14 Jun 2001 08:57:56 +0800 (SST) Message-Id: <5.1.0.14.2.20010614085549.00a93b48@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Jun 2001 09:03:37 +0800 To: mobile-ip@sunroof.eng.sun.com From: Charles Qi Shen Subject: Re: [mobile-ip] Archive of the list In-Reply-To: <3B277777.E9A5070A@crm.mot.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Currently the lifix.fi link below archives up to May only, a most updated archive link is available in every message of this Mailing list: http://playground.sun.com/mobile-ip/ Best regards, Charles At 04:23 PM 6/13/2001 +0200, you wrote: >Hi, > >You may want to try this >http://www.lifix.fi/extarchive/mobile-ip/ > > >Have a nice day. > >Damien > >Lars Henrik Petander wrote: > > > > Hi, > > > > I noticed that the list archive at Nortel's site is not up to date anymore > > (February is the last month covered in the archive). Is there a more > > current archive available somewhere? > > > > Thanks, > > > > Henrik Petander Charles Qi Shen Centre for Wireless Communications National University of Singapore 20 Science Park Rd. #02-34/37, TeleTech Park Singapore Science Park II, Singapore 117674 Tel: +65 870-9358 Fax: +65 779-5441 Email: shenqi@cwc.nus.edu.sg URL: http://www.cwc.nus.edu.sg From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 05:34:36 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23990 for ; Thu, 14 Jun 2001 05:34:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16139; Thu, 14 Jun 2001 03:34:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29368; Thu, 14 Jun 2001 02:34:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5E9XwWi017136 for ; Thu, 14 Jun 2001 02:33:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5E9XwFK017135 for mobile-ip-dist; Thu, 14 Jun 2001 02:33:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5E9XtWi017128 for ; Thu, 14 Jun 2001 02:33:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00601 for ; Thu, 14 Jun 2001 02:34:04 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11155 for ; Thu, 14 Jun 2001 03:34:44 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5E9Y1N14784 for ; Thu, 14 Jun 2001 11:34:01 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Jun 14 11:33:45 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 11:28:16 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF29@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Thu, 14 Jun 2001 11:33:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > > Ping pong is not the only reason for using bicasting, > > once you anticipate movement, you're ever 100 % sure > > about the exact time at which you will lose L2 connectivity, > > therefore packets will be lost in the mean time. > > > > Basically, what I'm saying is, choice of smoothing technique is > implementation/system specific, and not a part of the "protocol". Implementors > can use FMIPv6 protocol with any of the available smoothing techniques, and be > able to interoperate with others' products. > => Not quite, that maybe true in the network determined case where the MN does not send a BU to the old AR. If the MN sends a BU then it MUST be able to request bicasting for a number of reasons: 1. BU list management in terms of lifetimes 2. In some cases (different access technologies) the MN doesn't need to request bicasting at all. The AR won't have that knowledge and therefore the best place to have the request is the BU. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 07:12:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24964 for ; Thu, 14 Jun 2001 07:12:19 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10786; Thu, 14 Jun 2001 05:11:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07436; Thu, 14 Jun 2001 04:09:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EB8MWi017220 for ; Thu, 14 Jun 2001 04:08:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EB8LNj017219 for mobile-ip-dist; Thu, 14 Jun 2001 04:08:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EB8HWi017212 for ; Thu, 14 Jun 2001 04:08:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07308 for ; Thu, 14 Jun 2001 04:08:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA22304 for ; Thu, 14 Jun 2001 05:09:03 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24622; Thu, 14 Jun 2001 07:07:50 -0400 (EDT) Message-Id: <200106141107.HAA24622@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Date: Thu, 14 Jun 2001 07:07:50 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Incorporating NAT boxes in Mobile IPv4 Author(s) : S. Shahrier Filename : draft-shahrier-mobileip-nat-00.txt Pages : 6 Date : 13-Jun-01 In this draft, we propose an Internet architecture consisting of large number private networks, individually connected to the Internet backbone via NAT-routers. Hosts within the same private network can communicate with one another locally, and also with hosts in other networks via the Internet backbone. The routers in each private network maintain their own local routing state and routers in the backbone maintain their own external routing state. More specifically, the routers within a particular domain are not cognizant of routes outside that domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shahrier-mobileip-nat-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shahrier-mobileip-nat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shahrier-mobileip-nat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010613125912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shahrier-mobileip-nat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shahrier-mobileip-nat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010613125912.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 07:13:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24977 for ; Thu, 14 Jun 2001 07:13:13 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11645; Thu, 14 Jun 2001 05:12:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07581; Thu, 14 Jun 2001 04:11:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EBAOWi017240 for ; Thu, 14 Jun 2001 04:10:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EBAOdV017239 for mobile-ip-dist; Thu, 14 Jun 2001 04:10:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EBAJWi017229 for ; Thu, 14 Jun 2001 04:10:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05934 for ; Thu, 14 Jun 2001 04:10:26 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24774 for ; Thu, 14 Jun 2001 04:10:25 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24895; Thu, 14 Jun 2001 07:09:46 -0400 (EDT) Message-Id: <200106141109.HAA24895@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: seamoby@cdma-2000.org, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-mmp-00.txt Date: Thu, 14 Jun 2001 07:09:46 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Low-Overhead Mobility Management Protocol in IP Layer Author(s) : S. Shahrier Filename : draft-shahrier-mobileip-mmp-00.txt Pages : 7 Date : 13-Jun-01 The Future Mobile Internet has to support many types of traffic flows, including both real-time and non real-time services. In addition, the network has to keep account of the location of each mobile node (MN) as it moves around the network. This draft proposes a novel protocol that combines mobility management with optimal routing for use over the mobile air interface. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-shahrier-mobileip-mmp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-shahrier-mobileip-mmp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-shahrier-mobileip-mmp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010613133741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-shahrier-mobileip-mmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-shahrier-mobileip-mmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010613133741.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 09:48:12 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29248 for ; Thu, 14 Jun 2001 09:48:11 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21381; Thu, 14 Jun 2001 06:48:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20464; Thu, 14 Jun 2001 06:46:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EDj4Wi017656 for ; Thu, 14 Jun 2001 06:45:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EDj4Kc017655 for mobile-ip-dist; Thu, 14 Jun 2001 06:45:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EDj0Wi017648 for ; Thu, 14 Jun 2001 06:45:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05552 for ; Thu, 14 Jun 2001 06:45:08 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20375 for ; Thu, 14 Jun 2001 06:45:07 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 09:45:05 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Date: Thu, 14 Jun 2001 09:45:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Where can one find a description of the Transition Gateway function you mention? > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Wednesday, June 13, 2001 3:00 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile > IPv4" > > > I have submitted a new internet-draft, please find it > attached. I would like > some feedback. It concerns the use of NAT boxes in Mobile IPv4. Now, > currently, in the Mobile Telecommunications Industry, the > UMTS architecture > is slated to go "all-IP" based according to the R5 of 3GPP > specs. The GPRS > core network is to be connected to the Internet by a > Transition Gateway > (TrGw). Amongst other functions, the TrGw is expected to provide NAT > functions. Thus, this I-D proposes a solution to the problem > of mobility > management with network address translation. > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 09:55:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29499 for ; Thu, 14 Jun 2001 09:55:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24017; Thu, 14 Jun 2001 06:55:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19680; Thu, 14 Jun 2001 06:54:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EDrVWi017691 for ; Thu, 14 Jun 2001 06:53:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EDrVBf017690 for mobile-ip-dist; Thu, 14 Jun 2001 06:53:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EDrSWi017683 for ; Thu, 14 Jun 2001 06:53:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03493 for ; Thu, 14 Jun 2001 06:53:36 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16068 for ; Thu, 14 Jun 2001 07:54:17 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 09:52:34 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Date: Thu, 14 Jun 2001 09:52:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is in the document 3GPP TS 23.221. Look at www.3gpp.org Sharif -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Thursday, June 14, 2001 9:45 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Where can one find a description of the Transition Gateway function you mention? > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Wednesday, June 13, 2001 3:00 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile > IPv4" > > > I have submitted a new internet-draft, please find it > attached. I would like > some feedback. It concerns the use of NAT boxes in Mobile IPv4. Now, > currently, in the Mobile Telecommunications Industry, the > UMTS architecture > is slated to go "all-IP" based according to the R5 of 3GPP > specs. The GPRS > core network is to be connected to the Internet by a > Transition Gateway > (TrGw). Amongst other functions, the TrGw is expected to provide NAT > functions. Thus, this I-D proposes a solution to the problem > of mobility > management with network address translation. > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 10:02:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29732 for ; Thu, 14 Jun 2001 10:02:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26770; Thu, 14 Jun 2001 07:02:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20931; Thu, 14 Jun 2001 07:02:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EE1gWi017728 for ; Thu, 14 Jun 2001 07:01:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EE1gV7017727 for mobile-ip-dist; Thu, 14 Jun 2001 07:01:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EE1dWi017720 for ; Thu, 14 Jun 2001 07:01:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10135 for ; Thu, 14 Jun 2001 07:01:45 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA20792 for ; Thu, 14 Jun 2001 08:02:25 -0600 (MDT) Received: (qmail 11757 invoked by uid 500); 14 Jun 2001 13:51:06 -0000 Date: Thu, 14 Jun 2001 06:51:06 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Message-ID: <20010614065105.H17928@charizard.diameter.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Sharif.Shahrier@InterDigital.com on Thu, Jun 14, 2001 at 09:52:33AM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Thu, Jun 14, 2001 at 09:52:33AM -0400, Shahrier, Sharif M. wrote: > This is in the document 3GPP TS 23.221. Look at www.3gpp.org Sharif, It is typically not customary to include terminology that will require the reader to sift through other SDO documents just to understand what the I-D is trying to say. Could you perhaps include an introduction, or at the very least, a terminology definition, of a Transition Gateway function? Assume the reader is lazy :) PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 10:35:19 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00887 for ; Thu, 14 Jun 2001 10:35:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10849; Thu, 14 Jun 2001 07:35:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25230; Thu, 14 Jun 2001 07:35:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EEYMWi017783 for ; Thu, 14 Jun 2001 07:34:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EEYMZ2017782 for mobile-ip-dist; Thu, 14 Jun 2001 07:34:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EEYJWi017775 for ; Thu, 14 Jun 2001 07:34:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18156 for ; Thu, 14 Jun 2001 07:34:25 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09429 for ; Thu, 14 Jun 2001 08:35:06 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Jun 2001 10:34:21 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Date: Thu, 14 Jun 2001 10:34:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 23.221 describes the Transitition Gateway as a v6 to v4 function and the NAT there is NAT-PT. > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Thursday, June 14, 2001 9:53 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes > with Mobile > I Pv4" > > > This is in the document 3GPP TS 23.221. Look at www.3gpp.org > > Sharif > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Thursday, June 14, 2001 9:45 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes > with Mobile > I Pv4" > > > Where can one find a description of the Transition Gateway function > you mention? > > > > -----Original Message----- > > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Wednesday, June 13, 2001 3:00 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile > > IPv4" > > > > > > I have submitted a new internet-draft, please find it > > attached. I would like > > some feedback. It concerns the use of NAT boxes in Mobile IPv4. Now, > > currently, in the Mobile Telecommunications Industry, the > > UMTS architecture > > is slated to go "all-IP" based according to the R5 of 3GPP > > specs. The GPRS > > core network is to be connected to the Internet by a > > Transition Gateway > > (TrGw). Amongst other functions, the TrGw is expected to provide NAT > > functions. Thus, this I-D proposes a solution to the problem > > of mobility > > management with network address translation. > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 10:53:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01463 for ; Thu, 14 Jun 2001 10:53:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09640; Thu, 14 Jun 2001 08:53:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28172; Thu, 14 Jun 2001 07:53:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EEqiWi017823 for ; Thu, 14 Jun 2001 07:52:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EEqi7E017822 for mobile-ip-dist; Thu, 14 Jun 2001 07:52:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EEqfWi017815 for ; Thu, 14 Jun 2001 07:52:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11331 for ; Thu, 14 Jun 2001 07:52:47 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00400 for ; Thu, 14 Jun 2001 07:52:46 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 10:51:45 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Date: Thu, 14 Jun 2001 10:51:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: There are no terminology in the document that are taken from other organizations, other than the IETF. In fact, I just mentioned the transition gateway TrGW in my posting. It is not present in the actual draft. -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, June 14, 2001 9:51 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" On Thu, Jun 14, 2001 at 09:52:33AM -0400, Shahrier, Sharif M. wrote: > This is in the document 3GPP TS 23.221. Look at www.3gpp.org Sharif, It is typically not customary to include terminology that will require the reader to sift through other SDO documents just to understand what the I-D is trying to say. Could you perhaps include an introduction, or at the very least, a terminology definition, of a Transition Gateway function? Assume the reader is lazy :) PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 10:57:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01527 for ; Thu, 14 Jun 2001 10:57:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13047; Thu, 14 Jun 2001 08:57:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28603; Thu, 14 Jun 2001 07:57:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EEucWi017870 for ; Thu, 14 Jun 2001 07:56:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EEucCG017869 for mobile-ip-dist; Thu, 14 Jun 2001 07:56:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EEuYWi017859 for ; Thu, 14 Jun 2001 07:56:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29902 for ; Thu, 14 Jun 2001 07:56:41 -0700 (PDT) Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02917 for ; Thu, 14 Jun 2001 07:56:39 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Date: Thu, 14 Jun 2001 10:56:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Thread-Index: AcD030P8QJyDy5L7QRm413QQlpDyXgACjypQ From: "Qiang Zhang" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5EEuZWi017860 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit might be a typo? contrary to private address the global addresses should be registered addresses. Section 1 Introduction the private networks can use any any one of the unregistered addresses, without prior approval fro IANA. The public or global addresses are unregistered addresses -----Original Message----- From: Phil Roberts [mailto:PRoberts@megisto.com] Sent: Thursday, June 14, 2001 9:34 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" 23.221 describes the Transitition Gateway as a v6 to v4 function and the NAT there is NAT-PT. > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Thursday, June 14, 2001 9:53 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes > with Mobile > I Pv4" > > > This is in the document 3GPP TS 23.221. Look at www.3gpp.org > > Sharif > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Thursday, June 14, 2001 9:45 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes > with Mobile > I Pv4" > > > Where can one find a description of the Transition Gateway function > you mention? > > > > -----Original Message----- > > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Wednesday, June 13, 2001 3:00 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile > > IPv4" > > > > > > I have submitted a new internet-draft, please find it > > attached. I would like > > some feedback. It concerns the use of NAT boxes in Mobile IPv4. Now, > > currently, in the Mobile Telecommunications Industry, the > > UMTS architecture > > is slated to go "all-IP" based according to the R5 of 3GPP > > specs. The GPRS > > core network is to be connected to the Internet by a > > Transition Gateway > > (TrGw). Amongst other functions, the TrGw is expected to provide NAT > > functions. Thus, this I-D proposes a solution to the problem > > of mobility > > management with network address translation. > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 11:05:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01719 for ; Thu, 14 Jun 2001 11:04:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20563; Thu, 14 Jun 2001 09:05:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29848; Thu, 14 Jun 2001 08:04:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EF3vWi017924 for ; Thu, 14 Jun 2001 08:03:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EF3vm8017923 for mobile-ip-dist; Thu, 14 Jun 2001 08:03:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EF3sWi017916 for ; Thu, 14 Jun 2001 08:03:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29742 for ; Thu, 14 Jun 2001 08:04:00 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07880 for ; Thu, 14 Jun 2001 08:04:00 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 11:02:59 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" Date: Thu, 14 Jun 2001 11:02:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Global addresses are "registered". Thanks. -----Original Message----- From: Qiang Zhang [mailto:qzhang@ecutel.com] Sent: Thursday, June 14, 2001 10:57 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" might be a typo? contrary to private address the global addresses should be registered addresses. Section 1 Introduction the private networks can use any any one of the unregistered addresses, without prior approval fro IANA. The public or global addresses are unregistered addresses -----Original Message----- From: Phil Roberts [mailto:PRoberts@megisto.com] Sent: Thursday, June 14, 2001 9:34 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile I Pv4" 23.221 describes the Transitition Gateway as a v6 to v4 function and the NAT there is NAT-PT. > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Thursday, June 14, 2001 9:53 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes > with Mobile > I Pv4" > > > This is in the document 3GPP TS 23.221. Look at www.3gpp.org > > Sharif > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Thursday, June 14, 2001 9:45 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] New I-D on "Incorporating NAT-Boxes > with Mobile > I Pv4" > > > Where can one find a description of the Transition Gateway function > you mention? > > > > -----Original Message----- > > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > > Sent: Wednesday, June 13, 2001 3:00 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: [mobile-ip] New I-D on "Incorporating NAT-Boxes with Mobile > > IPv4" > > > > > > I have submitted a new internet-draft, please find it > > attached. I would like > > some feedback. It concerns the use of NAT boxes in Mobile IPv4. Now, > > currently, in the Mobile Telecommunications Industry, the > > UMTS architecture > > is slated to go "all-IP" based according to the R5 of 3GPP > > specs. The GPRS > > core network is to be connected to the Internet by a > > Transition Gateway > > (TrGw). Amongst other functions, the TrGw is expected to provide NAT > > functions. Thus, this I-D proposes a solution to the problem > > of mobility > > management with network address translation. > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 11:29:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02093 for ; Thu, 14 Jun 2001 11:29:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08860; Thu, 14 Jun 2001 08:29:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05227; Thu, 14 Jun 2001 08:29:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFSVWi018006 for ; Thu, 14 Jun 2001 08:28:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EFSVEn018005 for mobile-ip-dist; Thu, 14 Jun 2001 08:28:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFSSWi017998 for ; Thu, 14 Jun 2001 08:28:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02900 for ; Thu, 14 Jun 2001 08:28:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23384 for ; Thu, 14 Jun 2001 08:28:34 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA16346 for ; Thu, 14 Jun 2001 08:28:34 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5EFSXv15117 for ; Thu, 14 Jun 2001 08:28:33 -0700 X-mProtect: Thu, 14 Jun 2001 08:28:33 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd1czyrp; Thu, 14 Jun 2001 08:28:31 PDT Message-ID: <3B28D820.2547D401@iprg.nokia.com> Date: Thu, 14 Jun 2001 08:28:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] questions on fast handoffs for MIPv6 References: <034BEFD03799D411A59F00508BDF7546013DBF29@esealnt448.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, > => Not quite, that maybe true in the network determined case where > the MN does not send a BU to the old AR. If the MN sends a BU > then it MUST be able to request bicasting for a number of reasons: > > 1. BU list management in terms of lifetimes > 2. In some cases (different access technologies) the MN doesn't > need to request bicasting at all. The AR won't have that knowledge > and therefore the best place to have the request is the BU. I don't think that this behavior has been mandated -- certainly not for Mobile IPv6! Thus I would ask that you not capitalize such "MUST"s merely for emphasizing your point. A lot of people might get the wrong impression. Plus, how does (2) support your contention?! Didn't you claim in earlier messages that when bicasting has value, its value depends on characteristics of the access medium? Why doesn't the access router have knowledge of those characteristics? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 11:34:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02222 for ; Thu, 14 Jun 2001 11:34:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17570; Thu, 14 Jun 2001 09:35:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04063; Thu, 14 Jun 2001 08:35:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFYMWi018048 for ; Thu, 14 Jun 2001 08:34:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EFYMOU018047 for mobile-ip-dist; Thu, 14 Jun 2001 08:34:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFYKWi018040 for ; Thu, 14 Jun 2001 08:34:20 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13117 for ; Thu, 14 Jun 2001 11:34:26 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA29077 for mobile-ip@sunroof.eng.sun.com; Thu, 14 Jun 2001 11:34:45 -0400 (EDT) Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DGMKWi015719 for ; Wed, 13 Jun 2001 09:22:20 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA07508 for ; Wed, 13 Jun 2001 09:22:28 -0700 (PDT) Message-Id: <200106131622.JAA07508@heliopolis.eng.sun.com> Date: Wed, 13 Jun 2001 09:22:27 -0700 (PDT) From: James Kempf Subject: Re: [mobile-ip] Handover to Third? To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hpFa0jHow4FgZMWGQJmfoA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Wolfgang, I don't think it is unsolvable, it is solved in the current IS-41/IS-95/IOS 4.1 network, which is used for cellular communication in North America and Korea. I'll spare you the details of how it is solved, but you can check the IS-41 specification if you want to see how on the core network side. I presume GSM has a solution also. jak >Date: Wed, 13 Jun 2001 09:54:03 +0200 >From: Wolfgang Schoenfeld >To: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] Handover to Third? > >James, > >one may imagine that MN moves (physically or by radio reachability) so fast >that any data forwarded to newAR by whatsoever method >arrives there only after MN has left it. > >(This holds for unicast forwarding only. >If data is multicasted to all envisaged ARs, >MN will receive it by at least one of them >- if reachability time is long enough.) > >Couldn't it be that the problem you describe is unsolvable in general and >has a solution only under reasonable assumptions on MN's moves, >taking numbers into account as you computed? >These would clearly depend on the (geographical) distribution of ARs. > >Wolfgang > >James Kempf schrieb: >> >> I've been looking through the FMIPv6 draft again, and a question came up. >> >> It is possible that the MN may have some traffic on newAR required >> to set up the newCoA. It may have to send an F-BU, and an >> F-NA or NA. This is in addition to the BU to the HA or hierarchical agent, which >> will require at least another radio link round trip, probably without full >> header compression. So there is some amount of time on newAR during which the MN >> is not in full possession of the newCoA, but is in the process of >> establishing it. >> >> The question is, what happens if the MN moves to a third AR before >> the process of establishing the newCoA is complete? >> >> For example, let's suppose the MN sends the F-BU while on the oldAR >> but does not receive a reply before L2 handover to newAR happens. Suppose >> further that the MN's location is at a place where three cells butt >> up against each other, and that it quickly slips into a third cell at L2, >> before the F-BACK arrives. Or suppose the MN is moving quickly through >> a small sliver of a cell between two others. This problem is similar >> to the ping-pong problem, but with a third cell. >> >> There are two issues here: >> >> 1) The newAR may not have enough time to complete the PrRtAdv/F-BU pair >> that is required for network assisted handover over the air with MN prior to the >> L2 handover to thirdAR, to say nothing of the RtSolPr/PrRtAdv/F-BU for mobile >> assisted. The HI/HACK would probably work, since that is sent over >> the backbone and should take no longer than 10 ms, if processing time >> on thirdAR is low, and 10 ms is about 1/2 of a radio frame for typical 3G >> radio link protocols. >> >> 2) The oldAR is now left thinking that MN has moved to newAR. It has >> set up a bi-directional tunnel with newAR to assure that MN's packets >> get to it, even if they have oCoA as the destination address. It attempts >> to send the F-BACK to nCoA, but MN has moved and the F-BACK doesn't get >> there, maybe oldAR gets an ICMP message to that effect. What should oldAR do? >> How does it distinguish this case from one where the MN has moved and goes into >> dormant mode or is lost? Should newAR set up a second tunnel to thirdAR? >> >> It seems to me like the draft needs to provide some solution for this >> case, as well as for ping-ponging. >> >> jak > >-- >Prof. Dr. Wolfgang Schoenfeld, GMD-IPSI, Dolivostr. 15, D-64293 Darmstadt >Office: +49-6151-869-865 FAX: -6847 Mobile: +49-174-7093455 From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 11:36:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02301 for ; Thu, 14 Jun 2001 11:36:42 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19435; Thu, 14 Jun 2001 09:36:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04407; Thu, 14 Jun 2001 08:36:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFa9Wi018071 for ; Thu, 14 Jun 2001 08:36:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EFa9VA018070 for mobile-ip-dist; Thu, 14 Jun 2001 08:36:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFa7Wi018063 for ; Thu, 14 Jun 2001 08:36:07 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13588 for ; Thu, 14 Jun 2001 11:36:14 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA29105 for mobile-ip@sunroof.eng.sun.com; Thu, 14 Jun 2001 11:36:32 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5E5J1Wi016869 for ; Wed, 13 Jun 2001 22:19:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10719 for ; Wed, 13 Jun 2001 22:19:10 -0700 (PDT) Received: from lochinvar.ece.neu.edu (mail2.ece.neu.edu [129.10.60.82]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04569 for ; Wed, 13 Jun 2001 22:19:10 -0700 (PDT) Received: from runner.ece.neu.edu (runner.ece.neu.edu [129.10.60.136]) by lochinvar.ece.neu.edu (8.9.3/8.9.3) with ESMTP id BAA26118 for ; Thu, 14 Jun 2001 01:20:30 -0400 (EDT) Received: from localhost by runner.ece.neu.edu (8.9.3/8.9.3) with ESMTP id BAA06972 for ; Thu, 14 Jun 2001 01:19:07 -0400 (EDT) X-Authentication-Warning: runner.ece.neu.edu: mcdonald owned process doing -bs Date: Thu, 14 Jun 2001 01:19:07 -0400 (EDT) From: "A. Bruce McDonald" X-Sender: mcdonald@runner To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] CFP: CNDS 2002, San Antonio, Texas Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ANNOUNCEMENT AND CALL FOR PAPERS Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP The Society for Computer Simulation International (SCS) presents: COMMUNICATION NETWORKS AND DISTRIBUTED SYSTEMS MODELING AND SIMULATION CONFERENCE 2002 January 27-31, 2002 Four Points Sheraton Hotel, Riverwalk North San Antonio, Texas Please Visit the Conference Web Site for Additional Information http://www.ece.neu.edu/conf/CNDS/2002/ Part of the 2002 SCS Western Multiconference on Computer Simulation The objective of this conference is to serve as a forum for the exchange of ideas among a talented group of international researchers on advances in the design and performance analysis of communication networks and distributed systems. The conference emphasizes modeling, technical advances and unique applications in the areas of high speed networking, wireless communications, multimedia applications, computer architecture and distributed, parallel and mobile computing systems. The structure of the conference is designed to facilitate collegiality and continuity of discussion among the conference speakers and attendees on the topics covered during the week. Paper sessions are designed to promote discussion of concepts and methodologies based on the presentation of results and innovative modeling, simulation or analysis techniques. The conference grew out of the need to improve the efficiency and quality of models of increasingly complex networks and distributed systems. In addition to the technical sessions, the conference includes invited speakers, vendor presentations and exhibits arranged in conjunction with the 2002 SCS Western Simulation Multiconference (WMC). Original, high-quality technical papers, addressing significant aspects of the design, modeling, or performance analysis of communication networks and distributed systems are solicited for review, possible presentation and subsequent publication in the conference proceedings. Papers that include well-conceived or innovative simulation modeling techniques with strong results and analysis are especially sought. Papers are solicited from not limited to the following topics: * Performance Modeling and Analysis * Mobile and Nomadic Computing * Distributed and Wireless Multimedia Systems * QoS Support for Wireless Ad Hoc Network Applications * Routing and Mobility Management in Wireless Networks * Power Control in Wireless Computer Systems * Distributed and Intelligent Sensor Networks * Wearable Computer Systems * Resource Allocation in High Speed Networks * Switch and Processor Architectures for High Speed Routers * Advances in Computer Architecture and Memory Systems * Network and Parallel Computing * Storage Area Networks * Content Based Image Retrieval Systems * Real-Time and Mobile Web-Based Computing * Reliable Multicast Routing and Group Communications * Network and Application Security and Availability * Web Caching and Switching * Scalable and Reliable Distributed Servers * Load Balancing in Distributed Systems IMPORTANT DATES: September 15, 2001 Paper Submission Deadline. October 15, 2001 Acceptance Notification. November 15, 2001 Camera Ready Paper Deadline. Authors are requested to submit manuscripts electronically to the Program Chair by 11:00 pm (Eastern Time) of the due date via Anonymous ftp directly: ftp.ece.neu.edu:/pub/conf/CNDS/2002/Submissions. Papers can also be uploaded using the Web Site: www.ece.neu.edu/conf/CNDS/2002/. Papers must be in English and submitted files must be in Postscript or PDF format with all figures and tables included. Files names must be unique and reflect the name of the primary author, his or her primary affiliation, the version number of the file and an extension indicating the file type. Multiple versions may be uploaded; however, only the most recent will be reviewed. Filenames are not readable once the file transfer has been completed. Confirmations will be sent to the contact author when the file has been retrieved and successfully viewed or printed. Only original unpublished material will be considered for publication. This year's International TPC is outstanding. Its members represent a broad spectrum of interrelated interests and technical expertise relevent to CNDS. Each member is committed to ensure that all submissions are fully refereed for accuracy, technical content, and relevance. Papers should be limited to 20 double-spaced pages (camera-ready versions are limited to 6 single-spaced pages). Authors must include a single page which includes all the authors' names, titles and affiliations, a paper abstract, list of top three relevant topics and contact person information (complete address, email, phone, and fax). Accepted papers will appear in the Conference's Proceedings to be published by the Society for Computer Simulation. Instructions for submitting camera ready papers will be sent to authors following paper acceptance. An award will be presented to the best paper presented at WMC'02. Authors of top papers will also be encouraged to submit a follow-on paper to the International Journal in Computer Simulation. Authors must obtain employer, client, or government releases prior to submittal of the final manuscript. Please do not hesitate to contact the Program Chair, Prof. McDonald via email (mcdonald@ece.neu.edu), or telephone ((617) 373-3028) with any questions concerning the paper submission and review process, or questions regarding the relevance of a paper to the conference. General Chair Program Chair Dr. Taieb F. Znati Prof. A. Bruce McDonald Senior Program Director Dept. of Electrical and Computer Eng. National Science Foundation 417 Dana Research Center ANIR and Northeastern University Computer Science Department 360 Huntington Avenue University of Pittsburgh Boston, MA 15221 Pittsburgh, PA 15260 U.S.A. U.S.A. Phone: +1(412)624-8417 Phone: +1(617)328-3028 FAX: +1(412)624-8854 FAX: +1(617)328-8970 E_Mail: znati@cs.pitt.edu E_Mail: mcdonald@ece.neu.edu Please visit the conference Web Site to see an up-to-date list of the members of the International Technical Program Commmittee: http://www.ece.neu.edu/conf/CNDS/2002/ -------------------------------------------- A. Bruce McDonald f:617.373.8970 Assistant Prof. v:617.373.3028 ECE Dept., 417 Dana mcdonald@ece.neu.edu 360 Huntington Ave. Northeastern University Boston, MA 02115 -------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 11:43:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02537 for ; Thu, 14 Jun 2001 11:43:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16654; Thu, 14 Jun 2001 08:43:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05352; Thu, 14 Jun 2001 08:43:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFgUWi018117 for ; Thu, 14 Jun 2001 08:42:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EFgUbp018116 for mobile-ip-dist; Thu, 14 Jun 2001 08:42:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFgRWi018109 for ; Thu, 14 Jun 2001 08:42:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07923 for ; Thu, 14 Jun 2001 08:42:34 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02526 for ; Thu, 14 Jun 2001 08:42:32 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5EFgUO16921 for ; Thu, 14 Jun 2001 17:42:30 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Jun 14 17:42:29 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 17:42:28 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF35@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Thu, 14 Jun 2001 17:42:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Charlie, > > => Not quite, that maybe true in the network determined case where > > the MN does not send a BU to the old AR. If the MN sends a BU > > then it MUST be able to request bicasting for a number of reasons: > > > > 1. BU list management in terms of lifetimes > > 2. In some cases (different access technologies) the MN doesn't > > need to request bicasting at all. The AR won't have that knowledge > > and therefore the best place to have the request is the BU. > > I don't think that this behavior has been mandated -- certainly > not for Mobile IPv6! Thus I would ask that you not capitalize such > "MUST"s merely for emphasizing your point. A lot of people might > get the wrong impression. > => I wasn't quoting any RFCs or drafts. > Plus, how does (2) support your contention?! Didn't you claim in > earlier messages that when bicasting has value, its value depends > on characteristics of the access medium? > => Yes. > Why doesn't the access > router have knowledge of those characteristics? > => I am referring to an example of a case where the MN has two interfaces and can receive two traffic streams simultaneously. I don't expect a router connected to a WCDMA network to know that there is a WLAN network nearby and that the MN can hear both. I don't think this should be expected. IF the air interface happened to allow the MN to receive two sets of traffic streams from two different routers on a single physical interface in the MN, then I would expect the AR to know about this. This would be a link layer that allows for make before break handovers. Not many of those are around, if any. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 11:45:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02600 for ; Thu, 14 Jun 2001 11:45:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27877; Thu, 14 Jun 2001 09:45:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05957; Thu, 14 Jun 2001 08:45:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFipWi018148 for ; Thu, 14 Jun 2001 08:44:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EFipPF018147 for mobile-ip-dist; Thu, 14 Jun 2001 08:44:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFilWi018137 for ; Thu, 14 Jun 2001 08:44:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07796 for ; Thu, 14 Jun 2001 08:44:54 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27085 for ; Thu, 14 Jun 2001 09:44:53 -0600 (MDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5EFis811799 for ; Thu, 14 Jun 2001 10:44:54 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 14 Jun 2001 10:44:53 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 14 Jun 2001 10:44:52 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B03213BF5@daeis07nok> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] QoS Requiremements for Mobility work Date: Thu, 14 Jun 2001 10:44:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, The initial work on : "Requirements of a QoS Solution for Mobile IP - draft-ietf-mobileip-qos-requirements-00.txt" has been submitted to the Mobile IP WG. The discussion list that was setup for this effort has been shutdown and all further discussion related to this work will continue on this list (MIP list). The archives will be made available shortly. Please provide comments and input to this work. Thanks to Hemant Chaskar (Editor of the draft) and everyone else who participated in this effort. Basavaraj & Phil From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 11:49:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02693 for ; Thu, 14 Jun 2001 11:49:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01204; Thu, 14 Jun 2001 09:49:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06669; Thu, 14 Jun 2001 08:49:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFmrWi018201 for ; Thu, 14 Jun 2001 08:48:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EFmr95018200 for mobile-ip-dist; Thu, 14 Jun 2001 08:48:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EFmpWi018193 for ; Thu, 14 Jun 2001 08:48:51 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09264 for ; Thu, 14 Jun 2001 11:48:58 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA29328 for mobile-ip@sunroof.eng.sun.com; Thu, 14 Jun 2001 11:49:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EF3SWi017905 for ; Thu, 14 Jun 2001 08:03:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27177 for ; Thu, 14 Jun 2001 08:03:34 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07589 for ; Thu, 14 Jun 2001 08:03:34 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA05116 for ; Thu, 14 Jun 2001 08:03:33 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA11696 for ; Thu, 14 Jun 2001 08:03:33 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 10:03:33 -0500 Message-ID: From: Zhao Xiaoming-CXZ004 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] TSB-115 copy ? Date: Thu, 14 Jun 2001 10:03:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I could not find TSB-115 "Wireless IP Architecture Based on IETF Protocols". By chance anybody have a copy could send one to me? Thanks. Xiaoming Zhao From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 15:18:24 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08068 for ; Thu, 14 Jun 2001 15:18:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08224; Thu, 14 Jun 2001 12:18:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27662; Thu, 14 Jun 2001 12:18:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EJHJWi018499 for ; Thu, 14 Jun 2001 12:17:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EJHJf1018498 for mobile-ip-dist; Thu, 14 Jun 2001 12:17:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EJHFWi018491 for ; Thu, 14 Jun 2001 12:17:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15439 for ; Thu, 14 Jun 2001 12:17:22 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23624 for ; Thu, 14 Jun 2001 12:17:22 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA28071 for ; Thu, 14 Jun 2001 14:17:21 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5EJHLF02882; Thu, 14 Jun 2001 14:17:21 -0500 (CDT) Message-ID: <3B290DFA.B479D4C4@usa.alcatel.com> Date: Thu, 14 Jun 2001 14:18:18 -0500 From: "Mingguey M. Yang" Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt References: <200106141107.HAA24622@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sharif, In the "System Architecture" section: ... The NAT tables have to be set up, to reflect the correct binding between the global address of NAT-A and the local address of the sender in A... Is the binding of one global address to one private address mapping? Or one global address to many private addresses mapping? Mingguey From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 15:27:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08292 for ; Thu, 14 Jun 2001 15:27:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06030; Thu, 14 Jun 2001 13:27:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29072; Thu, 14 Jun 2001 12:27:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EJQBWi018534 for ; Thu, 14 Jun 2001 12:26:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EJQBsX018533 for mobile-ip-dist; Thu, 14 Jun 2001 12:26:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EJQ7Wi018526 for ; Thu, 14 Jun 2001 12:26:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01703 for ; Thu, 14 Jun 2001 12:26:14 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17629 for ; Thu, 14 Jun 2001 12:26:14 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 15:25:08 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Date: Thu, 14 Jun 2001 15:25:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The binding is one global address to one private address for a given session. -----Original Message----- From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] Sent: Thursday, June 14, 2001 3:18 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Sharif, In the "System Architecture" section: ... The NAT tables have to be set up, to reflect the correct binding between the global address of NAT-A and the local address of the sender in A... Is the binding of one global address to one private address mapping? Or one global address to many private addresses mapping? Mingguey From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 16:39:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09467 for ; Thu, 14 Jun 2001 16:39:33 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05482; Thu, 14 Jun 2001 14:39:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03574; Thu, 14 Jun 2001 13:39:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EKbgWi018626 for ; Thu, 14 Jun 2001 13:37:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5EKbg5Y018625 for mobile-ip-dist; Thu, 14 Jun 2001 13:37:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5EKbcWi018618 for ; Thu, 14 Jun 2001 13:37:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03186 for ; Thu, 14 Jun 2001 13:37:46 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA28130 for ; Thu, 14 Jun 2001 13:37:43 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA08223 for ; Thu, 14 Jun 2001 15:37:10 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5EKbAD25039 for ; Thu, 14 Jun 2001 15:37:10 -0500 (CDT) Message-ID: <3B2920AE.13BC0CCD@usa.alcatel.com> Date: Thu, 14 Jun 2001 15:38:06 -0500 From: "Mingguey M. Yang" Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sharif, In your proposed architecture, Basic Static NAT-routers are used. This means that a set of globally unique IP addresses (i.e., a set of registered addresses) is reserved by each NAT device (located in a NAT-enabled router) just for the purpose of for address translation, i.e., mapping the private address of each local private node that wants to communicate with an external node (i.e., CN) to one of the reserved global addresses. This is an one-to-one mapping within not only the NAT table but also the entire private network. Your proposal says that the format of a binding in the NAT is (Global IP Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the registered IP address of the NAT-enabled router itself or one of the globally unique IP addresses reserved by the NAT located in the router? If it is the former, then NAPT is used (instead of basic static NAT), where port numbers are involved in the address translation. If it is the later, then the format of a binding in the NAT should be (A Global IP Address Reserved by NAT, Local IP Address). Mingguey "Shahrier, Sharif M." wrote: > The binding is one global address to one private address for a given > session. > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Thursday, June 14, 2001 3:18 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > In the "System Architecture" section: > ... > The NAT tables have to be set up, to reflect the correct binding > between the global address of NAT-A and the local address of the > sender in A... > > Is the binding of one global address to one private address mapping? Or one > global > address to many private addresses mapping? > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 22:39:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14892 for ; Thu, 14 Jun 2001 22:39:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13665; Thu, 14 Jun 2001 19:39:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16963; Thu, 14 Jun 2001 19:39:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F2cG42019272 for ; Thu, 14 Jun 2001 19:38:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5F2cGex019271 for mobile-ip-dist; Thu, 14 Jun 2001 19:38:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F2cD42019264 for ; Thu, 14 Jun 2001 19:38:13 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5F2cKG712623 for ; Thu, 14 Jun 2001 19:38:20 -0700 (PDT) Message-Id: <200106150238.f5F2cKG712623@jurassic.eng.sun.com> Date: Thu, 14 Jun 2001 19:38:20 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8X2ed404WHyIGq1KpOJibg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Madjid, > > MN>>>>Well, how does the sender know where to send the packets before > > receiving > > F-NA/NA from the mobile? > > L2 address of MN is sent in HI message from oldAR to newAR. As soon as MN > attaches to new link, "if" newAR can detect this attachment and correlate > this > to MN, then newAR can start forwarding packets. Otherwise, newAR needs to > wait > for F-NA. "where to send" information is the L2 address of the mobile node, > which was communicated in the HI message. > > MN>> Ok, Maybe I need to do some studying on the addressing issues, > at this point, I am not sure what correlating in this case means, > Does it mean newAR looks at its database for MN's address (stateful) > what about stateless? Ability to identify the matching HI message based on the L2 address of the newly attached MN.. Once newAR find the matching HI message, it can figure out who this MN is. And start forwarding this MN's traffic. > I would say waiting for F-NA is the layer 3 way of doing things. > You seem to be relying on some L2 mechanisms, am I missing something? Using them (L2 features) whenever they are available.. If missing, then rely on L3. > > > > MN>>>> to me neither. Tell me who sends L2 attachement to MN, > > AR or AP, if AR does then there would be no race condition > > (however, this would not be a general case, I think), but > > if AP does, then AP sends the signal to AR as well and there > > would be a time when one of AR and MN does not know about the > > L2 connectivity (I think MN would know later, but it is not certain) > > > So, what you are saying is this: there can be a case where AR thinks MN is > L2 > connected and starts sending packets, but MN is actually not L2 connected > yet. > This sounds like a L2 problem, that needs to be handled at L2. I think L2 > folks > should fix this :) > > MN>> Well maybe, but the way it is written in the draft, you are > making your protocol volnurable to L2 imperfections!! Especially > in the solution that offerred in your first answer above. If there's some imperfection on the L2, of course it effects the protocol. We cannot guard the protocol againist this kind of L2 problems.... > I still have a hard time to digest your "based on L2 connectivity > signal OR receiving F-NA" condition. > > Let me know if I am confused. > > Madjid alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 22:40:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14985 for ; Thu, 14 Jun 2001 22:40:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11379; Thu, 14 Jun 2001 20:41:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17171; Thu, 14 Jun 2001 19:40:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F2eJ42019293 for ; Thu, 14 Jun 2001 19:40:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5F2eJBa019292 for mobile-ip-dist; Thu, 14 Jun 2001 19:40:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F2eG42019285 for ; Thu, 14 Jun 2001 19:40:16 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5F2eNG712946 for ; Thu, 14 Jun 2001 19:40:23 -0700 (PDT) Message-Id: <200106150240.f5F2eNG712946@jurassic.eng.sun.com> Date: Thu, 14 Jun 2001 19:40:23 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XFUcKkGZlCOF20wzJxze9g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barani, > As in the draft and this thread, I like to point out that Link layer address > based verification across ARs should be avoided as much as possible. > MN can have two interfaces and also move from one AR to another AR using the new > L2 interface. > > If we want L2 identifier then there should be a way that MN can indicate to the > old AR about the new Link layer ID that it will be using plus the current L2 ID. > If this is a mobile node with multiple links, which can be connected to different ARs at the same time, you most probably don't need FMIPv6 draft. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 14 22:46:27 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15093 for ; Thu, 14 Jun 2001 22:46:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13587; Thu, 14 Jun 2001 20:46:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17736; Thu, 14 Jun 2001 19:46:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F2k142019335 for ; Thu, 14 Jun 2001 19:46:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5F2k1fB019334 for mobile-ip-dist; Thu, 14 Jun 2001 19:46:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F2jw42019327 for ; Thu, 14 Jun 2001 19:45:58 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5F2k5G713523 for ; Thu, 14 Jun 2001 19:46:05 -0700 (PDT) Message-Id: <200106150246.f5F2k5G713523@jurassic.eng.sun.com> Date: Thu, 14 Jun 2001 19:46:05 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: MXX5Rtj2It9qPwgq3grwSw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, > > > => Not quite, that maybe true in the network determined case where > > > the MN does not send a BU to the old AR. If the MN sends a BU > > > then it MUST be able to request bicasting for a number of reasons: > > > > > > 1. BU list management in terms of lifetimes Can you please elaborate this, I didn't get it. > > > 2. In some cases (different access technologies) the MN doesn't > > > need to request bicasting at all. The AR won't have that knowledge > > > and therefore the best place to have the request is the BU. > > > > I don't think that this behavior has been mandated -- certainly > > not for Mobile IPv6! Thus I would ask that you not capitalize such > > "MUST"s merely for emphasizing your point. A lot of people might > > get the wrong impression. > > > => I wasn't quoting any RFCs or drafts. > > > Plus, how does (2) support your contention?! Didn't you claim in > > earlier messages that when bicasting has value, its value depends > > on characteristics of the access medium? > > > => Yes. > > > Why doesn't the access > > router have knowledge of those characteristics? > > > => I am referring to an example of a case where the MN > has two interfaces and can receive two traffic streams > simultaneously. I don't expect a router connected > to a WCDMA network to know that there is a WLAN > network nearby and that the MN can hear both. > I don't think this should be expected. Why do we need FMIPv6 in this case? You have two simultaneously connected interfaces.. > > IF the air interface happened to allow the MN to receive > two sets of traffic streams from two different routers > on a single physical interface in the MN, then > I would expect the AR to know about this. > This would be a link layer that allows for make before break > handovers. Not many of those are around, if any. > > Regards, > Hesham alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 00:23:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16070 for ; Fri, 15 Jun 2001 00:23:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21251; Thu, 14 Jun 2001 22:23:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA27442; Thu, 14 Jun 2001 21:23:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F4Mu42019425 for ; Thu, 14 Jun 2001 21:22:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5F4Mu0b019424 for mobile-ip-dist; Thu, 14 Jun 2001 21:22:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F4Mr42019417 for ; Thu, 14 Jun 2001 21:22:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14304 for ; Thu, 14 Jun 2001 21:23:01 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA05621 for ; Thu, 14 Jun 2001 22:23:41 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5F4L0p25167 for ; Thu, 14 Jun 2001 21:21:00 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5F4MwI26242 for ; Thu, 14 Jun 2001 21:22:58 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A6C.00180E3A ; Thu, 14 Jun 2001 21:22:45 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A6C.00180C26.00@hqoutbound.ops.3com.com> Date: Thu, 14 Jun 2001 21:23:04 -0700 Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, No. It is a single mobile with multiple links but connects via a single link at any given time to a single AR. However, after hand off it connects to new AR via a different link. Example would be WLAN and WWAN or any other combination. Barani. Alper Yegin on 06/14/2001 07:40:23 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Alper Yegin To: mobile-ip@sunroof.eng.sun.com cc: (Barani Subbiah/HQ/3Com) Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Barani, > As in the draft and this thread, I like to point out that Link layer address > based verification across ARs should be avoided as much as possible. > MN can have two interfaces and also move from one AR to another AR using the new > L2 interface. > > If we want L2 identifier then there should be a way that MN can indicate to the > old AR about the new Link layer ID that it will be using plus the current L2 ID. > If this is a mobile node with multiple links, which can be connected to different ARs at the same time, you most probably don't need FMIPv6 draft. alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 05:48:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02239 for ; Fri, 15 Jun 2001 05:48:04 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04200; Fri, 15 Jun 2001 03:48:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08555; Fri, 15 Jun 2001 02:48:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F9kr42019768 for ; Fri, 15 Jun 2001 02:46:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5F9krOA019767 for mobile-ip-dist; Fri, 15 Jun 2001 02:46:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F9kn42019760 for ; Fri, 15 Jun 2001 02:46:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06137 for ; Fri, 15 Jun 2001 02:46:57 -0700 (PDT) Received: from quicksilver.ukc.ac.uk (quicksilver.ukc.ac.uk [129.12.21.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08500 for ; Fri, 15 Jun 2001 02:46:56 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by quicksilver.ukc.ac.uk with esmtp (Exim 3.22 #4) id 15AqBc-00002i-00 for mobile-ip@sunroof.eng.sun.com; Fri, 15 Jun 2001 10:46:40 +0100 Received: from pccomm6.ukc.ac.uk ([129.12.50.121] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 15AqBo-00077j-00 for mobile-ip@sunroof.eng.sun.com; Fri, 15 Jun 2001 10:46:52 +0100 Message-ID: <3B29D98C.3950E63B@ukc.ac.uk> Date: Fri, 15 Jun 2001 10:46:52 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Good Book on Wireless Network Performance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Can someone suggest me a good book on modeling wireless network performance. I am interested in admission control and resource reservation for mobile nodes during handoff but any book related to wireless network modeling would be a good start.. I have been searching for a while and am yet to find aything on this subject. Please help INdran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Electronics Engineering Laboratory \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \ Telephone(Mobile): +44 (0)7765 007016 / \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 05:55:27 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02322 for ; Fri, 15 Jun 2001 05:55:26 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25658; Fri, 15 Jun 2001 02:55:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08994; Fri, 15 Jun 2001 02:55:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F9sr42019807 for ; Fri, 15 Jun 2001 02:54:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5F9sruL019806 for mobile-ip-dist; Fri, 15 Jun 2001 02:54:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5F9so42019799 for ; Fri, 15 Jun 2001 02:54:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24315 for ; Fri, 15 Jun 2001 02:54:57 -0700 (PDT) Received: from mx2.ust.hk (mx2.ust.hk [143.89.14.128]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10740 for ; Fri, 15 Jun 2001 02:54:56 -0700 (PDT) Received: from smtp.ust.hk (smtp.ust.hk [143.89.14.35]) by mx2.ust.hk (8.11.0/8.11.0) with ESMTP id f5F9q0T21820 for ; Fri, 15 Jun 2001 17:52:00 +0800 Received: from MSR-jcliu (tide121.microsoft.com [207.46.71.13]) by smtp.ust.hk (8.11.0/8.11.0) with SMTP id f5F9pWe07371 for ; Fri, 15 Jun 2001 17:51:33 +0800 (HKT) Message-Id: <200106150951.f5F9pWe07371@smtp.ust.hk> Date: Fri, 15 Jun 2001 17:52:35 +0800 From: Rito Ljc To: "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Multicast or broadcast in a cell Organization: UST X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Can anyone provide me some information on multicast or broadcast data or video content over a cell (from base station to receivers). Does 3G wireless standards supportthis sort of operation ? And are there research papers on this topic ? Thanks a lot Rito From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 07:38:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03478 for ; Fri, 15 Jun 2001 07:38:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA23475; Fri, 15 Jun 2001 04:38:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13732; Fri, 15 Jun 2001 04:38:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FBbH42020099 for ; Fri, 15 Jun 2001 04:37:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FBbGec020098 for mobile-ip-dist; Fri, 15 Jun 2001 04:37:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FBbD42020091 for ; Fri, 15 Jun 2001 04:37:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA26301 for ; Fri, 15 Jun 2001 04:37:20 -0700 (PDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28319 for ; Fri, 15 Jun 2001 04:37:18 -0700 (PDT) Received: from cwc-ibxus8n62wn.cwc.nus.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.10.0/8.10.0) with ESMTP id f5FBau525856 for ; Fri, 15 Jun 2001 19:36:56 +0800 (SST) Message-Id: <5.1.0.14.2.20010615193941.00a6b658@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Jun 2001 19:42:33 +0800 To: mobile-ip@sunroof.eng.sun.com From: Charles Qi Shen Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 In-Reply-To: <88256A6C.00180C26.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barani, Do you mean a mobile with multiple interfaces but it only uses a single interface at any given time and it changes this single interface after a handoff? Charles At 09:23 PM 6/14/2001 -0700, you wrote: >Alper, > >No. It is a single mobile with multiple links but connects via a single >link at >any given time to a single AR. However, after hand off it connects to new >AR via >a different link. Example would be WLAN and WWAN or any other combination. > >Barani. > > > > >Alper Yegin on 06/14/2001 07:40:23 PM > >Please respond to mobile-ip@sunroof.eng.sun.com > >Sent by: Alper Yegin > > >To: mobile-ip@sunroof.eng.sun.com >cc: (Barani Subbiah/HQ/3Com) >Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > >Barani, > > > As in the draft and this thread, I like to point out that Link layer > address > > based verification across ARs should be avoided as much as possible. > > MN can have two interfaces and also move from one AR to another AR > using the >new > > L2 interface. > > > > If we want L2 identifier then there should be a way that MN can indicate to >the > > old AR about the new Link layer ID that it will be using plus the > current L2 >ID. > > > >If this is a mobile node with multiple links, which can be connected to >different ARs at the same time, you most probably don't need FMIPv6 draft. > >alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 07:39:19 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03523 for ; Fri, 15 Jun 2001 07:39:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00771; Fri, 15 Jun 2001 05:39:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13859; Fri, 15 Jun 2001 04:39:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FBcl42020116 for ; Fri, 15 Jun 2001 04:38:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FBckx4020115 for mobile-ip-dist; Fri, 15 Jun 2001 04:38:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FBch42020108 for ; Fri, 15 Jun 2001 04:38:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13811 for ; Fri, 15 Jun 2001 04:38:50 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00142 for ; Fri, 15 Jun 2001 05:38:48 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5FBclO26247 for ; Fri, 15 Jun 2001 13:38:47 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jun 15 13:38:21 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 13:33:13 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF3B@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Fri, 15 Jun 2001 13:38:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > > > > => Not quite, that maybe true in the network determined case where > > > > the MN does not send a BU to the old AR. If the MN sends a BU > > > > then it MUST be able to request bicasting for a number of reasons: > > > > > > > > 1. BU list management in terms of lifetimes > > Can you please elaborate this, I didn't get it. > => You need to know how long a Binding Update entry is valid for. Ie. how long will the AR forward to a particular address for. If you don't communicate that in the BU there is no way of knowing when to remove the entry, or when the AR will require a refresh, or when it will stop forwarding. So if you're bicasting you need to know how long the bicasting lifetime is. > > => I am referring to an example of a case where the MN > > has two interfaces and can receive two traffic streams > > simultaneously. I don't expect a router connected > > to a WCDMA network to know that there is a WLAN > > network nearby and that the MN can hear both. > > I don't think this should be expected. > > > Why do we need FMIPv6 in this case? You have two simultaneously connected > interfaces.. > => You don't, which is what I was saying. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 08:56:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05978 for ; Fri, 15 Jun 2001 08:56:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11172; Fri, 15 Jun 2001 06:56:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07167; Fri, 15 Jun 2001 05:56:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FCtG42020254 for ; Fri, 15 Jun 2001 05:55:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FCtGcd020253 for mobile-ip-dist; Fri, 15 Jun 2001 05:55:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FCtD42020246 for ; Fri, 15 Jun 2001 05:55:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07003 for ; Fri, 15 Jun 2001 05:55:21 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA04927 for ; Fri, 15 Jun 2001 06:56:01 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5FCrLp20194 for ; Fri, 15 Jun 2001 05:53:21 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5FCtJI25059 for ; Fri, 15 Jun 2001 05:55:19 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A6C.0046F558 ; Fri, 15 Jun 2001 05:55:03 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A6C.0046F409.00@hqoutbound.ops.3com.com> Date: Fri, 15 Jun 2001 05:55:25 -0700 Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Charles, Yes, you got it right. Barani. Charles Qi Shen on 06/15/2001 04:42:33 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Charles Qi Shen To: mobile-ip@sunroof.eng.sun.com cc: (Barani Subbiah/HQ/3Com) Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Barani, Do you mean a mobile with multiple interfaces but it only uses a single interface at any given time and it changes this single interface after a handoff? Charles At 09:23 PM 6/14/2001 -0700, you wrote: >Alper, > >No. It is a single mobile with multiple links but connects via a single >link at >any given time to a single AR. However, after hand off it connects to new >AR via >a different link. Example would be WLAN and WWAN or any other combination. > >Barani. > > > > >Alper Yegin on 06/14/2001 07:40:23 PM > >Please respond to mobile-ip@sunroof.eng.sun.com > >Sent by: Alper Yegin > > >To: mobile-ip@sunroof.eng.sun.com >cc: (Barani Subbiah/HQ/3Com) >Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > >Barani, > > > As in the draft and this thread, I like to point out that Link layer > address > > based verification across ARs should be avoided as much as possible. > > MN can have two interfaces and also move from one AR to another AR > using the >new > > L2 interface. > > > > If we want L2 identifier then there should be a way that MN can indicate to >the > > old AR about the new Link layer ID that it will be using plus the > current L2 >ID. > > > >If this is a mobile node with multiple links, which can be connected to >different ARs at the same time, you most probably don't need FMIPv6 draft. > >alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 10:32:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10503 for ; Fri, 15 Jun 2001 10:32:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25142; Fri, 15 Jun 2001 07:30:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19242; Fri, 15 Jun 2001 07:28:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FERk42020337 for ; Fri, 15 Jun 2001 07:27:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FERjWH020336 for mobile-ip-dist; Fri, 15 Jun 2001 07:27:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FERg42020329 for ; Fri, 15 Jun 2001 07:27:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05766 for ; Fri, 15 Jun 2001 07:27:49 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24036 for ; Fri, 15 Jun 2001 08:28:28 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 10:26:44 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Date: Fri, 15 Jun 2001 10:26:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mingguey, If you look at RFC 3022, it describes a "traditional NAT", where only registered IP addresses are used in the translation, not port numbers. That is the model that my proposal is based on. However, it can be extended to NAPT as well. Sharif. -----Original Message----- From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] Sent: Thursday, June 14, 2001 4:38 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Sharif, In your proposed architecture, Basic Static NAT-routers are used. This means that a set of globally unique IP addresses (i.e., a set of registered addresses) is reserved by each NAT device (located in a NAT-enabled router) just for the purpose of for address translation, i.e., mapping the private address of each local private node that wants to communicate with an external node (i.e., CN) to one of the reserved global addresses. This is an one-to-one mapping within not only the NAT table but also the entire private network. Your proposal says that the format of a binding in the NAT is (Global IP Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the registered IP address of the NAT-enabled router itself or one of the globally unique IP addresses reserved by the NAT located in the router? If it is the former, then NAPT is used (instead of basic static NAT), where port numbers are involved in the address translation. If it is the later, then the format of a binding in the NAT should be (A Global IP Address Reserved by NAT, Local IP Address). Mingguey "Shahrier, Sharif M." wrote: > The binding is one global address to one private address for a given > session. > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Thursday, June 14, 2001 3:18 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > In the "System Architecture" section: > ... > The NAT tables have to be set up, to reflect the correct binding > between the global address of NAT-A and the local address of the > sender in A... > > Is the binding of one global address to one private address mapping? Or one > global > address to many private addresses mapping? > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 10:47:50 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10889 for ; Fri, 15 Jun 2001 10:47:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10901; Fri, 15 Jun 2001 08:48:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22094; Fri, 15 Jun 2001 07:47:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEl442020420 for ; Fri, 15 Jun 2001 07:47:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FEl4BK020419 for mobile-ip-dist; Fri, 15 Jun 2001 07:47:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEkx42020412 for ; Fri, 15 Jun 2001 07:46:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20281 for ; Fri, 15 Jun 2001 07:47:06 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10003 for ; Fri, 15 Jun 2001 08:47:04 -0600 (MDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA26825 for ; Fri, 15 Jun 2001 09:47:05 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5FEl4F24623 for ; Fri, 15 Jun 2001 09:47:04 -0500 (CDT) Message-ID: <3B2A2021.CF9029D0@usa.alcatel.com> Date: Fri, 15 Jun 2001 09:48:02 -0500 From: "Mingguey M. Yang" Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sharif, Then you mean that the format of a binding in the NAT should be (A Global IP Address Reserved by NAT, Local IP Address) instead of (Global IP Address of NAT, Local IP Address), right? Mingguey "Shahrier, Sharif M." wrote: > Mingguey, > > If you look at RFC 3022, it describes a "traditional NAT", where > only registered IP addresses are used in the translation, not port numbers. > That is the model that my proposal is based on. However, it can be extended > to NAPT as well. > > Sharif. > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Thursday, June 14, 2001 4:38 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > In your proposed architecture, Basic Static NAT-routers are used. This means > that a set of globally unique IP addresses (i.e., a set of registered > addresses) is reserved by each NAT device (located in a NAT-enabled router) > just for the purpose of for address translation, i.e., mapping the private > address of each local private node that wants to communicate with an > external > node (i.e., CN) to one of the reserved global addresses. This is an > one-to-one > mapping within not only the NAT table but also the entire private network. > > Your proposal says that the format of a binding in the NAT is (Global IP > Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the > registered IP address of the NAT-enabled router itself or one of the > globally > unique IP addresses reserved by the NAT located in the router? If it is the > former, then NAPT is used (instead of basic static NAT), where port numbers > are > involved in the address translation. If it is the later, then the format of > a > binding in the NAT should be (A Global IP Address Reserved by NAT, Local IP > Address). > > Mingguey > > "Shahrier, Sharif M." wrote: > > > The binding is one global address to one private address for a given > > session. > > > > -----Original Message----- > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > Sent: Thursday, June 14, 2001 3:18 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > Sharif, > > > > In the "System Architecture" section: > > ... > > The NAT tables have to be set up, to reflect the correct binding > > between the global address of NAT-A and the local address of the > > sender in A... > > > > Is the binding of one global address to one private address mapping? Or > one > > global > > address to many private addresses mapping? > > > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 11:53:55 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12537 for ; Fri, 15 Jun 2001 11:53:54 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15795; Fri, 15 Jun 2001 09:54:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04726; Fri, 15 Jun 2001 08:54:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FFrD42020574 for ; Fri, 15 Jun 2001 08:53:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FFrDVN020573 for mobile-ip-dist; Fri, 15 Jun 2001 08:53:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FFrA42020566 for ; Fri, 15 Jun 2001 08:53:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03744 for ; Fri, 15 Jun 2001 08:53:17 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14842 for ; Fri, 15 Jun 2001 09:53:16 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 11:52:16 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Date: Fri, 15 Jun 2001 11:52:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mingguey, I don't see the distinction between the two cases, since both cases would statically assign a few global addresses to the NAT-box, for mapping and transfer over the public backbone. Are you saying that in the second case the global IP addresses are NOT statically assigned? Sharif -----Original Message----- From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] Sent: Friday, June 15, 2001 10:48 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Sharif, Then you mean that the format of a binding in the NAT should be (A Global IP Address Reserved by NAT, Local IP Address) instead of (Global IP Address of NAT, Local IP Address), right? Mingguey "Shahrier, Sharif M." wrote: > Mingguey, > > If you look at RFC 3022, it describes a "traditional NAT", where > only registered IP addresses are used in the translation, not port numbers. > That is the model that my proposal is based on. However, it can be extended > to NAPT as well. > > Sharif. > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Thursday, June 14, 2001 4:38 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > In your proposed architecture, Basic Static NAT-routers are used. This means > that a set of globally unique IP addresses (i.e., a set of registered > addresses) is reserved by each NAT device (located in a NAT-enabled router) > just for the purpose of for address translation, i.e., mapping the private > address of each local private node that wants to communicate with an > external > node (i.e., CN) to one of the reserved global addresses. This is an > one-to-one > mapping within not only the NAT table but also the entire private network. > > Your proposal says that the format of a binding in the NAT is (Global IP > Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the > registered IP address of the NAT-enabled router itself or one of the > globally > unique IP addresses reserved by the NAT located in the router? If it is the > former, then NAPT is used (instead of basic static NAT), where port numbers > are > involved in the address translation. If it is the later, then the format of > a > binding in the NAT should be (A Global IP Address Reserved by NAT, Local IP > Address). > > Mingguey > > "Shahrier, Sharif M." wrote: > > > The binding is one global address to one private address for a given > > session. > > > > -----Original Message----- > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > Sent: Thursday, June 14, 2001 3:18 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > Sharif, > > > > In the "System Architecture" section: > > ... > > The NAT tables have to be set up, to reflect the correct binding > > between the global address of NAT-A and the local address of the > > sender in A... > > > > Is the binding of one global address to one private address mapping? Or > one > > global > > address to many private addresses mapping? > > > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 12:03:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12847 for ; Fri, 15 Jun 2001 12:03:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24963; Fri, 15 Jun 2001 10:03:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07129; Fri, 15 Jun 2001 09:03:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FG3642020617 for ; Fri, 15 Jun 2001 09:03:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FG35eC020616 for mobile-ip-dist; Fri, 15 Jun 2001 09:03:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FG3242020609 for ; Fri, 15 Jun 2001 09:03:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26275 for ; Fri, 15 Jun 2001 09:03:09 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24280 for ; Fri, 15 Jun 2001 10:03:08 -0600 (MDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA12025 for ; Fri, 15 Jun 2001 11:03:09 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5FG38D18453 for ; Fri, 15 Jun 2001 11:03:08 -0500 (CDT) Message-ID: <3B2A31F5.E3FAA22@usa.alcatel.com> Date: Fri, 15 Jun 2001 11:04:05 -0500 From: "Mingguey M. Yang" Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sharif, I just want to clarify what the "Global IP Address of NAT" means in the format of a binding of NAT. Is it the registered IP address of the NAT-enabled router itself or one of the globally unique IP addresses reserved by the NAT located in the router? Would you please identify which one it stands for? Mingguey "Shahrier, Sharif M." wrote: > Mingguey, > > I don't see the distinction between the two cases, since both cases > would statically assign a few global addresses > to the NAT-box, for mapping and transfer over the public backbone. Are you > saying that in the second case the global IP addresses are NOT statically > assigned? > > Sharif > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Friday, June 15, 2001 10:48 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > Then you mean that the format of a binding in the NAT should be (A Global IP > Address Reserved by NAT, Local IP > Address) instead of (Global IP Address of NAT, Local IP Address), right? > > Mingguey > > "Shahrier, Sharif M." wrote: > > > Mingguey, > > > > If you look at RFC 3022, it describes a "traditional NAT", where > > only registered IP addresses are used in the translation, not port > numbers. > > That is the model that my proposal is based on. However, it can be > extended > > to NAPT as well. > > > > Sharif. > > > > -----Original Message----- > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > Sent: Thursday, June 14, 2001 4:38 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > Sharif, > > > > In your proposed architecture, Basic Static NAT-routers are used. This > means > > that a set of globally unique IP addresses (i.e., a set of registered > > addresses) is reserved by each NAT device (located in a NAT-enabled > router) > > just for the purpose of for address translation, i.e., mapping the > private > > address of each local private node that wants to communicate with an > > external > > node (i.e., CN) to one of the reserved global addresses. This is an > > one-to-one > > mapping within not only the NAT table but also the entire private network. > > > > Your proposal says that the format of a binding in the NAT is (Global IP > > Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the > > registered IP address of the NAT-enabled router itself or one of the > > globally > > unique IP addresses reserved by the NAT located in the router? If it is > the > > former, then NAPT is used (instead of basic static NAT), where port > numbers > > are > > involved in the address translation. If it is the later, then the format > of > > a > > binding in the NAT should be (A Global IP Address Reserved by NAT, Local > IP > > Address). > > > > Mingguey > > > > "Shahrier, Sharif M." wrote: > > > > > The binding is one global address to one private address for a given > > > session. > > > > > > -----Original Message----- > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > Sent: Thursday, June 14, 2001 3:18 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > Sharif, > > > > > > In the "System Architecture" section: > > > ... > > > The NAT tables have to be set up, to reflect the correct binding > > > between the global address of NAT-A and the local address of the > > > sender in A... > > > > > > Is the binding of one global address to one private address mapping? Or > > one > > > global > > > address to many private addresses mapping? > > > > > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 13:10:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17042 for ; Fri, 15 Jun 2001 13:10:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17956; Fri, 15 Jun 2001 10:11:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22014; Fri, 15 Jun 2001 10:10:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FH9J42020737 for ; Fri, 15 Jun 2001 10:09:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FH9Igm020736 for mobile-ip-dist; Fri, 15 Jun 2001 10:09:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FH9F42020729 for ; Fri, 15 Jun 2001 10:09:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22636 for ; Fri, 15 Jun 2001 10:09:23 -0700 (PDT) Received: from hotmail.com (f147.law7.hotmail.com [216.33.237.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02563 for ; Fri, 15 Jun 2001 10:09:22 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Jun 2001 10:09:22 -0700 Received: from 63.78.179.4 by lw7fd.law7.hotmail.msn.com with HTTP; Fri, 15 Jun 2001 17:09:22 GMT X-Originating-IP: [63.78.179.4] From: "Hemant Chaskar" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement s for Mobile IP Date: Fri, 15 Jun 2001 17:09:22 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jun 2001 17:09:22.0816 (UTC) FILETIME=[EC485000:01C0F5BD] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Murat: Some answers inline. >From: "Bilgic, Murat" >Reply-To: mobile-ip@sunroof.eng.sun.com >To: "'mobile-ip@sunroof.eng.sun.com'" >Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement >s for Mobile IP >Date: Tue, 12 Jun 2001 17:24:50 -0700 > > > >Also do you think, if > > >the MN should be able to resolve such conflicts based on only local > > >knowledge or does it require the network's assistance while making that > > >decision? (As you may guess, I'm trying to state this as a requirement > > not > > >as some form of design parameter.) > > > > [HC] So much of a detail tends to drive us into solution space and >reduces > > > > the flexibility of solution design. > [MB] I disagree on this one. But probably I should clarify my >reasoning. I see the two ends of the spectrum of solutions as follows: > 1. MN does not need any authorization prior to a mobility event for >QoS. Therefore, the network is (over-)provisioned to accommodate such >events. Obviously this does not mean that after the mobility event, the >network can't force a degradation in the provided QoS, but the application >demanding QoS has a much longer time to adopt itself. The benefit I see for >this end of the spectrum is potentially faster and simpler mobility. BTW, >this was what I was referring as "local knowledge". > 2. MN needs authorization, i.e., negotiation with the network prior >to a mobility event for QoS. Therefore, the network is provisioned just the >"right amount". However, the mobility mechanism is most likely more complex >and slower. In addition, the application has to react much faster to >degradation in the provided QoS. Again, this was what I was referring to as >"network assistance". > > In my opinion, there is a very big difference between these two >approaches. If you are saying the requirement is so broad such that any >solution within this spectrum would be acceptable, then I'd have difficulty >accepting the value of requirements development phase. [HC] This issue had surfaced on the mailing list. At that time, the concensus was that we would work from a point onwards when the target AR for handover is "pinned down". That is also the working assumption in some other task items such as fast handover and context transfer. Now pinning down the target AR for handover may involve negotiation phase as you have described in one extreme case or "I am going there anyway" case as you have described in the other extreme case. The task of pinning down the target AR may be solved in other task items such as candidate access router discovery task item of Seamoby charter. In any case, if the new AR cannot provide QoS that was obtainable from the old one, MN applications have to reach to it. Some people thought of it as not necessarily the Mobile IP specific requirement, rather a general area of elastic applications when network QoS degrades. However, in my opinion this event will happen more often in mobile environments. So, if people think that something to that effect must be included in the requirements, I will do that. > > > > > > >4. How should I intrepret your requirement on heterogeneous end-to-end > > >packet paths? Does it mean that the MN has to be aware of the entire > > >network > > >topology, e.g., where diffserv, intserv, MPLS or any other mechanism is > > >used > > >and how and where it is interworked? Since I don't currently have to do > > >that > > >for my non-mobile host, I wonder again why is this requirement imposed > > for > > >mobile hosts? > > > > [HC] There is no QoS in Internet today, and that's why you do not have >to > > do > > it for your non-mobile host. > > > > Further, if you have a static host, it is possible to configure in it >the > > QoS functions that the access network expects the host to perform and > > those > > functions are not going to change during the ongoing session. For >example, > > > > the service provider can tell you that it uses DiffServ in access and >can > > give you a configuration file that tells what port numbers to use for >say > > EF > > traffic so that the network can classify that traffic. In the mobile >case, > > > > the MN may move across differnt access networks. > > > > Also, believe me that some knowledge about the end-to-end packet path is > > required for end-to-end QoS. The host may not have this knowledge but >the > > network needs to have it. It could be by virtue of SLAs between DiffServ > > domains, or such knowledge can be acquired by RSVP signalling {RFC 2998) > > over a mix of IntServ and DiffServ networks. > [MB] I don't dispute that end-to-end QoS requires some form of >capability to signal what you are looking for from the MN's side or what >you >should use from the network side. However, as articulated quite >convincingly >in RFC 2990, it's quite hard to imagine one framework, i.e., a holy grail >to >solve this problem. If (at least as of today it's true) there is no >unifying >QoS framework for Internet, then I'd say the argument for one for mobile >hosts is pretty weak. Instead, wouldn't it be better to put together a more >limited requirement stating that a network's QoS capabilities are used in >determining the mobility decision within the MN. In this case, there is no >reason for a "one-size fits all" QoS solution and MNs would still make >informed decisions. In addition end-to-end QoS mechanism(s) can be kept >entirely separate from mobile IP. What do you think? [HC] I think this is a good suggestion. We can phrase it something like this: Network's QoS capabilities SHOULD be used in determining the mobility decision within the MN. "One-size fits all" may not be a good approach as you have rightly suggested. Let me think more about it before formulating the right kind of requirement. > > > > > >Thanks in advance for your answers, > > > > [HC] I hope this clarifies some of your concerns. Thanks for your > > comments. > > > > [Hemant] > [MB] Thank you, > > Murat Bilgic [Hemant] _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 14:24:58 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21377 for ; Fri, 15 Jun 2001 14:24:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25867; Fri, 15 Jun 2001 12:25:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10352; Fri, 15 Jun 2001 11:25:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FIOF42021274 for ; Fri, 15 Jun 2001 11:24:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FIOFal021273 for mobile-ip-dist; Fri, 15 Jun 2001 11:24:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FIOC42021266 for ; Fri, 15 Jun 2001 11:24:12 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09803 for ; Fri, 15 Jun 2001 11:24:18 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13796 for ; Fri, 15 Jun 2001 11:24:12 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Jun 2001 14:23:09 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Date: Fri, 15 Jun 2001 14:23:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The meaning of term "Global IP Address of NAT" is: (1) It is an address from the registered public address space. (2) It is statically assigned to the NAT as a global address for communication over the backbone. Sharif -----Original Message----- From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] Sent: Friday, June 15, 2001 12:04 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Sharif, I just want to clarify what the "Global IP Address of NAT" means in the format of a binding of NAT. Is it the registered IP address of the NAT-enabled router itself or one of the globally unique IP addresses reserved by the NAT located in the router? Would you please identify which one it stands for? Mingguey "Shahrier, Sharif M." wrote: > Mingguey, > > I don't see the distinction between the two cases, since both cases > would statically assign a few global addresses > to the NAT-box, for mapping and transfer over the public backbone. Are you > saying that in the second case the global IP addresses are NOT statically > assigned? > > Sharif > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Friday, June 15, 2001 10:48 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > Then you mean that the format of a binding in the NAT should be (A Global IP > Address Reserved by NAT, Local IP > Address) instead of (Global IP Address of NAT, Local IP Address), right? > > Mingguey > > "Shahrier, Sharif M." wrote: > > > Mingguey, > > > > If you look at RFC 3022, it describes a "traditional NAT", where > > only registered IP addresses are used in the translation, not port > numbers. > > That is the model that my proposal is based on. However, it can be > extended > > to NAPT as well. > > > > Sharif. > > > > -----Original Message----- > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > Sent: Thursday, June 14, 2001 4:38 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > Sharif, > > > > In your proposed architecture, Basic Static NAT-routers are used. This > means > > that a set of globally unique IP addresses (i.e., a set of registered > > addresses) is reserved by each NAT device (located in a NAT-enabled > router) > > just for the purpose of for address translation, i.e., mapping the > private > > address of each local private node that wants to communicate with an > > external > > node (i.e., CN) to one of the reserved global addresses. This is an > > one-to-one > > mapping within not only the NAT table but also the entire private network. > > > > Your proposal says that the format of a binding in the NAT is (Global IP > > Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the > > registered IP address of the NAT-enabled router itself or one of the > > globally > > unique IP addresses reserved by the NAT located in the router? If it is > the > > former, then NAPT is used (instead of basic static NAT), where port > numbers > > are > > involved in the address translation. If it is the later, then the format > of > > a > > binding in the NAT should be (A Global IP Address Reserved by NAT, Local > IP > > Address). > > > > Mingguey > > > > "Shahrier, Sharif M." wrote: > > > > > The binding is one global address to one private address for a given > > > session. > > > > > > -----Original Message----- > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > Sent: Thursday, June 14, 2001 3:18 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > Sharif, > > > > > > In the "System Architecture" section: > > > ... > > > The NAT tables have to be set up, to reflect the correct binding > > > between the global address of NAT-A and the local address of the > > > sender in A... > > > > > > Is the binding of one global address to one private address mapping? Or > > one > > > global > > > address to many private addresses mapping? > > > > > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 16:20:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27932 for ; Fri, 15 Jun 2001 16:20:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13925; Fri, 15 Jun 2001 13:20:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09714; Fri, 15 Jun 2001 13:20:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FKJ242021442 for ; Fri, 15 Jun 2001 13:19:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FKJ2YE021441 for mobile-ip-dist; Fri, 15 Jun 2001 13:19:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FKIw42021434 for ; Fri, 15 Jun 2001 13:18:58 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09525 for ; Fri, 15 Jun 2001 13:19:06 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00737 for ; Fri, 15 Jun 2001 13:19:05 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA19203 for ; Fri, 15 Jun 2001 15:19:05 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5FKJ4p10795 for ; Fri, 15 Jun 2001 15:19:04 -0500 (CDT) Message-ID: <3B2A6DF1.5BDD78D1@usa.alcatel.com> Date: Fri, 15 Jun 2001 15:20:01 -0500 From: "Mingguey M. Yang" Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sharif, Thank you for clarifying the term. So, it is indeed one of the globally unique IP addresses reserved by the NAT for address translation. Would you please also clarify my another confusion? With the nat-binding-update message (sent from the MN to the NAT) and mobile-location-solicitation message (sent from the CN to the mobile-database), you obviously assume that both CN and MN are aware of that the MN is a private node. But this is against the principle of using NAT. As stated in RFC 3022, NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. That is, both the CN and MN have no idea of the existence of the NAT. The NAT translates the MN's private address to a global address (i.e., NAT-translated address) in all the outgoing IP packets from the MN, and vice versa for the IP packets in the reverse flow. The CN only sees the MN as a public node because the NAT-translated global address is shown in the source address field of all the packets from the MN. The MN never realizes that its private address has been mapped to a global address and the CN can only recognize it by its NAT-translated global address. Most importantly, the MN has no idea of the existence of the global address. Otherwise, the MN should have used it instead of its private address to communicate with the CN in the first place. Would you plase explain this confliction? Thanks. Mingguey "Shahrier, Sharif M." wrote: > The meaning of term "Global IP Address of NAT" is: > > (1) It is an address from the registered public address space. > (2) It is statically assigned to the NAT as a global address for > communication over the backbone. > > Sharif > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Friday, June 15, 2001 12:04 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > I just want to clarify what the "Global IP Address of NAT" means in the > format > of a binding of NAT. > Is it the registered IP address of the NAT-enabled router itself or one of > the > globally unique IP addresses reserved by the NAT located in the router? > Would you please identify which one it stands for? > > Mingguey > > "Shahrier, Sharif M." wrote: > > > Mingguey, > > > > I don't see the distinction between the two cases, since both > cases > > would statically assign a few global addresses > > to the NAT-box, for mapping and transfer over the public backbone. Are you > > saying that in the second case the global IP addresses are NOT statically > > assigned? > > > > Sharif > > > > -----Original Message----- > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > Sent: Friday, June 15, 2001 10:48 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > Sharif, > > > > Then you mean that the format of a binding in the NAT should be (A Global > IP > > Address Reserved by NAT, Local IP > > Address) instead of (Global IP Address of NAT, Local IP Address), right? > > > > Mingguey > > > > "Shahrier, Sharif M." wrote: > > > > > Mingguey, > > > > > > If you look at RFC 3022, it describes a "traditional NAT", where > > > only registered IP addresses are used in the translation, not port > > numbers. > > > That is the model that my proposal is based on. However, it can be > > extended > > > to NAPT as well. > > > > > > Sharif. > > > > > > -----Original Message----- > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > Sent: Thursday, June 14, 2001 4:38 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > Sharif, > > > > > > In your proposed architecture, Basic Static NAT-routers are used. This > > means > > > that a set of globally unique IP addresses (i.e., a set of registered > > > addresses) is reserved by each NAT device (located in a NAT-enabled > > router) > > > just for the purpose of for address translation, i.e., mapping the > > private > > > address of each local private node that wants to communicate with an > > > external > > > node (i.e., CN) to one of the reserved global addresses. This is an > > > one-to-one > > > mapping within not only the NAT table but also the entire private > network. > > > > > > Your proposal says that the format of a binding in the NAT is (Global IP > > > Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the > > > registered IP address of the NAT-enabled router itself or one of the > > > globally > > > unique IP addresses reserved by the NAT located in the router? If it is > > the > > > former, then NAPT is used (instead of basic static NAT), where port > > numbers > > > are > > > involved in the address translation. If it is the later, then the format > > of > > > a > > > binding in the NAT should be (A Global IP Address Reserved by NAT, Local > > IP > > > Address). > > > > > > Mingguey > > > > > > "Shahrier, Sharif M." wrote: > > > > > > > The binding is one global address to one private address for a given > > > > session. > > > > > > > > -----Original Message----- > > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > > Sent: Thursday, June 14, 2001 3:18 PM > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > > > Sharif, > > > > > > > > In the "System Architecture" section: > > > > ... > > > > The NAT tables have to be set up, to reflect the correct binding > > > > between the global address of NAT-A and the local address of the > > > > sender in A... > > > > > > > > Is the binding of one global address to one private address mapping? > Or > > > one > > > > global > > > > address to many private addresses mapping? > > > > > > > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 16:57:09 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29452 for ; Fri, 15 Jun 2001 16:57:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18548; Fri, 15 Jun 2001 14:57:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17387; Fri, 15 Jun 2001 13:57:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FKuJ42021546 for ; Fri, 15 Jun 2001 13:56:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FKuJwj021545 for mobile-ip-dist; Fri, 15 Jun 2001 13:56:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FKuF42021538 for ; Fri, 15 Jun 2001 13:56:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11101 for ; Fri, 15 Jun 2001 13:56:24 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17404 for ; Fri, 15 Jun 2001 13:56:23 -0700 (PDT) Received: from msubbara-u10.cisco.com (msubbara-u10.cisco.com [64.102.66.20]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5FKuTU12081; Fri, 15 Jun 2001 13:56:29 -0700 (PDT) Received: (msubbara@localhost) by msubbara-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA14998; Fri, 15 Jun 2001 16:56:16 -0400 (EDT) Date: Fri, 15 Jun 2001 16:56:16 -0400 From: Madhavi Subbarao To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] HA Redundancy draft Message-ID: <20010615165616.A14994@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi All, We recently submitted a draft on "Home Agent Redundancy in Mobile IP" (draft-subbarao-mobileip-redundancy-00.txt). I'm not sure when the drafts announcement will be made...so here is the link: http://search.ietf.org/internet-drafts/draft-subbarao-mobileip-redundancy-00.txt Comments and feedback are welcome! Thanks, Madhavi From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 20:27:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02086 for ; Fri, 15 Jun 2001 20:27:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15205; Fri, 15 Jun 2001 18:27:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26700; Fri, 15 Jun 2001 17:27:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5G0Ql42021980 for ; Fri, 15 Jun 2001 17:26:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5G0QlJU021979 for mobile-ip-dist; Fri, 15 Jun 2001 17:26:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5G0Qh42021972 for ; Fri, 15 Jun 2001 17:26:44 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5G0QmG939479 for ; Fri, 15 Jun 2001 17:26:48 -0700 (PDT) Message-Id: <200106160026.f5G0QmG939479@jurassic.eng.sun.com> Date: Fri, 15 Jun 2001 17:26:52 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: B2zaXLqg5CyNVJY8g3Gcyw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barani, Is there any reason why this mobile node cannot have both interfaces connected at the same time? Do you have a scenario where it can or it should have only one connected, although they are using different interfaces? alper > > Alper, > > No. It is a single mobile with multiple links but connects via a single link at > any given time to a single AR. However, after hand off it connects to new AR via > a different link. Example would be WLAN and WWAN or any other combination. > > Barani. > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: Alper Yegin > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > Barani, > > > As in the draft and this thread, I like to point out that Link layer address > > based verification across ARs should be avoided as much as possible. > > MN can have two interfaces and also move from one AR to another AR using the > new > > L2 interface. > > > > If we want L2 identifier then there should be a way that MN can indicate to > the > > old AR about the new Link layer ID that it will be using plus the current L2 > ID. > > > > If this is a mobile node with multiple links, which can be connected to > different ARs at the same time, you most probably don't need FMIPv6 draft. > > alper > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 15 20:41:31 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02241 for ; Fri, 15 Jun 2001 20:41:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20820; Fri, 15 Jun 2001 18:41:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28843; Fri, 15 Jun 2001 17:41:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5G0ep42022025 for ; Fri, 15 Jun 2001 17:40:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5G0eptQ022024 for mobile-ip-dist; Fri, 15 Jun 2001 17:40:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5G0em42022017 for ; Fri, 15 Jun 2001 17:40:48 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5G0eqG941854 for ; Fri, 15 Jun 2001 17:40:52 -0700 (PDT) Message-Id: <200106160040.f5G0eqG941854@jurassic.eng.sun.com> Date: Fri, 15 Jun 2001 17:40:56 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Byld2S/MWxxW6prld3xzuw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hesham, > > > > > => Not quite, that maybe true in the network determined case where > > > > > the MN does not send a BU to the old AR. If the MN sends a BU > > > > > then it MUST be able to request bicasting for a number of reasons: > > > > > > > > > > 1. BU list management in terms of lifetimes > > > > Can you please elaborate this, I didn't get it. > > > => You need to know how long a Binding Update entry is valid for. > Ie. how long will the AR forward to a particular address for. > If you don't communicate that in the BU there is no > way of knowing when to remove the entry, or when the > AR will require a refresh, or when it will stop forwarding. > > So if you're bicasting you need to know how long the bicasting > lifetime is. Bi-casting lifetime is different than binding cache lifetime, right? I'm guessing you wouldn't want your oldAR to bi-cast as long as it has a binding cache entry of the oldCoA. Binding cache entry lifetime is dealed with the Binding Update already. And bi-cast lifetime, which is presumably a very short period, a L2 dependent duration, can be determined by oldAR. And mobile node wouldn't even know when it started, when it's terminated (given that it reecives single stream of data). > > > > => I am referring to an example of a case where the MN > > > has two interfaces and can receive two traffic streams > > > simultaneously. I don't expect a router connected > > > to a WCDMA network to know that there is a WLAN > > > network nearby and that the MN can hear both. > > > I don't think this should be expected. > > > > > > Why do we need FMIPv6 in this case? You have two simultaneously connected > > interfaces.. > > > => You don't, which is what I was saying. You were saying that there are cases (such as above) where MN wouldn't request bi-casting, as it's not needed. According to your logic (if I'm following it right) that means we need a flag or something in the BU "not to request" bi-casting. But, if we are not talking about FMIPv6 (as you agreed above), then we are not talking about having such a flag in F-BU. When oldAR receives a F-BU, it can bi-cast. When it recevies regular BU, it can choose not to bi-cast. So, I don't see how this example justifies that MN needs the capability to request bi-casting. alper From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 02:01:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21818 for ; Mon, 18 Jun 2001 02:01:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19576; Mon, 18 Jun 2001 00:01:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA08562; Sun, 17 Jun 2001 23:01:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I60pdP023500 for ; Sun, 17 Jun 2001 23:00:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5I60psm023499 for mobile-ip-dist; Sun, 17 Jun 2001 23:00:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I60ldP023492 for ; Sun, 17 Jun 2001 23:00:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24641; Sun, 17 Jun 2001 23:00:54 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA26688; Sun, 17 Jun 2001 23:00:52 -0700 (PDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id PAA06359; Mon, 18 Jun 2001 15:03:05 +0900 (KST) Message-ID: <004901c0f7bb$fee8f980$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: Cc: "Pat Calhoun" Subject: [mobile-ip] MN-AAA entension clarification Date: Mon, 18 Jun 2001 15:00:34 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C0F807.6D80F000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C0F807.6D80F000 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SEkhDQoNCkluIFJGQy0zMDEyLCBpdCBpcyBub3QgY2xlYXIgd2hldGhlciBGb3JlaWduIEFnZW50 IGluY2x1ZGVzIE1OLUFBQSBleHRlbnNpb24gdG8gdGhlIFJSUSBhZnRlciBNTi1BQUEgYXV0aGVu dGljYXRpb24gYnkgdmVyaWZpY2F0aW9uIGluZnJhc3RydWN0dXJlLg0KDQpTbywgaW4gM0dQUDIg cGFja2V0IHN5c3RlbSBQRFNOLCBpdCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4gIEFuZCBl YWNoIFBEU04gdmVuZG9yIGhhcyB0aGVpciBvd24gaW50ZXJwcmV0YXRpb24uICBJIHdpc2ggTW9i aWxlIElQIHdvcmsgZ3JvdXAgY2FuIGNsYXJpZnkgdGhpcy4NCg0KUmVnYXJkcywNCkpIIFNPTkcN Cg== ------=_NextPart_000_0046_01C0F807.6D80F000 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhJITwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkluIFJGQy0zMDEyLCBpdCBpcyBub3QgY2xlYXIgd2hldGhlciBGb3JlaWduIEFn ZW50IGluY2x1ZGVzIA0KTU4tQUFBIGV4dGVuc2lvbiB0byB0aGUgUlJRIGFmdGVyIE1OLUFBQSBh dXRoZW50aWNhdGlvbiBieSB2ZXJpZmljYXRpb24gDQppbmZyYXN0cnVjdHVyZS48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj5TbywgaW4gM0dQUDIgcGFja2V0IHN5c3RlbSBQRFNOLCBpdCBpcyBhbiBpbXBsZW1lbnRh dGlvbiANCmlzc3VlLiZuYnNwOyBBbmQgZWFjaCBQRFNOIHZlbmRvciBoYXMgdGhlaXIgb3duIGlu dGVycHJldGF0aW9uLiZuYnNwOyBJIHdpc2ggDQpNb2JpbGUgSVAgd29yayBncm91cCBjYW4gY2xh cmlmeSB0aGlzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+SkggU09ORzwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0046_01C0F807.6D80F000-- From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 03:22:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01638 for ; Mon, 18 Jun 2001 03:22:37 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA21647; Mon, 18 Jun 2001 00:22:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25954; Mon, 18 Jun 2001 00:22:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I7LKdP023635 for ; Mon, 18 Jun 2001 00:21:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5I7LKTe023634 for mobile-ip-dist; Mon, 18 Jun 2001 00:21:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I7LGdP023627 for ; Mon, 18 Jun 2001 00:21:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01048 for ; Mon, 18 Jun 2001 00:21:24 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22676 for ; Mon, 18 Jun 2001 01:21:21 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5I7LMN15732 for ; Mon, 18 Jun 2001 09:21:22 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Jun 18 09:21:21 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 09:21:20 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF44@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Mon, 18 Jun 2001 09:21:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, > > > > > > => Not quite, that maybe true in the network determined case > where > > > > > > the MN does not send a BU to the old AR. If the MN sends a BU > > > > > > then it MUST be able to request bicasting for a number of > reasons: > > > > > > > > > > > > 1. BU list management in terms of lifetimes > > > > > > Can you please elaborate this, I didn't get it. > > > > > => You need to know how long a Binding Update entry is valid for. > > Ie. how long will the AR forward to a particular address for. > > If you don't communicate that in the BU there is no > > way of knowing when to remove the entry, or when the > > AR will require a refresh, or when it will stop forwarding. > > > > So if you're bicasting you need to know how long the bicasting > > lifetime is. > > > Bi-casting lifetime is different than binding cache lifetime, right? > => No, it is a binding cache entry. It's different for one of the addresses if that's what you mean. Ie. not one lifetime for both addresses. > I'm > guessing you wouldn't want your oldAR to bi-cast as long as it has a binding > cache entry of the oldCoA. > => Correct. > Binding cache entry lifetime is dealed with the Binding Update already. And > bi-cast lifetime, which is presumably a very short period, a L2 dependent > duration, can be determined by oldAR. > => No. The MN still has to know. You might want to extend it. For example ping pong might occur for a longer period than expected. > > > > > > => I am referring to an example of a case where the MN > > > > has two interfaces and can receive two traffic streams > > > > simultaneously. I don't expect a router connected > > > > to a WCDMA network to know that there is a WLAN > > > > network nearby and that the MN can hear both. > > > > I don't think this should be expected. > > > > > > > > > Why do we need FMIPv6 in this case? You have two simultaneously connected > > > interfaces.. > > > > > => You don't, which is what I was saying. > > You were saying that there are cases (such as above) where MN wouldn't request > bi-casting, as it's not needed. According to your logic (if I'm following it > right) that means we need a flag or something in the BU "not to request" > bi-casting. But, if we are not talking about FMIPv6 (as you agreed above), then > we are not talking about having such a flag in F-BU. > => You're referring to one particular case above, there maybe other cases where bicasting doesn't need to be a default behaviour. We will deal with those examples in the draft. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 05:07:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02318 for ; Mon, 18 Jun 2001 05:07:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17780; Mon, 18 Jun 2001 03:07:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07702; Mon, 18 Jun 2001 02:07:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I96IdP023786 for ; Mon, 18 Jun 2001 02:06:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5I96Iee023785 for mobile-ip-dist; Mon, 18 Jun 2001 02:06:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I96EdP023778 for ; Mon, 18 Jun 2001 02:06:14 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21992 for ; Mon, 18 Jun 2001 02:06:23 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17934 for ; Mon, 18 Jun 2001 02:06:22 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5I96HO24743 for ; Mon, 18 Jun 2001 11:06:17 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA23460; Mon, 18 Jun 2001 11:06:15 +0200 Message-ID: <3B2DC43B.5EA933A0@era.ericsson.se> Date: Mon, 18 Jun 2001 11:04:59 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Ulf =?iso-8859-1?Q?Bj=F6rklund?= Subject: [mobile-ip] Mobile IPv6 clarifications Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, We've been playing aroung with MIPv6 for a while and came up with these considerations: 1. Let's say the MN is away and is registered with the HA, and then the MN either A) reboots/crashes (unintentional) B) is shut off (intentional) for some reason. In A), it has no way of de-registering with the HA before the crash. In B) I don't think you have the possibility anyway according to the spec, since the MN isn't at home. Some might say that the MN should store state on non-volatile memory, but can all platforms support that? Anyway, the MN comes up again and tries to register with the HA. The binding in the HA is still valid for the remaining lifetime based on - Home prefix lifetime - Care-of prefix lifetime - MN policy - HA policy and can be anything from seconds to weeks. The HA has an associated sequence number S with the binding, and S >= 0. A fresh registration from the MN would use sequence number 0. So MN sends a BU with seq no T = 0. The HA compares it with S, and silently ignores the BU if the T <= S. After timeout (1 second at first), the MN re-transmits the BU, now with T increased. It can be increased with any value D, please see below. MN will keep retransmitting the BU with exponential backoff for the interval. Finally T > S, and the HA will accept the registration. How long time this will take and how many BUs it will require of course depends on S and D. Let's set D=1. If S is large, it will take very long time for MN to register. It is likely that the binding expires, rather than T reaches S. If D is large, say 8192 which is 1/8th of the total sequence number space (16 bit), we could reach S after max 8 transmitted BUs (but also see next question). On the other hand, that will quickly consume large parts of the sequence number space. Our suggestion is that we instead define a new BA status code (139?) of "sequence number too small". If the HA recieves a BU where T <= S, it must instead send a BA back to MN with status = 139 and the sequence number field set to S. The MN will retransmit the BU and now use T = S + D (D=1 comes to mind as best choice). Does anyone see a security problem here? The HA only exposes what has already been transmitted over the wire. The HA doesn't need to keep state for this. 2. There should be a statement about sequence numbers. According to the sequence number comparison method, the number 0 is smaller than 1 up to 32767, but greater than 32768 up to 65535. If MN sends a BU with sequence number 0 at some point, it can use all sequence numbers up to 32767. After that, it must renegotiate SA with the peer (HA/CN), or it will be exposed to a potential replay attack. /Mattias and Ulf From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 05:52:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02559 for ; Mon, 18 Jun 2001 05:52:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13123; Mon, 18 Jun 2001 03:52:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25212; Mon, 18 Jun 2001 02:52:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I9prdP023842 for ; Mon, 18 Jun 2001 02:51:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5I9pr2X023841 for mobile-ip-dist; Mon, 18 Jun 2001 02:51:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I9pndP023834 for ; Mon, 18 Jun 2001 02:51:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05379 for ; Mon, 18 Jun 2001 02:51:56 -0700 (PDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12562 for ; Mon, 18 Jun 2001 03:51:49 -0600 (MDT) Received: from cwc-ibxus8n62wn.cwc.nus.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.10.0/8.10.0) with ESMTP id f5I9pX528255 for ; Mon, 18 Jun 2001 17:51:33 +0800 (SST) Message-Id: <5.1.0.14.2.20010618174302.00ac2030@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Jun 2001 17:57:39 +0800 To: mobile-ip@sunroof.eng.sun.com From: Charles Qi Shen Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 In-Reply-To: <200106160026.f5G0QmG939479@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, I am not aware of what kinds of scenarios Barani may have in his mind. Please see whether my scenario can be something close to that. For example, you have a Mobile Node with two interfaces, one GPRS and one Wireless LAN, your company is covered by WLAN and you can use it for free within the company, while you are outside you will use GPRS. Since you pay for your GPRS but not the WLAN. You may wish to use WLAN *only* while inside the Company. In this case, it is not really this mobile node *cannot* have both interfaces connected, but it is the user choosing so. Charles At 05:26 PM 6/15/2001 -0700, you wrote: >Barani, > >Is there any reason why this mobile node cannot have both interfaces >connected >at the same time? Do you have a scenario where it can or it should have >only one >connected, although they are using different interfaces? > >alper > > > > > > Alper, > > > > No. It is a single mobile with multiple links but connects via a single > link >at > > any given time to a single AR. However, after hand off it connects to > new AR >via > > a different link. Example would be WLAN and WWAN or any other combination. > > > > Barani. > > > > > > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: Alper Yegin > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > Barani, > > > > > As in the draft and this thread, I like to point out that Link layer > address > > > based verification across ARs should be avoided as much as possible. > > > MN can have two interfaces and also move from one AR to another AR > using the > > new > > > L2 interface. > > > > > > If we want L2 identifier then there should be a way that MN can > indicate to > > the > > > old AR about the new Link layer ID that it will be using plus the > current L2 > > ID. > > > > > > > If this is a mobile node with multiple links, which can be connected to > > different ARs at the same time, you most probably don't need FMIPv6 draft. > > > > alper > > > > > > > > > > > >alper SHEN, Qi (Charles) Centre for Wireless Communications National University of Singapore 20 Science Park Rd. #02-34/37, TeleTech Park Singapore Science Park II, Singapore 117674 Tel: +65 870-9358 Fax: +65 779-5441 Email: shenqi@cwc.nus.edu.sg URL: http://www.cwc.nus.edu.sg From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 05:54:13 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02597 for ; Mon, 18 Jun 2001 05:54:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07654; Mon, 18 Jun 2001 02:54:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25376; Mon, 18 Jun 2001 02:54:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I9rSdP023865 for ; Mon, 18 Jun 2001 02:53:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5I9rS63023864 for mobile-ip-dist; Mon, 18 Jun 2001 02:53:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5I9rOdP023854 for ; Mon, 18 Jun 2001 02:53:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25313 for ; Mon, 18 Jun 2001 02:53:32 -0700 (PDT) Received: from leonis.nus.edu.sg (leonis.nus.edu.sg [137.132.1.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01281 for ; Mon, 18 Jun 2001 03:54:16 -0600 (MDT) Received: from cwc-ibxus8n62wn.cwc.nus.edu.sg ([137.132.31.150]) by leonis.nus.edu.sg (8.10.0/8.10.0) with ESMTP id f5I9rF528724 for ; Mon, 18 Jun 2001 17:53:15 +0800 (SST) Message-Id: <5.1.0.14.2.20010618165815.00abba40@postman.cwc.nus.edu.sg> X-Sender: shenqi@postman.cwc.nus.edu.sg X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Jun 2001 17:59:16 +0800 To: mobile-ip@sunroof.eng.sun.com From: Charles Qi Shen Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement s for Mobile IP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I quite agree with the argument "There is no reason for a "one-size fits all" QoS solution". However the following sentence sounds confusing to me, "Network's QoS capabilities SHOULD be used in determining the mobility decision within the MN. " Don't we have both Network determined and MN determined handoff scenarios for mobility? So why only say within MN? Charles At 05:09 PM 6/15/2001 +0000, you wrote: >Hi Murat: > >Some answers inline. > > >>From: "Bilgic, Murat" >>Reply-To: mobile-ip@sunroof.eng.sun.com >>To: "'mobile-ip@sunroof.eng.sun.com'" >>Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement >>s for Mobile IP >>Date: Tue, 12 Jun 2001 17:24:50 -0700 >> >> > >Also do you think, if >> > >the MN should be able to resolve such conflicts based on only local >> > >knowledge or does it require the network's assistance while making that >> > >decision? (As you may guess, I'm trying to state this as a requirement >> > not >> > >as some form of design parameter.) >> > >> > [HC] So much of a detail tends to drive us into solution space and reduces >> > >> > the flexibility of solution design. >> [MB] I disagree on this one. But probably I should clarify my >>reasoning. I see the two ends of the spectrum of solutions as follows: >> 1. MN does not need any authorization prior to a mobility event for >>QoS. Therefore, the network is (over-)provisioned to accommodate such >>events. Obviously this does not mean that after the mobility event, the >>network can't force a degradation in the provided QoS, but the application >>demanding QoS has a much longer time to adopt itself. The benefit I see for >>this end of the spectrum is potentially faster and simpler mobility. BTW, >>this was what I was referring as "local knowledge". >> 2. MN needs authorization, i.e., negotiation with the network prior >>to a mobility event for QoS. Therefore, the network is provisioned just the >>"right amount". However, the mobility mechanism is most likely more complex >>and slower. In addition, the application has to react much faster to >>degradation in the provided QoS. Again, this was what I was referring to as >>"network assistance". >> >> In my opinion, there is a very big difference between these two >>approaches. If you are saying the requirement is so broad such that any >>solution within this spectrum would be acceptable, then I'd have difficulty >>accepting the value of requirements development phase. > >[HC] This issue had surfaced on the mailing list. At that time, the >concensus was that we would work from a point onwards when the target AR >for handover is "pinned down". That is also the working assumption in some >other task items such as fast handover and context transfer. Now pinning >down the target AR for handover may involve negotiation phase as you have >described in one extreme case or "I am going there anyway" case as you >have described in the other extreme case. The task of pinning down the >target AR may be solved in other task items such as candidate access >router discovery task item of Seamoby charter. In any case, if the new AR >cannot provide QoS that was obtainable from the old one, MN applications >have to reach to it. Some people thought of it as not necessarily the >Mobile IP specific requirement, rather a general area of elastic >applications when network QoS degrades. However, in my opinion this event >will happen more often in mobile environments. So, if people think that >something to that effect must be included in the requirements, I will do that. > >> >> > > >> > >4. How should I intrepret your requirement on heterogeneous end-to-end >> > >packet paths? Does it mean that the MN has to be aware of the entire >> > >network >> > >topology, e.g., where diffserv, intserv, MPLS or any other mechanism is >> > >used >> > >and how and where it is interworked? Since I don't currently have to do >> > >that >> > >for my non-mobile host, I wonder again why is this requirement imposed >> > for >> > >mobile hosts? >> > >> > [HC] There is no QoS in Internet today, and that's why you do not have to >> > do >> > it for your non-mobile host. >> > >> > Further, if you have a static host, it is possible to configure in it the >> > QoS functions that the access network expects the host to perform and >> > those >> > functions are not going to change during the ongoing session. For example, >> > >> > the service provider can tell you that it uses DiffServ in access and can >> > give you a configuration file that tells what port numbers to use for say >> > EF >> > traffic so that the network can classify that traffic. In the mobile case, >> > >> > the MN may move across differnt access networks. >> > >> > Also, believe me that some knowledge about the end-to-end packet path is >> > required for end-to-end QoS. The host may not have this knowledge but the >> > network needs to have it. It could be by virtue of SLAs between DiffServ >> > domains, or such knowledge can be acquired by RSVP signalling {RFC 2998) >> > over a mix of IntServ and DiffServ networks. >> [MB] I don't dispute that end-to-end QoS requires some form of >>capability to signal what you are looking for from the MN's side or what you >>should use from the network side. However, as articulated quite convincingly >>in RFC 2990, it's quite hard to imagine one framework, i.e., a holy grail to >>solve this problem. If (at least as of today it's true) there is no unifying >>QoS framework for Internet, then I'd say the argument for one for mobile >>hosts is pretty weak. Instead, wouldn't it be better to put together a more >>limited requirement stating that a network's QoS capabilities are used in >>determining the mobility decision within the MN. In this case, there is no >>reason for a "one-size fits all" QoS solution and MNs would still make >>informed decisions. In addition end-to-end QoS mechanism(s) can be kept >>entirely separate from mobile IP. What do you think? > >[HC] I think this is a good suggestion. We can phrase it something like this: > >Network's QoS capabilities SHOULD be used in determining the mobility >decision within the MN. "One-size fits all" may not be a good approach as >you have rightly suggested. Let me think more about it before formulating >the right kind of requirement. > >> > > >> > >Thanks in advance for your answers, >> > >> > [HC] I hope this clarifies some of your concerns. Thanks for your >> > comments. >> > >> > [Hemant] >> [MB] Thank you, >> >> Murat Bilgic > >[Hemant] >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 06:41:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02840 for ; Mon, 18 Jun 2001 06:41:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09894; Mon, 18 Jun 2001 04:42:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29096; Mon, 18 Jun 2001 03:41:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IAf6dP024005 for ; Mon, 18 Jun 2001 03:41:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5IAf5XC024004 for mobile-ip-dist; Mon, 18 Jun 2001 03:41:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IAf2dP023997 for ; Mon, 18 Jun 2001 03:41:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13508 for ; Mon, 18 Jun 2001 03:41:08 -0700 (PDT) Received: from stsl.siemens.com.tw (stsl.siemens.com.tw [192.72.45.189]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18906 for ; Mon, 18 Jun 2001 04:41:50 -0600 (MDT) Received: from stslex.siemens.com.tw (stslex [192.72.45.13]) by stsl.siemens.com.tw (8.11.4/8.11.4) with ESMTP id f5IArhX10519 for ; Mon, 18 Jun 2001 18:53:44 +0800 (CST) Received: by stslex.siemens.com.tw with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Jun 2001 18:39:42 +0800 Received: from yuchung.stsl.siemens.com.tw (YUCHUNG [140.231.62.74]) by stslex.siemens.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MHYNR848; Mon, 18 Jun 2001 18:39:39 +0800 Received: from yccheng by yuchung.stsl.siemens.com.tw with local (Exim 3.22 #1 (Debian)) id 15BwOh-0001sl-00 for ; Mon, 18 Jun 2001 18:36:43 +0800 From: Yuchung Cheng To: mobile-ip@sunroof.eng.sun.com Date: Mon, 18 Jun 2001 18:36:43 +0800 Subject: [mobile-ip] problem of infinite lifetime in BU Message-ID: <20010618183642.A7184@yuchung> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Why BU can have infinite lifetime? I mean if MN sends such BU to HA, then MN crashes and boot again, the new registration probably fails because HA performs sequence number checking and the binding never expires? Yuchung From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 13:56:59 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14914 for ; Mon, 18 Jun 2001 13:56:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05990; Mon, 18 Jun 2001 10:56:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09987; Mon, 18 Jun 2001 10:56:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IHtCdP024486 for ; Mon, 18 Jun 2001 10:55:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5IHtC98024485 for mobile-ip-dist; Mon, 18 Jun 2001 10:55:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IHt9dP024478 for ; Mon, 18 Jun 2001 10:55:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26130 for ; Mon, 18 Jun 2001 10:55:15 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07703 for ; Mon, 18 Jun 2001 11:55:59 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5IHrDp13254 for ; Mon, 18 Jun 2001 10:53:13 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5IHtDI17819 for ; Mon, 18 Jun 2001 10:55:13 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A6F.00626AFC ; Mon, 18 Jun 2001 10:54:59 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A6F.00626A60.00@hqoutbound.ops.3com.com> Date: Mon, 18 Jun 2001 10:55:25 -0700 Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Charles: Thanks for the scenario. Alper: you can think of the same scenario with no GPRS coverage inside the building. IMHO, we are going to see scenarios like this more often than a pure single access technology wireless data access. You can also think of same operator providing WWAN and WLAN (hot spot) coverage and like to use fast MIP techniques. I like to suggest that we remove any dependency of L2 with FMIP techniques. Barani. Charles Qi Shen on 06/18/2001 02:57:39 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Charles Qi Shen To: mobile-ip@sunroof.eng.sun.com cc: (Barani Subbiah/HQ/3Com) Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Alper, I am not aware of what kinds of scenarios Barani may have in his mind. Please see whether my scenario can be something close to that. For example, you have a Mobile Node with two interfaces, one GPRS and one Wireless LAN, your company is covered by WLAN and you can use it for free within the company, while you are outside you will use GPRS. Since you pay for your GPRS but not the WLAN. You may wish to use WLAN *only* while inside the Company. In this case, it is not really this mobile node *cannot* have both interfaces connected, but it is the user choosing so. Charles At 05:26 PM 6/15/2001 -0700, you wrote: >Barani, > >Is there any reason why this mobile node cannot have both interfaces >connected >at the same time? Do you have a scenario where it can or it should have >only one >connected, although they are using different interfaces? > >alper > > > > > > Alper, > > > > No. It is a single mobile with multiple links but connects via a single > link >at > > any given time to a single AR. However, after hand off it connects to > new AR >via > > a different link. Example would be WLAN and WWAN or any other combination. > > > > Barani. > > > > > > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: Alper Yegin > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > Barani, > > > > > As in the draft and this thread, I like to point out that Link layer > address > > > based verification across ARs should be avoided as much as possible. > > > MN can have two interfaces and also move from one AR to another AR > using the > > new > > > L2 interface. > > > > > > If we want L2 identifier then there should be a way that MN can > indicate to > > the > > > old AR about the new Link layer ID that it will be using plus the > current L2 > > ID. > > > > > > > If this is a mobile node with multiple links, which can be connected to > > different ARs at the same time, you most probably don't need FMIPv6 draft. > > > > alper > > > > > > > > > > > >alper SHEN, Qi (Charles) Centre for Wireless Communications National University of Singapore 20 Science Park Rd. #02-34/37, TeleTech Park Singapore Science Park II, Singapore 117674 Tel: +65 870-9358 Fax: +65 779-5441 Email: shenqi@cwc.nus.edu.sg URL: http://www.cwc.nus.edu.sg From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 15:22:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17727 for ; Mon, 18 Jun 2001 15:22:16 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29617; Mon, 18 Jun 2001 13:22:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06020; Mon, 18 Jun 2001 12:22:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IJDJdP024575 for ; Mon, 18 Jun 2001 12:13:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5IJDJvR024574 for mobile-ip-dist; Mon, 18 Jun 2001 12:13:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IJDFdP024567 for ; Mon, 18 Jun 2001 12:13:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29579 for ; Mon, 18 Jun 2001 12:13:22 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08227 for ; Mon, 18 Jun 2001 12:13:21 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Jun 2001 15:12:19 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Date: Mon, 18 Jun 2001 15:12:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Mingguey, Sharif, Thank you for clarifying the term. So, it is indeed one of the globally unique IP addresses reserved by the NAT for address translation. Would you please also clarify my another confusion? With the nat-binding-update message (sent from the MN to the NAT) and mobile-location-solicitation message (sent from the CN to the mobile-database), you obviously assume that both CN and MN are aware of that the MN is a private node. But this is against the principle of using NAT. Before the MN sends out its first packet, a binding has estabished between the local address and the global address of the NAT. If the MN moves during the session, a new binding must be established, so that correct mapping can be performed by the NAT. I made the assumption in my model, that once a binding is set up, the session must continue to use the same global address for the duration of that session. Thus, "nat-binding-update" must be sent to th NAT to configure a new binding. The "mobile-location-solicitation" is sent to the mobile-database to ascertain whether the MN is currently at its local network or in a foreign network, so that: (1) The CN can set up a binding in its NAT to receive packets from MN. (2) Packets can be sent directly to MN without any "triangle routing" action neccessary. As stated in RFC 3022, NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. That is, both the CN and MN have no idea of the existence of the NAT. The NAT translates the MN's private address to a global address (i.e., NAT-translated address) in all the outgoing IP packets from the MN, and vice versa for the IP packets in the reverse flow. Yes, that is true. I will needto make a minor modification to conform with this. When the MN sends a "dbase-binding-update", the mobile-database will in turn send the "nat-binding-update" to the NAT. This way the MN will never need to be aware of the NAT and any address mappings that it may employ. I will send a -01.txt update. The CN only sees the MN as a public node because the NAT-translated global address is shown in the source address field of all the packets from the MN. The MN never realizes that its private address has been mapped to a global address and the CN can only recognize it by its NAT-translated global address. Most importantly, the MN has no idea of the existence of the global address. Otherwise, the MN should have used it instead of its private address to communicate with the CN in the first place. I find a solution using a "NAT-translated global address" a little problametic. This is because every node within the private network that sends to the CN would use the same global address, which will make it difficult for the CN to determine the identity of the sender (assume that we're using Basic-NAT, not NATP). Thus I felt as one option that the CN shoul know about the local address of the MN aslo using "mobile-location-solicitation" allowing it to set up a binding of the address of the MN. Thus, knowing the address binding, the CN's NAT can do the resverse mapping of the global -> local address of MN, allowing CN to itentify the MN precisely (because both global address and local address of MN is known). Thanks. -Sharif Would you plase explain this confliction? Thanks. Mingguey "Shahrier, Sharif M." wrote: > The meaning of term "Global IP Address of NAT" is: > > (1) It is an address from the registered public address space. > (2) It is statically assigned to the NAT as a global address for > communication over the backbone. > > Sharif > > -----Original Message----- > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > Sent: Friday, June 15, 2001 12:04 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > Sharif, > > I just want to clarify what the "Global IP Address of NAT" means in the > format > of a binding of NAT. > Is it the registered IP address of the NAT-enabled router itself or one of > the > globally unique IP addresses reserved by the NAT located in the router? > Would you please identify which one it stands for? > > Mingguey > > "Shahrier, Sharif M." wrote: > > > Mingguey, > > > > I don't see the distinction between the two cases, since both > cases > > would statically assign a few global addresses > > to the NAT-box, for mapping and transfer over the public backbone. Are you > > saying that in the second case the global IP addresses are NOT statically > > assigned? > > > > Sharif > > > > -----Original Message----- > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > Sent: Friday, June 15, 2001 10:48 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > Sharif, > > > > Then you mean that the format of a binding in the NAT should be (A Global > IP > > Address Reserved by NAT, Local IP > > Address) instead of (Global IP Address of NAT, Local IP Address), right? > > > > Mingguey > > > > "Shahrier, Sharif M." wrote: > > > > > Mingguey, > > > > > > If you look at RFC 3022, it describes a "traditional NAT", where > > > only registered IP addresses are used in the translation, not port > > numbers. > > > That is the model that my proposal is based on. However, it can be > > extended > > > to NAPT as well. > > > > > > Sharif. > > > > > > -----Original Message----- > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > Sent: Thursday, June 14, 2001 4:38 PM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > Sharif, > > > > > > In your proposed architecture, Basic Static NAT-routers are used. This > > means > > > that a set of globally unique IP addresses (i.e., a set of registered > > > addresses) is reserved by each NAT device (located in a NAT-enabled > > router) > > > just for the purpose of for address translation, i.e., mapping the > > private > > > address of each local private node that wants to communicate with an > > > external > > > node (i.e., CN) to one of the reserved global addresses. This is an > > > one-to-one > > > mapping within not only the NAT table but also the entire private > network. > > > > > > Your proposal says that the format of a binding in the NAT is (Global IP > > > Address of NAT, Local IP Address). Is the "Global IP Address of NAT" the > > > registered IP address of the NAT-enabled router itself or one of the > > > globally > > > unique IP addresses reserved by the NAT located in the router? If it is > > the > > > former, then NAPT is used (instead of basic static NAT), where port > > numbers > > > are > > > involved in the address translation. If it is the later, then the format > > of > > > a > > > binding in the NAT should be (A Global IP Address Reserved by NAT, Local > > IP > > > Address). > > > > > > Mingguey > > > > > > "Shahrier, Sharif M." wrote: > > > > > > > The binding is one global address to one private address for a given > > > > session. > > > > > > > > -----Original Message----- > > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > > Sent: Thursday, June 14, 2001 3:18 PM > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > > > Sharif, > > > > > > > > In the "System Architecture" section: > > > > ... > > > > The NAT tables have to be set up, to reflect the correct binding > > > > between the global address of NAT-A and the local address of the > > > > sender in A... > > > > > > > > Is the binding of one global address to one private address mapping? > Or > > > one > > > > global > > > > address to many private addresses mapping? > > > > > > > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 18 23:00:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29034 for ; Mon, 18 Jun 2001 23:00:00 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA02648; Mon, 18 Jun 2001 20:00:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01900; Mon, 18 Jun 2001 19:59:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5J2wddP024996 for ; Mon, 18 Jun 2001 19:58:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5J2wdD6024995 for mobile-ip-dist; Mon, 18 Jun 2001 19:58:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5J2wadP024988 for ; Mon, 18 Jun 2001 19:58:36 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5J2wdG488338 for ; Mon, 18 Jun 2001 19:58:39 -0700 (PDT) Message-Id: <200106190258.f5J2wdG488338@jurassic.eng.sun.com> Date: Mon, 18 Jun 2001 19:58:43 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HDVhkeauEsTgVXYMP2i4vg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Charles, Barani, All it takes to avoid using FMIPv6 is the capability to be data connected at two interfaces for few seconds. So, if there's overlap (worth few seconds) then one can get away without using FMIPv6. During the overlap, the other interface is used to configure a new CoA and send a BU to oldAR to establish forwarding from previous care-of address. After this point old attachment can be released. I think few seconds overlap is reasonable. alper > Charles: Thanks for the scenario. > > Alper: you can think of the same scenario with no GPRS coverage inside the > building. IMHO, we are going to see scenarios like this more often than a pure > single access technology wireless data access. > You can also think of same operator providing WWAN and WLAN (hot spot) coverage > and like to use fast MIP techniques. > > I like to suggest that we remove any dependency of L2 with FMIP techniques. > > Barani. > > > > > > Charles Qi Shen on 06/18/2001 02:57:39 AM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: Charles Qi Shen > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > Alper, > > I am not aware of what kinds of scenarios Barani may have in his mind. > Please see whether my scenario can be something close to that. > > For example, you have a Mobile Node with two interfaces, one GPRS and one > Wireless LAN, your company is covered by WLAN and you can use it for free > within the company, while you are outside you will use GPRS. Since you pay > for your GPRS but not the WLAN. You may wish to use WLAN *only* while > inside the Company. In this case, it is not really this mobile node > *cannot* have both interfaces connected, but it is the user choosing so. > > Charles > > At 05:26 PM 6/15/2001 -0700, you wrote: > >Barani, > > > >Is there any reason why this mobile node cannot have both interfaces > >connected > >at the same time? Do you have a scenario where it can or it should have > >only one > >connected, although they are using different interfaces? > > > >alper > > > > > > > > > > Alper, > > > > > > No. It is a single mobile with multiple links but connects via a single > > link > >at > > > any given time to a single AR. However, after hand off it connects to > > new AR > >via > > > a different link. Example would be WLAN and WWAN or any other combination. > > > > > > Barani. > > > > > > > > > > > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > > > Sent by: Alper Yegin > > > > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > cc: (Barani Subbiah/HQ/3Com) > > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > > > > > Barani, > > > > > > > As in the draft and this thread, I like to point out that Link layer > > address > > > > based verification across ARs should be avoided as much as possible. > > > > MN can have two interfaces and also move from one AR to another AR > > using the > > > new > > > > L2 interface. > > > > > > > > If we want L2 identifier then there should be a way that MN can > > indicate to > > > the > > > > old AR about the new Link layer ID that it will be using plus the > > current L2 > > > ID. > > > > > > > > > > If this is a mobile node with multiple links, which can be connected to > > > different ARs at the same time, you most probably don't need FMIPv6 draft. > > > > > > alper > > > > > > > > > > > > > > > > > > >alper > > SHEN, Qi (Charles) > Centre for Wireless Communications > National University of Singapore > 20 Science Park Rd. #02-34/37, TeleTech Park > Singapore Science Park II, Singapore 117674 > Tel: +65 870-9358 Fax: +65 779-5441 > Email: shenqi@cwc.nus.edu.sg > URL: http://www.cwc.nus.edu.sg > > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 19 06:47:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17276 for ; Tue, 19 Jun 2001 06:47:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA17560; Tue, 19 Jun 2001 03:47:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12102; Tue, 19 Jun 2001 03:47:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JAk9dP025249 for ; Tue, 19 Jun 2001 03:46:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5JAk8pV025248 for mobile-ip-dist; Tue, 19 Jun 2001 03:46:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JAk4dP025241 for ; Tue, 19 Jun 2001 03:46:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11984 for ; Tue, 19 Jun 2001 03:46:10 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27906 for ; Tue, 19 Jun 2001 04:46:56 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17068; Tue, 19 Jun 2001 06:45:34 -0400 (EDT) Message-Id: <200106191045.GAA17068@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ernst-mobileip-v6-network-02.txt Date: Tue, 19 Jun 2001 06:45:34 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates) Author(s) : T. Ernst, L. Bellier, A. Olivereau, C. Castelluccia, H. Lach Filename : draft-ernst-mobileip-v6-network-02.txt Pages : 24 Date : 18-Jun-01 This draft addresses the problems of routing datagrams to nodes located in an IPv6 mobile network. A mobile network is one or more IP-subnets attached to a mobile router and mobile as a unit. The mobile router dynamically changes its point of attachment. Applications of mobile networks include networks attached to people (PANs) and networks of sensors deployed in an aircraft, a boat, or a car. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ernst-mobileip-v6-network-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ernst-mobileip-v6-network-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ernst-mobileip-v6-network-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010618105526.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ernst-mobileip-v6-network-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ernst-mobileip-v6-network-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010618105526.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 19 09:05:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20447 for ; Tue, 19 Jun 2001 09:05:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21513; Tue, 19 Jun 2001 07:05:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13554; Tue, 19 Jun 2001 06:05:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JD4KdP025423 for ; Tue, 19 Jun 2001 06:04:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5JD4KpK025422 for mobile-ip-dist; Tue, 19 Jun 2001 06:04:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JD4HdP025415 for ; Tue, 19 Jun 2001 06:04:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23842 for ; Tue, 19 Jun 2001 06:04:24 -0700 (PDT) Received: from ext.lri.fr (ext.lri.fr [129.175.15.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17934 for ; Tue, 19 Jun 2001 06:04:23 -0700 (PDT) Received: from lri.fr (newsun-asspro [129.175.11.103]) by ext.lri.fr (8.11.1/jtpda-5.3.2) with ESMTP id f5JD4L516572 for ; Tue, 19 Jun 2001 15:04:22 +0200 (MET DST) Message-ID: <3B2F4DD5.C5F30214@lri.fr> Date: Tue, 19 Jun 2001 15:04:21 +0200 From: Benzaid Mounir X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] library mobile IPv4 for linux Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, Does anyone know any Mobile IPv4 library for linux/Redhat (kernel 2.2.x) ? Thanks in advance. From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 19 09:26:12 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21047 for ; Tue, 19 Jun 2001 09:26:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09165; Tue, 19 Jun 2001 07:26:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23629; Tue, 19 Jun 2001 06:26:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JDPLdP025472 for ; Tue, 19 Jun 2001 06:25:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5JDPK2O025471 for mobile-ip-dist; Tue, 19 Jun 2001 06:25:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JDPHdP025464 for ; Tue, 19 Jun 2001 06:25:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15917 for ; Tue, 19 Jun 2001 06:25:25 -0700 (PDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01104 for ; Tue, 19 Jun 2001 06:25:23 -0700 (PDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JDPMp19807 for ; Tue, 19 Jun 2001 09:25:22 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5JDPMD19801 for ; Tue, 19 Jun 2001 09:25:22 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 14:25:21 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00211A99A@en0033exch001u.uk.lucent.com> From: "Tanis, Michael (Michael)" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] library mobile IPv4 for linux Date: Tue, 19 Jun 2001 14:25:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I hope this implementation from the Helsinki University of Technology is useful to you http://www.cs.hut.fi/Research/Dynamics/index.html if not, then it is also worth checking the "links" regards, -------------------------------- Michael Tanis O Lucent Technologies UMTS-SAE Optimus Building Windmill Hill Business Park Swindon Wilts SN5 6PP United Kingdom Work Tel: +44 1793 897856 Mobile : +44 7779 032004 e-mail : mtanis@lucent.com ---------- From: Benzaid Mounir [SMTP:Mounir.Benzaid@lri.fr] Sent: Tuesday, June 19, 2001 2:04 PM To: mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] library mobile IPv4 for linux Hello, Does anyone know any Mobile IPv4 library for linux/Redhat (kernel 2.2.x) ? Thanks in advance. From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 19 12:56:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26804 for ; Tue, 19 Jun 2001 12:56:17 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21051; Tue, 19 Jun 2001 10:56:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13934; Tue, 19 Jun 2001 09:56:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JGskdP025659 for ; Tue, 19 Jun 2001 09:54:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5JGskdV025658 for mobile-ip-dist; Tue, 19 Jun 2001 09:54:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JGshdP025651 for ; Tue, 19 Jun 2001 09:54:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00428 for ; Tue, 19 Jun 2001 09:54:51 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29262 for ; Tue, 19 Jun 2001 10:55:37 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5JGqk614111 for ; Tue, 19 Jun 2001 09:52:46 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5JGslI22425 for ; Tue, 19 Jun 2001 09:54:47 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A70.005CE268 ; Tue, 19 Jun 2001 09:54:32 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com cc: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A70.005CE037.00@hqoutbound.ops.3com.com> Date: Tue, 19 Jun 2001 09:54:55 -0700 Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, I am not sure if this is a valid assumption to design a solution that works given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will be the most prevalent wireless data access scenario and Mobile IP has lots to gain to propose solutions that works across heterogeneous access (L2) technologies. Again, I want to emphasis that we remove any L2 dependency with FMIP. There are other ways to solve the problem with out using L2 identifier. Barani. Alper Yegin on 06/18/2001 07:58:43 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Alper Yegin To: mobile-ip@sunroof.eng.sun.com cc: (Barani Subbiah/HQ/3Com) Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Charles, Barani, All it takes to avoid using FMIPv6 is the capability to be data connected at two interfaces for few seconds. So, if there's overlap (worth few seconds) then one can get away without using FMIPv6. During the overlap, the other interface is used to configure a new CoA and send a BU to oldAR to establish forwarding from previous care-of address. After this point old attachment can be released. I think few seconds overlap is reasonable. alper > Charles: Thanks for the scenario. > > Alper: you can think of the same scenario with no GPRS coverage inside the > building. IMHO, we are going to see scenarios like this more often than a pure > single access technology wireless data access. > You can also think of same operator providing WWAN and WLAN (hot spot) coverage > and like to use fast MIP techniques. > > I like to suggest that we remove any dependency of L2 with FMIP techniques. > > Barani. > > > > > > Charles Qi Shen on 06/18/2001 02:57:39 AM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: Charles Qi Shen > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > Alper, > > I am not aware of what kinds of scenarios Barani may have in his mind. > Please see whether my scenario can be something close to that. > > For example, you have a Mobile Node with two interfaces, one GPRS and one > Wireless LAN, your company is covered by WLAN and you can use it for free > within the company, while you are outside you will use GPRS. Since you pay > for your GPRS but not the WLAN. You may wish to use WLAN *only* while > inside the Company. In this case, it is not really this mobile node > *cannot* have both interfaces connected, but it is the user choosing so. > > Charles > > At 05:26 PM 6/15/2001 -0700, you wrote: > >Barani, > > > >Is there any reason why this mobile node cannot have both interfaces > >connected > >at the same time? Do you have a scenario where it can or it should have > >only one > >connected, although they are using different interfaces? > > > >alper > > > > > > > > > > Alper, > > > > > > No. It is a single mobile with multiple links but connects via a single > > link > >at > > > any given time to a single AR. However, after hand off it connects to > > new AR > >via > > > a different link. Example would be WLAN and WWAN or any other combination. > > > > > > Barani. > > > > > > > > > > > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > > > Sent by: Alper Yegin > > > > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > cc: (Barani Subbiah/HQ/3Com) > > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > > > > > Barani, > > > > > > > As in the draft and this thread, I like to point out that Link layer > > address > > > > based verification across ARs should be avoided as much as possible. > > > > MN can have two interfaces and also move from one AR to another AR > > using the > > > new > > > > L2 interface. > > > > > > > > If we want L2 identifier then there should be a way that MN can > > indicate to > > > the > > > > old AR about the new Link layer ID that it will be using plus the > > current L2 > > > ID. > > > > > > > > > > If this is a mobile node with multiple links, which can be connected to > > > different ARs at the same time, you most probably don't need FMIPv6 draft. > > > > > > alper > > > > > > > > > > > > > > > > > > >alper > > SHEN, Qi (Charles) > Centre for Wireless Communications > National University of Singapore > 20 Science Park Rd. #02-34/37, TeleTech Park > Singapore Science Park II, Singapore 117674 > Tel: +65 870-9358 Fax: +65 779-5441 > Email: shenqi@cwc.nus.edu.sg > URL: http://www.cwc.nus.edu.sg > > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 19 20:30:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08850 for ; Tue, 19 Jun 2001 20:30:55 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23896; Tue, 19 Jun 2001 17:31:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26945; Tue, 19 Jun 2001 17:30:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K0SfdP025999 for ; Tue, 19 Jun 2001 17:28:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5K0SecT025998 for mobile-ip-dist; Tue, 19 Jun 2001 17:28:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K0SbdP025991 for ; Tue, 19 Jun 2001 17:28:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26568 for ; Tue, 19 Jun 2001 17:28:45 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01194 for ; Tue, 19 Jun 2001 17:28:44 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5K0ShO17777 for ; Wed, 20 Jun 2001 02:28:43 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Jun 20 02:28:43 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Jun 2001 02:23:09 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBF60@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Wed, 20 Jun 2001 02:28:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I am not sure if this is a valid assumption to design a solution that works > given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will > be the most prevalent wireless data access scenario > => That's certainly debatable to say the least, but I guess this is a side topic for this list. Which asumptions in the draft do you disagree with ? Do you disagree that some overlap between coverage areas is required ? I find that hard to believe since this is the fundamental requirement for ANY wireless system. > and Mobile IP has lots to > gain to propose solutions that works across heterogeneous access (L2) > technologies. > => MIP already works across heterogenous networks due to its location in the stack. Again what in the draft eliminates this very useful feature ? > Again, I want to emphasis that we remove any L2 dependency with FMIP. > => We are doing a handover because we're moving within the topology. Topological movement can be due to physical movement (L2 changes) or changes in the topology. In the former I can't see how you could possibly eliminate the need for an L2 indication. In the latter you rely less on L2 knowledge but knowing it is a good optimisation. Which scenario doesn't require L2 knowledge ? > There are > other ways to solve the problem with out using L2 identifier. > => It would be good to know these, can you please elaborate ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 19 20:51:26 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09329 for ; Tue, 19 Jun 2001 20:51:26 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29647; Tue, 19 Jun 2001 17:51:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA00207; Tue, 19 Jun 2001 17:51:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K0o6dP026052 for ; Tue, 19 Jun 2001 17:50:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5K0o5q6026051 for mobile-ip-dist; Tue, 19 Jun 2001 17:50:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K0o1dP026044 for ; Tue, 19 Jun 2001 17:50:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29975 for ; Tue, 19 Jun 2001 17:50:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19035 for ; Tue, 19 Jun 2001 18:50:07 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA21917; Tue, 19 Jun 2001 17:50:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5K0o6C13684; Tue, 19 Jun 2001 17:50:06 -0700 X-mProtect: Tue, 19 Jun 2001 17:50:06 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdEtl9Q7; Tue, 19 Jun 2001 17:50:05 PDT Message-ID: <3B2FF33E.EF76D461@iprg.nokia.com> Date: Tue, 19 Jun 2001 17:50:06 -0700 From: Theo Pagtzis Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, PRoberts@MEGISTO.com Subject: [mobile-ip] A question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil, because of the complexity of the schematics I am thinking of leaving out ascii representations of the postscript originals. Is that acceptable for an internet draft. I am asking that because I have already seen it in the IDMR group.. Thanks Theo From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 20 10:43:21 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09518 for ; Wed, 20 Jun 2001 10:43:21 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00891; Wed, 20 Jun 2001 07:43:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21253; Wed, 20 Jun 2001 07:42:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KEfBdP026775 for ; Wed, 20 Jun 2001 07:41:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5KEfB4B026774 for mobile-ip-dist; Wed, 20 Jun 2001 07:41:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KEf7dP026767 for ; Wed, 20 Jun 2001 07:41:08 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05032 for ; Wed, 20 Jun 2001 10:41:13 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.3+Sun/8.11.3) id f5KEg2d18283; Wed, 20 Jun 2001 10:42:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15152.46649.944047.729921@gargle.gargle.HOWL> Date: Wed, 20 Jun 2001 10:42:01 -0400 (EDT) From: James Carlson To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] A question In-Reply-To: Phil Roberts's message of 20 June 2001 08:52:21 References: X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil Roberts writes: > I'm not really sure I understand what you're asking, but ... > > As a reader of an I-D I want to be able to understand what the > author is talking about. To that extent diagrams sometimes help. > Without seeing it it's hard to give any assessment. > > I'm not sure this is what you're looking for. Perhaps you > could clarify? I think he's just asking "is it acceptable to leave out the pictures in the ASCII version?" The answer is yes, though if you can include them, it's better to do so. See: http://www.ietf.org/ietf/1id-guidelines.txt Internet-Drafts are generally in the format of an RFC, although they are expected to be rough drafts. This format is specified fully in RFC 2223. In brief, an Internet-Draft must be submitted in ASCII text, limited to 72 characters per line and 58 lines per page, followed by a formfeed character. Overstriking to achieve underlining is not acceptable. PostScript is acceptable, but only when submitted with a matching ASCII version (even if figures must be deleted). PostScript should be formatted for use on 8.5x11 inch paper. If A4 paper is used, an image area less than 10 inches high should be used to avoid printing extra pages when printed on 8.5x11 paper. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 20 10:49:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09718 for ; Wed, 20 Jun 2001 10:49:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18249; Wed, 20 Jun 2001 06:53:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17976; Wed, 20 Jun 2001 05:53:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KCqWdP026665 for ; Wed, 20 Jun 2001 05:52:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5KCqWcX026664 for mobile-ip-dist; Wed, 20 Jun 2001 05:52:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KCqSdP026657 for ; Wed, 20 Jun 2001 05:52:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17895 for ; Wed, 20 Jun 2001 05:52:36 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07814 for ; Wed, 20 Jun 2001 05:52:35 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Jun 2001 08:52:22 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A question Date: Wed, 20 Jun 2001 08:52:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Theo, I'm not really sure I understand what you're asking, but ... As a reader of an I-D I want to be able to understand what the author is talking about. To that extent diagrams sometimes help. Without seeing it it's hard to give any assessment. I'm not sure this is what you're looking for. Perhaps you could clarify? Phil > -----Original Message----- > From: Theo Pagtzis [mailto:tpagtzis@iprg.nokia.com] > Sent: Tuesday, June 19, 2001 8:50 PM > To: mobile-ip@sunroof.eng.sun.com; PRoberts@MEGISTO.com > Subject: [mobile-ip] A question > > > Phil, > > because of the complexity of the schematics I am thinking > of leaving out > ascii representations of the postscript originals. Is that > acceptable for an > internet draft. I am asking that because I have already seen > it in the IDMR > group.. > > > Thanks > > > Theo > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 20 11:48:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11701 for ; Wed, 20 Jun 2001 11:48:37 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18941; Wed, 20 Jun 2001 09:47:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06535; Wed, 20 Jun 2001 08:47:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KFkRdP026844 for ; Wed, 20 Jun 2001 08:46:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5KFkR57026843 for mobile-ip-dist; Wed, 20 Jun 2001 08:46:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KFkOdP026836 for ; Wed, 20 Jun 2001 08:46:24 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22656 for ; Wed, 20 Jun 2001 11:46:31 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id LAA19991 for mobile-ip@sunroof.eng.sun.com; Wed, 20 Jun 2001 11:46:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JGaddP025617 for ; Tue, 19 Jun 2001 09:36:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08442 for ; Tue, 19 Jun 2001 09:36:47 -0700 (PDT) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02628 for ; Tue, 19 Jun 2001 10:36:45 -0600 (MDT) Received: from ffb5b (lsanca1-ar8-176-246.lsanca1.dsl.gtei.net [4.35.176.246]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id JAA24401; Tue, 19 Jun 2001 09:36:38 -0700 (PDT) Message-ID: <004601c0f8de$e940cc60$f6b02304@ffb5b> From: "jshukla" To: Cc: References: Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt Date: Tue, 19 Jun 2001 09:43:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit We have a ID on making IPSec compatible with NATs and it is very similar to this draft. However, there are some important differences that are explained inline. ----- Original Message ----- From: "Shahrier, Sharif M." > > Before the MN sends out its first packet, a binding has estabished between > the local address and > the global address of the NAT. If the MN moves during the session, a new > binding must be established, > so that correct mapping can be performed by the NAT. I made the assumption > in my model, that once a binding is set up, the session must continue to use > the same global address for the duration of that session. > Thus, "nat-binding-update" must be sent to th NAT to configure a new > binding. As mentioned in Section 2 of your draft, the NAT-B must be able to reverse the effect of NAT-A to obtain the local address of MH. However, you have not described this mechanism. We describe this mechanism in our draft on NAT and IPSec compatibility. Our proposed method works with NAPT as well. You can take a look at our draft. The new version will come out in a month. http://search.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible -security-00.txt I am very happy to see that someone else also realized that NAT can be used to provide mobility. A great advantage of this approach is that the security protocol can also provides mobility. regards, Jayant > The "mobile-location-solicitation" is sent to the mobile-database to > ascertain whether the MN is currently at > its local network or in a foreign network, so that: > > (1) The CN can set up a binding in its NAT to receive packets from MN. > (2) Packets can be sent directly to MN without any "triangle routing" > action neccessary. > > As stated in RFC 3022, NAT is a method by which IP addresses are mapped from > one > group to another, transparent to end users. That is, both the CN and MN have > no > idea of the existence of the NAT. The NAT translates the MN's private > address to > a global address (i.e., NAT-translated address) in all the outgoing IP > packets > from the MN, and vice versa for the IP packets in the reverse flow. > > Yes, that is true. I will needto make a minor modification to conform with > this. When the MN sends a > "dbase-binding-update", the mobile-database will in turn send the > "nat-binding-update" to the NAT. > This way the MN will never need to be aware of the NAT and any address > mappings that it may employ. > I will send a -01.txt update. > > The CN only > sees the MN as a public node because the NAT-translated global address is > shown > in the source address field of all the packets from the MN. The MN never > realizes that its private address has been mapped to a global address and > the CN > can only recognize it by its NAT-translated global address. Most > importantly, > the MN has no idea of the existence of the global address. Otherwise, the MN > should have used it instead of its private address to communicate with the > CN in > the first place. > > I find a solution using a "NAT-translated global address" a little > problametic. This is because > every node within the private network that sends to the CN would use the > same global address, which will > make it difficult for the CN to determine the identity of the sender (assume > that we're using Basic-NAT, not NATP). > Thus I felt as one option that the CN shoul know about the local address of > the MN aslo using "mobile-location-solicitation" > allowing it to set up a binding of the address of the MN. > Thus, knowing the address binding, > the CN's NAT can do the resverse mapping of the global -> local address of > MN, allowing CN to itentify the MN precisely > (because both global address and local address of MN is known). > > Thanks. > > -Sharif > Would you plase explain this confliction? > Thanks. > > Mingguey > > > "Shahrier, Sharif M." wrote: > > > The meaning of term "Global IP Address of NAT" is: > > > > (1) It is an address from the registered public address space. > > (2) It is statically assigned to the NAT as a global address for > > communication over the backbone. > > > > Sharif > > > > -----Original Message----- > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > Sent: Friday, June 15, 2001 12:04 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > Sharif, > > > > I just want to clarify what the "Global IP Address of NAT" means in the > > format > > of a binding of NAT. > > Is it the registered IP address of the NAT-enabled router itself or one of > > the > > globally unique IP addresses reserved by the NAT located in the router? > > Would you please identify which one it stands for? > > > > Mingguey > > > > "Shahrier, Sharif M." wrote: > > > > > Mingguey, > > > > > > I don't see the distinction between the two cases, since both > > cases > > > would statically assign a few global addresses > > > to the NAT-box, for mapping and transfer over the public backbone. Are > you > > > saying that in the second case the global IP addresses are NOT > statically > > > assigned? > > > > > > Sharif > > > > > > -----Original Message----- > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > Sent: Friday, June 15, 2001 10:48 AM > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > Sharif, > > > > > > Then you mean that the format of a binding in the NAT should be (A > Global > > IP > > > Address Reserved by NAT, Local IP > > > Address) instead of (Global IP Address of NAT, Local IP Address), right? > > > > > > Mingguey > > > > > > "Shahrier, Sharif M." wrote: > > > > > > > Mingguey, > > > > > > > > If you look at RFC 3022, it describes a "traditional NAT", > where > > > > only registered IP addresses are used in the translation, not port > > > numbers. > > > > That is the model that my proposal is based on. However, it can be > > > extended > > > > to NAPT as well. > > > > > > > > Sharif. > > > > > > > > -----Original Message----- > > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > > Sent: Thursday, June 14, 2001 4:38 PM > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: Re: [mobile-ip] I-D ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > > > Sharif, > > > > > > > > In your proposed architecture, Basic Static NAT-routers are used. This > > > means > > > > that a set of globally unique IP addresses (i.e., a set of registered > > > > addresses) is reserved by each NAT device (located in a NAT-enabled > > > router) > > > > just for the purpose of for address translation, i.e., mapping the > > > private > > > > address of each local private node that wants to communicate with an > > > > external > > > > node (i.e., CN) to one of the reserved global addresses. This is an > > > > one-to-one > > > > mapping within not only the NAT table but also the entire private > > network. > > > > > > > > Your proposal says that the format of a binding in the NAT is (Global > IP > > > > Address of NAT, Local IP Address). Is the "Global IP Address of NAT" > the > > > > registered IP address of the NAT-enabled router itself or one of the > > > > globally > > > > unique IP addresses reserved by the NAT located in the router? If it > is > > > the > > > > former, then NAPT is used (instead of basic static NAT), where port > > > numbers > > > > are > > > > involved in the address translation. If it is the later, then the > format > > > of > > > > a > > > > binding in the NAT should be (A Global IP Address Reserved by NAT, > Local > > > IP > > > > Address). > > > > > > > > Mingguey > > > > > > > > "Shahrier, Sharif M." wrote: > > > > > > > > > The binding is one global address to one private address for a given > > > > > session. > > > > > > > > > > -----Original Message----- > > > > > From: Mingguey M. Yang [mailto:Mingguey.Yang@usa.alcatel.com] > > > > > Sent: Thursday, June 14, 2001 3:18 PM > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > Subject: Re: [mobile-ip] I-D > ACTION:draft-shahrier-mobileip-nat-00.txt > > > > > > > > > > Sharif, > > > > > > > > > > In the "System Architecture" section: > > > > > ... > > > > > The NAT tables have to be set up, to reflect the correct binding > > > > > between the global address of NAT-A and the local address of the > > > > > sender in A... > > > > > > > > > > Is the binding of one global address to one private address mapping? > > Or > > > > one > > > > > global > > > > > address to many private addresses mapping? > > > > > > > > > > Mingguey From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 20 14:18:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16808 for ; Wed, 20 Jun 2001 14:18:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23996; Wed, 20 Jun 2001 12:18:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13659; Wed, 20 Jun 2001 11:18:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KIGedP027039 for ; Wed, 20 Jun 2001 11:16:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5KIGeAM027038 for mobile-ip-dist; Wed, 20 Jun 2001 11:16:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KIGadP027031 for ; Wed, 20 Jun 2001 11:16:36 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5KIGbG890848 for ; Wed, 20 Jun 2001 11:16:37 -0700 (PDT) Message-Id: <200106201816.f5KIGbG890848@jurassic.eng.sun.com> Date: Wed, 20 Jun 2001 11:16:43 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Se38ocQ9u58tSk26VENGdA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barani, I agree there will be a mix of access technologies deployed and Mobile IP will be best used across this kind of environment. And I think you also agree that if there's "enough" overlap between two different access network coverage, we don't need FMIPv6. "enough" being few seconds needed to configure a new CoA and send a BU to oldAR. There might be cases where MN doesn't have this few seconds, and need to use FMIPv6. In this case, the L2 indetifier MN send in F-BU does not match the L2 identifier it'll be using at the new link. That means newAR cannot detect this "mobile node" at L2, but instead needs to wait for the F-NA, which is in the draft. I don't see this as a "L2 dependency". So, draft has a solution for your scenario (F-NA). But of course, we'd like to hear your proposal as well. alper > Alper, > > I am not sure if this is a valid assumption to design a solution that works > given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will > be the most prevalent wireless data access scenario and Mobile IP has lots to > gain to propose solutions that works across heterogeneous access (L2) > technologies. > > Again, I want to emphasis that we remove any L2 dependency with FMIP. There are > other ways to solve the problem with out using L2 identifier. > > Barani. > > > > > Alper Yegin on 06/18/2001 07:58:43 PM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: Alper Yegin > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > Charles, Barani, > > All it takes to avoid using FMIPv6 is the capability to be data connected at two > interfaces for few seconds. So, if there's overlap (worth few seconds) then one > can get away without using FMIPv6. > > During the overlap, the other interface is used to configure a new CoA and send > a BU to oldAR to establish forwarding from previous care-of address. After this > point old attachment can be released. > > I think few seconds overlap is reasonable. > > alper > > > Charles: Thanks for the scenario. > > > > Alper: you can think of the same scenario with no GPRS coverage inside the > > building. IMHO, we are going to see scenarios like this more often than a pure > > single access technology wireless data access. > > You can also think of same operator providing WWAN and WLAN (hot spot) > coverage > > and like to use fast MIP techniques. > > > > I like to suggest that we remove any dependency of L2 with FMIP techniques. > > > > Barani. > > > > > > > > > > > > Charles Qi Shen on 06/18/2001 02:57:39 AM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: Charles Qi Shen > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > Alper, > > > > I am not aware of what kinds of scenarios Barani may have in his mind. > > Please see whether my scenario can be something close to that. > > > > For example, you have a Mobile Node with two interfaces, one GPRS and one > > Wireless LAN, your company is covered by WLAN and you can use it for free > > within the company, while you are outside you will use GPRS. Since you pay > > for your GPRS but not the WLAN. You may wish to use WLAN *only* while > > inside the Company. In this case, it is not really this mobile node > > *cannot* have both interfaces connected, but it is the user choosing so. > > > > Charles > > > > At 05:26 PM 6/15/2001 -0700, you wrote: > > >Barani, > > > > > >Is there any reason why this mobile node cannot have both interfaces > > >connected > > >at the same time? Do you have a scenario where it can or it should have > > >only one > > >connected, although they are using different interfaces? > > > > > >alper > > > > > > > > > > > > > > Alper, > > > > > > > > No. It is a single mobile with multiple links but connects via a single > > > link > > >at > > > > any given time to a single AR. However, after hand off it connects to > > > new AR > > >via > > > > a different link. Example would be WLAN and WWAN or any other combination. > > > > > > > > Barani. > > > > > > > > > > > > > > > > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > > > > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > > > > > Sent by: Alper Yegin > > > > > > > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > cc: (Barani Subbiah/HQ/3Com) > > > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > > > > > > > > > Barani, > > > > > > > > > As in the draft and this thread, I like to point out that Link layer > > > address > > > > > based verification across ARs should be avoided as much as possible. > > > > > MN can have two interfaces and also move from one AR to another AR > > > using the > > > > new > > > > > L2 interface. > > > > > > > > > > If we want L2 identifier then there should be a way that MN can > > > indicate to > > > > the > > > > > old AR about the new Link layer ID that it will be using plus the > > > current L2 > > > > ID. > > > > > > > > > > > > > If this is a mobile node with multiple links, which can be connected to > > > > different ARs at the same time, you most probably don't need FMIPv6 draft. > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > > > > >alper > > > > SHEN, Qi (Charles) > > Centre for Wireless Communications > > National University of Singapore > > 20 Science Park Rd. #02-34/37, TeleTech Park > > Singapore Science Park II, Singapore 117674 > > Tel: +65 870-9358 Fax: +65 779-5441 > > Email: shenqi@cwc.nus.edu.sg > > URL: http://www.cwc.nus.edu.sg > > > > > > > > > > > > > > alper > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 21 12:59:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06923 for ; Thu, 21 Jun 2001 12:59:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02312; Thu, 21 Jun 2001 10:59:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07969; Thu, 21 Jun 2001 09:59:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LGwGdP028015 for ; Thu, 21 Jun 2001 09:58:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5LGwFEV028014 for mobile-ip-dist; Thu, 21 Jun 2001 09:58:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LGwCdP028007 for ; Thu, 21 Jun 2001 09:58:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21980 for ; Thu, 21 Jun 2001 09:58:20 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14398 for ; Thu, 21 Jun 2001 10:59:08 -0600 (MDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5LGuI602660 for ; Thu, 21 Jun 2001 09:56:18 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5LGwII16839 for ; Thu, 21 Jun 2001 09:58:18 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A72.005D368A ; Thu, 21 Jun 2001 09:58:08 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A72.005D35A7.00@hqoutbound.ops.3com.com> Date: Thu, 21 Jun 2001 09:58:34 -0700 Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: See comments below. Barani. "Hesham Soliman (ERA)" on 06/19/2001 05:28:40 PM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: "Hesham Soliman (ERA)" To: "'mobile-ip @sunroof.eng.sun.com'" cc: (Barani Subbiah/HQ/3Com) Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > I am not sure if this is a valid assumption to design a solution that works > given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will > be the most prevalent wireless data access scenario > => That's certainly debatable to say the least, but I guess this is a side topic for this list. Which asumptions in the draft do you disagree with ? Do you disagree that some overlap between coverage areas is required ? I find that hard to believe since this is the fundamental requirement for ANY wireless system. //// The discussion so far is that does MN need to have connectivity to both AR domains at same time (L3 at old AR and L2 at new AR). Have a look at Alper's recent posting. FYI. current 802.11 spec does not allow a client to connect to 2 APs at any time. > and Mobile IP has lots to > gain to propose solutions that works across heterogeneous access (L2) > technologies. > => MIP already works across heterogenous networks due to its location in the stack. Again what in the draft eliminates this very useful feature ? /// L2 dependency. See Alpers recent posting > Again, I want to emphasis that we remove any L2 dependency with FMIP. > => We are doing a handover because we're moving within the topology. Topological movement can be due to physical movement (L2 changes) or changes in the topology. In the former I can't see how you could possibly eliminate the need for an L2 indication. In the latter you rely less on L2 knowledge but knowing it is a good optimisation. Which scenario doesn't require L2 knowledge ? /// There is a difference between L2 assistance and dependence. You are referring to L2 assistance and it is a good thing to have, but not the later. L3 solutions can use L2 indications but should not expect the same L2 appear on the other side after the handoff. > There are > other ways to solve the problem with out using L2 identifier. > => It would be good to know these, can you please elaborate ? /// It will be in response to Alpers mail. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 21 13:46:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09802 for ; Thu, 21 Jun 2001 13:46:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05318; Thu, 21 Jun 2001 10:45:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19951; Thu, 21 Jun 2001 10:45:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LHiLdP028125 for ; Thu, 21 Jun 2001 10:44:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5LHiLu7028124 for mobile-ip-dist; Thu, 21 Jun 2001 10:44:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LHiIdP028117 for ; Thu, 21 Jun 2001 10:44:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05309 for ; Thu, 21 Jun 2001 10:44:26 -0700 (PDT) From: Barani_Subbiah@3com.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11909 for ; Thu, 21 Jun 2001 10:44:22 -0700 (PDT) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f5LHgJ608452 for ; Thu, 21 Jun 2001 10:42:20 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f5LHiKI22452 for ; Thu, 21 Jun 2001 10:44:20 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A72.00616A7E ; Thu, 21 Jun 2001 10:44:02 -0700 X-Lotus-FromDomain: 3COM To: mobile-ip@sunroof.eng.sun.com Message-ID: <88256A72.00616900.00@hqoutbound.ops.3com.com> Date: Thu, 21 Jun 2001 10:44:26 -0700 Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Alper, comments below. Barani. Alper Yegin on 06/20/2001 11:16:43 AM Please respond to mobile-ip@sunroof.eng.sun.com Sent by: Alper Yegin To: mobile-ip@sunroof.eng.sun.com cc: (Barani Subbiah/HQ/3Com) Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Barani, I agree there will be a mix of access technologies deployed and Mobile IP will be best used across this kind of environment. >>>> I am glad to hear this. And I think you also agree that if there's "enough" overlap between two different access network coverage, we don't need FMIPv6. "enough" being few seconds needed to configure a new CoA and send a BU to oldAR. >>>> Yes, if the MN can connect at the same time to both access network. There might be cases where MN doesn't have this few seconds, and need to use FMIPv6. In this case, the L2 indetifier MN send in F-BU does not match the L2 identifier it'll be using at the new link. That means newAR cannot detect this "mobile node" at L2, but instead needs to wait for the F-NA, which is in the draft. I don't see this as a "L2 dependency". So, draft has a solution for your scenario (F-NA). But of course, we'd like to hear your proposal as well. >>>> We have tried to create a new ID called Association ID (AID), which is created using AR L2 address, thus unique to each ARs. When a MN associated with a AR, both MN and AR exchange this AID and agree to use this AID if and when there is a hand off. So, in the HI message from old AR to new AR, we can send this AID instead of L2 ID. Once the MN move to new AR, it should send this AID to new AR so that new AR can bind the AID and new L2 address and/or AID and new CoA. It can be in F-NA. We are experimenting to see if we can extend the "ARP" to carry this AID to the new AR. My proposal is that if we can find a way to get this AID at the same time when L2 identification happens then we get the same effect of moving with same L2. alper > Alper, > > I am not sure if this is a valid assumption to design a solution that works > given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will > be the most prevalent wireless data access scenario and Mobile IP has lots to > gain to propose solutions that works across heterogeneous access (L2) > technologies. > > Again, I want to emphasis that we remove any L2 dependency with FMIP. There are > other ways to solve the problem with out using L2 identifier. > > Barani. > > > > > Alper Yegin on 06/18/2001 07:58:43 PM > > Please respond to mobile-ip@sunroof.eng.sun.com > > Sent by: Alper Yegin > > > To: mobile-ip@sunroof.eng.sun.com > cc: (Barani Subbiah/HQ/3Com) > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > Charles, Barani, > > All it takes to avoid using FMIPv6 is the capability to be data connected at two > interfaces for few seconds. So, if there's overlap (worth few seconds) then one > can get away without using FMIPv6. > > During the overlap, the other interface is used to configure a new CoA and send > a BU to oldAR to establish forwarding from previous care-of address. After this > point old attachment can be released. > > I think few seconds overlap is reasonable. > > alper > > > Charles: Thanks for the scenario. > > > > Alper: you can think of the same scenario with no GPRS coverage inside the > > building. IMHO, we are going to see scenarios like this more often than a pure > > single access technology wireless data access. > > You can also think of same operator providing WWAN and WLAN (hot spot) > coverage > > and like to use fast MIP techniques. > > > > I like to suggest that we remove any dependency of L2 with FMIP techniques. > > > > Barani. > > > > > > > > > > > > Charles Qi Shen on 06/18/2001 02:57:39 AM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: Charles Qi Shen > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > Alper, > > > > I am not aware of what kinds of scenarios Barani may have in his mind. > > Please see whether my scenario can be something close to that. > > > > For example, you have a Mobile Node with two interfaces, one GPRS and one > > Wireless LAN, your company is covered by WLAN and you can use it for free > > within the company, while you are outside you will use GPRS. Since you pay > > for your GPRS but not the WLAN. You may wish to use WLAN *only* while > > inside the Company. In this case, it is not really this mobile node > > *cannot* have both interfaces connected, but it is the user choosing so. > > > > Charles > > > > At 05:26 PM 6/15/2001 -0700, you wrote: > > >Barani, > > > > > >Is there any reason why this mobile node cannot have both interfaces > > >connected > > >at the same time? Do you have a scenario where it can or it should have > > >only one > > >connected, although they are using different interfaces? > > > > > >alper > > > > > > > > > > > > > > Alper, > > > > > > > > No. It is a single mobile with multiple links but connects via a single > > > link > > >at > > > > any given time to a single AR. However, after hand off it connects to > > > new AR > > >via > > > > a different link. Example would be WLAN and WWAN or any other combination. > > > > > > > > Barani. > > > > > > > > > > > > > > > > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > > > > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > > > > > Sent by: Alper Yegin > > > > > > > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > cc: (Barani Subbiah/HQ/3Com) > > > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > > > > > > > > > Barani, > > > > > > > > > As in the draft and this thread, I like to point out that Link layer > > > address > > > > > based verification across ARs should be avoided as much as possible. > > > > > MN can have two interfaces and also move from one AR to another AR > > > using the > > > > new > > > > > L2 interface. > > > > > > > > > > If we want L2 identifier then there should be a way that MN can > > > indicate to > > > > the > > > > > old AR about the new Link layer ID that it will be using plus the > > > current L2 > > > > ID. > > > > > > > > > > > > > If this is a mobile node with multiple links, which can be connected to > > > > different ARs at the same time, you most probably don't need FMIPv6 draft. > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > > > > >alper > > > > SHEN, Qi (Charles) > > Centre for Wireless Communications > > National University of Singapore > > 20 Science Park Rd. #02-34/37, TeleTech Park > > Singapore Science Park II, Singapore 117674 > > Tel: +65 870-9358 Fax: +65 779-5441 > > Email: shenqi@cwc.nus.edu.sg > > URL: http://www.cwc.nus.edu.sg > > > > > > > > > > > > > > alper > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 21 21:15:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22952 for ; Thu, 21 Jun 2001 21:15:03 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03015; Thu, 21 Jun 2001 18:14:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08650; Thu, 21 Jun 2001 18:14:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5M1DDdP028544 for ; Thu, 21 Jun 2001 18:13:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5M1DDBq028543 for mobile-ip-dist; Thu, 21 Jun 2001 18:13:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5M1D9dP028536 for ; Thu, 21 Jun 2001 18:13:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07470 for ; Thu, 21 Jun 2001 18:13:18 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17519 for ; Thu, 21 Jun 2001 19:14:06 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA29093 for ; Thu, 21 Jun 2001 18:13:16 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5M1DFx19923 for ; Thu, 21 Jun 2001 18:13:15 -0700 X-mProtect: Thu, 21 Jun 2001 18:13:15 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdKL2b49; Thu, 21 Jun 2001 18:13:14 PDT Message-ID: <3B329BAB.3CAEDF88@iprg.nokia.com> Date: Thu, 21 Jun 2001 18:13:15 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] LLA option in the fast handoffs draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, I have a question on the Link Layer address option (sec 4.4.2 in the fast handoffs draft). Shouldnt the length of the option be in terms of octets and not 8 octets? Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 21 23:31:47 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27205 for ; Thu, 21 Jun 2001 23:31:46 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27298; Thu, 21 Jun 2001 20:32:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA24209; Thu, 21 Jun 2001 20:31:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5M3UZdP028679 for ; Thu, 21 Jun 2001 20:30:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5M3UZTr028678 for mobile-ip-dist; Thu, 21 Jun 2001 20:30:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5M3UWdP028671 for ; Thu, 21 Jun 2001 20:30:32 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5M3UYG337859 for ; Thu, 21 Jun 2001 20:30:34 -0700 (PDT) Message-Id: <200106220330.f5M3UYG337859@jurassic.eng.sun.com> Date: Thu, 21 Jun 2001 20:30:39 -0700 (PDT) From: Alper Yegin Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: zZnXegA1pVOWpxvwzhRxaQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barani, > There might be cases where MN doesn't have this few seconds, and need to use > FMIPv6. In this case, the L2 indetifier MN send in F-BU does not match the L2 > identifier it'll be using at the new link. That means newAR cannot detect this > "mobile node" at L2, but instead needs to wait for the F-NA, which is in the > draft. > > I don't see this as a "L2 dependency". > > So, draft has a solution for your scenario (F-NA). But of course, we'd like to > hear your proposal as well. > > >>>> We have tried to create a new ID called Association ID (AID), which is > created using AR L2 address, thus unique to each ARs. When a MN associated with > a AR, both MN and AR exchange this AID and agree to use this AID if and when > there is a hand off. > So, in the HI message from old AR to new AR, we can send this AID instead of L2 > ID. > Once the MN move to new AR, it should send this AID to new AR so that new AR can > bind the AID and new L2 address and/or AID and new CoA. > It can be in F-NA. We are experimenting to see if we can extend the "ARP" to > carry this AID to the new AR. My proposal is that if we can find a way to get > this AID at the same time when L2 identification happens then we get the same > effect of moving with same L2. As long as there's a way MN can negotiate this AID with the oldAR while it's attached to it, and MN can communicate this AID to newAR to signals it's arrival, I don't think there's anyhting that holds implementations from sending this AID in HI message... (pretend this is the L2 address of MN). I guess this AID exchanges can happen outside FMIPv6 protocol signaling. But, if you are saying that we should put this AID in F-NA message, then I'd ask why we need this? If this is used to associate a fast handoff with the arrival of the MN, then F-NA carries oldCoA and newCoA to accomplish this. alper > > > alper > > > > > Alper, > > > > I am not sure if this is a valid assumption to design a solution that works > > given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will > > be the most prevalent wireless data access scenario and Mobile IP has lots to > > gain to propose solutions that works across heterogeneous access (L2) > > technologies. > > > > Again, I want to emphasis that we remove any L2 dependency with FMIP. There > are > > other ways to solve the problem with out using L2 identifier. > > > > Barani. > > > > > > > > > > Alper Yegin on 06/18/2001 07:58:43 PM > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > Sent by: Alper Yegin > > > > > > To: mobile-ip@sunroof.eng.sun.com > > cc: (Barani Subbiah/HQ/3Com) > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > Charles, Barani, > > > > All it takes to avoid using FMIPv6 is the capability to be data connected at > two > > interfaces for few seconds. So, if there's overlap (worth few seconds) then > one > > can get away without using FMIPv6. > > > > During the overlap, the other interface is used to configure a new CoA and > send > > a BU to oldAR to establish forwarding from previous care-of address. After > this > > point old attachment can be released. > > > > I think few seconds overlap is reasonable. > > > > alper > > > > > Charles: Thanks for the scenario. > > > > > > Alper: you can think of the same scenario with no GPRS coverage inside the > > > building. IMHO, we are going to see scenarios like this more often than a > pure > > > single access technology wireless data access. > > > You can also think of same operator providing WWAN and WLAN (hot spot) > > coverage > > > and like to use fast MIP techniques. > > > > > > I like to suggest that we remove any dependency of L2 with FMIP techniques. > > > > > > Barani. > > > > > > > > > > > > > > > > > > Charles Qi Shen on 06/18/2001 02:57:39 AM > > > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > > > Sent by: Charles Qi Shen > > > > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > cc: (Barani Subbiah/HQ/3Com) > > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > > > > > Alper, > > > > > > I am not aware of what kinds of scenarios Barani may have in his mind. > > > Please see whether my scenario can be something close to that. > > > > > > For example, you have a Mobile Node with two interfaces, one GPRS and one > > > Wireless LAN, your company is covered by WLAN and you can use it for free > > > within the company, while you are outside you will use GPRS. Since you pay > > > for your GPRS but not the WLAN. You may wish to use WLAN *only* while > > > inside the Company. In this case, it is not really this mobile node > > > *cannot* have both interfaces connected, but it is the user choosing so. > > > > > > Charles > > > > > > At 05:26 PM 6/15/2001 -0700, you wrote: > > > >Barani, > > > > > > > >Is there any reason why this mobile node cannot have both interfaces > > > >connected > > > >at the same time? Do you have a scenario where it can or it should have > > > >only one > > > >connected, although they are using different interfaces? > > > > > > > >alper > > > > > > > > > > > > > > > > > > Alper, > > > > > > > > > > No. It is a single mobile with multiple links but connects via a single > > > > link > > > >at > > > > > any given time to a single AR. However, after hand off it connects to > > > > new AR > > > >via > > > > > a different link. Example would be WLAN and WWAN or any other > combination. > > > > > > > > > > Barani. > > > > > > > > > > > > > > > > > > > > > > > > > Alper Yegin on 06/14/2001 07:40:23 PM > > > > > > > > > > Please respond to mobile-ip@sunroof.eng.sun.com > > > > > > > > > > Sent by: Alper Yegin > > > > > > > > > > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > cc: (Barani Subbiah/HQ/3Com) > > > > > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > > > > > > > > > > > > > > > > > > Barani, > > > > > > > > > > > As in the draft and this thread, I like to point out that Link layer > > > > address > > > > > > based verification across ARs should be avoided as much as possible. > > > > > > MN can have two interfaces and also move from one AR to another AR > > > > using the > > > > > new > > > > > > L2 interface. > > > > > > > > > > > > If we want L2 identifier then there should be a way that MN can > > > > indicate to > > > > > the > > > > > > old AR about the new Link layer ID that it will be using plus the > > > > current L2 > > > > > ID. > > > > > > > > > > > > > > > > If this is a mobile node with multiple links, which can be connected to > > > > > different ARs at the same time, you most probably don't need FMIPv6 > draft. > > > > > > > > > > alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >alper > > > > > > SHEN, Qi (Charles) > > > Centre for Wireless Communications > > > National University of Singapore > > > 20 Science Park Rd. #02-34/37, TeleTech Park > > > Singapore Science Park II, Singapore 117674 > > > Tel: +65 870-9358 Fax: +65 779-5441 > > > Email: shenqi@cwc.nus.edu.sg > > > URL: http://www.cwc.nus.edu.sg > > > > > > > > > > > > > > > > > > > > > > alper > > > > > > > > > > > > alper > > > > > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 22 07:14:05 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16194 for ; Fri, 22 Jun 2001 07:14:04 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06693; Fri, 22 Jun 2001 04:13:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28242; Fri, 22 Jun 2001 04:13:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MBCOdP028999 for ; Fri, 22 Jun 2001 04:12:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MBCOTU028998 for mobile-ip-dist; Fri, 22 Jun 2001 04:12:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MBCKdP028991 for ; Fri, 22 Jun 2001 04:12:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27395 for ; Fri, 22 Jun 2001 04:12:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29264 for ; Fri, 22 Jun 2001 05:12:24 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15834; Fri, 22 Jun 2001 07:11:49 -0400 (EDT) Message-Id: <200106221111.HAA15834@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc2002-bis-05.txt Date: Fri, 22 Jun 2001 07:11:48 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mobileip-rfc2002-bis-05.txt Pages : 95 Date : 21-Jun-01 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2002-bis-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-rfc2002-bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010621134322.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2002-bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010621134322.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 23 12:00:45 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12591 for ; Sat, 23 Jun 2001 12:00:44 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03774; Sat, 23 Jun 2001 08:59:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07193; Sat, 23 Jun 2001 08:59:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NFwTdP000473 for ; Sat, 23 Jun 2001 08:58:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NFwTDo000472 for mobile-ip-dist; Sat, 23 Jun 2001 08:58:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NFwQdP000465 for ; Sat, 23 Jun 2001 08:58:26 -0700 (PDT) Received: from awe171-106 (awe195-63.AWE.Sun.COM [192.29.195.63]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA25518; Sat, 23 Jun 2001 08:58:32 -0700 (PDT) Message-Id: <200106231558.IAA25518@heliopolis.eng.sun.com> Date: Sat, 23 Jun 2001 07:50:10 -0700 (PDT) From: kempf Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: om7JZS69F59hxUXj96XCCA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 i86pc i386 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Barani, What do you mean by "dependency on L2"? IHMO, it is simply not possible to achieve performance sufficient for real time media without some form of L2 support. I'm not talking about a specific L2, if you look at the FMIPv4 paper, you'll see that we have defined an abstraction layer for L2 that can be applied to a wide variety of L2. A similar situation exists with respect to minimum path MTU in IPv6. IPv6 requires that either the L2 support a minimum path MTU having a certain value, or that a shim be written in the driver to perform segmentation and reassembly. The IPv6 spec does not specify one particular L2 but rather an (admittedly simple) abstraction that an L2 should support for efficient IPv6 implementation. W.r.t. FMIP, if a particular L2 does not support the necessary abstractions, then either a shim layer needs to be written or designers should not expect to get seamless handoff of real time media over it. jak >From: Barani_Subbiah@3com.com >X-Lotus-FromDomain: 3COM >To: mobile-ip@sunroof.eng.sun.com >cc: mobile-ip@sunroof.eng.sun.com >Date: Mon, 18 Jun 2001 10:55:25 -0700 >Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 >Content-Disposition: inline >List-Owner: > > > >Charles: Thanks for the scenario. > >Alper: you can think of the same scenario with no GPRS coverage inside the >building. IMHO, we are going to see scenarios like this more often than a pure >single access technology wireless data access. >You can also think of same operator providing WWAN and WLAN (hot spot) coverage >and like to use fast MIP techniques. > >I like to suggest that we remove any dependency of L2 with FMIP techniques. > >Barani. > > > > > >Charles Qi Shen on 06/18/2001 02:57:39 AM > >Please respond to mobile-ip@sunroof.eng.sun.com > >Sent by: Charles Qi Shen > > >To: mobile-ip@sunroof.eng.sun.com >cc: (Barani Subbiah/HQ/3Com) >Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 > > > >Alper, > >I am not aware of what kinds of scenarios Barani may have in his mind. >Please see whether my scenario can be something close to that. > >For example, you have a Mobile Node with two interfaces, one GPRS and one >Wireless LAN, your company is covered by WLAN and you can use it for free >within the company, while you are outside you will use GPRS. Since you pay >for your GPRS but not the WLAN. You may wish to use WLAN *only* while >inside the Company. In this case, it is not really this mobile node >*cannot* have both interfaces connected, but it is the user choosing so. > >Charles > >At 05:26 PM 6/15/2001 -0700, you wrote: >>Barani, >> >>Is there any reason why this mobile node cannot have both interfaces >>connected >>at the same time? Do you have a scenario where it can or it should have >>only one >>connected, although they are using different interfaces? >> >>alper >> >> >> > >> > Alper, >> > >> > No. It is a single mobile with multiple links but connects via a single >> link >>at >> > any given time to a single AR. However, after hand off it connects to >> new AR >>via >> > a different link. Example would be WLAN and WWAN or any other combination. >> > >> > Barani. >> > >> > >> > >> > >> > Alper Yegin on 06/14/2001 07:40:23 PM >> > >> > Please respond to mobile-ip@sunroof.eng.sun.com >> > >> > Sent by: Alper Yegin >> > >> > >> > To: mobile-ip@sunroof.eng.sun.com >> > cc: (Barani Subbiah/HQ/3Com) >> > Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 >> > >> > >> > >> > Barani, >> > >> > > As in the draft and this thread, I like to point out that Link layer >> address >> > > based verification across ARs should be avoided as much as possible. >> > > MN can have two interfaces and also move from one AR to another AR >> using the >> > new >> > > L2 interface. >> > > >> > > If we want L2 identifier then there should be a way that MN can >> indicate to >> > the >> > > old AR about the new Link layer ID that it will be using plus the >> current L2 >> > ID. >> > > >> > >> > If this is a mobile node with multiple links, which can be connected to >> > different ARs at the same time, you most probably don't need FMIPv6 draft. >> > >> > alper >> > >> > >> > >> > >> > >> >>alper > >SHEN, Qi (Charles) >Centre for Wireless Communications >National University of Singapore >20 Science Park Rd. #02-34/37, TeleTech Park >Singapore Science Park II, Singapore 117674 >Tel: +65 870-9358 Fax: +65 779-5441 >Email: shenqi@cwc.nus.edu.sg >URL: http://www.cwc.nus.edu.sg > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 23 13:34:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13851 for ; Sat, 23 Jun 2001 13:34:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26533; Sat, 23 Jun 2001 11:33:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24659; Sat, 23 Jun 2001 10:33:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NHWEdP000625 for ; Sat, 23 Jun 2001 10:32:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NHWEjw000624 for mobile-ip-dist; Sat, 23 Jun 2001 10:32:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NHWAdP000617 for ; Sat, 23 Jun 2001 10:32:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09097 for ; Sat, 23 Jun 2001 10:32:18 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA25931 for ; Sat, 23 Jun 2001 11:32:16 -0600 (MDT) Received: (qmail 1052 invoked by uid 500); 23 Jun 2001 17:21:09 -0000 Date: Sat, 23 Jun 2001 10:21:09 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] welcome back Message-ID: <20010623102109.W14828@charizard.diameter.org> References: <200106231558.IAA25518@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106231558.IAA25518@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Sat, Jun 23, 2001 at 07:50:10AM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: welcome back. Boy, do I have lots to talk about. We have a meeting tomorrow at 1pm in menlo somewhere. I think we should get together around 11 in menlo to chat. Have a great one. PatC From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 23 19:38:13 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19285 for ; Sat, 23 Jun 2001 19:38:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26640; Sat, 23 Jun 2001 17:36:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09273; Sat, 23 Jun 2001 16:36:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NNZhdP000941 for ; Sat, 23 Jun 2001 16:35:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NNZhV0000940 for mobile-ip-dist; Sat, 23 Jun 2001 16:35:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NNZddP000933 for ; Sat, 23 Jun 2001 16:35:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09232 for ; Sat, 23 Jun 2001 16:35:47 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA24329 for ; Sat, 23 Jun 2001 16:35:46 -0700 (PDT) Received: (qmail 1858 invoked by uid 500); 23 Jun 2001 23:24:38 -0000 Date: Sat, 23 Jun 2001 16:24:38 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] My stupidity! Message-ID: <20010623162437.X14828@charizard.diameter.org> References: <200106231558.IAA25518@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106231558.IAA25518@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Sat, Jun 23, 2001 at 07:50:10AM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: All, I should have known better. this list has bitten me before, and I guess I haven't learned my lesson yet. I really wish that this list was configured the way it use to be... as I've asked many times, but were ignored. I know others have been bitten as well. Oh well, PatC From owner-mobile-ip@sunroof.eng.sun.com Sun Jun 24 19:04:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16689 for ; Sun, 24 Jun 2001 19:04:36 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21958; Sun, 24 Jun 2001 16:04:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27709; Sun, 24 Jun 2001 16:04:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5ON2xdP002104 for ; Sun, 24 Jun 2001 16:02:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5ON2xdw002103 for mobile-ip-dist; Sun, 24 Jun 2001 16:02:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5ON2tdP002096 for ; Sun, 24 Jun 2001 16:02:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29557 for ; Sun, 24 Jun 2001 16:03:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06762 for ; Sun, 24 Jun 2001 16:03:02 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA23208; Sun, 24 Jun 2001 15:58:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5OMw0906281; Sun, 24 Jun 2001 15:58:00 -0700 X-mProtect: Sun, 24 Jun 2001 15:58:00 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdRLEJYY; Sun, 24 Jun 2001 15:57:59 PDT Message-ID: <3B367077.D151E38D@iprg.nokia.com> Date: Sun, 24 Jun 2001 15:57:59 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: porce@ktf.co.kr Subject: Re: [mobile-ip] [Q] Sending a packet to a BUed MN References: <00c601c0e4f8$a10733c0$ae0a060a@n016.co.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Jiwoong, Jiwoong Lee wrote: > > All, > > MobileIPv6 recommneds the use of a routing header to send a packet to a > Binding update requested mobile node. Because the document does not specify > the use of routing header type, the correspondent node SHOULD be able to > generate a different kind of routing header type which is NOT zero. I guess > this statement is omitted intentionally. Yes, I think this is right. > But why ? And what if the > correspondent node wants loose source routing that is not for Mobile IP > routing optimization and direct forwarding to the mobile node ? If the correspondent node wants to use loose source routing for some reason not related to Mobile IP, then I think that should still work fine. Do you see any reason why it would not? > I believe section 8.9 of Mobile IPv6-13 should be reinforced tightly. I don't remember previous discussion on this point, but I reckon that the intention was to allow other kinds of source routing headers to work just as well as type-0 routing headers. If someone specifies a routing header that has some property causing the care-of address not to work any longer, which is difficult for me to imagine (but not impossible), then I reckon it would be the work of that future specification to make the determination about how the system should react when using Mobile IP. This topic engendered quite a bit of discussion on the ipng mailing list. I'm catching up, but I don't believe that there are Mobile IPv6 action items directly related to that discussion. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 05:20:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09408 for ; Mon, 25 Jun 2001 05:20:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12913; Mon, 25 Jun 2001 03:20:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10247; Mon, 25 Jun 2001 02:19:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9ImdP002946 for ; Mon, 25 Jun 2001 02:18:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P9Imqe002945 for mobile-ip-dist; Mon, 25 Jun 2001 02:18:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9IjdP002938 for ; Mon, 25 Jun 2001 02:18:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04059 for ; Mon, 25 Jun 2001 02:18:54 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA25505 for ; Mon, 25 Jun 2001 03:19:45 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5P9IpO18499 for ; Mon, 25 Jun 2001 11:18:51 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jun 25 11:18:49 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Jun 2001 11:13:12 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008A58@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] questions on fast handoffs for MIPv6 Date: Mon, 25 Jun 2001 11:18:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I am not sure if this is a valid assumption to design a solution that works > > given few seconds of overlap. The scenarios such as BT-WLAN-WWAN-Ethernet will > > be the most prevalent wireless data access scenario > > > => That's certainly debatable to say the least, but I guess > this is a side topic for this list. Which asumptions in the draft do you > disagree with ? Do you disagree that some overlap between > coverage areas is required ? I find that hard to believe since this > is the fundamental requirement for ANY wireless system. > > //// The discussion so far is that does MN need to have connectivity to both AR > domains at same time (L3 at old AR and L2 at new AR). > => Yes I followed that discussion. The point is that if you do have it then you can use standard MIPv6, if you don't then you should use this draft. Overlap != simultaneous connectivity and receiving two independant traffic streams. Every wireless system has overlap between coverage area, but that doesn't equate to a "make before break" handover. > current 802.11 spec does not allow a client to connect to 2 APs at any time. > => I am aware of that. see above. > > Again, I want to emphasis that we remove any L2 dependency with FMIP. > > > => We are doing a handover because we're moving within the topology. > Topological movement can be due to physical movement (L2 changes) > or changes in the topology. In the former I can't see how you could > possibly eliminate the need for an L2 indication. In the latter you > rely less on L2 knowledge but knowing it is a good optimisation. > Which scenario doesn't require L2 knowledge ? > > /// There is a difference between L2 assistance and dependence. You are > referring to L2 assistance and it is a good thing to have, but not the later. > L3 solutions can use L2 indications but should not expect the same L2 appear on > the other side after the handoff. > => Agreed. I still don't see where the L2 dependancy is ? The draft only relies on assistance. Having overlapping coverage areas is an assumption you can safely make abouany wireless system that provides an acceptable handover performance. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 06:25:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09833 for ; Mon, 25 Jun 2001 06:25:53 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04720; Mon, 25 Jun 2001 03:25:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07531; Mon, 25 Jun 2001 03:25:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PANedP003092 for ; Mon, 25 Jun 2001 03:23:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PANeCY003091 for mobile-ip-dist; Mon, 25 Jun 2001 03:23:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PANadP003084 for ; Mon, 25 Jun 2001 03:23:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13911 for ; Mon, 25 Jun 2001 03:23:45 -0700 (PDT) Received: from samar.sasken.com (samar.sasken.com [164.164.56.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21847 for ; Mon, 25 Jun 2001 03:23:35 -0700 (PDT) Received: from samar (localhost [127.0.0.1]) by samar.sasken.com (8.11.3/8.11.3) with SMTP id f5PANSt22523 for ; Mon, 25 Jun 2001 15:53:28 +0530 (IST) Received: from SATISHJ (pcd-1-217.sasi.com [10.0.19.217]) by sund2.sasi.com (8.9.3/8.9.3) with SMTP id PAA29996 for ; Mon, 25 Jun 2001 15:53:30 +0530 (IST) Message-ID: <002c01c0fd61$77459dc0$d913000a@SATISHJ> From: "Satish Jamadagni" To: References: <200106201816.f5KIGbG890848@jurassic.eng.sun.com> Subject: [mobile-ip] A question on fast handoffs for MIPv6 Date: Mon, 25 Jun 2001 15:57:41 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit All, In the fast handoff draft for IPv6, It is mentioned that in the mobile initiated handoff (Consider an inter technology handoff scenario) a router solicitation for proxy with some access network information is sent by the mobile (I assume that the access network is the new access network to which the mobile plans to handoff).In the inter-technology case handoffs will be mostly mobile initiated - so this information will be hard to come by for a mobile. Can any one direct me to what kind of access network information is sent - are there any specs that are comming up to define this information. Satish Jamadagni Sasken Communication technologies Ltd, The Soft-Radio project Bangalore - 560 008 From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 08:19:47 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12640 for ; Mon, 25 Jun 2001 08:19:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAB17983; Mon, 25 Jun 2001 06:19:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16683; Mon, 25 Jun 2001 05:19:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PCI4dP003244 for ; Mon, 25 Jun 2001 05:18:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PCI4Lr003243 for mobile-ip-dist; Mon, 25 Jun 2001 05:18:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PCI0dP003236 for ; Mon, 25 Jun 2001 05:18:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20033 for ; Mon, 25 Jun 2001 05:18:10 -0700 (PDT) Received: from cs.chonbuk.ac.kr ([210.117.172.28]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03718 for ; Mon, 25 Jun 2001 05:17:32 -0700 (PDT) Received: from cs.chonbuk.ac.kr ([210.117.172.216]) by cs.chonbuk.ac.kr (8.9.1/8.9.1) with ESMTP id VAA07297 for ; Mon, 25 Jun 2001 21:04:38 +0900 (KST) Message-ID: <3B372BDC.8DF18151@cs.chonbuk.ac.kr> Date: Mon, 25 Jun 2001 21:17:32 +0900 From: Gihwan Cho Organization: Chonbuk National University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: ko,en-US MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Presentation materials of mobile IP WG meeting at IETF50 Content-Type: text/plain; charset=EUC-KR Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by patan.sun.com id GAB17983 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA12640   Hi all, Can anybody point me the presentation materials of mobile IP WG meeting at IETF50 (if possible, IETF49 as well). Thanks in advance, --ghcho -- Gihwan Cho, Ph.D. Dept. of Computing Science                  Voice: +82 63 270 3437 Chonbuk National University                  Fax : +82 63 270 3403 664-14 Duckjin-Dong, Duckjin-Gu         C.P.: 016 412 5323 Chonju, Chonbuk, 561-756, S. Korea     http://cs.chonbuk.ac.kr/~ghcho --   From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 08:51:48 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13795 for ; Mon, 25 Jun 2001 08:51:48 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18346; Mon, 25 Jun 2001 05:51:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17253; Mon, 25 Jun 2001 05:51:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PCngdP003316 for ; Mon, 25 Jun 2001 05:49:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PCngCU003315 for mobile-ip-dist; Mon, 25 Jun 2001 05:49:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PCncdP003308 for ; Mon, 25 Jun 2001 05:49:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17149 for ; Mon, 25 Jun 2001 05:49:48 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19524 for ; Mon, 25 Jun 2001 05:49:47 -0700 (PDT) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5PD87116178 for ; Mon, 25 Jun 2001 09:08:07 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010625085141.03d461a0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Jun 2001 08:52:33 -0400 To: mobile-ip@sunroof.eng.sun.com From: Marc Blanchet Subject: Re: [mobile-ip] Presentation materials of mobile IP WG meeting at IETF50 In-Reply-To: <3B372BDC.8DF18151@cs.chonbuk.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id FAA18346 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13795 At/À 21:17 2001-06-25 +0900, Gihwan Cho you wrote/vous écriviez: > >Hi all, > >Can anybody point me the presentation materials of >mobile IP WG meeting at IETF50 (if possible, IETF49 as well). See http://www.ietf.org/proceedings/directory.html Marc. >Thanks in advance, > >--ghcho > >-- >Gihwan Cho, Ph.D. >Dept. of Computing Science Voice: +82 63 270 3437 >Chonbuk National University Fax : +82 63 270 3403 >664-14 Duckjin-Dong, Duckjin-Gu C.P.: 016 412 5323 >Chonju, Chonbuk, 561-756, S. Korea http://cs.chonbuk.ac.kr/~ghcho >-- > From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 16:16:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25994 for ; Mon, 25 Jun 2001 16:16:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15016; Mon, 25 Jun 2001 13:16:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06575; Mon, 25 Jun 2001 12:46:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PJijdP004226 for ; Mon, 25 Jun 2001 12:44:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PJij2t004225 for mobile-ip-dist; Mon, 25 Jun 2001 12:44:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PJifdP004218 for ; Mon, 25 Jun 2001 12:44:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19494 for ; Mon, 25 Jun 2001 12:44:51 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06025 for ; Mon, 25 Jun 2001 13:45:44 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17508; Mon, 25 Jun 2001 12:44:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PJin926654; Mon, 25 Jun 2001 12:44:49 -0700 X-mProtect: Mon, 25 Jun 2001 12:44:49 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdewzj9e; Mon, 25 Jun 2001 12:44:47 PDT Message-ID: <3B3794B0.F92137DB@iprg.nokia.com> Date: Mon, 25 Jun 2001 12:44:48 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ken Powell CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-ietf-mobileip-ipv6-13 comments References: <88BD5A70CA8BFA4CA15D0ED053E49D691466D0@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ken, I've been delayed for quite a while in getting back to you on this, but it was never forgotten. I'm trying to catch up on the way to finishing the new draft. "Powell, Ken" wrote: > Section 4.6 Conceptual Data Structures > > I don't understand why the following Binding Cache field exists: > >> - The time at which a Binding Request was last sent for this >> entry, as needed to implement the rate limiting restriction >> for sending Binding Requests. > > I could find two reasons to send a Binding Request: > > o When a binding cache entry is about to time-out (see Section > 8.6). There is no suggestion that the correspondent node > should retransmit the binding request if the mobile node > does not respond. > > o When sending a Router Advertisement (see Section 9.8.3). In > this case, the Router Advertisement with Binding Request does > get retransmitted and rate-limiting applies. > > Was this Binding Cache field intended to support the rate > limiting restriction on the router advertisements? I think so. I guess that means that the actual restriction is the one placed on the advertisement. Therefore, I guess you mean to suggest that we can delete this field of the Binding Cache entry. I have done that, since I don't see any other reason to keep it. However, I'm open to further discussion! > Section 5.6 ICMP Home Agent Address Discovery Request Message > > What does the mobile node specify in the home address field > if it doesn't have a home address, like upon initialization? > Should it use the unspecified address in this case? O.K. This sounds fine to me, but I expect that there may be some networks where policy forbids the operation. Anyway, whether or not the operation works should be controlled by whether the mobile node can create a security association, and not by whether the protocol specification says which addresses to use. > Section 6.2 Modified Prefix Information Option Format > >> In a solicited Router Advertisement, a router MUST include at least >> one Prefix Information option with the Router Address (R) bit set. >> Neighbor Discovery specifies that, if including all options in a >> Router Advertisement causes the size of the Advertisement to exceed >> the link MTU, multiple Advertisements can be sent, each containing >> a subset of the options [17]. In this case, at least one of these >> multiple Advertisements being sent instead of a single larger >> solicited Advertisement, MUST include a Prefix Information option >> with the Router Address (R) bit set. > > Why are these MUST requirements applied to all routers instead > of just home agents? There is nothing in Neighbor Discovery or > this spec that relies on this information from IPv6 routers that > are not home agents. We can see how such information could support > applications outside the scope of ND and Mobility, but this doesn't > warrant an unconditional mandate. We would prefer to see something > like: > > + In a solicited Router Advertisement, a home agent MUST and all > + other routers SHOULD include at least one Prefix Information > + option with the Router Address (R) bit set.... Done. I agree with your analysis. > Section 7.2 Requirements for All IPv6 Routers > > Should this section list the new requirements from > section 6.2? > > + - all routers SHOULD include at least one prefix with the R bit > + set and with it's full IP address in its router advertisements. Done. Thanks! > Section 9.2 Dynamic Home Agent Address Discovery > >> - For each entry in this home agents ... >> ... The selected global IP address for each home >> agent to include in forming the Home Agent Addresses field in the >> Reply message MUST be the global IP address of the respective >> home agent sharing a prefix with the mobile node's home address >> as indicated in the Home Address option in the Request message; > > During initialization, the mobile node may not have a home > address when it performs home agent address discovery. Assuming > the mobile node sent the unspecified address instead, what global > IP addresses does the home agent select? Perhaps it could > select IP addresses that share a prefix with the destination > address from the Home Agent Address Discovery Request packet's > IPv6 header instead. > > Same problem in the fourth rule for constructing the Home Agent > Addresses Field: > >> ... The selected global IP address for each home >> agent to include in forming the Home Agent Addresses field in the >> Reply message MUST be the global IP address of the respective >> home agent sharing a prefix with the mobile node's home address >> as indicated in the Home Address option in the Request message; Done. I replaced: "mobile node's home address as indicated in the Home Address option in" by "Destination IP address of" However, I only found one instance of the problem; your first example was, I think, the text in the fourth rule. Please let me know if somehow I missed something. > Section 9.5 Intercepting Packets for a Mobile Node > >> - The home agent examines the value of the Prefix Length field >> in the new "home registration" Binding Cache entry. If this >> value is zero, the following step is carried out only for the >> individual home address specified for this binding. If, instead, >> this field is nonzero, then the following step is carried out >> for each address for the mobile node formed from the interface >> identifier in the mobile node's home address in this binding >> (the remaining low-order bits in the address after the indicated >> subnet prefix), together with each one of the subnet prefixes >> currently considered by the home agent to be on-link ... > ============== > The home agent should forward messages considered by other > routers on the home network to be on-link as well. In other > words, we think the home agent should use the aggregate list > of home network prefixes for this. I don't know about this. It seems to me that the current wording is correct. I don't know about why a home agent would try to protect addresses that it considers to be off-link. >> - For each specific IP address for the mobile node determined >> in the first step above, the home agent multicasts onto the >> home link (to the all-nodes multicast address) a Neighbor >> Advertisement message [17] on behalf of the mobile node, to >> advertise the home agent's own link-layer address for this IP >> address. >> >> All fields in each such Neighbor Advertisement message SHOULD be >> set in the same way they would be set by the mobile node itself >> if sending this Neighbor Advertisement while at home [17], with >> the following exceptions: >> >> * The Target Address in the Neighbor Advertisement message MUST >> be set to the specific IP address for the mobile node. > > Does the home agent set the Neighbor Advertisement source IP > address to its own link-local address as opposed to the > mobile node's link-local address? I think the purpose is for the home agent to substitute its own link-layer address for that of the mobile node. And, it needs to do this for the mobile node's link-local IPv6 address also. Thus, I wouldn't expect for the home agent to use its own link-local address in that field. >> While a node is serving as a home agent for some mobile node (it >> still has a "home registration" entry for this mobile node in its >> Binding Cache), the home agent uses IPv6 Neighbor Discovery [17] >> to intercept unicast packets on the home link addressed the mobile >> node's home address. In order to intercept packets in this way, >> the home agent MUST act as a proxy for this mobile node to reply to >> any received Neighbor Solicitation messages for it. When a home >> agent receives a Neighbor Solicitation message, it MUST check if the >> Target Address specified in the message matches the home address >> of any mobile node for which it has a Binding Cache entry marked >> as a "home registration". This check MUST include all possible >> home addresses for the mobile node, based on the subnet prefixes >> currently considered to be on-link by the home agent ... > ================= > > The home agent probably should use the aggregate list of prefixes > for this as well? Maybe I'm missing something, but I think the "on-link" criterion is appropriate here as well. > Section 9.6 Tunneling Intercepted Packets to a Mobile Node > >> Tunneling of multicast packets to a mobile node follows similar >> limitations to those defined above for unicast packets addressed to >> the mobile node's link-local and site-local addresses. Multicast >> packets addressed to a multicast address with link-local scope [9], >> to which the mobile node is subscribed, MUST NOT be tunneled >> to the mobile node; such packets SHOULD be silently discarded >> (after delivering to other local multicast recipients). Multicast >> packets addressed to a multicast address with scope larger >> than link-local but smaller than global (e.g., site-local and >> organization-local) [9], to which the mobile node is subscribed, >> SHOULD be tunneled to the mobile node by default, but this behavior >> MUST be configurable to disable it; this default behavior might >> change at some point in the future as the definition of these >> scopes become better defined in IPv6. > > This spec does not explain how a home agent determines what > multicast addresses to forward to a mobile node. Host systems > normally send Multicast Listener Discovery (MLD) messages to > attached routers to join/leave multicast groups. The rules > for doing this between mobile node and home agent are undefined. Not really...? Why can't the tunneled packets use the same rule as in other cases. In other words, the mobile node should use a Home Address destination option here, but that would be implicit. It would be a mistake for the Mobile IPv6 specification to go specify the inclusion of the Home Address option for _every_ possible application between endpoints. Tunneling is not essentially different here, as far as I can tell. > The text above and in section 10.19 indicates a bi-directional > tunnel could be used to support this. There is no clear definition > of how to set up such a tunnel. What addresses are used for > tunnel source and destination? Would the tunnel have its own > link local and global interface addresses? Will it carry MLD > traffic specifically for the mobile node? What other traffic > should such a tunnel between a mobile node and the home agent > carry? I don't think there is a problem here. The tunnel should be set up just like any tunnel would be set up. The outer header should have the natural IP addresses. A home address destination option would be used as normal. The inner header should have the same field values as if the mobile node were on its home network. Policy determination for tunnel use is, I reckon, outside the scope of the Mobile IPv6 specification. Otherwise, we would have to do it for every protocol, not just MLD. That could be bad, and seems like a major potential source for specification errors. > IMHO we should not try to solve the multicast tunneling > issues now. Instead, descriptions of tunneling multicast > traffic should be removed from the spec and left for future > work. Perhaps the spec could say something like: > > + It may be possible to tunnel multicast traffic between > + a mobile node and it's home agent to extend the range of > + a multicast zone. The rules for setting up such tunnels and > + for identifying which traffic to forward is beyond the scope > + of this spec. As of now, I don't believe this is the right technical direction; I have left the current specification as is. > 9.8.3. Sending Mobile Prefix Advertisements to the Mobile Node > >> The home agent SHOULD periodically continue to retransmit this >> tunneled packet to the mobile node, until it is acknowledged by >> the receipt from the mobile node of a Binding Update matching >> the Binding Request in the packet (i.e., with matching Sequence >> Number). A Binding Update matches a Binding Request if it specifies >> a binding for the mobile node to which the Binding Request was sent >> and contains a Unique Identifier Sub-Option matching the unique >> identifier sent in the Unique Identifier Sub-Option in the Binding >> Request. > > At what rate should this retransmission occur? Once per > INITIAL_BINDACK timeout? > > How many router advertisements should the home agent send > before it gives up? > > Should retransmissions stop if the mobile node's binding is > deleted? I have added the following: The home agent SHOULD periodically continue to retransmit an unsolicited Advertisement to the mobile node, until it is acknowledged by the receipt from the mobile node of a Binding Update matching the Binding Request in the packet (i.e., with matching Sequence Number). The home agent MUST wait PREFIX_ADV_TIMEOUT before the first retransmission, and double the retransmission wait time for every succeeding retransmission, up until a maximum of PREFIX_ADV_RETRIES attempts. If the mobile node's bindings expire before the matching Binding Update has been received, then the home agent MUST NOT attempt any more retransmissions, even if not all PREFIX_ADV_RETRIES have been retransmitted. After another Binding Update is received from the mobile node, and if the mobile node has not returned to the home network in the meantime, the home agent SHOULD begin the process again of transmitting the unsolicited Advertisement. Thanks for the roadmap about what needed to be done. > Section 10.19 Routing Multicast Packets > > > Alternatively, a mobile node MAY join multicast groups via a > > bi-directional tunnel to its home agent. The mobile node tunnels its > > multicast group membership control packets to its home agent, and the > > home agent forwards multicast packets down the tunnel to the mobile > > node. > > > > A mobile node that wishes to send packets to a multicast group > > also has two options: (1) send directly on the foreign link being > > visited; or (2) send via a tunnel to its home agent. Because > > multicast routing in general depends upon the Source Address used in > > the IPv6 header of the multicast packet, a mobile node that tunnels a > > multicast packet to its home agent MUST use its home address as the > > IPv6 Source Address of the inner multicast packet. > > Same concern with multicast messages as for section 9.6. We think > this spec should describe option (1) and leave option (2) as beyond > scope for now. Well, I hope we can keep the specification. It's likely to work well enough for Proposed Standard, and deployment and experience are clearly needed. > Section 10.20 Returning Home > >> ..... >> In addition, when returning home prior to the expiration of a current >> binding for its home address, and configuring its home address on its >> network interface on its home link, the mobile node MUST NOT perform >> Duplicate Address Detection on its own home address, in order to >> avoid confusion or conflict with its home agent's use of the same >> address. ..... > > Could a mobile node perform DAD if it had knowledge of the home > agent's link layer address? It could work as follows: > > 1) the mobile node runs DAD when it moves to any new > physical link; > 2) if this happens on the home link, the home agent will > respond with a neighbor advertisement defending the mobile > node's address; > 3) the mobile node recognizes the home agent's link > layer address in the neighbor solicit and thus > determines it moved home; > 4) the mobile node immediately sends a binding update > to the home agent to delete the binding (no neighbor > solicit needed); > 5) the home agent responds with a binding ack to > signal that the binding is deleted and the home > agent is no longer defending the mobile node's > home address; > 6) The mobile node runs DAD again; > 7) Communication proceeds as normal. I don't see anything wrong with this, but on the other hand I am reluctant to put it into the revised protocol specification without some additional working group discussion. > 11. Protocol Constants > >> HomeRtrAdvInterval 1,000 seconds > > This is the maximum interval between periodic router > advertisements from the home agent to the mobile node. > Given that advertisements are acknowledged and the > periodic advertisements are primarily a fail-safe > feature, would it be reasonable to increase this to > something like 36000 seconds (1 hour) to further > overhead? I guess you meant 3600 seconds. So, I made that change. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 16:35:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26391 for ; Mon, 25 Jun 2001 16:35:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21001; Mon, 25 Jun 2001 13:28:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13714; Mon, 25 Jun 2001 13:22:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PKLFdP004497 for ; Mon, 25 Jun 2001 13:21:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PKLFEp004496 for mobile-ip-dist; Mon, 25 Jun 2001 13:21:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PKLBdP004486 for ; Mon, 25 Jun 2001 13:21:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13463 for ; Mon, 25 Jun 2001 13:21:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08709 for ; Mon, 25 Jun 2001 13:21:20 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA20521; Mon, 25 Jun 2001 13:21:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PKLDG15534; Mon, 25 Jun 2001 13:21:13 -0700 X-mProtect: Mon, 25 Jun 2001 13:21:13 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdBf7s66; Mon, 25 Jun 2001 13:21:11 PDT Message-ID: <3B379D38.AFAB76C4@iprg.nokia.com> Date: Mon, 25 Jun 2001 13:21:12 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ken Powell CC: mobile-ip@sunroof.eng.sun.com, "'T.J. Kniveton'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D692457C7@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again Ken, > Section 4.5 New IPv6 ICMP Messages > > Should this section mention the new ICMP Mobile Prefix > Solicitation and ICMP Mobile Prefix Advertisement > messages? Yes, definitely! Done. (Thanks, T.J.!) > Section 5.8 ICMP Mobile Prefix Solicitation Message Format > > Will the Destination Option extension header with a > Home Address option normally be included? The exception > would be during mobile node initialization when the > mobile node does not have a home address yet. Agreed. I reckon this should just follow normal rules for sending packets. Does it need to be stated explicitly? > 5.9 ICMP Mobile Prefix Advertisement Message Format > > > Destination Address > > If a Mobile Prefix Solicitation was sent, the Source > > Address field from that packet. > > If the Mobile Prefix Solicitation contained a home address > option, should the should this Destination Address be set > to the mobile node's home address? Wouldn't the packet be sent with a routing header? If so, then this should follow normal rules for sending packets. > >> For unsolicited >> message, the mobile node's home address or care-of >> address may be used. > > I don't think the home agent should send an > unsolicited MPA message to the mobile node's > care-of address. Unsolicited messages should only > be sent when there is a valid home registration, > and in that case, sending to the home address seems > the best approach. Always doing so would probably > make it easier for the mobile node to associate > the advertisement with a particular home network. Agreed. > > This message header should include a reserved > field to align the remaining prefix options on > a 64-bit boundary. Here I am not so sure. The Prefix Information option doesn't start with a 64-bit field, and I didn't find any specification that required an _option_ to be aligned in a certain way -- only that the data fields in the option should be aligned in a certain way. I can see both sides of the argument, and the picture at the beginning of section 4.6 of RFC 2461 doesn't appear to mandate the restriction. >> The Prefix Information option is defined in Section >> 4.6.2 of [17]. The home agent MAY use the modified >> option described in this draft to convey other home >> agents' global addresses as well as their prefixes. > > Section 9.8.1 indicates the home agent clears > global address information of other routers when > building the aggregate prefix list. It also calls > this a SHOULD requirement. Therefore, I think this > statement should be changed to: > > + The Prefix Information Option is defined in > + Section 4.6.2 of [17] with modifications defined > + 6.2 of this specification. The home > + agent uses this option to send an aggregate > + list of home network prefixes as defined in > + Section 9.8.1." Done. > It may be helpful to allow the Source Link Layer > Address option on the Mobile Prefix Advertisement > message. As section 10.20 points out, the home agent's > link layer address can be very handy to know before > returning home. > > I think you should also allow the Advertisement Interval > Option to support processing defined in Section 10.16. Good ideas. Done. > 9.8.1. Building Aggregate List of Home Network Prefixes > > > A mobile node on a remote network SHOULD autoconfigure all of > > the global IP addresses, which it would autoconfigure if it were > > attached to its home network, that are served by home agents. > ============================== > What does this underlined phrase mean? It means that the mobile node should only get home addresses this way for networks that are served by home agents; I have changed the wording to hopefully make that clearer. > > > To support this, the home agent monitors prefixes advertised on > > the home link by itself and other home agents, and passes the ... > ===================== > > Why limit this to prefixes from other home agents only? Why not > use prefixes from any router? I don't think that was the intention. > >> - Check Router Advertisements which contain an H bit (from other >> home agents) for valid prefixes that are not yet in the >> aggregate list, and if they are usable for autoconfiguration >> (A bit set, and prefix length less than 80 bits) add them and >> preserve the L flag value. Clear the R flag and zero the >> interface-id portion of the > > Same question on home agent advertisement restriction. Why > not use prefixes from all routers on the home subnet? What if those other prefixes don't have home agents > I noticed you added an interesting optimization of filtering > out any prefixes not used for autoconfiguration. This seems > like a reasonable thing to do. The mobile node ignores this > info when off link, and will rediscover all it needs soon > after moving home. Should this same filter be used to restrict > which prefixes from the home agent's AdvPrefixList are copied > to the aggregate list? > > I don't understand the test for "length less than 80 bits". > I assume that a node cannot autoconfigure to prefixes with > different lengths on the same link. The specific length > allowed is defined in the "IPv6 over foo" spec (where "foo" > is a link type like "ethernet"). Perhaps change this test > to "the prefix length is valid for address autoconfiguration > on the home subnet". Done. More soon. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 17:49:14 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27978 for ; Mon, 25 Jun 2001 17:49:13 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27156; Mon, 25 Jun 2001 14:45:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00587; Mon, 25 Jun 2001 14:20:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PLIVdP005231 for ; Mon, 25 Jun 2001 14:18:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PLIV90005230 for mobile-ip-dist; Mon, 25 Jun 2001 14:18:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PLIRdP005220 for ; Mon, 25 Jun 2001 14:18:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26958 for ; Mon, 25 Jun 2001 14:18:38 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02973 for ; Mon, 25 Jun 2001 14:18:37 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA24953; Mon, 25 Jun 2001 14:18:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PLI0X03813; Mon, 25 Jun 2001 14:18:00 -0700 X-mProtect: Mon, 25 Jun 2001 14:18:00 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdbYmVyJ; Mon, 25 Jun 2001 14:17:59 PDT Message-ID: <3B37AA88.663F7444@Kniveton.com> Date: Mon, 25 Jun 2001 14:18:00 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: Ken Powell , mobile-ip@sunroof.eng.sun.com, "'T.J. Kniveton'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D692457C7@tayexc14.americas.cpqcorp.net> <3B379D38.AFAB76C4@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks for the message Charlie. I agree with all your comments, and would like to add the following: "Charles E. Perkins" wrote: > > > Destination Address > > > If a Mobile Prefix Solicitation was sent, the Source > > > Address field from that packet. > > > > If the Mobile Prefix Solicitation contained a home address > > option, should the should this Destination Address be set > > to the mobile node's home address? This level of indirection is unnecessary, and will only work sometimes; specifically, we can't rely on a home address option, and using the option when it is there is OK, but not necessary. We don't need to preserve a MN's Home Address in an advertisement -- the MN should be ready to receive a MPA at the same address it sent the MPS from, specifically the COA. Of course I might be wrong, so let me know if there is a better way to support both of these cases. > Wouldn't the packet be sent with a routing header? If so, > then this should follow normal rules for sending packets. A mobile prefix solicitation will sometimes be sent from a mobile node that is trying to construct a home address; thus, you can't rely on an home address option. > > 9.8.1. Building Aggregate List of Home Network Prefixes > > > > > A mobile node on a remote network SHOULD autoconfigure all of > > > the global IP addresses, which it would autoconfigure if it were > > > attached to its home network, that are served by home agents. > > ============================== > > What does this underlined phrase mean? > > It means that the mobile node should only get home addresses > this way for networks that are served by home agents; I have > changed the wording to hopefully make that clearer. Yes, that was bad wording. The old requirement was that the MN should be able to autoconfigure all of the addresses it could on the home network. I added *another* filter, that only the addresses that are served by a HA (and thus, usable while away from home) should be required. > > > > > > To support this, the home agent monitors prefixes advertised on > > > the home link by itself and other home agents, and passes the ... > > ===================== > > > > Why limit this to prefixes from other home agents only? Why not > > use prefixes from any router? > > I don't think that was the intention. Actually it was my intention, so please correct me here because this is important. In the general case, I do not see how a MN can use a prefix being advertised on its home link, unless a home agent is willing to "serve" that prefix by accepting registrations for addresses on the prefix, and thus forwarding packets to the MN while it is roaming. So, are you suggesting that a home agent would want to serve mobile nodes that do not use a home address on a prefix that the HA is advertising? > >> - Check Router Advertisements which contain an H bit (from other > >> home agents) for valid prefixes that are not yet in the > >> aggregate list, and if they are usable for autoconfiguration > >> (A bit set, and prefix length less than 80 bits) add them and > >> preserve the L flag value. Clear the R flag and zero the > >> interface-id portion of the > > > > Same question on home agent advertisement restriction. Why > > not use prefixes from all routers on the home subnet? > > What if those other prefixes don't have home agents (see above question) > > I noticed you added an interesting optimization of filtering > > out any prefixes not used for autoconfiguration. This seems > > like a reasonable thing to do. The mobile node ignores this > > info when off link, and will rediscover all it needs soon > > after moving home. Should this same filter be used to restrict > > which prefixes from the home agent's AdvPrefixList are copied > > to the aggregate list? In a sense, that was what I was attempting to do above. I was thinking that the more complexity that can be cut out of constructing, sending, and receiving/processing the list, the better. But of course this is not supposed to be at the expense of doing things the wrong way, so please share your alternate thoughts about how to do it. > > > > I don't understand the test for "length less than 80 bits". > > I assume that a node cannot autoconfigure to prefixes with > > different lengths on the same link. The specific length > > allowed is defined in the "IPv6 over foo" spec (where "foo" > > is a link type like "ethernet"). Perhaps change this test > > to "the prefix length is valid for address autoconfiguration > > on the home subnet". Well yes, to be precise we could change the wording to say the prefix has a length less than or equal to 128 minus the interface identifier length for the media type in use, which is more or less equivalent to your suggestion. In other words, sounds good to me. :) > > Done. > > More soon. > > Regards, > Charlie P. Thanks Charlie and Ken. -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 18:41:49 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28801 for ; Mon, 25 Jun 2001 18:41:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22526; Mon, 25 Jun 2001 15:40:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27937; Mon, 25 Jun 2001 15:39:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PMbhdP006034 for ; Mon, 25 Jun 2001 15:37:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PMbgcL006033 for mobile-ip-dist; Mon, 25 Jun 2001 15:37:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PMbddP006026 for ; Mon, 25 Jun 2001 15:37:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16337 for ; Mon, 25 Jun 2001 15:37:48 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27388 for ; Mon, 25 Jun 2001 15:37:47 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA00733; Mon, 25 Jun 2001 15:37:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PMbk806340; Mon, 25 Jun 2001 15:37:46 -0700 X-mProtect: Mon, 25 Jun 2001 15:37:46 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdo5vHzV; Mon, 25 Jun 2001 15:37:44 PDT Message-ID: <3B37BD34.C63BDCD8@iprg.nokia.com> Date: Mon, 25 Jun 2001 15:37:40 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "T.J. Kniveton" CC: Ken Powell , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D692457C7@tayexc14.americas.cpqcorp.net> <3B379D38.AFAB76C4@iprg.nokia.com> <3B37AA88.663F7444@Kniveton.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello T.J., > > > > If the Mobile Prefix Solicitation contained a home address > > > option, should the should this Destination Address be set > > > to the mobile node's home address? > > This level of indirection is unnecessary, and will only work sometimes; > specifically, we can't rely on a home address option, and using the > option when it is there is OK, but not necessary. We don't need to > preserve a MN's Home Address in an advertisement -- the MN should be > ready to receive a MPA at the same address it sent the MPS from, > specifically the COA. I understand that it might not be necessary, and doesn't always work, but the default address model means that the mobile node should use its home address when it has one, and the home agent should send packets to the home address when it needs to send packets to the mobile node. I guess the question is whether the message _always_ invokes exceptional processing, or whether the exceptional processing is only invoked for exceptional conditions, like missing Home Address option. > Of course I might be wrong, so let me know if there is a better way to > support both of these cases. > > > Wouldn't the packet be sent with a routing header? If so, > > then this should follow normal rules for sending packets. > > A mobile prefix solicitation will sometimes be sent from a mobile node > that is trying to construct a home address; thus, you can't rely on an > home address option. I think the same discussion applies here. > > > > > To support this, the home agent monitors prefixes advertised on > > > > the home link by itself and other home agents, and passes the ... > > > ===================== > > > > > > Why limit this to prefixes from other home agents only? Why not > > > use prefixes from any router? > > > > I don't think that was the intention. > > Actually it was my intention, so please correct me here because this is > important. In the general case, I do not see how a MN can use a prefix > being advertised on its home link, unless a home agent is willing to > "serve" that prefix by accepting registrations for addresses on the > prefix, and thus forwarding packets to the MN while it is roaming. > > So, are you suggesting that a home agent would want to serve mobile > nodes that do not use a home address on a prefix that the HA is > advertising? No, my wording was bad. I was trying to say that the intention was _not_ to use addresses from routers that are not home agents, but since I was in a hurry I didn't put enough text around it to be clear. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 19:04:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29146 for ; Mon, 25 Jun 2001 19:04:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01279; Mon, 25 Jun 2001 16:02:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02140; Mon, 25 Jun 2001 16:00:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PMxJdP006335 for ; Mon, 25 Jun 2001 15:59:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PMxIic006334 for mobile-ip-dist; Mon, 25 Jun 2001 15:59:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PMxFdP006327 for ; Mon, 25 Jun 2001 15:59:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23934 for ; Mon, 25 Jun 2001 15:59:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09862 for ; Mon, 25 Jun 2001 15:59:24 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA02517; Mon, 25 Jun 2001 15:59:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PMxKY07927; Mon, 25 Jun 2001 15:59:20 -0700 X-mProtect: Mon, 25 Jun 2001 15:59:20 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdnRl5cM; Mon, 25 Jun 2001 15:59:18 PDT Message-ID: <3B37C231.7AF7CD86@iprg.nokia.com> Date: Mon, 25 Jun 2001 15:58:57 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" CC: mobile-ip@sunroof.eng.sun.com, "'T.J. Kniveton'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements ... additional thought References: <88BD5A70CA8BFA4CA15D0ED053E49D692457CD@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ken, I didn't see any other discussion about this on the mailing list, so I didn't make the corresponding change to the document. However, I think that one can go even farther. - The Binding Acknowledgement could be a destination option in the Mobile Prefix Advertisement (MPA). If the mobile node does NOT get the MPA, then it would retransmit the Binding Update since the Binding Acknowledgement was never received. In the case, if the mobile node only had one home address and it was getting renumbered to have a new prefix, then the home agent does NOT need to get a Binding Update, since it can assume that either: - the mobile node will receive the Binding Acknowledgement - the mobile node will retransmit the Binding Update. So, a typical exchange could be exactly two messages. What do you think about that? Of course, if there are lots of prefixes and lots of home addresses involved, the same logic does not necessarily hold. But perhaps we ought to make the simple cases really simple. Maybe there should be another bit in the MPA to say whether the Binding Update is requested or not. Regards, Charlie P. "Powell, Ken" wrote: > I've been wondering about the coupling between mobile > prefix solicitation/advertisement and binding request/ > update/ack. > > Specifically: > - Section 9.8.2 describes how a binding update could > trigger a mobile prefix advertisement > - Section 9.8.3 describes how a binding request/update is > used to acknowledge the mobile prefix advertisement > > This leads me to consider the following exchange: > > mobile node <--> home agent > =========================== > --> binding update w/ ack bit set > (destination option processing on home agent handles > processes binding update and sends binding ack, > then signals ICMP mobile prefix handler to check > for pending advertisements) > <-- binding ack > <-- mobile prefix advertisement w/ binding request > --> binding update w/ ack bit set > <-- binding ack > > It seems we could simplify the exchange rules by > adding an ICMP mobile prefix ack message that could be > used to replace the final binding request/update/ack > exchange. > > --> binding update w/ ack bit set > <-- binding ack > <-- mobile prefix advertisement > --> mobile prefix ack > > Ken From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 19:31:46 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29684 for ; Mon, 25 Jun 2001 19:31:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA12230; Mon, 25 Jun 2001 16:31:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27396; Mon, 25 Jun 2001 16:31:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PNU7dP006428 for ; Mon, 25 Jun 2001 16:30:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PNU7t1006427 for mobile-ip-dist; Mon, 25 Jun 2001 16:30:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PNU1dP006420 for ; Mon, 25 Jun 2001 16:30:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00111 for ; Mon, 25 Jun 2001 16:30:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25183 for ; Mon, 25 Jun 2001 16:30:06 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA04954; Mon, 25 Jun 2001 16:30:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5PNU0o09406; Mon, 25 Jun 2001 16:30:00 -0700 X-mProtect: Mon, 25 Jun 2001 16:30:00 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdT1NQDD; Mon, 25 Jun 2001 16:29:57 PDT Message-ID: <3B37C940.A3307134@iprg.nokia.com> Date: Mon, 25 Jun 2001 16:29:04 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" CC: mobile-ip@sunroof.eng.sun.com, "'T.J. Kniveton'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D692457C7@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ken, I'm back with more. "Powell, Ken" wrote: > > ..... It may > > be possible to construct an aggregate list by combining information > > contained in the home agent's AdvPrefixList and its Home Agent List > > used for Dynamic Home Agent Address Discovery (section 10.7). > > I don't think this will work. Only prefixes with the "R" bit > set are added to the home agent's list. There is no guarantee > that all prefixes with an "A" bit set will also have the "R" bit set. The Home Agents List is formed from home agents that advertise with the 'H' bit set. The AdvPrefixList is preconfigured. Should there be additional restrictions on which home agent addresses can be placed in the Home Agent list? In particular, I don't see that it is necessary for the home network to support "autonomous" address autoconfiguration in order for a home agent on that network to be listed in the Home Agents List. So far, I don't see what change is needed to the specification for this issue, but I will await further discussion. > 9.8.2 Sending Changed Prefix Information to the Mobile Node > > I have multiple concerns in this section. I wish we had > a proposal ready to fix these, but that's not so easy. > > 1) There is a requirement at the end of section 9.8.3 > to send all prefixes periodically. This is necessary > to avoid eventual expiration of prefixes that don't > change on the mobile node. Between this section, and > 9.8.3, I'm confused about when all prefixes get sent > as opposed to just sending changes. > > 2) I don't fully understand what your trying to do with > the following MAY requirements: > > > MUST: > > - The valid or preferred lifetime or the state of the flags > > changes for the prefix of the mobile node's registered home > > address changes > > - The mobile node requests the information with a Router > > Solicitation (see section 10.16). > > > > MAY: > > - A new prefix is added to the aggregate list > > - The valid or preferred lifetime or the state of the flags > > changes for a prefix which is not used in any binding cache > > entry for this mobile node I think this is O.K., as T.J. has noted in a much earlier message. > > > It looks like its addressing a problem I've been > wondering about. A mobile node with multiple home > addresses could either > > - establish a single binding with a non-zero prefix > length to cover all its home addresses, or > > - establish multiple bindings each with a zero prefix > length to cover a single home address. > > In the latter case, how does the home agent recognize > that a single node has multiple bindings? The home agent > shouldn't send duplicate home prefix advertisements to > the mobile node. > > One way to fix this for the home agent to only send > prefix information that is applicable to a specific > binding. If the prefix length of the binding is zero, > send information only for the home address's prefix. > If the prefix length is non-zero, send information for > all addresses in the aggregate list. I'm not very clear on this, but I hope that in general that the home agent can send as many addresses as possible at once. Otherwise, there will get to be some weird timing dependencies on sending Binding Updates, retransmissions, and asking for more home agent addresses. > 3) There may be a problem if the scheduling algorithm causes > the home agent to transmit a home prefix advertisement to > all mobile nodes at the same time. There probably should > be a requirement to avoid this. Perhaps the scheduling of > prefix advertisements should be done independently for each > home registration? Yes, this was the intention. However, it needs to be made clearer in the specification so that the intention is more obvious. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Jun 25 23:19:03 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05540 for ; Mon, 25 Jun 2001 23:19:03 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22417; Mon, 25 Jun 2001 21:18:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27118; Mon, 25 Jun 2001 20:18:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3H0dP006943 for ; Mon, 25 Jun 2001 20:17:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3Gx8K006942 for mobile-ip-dist; Mon, 25 Jun 2001 20:16:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3GudP006935 for ; Mon, 25 Jun 2001 20:16:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA07622 for ; Mon, 25 Jun 2001 20:17:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22508 for ; Mon, 25 Jun 2001 20:17:05 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA16800; Mon, 25 Jun 2001 20:17:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5Q3H3o11319; Mon, 25 Jun 2001 20:17:03 -0700 X-mProtect: Mon, 25 Jun 2001 20:17:03 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd3OQugx; Mon, 25 Jun 2001 20:16:59 PDT Message-ID: <3B37FC9D.B5793A32@iprg.nokia.com> Date: Mon, 25 Jun 2001 20:08:13 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" CC: "'T.J. Kniveton'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) References: <88BD5A70CA8BFA4CA15D0ED053E49D69067D70@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Powell, Ken" wrote: > Hi T.J., > > Vlad Yasevich, Brian Haley, Greg Colburn and I > finished our discussion of your proposal. This is the > remainder of our comments. Many comments also apply > to draft-ietf-mobileip-ipv6-13 without your changes > as well. > > Ken Powell > Compaq Computer Corporation > > 5.8 Mobile Prefix Solicitation Message Format > > My comments to section 9.8.2 below request that only the prefixes > that match a particular home registration be sent to the mobile > node in Mobile Prefix Advertisements. If the binding has a zero > prefix length, only the specific prefix for the mobile node's > home address would be sent. For a bindings with a non-zero prefix > length, all prefixes in the aggregate list would be sent. I'm going to go out on a limb here, and suggest that the existing semantics for the Prefix Length option need substantial change. I might be missing something, but having a nonzero prefix length seems to only have the effect of requesting that the home agent should provide service for more home addresses. The addresses served by the home are determined by the collection of on-link prefixes, not the actual value of the Prefix Length field. Thus, this purpose could be managed by a single bit. That would allow us to use the Prefix Length field for something more important -- namely to serve the same function as the proposed "Mobile Router Prefix Length Sub-Option", which I wrote about earlier and put into the existing intermediate (unfinished) draft which I am trying to finish now. Then we could get rid of that Sub-Option and have a more natural specification. > This left a problem, what prefixes do we send in response to a > Router Solicitation? I think the home agent should use the > same prefix selection logic, but the mobile node needs a way to > override this behavior to support initialization. One option is > to add a flag to the Mobile Prefix Solicitation Message: > > + Send All Prefixes flag > + > + If clear, the home agent replies by sending only the prefixes > + that match the mobile nodes home registration as defined in > + section 9.8.2. If set, the home agent will send all prefixes > + for the home network as defined in section 9.8.1. No prefixes > + will be sent if this flag is clear and the mobile node does > + not yet have a home registration. So, in a way, I am supporting this suggestion. > 9.8.2 Sending Changed Prefix Information to the Mobile Node > > Due to the number of comments on this section, I'm including > the entire text with ">" marks, and slicing in the comments > where they apply. > > > A home agent serving a mobile node will schedule the delivery > > of new prefix information to that mobile node when any of the > > following conditions occur: > > Can the following list of MUST and MAY requirements be merged > into the algorithm for sending prefix information below? Maybe -- especially if you think it will be clearer. Would you be willing to suggest some reorganized text? However, one list says how to figure out that the list needs to be sent, and the other list says how to figure out when to send it. > > > > MUST: > > - The valid or preferred lifetime or the state of the flags > > changes for the prefix of the mobile node's registered home > > address changes > > - The mobile node requests the information with a Router > > Solicitation (see section 10.16). > > > > MAY: > > - A new prefix is added to the aggregate list > > Why is this a MAY instead of MUST? Is it to cover the case > where a home registration has a zero prefix length? It's a MAY because it won't hurt the mobile node not to find out this information. > > - The valid or preferred lifetime or the state of the flags > > changes for a prefix which is not used in any binding cache > > entry for this mobile node > > I don't understand what your trying to do with this > last MAY requirement. Maybe the mobile node didn't like one of the prefixes because the lifetime was too short, and it changed to be long enough. Really, though, it's almost the same as the previous bullet, thus also a MAY. > It looks like its addressing a problem I've been wondering about. > A mobile node with multiple home addresses could either > > o establish a single binding with a non-zero prefix > length to cover all its home addresses, or > > o establish multiple bindings each with a zero prefix > length to cover a single home address. > > In the latter case, how does the home agent recognize > that a single node has multiple bindings? I believe the > home agent should avoid sending duplicate home prefix > advertisements to the mobile node. I'm not totally understanding this. It seems like a home agent is going to have one primary care-of address for a mobile node, and that is what binding the mobile node will effect. I agree that the home agent shouldn't send duplicate MPAs to the mobile node, insofar as it's possible to do so, but I didn't get the connection with the previous bullets, sorry. > One way to fix this is to have the home agent to only > send prefix information that is applicable to a specific > binding. Is that what your additional requirement was > after? If so, I agree with the intent, but believe more > detail is needed. Perhaps a statement like the following > would help at the start of this section: > > + A home agent normally sends only the prefixes that match > + a mobile node's home registration to the mobile node. A > + match exists if the home registration's home address > + contains a prefix or if the home registration's prefix > + length field is non-zero. Each home registration entry > + in the binding cache MUST be treated as if it were > + created for a separate mobile node. I like the last sentence, but it belongs in the section on "Home Agent Operation.. The first sentences are are already implicit in the previous parts of the description of the Prefix Lengths field (as it is currently, that is). > > The home agent uses the following algorithm to determine when to > > send prefix information to the mobile node. > > There is a requirement at the end of section 9.8.3 to send all > prefixes periodically. I think that requirement should be folded > into this section to avoid confusion between the two sections. > > + - Send a Home Agent Prefix Advertisement periodically to prevent > + non-decrementing prefixes from expiring on the mobile node. > + Calculate the interval between each successive transmission > + independently as rand()*HomeRtrAdvInterval seconds; I did put in a new bullet according to your suggestion, but I was not so clear about randomizing the interval. I see that it would be a good idea to avoid having a lot of advertisements happening all at once, but the nature of the Binding Update process seems to imply that the transmissions will effectively be randomized anyway, and with a longer period between periodic transmissions. > > - If a mobile node sends a solicitation, answer right away. > > If the proposal for the Send All Prefixes flag is accepted, > the following text should be added here: > > + If the Send All Prefixes flag in the solicitation was set, > + include all prefixes from the aggregate list in the advertisement. But that would amount to saying the same thing in two different places, unnecessarily, wouldn't it? > > - If a prefix changes state in a way that causes a mobile node's > > address to go deprecated, send an advertisement right away. > > I believe the algorithm for RAND_ADV_DELAY covers this situation. > It will cause an advertisement to be sent right away if a change > causes an address to go deprecated. Can we remove this special > case from here simplify the text? I have done so at your suggestion. > > - For any existing prefix, if the mobile node's binding expires > > before the advertised Preferred Lifetime, do not schedule the > > advertisement. The mobile node will get the revised information > > in its next Binding Acknowledgement. > > This is covered in the RAND_ADV_DELAY scheduling algorithm below. > Can we remove it from here to simplify the text? O.K. > > - If a prefix is added, or if it changes in any way that does not > > ============= > > cause the mobile node's address to go deprecated, ensure that a > > ================================================ > > transmission is scheduled at time RAND_ADV_DELAY in the future. > > Same comment as before, do we need the special case text that is > underlined? Also, this probably should be qualified to be more > precise. O.K. I removed the text. > + - If a prefix in the aggregate list that matches the mobile node's > + home registration is added or its information changes, ensure that > + a transmission is scheduled at time RAND_ADV_DELAY in the future. I basically merged this with the previous text. > > - If a prefix advertisement is scheduled, and a Binding Update > > arrives, perform that advertisement and include the information > > in a Router Advertisement that has the Binding Acknowledgement as > > ==================== > > a Destination Option. Remove the future scheduled advertisement. > > Did you mean Mobile Prefix Advertisement here? > > Is it really necessary to send the Binding Acknowledgement in the > same message as the Mobile Prefix Advertisement? I suspect this > will be awkward to implement given that Binding Acknowledgements are > probably handled in the kernel and Mobile Prefix Advertisements > in a daemon. I made it a SHOULD. > The 3rd rule in this list says "do not schedule the advertisement" > if a binding update is expected before the prefix becomes > deprecated. The 5th rule says to send an advertisement if "a > prefix advertisement is scheduled". Any change that satisfies > 3rd rule will never be sent. Perhaps this last rule should say: > > + - If there are any unacknowledged changes to prefix information > + when a Binding Update arrives for the home registration, send > + a Mobile Prefix Advertisement to the mobile node > immediately. + If an > advertisement was previously scheduled for the changes, Done. > Should the following be added here for completeness? > > + - If a home registration expires, cancel any scheduled > + advertisements to the mobile node. Done. > > The home agent uses the following algorithm to compute > > RAND_ADV_DELAY, the offset from the current time for the > > scheduled transmission. > > > > If there is a transmission already scheduled, then > > > > if the current RAND_ADV_DELAY would cause another > > transmission BEFORE the Preferred Lifetime of the > > mobile node's home address derived from the prefix whose > > advertisement information has changed, then > > > > add the new information to be transmitted to the > > existing scheduled transmission -- return. > > > > otherwise, > > > > continue with the following computation, and add the > > data from the existing scheduled transmission to the > > newly scheduled transmission, deleting the previously > > scheduled transmission event. > > I understood that the reason for sending only the changed prefix > information instead of all prefix information is to reduce the > connection costs for the mobile nodes on expensive wireless > networks. We don't believe the cost savings for this extra > complexity will be significant. We would prefer this to be an > optional feature. You suggest that the home agent should be allowed to send more than the minimum amount of information. This is O.K., except that I didn't find a good place to insert the necessary text. If you can suggest some text, I'll put it in. However, the important thing is that the Mobile Node _MUST_ be able to correctly interpret a partial list to contain only _changed_ information. A mobile node should not assume that missing advertisements mean that the prefix has been deleted. The latter operation has to be done by other means. > > > If the mobile node's binding expires after the Preferred Lifetime, > > then compute > > The indentation following this text could be interpreted to mean > we still need to compute RAND_ADV_DELAY even when the IF condition > here is false. As an alternative, perhaps a rewording of this IF > clause combined with text from above would be helpful. > > + If the mobile node's binding expires before the Preferred Lifetime, > + then return. The mobile node will get the revised information > + with its next Binding Acknowledgement. Otherwise, continue with the > + following computation: > > > MAX_SCHEDULE_DELAY == > > min (MAX_PFX_ADV_DELAY, Preferred Lifetime) > > > > for the newly advertised Preferred Lifetime. > > Then compute RAND_ADV_DELAY = > > MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) > > There may be a problem overwhelming system or network resources > if the scheduling algorithm causes the home agent to transmit a > home prefix advertisement to all mobile nodes at the same time. > The spec should allow a mechanism to avoid this. This was supposed to be part of the point of the RAND_ADV_ DELAY. > + A home agent SHOULD perform scheduling of advertisements > + described in this section independently for each home > + registration in the binding cache to avoid a burst of > + advertisements being sent to all mobile nodes at the same time. > + In addition, a home agent MAY throttle transmission of > + advertisements to prevent overwhelming local resources when > + the rules above require immediate transmission of advertisements > + to large numbers of mobile nodes. I used most of your words here. > Section 9.8.3 Sending Mobile Prefix Advertisements to the Mobile Node > > > - When the advertisement was triggered by network renumbering, the > > advertisement MUST include a Binding Request destination option. > > I agree with your intent of not requesting ACKs for > every advertisement, but I don't think the term "triggered > by network renumbering" catches all the important situations. > How does the following sound? > > + The advertisement MUST include a Binding Request destination > + option if this is the first advertisement sent for a home > + registration or if there was a change in prefix information > + since the last acknowledged advertisement was sent to the > + mobile node for the home registration. Done! > > > > The home agent SHOULD periodically continue to retransmit this > > tunneled packet to the mobile node, until it is acknowledged by > ======== > > The term "tunneled" was removed elsewhere in section 9.8. > Should it be removed here too? Done. > > [Delete this paragraph? This is also too much.] > > Whenever a mobile node has a valid binding on a network other > > than its home network, the home agent MUST send a Mobile Prefix > > Advertisement with all prefixes in the aggregate list to the > > mobile node at least once per HomeRtrAdvInterval seconds, and > > upon receipt of a valid Router Solicitation from the mobile > > node. O.K. I reckon it's already been covered earlier. > I have no idea what "a network other than its home network" > means, but I think a requirement to periodically transmit > all prefixes is needed because home addresses on mobile nodes > still have a finite lifetime that will expire unless > periodically updated. As I stated above, I think this requirement > fits better in section 9.8.2. It's there now. > Section 10.16 Sending Mobile Prefix Solicitations > > > The mobile node SHOULD send a Solicitation to the home agent > > when its home address will become invalid within MaxRtrAdvInterval > > seconds, where this value is acquired in a previous Router > > Advertisement from the home agent. ... ====== > ============= > > Should this be Mobile Prefix Advertisement? Done. > > If the mobile node does not have a valid home address available for > > use as the IP source address, it MAY use its care-of address, [but > > there will not be a security association between the Home Agent and > > the care-of address for the corresponding Advertisement to be > > authenticated.] > > We think some kind of security association will be needed here. I don't know how to specify that, and the home agent can limit this. > Section 10.17 Receiving Mobile Prefix Advertisements > > > - The Source Address of the IP packet carrying the Router > > Advertisement is ..... ====== > ============= > > Should this be Mobile Prefix Advertisement? Fixed. > > Since the advertisement contains a Binding Request option, the mobile > > node SHOULD return a Binding Update, which will be viewed by the home > > agent as an acknowledgement of the corresponding Mobile Prefix > > Advertisement, which it can cease retransmitting. > > Should this paragraph start with "If the advertisement contains..."? > The Binding Request option does not always need to be included with > a Mobile Prefix Advertisement. Fixed. > Appendix A: Remote Home Address Configuration > > I noticed you didn't attempt to fix this part. How about: > > Delete: > > > A mobile node MAY generate a temporary home address using the > > following information: > > > > - the subnet prefix from the home network's mobile agent anycast > > address, and > > > > - the globally unique interface identifier that would have been > > used to generate the link local address if the mobile node were > > attached directly to the home network. > > > > Such a temporary address could be used to establish a binding with > > a home agent in the absence of any other known home addresses. It > > could be created with short valid lifetime and a preferred lifetime > > of zero to ensure a quick transition to other addresses generated > > when stateless or stateful (DHCPv6) address autoconfiguration runs. > > Your new Mobile Prefix Solicit/Advertisement exchange capability > between the mobile node's care-of address and home agent makes this > hack unnecessary. > > Change steps 5 through 9 to: > > + 5. Select the most preferred home agent and establish a security > + association between the mobile node's current care-of address > + and the home agent for temporary use during initialization only. > + > + 6. Send a Home Prefix Solicitation message with the Request All > + Prefixes flag set to the home agent from the mobile node's > + care-of address. > + > + 7. Receive a Home Prefix Advertisement message from the home agent, > + follow stateless address autoconfiguration rules to configure > + home addresses for prefixes received. > + > + 8. Create a security association between the mobile node's home > + address and the home agent. > + > + 9. Send a binding update(s) to the home agent to register the > + mobile node's home addresses. > + > + 10. Receive binding acknowledgement(s) then begin normal > + communications. Done, to a close approximation. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 03:41:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24580 for ; Tue, 26 Jun 2001 03:41:25 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03207; Tue, 26 Jun 2001 01:41:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25656; Tue, 26 Jun 2001 00:41:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q7ctdP007538 for ; Tue, 26 Jun 2001 00:38:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q7ctZ3007537 for mobile-ip-dist; Tue, 26 Jun 2001 00:38:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q7cpdP007530 for ; Tue, 26 Jun 2001 00:38:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19248 for ; Tue, 26 Jun 2001 00:38:56 -0700 (PDT) Received: from tiger.korea.ac.kr (tiger.korea.ac.kr [163.152.209.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18097 for ; Tue, 26 Jun 2001 00:38:54 -0700 (PDT) Received: from jinwoo ([163.152.155.226]) by tiger.korea.ac.kr (8.11.0/8.11.0) with SMTP id f5Q7ZnZ20522 for ; Tue, 26 Jun 2001 16:35:49 +0900 Message-ID: <004301c0fe13$69446e60$e29b98a3@korea> From: =?ks_c_5601-1987?B?waTB+L/s?= To: Subject: [mobile-ip] [Movement dection in MIPv4] Date: Tue, 26 Jun 2001 16:41:28 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C0FE5E.D90A84A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C0FE5E.D90A84A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgd291bGQgbGlrZSB0byBrbm93IGlmIE1vdmVtZW50IGRldGVjdGlvbiB1c2lu ZyBJUCBzb3VyY2luZyByb3V0aW5nIHdhcyBzdWdnZXN0ZWQsLg0KDQpJIGhhdmUgcmVzZWFyY2hl ZCBtb3ZlbWVudCBkZWN0aW9uIG1ldGhvZCBpbiBNSVB2NCwgYW5kIA0KDQp3ZSB3aWxsIHByb3Bv c2UgbmV3IG1ldGhvZCB1c2luZyBzdHJpY3Qgc291cmNlIHJvdXRpbmcuDQoNClNvLCBJIHRoaW5r IHRoaXMgYXBwcm9jaCBpcyBub3RoaW5nIHByb2JsZW0sIA0KDQpidXQgaWYgYW55Ym9keSBrbm93 cyBzaW1pbGFyIG1ldGhvZCBvciBwcm9ibGVtIG9mIHRoaXMgbWV0aG9kLA0KDQpwbHogZ2l2ZXMg bWUgYSBhZHZpY2UuDQoNClRoYW5rcyBpbiB5b3VyIGFkdmFuY2UuDQoNCg0KDQoNCg0KDQoNCg== ------=_NextPart_000_0040_01C0FE5E.D90A84A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ2MTYuMjAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+SGVsbG8sPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+SSB3b3VsZCBsaWtlIHRvIGtub3cgaWYgTW92ZW1lbnQgZGV0ZWN0aW9uIHVz aW5nIElQIHNvdXJjaW5nIA0Kcm91dGluZyB3YXMgc3VnZ2VzdGVkLC48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5J Jm5ic3A7aGF2ZSByZXNlYXJjaGVkIG1vdmVtZW50IGRlY3Rpb24gbWV0aG9kIGluIE1JUHY0LCBh bmQgDQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj53ZSB3aWxsIHByb3Bvc2UgbmV3IG1ldGhvZCB1c2luZyBzdHJp Y3Qgc291cmNlIA0Kcm91dGluZy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5TbywmbmJzcDtJIHRoaW5rIHRoaXMg YXBwcm9jaCBpcyBub3RoaW5nIHByb2JsZW0sIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+YnV0IGlmIGFueWJv ZHkga25vd3Mgc2ltaWxhciBtZXRob2Qgb3IgPC9GT05UPjxGT05UIA0Kc2l6ZT0yPnByb2JsZW0g b2YgdGhpcyBtZXRob2QsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+cGx6IGdpdmVzIG1lIGEgYWR2aWNlLjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPlRoYW5rcyBpbiB5b3VyIGFkdmFuY2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0040_01C0FE5E.D90A84A0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 07:05:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27566 for ; Tue, 26 Jun 2001 07:05:34 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27117; Tue, 26 Jun 2001 04:05:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10850; Tue, 26 Jun 2001 04:05:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QB3YdP008153 for ; Tue, 26 Jun 2001 04:03:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QB3YHf008152 for mobile-ip-dist; Tue, 26 Jun 2001 04:03:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QB3SdP008135 for ; Tue, 26 Jun 2001 04:03:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10645 for ; Tue, 26 Jun 2001 04:03:36 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27561 for ; Tue, 26 Jun 2001 04:03:35 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27339; Tue, 26 Jun 2001 07:02:56 -0400 (EDT) Message-Id: <200106261102.HAA27339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-subbarao-mobileip-redundancy-00.txt Date: Tue, 26 Jun 2001 07:02:55 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Home Agent Redundancy in Mobile IP Author(s) : K. Leung, M. Subbarao Filename : draft-subbarao-mobileip-redundancy-00.txt Pages : Date : 11-Jun-01 In Mobile IP, a Home Agent (HA) creates a mobility binding table that tracks the association of a Mobile Node's (MN) home address with its current Care-of Address (CoA). If the HA fails, the mobility binding table will be lost and all MNs registered with the HA will lose connectivity. In this draft, we propose a Mobile IP Home Agent Redundancy framework mechanism that provides the essential robust redundancy needed at the HA. The mechanism described herein can also be used to provide the redundancy needed at any 'regional/local' HAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-subbarao-mobileip-redundancy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-subbarao-mobileip-redundancy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-subbarao-mobileip-redundancy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625110710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-subbarao-mobileip-redundancy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-subbarao-mobileip-redundancy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010625110710.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 10:02:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07773 for ; Tue, 26 Jun 2001 10:02:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21458; Tue, 26 Jun 2001 06:59:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22675; Tue, 26 Jun 2001 06:58:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QDuMdP008498 for ; Tue, 26 Jun 2001 06:56:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QDuLDu008497 for mobile-ip-dist; Tue, 26 Jun 2001 06:56:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QDuHdP008490 for ; Tue, 26 Jun 2001 06:56:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22398 for ; Tue, 26 Jun 2001 06:56:26 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05803 for ; Tue, 26 Jun 2001 06:56:25 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5QDuON24807; Tue, 26 Jun 2001 15:56:24 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id PAA18934; Tue, 26 Jun 2001 15:56:21 +0200 Message-ID: <3B389436.8245D388@era.ericsson.se> Date: Tue, 26 Jun 2001 15:55:02 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: marcelo CC: multi6@ops.ietf.org, alberto@it.uc3m.es, azcorra@it.uc3m.es, dlarra@it.uc3m.es, "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Re: Survey on proposed IPv6 multi-homing mechanisms References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Marcelo, [cross-posting to mobile-ip list] marcelo wrote: > > Hi, > > We have been working on a survey of proposals related to IPv6 multi-homing. > We think that this could be a good input for a discussion about > which of these ideas can be valuable, and need to be further developed. > We have included all the mechanisms that we have found. If there are other > mechanisms, please let us know. We have also includes some advantages and > concerns about the mechanisms, but we think that discusion will really > disclose much more points. [...] > 5. Mobility mechanisms > > Another proposal presented in [DUPNOT] is based in the use of IP > mobility mechanisms. The main idea is to use the care-of-address > assignation mechanism to switch between delegated addresses in case of > failure. Suppose that there is an established communication between > > Survey on multi-homing mecanisms 7 > > hostA belonging to the multi-homed site and hostB, somewhere in the > Internet, as shown in figure 4. > > ___________________________________________ > | Internet | > | hostB | > |___________________________________________| > | | > | | > +----+ +----+ > |ISPA| |ISPB| > |BRA | |BRB | > +----+ +----+ > | | > link1 | | link2 > __|____________________________|___ > | RA RB | > | | | | > | ------------------------------- | > | | | > | hostA | > | PrefA:Prefsite:hostA | > | PrefB:Prefsite:hostA | > | | > |___________________________________| > > Figure 4: Mobility mechanisms > > The established connection is being routed through ISPA and > PrefA:Prefsite:hostA is used. If ISPA fails, the described steps are > followed in order to preserve communication: > - HostA packets contain the home address destination option with > PrefA:Prefsite:hostA and PrefB:Prefsite:hostA as source address, so > that for every device on the path source address is > PrefB:Prefsite:hostA and only hostB replaces this source address by > PrefA:Prefsite:hostA. > - HostA sends a binding update containing PrefB:Prefsite:hostA as a > care-of address. Note that that authentication header is needed in > this packet. > - HostB sends a binding acknowledgement. This packet and all next > packets are sent with PrefA:Prefsite:hostA as final destination > (included in a routing header) and PrefB:Prefsite:hostA as next > destination (included as destination address). Consequently, all > packets are sent towards HostA using ISPB, and address "translation" > is done when packets reach HostA. > > Mechanism Evaluation: > > Advantages: > > - The mechanism provides complete fault tolerance. > - It uses existing protocols. > - It allows ISP selection for load sharing. > > Survey on multi-homing mecanisms 8 > > Concerns > > - Needs Mobile IP implementation on destination host. So, modifications > in external hosts are needed to achieve internal multi-homing. > - Mobile IP security mechanisms impose the use of authentication header, > raising complexity. > > Currently, Mobile IP WG has to come up with a solution to establish security associations between the MN (host A) and the CN (host B). SA establishment using public key infrastructure is assumed to not be available everywhere and with all CNs. The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak but strong enough for the purpose) mechanism that involves a home agent during the key exchange. The validity of the MN's binding of the home address is verified by the CN by sending packets via the home network. The home agent address belongs to the same prefix as the MN's home address, i.e. PrefA:Prefsite::. If no SA is set up prior to the failure of ISPA, the key exchange will fail since the CN can't send packets through the home agent any more. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 11:17:00 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19615 for ; Tue, 26 Jun 2001 11:16:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09053; Tue, 26 Jun 2001 09:11:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17644; Tue, 26 Jun 2001 08:11:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QFA4dP008716 for ; Tue, 26 Jun 2001 08:10:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QFA4Ak008713 for mobile-ip-dist; Tue, 26 Jun 2001 08:10:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QFA0dP008698 for ; Tue, 26 Jun 2001 08:10:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17394 for ; Tue, 26 Jun 2001 08:10:08 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21791 for ; Tue, 26 Jun 2001 08:10:06 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QF8fi35823; Tue, 26 Jun 2001 17:08:42 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA20117; Tue, 26 Jun 2001 17:08:41 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QF8aO88923; Tue, 26 Jun 2001 17:08:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261508.f5QF8aO88923@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mattias Pettersson cc: marcelo , multi6@ops.ietf.org, alberto@it.uc3m.es, azcorra@it.uc3m.es, dlarra@it.uc3m.es, "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Re: Survey on proposed IPv6 multi-homing mechanisms In-reply-to: Your message of Tue, 26 Jun 2001 15:55:02 +0200. <3B389436.8245D388@era.ericsson.se> Date: Tue, 26 Jun 2001 17:08:36 +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: [cross-posting to mobile-ip list] => please keep further messages in the multi6 list. > Concerns > > - Needs Mobile IP implementation on destination host. So, modifications > in external hosts are needed to achieve internal multi-homing. > - Mobile IP security mechanisms impose the use of authentication header, > raising complexity. Currently, Mobile IP WG has to come up with a solution to establish security associations between the MN (host A) and the CN (host B). SA establishment using public key infrastructure is assumed to not be available everywhere and with all CNs. => the mobility mechanism for IPv6 multi-homing was proposed before the security details were specified in the IPv6 mobility drafts... So don't expect that it works with any suggestion of this year (:-). More seriously, the idea was that if the mechanism is applied to critical connections then these connections are already protected by some mechanisms, i.e. the key material is already available or very easy to setup. The (unofficially?) proposed draft-perkins-bake-00.txt suggests a (weak but strong enough for the purpose) mechanism that involves a home agent during the key exchange. The validity of the MN's binding of the home address is verified by the CN by sending packets via the home network. The home agent address belongs to the same prefix as the MN's home address, i.e. PrefA:Prefsite::. If no SA is set up prior to the failure of ISPA, the key exchange will fail since the CN can't send packets through the home agent any more. => a SA set up prior to the failure of ISPA is the very easy case but can be common. Issues with the lack of home agent are different: - the CN should not flush the binding (i.e. a bit/sub-option/... is needed, its meaning should be "keep this binding as long as possible") - there is no support for mobile to mobile, in the multi-home environment this is translated by no support for failure on both the node and its CN ISPs or one has to assume that this condition is detectable. A common case is the failure of a high level ISP: if both nodes are connected to it they will see a failure at the same time, to understand this situation is hard but not impossible... I like this mechanism (of course :-) but we wait for the IPv6 mobility RFC before work again on it. BTW this is very easy to implement (movement detection is a dream). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 11:25:17 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20871 for ; Tue, 26 Jun 2001 11:25:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29719; Tue, 26 Jun 2001 08:23:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15522; Tue, 26 Jun 2001 08:00:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QExIdP008620 for ; Tue, 26 Jun 2001 07:59:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QExIC2008619 for mobile-ip-dist; Tue, 26 Jun 2001 07:59:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QExFdP008612 for ; Tue, 26 Jun 2001 07:59:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15219 for ; Tue, 26 Jun 2001 07:59:23 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18438 for ; Tue, 26 Jun 2001 09:00:14 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id ADEBD13D9; Tue, 26 Jun 2001 09:59:15 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4B07F122F for ; Tue, 26 Jun 2001 09:59:15 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 26 Jun 2001 10:59:14 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509A98@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] draft-ietf-mobileip-ipv6-13 comments Date: Tue, 26 Jun 2001 10:59:08 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, > > Section 5.6 ICMP Home Agent Address Discovery Request Message > > > > What does the mobile node specify in the home address field > > if it doesn't have a home address, like upon initialization? > > Should it use the unspecified address in this case? > > O.K. This sounds fine to me, but I expect that there may be > some networks where policy forbids the operation. Anyway, > whether or not the operation works should be controlled by > whether the mobile node can create a security association, > and not by whether the protocol specification says which > addresses to use. I hadn't thought that this field would be used for a policy table lookup. Interesting idea. I was simply looking for a consistent way to handle the problem of not knowing the home address at initialization to avoid possible interoperability questions later. I see no problem having it be an optional feature that can be disabled or rejected by local policy. > > Section 9.2 Dynamic Home Agent Address Discovery > > > >> - For each entry in this home agents ... > >> ... The selected global IP address for each home > >> agent to include in forming the Home Agent Addresses field in the > >> Reply message MUST be the global IP address of the respective > >> home agent sharing a prefix with the mobile node's home address > >> as indicated in the Home Address option in the Request message; > > > > During initialization, the mobile node may not have a home > > address when it performs home agent address discovery. Assuming > > the mobile node sent the unspecified address instead, what global > > IP addresses does the home agent select? Perhaps it could > > select IP addresses that share a prefix with the destination > > address from the Home Agent Address Discovery Request packet's > > IPv6 header instead. > > > > Same problem in the fourth rule for constructing the Home Agent > > Addresses Field: > > > >> ... The selected global IP address for each home > >> agent to include in forming the Home Agent Addresses field in the > >> Reply message MUST be the global IP address of the respective > >> home agent sharing a prefix with the mobile node's home address > >> as indicated in the Home Address option in the Request message; > > Done. I replaced: > "mobile node's home address as indicated in the Home > Address option in" > by > "Destination IP address of" > > However, I only found one instance of the problem; your first example > was, I think, the text in the fourth rule. Please let me > know if somehow I missed something. Oops, looking back at my notes, I see that I misread something. Changing the one place is OK. > > > > Section 9.5 Intercepting Packets for a Mobile Node > > > >> - The home agent examines the value of the Prefix Length field > >> in the new "home registration" Binding Cache entry. If this > >> value is zero, the following step is carried out only for the > >> individual home address specified for this binding. If, instead, > >> this field is nonzero, then the following step is carried out > >> for each address for the mobile node formed from the interface > >> identifier in the mobile node's home address in this binding > >> (the remaining low-order bits in the address after the indicated > >> subnet prefix), together with each one of the subnet prefixes > >> currently considered by the home agent to be on-link ... > > ============== > > The home agent should forward messages considered by other > > routers on the home network to be on-link as well. In other > > words, we think the home agent should use the aggregate list > > of home network prefixes for this. > > I don't know about this. It seems to me that the current wording > is correct. I don't know about why a home agent would try to > protect addresses that it considers to be off-link. I assumed the home agent should be capable of intercepting and forwarding any messages that the mobile node would accept if it were home (except link-local of course). I read "currently considered by the home agent to be on-link" to mean those prefixes defined in the home agent's own AdvPrefixList with the "L"ink bit set. If the mobile node were home, it would autoconfigure itself to prefixes advertised with the "A"utonomous bit set by any router on the home subnet, not just those advertised by the home agent. To avoid this kind of confusion, I think "currently considered by the home agent to be on-link" should be changed to "included in the Aggregate List of Home Network Prefixes (section 9.8.1) with the A bit set". > >> - For each specific IP address for the mobile node determined > >> in the first step above, the home agent multicasts onto the > >> home link (to the all-nodes multicast address) a Neighbor > >> Advertisement message [17] on behalf of the mobile node, to > >> advertise the home agent's own link-layer address for this IP > >> address. > >> > >> All fields in each such Neighbor Advertisement message SHOULD be > >> set in the same way they would be set by the mobile node itself > >> if sending this Neighbor Advertisement while at home [17], with > >> the following exceptions: > >> > >> * The Target Address in the Neighbor Advertisement message MUST > >> be set to the specific IP address for the mobile node. > > > > Does the home agent set the Neighbor Advertisement source IP > > address to its own link-local address as opposed to the > > mobile node's link-local address? > > I think the purpose is for the home agent to substitute its own > link-layer address for that of the mobile node. And, it needs to > do this for the mobile node's link-local IPv6 address also. Thus, > I wouldn't expect for the home agent to use its own link-local > address in that field. OK. > > >> While a node is serving as a home agent for some mobile node (it > >> still has a "home registration" entry for this mobile node in its > >> Binding Cache), the home agent uses IPv6 Neighbor Discovery [17] > >> to intercept unicast packets on the home link addressed the mobile > >> node's home address. In order to intercept packets in this way, > >> the home agent MUST act as a proxy for this mobile node to reply to > >> any received Neighbor Solicitation messages for it. When a home > >> agent receives a Neighbor Solicitation message, it MUST > check if the > >> Target Address specified in the message matches the home address > >> of any mobile node for which it has a Binding Cache entry marked > >> as a "home registration". This check MUST include all possible > >> home addresses for the mobile node, based on the subnet prefixes > >> currently considered to be on-link by the home agent ... > > ================= > > > > The home agent probably should use the aggregate list of prefixes > > for this as well? > > Maybe I'm missing something, but I think the "on-link" criterion > is appropriate here as well. Same reasoning as above. > > > Section 9.6 Tunneling Intercepted Packets to a Mobile Node > > > >> Tunneling of multicast packets to a mobile node follows similar > >> limitations to those defined above for unicast packets addressed to > >> the mobile node's link-local and site-local addresses. Multicast > >> packets addressed to a multicast address with link-local scope [9], > >> to which the mobile node is subscribed, MUST NOT be tunneled > >> to the mobile node; such packets SHOULD be silently discarded > >> (after delivering to other local multicast recipients). Multicast > >> packets addressed to a multicast address with scope larger > >> than link-local but smaller than global (e.g., site-local and > >> organization-local) [9], to which the mobile node is subscribed, > >> SHOULD be tunneled to the mobile node by default, but this behavior > >> MUST be configurable to disable it; this default behavior might > >> change at some point in the future as the definition of these > >> scopes become better defined in IPv6. > > > > This spec does not explain how a home agent determines what > > multicast addresses to forward to a mobile node. Host systems > > normally send Multicast Listener Discovery (MLD) messages to > > attached routers to join/leave multicast groups. The rules > > for doing this between mobile node and home agent are undefined. > > Not really...? Why can't the tunneled packets use the same rule > as in other cases. In other words, the mobile node should use > a Home Address destination option here, but that would be implicit. > It would be a mistake for the Mobile IPv6 specification to go specify > the inclusion of the Home Address option for _every_ possible > application between endpoints. Tunneling is not essentially > different here, as far as I can tell. The problem I have is that the term "tunnel" is extremely ambiguous. I can envision multiple ways to set up tunnels between a mobile node and its home agent. For example, I get the impression from your statement here that you were thinking of creating a bi-directional tunnel between the mobile node's home address and the home agent's address. I always assumed you were intending to create the tunnel using the mobile node's care-of address for the tunnel endpoint as is done in section 9.6. > > > The text above and in section 10.19 indicates a bi-directional > > tunnel could be used to support this. There is no clear > definition > > of how to set up such a tunnel. What addresses are used for > > tunnel source and destination? Would the tunnel have its own > > link local and global interface addresses? Will it carry MLD > > traffic specifically for the mobile node? What other traffic > > should such a tunnel between a mobile node and the home agent > > carry? > > I don't think there is a problem here. The tunnel should be set > up just like any tunnel would be set up. The outer header should > have the natural IP addresses. What are the tunnel endpoints? The home agent address is one, but do we use the mobile node's home address or care-of address for the other? > A home address destination option > would be used as normal. The inner header should have the same > field values as if the mobile node were on its home network. I agree with this part, and think it should be stated. > Policy determination for tunnel use is, I reckon, outside the scope > of the Mobile IPv6 specification. Otherwise, we would have to do > it for every protocol, not just MLD. That could be bad, and seems > like a major potential source for specification errors. I thought MLD was critical to supporting multicast traffic on a host in much the same way as Router Solicitation/ Advertisements are critical to unicast traffic support. Therefore, I think MLD is a special case that needs to be mentioned how it fits. It could be obvious depending on how the tunnel setup is defined. > > IMHO we should not try to solve the multicast tunneling > > issues now. Instead, descriptions of tunneling multicast > > traffic should be removed from the spec and left for future > > work. Perhaps the spec could say something like: > > > > + It may be possible to tunnel multicast traffic between > > + a mobile node and it's home agent to extend the range of > > + a multicast zone. The rules for setting up such tunnels and > > + for identifying which traffic to forward is beyond the scope > > + of this spec. > > As of now, I don't believe this is the right technical direction; > I have left the current specification as is. In that case, I think more detail will be needed in this section. I envision the mobile node and the home agent set up bi-directional tunnels per RFC 2473 between the mobile node's home address and the home agent's address to carry multicast traffic. The tunnel pseudo interfaces must have link local addresses to support MLD (RFC 2710) traffic between the home agent and the mobile node. Global addresses on the tunnel pseudo-interfaces are not necessary. This sounds like quite a bit of overhead in the home agent for a feature that may not be used often. Would it make sense to add a flag to the binding update request/response options to request support for such a tunnel? This might give home agents an option to save memory when the overhead is not needed. Section 9.7 mentions that the home agent MUST support decapsulating reverse tunneled packets. What is the tunnel source address in this case, the mobile node's care-of address or its home address? Will it use the same bi-directional configured tunnel that is used to support multicast traffic? > > Section 10.19 Routing Multicast Packets > > > > > Alternatively, a mobile node MAY join multicast groups via a > > > bi-directional tunnel to its home agent. The mobile > node tunnels its > > > multicast group membership control packets to its home > agent, and the > > > home agent forwards multicast packets down the tunnel to > the mobile > > > node. > > > > > > A mobile node that wishes to send packets to a multicast group > > > also has two options: (1) send directly on the foreign > link being > > > visited; or (2) send via a tunnel to its home agent. Because > > > multicast routing in general depends upon the Source > Address used in > > > the IPv6 header of the multicast packet, a mobile node > that tunnels a > > > multicast packet to its home agent MUST use its home > address as the > > > IPv6 Source Address of the inner multicast packet. > > > > Same concern with multicast messages as for section 9.6. We think > > this spec should describe option (1) and leave option > (2) as beyond > > scope for now. > > Well, I hope we can keep the specification. It's likely to work well > enough for Proposed Standard, and deployment and experience > are clearly > needed. I'm beginning to agree, just need to nail down what the tunnel endpoints are, and that the tunnel pseudo-interfaces must be configured with link-local addresses to carry MLD traffic. Also be clear that we are using bi-directional tunnels as defined in RFC 2473. > > > Section 10.20 Returning Home > > > >> ..... > >> In addition, when returning home prior to the expiration > of a current > >> binding for its home address, and configuring its home > address on its > >> network interface on its home link, the mobile node MUST > NOT perform > >> Duplicate Address Detection on its own home address, in order to > >> avoid confusion or conflict with its home agent's use of the same > >> address. ..... > > > > Could a mobile node perform DAD if it had knowledge of the home > > agent's link layer address? It could work as follows: > > > > 1) the mobile node runs DAD when it moves to any new > > physical link; > > 2) if this happens on the home link, the home agent will > > respond with a neighbor advertisement defending the mobile > > node's address; > > 3) the mobile node recognizes the home agent's link > > layer address in the neighbor solicit and thus > > determines it moved home; > > 4) the mobile node immediately sends a binding update > > to the home agent to delete the binding (no neighbor > > solicit needed); > > 5) the home agent responds with a binding ack to > > signal that the binding is deleted and the home > > agent is no longer defending the mobile node's > > home address; > > 6) The mobile node runs DAD again; > > 7) Communication proceeds as normal. > > I don't see anything wrong with this, but on the other hand I am > reluctant to put it into the revised protocol specification without > some additional working group discussion. I understand. This is one mechanism that would be extremely easy to add later, so I have no problem leaving the spec as is for now. Perhaps I should start a separate discussion on this point? > > > 11. Protocol Constants > > > >> HomeRtrAdvInterval 1,000 seconds > > > > This is the maximum interval between periodic router > > advertisements from the home agent to the mobile node. > > Given that advertisements are acknowledged and the > > periodic advertisements are primarily a fail-safe > > feature, would it be reasonable to increase this to > > something like 36000 seconds (1 hour) to further > > overhead? > > I guess you meant 3600 seconds. So, I made that change. Yes. Got carried away with those zeros. Thanks Ken From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 11:45:44 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22944 for ; Tue, 26 Jun 2001 11:45:42 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10959; Tue, 26 Jun 2001 09:45:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12607; Tue, 26 Jun 2001 08:45:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QFhfdP008791 for ; Tue, 26 Jun 2001 08:43:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QFhfCX008790 for mobile-ip-dist; Tue, 26 Jun 2001 08:43:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QFhbdP008783 for ; Tue, 26 Jun 2001 08:43:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12173 for ; Tue, 26 Jun 2001 08:43:46 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13316 for ; Tue, 26 Jun 2001 08:43:45 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id AAB341EC7; Tue, 26 Jun 2001 10:43:44 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 6D0C71204 for ; Tue, 26 Jun 2001 10:43:44 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 26 Jun 2001 11:43:43 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509ADE@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'Charlie Perkins'" , "T.J. Kniveton" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Prefix Advertisements Date: Tue, 26 Jun 2001 11:43:40 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think we have a serious issue here. > > > > >9.8.1. Building Aggregate List of Home Network Prefixes > > > > > > > > > > To support this, the home agent monitors prefixes > > > > > advertised on > > > > > the home link by itself and other home agents, and > > > > > passes the ... > > > > ===================== > > > > > > > > Why limit this to prefixes from other home agents > > > > only? Why not use prefixes from any router? > > > > > > I don't think that was the intention. > > > > Actually it was my intention, so please correct me here > > because this is important. In the general case, I do not > > see how a MN can use a prefix > > being advertised on its home link, unless a home agent is willing to > > "serve" that prefix by accepting registrations for addresses on the > > prefix, and thus forwarding packets to the MN while it is roaming. > > > > So, are you suggesting that a home agent would want to serve mobile > > nodes that do not use a home address on a prefix that the HA is > > advertising? > > No, my wording was bad. I was trying to say that the intention was > _not_ to use addresses from routers that are not home agents, > but since I was in a hurry I didn't put enough text around it to > be clear. I disagree. When a mobile node is home, it will autoconfigure to all prefixes advertised by any router. When the mobile node moves off-link, the home agent will need to intercept all traffic for the mobile node, otherwise you will get dropped connections. The reason for creating the aggregate list was to handle this problem. While playing in the lab, I discovered I could set up a home agent that doesn't set the A or L bits on any prefixes. The mobile node autoconfigures to another router on the home net. I realized this could be a very handy feature, particularly in cases where the network administrator doesn't want the home agent to effect addresses configured on the non-mobile nodes. Ken From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 12:22:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24710 for ; Tue, 26 Jun 2001 12:22:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16425; Tue, 26 Jun 2001 10:22:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18289; Tue, 26 Jun 2001 09:21:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGKvdP009000 for ; Tue, 26 Jun 2001 09:20:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGKurf008999 for mobile-ip-dist; Tue, 26 Jun 2001 09:20:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGKrdP008992 for ; Tue, 26 Jun 2001 09:20:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18099 for ; Tue, 26 Jun 2001 09:21:02 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08734 for ; Tue, 26 Jun 2001 09:20:58 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 8DBBB116E; Tue, 26 Jun 2001 11:20:57 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4D6DE1281 for ; Tue, 26 Jun 2001 11:20:57 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 26 Jun 2001 12:20:56 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509ADD@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'T.J. Kniveton'" , "Charles E. Perkins" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Prefix Advertisements Date: Tue, 26 Jun 2001 12:20:34 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi TJ, Charlie > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Monday, June 25, 2001 5:18 PM > To: Charles E. Perkins > Cc: Powell, Ken; mobile-ip@sunroof.eng.sun.com; 'T.J. Kniveton' > Subject: Re: [mobile-ip] Mobile Prefix Advertisements > > > Thanks for the message Charlie. I agree with all your comments, and > would like to add the following: > > "Charles E. Perkins" wrote: > > > > Destination Address > > > > If a Mobile Prefix Solicitation was sent, the Source > > > > Address field from that packet. > > > > > > If the Mobile Prefix Solicitation contained a home address > > > option, should the should this Destination Address be set > > > to the mobile node's home address? > > This level of indirection is unnecessary, and will only work > sometimes; > specifically, we can't rely on a home address option, and using the > option when it is there is OK, but not necessary. We don't need to > preserve a MN's Home Address in an advertisement -- the MN should be > ready to receive a MPA at the same address it sent the MPS from, > specifically the COA. > > Of course I might be wrong, so let me know if there is a better way to > support both of these cases. > > > Wouldn't the packet be sent with a routing header? If so, > > then this should follow normal rules for sending packets. > > A mobile prefix solicitation will sometimes be sent from a mobile node > that is trying to construct a home address; thus, you can't rely on an > home address option. I agree. > > > 9.8.1. Building Aggregate List of Home Network Prefixes > > > I noticed you added an interesting optimization of filtering > > > out any prefixes not used for autoconfiguration. This seems > > > like a reasonable thing to do. The mobile node ignores this > > > info when off link, and will rediscover all it needs soon > > > after moving home. Should this same filter be used to restrict > > > which prefixes from the home agent's AdvPrefixList are copied > > > to the aggregate list? > > In a sense, that was what I was attempting to do above. I was thinking > that the more complexity that can be cut out of constructing, sending, > and receiving/processing the list, the better. But of course > this is not > supposed to be at the expense of doing things the wrong way, so please > share your alternate thoughts about how to do it. > OK, I was thinking something like changing x - Copy prefix information defined in the home agent's AdvPrefixList x on the home subnet's interfaces to the aggregate list. Also x apply any changes made to the AdvPrefixList on the home agent to x the aggregate list. to + - For each home subnet interface on the home agent, copy any prefix + information defined in the home agent's AdvPrefixList with the "A" + bit set to the aggregate list. Also apply any changes to made to + the AdvPrefixList on the home agent to the aggregate list. Ken From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 12:23:41 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24826 for ; Tue, 26 Jun 2001 12:23:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAB14532; Tue, 26 Jun 2001 10:20:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17928; Tue, 26 Jun 2001 09:20:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGItdP008966 for ; Tue, 26 Jun 2001 09:18:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGItde008965 for mobile-ip-dist; Tue, 26 Jun 2001 09:18:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGIpdP008958 for ; Tue, 26 Jun 2001 09:18:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23186 for ; Tue, 26 Jun 2001 09:19:00 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14537 for ; Tue, 26 Jun 2001 10:19:44 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA18183; Tue, 26 Jun 2001 09:18:47 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5QGIkS29944; Tue, 26 Jun 2001 09:18:46 -0700 X-mProtect: Tue, 26 Jun 2001 09:18:46 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdh5imri; Tue, 26 Jun 2001 09:18:45 PDT Message-ID: <3B38B5E5.79EA830E@Kniveton.com> Date: Tue, 26 Jun 2001 09:18:45 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" , "Perkins Charles (IPRG/MtView)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D69509ADE@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Powell, Ken" wrote: > > I think we have a serious issue here. > > > > > > >9.8.1. Building Aggregate List of Home Network Prefixes > > > > > > > > > > > > To support this, the home agent monitors prefixes > > > > > > advertised on > > > > > > the home link by itself and other home agents, and > > > > > > passes the ... > > > > > ===================== > > > > > > > > > > Why limit this to prefixes from other home agents > > > > > only? Why not use prefixes from any router? > > > > > > > > I don't think that was the intention. > > > > > > Actually it was my intention, so please correct me here > > > because this is important. In the general case, I do not > > > see how a MN can use a prefix > > > being advertised on its home link, unless a home agent is willing to > > > "serve" that prefix by accepting registrations for addresses on the > > > prefix, and thus forwarding packets to the MN while it is roaming. > > > > > > So, are you suggesting that a home agent would want to serve mobile > > > nodes that do not use a home address on a prefix that the HA is > > > advertising? > > > > No, my wording was bad. I was trying to say that the intention was > > _not_ to use addresses from routers that are not home agents, > > but since I was in a hurry I didn't put enough text around it to > > be clear. > > I disagree. When a mobile node is home, it will autoconfigure > to all prefixes advertised by any router. When the mobile node > moves off-link, the home agent will need to intercept all > traffic for the mobile node, otherwise you will get dropped > connections. The reason for creating the aggregate list > was to handle this problem. > > While playing in the lab, I discovered I could set up a home > agent that doesn't set the A or L bits on any prefixes. The > mobile node autoconfigures to another router on the home net. > I realized this could be a very handy feature, particularly > in cases where the network administrator doesn't want the > home agent to effect addresses configured on the non-mobile > nodes. Well first of all, if the home agent is willing to serve home addresses that are on prefixes it doesn't advertise (which it probably would be), then there is no issue with a mobile node leaving the home network - that will work fine regardless of what's in the MPA. As far as a mobile renewing an address, or configuring a new one, based on the MPA: while I'm not sure I agree 100%, I certainly see your point and it is valid: it would be very nice for a network administrator to be able to drop in an HA without having to reconfigure anything else. It doesn't seem great to require every HA to advertise all of the prefixes on its link to all MNs (and my intention was to pare the aggregate list by removing unnecessary prefixes). Perhaps we could reach a compromise of a router rule under "should": add received prefixes that have the A bit set to the aggregate list. I would also suggest that the rule should specify that the prefixes should be added only if they do *not* have the L bit set. To me, it seems problematic for a mobile node to be autoconfiguring home-network link-local addresses while roaming. How do you feel about that? As far as the rule that the mobile should be able to autoconfigure at least all of the prefixes (which are served by HAs) that it would on the home network, I think that still holds: the prefix still needs to be served by the HA for it to be relevant while roaming, even if the prefix is not explicitly advertised by the HA on the home link. -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 12:35:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25373 for ; Tue, 26 Jun 2001 12:35:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28107; Tue, 26 Jun 2001 10:33:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21299; Tue, 26 Jun 2001 09:33:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGVpdP009120 for ; Tue, 26 Jun 2001 09:31:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGVpGB009119 for mobile-ip-dist; Tue, 26 Jun 2001 09:31:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGVldP009112 for ; Tue, 26 Jun 2001 09:31:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03148 for ; Tue, 26 Jun 2001 09:31:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22567 for ; Tue, 26 Jun 2001 10:32:47 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA19334; Tue, 26 Jun 2001 09:31:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5QGVju22290; Tue, 26 Jun 2001 09:31:45 -0700 X-mProtect: Tue, 26 Jun 2001 09:31:45 -0700 Nokia Silicon Valley Messaging Protection Received: from tkniveto.iprg.nokia.com (205.226.2.111, claiming to be "Kniveton.com") by darkstar.iprg.nokia.com(P1.5 smtpdZcKCLI; Tue, 26 Jun 2001 09:31:44 PDT Message-ID: <3B38B8F0.5A1DEC4A@Kniveton.com> Date: Tue, 26 Jun 2001 09:31:44 -0700 From: "T.J. Kniveton" Organization: NOKIA Research X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" CC: "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D69509ADD@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Powell, Ken" wrote: > > > > 9.8.1. Building Aggregate List of Home Network Prefixes > > > > I noticed you added an interesting optimization of filtering > > > > out any prefixes not used for autoconfiguration. This seems > > > > like a reasonable thing to do. The mobile node ignores this > > > > info when off link, and will rediscover all it needs soon > > > > after moving home. Should this same filter be used to restrict > > > > which prefixes from the home agent's AdvPrefixList are copied > > > > to the aggregate list? > > > > In a sense, that was what I was attempting to do above. I was thinking > > that the more complexity that can be cut out of constructing, sending, > > and receiving/processing the list, the better. But of course > > this is not > > supposed to be at the expense of doing things the wrong way, so please > > share your alternate thoughts about how to do it. > > > > OK, I was thinking something like changing > > x - Copy prefix information defined in the home agent's AdvPrefixList > x on the home subnet's interfaces to the aggregate list. Also > x apply any changes made to the AdvPrefixList on the home agent to > x the aggregate list. > > to > > + - For each home subnet interface on the home agent, copy any prefix I'm not sure that a given home agent would want to use prefix info from all of its interfaces. > + information defined in the home agent's AdvPrefixList with the "A" > + bit set to the aggregate list. Also apply any changes to made to > + the AdvPrefixList on the home agent to the aggregate list. This may be below our radar when considering the 'general' case. In essence, this rule would be restricting the MPAs to advertising only auto-configurable addresses, which would close the gap for the minority of admins who may want to use stateful configuration or something else. To me, this is an acceptable change, and I agree with your idea, but I think we should have someone else sanity check this. -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 12:45:02 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25886 for ; Tue, 26 Jun 2001 12:45:02 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13151; Tue, 26 Jun 2001 08:50:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13689; Tue, 26 Jun 2001 08:49:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QFmedP008840 for ; Tue, 26 Jun 2001 08:48:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QFmeIP008839 for mobile-ip-dist; Tue, 26 Jun 2001 08:48:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QFmadP008832 for ; Tue, 26 Jun 2001 08:48:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16917 for ; Tue, 26 Jun 2001 08:48:45 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25497 for ; Tue, 26 Jun 2001 09:49:37 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id DB02E1053; Tue, 26 Jun 2001 10:48:39 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id A6C631348 for ; Tue, 26 Jun 2001 10:48:39 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 26 Jun 2001 11:48:39 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509ADC@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'Charles E. Perkins'" Cc: mobile-ip@sunroof.eng.sun.com, "'T.J. Kniveton'" Subject: RE: [mobile-ip] Mobile Prefix Advertisements Date: Tue, 26 Jun 2001 11:48:32 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, T.J., > > Section 5.8 ICMP Mobile Prefix Solicitation Message Format > > > > Will the Destination Option extension header with a > > Home Address option normally be included? The exception > > would be during mobile node initialization when the > > mobile node does not have a home address yet. > > Agreed. I reckon this should just follow normal rules > for sending packets. Does it need to be stated explicitly? I think it needs to be stated somewhere in the spec. Not sure where it makes most sense though. > > > > This message header should include a reserved > > field to align the remaining prefix options on > > a 64-bit boundary. > > Here I am not so sure. The Prefix Information option > doesn't start with a 64-bit field, and I didn't find > any specification that required an _option_ to be > aligned in a certain way -- only that the data fields > in the option should be aligned in a certain way. > I can see both sides of the argument, and the picture > at the beginning of section 4.6 of RFC 2461 doesn't > appear to mandate the restriction. There is no explicitly stated restriction, but I think all the headers are constructed such that long fields like IPv6 addresses land on proper byte-boundaries. IMHO, its important we try to maintain this alignment convention. Ken From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 12:51:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26247 for ; Tue, 26 Jun 2001 12:51:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16080; Tue, 26 Jun 2001 10:51:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25990; Tue, 26 Jun 2001 09:51:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGntdP009282 for ; Tue, 26 Jun 2001 09:49:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGnsCD009281 for mobile-ip-dist; Tue, 26 Jun 2001 09:49:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGnpdP009274 for ; Tue, 26 Jun 2001 09:49:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00493 for ; Tue, 26 Jun 2001 09:50:00 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03445 for ; Tue, 26 Jun 2001 10:50:47 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 09C12124F; Tue, 26 Jun 2001 11:49:35 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id CA6A11135 for ; Tue, 26 Jun 2001 11:49:34 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 26 Jun 2001 12:49:34 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69067DC1@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'T.J. Kniveton'" Cc: "Charles E. Perkins" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Prefix Advertisements Date: Tue, 26 Jun 2001 12:49:30 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Tuesday, June 26, 2001 12:32 PM > To: Powell, Ken > Cc: Charles E. Perkins; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Mobile Prefix Advertisements > > > "Powell, Ken" wrote: > > > > > 9.8.1. Building Aggregate List of Home Network Prefixes > > > > > I noticed you added an interesting optimization of > filtering > > > > > out any prefixes not used for autoconfiguration. This seems > > > > > like a reasonable thing to do. The mobile node ignores this > > > > > info when off link, and will rediscover all it needs soon > > > > > after moving home. Should this same filter be used > to restrict > > > > > which prefixes from the home agent's AdvPrefixList > are copied > > > > > to the aggregate list? > > > > > > In a sense, that was what I was attempting to do above. I > was thinking > > > that the more complexity that can be cut out of > constructing, sending, > > > and receiving/processing the list, the better. But of course > > > this is not > > > supposed to be at the expense of doing things the wrong > way, so please > > > share your alternate thoughts about how to do it. > > > > > > > OK, I was thinking something like changing > > > > x - Copy prefix information defined in the home agent's > AdvPrefixList > > x on the home subnet's interfaces to the aggregate list. Also > > x apply any changes made to the AdvPrefixList on the > home agent to > > x the aggregate list. > > > > to > > > > + - For each home subnet interface on the home agent, copy > any prefix > > I'm not sure that a given home agent would want to use prefix > info from > all of its interfaces. > > > + information defined in the home agent's AdvPrefixList > with the "A" > > + bit set to the aggregate list. Also apply any changes > to made to > > + the AdvPrefixList on the home agent to the aggregate list. > > This may be below our radar when considering the 'general' case. In > essence, this rule would be restricting the MPAs to advertising only > auto-configurable addresses, which would close the gap for > the minority > of admins who may want to use stateful configuration or > something else. > To me, this is an acceptable change, and I agree with your idea, but I > think we should have someone else sanity check this. Good thinking. Just realized we also want to include all prefixes with the "R" bit set. > > > -- > T.J. Kniveton > Communications Systems Lab > Nokia Research Center > From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 13:19:00 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27601 for ; Tue, 26 Jun 2001 13:19:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26766; Tue, 26 Jun 2001 10:19:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07905; Tue, 26 Jun 2001 10:18:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHGmdP009441 for ; Tue, 26 Jun 2001 10:16:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QHGm9d009440 for mobile-ip-dist; Tue, 26 Jun 2001 10:16:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHGidP009433 for ; Tue, 26 Jun 2001 10:16:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07527 for ; Tue, 26 Jun 2001 10:16:54 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19112 for ; Tue, 26 Jun 2001 11:17:34 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 482CC1230; Tue, 26 Jun 2001 12:13:45 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 07C5E12CD for ; Tue, 26 Jun 2001 12:13:44 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Tue, 26 Jun 2001 13:13:44 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509AE8@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'T.J. Kniveton'" , "Perkins Charles (IPRG/MtView)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Mobile Prefix Advertisements Date: Tue, 26 Jun 2001 13:13:42 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Tuesday, June 26, 2001 12:19 PM > To: Powell, Ken; Perkins Charles (IPRG/MtView) > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Mobile Prefix Advertisements > > > "Powell, Ken" wrote: > > > > I think we have a serious issue here. > > > > > > > > >9.8.1. Building Aggregate List of Home Network Prefixes > > > > > > > > > > > > > > To support this, the home agent monitors prefixes > > > > > > > advertised on > > > > > > > the home link by itself and other home agents, and > > > > > > > passes the ... > > > > > > ===================== > > > > > > > > > > > > Why limit this to prefixes from other home agents > > > > > > only? Why not use prefixes from any router? > > > > > > > > > > I don't think that was the intention. > > > > > > > > Actually it was my intention, so please correct me here > > > > because this is important. In the general case, I do not > > > > see how a MN can use a prefix > > > > being advertised on its home link, unless a home agent > is willing to > > > > "serve" that prefix by accepting registrations for > addresses on the > > > > prefix, and thus forwarding packets to the MN while it > is roaming. > > > > > > > > So, are you suggesting that a home agent would want to > serve mobile > > > > nodes that do not use a home address on a prefix that the HA is > > > > advertising? > > > > > > No, my wording was bad. I was trying to say that the > intention was > > > _not_ to use addresses from routers that are not home agents, > > > but since I was in a hurry I didn't put enough text around it to > > > be clear. > > > > I disagree. When a mobile node is home, it will autoconfigure > > to all prefixes advertised by any router. When the mobile node > > moves off-link, the home agent will need to intercept all > > traffic for the mobile node, otherwise you will get dropped > > connections. The reason for creating the aggregate list > > was to handle this problem. BTW, the statement above is the part that is critical we fix and handle consistently. The rest was personal preference. > > > > While playing in the lab, I discovered I could set up a home > > agent that doesn't set the A or L bits on any prefixes. The > > mobile node autoconfigures to another router on the home net. > > I realized this could be a very handy feature, particularly > > in cases where the network administrator doesn't want the > > home agent to effect addresses configured on the non-mobile > > nodes. > > Well first of all, if the home agent is willing to serve home > addresses > that are on prefixes it doesn't advertise (which it probably > would be), > then there is no issue with a mobile node leaving the home network - > that will work fine regardless of what's in the MPA. Agreed. I believe its mandatory the home agent be able to serve addresses it doesn't advertise, particularly for cases like DHCP served addresses. In most such cases, I would expect the mobile node to issue binding updates with a zero prefix length. > > As far as a mobile renewing an address, or configuring a new > one, based > on the MPA: while I'm not sure I agree 100%, I certainly see > your point > and it is valid: it would be very nice for a network > administrator to be > able to drop in an HA without having to reconfigure anything else. Normally I would expect the home agent and other routers to advertise the same set of prefixes, so dropping the home agent is no big deal. I was more interested in the possibility that a network administrator might want to avoid routing disruptions caused by possibly misconfigured home agents. > It doesn't seem great to require every HA to advertise all of the > prefixes on its link to all MNs (and my intention was to pare the > aggregate list by removing unnecessary prefixes). Perhaps we > could reach > a compromise of a router rule under "should": add received > prefixes that > have the A bit set to the aggregate list. I would also > suggest that the > rule should specify that the prefixes should be added only if they do > *not* have the L bit set. I don't think it matters what the L bit is set to. All the L bit does is indicate to a host that it should treat the a prefix as On-Link when sending messages. When a destination of any scope is on-link, the host will use Neighbor Discovery to find the destination instead of sending the message to router. > To me, it seems problematic for a > mobile node > to be autoconfiguring home-network link-local addresses while roaming. > How do you feel about that? Agreed. But that is not what the L bit is used for. > > As far as the rule that the mobile should be able to autoconfigure at > least all of the prefixes (which are served by HAs) that it > would on the > home network, I think that still holds: the prefix still needs to be > served by the HA for it to be relevant while roaming, even if > the prefix > is not explicitly advertised by the HA on the home link. I think this is the key point. The way I see it, the mobile node can autoconfigure a set of home network addresses while at home or while roaming. These sets of addresses must match exactly to each other and to the addresses that the home agent can serve. I define "serve" to mean the set of addresses that a home agent can intercept and forward to the mobile node. Another way we could compromise is to introduce a concept of home prefixes vs other prefixes on the home network. Home prefixes could be prefixes advertised by home agents. Other prefixes are prefixes not advertised by home agents. A mobile node could autoconfigure to any prefix while on the home subnet, but would "Prefer" to use home prefixes only. The other prefixes would be expected to come and go the same way care-of addresses do now. Ken From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 13:34:33 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28929 for ; Tue, 26 Jun 2001 13:34:33 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01061; Tue, 26 Jun 2001 10:28:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09901; Tue, 26 Jun 2001 10:26:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHPIdP009518 for ; Tue, 26 Jun 2001 10:25:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QHPIFA009517 for mobile-ip-dist; Tue, 26 Jun 2001 10:25:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHPEdP009510 for ; Tue, 26 Jun 2001 10:25:15 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5QHPFG211447 for ; Tue, 26 Jun 2001 10:25:15 -0700 (PDT) Message-Id: <200106261725.f5QHPFG211447@jurassic.eng.sun.com> Date: Tue, 26 Jun 2001 10:25:23 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] A question on fast handoffs for MIPv6 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fo6vEfsu6j9MC8kGWV1DtA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Satish, > All, > In the fast handoff draft for IPv6, It is mentioned that in the mobile > initiated handoff (Consider an inter technology handoff scenario) a router > solicitation for proxy with some access network information is sent by the > mobile (I assume that the access network is the new access network to which > the mobile plans to handoff).In the inter-technology case handoffs will be > mostly mobile initiated - so this information will be hard to come by for a > mobile. Why do you say that? Mobile should be able to establish new link through its other interface and get this access network information (link layer address of new attachment point). > > Can any one direct me to what kind of access network information is sent - > are there any specs that are comming up to define this information. > I'm not aware of any. alper > > Satish Jamadagni > Sasken Communication technologies Ltd, > The Soft-Radio project > Bangalore - 560 008 > > > alper From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 13:42:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00386 for ; Tue, 26 Jun 2001 13:42:34 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05829; Tue, 26 Jun 2001 10:39:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18354; Tue, 26 Jun 2001 10:36:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHZVdP009597 for ; Tue, 26 Jun 2001 10:35:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QHZU4b009596 for mobile-ip-dist; Tue, 26 Jun 2001 10:35:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHZQdP009586 for ; Tue, 26 Jun 2001 10:35:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07036 for ; Tue, 26 Jun 2001 10:35:36 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04701 for ; Tue, 26 Jun 2001 11:36:17 -0600 (MDT) Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Tue, 26 Jun 2001 18:39:08 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 16:02:05 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Tue, 26 Jun 2001 16:02:05 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15EuLt-00079u-00; Tue, 26 Jun 2001 16:02:05 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA19873 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 09:55:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18631 for ; Tue, 26 Jun 2001 07:02:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27339; Tue, 26 Jun 2001 07:02:56 -0400 (EDT) Message-Id: <200106261102.HAA27339@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-subbarao-mobileip-redundancy-00.txt Date: Tue, 26 Jun 2001 07:02:55 -0400 X-OriginalArrivalTime: 26 Jun 2001 17:39:08.0992 (UTC) FILETIME=[E7786400:01C0FE66] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Home Agent Redundancy in Mobile IP Author(s) : K. Leung, M. Subbarao Filename : draft-subbarao-mobileip-redundancy-00.txt Pages : Date : 11-Jun-01 In Mobile IP, a Home Agent (HA) creates a mobility binding table that tracks the association of a Mobile Node's (MN) home address with its current Care-of Address (CoA). If the HA fails, the mobility binding table will be lost and all MNs registered with the HA will lose connectivity. In this draft, we propose a Mobile IP Home Agent Redundancy framework mechanism that provides the essential robust redundancy needed at the HA. The mechanism described herein can also be used to provide the redundancy needed at any 'regional/local' HAs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-subbarao-mobileip-redundancy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-subbarao-mobileip-redundancy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-subbarao-mobileip-redundancy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010625110710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-subbarao-mobileip-redundancy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-subbarao-mobileip-redundancy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Tue Jun 26 15:49:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08127 for ; Tue, 26 Jun 2001 15:49:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01442; Tue, 26 Jun 2001 13:49:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13788; Tue, 26 Jun 2001 12:49:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QJlQdP010361 for ; Tue, 26 Jun 2001 12:47:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QJlQW1010360 for mobile-ip-dist; Tue, 26 Jun 2001 12:47:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QJlMdP010353 for ; Tue, 26 Jun 2001 12:47:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07879 for ; Tue, 26 Jun 2001 12:47:31 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29769 for ; Tue, 26 Jun 2001 13:47:28 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5QJl9O24906; Tue, 26 Jun 2001 21:47:09 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id VAA27447; Tue, 26 Jun 2001 21:47:08 +0200 Message-ID: <3B38DE74.DF98D2D7@era.ericsson.se> Date: Tue, 26 Jun 2001 21:11:48 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: "Powell, Ken" , "'T.J. Kniveton'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) References: <88BD5A70CA8BFA4CA15D0ED053E49D69067D70@tayexc14.americas.cpqcorp.net> <3B37FC9D.B5793A32@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, Charlie Perkins wrote: > > > 5.8 Mobile Prefix Solicitation Message Format > > > > My comments to section 9.8.2 below request that only the prefixes > > that match a particular home registration be sent to the mobile > > node in Mobile Prefix Advertisements. If the binding has a zero > > prefix length, only the specific prefix for the mobile node's > > home address would be sent. For a bindings with a non-zero prefix > > length, all prefixes in the aggregate list would be sent. > > I'm going to go out on a limb here, and suggest that the existing semantics > for the Prefix Length option need substantial change. I might be missing > something, but having a nonzero prefix length seems to only have the effect > of requesting that the home agent should provide service for more home > addresses. The addresses served by the home are determined by the > collection of on-link prefixes, not the actual value of the Prefix Length > field. Thus, this purpose could be managed by a single bit. Yes, get rid of the Prefix Length option. Sounds good. I really would like to hear people's opinion on if we should keep the possibility of registering all possible home addresses with one single BU using a non-zero prefix length. Especially mixing non-zero and zero prefix lengths seems like a mess. Either, we need a very strict specification on how to use the two formats, or we'd get rid of the case "prefix length != 0". I know it is there to save bandwidth on a scare-bandwidth wireless link MN is attached to and to minimize messaging, but the complexity on HA and MN side due to this increases. Still, we can't use non-zero prefix length towards the CN. I also see cases where the MN and HA have different opinions on what home addresses are registered due to MPA/MPS/BU/BA messaging mismatch. This thread has already explained difficulties on this. > > That would allow us to use the Prefix Length field for something more > important -- namely to serve the same function as the proposed > "Mobile Router Prefix Length Sub-Option", which I wrote about > earlier and put into the existing intermediate (unfinished) draft which > I am trying to finish now. Then we could get rid of that Sub-Option > and have a more natural specification. > Is this draft the Mobile IPv6 draft or another one? Does this have anything to do with the mobile networks draft by INRIA and Motorola? Is the idea to send one BU for the registration of the MR itself (prefix length 128) and a second BU for the registration of the network behind the MR (prefix length e.g. 64)? I brought up the issues with this earlier. Do we have a solution for running some kind of routing protocols between the MR and the home subnet, in order to update routers and HAs on the home subnet of the existance of the mobile network behind the MR? In all cases I know of the routing protocols use link-local addresses in messaging. Link-local addresses are not handled by Mobile IPv6 and are not tunnelled between HA and MN. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 27 00:27:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18256 for ; Wed, 27 Jun 2001 00:27:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA17709; Tue, 26 Jun 2001 21:27:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04030; Tue, 26 Jun 2001 21:27:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4QGdP011028 for ; Tue, 26 Jun 2001 21:26:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4QFaF011027 for mobile-ip-dist; Tue, 26 Jun 2001 21:26:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4QCdP011020 for ; Tue, 26 Jun 2001 21:26:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03935 for ; Tue, 26 Jun 2001 21:26:22 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13156 for ; Tue, 26 Jun 2001 22:27:14 -0600 (MDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id NAA29855 for ; Wed, 27 Jun 2001 13:28:42 +0900 (KST) Message-ID: <010f01c0fec1$6687e860$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: Subject: [mobile-ip] Mobile IPv4 Authentication Internt Draft Date: Wed, 27 Jun 2001 13:26:55 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_010B_01C0FF0C.D5D88080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_010B_01C0FF0C.D5D88080 Content-Type: multipart/alternative; boundary="----=_NextPart_001_010C_01C0FF0C.D5E1A840" ------=_NextPart_001_010C_01C0FF0C.D5E1A840 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpXZSByZWNlbnRseSBzdWJtaXR0ZWQgYSBkcmFmdCBvbiAiTUlQdjQgQXV0aGVu dGljYXRpb24gU2hhcmVkIFNlY3JldCBHZW5lcmF0aW9uIChkcmFmdC1zb25nLW1vYmlsZWlwLW1p cHY0LWF1dGgtc2VjZ2VuZXJhdGlvbi0wMC50eHQpICANCg0KDQpSZWdhcmRzLA0KSkggU09ORw0K DQo= ------=_NextPart_001_010C_01C0FF0C.D5E1A840 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIEFsbCw8 QlI+PEJSPldlIHJlY2VudGx5IHN1Ym1pdHRlZCBhIGRyYWZ0IG9uICJNSVB2NCANCkF1dGhlbnRp Y2F0aW9uIFNoYXJlZCBTZWNyZXQgR2VuZXJhdGlvbiANCihkcmFmdC1zb25nLW1vYmlsZWlwLW1p cHY0LWF1dGgtc2VjZ2VuZXJhdGlvbi0wMC50eHQpJm5ic3A7IDxCUj48Rk9OVCANCnNpemU9Mz48 L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PEZPTlQgc2l6ZT0zPjxGT05U IA0Kc2l6ZT0yPjwvRk9OVD48QlI+PC9GT05UPlJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTI+SkggU09ORzxCUj48L0RJVj48L0ZPTlQ+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_001_010C_01C0FF0C.D5E1A840-- ------=_NextPart_000_010B_01C0FF0C.D5D88080 Content-Type: text/plain; name="draft-song-mobileip-mipv4-auth-secgeneration-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-song-mobileip-mipv4-auth-secgeneration-00.txt" Content-Transfer-Encoding: quoted-printable JunHyuk Song INTERNET DRAFT ChaeYong Chong 29 June 2001 Samsung Elec. Dongkie Leigh SK telecom Raymond Hsu Qualcomm Inc. =20 Mobile IPv4 Authentication Shared key Generation draft-song-mobile-ipv4-auth-secgeneration-00.txt Status of This Memo Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract Mobile Node and Home Agent servers used in nowadays can provide authentication and authorization services mostly by the MN-HA and=20 MN-AAA Authentication. However, this kind of Security Association is = only possible if Mobile Node previously share the same shared secrets = with Home Agent and AAA. Based on the assumption that the SA between=20 Mobile Node and Home AAA is strong, it is possible to use that=20 security association to dynamically update MN-AAA Authentication=20 shared secret and create security associations between the Mobile =20 Node and foreign agent and its home agent. This document specifies=20 the method to dynamically update the shared secret used for MN-AAA=20 extension and create shared secret used for MN-HA extension among=20 Mobile Node, Foreign Agent and Home Agent, based on MN-AAA shared=20 secret, NAI, Foreign Agent IP address and Foreign Agent Challenge. Song et al. Expires 29 December 2001 [Page 1] =0C Internet Draft Mobile IP MN-HA Authentication 29 June 2000 Contents Status of This Memo 1 Abstract 1 1. Introduction.......................................................3 2. The parameters used for Dynamic MN-HA shared secret generation ....3 2.1 Mobile IP Agent Advertisement Challenge Extension.............3 =20 2.2 Network Access Identifier (NAI)...............................4 =20 2.3 MN-AAA shared secret..........................................4 =20 3. MN-AAA shared secret update........................................4 =20 3.1 MN-AAA key update by Mobile Node..............................4 =20 3.2 MN-AAA key update by AAA......................................5 =20 4. MN-HA shared secret creation.......................................5 =20 4.1 MN-HA key creation by Mobile Node.............................5 =20 4.2 MN-HA shared key creation by AAA..............................5 =20 5 Operation description...............................................6 =20 6 Security Considerations.............................................6 =20 Appendix A - 3G Wireless example......................................7 =20 Appendix B - MN-FA shared key consideration...........................8 =20 References............................................................8 =20 Addresses.............................................................9 =20 =20 Song et al. Expires 29 December 2001 [Page 2] =0C 1. Introduction In Mobile IP, AAA servers is in use nowadays to identify and=20 authenticate the mobile node by the Network Access Identifier (NAI)=20 [1] and MN-AAA authenticator [3]. Besides the mobile node is = required to have a security association with its home agent [2]. Mobile IP=20 defines an MN-HA authentication extension by which a mobile node can=20 authenticate itself to a home agent. However it is not currently=20 defined how Mobile Node, Home Agent and AAA obtain and update the=20 shared secret used in computing MN-AAA and MN-HA authenticator.=20 Based on the assumption that the SA between Mobile Node and Home AAA=20 is strong, it is possible to use that security association to create=20 security associations between the Mobile Node and its Home Agent. =20 This document specifies the method to dynamically update the shared=20 secret used for MN-AAA extension and create shared secret used for=20 MN-HA extension among Mobile Node, Foreign Agent and Home Agent,=20 based on MN-AAA shared secret, NAI, Foreign Agent IP address and=20 Foreign Agent Challenge. 2. The parameters used for Dynamic MN-HA shared secret generation This section defines the parameters used for MN-HA shared secret=20 generation and MN-AAA shared secret update. 2.1 Mobile IP Agent Advertisement Challenge Extension Currently Foreign Agent Challenge extension [3] is defined and in use = for 3G wireless system. That challenge extension is sent with the=20 Agent Advertisement by the Foreign Agent, in order to used by Mobile=20 Node to create the MN-AAA authentication extension for its Mobile IP=20 Registration Request. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Challenge ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: The Challenge Extension [3] Type 24 Length The length of the Challenge value in bytes; SHOULD be at least 4 Challenge A random value that SHOULD be at least 32 bits. The challenge extension is used to give the randomness for dynamic=20 MN-HA shared secret to avoid possible replay attack. Song et al. Expires 29 December 2001 [Page 3] =0C 2.2 Network Access Identifier (NAI) The Network Access Identifier (NAI) is the userID. The Mobile NAI extension in Mobile IP registration request is used=20 for AAA to identify the clients. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MN-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The Mobile Node NAI Extension [9] Type 131 (skippable) Length The length in bytes of the MN-NAI field MN-NAI A string in the NAI format defined in [1] 2.3 MN-AAA shared secret MN-AAA shared secret is the key used to compute MN-AAA authentication = extension. =20 3. MN-AAA shared secret update This section describes how the current MN-AAA shared secret is=20 updated by Mobile Node and AAA. How the initial MN-AAA shared secret = is distributed to the Mobile Node and AAA is out of scope of this=20 document 3.1 MN-AAA key update by Mobile Node 1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent=20 Advertisement. 2. The mobile node uses the FA Challenge, its own NAI, and the=20 previously assigned MN-AAA shared secret to calculate: =20 Current MN-AAA shared key =3D=20 HMAC-MD5(Initial MN-AAA-key | FA Challenge | MN NAI |=20 Initial MN-AAA-key) Song et al. Expires 29 December 2001 [Page 4] =0C 3.2 MN-AAA key update by AAA 1. AAA identifies Foreign Agent Challenge and MN's NAI from the AAA=20 message=20 2. AAA uses the FA Challenge, MN's NAI and the initially assigned=20 MN-AAA shared secret to calculate: Current MN-AAA shared key =3D=20 HMAC-MD5(Initial MN-AAA-key | FA Challenge | MN NAI | =20 Initial MN-AAA-key) =20 4. MN-HA shared secret creation This section describes the MN-HA shared secret creation by the Mobile = Node and AAA. 4.1 MN-HA key creation by Mobile Node 1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent Advertisement.=20 =20 2. The mobile node uses the FA Challenge, its own NAI, and the=20 currently generated MN-AAA shared secret to calculate: MN-HA shared key =3D HMAC-MD5(Current MN-AAA-key | FA Challenge = |=20 MN NAI | Current MN-AAA-key) =20 4.2 MN-HA shared key creation by AAA 1. AAA identifies Foreign Agent Challenge and the MN's NAI from the AAA message. 2. AAA calculates uses the FA Challenge, MN's NAI, and the currently=20 generated MN-AAA shared secret to calculate: MN-HA shared key =3D HMAC-MD5(Current MN-AAA-key | FA Challenge | = MN NAI | Current MN-AAA-key) Song et al. Expires 29 December 2001 [Page 5] =0C 5. Operation description Home Agent shall obtain MN-HA shared secret from AAA. The key fetching method varies from RADIUS [7] to DIAMETER [8] and it is out of scope of this document. =20 6. Security Considerations The key generation method described in this document provides the=20 reasonable level of security by dynamically creating and updating the = shared secrets. Since this key generation method depends on already=20 available key materials used in Mobile IP, it does not require new=20 key materials. Foreign Agent Challenge is used to avoid replay=20 attack and enhance the security. Therefore the weakest point=20 of this scheme is on the security of the shared secret for MN-AAA. =20 Since the MN-AAA shared secret is dynamically updated for every MIP=20 registration after it assigned first time, therefore the risk of=20 exposing the MN-AAA shared secret is minimal.=20 =20 Song et al. Expires 29 December 2001 [Page 6] =0C Appendix A - 3G Wireless Example In 3GPP2 Wireless system, both RADIUS and DIAMETER is supported as=20 the AAA protocols. This document suggests a method of dynamically creating and maintaining the shared secrets for MN-AAA and MN-HA=20 authentication. This is especially beneficial for the case of=20 dynamic HA allocation. In 3G wireless systems, if each Mobile Node=20 and Home Agent has the same static shared secret for MN-HA=20 authentication, it would be problematic for dynamic HA allocation=20 because each HA generally has no knowledge of all the MN-HA shared=20 secrets. On the other hand, configuring all the HAs with all the=20 MN-HA shared secrets in an administration domain raises concerns=20 in security and scalability. +--------------+ +--------------+ | |------------------->| | | AAAF | | AAAH | | |<-------------------| | +--------------+ +--------------+ ^ | ^ | | | | | | v | v +-----+ +--------------+ +--------------+ | | | | | | | MS |----->| PDSN/FA |------------------->| Home Agent | | |<-----| |<-------------------| | +-----+ +--------------+ +--------------+ =20 Figure 3 (3G Wireless Network) =20 =20 If this scheme applied to the 3GPP2 Wireless Network in figure 3, the = Mobile station (MS) shall update its pre-assigned MN-AAA shared=20 secret by running HMAC-MD5 with input of its NAI, Foreign Agent=20 Challenge, and the MN-AAA key. Then MS shall create the MN-HA shared = secret by running HMAC-MD5 with input of its NAI, Foreign Agent=20 challenge, and newly generated MN-AAA key. When AAAH receives the=20 AAA message, relayed from AAAF, AAAH shall update the MN-AAA shared=20 secret for that MS by using the same parameters from the AAA message. Upon completing the MN-AAA authentication, AAAH shall generate the=20 MN-HA shared secret by using the same parameters that the MS used. How Home Agent obtain that shared secret for MN-HA is up to AAA=20 protocol. In the case of using the RADIUS protocol, Home Agent shall = send the Access Request message to fetch MN-HA shared secret. In the=20 case of using DIAMETER protocol, the MN-HA Shared Secret will be =20 sent to HA by the HAR message. [10] =20 Song et al. Expires 29 December 2001 [Page 7] =0C Appendix B - MN-FA shared key consideration =20 Mobile Node and AAA now can easily derive MN-FA shared key by running = the HMAC-MD5 with input of MN-AAA shared secret, FA's IP address,=20 MN's NAI. This method has better scalability and less administrative = effort than provisioning MN-FA shared secrets. In face it is=20 administrative prohibitive to provision all MNs and FAs with static=20 shared secrets.=20 =20 =20 References [1] B. Aboba and M. Beadles. The Network Access Identifier. Request for Comments (Proposed Standard) 2486, Internet Engineering Task Force, December 1999. =20 [2] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent Challenge/Response Extension. Request for Comments (Proposed Standard) 3012, Internet Engineering Task Force, December 2000. [4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [5] P. Calhoun and C. E. Perkins. AAA Registration Keys for=20 Mobile IP Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-aaa-key-06.txt (work in progress) December 2001. [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. Song et al. Expires 29 December 2001 [Page 8] =0C [7] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote Authentication Dial In User Service (RADIUS). Request for Comments (Proposed Standard) 2865, Internet Engineering Task Force, June 2000. =20 [8] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER Base Protocol (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-aaa-diameter-03.txt, May 2001. [9] P. Calhoun and C. E. Perkins. Mobile IP Network Access=20 Identifier Extension for IPv4. Request for Comments=20 (Proposed Standard) 2794, Internet Engineering Task Force, March 2000 [10] P. Calhoun and C. E. Perkins. Diamter Mobile IP Extensions Internet Draft, Internet Engineering Task Force. draft-ietf-aaa-diameter-mobileip-01.txt =09 Addresses Questions about this memo can be directed to the authors: JUNHYUK SONG DongKie Leigh =20 SAMSUNG ELECTRONICS. SK TELECOM Mobile Development Team Core Network Development Team Network Systems Division Network R&D Center =09 Phone: +82-31-779-6822 Phone +82-2-829-4640 Email: santajun@lycos.co.kr Email: galahad@netsgo.com FAX: +82-31-7798769 FAX:+82-2-829-4612 Raymond Hsu CHAE YONG CHONG Qualcomm Inc. SAMSUNG ELECTRONICS. Corporate R&D Mobile Development Team Phone: 1-858-651-3623 Network Systems Division Email: rhsu@qualcomm.com Phone: +82-31-779-6822 FAX: 1-858-658-5006 Email:cychong@samsung.com Song et al. Expires 29 December 2001 [Page 9] =0C ------=_NextPart_000_010B_01C0FF0C.D5D88080-- From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 27 09:39:22 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06148 for ; Wed, 27 Jun 2001 09:39:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08713; Wed, 27 Jun 2001 07:39:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01832; Wed, 27 Jun 2001 06:38:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RDbNdP011934 for ; Wed, 27 Jun 2001 06:37:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RDbNCp011933 for mobile-ip-dist; Wed, 27 Jun 2001 06:37:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RDbIdP011926 for ; Wed, 27 Jun 2001 06:37:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01698 for ; Wed, 27 Jun 2001 06:37:23 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08488 for ; Wed, 27 Jun 2001 06:37:22 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f5RDZH119319 for ; Wed, 27 Jun 2001 15:35:17 +0200 (MEST) Message-ID: <3B39E161.68FF631C@inrialpes.fr> Date: Wed, 27 Jun 2001 15:36:33 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) References: <88BD5A70CA8BFA4CA15D0ED053E49D69067D70@tayexc14.americas.cpqcorp.net> <3B37FC9D.B5793A32@iprg.nokia.com> <3B38DE74.DF98D2D7@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: > Charlie Perkins wrote: > > I'm going to go out on a limb here, and suggest that the existing semantics > > for the Prefix Length option need substantial change. I might be missing > > something, but having a nonzero prefix length seems to only have the effect > > of requesting that the home agent should provide service for more home > > addresses. The addresses served by the home are determined by the > > collection of on-link prefixes, not the actual value of the Prefix Length > > field. Thus, this purpose could be managed by a single bit. > > Yes, get rid of the Prefix Length option. Sounds good. > > I really would like to hear people's opinion on if we should keep the > possibility of registering all possible home addresses with one single > BU using a non-zero prefix length. Especially mixing non-zero and zero > prefix lengths seems like a mess. > > Either, we need a very strict specification on how to use the two > formats, or we'd get rid of the case "prefix length != 0". I know it is > there to save bandwidth on a scare-bandwidth wireless link MN is > attached to and to minimize messaging, but the complexity on HA and MN > side due to this increases. Still, we can't use non-zero prefix length > towards the CN. I also see cases where the MN and HA have different > opinions on what home addresses are registered due to MPA/MPS/BU/BA > messaging mismatch. This thread has already explained difficulties on > this. > > > > > That would allow us to use the Prefix Length field for something more > > important -- namely to serve the same function as the proposed > > "Mobile Router Prefix Length Sub-Option", which I wrote about > > earlier and put into the existing intermediate (unfinished) draft which > > I am trying to finish now. Then we could get rid of that Sub-Option > > and have a more natural specification. > > > > Is this draft the Mobile IPv6 draft or another one? Does this have > anything to do with the mobile networks draft by INRIA and Motorola? Probably not because I've never had comments from Charlie concerning my draft and I do not know what Charlie is speaking about ... :-) I'm impatient to read the new draft. Should I assume that Charlie is in favor of bringing the "Mobile Network support item" up to the WG charter ? > Is the idea to send one BU for the registration of the MR itself (prefix > length 128) and a second BU for the registration of the network behind > the MR (prefix length e.g. 64)? > > I brought up the issues with this earlier. Do we have a solution for > running some kind of routing protocols between the MR and the home > subnet, in order to update routers and HAs on the home subnet of the > existance of the mobile network behind the MR? I have never heard anything such like this and I think this has nothing to do with Mobile IPv6. There is a couple of interesting issues here. If we do run a routing protocol between the MR and the home network, then the MR wouldn't need to perfom Mobile IPv6 anymore. > In all cases I know of > the routing protocols use link-local addresses in messaging. Link-local > addresses are not handled by Mobile IPv6 and are not tunnelled between > HA and MN. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/ From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 27 10:11:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23602 for ; Wed, 27 Jun 2001 10:11:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20618; Wed, 27 Jun 2001 07:08:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05397; Wed, 27 Jun 2001 07:08:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RE66dP012009 for ; Wed, 27 Jun 2001 07:06:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RE65UG012008 for mobile-ip-dist; Wed, 27 Jun 2001 07:06:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RE62dP012001 for ; Wed, 27 Jun 2001 07:06:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27072 for ; Wed, 27 Jun 2001 07:06:10 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA05885 for ; Wed, 27 Jun 2001 08:07:04 -0600 (MDT) Received: (qmail 12916 invoked by uid 500); 27 Jun 2001 13:54:47 -0000 Date: Wed, 27 Jun 2001 06:54:47 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt Message-ID: <20010627065447.Q22915@charizard.diameter.org> References: <010f01c0fec1$6687e860$0ee0d5a5@telecom.samsung.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <010f01c0fec1$6687e860$0ee0d5a5@telecom.samsung.co.kr>; from junhyuk@metro.telecom.samsung.co.kr on Wed, Jun 27, 2001 at 01:26:55PM +0900 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Authors, I am trying to understand this draft, and have a couple of questions. As you know, draft-ietf-mobileip-aaa-keys-06.txt, which has already been through WG last call and is about to be published as an RFC, describes a similar mechanism to what is proposed in the above mentioned draft. They key difference, from what I can tell, is that the nodes in question generate keys based on the FA challenge, instead of having the AAA infrastructure generate the keying material. Is this the only difference? The issue I have with this scheme is that the FA challenge is local to the foreign domain, and does not necessarily have any entropy. So, a malicious foreign agent could simply advertise a static challenge, and the mobile's keys would be created using the static challenge value. This issue here is that it exposes long term material to the foreign agent (and its administrators) which could be useful in key discovery attacks. The advantage with the AAAH creating the session keys, as described in draft-ietf-mobileip-aaa-keys-06.txt is that the long term keys are never exposed, and since only short term key material is sent to the foreign agent, security exposure is minimized. My 2 cents, PatC From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 27 12:25:35 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09344 for ; Wed, 27 Jun 2001 12:25:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04991; Wed, 27 Jun 2001 10:21:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25992; Wed, 27 Jun 2001 09:21:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGKXdP012359 for ; Wed, 27 Jun 2001 09:20:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RGKXVL012358 for mobile-ip-dist; Wed, 27 Jun 2001 09:20:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGKTdP012351 for ; Wed, 27 Jun 2001 09:20:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02268 for ; Wed, 27 Jun 2001 09:20:39 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16117 for ; Wed, 27 Jun 2001 09:20:39 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 94AE7256A; Wed, 27 Jun 2001 11:20:38 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 28F2B2459 for ; Wed, 27 Jun 2001 11:20:38 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Wed, 27 Jun 2001 12:20:36 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509B30@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'Charlie Perkins'" Cc: "'T.J. Kniveton'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Mobile Prefix Advertisements (more comments) Date: Wed, 27 Jun 2001 12:20:27 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Monday, June 25, 2001 11:08 PM > To: Powell, Ken > Cc: 'T.J. Kniveton'; 'mobile-ip@sunroof.eng.sun.com' > Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) > > "Powell, Ken" wrote: > > My comments to section 9.8.2 below request that only the prefixes > > that match a particular home registration be sent to the mobile > > node in Mobile Prefix Advertisements. If the binding has a zero > > prefix length, only the specific prefix for the mobile node's > > home address would be sent. For a bindings with a non-zero prefix > > length, all prefixes in the aggregate list would be sent. > > I'm going to go out on a limb here, and suggest that the > existing semantics > for the Prefix Length option need substantial change. I > might be missing > something, but having a nonzero prefix length seems to only > have the effect > of requesting that the home agent should provide service for more home > addresses. The addresses served by the home are determined by the > collection of on-link prefixes, not the actual value of the > Prefix Length > field. Thus, this purpose could be managed by a single bit. > > That would allow us to use the Prefix Length field for something more > important -- namely to serve the same function as the proposed > "Mobile Router Prefix Length Sub-Option", which I wrote about > earlier and put into the existing intermediate (unfinished) > draft which > I am trying to finish now. Then we could get rid of that Sub-Option > and have a more natural specification. This sounds like a good idea to me. This will probably also remove confusion caused by having two prefix length fields. > > > This left a problem, what prefixes do we send in response to a > > Router Solicitation? I think the home agent should use the > > same prefix selection logic, but the mobile node needs a way to > > override this behavior to support initialization. One option is > > to add a flag to the Mobile Prefix Solicitation Message: > > > > + Send All Prefixes flag > > + > > + If clear, the home agent replies by sending only the prefixes > > + that match the mobile nodes home registration as defined in > > + section 9.8.2. If set, the home agent will send all prefixes > > + for the home network as defined in section 9.8.1. No prefixes > > + will be sent if this flag is clear and the mobile node does > > + not yet have a home registration. > > So, in a way, I am supporting this suggestion. > > > > 9.8.2 Sending Changed Prefix Information to the Mobile Node > > > > Due to the number of comments on this section, I'm including > > the entire text with ">" marks, and slicing in the comments > > where they apply. > > > > > A home agent serving a mobile node will schedule the delivery > > > of new prefix information to that mobile node when any of the > > > following conditions occur: > > > > Can the following list of MUST and MAY requirements be merged > > into the algorithm for sending prefix information below? > > Maybe -- especially if you think it will be clearer. Would > you be willing > to suggest some reorganized text? However, one list says how > to figure > out that the list needs to be sent, and the other list says > how to figure > out when to send it. This will take a bit of thought, I'll let you know if I come up with something. > > > > > > > > MUST: > > > - The valid or preferred lifetime or the state of the flags > > > changes for the prefix of the mobile node's registered home > > > address changes > > > - The mobile node requests the information with a Router > > > Solicitation (see section 10.16). > > > > > > MAY: > > > - A new prefix is added to the aggregate list > > > > Why is this a MAY instead of MUST? Is it to cover the case > > where a home registration has a zero prefix length? > > It's a MAY because it won't hurt the mobile node not to find out > this information. For the most part, I agree. Particularly since all prefixes will definitely be advertised in an hour anyway. The only time I can see this being a problem is when other node's try to initiate a connection to the mobile node using the new address. This isn't a big concern to me, which kind of implies MUST isn't needed. Either MAY or SHOULD would make sense. > > > > - The valid or preferred lifetime or the state of the flags > > > changes for a prefix which is not used in any binding cache > > > entry for this mobile node > > > > I don't understand what your trying to do with this > > last MAY requirement. > > Maybe the mobile node didn't like one of the prefixes because > the lifetime was too short, and it changed to be long enough. > Really, though, it's almost the same as the previous bullet, thus > also a MAY. I didn't understand what was meant by "prefix which is not used in any binding cache entry for this mobile node". I think I get it now. I'm don't know if this is a good thing to do. A home agent that does this will probably end up sending duplicate information to a mobile node that has multiple bindings. More on this below... > > > It looks like its addressing a problem I've been wondering about. > > A mobile node with multiple home addresses could either > > > > o establish a single binding with a non-zero prefix > > length to cover all its home addresses, or > > > > o establish multiple bindings each with a zero prefix > > length to cover a single home address. > > > > In the latter case, how does the home agent recognize > > that a single node has multiple bindings? I believe the > > home agent should avoid sending duplicate home prefix > > advertisements to the mobile node. > > I'm not totally understanding this. It seems like a home agent > is going to have one primary care-of address for a mobile > node, and that is what binding the mobile node will effect. Does this rely on an assumption that two bindings with the same care-of address apply to the same mobile node? I think this is dangerous because: - We don't know what address assignment policy a remote network will use. One mobile node that has an active binding could suddenly disconnect, and another move onto the same remote network and pick up the same care-of address before the previous mobile node's binding times out. - I can envision someone defining an optimization to Mobile IPv6 where the mobile node binds it's home address to some intermediate router, then uses a local mechanism between itself and that router to have messages forwarded on the last leg. In such a case, multiple mobile nodes would want to use the router's address as their care-of address. > I agree that the home agent shouldn't send duplicate MPAs > to the mobile node, insofar as it's possible to do so, but > I didn't get the connection with the previous bullets, sorry. There is a good reason, I was making assumptions that were not intended. > > > One way to fix this is to have the home agent to only > > send prefix information that is applicable to a specific > > binding. Is that what your additional requirement was > > after? If so, I agree with the intent, but believe more > > detail is needed. Perhaps a statement like the following > > would help at the start of this section: > > > > + A home agent normally sends only the prefixes that match > > + a mobile node's home registration to the mobile node. A > > + match exists if the home registration's home address > > + contains a prefix or if the home registration's prefix > > + length field is non-zero. Each home registration entry > > + in the binding cache MUST be treated as if it were > > + created for a separate mobile node. > > I like the last sentence, but it belongs in the section on > "Home Agent Operation.. The first sentences are > already implicit in the previous parts of the description > of the Prefix Lengths field (as it is currently, that is). Let me try to explain where I was going with this. I see three policies a home agent could use when sending prefix information: 1) The home agent sends prefix information for the registered home address. 2) The home agent sends only prefix information that matches the binding. 3) The home agent sends all prefix information for all prefixes in the aggregate list. I think (1) is covered by the MUST requirements. The MAY requirements seem to cover (3). I was proposing (2) as a way to reduce the amount of duplicate prefix information sent to the same mobile node. The reason for the specific text I proposed was because if we accept (2), then its important to be clear what "match" means. My other suggestions below relied on that term to simplify the text. > > > > The home agent uses the following algorithm to determine when to > > > send prefix information to the mobile node. > > > > There is a requirement at the end of section 9.8.3 to send all > > prefixes periodically. I think that requirement should be folded > > into this section to avoid confusion between the two sections. > > > > + - Send a Home Agent Prefix Advertisement periodically to prevent > > + non-decrementing prefixes from expiring on the mobile node. > > + Calculate the interval between each successive transmission > > + independently as rand()*HomeRtrAdvInterval seconds; > > I did put in a new bullet according to your suggestion, but I was not > so clear about randomizing the interval. I see that it would > be a good > idea to avoid having a lot of advertisements happening all at once, > but the nature of the Binding Update process seems to imply that > the transmissions will effectively be randomized anyway, and with > a longer period between periodic transmissions. OK. > > > > - If a mobile node sends a solicitation, answer right away. > > > > If the proposal for the Send All Prefixes flag is accepted, > > the following text should be added here: > > > > + If the Send All Prefixes flag in the solicitation was set, > > + include all prefixes from the aggregate list in the > advertisement. > > But that would amount to saying the same thing in two different > places, unnecessarily, wouldn't it? Yes. I guess its not needed. > > > > - If a prefix changes state in a way that causes a mobile node's > > > address to go deprecated, send an advertisement right away. > > > > I believe the algorithm for RAND_ADV_DELAY covers this situation. > > It will cause an advertisement to be sent right away if a change > > causes an address to go deprecated. Can we remove this special > > case from here simplify the text? > > I have done so at your suggestion. > > > > - For any existing prefix, if the mobile node's binding expires > > > before the advertised Preferred Lifetime, do not schedule the > > > advertisement. The mobile node will get the revised > information > > > in its next Binding Acknowledgement. > > > > This is covered in the RAND_ADV_DELAY scheduling algorithm below. > > Can we remove it from here to simplify the text? > > O.K. > > > > - If a prefix is added, or if it changes in any way that does not > > > ============= > > > cause the mobile node's address to go deprecated, ensure that a > > > ================================================ > > > transmission is scheduled at time RAND_ADV_DELAY in the future. > > > > Same comment as before, do we need the special case text that is > > underlined? Also, this probably should be qualified to be more > > precise. > > O.K. I removed the text. > > > + - If a prefix in the aggregate list that matches the > mobile node's > > + home registration is added or its information changes, > ensure that > > + a transmission is scheduled at time RAND_ADV_DELAY in > the future. > > I basically merged this with the previous text. > > > > - If a prefix advertisement is scheduled, and a Binding Update > > > arrives, perform that advertisement and include the information > > > in a Router Advertisement that has the Binding > Acknowledgement as > > > ==================== > > > a Destination Option. Remove the future scheduled > advertisement. > > > > Did you mean Mobile Prefix Advertisement here? > > > > Is it really necessary to send the Binding Acknowledgement in the > > same message as the Mobile Prefix Advertisement? I suspect this > > will be awkward to implement given that Binding > Acknowledgements are > > probably handled in the kernel and Mobile Prefix Advertisements > > in a daemon. > > I made it a SHOULD. Thanks. > > > The 3rd rule in this list says "do not schedule the > advertisement" > > if a binding update is expected before the prefix becomes > > deprecated. The 5th rule says to send an advertisement if "a > > prefix advertisement is scheduled". Any change that satisfies > > 3rd rule will never be sent. Perhaps this last rule should say: > > > > + - If there are any unacknowledged changes to prefix information > > + when a Binding Update arrives for the home registration, send > > + a Mobile Prefix Advertisement to the mobile node > > immediately. + If an > > advertisement was previously scheduled for the changes, > > Done. > > > > Should the following be added here for completeness? > > > > + - If a home registration expires, cancel any scheduled > > + advertisements to the mobile node. > > Done. > > > > The home agent uses the following algorithm to compute > > > RAND_ADV_DELAY, the offset from the current time for the > > > scheduled transmission. > > > > > > If there is a transmission already scheduled, then > > > > > > if the current RAND_ADV_DELAY would cause another > > > transmission BEFORE the Preferred Lifetime of the > > > mobile node's home address derived from the prefix whose > > > advertisement information has changed, then > > > > > > add the new information to be transmitted to the > > > existing scheduled transmission -- return. > > > > > > otherwise, > > > > > > continue with the following computation, and add the > > > data from the existing scheduled transmission to the > > > newly scheduled transmission, deleting the previously > > > scheduled transmission event. > > > > I understood that the reason for sending only the changed prefix > > information instead of all prefix information is to reduce the > > connection costs for the mobile nodes on expensive wireless > > networks. We don't believe the cost savings for this extra > > complexity will be significant. We would prefer this to be an > > optional feature. > > You suggest that the home agent should be allowed to send more > than the minimum amount of information. This is O.K., except that > I didn't find a good place to insert the necessary text. If you can > suggest some text, I'll put it in. OK, something else for me to think through. > However, the important thing is that > the Mobile Node _MUST_ be able to correctly interpret a partial > list to contain only _changed_ information. A mobile node should > not assume that missing advertisements mean that the prefix has > been deleted. The latter operation has to be done by other means. Good point. I agree. Is this something that should be stated in section 10.17? > > > > > If the mobile node's binding expires after the Preferred > Lifetime, > > > then compute > > > > The indentation following this text could be interpreted to mean > > we still need to compute RAND_ADV_DELAY even when the IF > condition > > here is false. As an alternative, perhaps a rewording of this IF > > clause combined with text from above would be helpful. > > > > + If the mobile node's binding expires before the > Preferred Lifetime, > > + then return. The mobile node will get the revised information > > + with its next Binding Acknowledgement. Otherwise, > continue with the > > + following computation: > > > > > MAX_SCHEDULE_DELAY == > > > min (MAX_PFX_ADV_DELAY, Preferred Lifetime) > > > > > > for the newly advertised Preferred Lifetime. > > > Then compute RAND_ADV_DELAY = > > > MinRtrAdvInt + rand()*(MAX_SCHEDULE_DELAY - MinRtrAdvInt) > > > > There may be a problem overwhelming system or network resources > > if the scheduling algorithm causes the home agent to transmit a > > home prefix advertisement to all mobile nodes at the same time. > > The spec should allow a mechanism to avoid this. > > This was supposed to be part of the point of the RAND_ADV_ DELAY. Yes, but the algorithm still can cause a burst of traffic when preferred lifetime is zero or near zero. > > > + A home agent SHOULD perform scheduling of advertisements > > + described in this section independently for each home > > + registration in the binding cache to avoid a burst of > > + advertisements being sent to all mobile nodes at the same time. > > + In addition, a home agent MAY throttle transmission of > > + advertisements to prevent overwhelming local resources when > > + the rules above require immediate transmission of advertisements > > + to large numbers of mobile nodes. > > I used most of your words here. > > > Section 9.8.3 Sending Mobile Prefix Advertisements to the > Mobile Node > > > > > - When the advertisement was triggered by network renumbering, the > > > advertisement MUST include a Binding Request destination option. > > > > I agree with your intent of not requesting ACKs for > > every advertisement, but I don't think the term "triggered > > by network renumbering" catches all the important situations. > > How does the following sound? > > > > + The advertisement MUST include a Binding Request destination > > + option if this is the first advertisement sent for a home > > + registration or if there was a change in prefix information > > + since the last acknowledged advertisement was sent to the > > + mobile node for the home registration. > > Done! > > > > > > > > The home agent SHOULD periodically continue to retransmit this > > > tunneled packet to the mobile node, until it is acknowledged by > > ======== > > > > The term "tunneled" was removed elsewhere in section 9.8. > > Should it be removed here too? > > Done. > > > > [Delete this paragraph? This is also too much.] > > > Whenever a mobile node has a valid binding on a network other > > > than its home network, the home agent MUST send a Mobile Prefix > > > Advertisement with all prefixes in the aggregate list to the > > > mobile node at least once per HomeRtrAdvInterval seconds, and > > > upon receipt of a valid Router Solicitation from the mobile > > > node. > > O.K. I reckon it's already been covered earlier. > > > I have no idea what "a network other than its home network" > > means, but I think a requirement to periodically transmit > > all prefixes is needed because home addresses on mobile nodes > > still have a finite lifetime that will expire unless > > periodically updated. As I stated above, I think this requirement > > fits better in section 9.8.2. > > It's there now. > > > Section 10.16 Sending Mobile Prefix Solicitations > > > > > The mobile node SHOULD send a Solicitation to the home agent > > > when its home address will become invalid within > MaxRtrAdvInterval > > > seconds, where this value is acquired in a previous Router > > > Advertisement from the home agent. ... ====== > > ============= > > > > Should this be Mobile Prefix Advertisement? > > Done. > > > > If the mobile node does not have a valid home address > available for > > > use as the IP source address, it MAY use its care-of > address, [but > > > there will not be a security association between the > Home Agent and > > > the care-of address for the corresponding Advertisement to be > > > authenticated.] > > > > We think some kind of security association will be needed here. > > I don't know how to specify that, and the home agent can limit this. OK. > > > Section 10.17 Receiving Mobile Prefix Advertisements > > > > > - The Source Address of the IP packet carrying the Router > > > Advertisement is ..... ====== > > ============= > > > > Should this be Mobile Prefix Advertisement? > > Fixed. > > > > Since the advertisement contains a Binding Request > option, the mobile > > > node SHOULD return a Binding Update, which will be > viewed by the home > > > agent as an acknowledgement of the corresponding Mobile Prefix > > > Advertisement, which it can cease retransmitting. > > > > Should this paragraph start with "If the advertisement > contains..."? > > The Binding Request option does not always need to be > included with > > a Mobile Prefix Advertisement. > > Fixed. > > > Appendix A: Remote Home Address Configuration > > > > I noticed you didn't attempt to fix this part. How about: > > > > Delete: > > > > > A mobile node MAY generate a temporary home address using the > > > following information: > > > > > > - the subnet prefix from the home network's mobile agent anycast > > > address, and > > > > > > - the globally unique interface identifier that would have been > > > used to generate the link local address if the mobile node were > > > attached directly to the home network. > > > > > > Such a temporary address could be used to establish a > binding with > > > a home agent in the absence of any other known home > addresses. It > > > could be created with short valid lifetime and a > preferred lifetime > > > of zero to ensure a quick transition to other addresses generated > > > when stateless or stateful (DHCPv6) address > autoconfiguration runs. > > > > Your new Mobile Prefix Solicit/Advertisement exchange capability > > between the mobile node's care-of address and home agent > makes this > > hack unnecessary. > > > > Change steps 5 through 9 to: > > > > + 5. Select the most preferred home agent and establish a security > > + association between the mobile node's current care-of address > > + and the home agent for temporary use during > initialization only. > > + > > + 6. Send a Home Prefix Solicitation message with the Request All > > + Prefixes flag set to the home agent from the mobile node's > > + care-of address. > > + > > + 7. Receive a Home Prefix Advertisement message from the > home agent, > > + follow stateless address autoconfiguration rules to configure > > + home addresses for prefixes received. > > + > > + 8. Create a security association between the mobile node's home > > + address and the home agent. > > + > > + 9. Send a binding update(s) to the home agent to register the > > + mobile node's home addresses. > > + > > + 10. Receive binding acknowledgement(s) then begin normal > > + communications. > > Done, to a close approximation. > > Regards, > Charlie P. > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 27 13:55:37 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17534 for ; Wed, 27 Jun 2001 13:55:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04028; Wed, 27 Jun 2001 10:51:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15638; Wed, 27 Jun 2001 10:37:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RHa1dP012640 for ; Wed, 27 Jun 2001 10:36:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RHa0mf012639 for mobile-ip-dist; Wed, 27 Jun 2001 10:36:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RHZvdP012632 for ; Wed, 27 Jun 2001 10:35:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16617 for ; Wed, 27 Jun 2001 10:36:07 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08915 for ; Wed, 27 Jun 2001 11:37:00 -0600 (MDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id AF56D270A; Wed, 27 Jun 2001 12:36:01 -0500 (CDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 733B12495 for ; Wed, 27 Jun 2001 12:36:01 -0500 (CDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Wed, 27 Jun 2001 13:36:00 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D69509B61@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'Charlie Perkins'" Cc: mobile-ip@sunroof.eng.sun.com, "'T.J. Kniveton'" Subject: RE: [mobile-ip] Mobile Prefix Advertisements ... additional thoug ht Date: Wed, 27 Jun 2001 13:35:57 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Monday, June 25, 2001 6:59 PM > To: Powell, Ken > Cc: mobile-ip@sunroof.eng.sun.com; 'T.J. Kniveton' > Subject: Re: [mobile-ip] Mobile Prefix Advertisements ... additional > thought > > > > Hello Ken, > > I didn't see any other discussion about this on the mailing > list, so I didn't make the corresponding change to the > document. However, I think that one can go even farther. > - The Binding Acknowledgement could be a destination > option in the Mobile Prefix Advertisement (MPA). Yes. It makes sense for this to be a SHOULD type requirement to save on bandwidth. However, I think for code complexity reasons, I would prefer not to mandate this. This may be a difficult thing to implement on home agents where the Mobile Prefix Advertisement logic is in a user space daemon and the Binding Update logic is in kernel space. > If the mobile node does NOT get the MPA, then it > would retransmit the Binding Update since the Binding > Acknowledgement was never received. > > In the case, if the mobile node only had one home address > and it was getting renumbered to have a new prefix, then > the home agent does NOT need to get > a Binding Update, since it can assume that either: > - the mobile node will receive the Binding Acknowledgement > - the mobile node will retransmit the Binding Update. > > So, a typical exchange could be exactly two messages. Sounds like a great thing to allow as an option for home agents to implement. > > What do you think about that? Of course, if there are > lots of prefixes and lots of home addresses involved, the > same logic does not necessarily hold. But perhaps we > ought to make the simple cases really simple. Maybe > there should be another bit in the MPA to say whether > the Binding Update is requested or not. I thought that is what the Binding Request destination option was being sent for (section 9.8.3). Do we need a bit in addition to that? If the mobile prefix ack proposal is accepted, then I could see adding a bit to the mobile prefix advertisement to say whether the mobile prefix ack is requested. > > Regards, > Charlie P. > > > > > "Powell, Ken" wrote: > > > I've been wondering about the coupling between mobile > > prefix solicitation/advertisement and binding request/ > > update/ack. > > > > Specifically: > > - Section 9.8.2 describes how a binding update could > > trigger a mobile prefix advertisement > > - Section 9.8.3 describes how a binding request/update is > > used to acknowledge the mobile prefix advertisement > > > > This leads me to consider the following exchange: > > > > mobile node <--> home agent > > =========================== > > --> binding update w/ ack bit set > > (destination option processing on home agent handles > > processes binding update and sends binding ack, > > then signals ICMP mobile prefix handler to check > > for pending advertisements) > > <-- binding ack > > <-- mobile prefix advertisement w/ binding request > > --> binding update w/ ack bit set > > <-- binding ack > > > > It seems we could simplify the exchange rules by > > adding an ICMP mobile prefix ack message that could be > > used to replace the final binding request/update/ack > > exchange. > > > > --> binding update w/ ack bit set > > <-- binding ack > > <-- mobile prefix advertisement > > --> mobile prefix ack > > > > Ken > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 27 21:28:25 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00856 for ; Wed, 27 Jun 2001 21:28:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08173; Wed, 27 Jun 2001 18:28:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27414; Wed, 27 Jun 2001 18:26:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S1PgdP015487 for ; Wed, 27 Jun 2001 18:25:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5S1PgX7015486 for mobile-ip-dist; Wed, 27 Jun 2001 18:25:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S1PcdP015479 for ; Wed, 27 Jun 2001 18:25:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03495 for ; Wed, 27 Jun 2001 18:25:49 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01296 for ; Wed, 27 Jun 2001 18:25:47 -0700 (PDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id KAA10813 for ; Thu, 28 Jun 2001 10:28:04 +0900 (KST) Message-ID: <008801c0ff71$57374080$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: References: <010f01c0fec1$6687e860$0ee0d5a5@telecom.samsung.co.kr> <20010627065447.Q22915@charizard.diameter.org> Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt Date: Thu, 28 Jun 2001 10:26:21 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f5S1PcdP015480 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Pat! I finally caught your attention. Read my comment below. ----- Original Message ----- From: "Pat Calhoun" To: Sent: Wednesday, June 27, 2001 10:54 PM Subject: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt > Authors, > > I am trying to understand this draft, and have a couple of questions. > > As you know, draft-ietf-mobileip-aaa-keys-06.txt, which has already been through WG > last call and is about to be published as an RFC, describes a similar mechanism > to what is proposed in the above mentioned draft. They key difference, from what I > can tell, is that the nodes in question generate keys based on the FA challenge, > instead of having the AAA infrastructure generate the keying material. > > Is this the only difference? That is the one of the key difference, your proposal requires new Mobile IP extension while our proposal doesn't. Besides, this document propose to dynamically update MN-AAA shared seceret based on FAC. MN-HA shared secreet is created based on newly generated MN-AAA shared key. > The issue I have with this scheme is that the FA challenge is local to the > foreign domain, and does not necessarily have any entropy. So, a malicious > foreign agent could simply advertise a static challenge, and the mobile's > keys would be created using the static challenge value. This issue here is > that it exposes long term material to the foreign agent (and its administrators) > which could be useful in key discovery attacks. The advantage with the > AAAH creating the session keys, as described in draft-ietf-mobileip-aaa-keys-06.txt > is that the long term keys are never exposed, and since only short term key > material is sent to the foreign agent, security exposure is minimized. > > My 2 cents, I don't understand what do you mean by that? FA is vouched by veirification infrastructure (AAA) right? Now, let's say there is what you called malicious foregin agent. I still don't see how to derive the long term material used for making MN-HA by sending static FAC. Even FA somehow compromises MN-AAA shared key used in creating MN-HA shared key, its initial MN-AAA shared key is secure. Because MN-HA shared secret is made of newly created MN-AAA shared key (New long term key) with FAC, and MN NAI. Not initial MN-AAA shared key. PS. In RFC-3012, it is not clear whether Foreign Agent includes MN-AAA extension to the RRQ and relay to HA after MN-AAA authentication by verification infrastructure. Can you calarify that? > > PatC > From owner-mobile-ip@sunroof.eng.sun.com Wed Jun 27 21:52:43 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18313 for ; Wed, 27 Jun 2001 21:52:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13435; Wed, 27 Jun 2001 18:52:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00304; Wed, 27 Jun 2001 18:52:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S1p1dP015589 for ; Wed, 27 Jun 2001 18:51:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5S1p1tA015588 for mobile-ip-dist; Wed, 27 Jun 2001 18:51:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S1owdP015581 for ; Wed, 27 Jun 2001 18:50:58 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26775 for ; Wed, 27 Jun 2001 18:51:09 -0700 (PDT) Received: from ms.samsung.com ([211.45.29.136]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08516 for ; Wed, 27 Jun 2001 18:51:08 -0700 (PDT) Received: from CYCHONG ([203.241.48.20]) by ms.samsung.com (Netscape Messaging Server 4.15) with SMTP id GFMAB000.K27 for ; Thu, 28 Jun 2001 10:47:24 +0900 Message-ID: <000a01c0ff75$d149b8e0$10e0d5a5@CYCHONG> From: "=?ks_c_5601-1987?B?Q2hhZS15b25nIENob25nXCjBpMDnv7VcKQ==?=" To: References: <010f01c0fec1$6687e860$0ee0d5a5@telecom.samsung.co.kr> <20010627065447.Q22915@charizard.diameter.org> Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt Date: Thu, 28 Jun 2001 10:58:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f5S1owdP015582 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Pat, Read my comments. ----- Original Message ----- From: "Pat Calhoun" To: Sent: Wednesday, June 27, 2001 10:54 PM Subject: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt > Authors, > > I am trying to understand this draft, and have a couple of questions. > > As you know, draft-ietf-mobileip-aaa-keys-06.txt, which has already been through WG > last call and is about to be published as an RFC, describes a similar mechanism > to what is proposed in the above mentioned draft. They key difference, from what I > can tell, is that the nodes in question generate keys based on the FA challenge, > instead of having the AAA infrastructure generate the keying material. > > Is this the only difference? > This does not introduce "NEW" extensions which require to modify Mobile Node and FA(HA too?) If there is a way to achive enough security without adding or modifying already defined protocol, it is desirable to use that. > The issue I have with this scheme is that the FA challenge is local to the > foreign domain, and does not necessarily have any entropy. So, a malicious > foreign agent could simply advertise a static challenge, and the mobile's > keys would be created using the static challenge value. This issue here is > that it exposes long term material to the foreign agent (and its administrators) > which could be useful in key discovery attacks. The advantage with the > AAAH creating the session keys, as described in draft-ietf-mobileip-aaa-keys-06.txt > is that the long term keys are never exposed, and since only short term key > material is sent to the foreign agent, security exposure is minimized. > You said that some FA could use the static FAC. If so, what is the purpose of the FAC. In my understand, FAC is used to pretect replay attack. If some FA does use static FAC all the time, it must provide some other means to protect it. Or that FA give up the replay attack protecting service provided by FAC extension. If so, why we should do for this FA. Should we do another jobs to help that FA which maybe does not want to use the FAC extension's capability? > My 2 cents, > > PatC From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 03:01:07 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07230 for ; Thu, 28 Jun 2001 03:01:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29083; Thu, 28 Jun 2001 01:01:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05596; Thu, 28 Jun 2001 00:00:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S6xldP015876 for ; Wed, 27 Jun 2001 23:59:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5S6xlQ6015875 for mobile-ip-dist; Wed, 27 Jun 2001 23:59:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S6xhdP015868 for ; Wed, 27 Jun 2001 23:59:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25904 for ; Wed, 27 Jun 2001 23:59:53 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03644 for ; Thu, 28 Jun 2001 01:00:47 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5S6xpN17122 for ; Thu, 28 Jun 2001 08:59:51 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id IAA19467; Thu, 28 Jun 2001 08:59:50 +0200 Message-ID: <3B3AD597.83F421AF@era.ericsson.se> Date: Thu, 28 Jun 2001 08:58:31 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) References: <88BD5A70CA8BFA4CA15D0ED053E49D69067D70@tayexc14.americas.cpqcorp.net> <3B37FC9D.B5793A32@iprg.nokia.com> <3B38DE74.DF98D2D7@era.ericsson.se> <3B39E161.68FF631C@inrialpes.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > > Is the idea to send one BU for the registration of the MR itself (prefix > > length 128) and a second BU for the registration of the network behind > > the MR (prefix length e.g. 64)? > > > > I brought up the issues with this earlier. Do we have a solution for > > running some kind of routing protocols between the MR and the home > > subnet, in order to update routers and HAs on the home subnet of the > > existance of the mobile network behind the MR? > > I have never heard anything such like this and I think this has nothing > to do with Mobile IPv6. There is a couple of interesting issues > here. If we do run a routing protocol between the MR and the home > network, then the MR wouldn't need to perfom Mobile IPv6 anymore. If the MR runs routing protocols at home, then it should continue to do so when it is not at home, shouldn't it? I didn't intend to run routing protocols propagating MR's mobile prefix over the Internet, but rather in a bi-directional tunnel between the HA and MN. > > > In all cases I know of > > the routing protocols use link-local addresses in messaging. Link-local > > addresses are not handled by Mobile IPv6 and are not tunnelled between > > HA and MN. /Mattias From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 07:18:32 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11520 for ; Thu, 28 Jun 2001 07:18:31 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09787; Thu, 28 Jun 2001 05:18:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16518; Thu, 28 Jun 2001 04:17:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SBGUdP016208 for ; Thu, 28 Jun 2001 04:16:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SBGUOv016207 for mobile-ip-dist; Thu, 28 Jun 2001 04:16:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SBGQdP016200 for ; Thu, 28 Jun 2001 04:16:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24597 for ; Thu, 28 Jun 2001 04:16:35 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08791 for ; Thu, 28 Jun 2001 05:16:32 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11242; Thu, 28 Jun 2001 07:15:52 -0400 (EDT) Message-Id: <200106281115.HAA11242@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc2002-bis-06.txt Date: Thu, 28 Jun 2001 07:15:51 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : IP Mobility Support for IPv4, revised Author(s) : C. Perkins Filename : draft-ietf-mobileip-rfc2002-bis-06.txt Pages : 95 Date : 27-Jun-01 This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc2002-bis-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-rfc2002-bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010627143518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc2002-bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc2002-bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010627143518.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 11:10:49 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10795 for ; Thu, 28 Jun 2001 11:10:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17448; Thu, 28 Jun 2001 09:10:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10894; Thu, 28 Jun 2001 08:09:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SF8idP016561 for ; Thu, 28 Jun 2001 08:08:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SF8hAM016560 for mobile-ip-dist; Thu, 28 Jun 2001 08:08:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SF8edP016553 for ; Thu, 28 Jun 2001 08:08:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18520 for ; Thu, 28 Jun 2001 08:08:49 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00027 for ; Thu, 28 Jun 2001 08:08:44 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f5SF6CM18940 for ; Thu, 28 Jun 2001 17:06:27 +0200 (MEST) Message-ID: <3B3B4814.BF9D32BF@inrialpes.fr> Date: Thu, 28 Jun 2001 17:07:00 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements (more comments) References: <88BD5A70CA8BFA4CA15D0ED053E49D69067D70@tayexc14.americas.cpqcorp.net> <3B37FC9D.B5793A32@iprg.nokia.com> <3B38DE74.DF98D2D7@era.ericsson.se> <3B39E161.68FF631C@inrialpes.fr> <3B3AD597.83F421AF@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mattias Pettersson wrote: > Thierry Ernst wrote: > > > Is the idea to send one BU for the registration of the MR itself (prefix > > > length 128) and a second BU for the registration of the network behind > > > the MR (prefix length e.g. 64)? > > > > > > I brought up the issues with this earlier. Do we have a solution for > > > running some kind of routing protocols between the MR and the home > > > subnet, in order to update routers and HAs on the home subnet of the > > > existance of the mobile network behind the MR? > > > > I have never heard anything such like this and I think this has nothing > > to do with Mobile IPv6. There is a couple of interesting issues > > here. If we do run a routing protocol between the MR and the home > > network, then the MR wouldn't need to perfom Mobile IPv6 anymore. > > If the MR runs routing protocols at home, then it should continue to do > so when it is not at home, shouldn't it? I guess it should, but doesn't it raises a number of issues ? I can think of a larger cost for the path for instance. Increasing delays may cause routing table partition and that sort of things. What about a multi-homed mobile network ? Etc ... > I didn't intend to run routing protocols propagating MR's mobile prefix > over the Internet, but rather in a bi-directional tunnel between the HA > and MN. Of course not, I can not see how one could propagate a MR's mobile prefix over the Internet, we would end up in breaking aggregation. No one would ever think about it ... Having a bi-directional tunnel and keep running the routing protocol over the tunnel is the easiest thing to do, but may be not the best. All is depending of what kind of mobile network is behind the MR. I am going to write a draft to try to explain the issues. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 11:16:48 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14858 for ; Thu, 28 Jun 2001 11:16:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20842; Thu, 28 Jun 2001 09:13:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11693; Thu, 28 Jun 2001 08:13:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SFCUdP016634 for ; Thu, 28 Jun 2001 08:12:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SFCUPA016633 for mobile-ip-dist; Thu, 28 Jun 2001 08:12:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SFCQdP016626 for ; Thu, 28 Jun 2001 08:12:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11515 for ; Thu, 28 Jun 2001 08:12:35 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02082 for ; Thu, 28 Jun 2001 08:12:35 -0700 (PDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 11:11:38 -0400 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: Survey on proposed IPv6 multi-homing mechanis ms Date: Thu, 28 Jun 2001 11:11:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I am working at implementing Differentiated services with Mobile IP. Now, a proposal I have is suppose you have a queue holding a class of packets, and the mobile node does a hand over, I propose to purge all the packets belonging to the MN in the queue, so that the MN at its new access point with have to re-classify the packets and re-send then to the queue over there. I hope scanario is ok with everyone. -Sharif. From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 13:19:26 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10274 for ; Thu, 28 Jun 2001 13:19:25 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29967; Thu, 28 Jun 2001 11:20:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15965; Thu, 28 Jun 2001 10:19:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SHI5dP016909 for ; Thu, 28 Jun 2001 10:18:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SHI5st016908 for mobile-ip-dist; Thu, 28 Jun 2001 10:18:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SHI1dP016901 for ; Thu, 28 Jun 2001 10:18:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21176 for ; Thu, 28 Jun 2001 10:18:11 -0700 (PDT) Received: from mail.verizonwireless.com ([199.74.158.61]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18212 for ; Thu, 28 Jun 2001 10:18:09 -0700 (PDT) Received: from mail.verizonwireless.com by mail.verizonwireless.com (414/1100) with ESMTP id f5SH8Vk13061 for ; Thu, 28 Jun 2001 13:08:31 -0400 (EDT) Received: by hqbedigwy2.corp.bam.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Jun 2001 13:16:43 -0400 Message-ID: <43E8CCEAF148D211854C00805FA72E5807019865@rhqnneex1.corp.bam.com> From: "Carroll, Christopher X" To: mobile-ip@sunroof.eng.sun.com Cc: "Flynn, Gerry J" Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgenera tion-00.txt Date: Thu, 28 Jun 2001 13:18:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Junhyuk, Dongkie, Chae Yong, and Raymond, I have the following comments regarding your draft MIPv4 key generation proposal: Your proposal utilizes a Key Agreement protocol which is similar to the methods used in TIA TR-45 and GSM cellular telephone networks to create SESSION keys for privacy and authentication. Also, Bootstrapping the root key (MN-AAA key, A-key, or GSM K key) is a difficult problem, i.e., distributing secret keys to millions of handsets must be done securely and efficiently. GSM / 3GPP distributes keys via SIMs (smart cards), while TIA TR-45 / 3GPP2 primarily utilizes manufacturer pre-load and an out-of-band distribution network to populate the network's HLR/AC (equivalent to AAA). However, in those networks, the root key (A-key or GSM K key) is never updated/modified by the visited network. The root keys for these networks are jealously guarded by the Home Service provider. I suspect the MIPv4 service providers will want to protect the MN-AAA and MN-HA keys to the same degree. Unfortunately, your proposal enables a potentially devastating Denial-of-Service attack in which a Rogue FA creates a mis-synchronization of the MN-AAA and MN-HA keys between the MN and home network (AAA and HA). Even if every FA acts properly, a hacker can create his own FA that continuously initiates MN-AAA and MN-HA key updates with any MN within it's vacinity. One device, strategically placed at an airport or in the center of a city, could change the root keys in thousands of MNs. How will the service provider re-syncronize the MN-AAA or MN-HA key? Perhaps by the expensive process of manually re-loading the keys or distributing new smart cards. Perhaps the user could log onto a protected (SSL) website and download new keys (if they're allowed access). Your proposed MN-AAA key chaining is inherently susceptable to synchronization problems between the MN and AAA. Even the 3GPP AKA protocol has elaborate procedures for re-synchronization of sequence numbers. How do you propose to re-synchronize MN-AAA keys when there's a mismatch? How would the network know whether a fraudulent access attempt or MN-AAA key mismatch occurred? One possible solution to this problem could be to use a Mutual Authentication scheme between the MN and FA (or between the MN and AAA) to ensure that the MN only updates these keys with a valid FA - however, this may be impractical because the MN and FA must share a common secret in the first place (Chicken-before-the-egg problem). Let's not talk about Public key because MNs may not have the processing power to use Certificates and service providers may not have the expertise to deal with PKI. The MN-AAAh key appears to be the root key for MIPv4 in which a Radius/Diameter AAA server is used. It appears that the MN-AAAh key is intended to be a subscription lifetime key (like the A-key and K in TR-45/3GPP2 and GSM/3GPP networks). It is dangerous to allow a visited system to update such a key during the subscription lifetime - such a procedure should be initiate and controlled by the home system (AAAh). (Note: your root key update procedure doesn't even enable secure recovery if the MN-AAA key data base were compromised because the hacker/criminal will only need to intercept the FAC to generate the new MN-AAA key). The MN-HA key may not be a subscription lifetime key, but it could be. However, MN-HA key generation can be efficiently performed based on the MN-AAA key which implies that AAAh must be involved in the process. Your Dynamic / session generation of the MN-HA key appears inefficient from a key management perspective because the AAAh must generate and distribute a new MN-HA key for every system access. In the draft Perkins/Calhoun 06 proposal, a new MN-HA key is generated only when necessary. Thus, even when dynamic HA assignment occurs, the AAAh generates and distributes the new MN-HA key for the new HA. It also issues the MN-HA key update to the MN. It appears that the draft 06 proposal could allow the AAAh (and MN) to manage the MN-HA keys for multiple HA simultaneously. The MN simply needs a queue in which to store the different MN-HA keys or the AAAh could update one MN-HA key during each dynamic HA assignment. From my perspective the current Perkins/Calhoun proposal reduces the amount of MN-HA key generation and distribution while maintaining the proper security. It is likely most efficient to generate the MN-FA key as a session key because the MN may interact with countless FAs (impractical for MN to store MN-FA key for all FAs). In fact, I proposed a similar procedure to the 3GPP2 TSG-P Subcommittee several months ago. However, dynamic generation of the MN-FA key based on the FAC may not be significantly more efficeint than having the MN-FA generated based on randomness provided by the AAAh. I have a cryptographic concern with your method of generating a new MN-AAA key based on the previous MN-AAA key. This key generation chaining may be vulnerable to some type of cryptanalysis. In general, your proposed key generation scheme appears unacceptable because it may expose MIPv4 networks to a devastating Denial-of-Service attack. Like many security schemes that rely on synchronization, your key generation scheme appears too unstable to be reliable. However, I do beleive that your MN-FA key generation proposal has some merit. regards, chris ********************************************************************** Christopher Carroll Office: 508-330-3401 Senior Member Technical Staff fax: 508-330-3403 Verizon Wireless cellular: 781-424-4131 Chair TR-45 Adhoc Authentication Group email: christopher.carroll@verizonwireless.com ********************************************************************** From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 14:50:07 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15410 for ; Thu, 28 Jun 2001 14:50:06 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08494; Thu, 28 Jun 2001 11:50:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08886; Thu, 28 Jun 2001 11:50:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SImwdP017019 for ; Thu, 28 Jun 2001 11:48:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SImwBO017018 for mobile-ip-dist; Thu, 28 Jun 2001 11:48:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SImtdP017011 for ; Thu, 28 Jun 2001 11:48:55 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5SIn1U598363; Thu, 28 Jun 2001 11:49:01 -0700 (PDT) Message-Id: <200106281849.f5SIn1U598363@jurassic.eng.sun.com> Date: Thu, 28 Jun 2001 11:49:01 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] LLA option in the fast handoffs draft To: vijayd@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Cc: G.Tsirtsis@flarion.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8pyo4scxj1hfhQl+K6mQ3A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > hi, > > I have a question on the Link Layer address option (sec 4.4.2 > in the fast handoffs draft). Shouldnt the length of the option > be in terms of octets and not 8 octets? > > Vijay Vijay, Sorry for the late response. You are right. The length should be octets. Thanks for catching this! alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 18:17:30 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27181 for ; Thu, 28 Jun 2001 18:17:29 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17987; Thu, 28 Jun 2001 16:18:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27494; Thu, 28 Jun 2001 15:17:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SMG7dP017218 for ; Thu, 28 Jun 2001 15:16:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SMG6TY017217 for mobile-ip-dist; Thu, 28 Jun 2001 15:16:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SMG3dP017210 for ; Thu, 28 Jun 2001 15:16:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26646; Thu, 28 Jun 2001 15:16:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16718; Thu, 28 Jun 2001 16:16:09 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA05950; Thu, 28 Jun 2001 15:16:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5SMG7p04320; Thu, 28 Jun 2001 15:16:07 -0700 X-mProtect: Thu, 28 Jun 2001 15:16:07 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd9XOAmp; Thu, 28 Jun 2001 15:16:06 PDT Message-ID: <3B3BACA6.21DD29BE@iprg.nokia.com> Date: Thu, 28 Jun 2001 15:16:06 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alper Yegin CC: mobile-ip@sunroof.eng.sun.com, G.Tsirtsis@flarion.com Subject: Re: [mobile-ip] LLA option in the fast handoffs draft References: <200106281849.f5SIn1U598363@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit To maintain uniformity the length of the IP address option should also be in octets. what do you think? Vijay Alper Yegin wrote: > > > hi, > > > > I have a question on the Link Layer address option (sec 4.4.2 > > in the fast handoffs draft). Shouldnt the length of the option > > be in terms of octets and not 8 octets? > > > > Vijay > > Vijay, > > Sorry for the late response. > > You are right. The length should be octets. Thanks for catching this! > > alper From owner-mobile-ip@sunroof.eng.sun.com Thu Jun 28 20:45:38 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09317 for ; Thu, 28 Jun 2001 20:45:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08132; Thu, 28 Jun 2001 18:46:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21134; Thu, 28 Jun 2001 17:46:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T0ixdP017415 for ; Thu, 28 Jun 2001 17:44:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5T0ixRF017414 for mobile-ip-dist; Thu, 28 Jun 2001 17:44:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T0iudP017407 for ; Thu, 28 Jun 2001 17:44:56 -0700 (PDT) Received: from istanbul.Eng.Sun.COM (istanbul.Eng.Sun.COM [129.146.86.247]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5T0j1U695637; Thu, 28 Jun 2001 17:45:01 -0700 (PDT) Message-Id: <200106290045.f5T0j1U695637@jurassic.eng.sun.com> Date: Thu, 28 Jun 2001 17:45:01 -0700 (PDT) From: Alper Yegin Subject: Re: [mobile-ip] LLA option in the fast handoffs draft To: Alper.Yegin@eng.sun.com, mobile-ip@sunroof.eng.sun.com Cc: G.Tsirtsis@flarion.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jnSNpaMMlYPIu2Og5z6lvQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4_37 SunOS 5.8.1 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hmmm, I might have missed something. I'm looking at RFC2461, and I see the length of Source/Target Link Layer Address (section 4.6.1) is "in units of 8 octets". I think the assumption is that the the option needs to be at least 8 byte aligned (of course), and the the recevier can map "Type" field to "exact" length of the address (a L2 knowledge). It looks like I had jumped the gun too quick. What does other authors think? alper > To maintain uniformity the length of the IP address option should > also be in octets. what do you think? > > Vijay > > Alper Yegin wrote: > > > > > hi, > > > > > > I have a question on the Link Layer address option (sec 4.4.2 > > > in the fast handoffs draft). Shouldnt the length of the option > > > be in terms of octets and not 8 octets? > > > > > > Vijay > > > > Vijay, > > > > Sorry for the late response. > > > > You are right. The length should be octets. Thanks for catching this! > > > > alper alper From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 29 02:11:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00667 for ; Fri, 29 Jun 2001 02:11:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03435; Fri, 29 Jun 2001 00:11:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05091; Thu, 28 Jun 2001 23:11:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T6AZdP017721 for ; Thu, 28 Jun 2001 23:10:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5T6AZRU017720 for mobile-ip-dist; Thu, 28 Jun 2001 23:10:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T6AWdP017713 for ; Thu, 28 Jun 2001 23:10:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26041 for ; Thu, 28 Jun 2001 23:10:41 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01775 for ; Fri, 29 Jun 2001 00:11:36 -0600 (MDT) Received: from metro (a22414 [165.213.224.14]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id PAA10706 for ; Fri, 29 Jun 2001 15:13:02 +0900 (KST) Message-ID: <002b01c10062$5472f6e0$0ee0d5a5@telecom.samsung.co.kr> From: "junhyuk song" To: References: <43E8CCEAF148D211854C00805FA72E5807019865@rhqnneex1.corp.bam.com> Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt Date: Fri, 29 Jun 2001 15:11:25 +0900 Organization: cdma2000 system MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f5T6AWdP017714 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Chris, Thank you for giving us very long insightful comments, it took me a couple of hours to read it through. I agree with you some of your comments. Actually I myself believe distributing key by IKE like "key material" mechanism of draft-ietf-mobileip-aaa-keys-06.txt is the best security solution. Because in the security point of view, it gives master authority to AAA, and MN and any other entity, doesn't really have to care about KEY stuff. What we prpoposed is the interim solution, before we are eventually able to use such new Mobile IP extensions and DIAMETER. We will make necessary changes to our upcoming revision. So meanwhile, please read my comment below. ----- Original Message ----- From: "Carroll, Christopher X" To: Cc: "Flynn, Gerry J" Sent: Friday, June 29, 2001 2:18 AM Subject: Re: [mobile-ip] Comments on draft-song-mobile-ipv4-auth-secgeneration-00.txt > Hi Junhyuk, Dongkie, Chae Yong, and Raymond, > > I have the following comments regarding your draft MIPv4 key generation > proposal: > > Your proposal utilizes a Key Agreement protocol which is similar to the > methods used in TIA TR-45 and GSM cellular telephone networks to create > SESSION keys for privacy and authentication. Also, Bootstrapping the root > key (MN-AAA key, A-key, or GSM K key) is a difficult problem, i.e., > distributing secret keys to millions of handsets must be done securely and > efficiently. GSM / 3GPP distributes keys via SIMs (smart cards), while TIA > TR-45 / 3GPP2 primarily utilizes manufacturer pre-load and an out-of-band > distribution network to populate the network's HLR/AC (equivalent to AAA). I agree. > However, in those networks, the root key (A-key or GSM K key) is never > updated/modified by the visited network. The root keys for these networks > are jealously guarded by the Home Service provider. I suspect the MIPv4 > service providers will want to protect the MN-AAA and MN-HA keys to the same > degree. Unfortunately, your proposal enables a potentially devastating > Denial-of-Service attack in which a Rogue FA creates a mis-synchronization > of the MN-AAA and MN-HA keys between the MN and home network (AAA and HA). > Even if every FA acts properly, a hacker can create his own FA that > continuously initiates MN-AAA and MN-HA key updates with any MN within it's > vacinity. One device, strategically placed at an airport or in the center > of a city, could change the root keys in thousands of MNs. How will the > service provider re-syncronize the MN-AAA or MN-HA key? Perhaps by the > expensive process of manually re-loading the keys or distributing new smart > cards. Perhaps the user could log onto a protected (SSL) website and > download new keys (if they're allowed access). The master MN-AAA shared key never change in our Internet Draft. Only the session MN-AAA shared key is dynamically generated based on FAC. Speaking of DOS attack, are you implying that FA could do the DoS attack to HA with junk MN-AAA or MN-HA key? I believe it is the native problem that exist unless enforcing FA-HA securecy. In your example you mentioned that someone could change the root MN-AAA key in the airport, We DO NOT CHANGE initial MN-AAA key. We just update the it with new one. We always refer the intial MN-AAA key to create new one. Only each MN and each HA just remember the new key, it should always store the initial key. If someone failed to sync with AAA, the others could still have their MN-AAA key. All MN-AAA keys could be different. The Initial MN-AAA key is still intact. > Your proposed MN-AAA key chaining is inherently susceptable to > synchronization problems between the MN and AAA. Even the 3GPP AKA protocol > has elaborate procedures for re-synchronization of sequence numbers. How do > you propose to re-synchronize MN-AAA keys when there's a mismatch? How > would the network know whether a fraudulent access attempt or MN-AAA key > mismatch occurred? There is no synchronization problems between MN and AAA, because AAA alway create the session MN-AAA shared key based on Master MN-AAA shared key and FAC > One possible solution to this problem could be to use a Mutual > Authentication scheme between the MN and FA (or between the MN and AAA) to > ensure that the MN only updates these keys with a valid FA - however, this > may be impractical because the MN and FA must share a common secret in the > first place (Chicken-before-the-egg problem). Let's not talk about Public > key because MNs may not have the processing power to use Certificates and > service providers may not have the expertise to deal with PKI. I agree MN-FA is not practical at all. > The MN-AAAh key appears to be the root key for MIPv4 in which a > Radius/Diameter AAA server is used. It appears that the MN-AAAh key is > intended to be a subscription lifetime key (like the A-key and K in > TR-45/3GPP2 and GSM/3GPP networks). It is dangerous to allow a visited > system to update such a key during the subscription lifetime - such a > procedure should be initiate and controlled by the home system (AAAh). > (Note: your root key update procedure doesn't even enable secure recovery if > the MN-AAA key data base were compromised because the hacker/criminal will > only need to intercept the FAC to generate the new MN-AAA key). First 3GPP2 does not enforce any life time for MN-AAA key what so ever. And once again, the master MN-AAAH key never updated, it only used for creating session MN-AAA key. (Note: Hacker will not be able to compromise session MN-AAA key by FAC. This is simply because our solution has the same security assumption of MN-AAA authentication. In other words, even if Hacker intercept FAC to derive MN-HA shared key or even MN-AAA shared key, it costs the same amount of money and time to compromise MN-AAA shared key used in MN-AAA athenticator. If so it can be compromised anyway, it is same to MN-AAA authentication. ) > The MN-HA key may not be a subscription lifetime key, but it could be. > However, MN-HA key generation can be efficiently performed based on the > MN-AAA key which implies that AAAh must be involved in the process. Your > Dynamic / session generation of the MN-HA key appears inefficient from a > key management perspective because the AAAh must generate and distribute a > new MN-HA key for every system access. In the draft Perkins/Calhoun 06 > proposal, a new MN-HA key is generated only when necessary. Thus, even when > dynamic HA assignment occurs, the AAAh generates and distributes the new > MN-HA key for the new HA. It also issues the MN-HA key update to the MN. > It appears that the draft 06 proposal could allow the AAAh (and MN) to > manage the MN-HA keys for multiple HA simultaneously. The MN simply needs a > queue in which to store the different MN-HA keys or the AAAh could update > one MN-HA key during each dynamic HA assignment. From my perspective the > current Perkins/Calhoun proposal reduces the amount of MN-HA key generation > and distribution while maintaining the proper security. Speaking of key lifetime and key management perspective, we are working on the next revision. Our new revision has better Key management than current Internet Draft. In a nutshell, MN and AAAH has pre-fixed MN-HA shared key life time, and the lifetime will be sent with MN-HA shared key to HA by AAA message. So, when MN generates MN-HA shared key, MN will timestamp it. That timesamp is the same timestamp used to RRQ Identification. HA and AAA can derive the life time of MN-HA out of timestamp and the pre-fixed lifetime from AAA message. Key life time and key management perspective, we are working on the next revision. Well, I thought we are talking about our Internet Draft, but since you keep specifically refering to other Internet Draft. Let me compare our darft and draft-ietf-mobileip-aaa-keys-06.txt. Our solution works better for RADIUS based AAA in terms of DOS attack. The problem I have for draft-ietf-mobileip-aaa-keys-06.txt is that it only may works for DIAMETER based AAA. For example, it lets MN to send RRQ with MN-HA authenticator made "0" MN-HA shared key. So upon receiving of RRQ, HA must ask AAAH and fetch "Key Material" and "MN-HA shared key". And then HA will made binding table, other necessary processing, and made RRP with MN-HA Authenticator with newly assigned MN-HA shared key. But problem is HA does all of this work with no knowledge of whether MN is legimate or not, since it didn't perform MN-HA authentication. And it does not require or enforce FA-HA authentication. Someone, may argue that since there is MN-HA shared key was found in AAAH, it means that it is legimate RRQ, but that key may be supposed to be given to some other HA. That means that solution is vulnerable to DoS attack too. > It is likely most efficient to generate the MN-FA key as a session key > because the MN may interact with countless FAs (impractical for MN to store > MN-FA key for all FAs). In fact, I proposed a similar procedure to the > 3GPP2 TSG-P Subcommittee several months ago. However, dynamic generation of > the MN-FA key based on the FAC may not be significantly more efficeint than > having the MN-FA generated based on randomness provided by the AAAh. I agree, the randomness generated by the AAAh will be more secure, but I cannot agree with you on the 3GPP2 TSG-P network case. Becuase the FAC is 128 bit, randomness provided by PDSN. And it depends on the Random number generator of PDSN, it is supposed to be unique in each RRQ. RFC3012, state that if it is not unique number for the user, it will simply discard it. > I have a cryptographic concern with your method of generating a new MN-AAA > key based on the previous MN-AAA key. This key generation chaining may be > vulnerable to some type of cryptanalysis. Once again, we are not proposing to generate new MN-AAA master key, it is session MN-AAA key. And if it can be compromised then, the MN-AAA authenticator has the same security concern. I think the cryptocgraphic concern about the cryptanylysis should be resolved by some other context, but it is out of boundary of this document(In my undertanding, all plain-text form of AAA access request/response messages are vulnerable to cryptanaysis what you refering to) > In general, your proposed key generation scheme appears unacceptable because > it may expose MIPv4 networks to a devastating Denial-of-Service attack. > Like many security schemes that rely on synchronization, your key generation > scheme appears too unstable to be reliable. However, I do beleive that your > MN-FA key generation proposal has some merit. I am not sure what DOS attack you are implying to. Other internet draft has the same DOS issue in case of RADIUS based AAA. It could be solved only by using the FA-HA authentication. And, Please don't say "unacceptable" you haven't seen our revision yet. Regards, JH SONG, CY Chong > regards, > > chris > > ********************************************************************** > Christopher Carroll Office: 508-330-3401 > Senior Member Technical Staff fax: 508-330-3403 > Verizon Wireless cellular: 781-424-4131 > Chair TR-45 Adhoc Authentication Group > email: christopher.carroll@verizonwireless.com > ********************************************************************** > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 29 07:37:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20226 for ; Fri, 29 Jun 2001 07:37:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28275; Fri, 29 Jun 2001 05:38:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29741; Fri, 29 Jun 2001 04:38:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TBbAdP018108 for ; Fri, 29 Jun 2001 04:37:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TBbA8O018107 for mobile-ip-dist; Fri, 29 Jun 2001 04:37:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TBb7dP018100 for ; Fri, 29 Jun 2001 04:37:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15601 for ; Fri, 29 Jun 2001 04:37:16 -0700 (PDT) Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07654 for ; Fri, 29 Jun 2001 05:38:13 -0600 (MDT) Received: from haskins.ee.surrey.ac.uk ([131.227.89.14] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 15FwaE-0001kr-00 for mobile-ip@sunroof.eng.sun.com; Fri, 29 Jun 2001 12:37:10 +0100 Received: from eep2kc (helo=localhost) by haskins.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 15FwaA-0002fY-00 for mobile-ip@sunroof.eng.sun.com; Fri, 29 Jun 2001 12:37:06 +0100 Date: Fri, 29 Jun 2001 12:37:06 +0100 (BST) From: Karann Chew X-Sender: eep2kc@haskins.ee.surrey.ac.uk To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] A question on draft-ietf-mobileip-hmipv6-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *15FwaE-0001kr-00*w5KNSnj6nIU* http://duncanthrax.net/exiscan/ Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I have a question on the HMIPv6 draft. Please help. In Section 8 "Comparison Btwn HMIPv6 Modes of Operation" Paragraph #2 mentions that for the extended mode, MAP will _decapsulate_ the packets and the _encapsulate_ them again to the MN. Why decap and encap? For MIPv6, isn't Routing Header is used instead? Regards, Karann On Mon, 30 Apr 2001 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. > > Title : Hierarchical MIPv6 mobility management > Author(s) : H. Soliman, C. Castelluccia, K. Malki, L. Bellier > Filename : draft-ietf-mobileip-hmipv6-03.txt > Pages : 27 > Date : 27-Apr-01 > > This draft introduces some extensions for MIPv6 and neighbour > discovery to allow for the introduction of a hierarchical MIPv6 > mobility management model. The proposed hierarchical mobility > management for MIPv6 will reduce the amount of signalling to CNs and > the HA and may also improve the performance of MIPv6 in terms of > handoff speed. Moreover, HMIPv6 is well-suited to implement access > control and handoffs between different access technologies. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-03.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mobileip-hmipv6-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mobileip-hmipv6-03.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 29 07:39:01 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21083 for ; Fri, 29 Jun 2001 07:39:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08322; Fri, 29 Jun 2001 04:39:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29845; Fri, 29 Jun 2001 04:39:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TBcldP018136 for ; Fri, 29 Jun 2001 04:38:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TBclkM018135 for mobile-ip-dist; Fri, 29 Jun 2001 04:38:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TBcidP018128 for ; Fri, 29 Jun 2001 04:38:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21673 for ; Fri, 29 Jun 2001 04:38:53 -0700 (PDT) From: georgeafansev@yahoo.com Received: from mta491.mail.yahoo.com (mta491.mail.yahoo.com [216.136.130.199]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA28471 for ; Fri, 29 Jun 2001 05:38:51 -0600 (MDT) Message-ID: <20010629113851.56448.qmail@mta491.mail.yahoo.com> Date: Fri, 29 Jun 2001 04:38:51 -0700 (PDT) Subject: [mobile-ip] Yahoo! Auto Response To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: George will be ooto without email access until July 7th... -------------------- Original Message: Received: from mercury.Sun.COM (192.9.25.1) by mta491.mail.yahoo.com with SMTP; 29 Jun 2001 04:38:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08070; Fri, 29 Jun 2001 04:38:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29776; Fri, 29 Jun 2001 04:38:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TBbAdP018108 for ; Fri, 29 Jun 2001 04:37:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TBbA8O018107 for mobile-ip-dist; Fri, 29 Jun 2001 04:37:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmai _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 29 07:51:51 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00050 for ; Fri, 29 Jun 2001 07:51:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11127; Fri, 29 Jun 2001 04:52:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01147; Fri, 29 Jun 2001 04:52:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TBpXdP018257 for ; Fri, 29 Jun 2001 04:51:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TBpXHC018256 for mobile-ip-dist; Fri, 29 Jun 2001 04:51:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TBpTdP018249 for ; Fri, 29 Jun 2001 04:51:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA26075 for ; Fri, 29 Jun 2001 04:51:38 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA21940 for ; Fri, 29 Jun 2001 04:51:28 -0700 (PDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5TBpQO09915 for ; Fri, 29 Jun 2001 13:51:26 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jun 29 13:51:25 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 13:45:42 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008A87@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] A question on draft-ietf-mobileip-hmipv6-03.txt Date: Fri, 29 Jun 2001 13:51:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Karann, There are two possibilities for receiving a packet at the MAP: 1. The packet was sent from the CN directly to the CoA in the Binding Cache. In extended mode this means the MAP's address. In this case the packet will contain a routing header which will be processed by the MAP. The MAP will see that the final destination is the MN's Home address, do a Binding Cache lookup and tunnel it to the MN's LCoA (Just like a HA would) 2. The packet was encapsulated by the HA and forwarded to the MN's CoA. This is the case you're referring to. Since the MN's CoA in the HA's binding cache is the MAP address (for Extended mode), The MAP will receive the packet addressed to itself, decapsulate it (normal IP processing for a tunnelled packet), and then find that the real destination is the MN's Home address and follow the same steps above. Hence it will encapsulate and forward to LCoA of the MN. Cheers, Hesham > -----Original Message----- > From: Karann Chew [SMTP:k.chew@eim.surrey.ac.uk] > Sent: Friday, 29 June 2001 1:37 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] A question on draft-ietf-mobileip-hmipv6-03.txt > > Hi, > > I have a question on the HMIPv6 draft. Please help. > > In Section 8 "Comparison Btwn HMIPv6 Modes of Operation" > Paragraph #2 mentions that for the extended mode, MAP will _decapsulate_ > the packets and the _encapsulate_ them again to the MN. > > Why decap and encap? For MIPv6, isn't Routing Header is used instead? > > Regards, > Karann > > > > > > On Mon, 30 Apr 2001 Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. > > > > Title : Hierarchical MIPv6 mobility management > > Author(s) : H. Soliman, C. Castelluccia, K. Malki, L. Bellier > > Filename : draft-ietf-mobileip-hmipv6-03.txt > > Pages : 27 > > Date : 27-Apr-01 > > > > This draft introduces some extensions for MIPv6 and neighbour > > discovery to allow for the introduction of a hierarchical MIPv6 > > mobility management model. The proposed hierarchical mobility > > management for MIPv6 will reduce the amount of signalling to CNs and > > the HA and may also improve the performance of MIPv6 in terms of > > handoff speed. Moreover, HMIPv6 is well-suited to implement access > > control and handoffs between different access technologies. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-03.txt > > > > Internet-Drafts are also available by anonymous FTP. Login with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-mobileip-hmipv6-03.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-mobileip-hmipv6-03.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader> > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 29 13:51:51 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20802 for ; Fri, 29 Jun 2001 13:51:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01529; Fri, 29 Jun 2001 11:52:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28206; Fri, 29 Jun 2001 10:50:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5THo1dP018748 for ; Fri, 29 Jun 2001 10:50:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5THo0hX018747 for mobile-ip-dist; Fri, 29 Jun 2001 10:50:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from heliopolis.eng.sun.com (heliopolis.Eng.Sun.COM [152.70.1.39]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5THnvdP018740 for ; Fri, 29 Jun 2001 10:49:57 -0700 (PDT) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA11763 for ; Fri, 29 Jun 2001 10:50:07 -0700 (PDT) Message-Id: <200106291750.KAA11763@heliopolis.eng.sun.com> Date: Fri, 29 Jun 2001 10:50:07 -0700 (PDT) From: James Kempf Subject: [mobile-ip] Extension proposal for FMIPv6 draft To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 16xvx9/9dzPIxK5WBqIbug== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, A draft was just submitted to the IETF drafts editor with a proposal for an extension to FMIPv6. The extension is designed for zero L3 latency, to accommodate fast vehicular movement and to reduce the probability of human perceptable artifacts in real time traffic. The proposal is similar to the POST-REG technique for FMIPv4. An abstract is attached below. There should be a copy of the draft at http://www.diameter.org/draft-kempf-beth-ipv6-00.txt shortly, if you would like to get a jump on the drafts editor. jak -------------------------------------------------------------------------------- Abstract This document discusses an extension to the Fast Mobile IPv6 handover protocol described in draft-ietf-mobileip-fastmipv6-01.txt that reduces the amount of L3 latency in Mobile IPv6 handover to zero. The protocol uses bi-directional edge tunnels and deferred Care of Address establishment to eliminate L3 radio traffic during handover, allowing a Mobile Node to move rapidly across a series of subnets without having to change its Care of Address while a real time session is in progress. Later, when the real time session has completed, the Mobile Node can use the Fast Mobile IPv6 handover protocol or the original Mobile IPv6 handover protocol to establish a Care of Address. An added benefit of the protocol is that header compression context for real time traffic can be transferred from the old Access Router to the new and reused unchanged, since the headers associated with the traffic to and from the MN over the air do not change. The design stems from a different series of tradeoffs than those that motivated the Fast Mobile IPv6 protocol. From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 29 14:07:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21439 for ; Fri, 29 Jun 2001 14:07:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14442; Fri, 29 Jun 2001 12:07:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02722; Fri, 29 Jun 2001 11:07:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TI6gdP018805 for ; Fri, 29 Jun 2001 11:06:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TI6gXd018804 for mobile-ip-dist; Fri, 29 Jun 2001 11:06:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TI6cdP018797 for ; Fri, 29 Jun 2001 11:06:38 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08557 for ; Fri, 29 Jun 2001 11:06:47 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA02995 for ; Fri, 29 Jun 2001 11:06:39 -0700 (PDT) Received: (qmail 27198 invoked by uid 500); 29 Jun 2001 17:55:11 -0000 Date: Fri, 29 Jun 2001 10:55:11 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Extension proposal for FMIPv6 draft Message-ID: <20010629105511.I25503@charizard.diameter.org> References: <200106291750.KAA11763@heliopolis.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106291750.KAA11763@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Fri, Jun 29, 2001 at 10:50:07AM -0700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Fri, Jun 29, 2001 at 10:50:07AM -0700, James Kempf wrote: > Folks, > > A draft was just submitted to the IETF drafts editor with a proposal for > an extension to FMIPv6. The extension is designed for zero L3 latency, > to accommodate fast vehicular movement and to reduce the probability > of human perceptable artifacts in real time traffic. The proposal > is similar to the POST-REG technique for FMIPv4. An abstract is attached > below. > > There should be a copy of the draft at > http://www.diameter.org/draft-kempf-beth-ipv6-00.txt shortly, if you > would like to get a jump on the drafts editor. The draft is now available on the web site for your perusal. Thanks, PatC From owner-mobile-ip@sunroof.eng.sun.com Fri Jun 29 18:53:08 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26781 for ; Fri, 29 Jun 2001 18:53:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12444; Tue, 26 Jun 2001 10:53:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22817; Tue, 26 Jun 2001 10:53:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHp6dP009919 for ; Tue, 26 Jun 2001 10:51:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QHp68S009918 for mobile-ip-dist; Tue, 26 Jun 2001 10:51:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QHp4dP009911 for ; Tue, 26 Jun 2001 10:51:04 -0700 (PDT) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12780 for ; Tue, 26 Jun 2001 13:51:13 -0400 (EDT) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA17163 for mobile-ip@sunroof.eng.sun.com; Tue, 26 Jun 2001 13:51:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9fUdP007834 for ; Tue, 26 Jun 2001 02:41:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27977 for ; Tue, 26 Jun 2001 02:41:41 -0700 (PDT) Received: from ultra5.unile.it (ultra5.unile.it [193.204.77.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16822 for ; Tue, 26 Jun 2001 02:41:40 -0700 (PDT) Received: from Snoopy ([193.204.77.105]) by ultra5.unile.it (8.9.3+Sun/8.9.1) with SMTP id LAA14152; Tue, 26 Jun 2001 11:19:39 +0100 (WET DST) Message-ID: <006201c0fe21$ac6eeae0$694dccc1@unile.it> From: "Luigi Patrono" To: Subject: [mobile-ip] EXTENSION OF THE DEADLINE FOR Workshop on Future Wireless Communications Date: Tue, 26 Jun 2001 11:22:53 +0200 Organization: DII-Unile MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005D_01C0FE32.5759D9A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_005D_01C0FE32.5759D9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable EXTENSION OF THE DEADLINE FOR PAPER SUBMISSION TO Workshop on Future = Wireless Communications UNTIL JULY 10, 2001. =20 =20 CALL FOR PAPERS=20 SoftCOM 2001=20 IEEE International Conference on Software, Telecommunications=20 and Computer Networks =20 =20 Workshop on Future Wireless Communications October 09-12, 2001=20 Split, Dubrovnik (Croatia)=20 Ancona, Bari (Italy)=20 Workshop on Future Wireless Communications will be held aboard the=20 ship Marko Polo travelling on the route Split (Croatia) =20 Ancona (Italy) Bari (Italy) Dubrovnik (Croatia) in the frame of the 9 th International Conference on Software, Telecommunications=20 and Computer Networks SoftCOM 2001. The increasing popularity of wireless networks indicates that most of future networking structures will be based on wireless networking technologies (Satellite, Ad Hoc, UMTS, ..). Wireless communication=20 poses some problems that do not exist in wired networks, such as=20 limited resources and fading due to mobility. This has generated an=20 enormous interest for new communication protocols and enhanced=20 traffic/resource management mechanisms. This Workshop on Future Wireless Communications will cover both theoretical=20 and pratical aspects and will provide an opportunity for researchers=20 to meet and discuss aspects of their work in an informal setting.=20 Papers presenting new results in (but not limited to) the following = areas are invited: * Emerging Satellite Systems * Protocols for Ad Hoc Wireless Networks * Transport/Data Link Protocols for Mobile Satellite Communications * QoS in Wireless Networks * Heterogeneous Wireless Networks * Traffic & Resource Management in Satellite Networks * Integration between Wired and Wireless (Satellite, Ad Hoc,=20 UMTS,..) Networks * Services and Applications for Wireless Communications Each day of the conference the ship will be anchored in one of the ports = on the route, and overnight it will sail towards the next destination. = This provides participants with the opportunity to share ideas in = close=20 contact with their coleagues and to enjoy the pleasant and inspiring=20 ambience while visiting the ports along the beautiful Adriatic coast.=20 During the conference the car deck will serve as an exhibition arena = for=20 exhibitors of software and telecommunication products.=20 Schedule Complete manuscript to be received by July 10, 2001 Notification of acceptance mailed out by September 1, 2001=20 Camera-ready manuscript to be received by September 15, 2001 =20 =20 More information about the Conference including details on the = submission=20 process and authors kit are available on the website http://www.fesb.hr/SoftCOM=20 Workshop Chair: Mario De Blasi, University of Lecce, Italy (mario.deblasi@unile.it) Conference Secretary: Hrvoje Dujmic, University of Split, Croatia=20 (softcom@fesb.hr)=20 ------=_NextPart_000_005D_01C0FE32.5759D9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
EXTENSION OF THE DEADLINE FOR PAPER = SUBMISSION TO=20 Workshop on Future Wireless Communications UNTIL JULY = 10,=20 2001.
 
 
CALL FOR PAPERS

SoftCOM 2001 =
IEEE=20 International Conference on Software, Telecommunications
and = Computer=20 Networks 
      
Workshop on = Future=20 Wireless Communications

      October = 09-12,=20 2001
      Split, Dubrovnik (Croatia)=20
      Ancona, Bari (Italy)

Workshop = on=20 Future Wireless Communications will be held aboard the
  ship = Marko=20 Polo travelling on the route Split (Croatia) 
  Ancona=20 (Italy)  Bari (Italy)  Dubrovnik (Croatia) in the = frame
  of=20 the 9 th International Conference on Software, Telecommunications =
  and=20 Computer Networks  SoftCOM 2001.

The increasing popularity = of=20 wireless networks indicates that most
  of future networking = structures=20 will be based on wireless networking
  technologies (Satellite, = Ad Hoc,=20 UMTS, ..). Wireless communication
  poses some problems that do = not=20 exist in wired networks, such as
  limited resources and fading = due to=20 mobility. This has generated an
  enormous interest for new=20 communication protocols and enhanced
  traffic/resource = management=20 mechanisms.

This Workshop on Future Wireless Communications will = cover=20 both
theoretical
  and pratical aspects and will provide an=20 opportunity for researchers
  to meet and discuss aspects of = their work=20 in an informal setting.

Papers presenting new results in (but = not=20 limited to) the following areas
are invited:
    * = Emerging=20 Satellite Systems
    * Protocols for Ad Hoc Wireless=20 Networks
    * Transport/Data Link Protocols for = Mobile=20 Satellite Communications
    * QoS in Wireless=20 Networks
    * Heterogeneous Wireless=20 Networks
    * Traffic & Resource Management in = Satellite=20 Networks
    * Integration between Wired and Wireless=20 (Satellite, Ad Hoc,
      UMTS,..)=20 Networks
    * Services and Applications for Wireless=20 Communications

Each day of the conference the ship will be = anchored in=20 one of the ports
  on the route, and overnight it will sail = towards the=20 next destination.
  This provides participants with the = opportunity to=20 share ideas in close
  contact with their coleagues and to = enjoy the=20 pleasant and inspiring
  ambience while visiting the ports = along the=20 beautiful Adriatic coast.
  During the conference the car deck = will=20 serve as an exhibition arena for
  exhibitors of software and=20 telecommunication products.

Schedule
  Complete = manuscript to be=20 received by July 10, 2001
  Notification of = acceptance=20 mailed out by September 1, 2001
  Camera-ready manuscript to be = received by September 15, 2001 
     =
More=20 information about the Conference including details on the submission =
 =20 process and authors kit are available on the=20 website

       http://www.fesb.hr/SoftCOM=20

Workshop Chair: Mario De Blasi, University of Lecce,=20 Italy
          &nbs= p;    =20 (mario.deblasi@unile.it)
Conference=20 Secretary: Hrvoje Dujmic, University of Split, Croatia=20
           &nb= sp;         =20 (softcom@fesb.hr)=20

------=_NextPart_000_005D_01C0FE32.5759D9A0-- From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 30 18:09:29 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25932 for ; Sat, 30 Jun 2001 18:09:29 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15097; Sat, 30 Jun 2001 16:10:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27404; Sat, 30 Jun 2001 15:09:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5UM8NdP020959 for ; Sat, 30 Jun 2001 15:08:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5UM8Nsq020958 for mobile-ip-dist; Sat, 30 Jun 2001 15:08:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5UM8JdP020951 for ; Sat, 30 Jun 2001 15:08:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04900 for ; Sat, 30 Jun 2001 15:08:28 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA14820 for ; Sat, 30 Jun 2001 16:08:26 -0600 (MDT) Received: (qmail 5240 invoked by uid 500); 30 Jun 2001 21:56:56 -0000 Date: Sat, 30 Jun 2001 14:56:56 -0700 From: Pat Calhoun To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Last Call comments addressed on draft-ietf-mobileip-aaa-keys-06.txt Message-ID: <20010630145656.D5195@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: All, I have addressed the following comments in the next revision of the AAA keys draft. I do not believe that another WG last call is needed on this document, but I will let the chairs decide. Thanks, PatC >> >> Pat, sorry for the late comments, the draft looks alot better >now but there >> are some issues I'd like to address. >> >> Section 1. >> "2. If the mobile node does not have a Mobility Security Association >> with the foreign agent, it includes an MN-FA Key Request >> extension." >> >> suggested change: >> >> "2. If the mobile node does not have a Mobility Security Association >> with the foreign agent, it SHOULD include an MN-FA Key Request >> extension." I used MUST instead of SHOULD >> >> Section 1. >> "3. Similarly, if the mobile node does not have a Mobility Security >> Association with the home agent, it adds an MN-HA Key Request >> extension." >> >> suggested change >> "3. Similarly, if the mobile node does not have a Mobility Security >> Association with the home agent, it MUST add an MN-HA Key Request >> extension." > >ok, so far minor editorial changes. > >> Section 4. >> I can't find reference 12 (Registration Keys for Route >Optimization) but I >> can find the extension pointed to in reference 11 (Generalized Key >> Distribution Extensions for Mobile IP) >> >> suggested change is to remove ref 12 and use 11 instead. fixed. > >> >> Section 5. >> The "Unsolicited MN-HA Key Material From AAA Subtype" includes a >Lifetime, a >> Lifetime is also included in the "Genralized MN-HA Key Reply >Extension" (see >> ref 11), i.e. the lifetime in the subtype is redundant so I >suggest that it >> will be removed. > Correct. As it stands, both the gen-key and the aaa subtype included a lifetime field for the mn-ha. I have removed the lifetime in the mn-ha aaa subtype. This is now clean. >> Section 6 and 7. >> >> The "Generalized MN-FA Key Request Extension" and the >"Generalized MN-HA Key >> Request Extension" in ref 11 both include a Mobile Node SPI >which indicates >> which SPI the mobile node would like to use in its security >association with >> the respective node. In section 6 and 7 a subtype is introduced to these >> extensions which includes a SPI which the mobile node would like >to use in >> its security assocition with respecive node. I believe this is redundant >> information. >> >> Suggested change: Use the SPI in the "Generalized" extensions >and have the >> subtype data field be zero in length. Thus the subtype indicates >that it is >> a MN-?A Key Request from AAA Subtype and that it uses the SPI >indicated by >> the Mobile Node SPI in the Generalized Extension. > This was a problem as we ended up with two SPI fields. Both request subtypes now include no data, and just define the subtype value of 7. >> >> One last thing has to do with the reference section. Ref 11 is: >> "[11] C. Perkins and P. Calhoun. Generalized Key Distribution >> Extensions for Mobile IP (work in progress). >> draft-ietf-mobileip-gen-key-02.txt, March 2001." >> >> and I can't find the draft as wg document. However, I can find it as >> draft-perkins-mobileip-gen-key-03.txt. >> So can we make it a WG document? And does it need to be a RFC in >order to be >> referenced from the aaa-key doc, or is it possible for a RFC to >reference a >> draft? > >This is the issue that I brought up with the chairs and CharlieP. This is now being fixed, and the gen-key is being submitted as a WG document. Thanks, PatC ----- End forwarded message ----- From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 30 22:04:35 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28557 for ; Sat, 30 Jun 2001 22:04:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA13560; Sat, 30 Jun 2001 19:05:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13053; Sat, 30 Jun 2001 19:04:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6123JdP021117 for ; Sat, 30 Jun 2001 19:03:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6123J2u021116 for mobile-ip-dist; Sat, 30 Jun 2001 19:03:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6123FdP021109 for ; Sat, 30 Jun 2001 19:03:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23259 for ; Sat, 30 Jun 2001 19:03:23 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28340 for ; Sat, 30 Jun 2001 19:03:23 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA10682; Sat, 30 Jun 2001 19:03:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6123Mk25633; Sat, 30 Jun 2001 19:03:22 -0700 X-mProtect: Sat, 30 Jun 2001 19:03:22 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdYCNy7I; Sat, 30 Jun 2001 19:03:20 PDT Message-ID: <3B3E84E8.CD285EB@iprg.nokia.com> Date: Sat, 30 Jun 2001 19:03:20 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" CC: mobile-ip@sunroof.eng.sun.com, "'T.J. Kniveton'" Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D69509ADC@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Ken, I'm trying to finish up something that can be sent out as the next revision... >>> Section 5.8 ICMP Mobile Prefix Solicitation Message Format >>> >>> Will the Destination Option extension header with a >>> Home Address option normally be included? The exception >>> would be during mobile node initialization when the >>> mobile node does not have a home address yet. >> >> Agreed. I reckon this should just follow normal rules >> for sending packets. Does it need to be stated explicitly? > > I think it needs to be stated somewhere in the spec. Not > sure where it makes most sense though. O.K. I am open to suggestion. >>> >>> This message header should include a reserved >>> field to align the remaining prefix options on >>> a 64-bit boundary. >> >> Here I am not so sure. The Prefix Information option >> doesn't start with a 64-bit field, and I didn't find >> any specification that required an _option_ to be >> aligned in a certain way -- only that the data fields >> in the option should be aligned in a certain way. >> I can see both sides of the argument, and the picture >> at the beginning of section 4.6 of RFC 2461 doesn't >> appear to mandate the restriction. > > There is no explicitly stated restriction, but I think > all the headers are constructed such that long fields > like IPv6 addresses land on proper byte-boundaries. > IMHO, its important we try to maintain this alignment > convention. There seems to be arguments both ways. Would it be O.K. to await comments from other folks in the working group? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 30 22:32:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29572 for ; Sat, 30 Jun 2001 22:32:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27717; Sat, 30 Jun 2001 20:32:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17321; Sat, 30 Jun 2001 19:32:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f612VsdP021210 for ; Sat, 30 Jun 2001 19:31:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f612VrAJ021209 for mobile-ip-dist; Sat, 30 Jun 2001 19:31:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f612VodP021202 for ; Sat, 30 Jun 2001 19:31:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17245 for ; Sat, 30 Jun 2001 19:31:59 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27506 for ; Sat, 30 Jun 2001 20:31:57 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA11631; Sat, 30 Jun 2001 19:31:58 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f612VwC30338; Sat, 30 Jun 2001 19:31:58 -0700 X-mProtect: Sat, 30 Jun 2001 19:31:58 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdrzxVNF; Sat, 30 Jun 2001 19:31:56 PDT Message-ID: <3B3E8B9C.D9485EC2@iprg.nokia.com> Date: Sat, 30 Jun 2001 19:31:56 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Powell, Ken" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-ietf-mobileip-ipv6-13 comments References: <88BD5A70CA8BFA4CA15D0ED053E49D69509A98@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > Section 9.6 Tunneling Intercepted Packets to a Mobile Node > > > > > >> Tunneling of multicast packets to a mobile node follows similar > > >> limitations to those defined above for unicast packets addressed to > > >> the mobile node's link-local and site-local addresses. Multicast > > >> packets addressed to a multicast address with link-local scope [9], > > >> to which the mobile node is subscribed, MUST NOT be tunneled > > >> to the mobile node; such packets SHOULD be silently discarded > > >> (after delivering to other local multicast recipients). Multicast > > >> packets addressed to a multicast address with scope larger > > >> than link-local but smaller than global (e.g., site-local and > > >> organization-local) [9], to which the mobile node is subscribed, > > >> SHOULD be tunneled to the mobile node by default, but this behavior > > >> MUST be configurable to disable it; this default behavior might > > >> change at some point in the future as the definition of these > > >> scopes become better defined in IPv6. > > > > > > This spec does not explain how a home agent determines what > > > multicast addresses to forward to a mobile node. Host systems > > > normally send Multicast Listener Discovery (MLD) messages to > > > attached routers to join/leave multicast groups. The rules > > > for doing this between mobile node and home agent are undefined. > > > > Not really...? Why can't the tunneled packets use the same rule > > as in other cases. In other words, the mobile node should use > > a Home Address destination option here, but that would be implicit. > > It would be a mistake for the Mobile IPv6 specification to go specify > > the inclusion of the Home Address option for _every_ possible > > application between endpoints. Tunneling is not essentially > > different here, as far as I can tell. > > The problem I have is that the term "tunnel" is extremely > ambiguous. I can envision multiple ways to set up tunnels > between a mobile node and its home agent. For example, I > get the impression from your statement here that you were > thinking of creating a bi-directional tunnel between the > mobile node's home address and the home agent's address. > I always assumed you were intending to create the tunnel > using the mobile node's care-of address for the tunnel > endpoint as is done in section 9.6. Maybe the tunnel does not need a lot of setup. Is it O.K. to use the home address? The only reason for using the care-of address would be if the mobile node doesn't have a valid home address, it seems to me, except maybe for some special- case protocol that I don't know about. >>> The text above and in section 10.19 indicates a bi-directional >>> tunnel could be used to support this. There is no clear definition >>> of how to set up such a tunnel. What addresses are used for >>> tunnel source and destination? Would the tunnel have its own >>> link local and global interface addresses? Will it carry MLD >>> traffic specifically for the mobile node? What other traffic >>> should such a tunnel between a mobile node and the home agent >>> carry? >> >> I don't think there is a problem here. The tunnel should be set >> up just like any tunnel would be set up. The outer header should >> have the natural IP addresses. > > What are the tunnel endpoints? The home agent address is one, > but do we use the mobile node's home address or care-of address > for the other? How about the home address? >> A home address destination option >> would be used as normal. The inner header should have the same >> field values as if the mobile node were on its home network. > > I agree with this part, and think it should be stated. Again, if the _general_ packet from a mobile node to the home agent uses the Home Address destination option, and there isn't any specific reason why these packets are different, then I am not yet understanding why it has to be stated for these particular cases, in addition to the implicit specification which would be inferred from the general case. But if you can suggest some natural text, I could go ahead and include it as long as people agree that it is O.K. to do so. >> Policy determination for tunnel use is, I reckon, outside the scope >> of the Mobile IPv6 specification. Otherwise, we would have to do >> it for every protocol, not just MLD. That could be bad, and seems >> like a major potential source for specification errors. > > I thought MLD was critical to supporting multicast traffic > on a host in much the same way as Router Solicitation/ > Advertisements are critical to unicast traffic support. > Therefore, I think MLD is a special case that needs to > be mentioned how it fits. It could be obvious depending > on how the tunnel setup is defined. But if the special case just works like the general case, then the special case is not special in this particular regard. ... >>> + It may be possible to tunnel multicast traffic between >>> + a mobile node and it's home agent to extend the range of >>> + a multicast zone. The rules for setting up such tunnels and >>> + for identifying which traffic to forward is beyond the scope >>> + of this spec. >> >> As of now, I don't believe this is the right technical direction; >> I have left the current specification as is. > > In that case, I think more detail will be needed in this section. > > I envision the mobile node and the home agent set up bi-directional > tunnels per RFC 2473 between the mobile node's home address and the > home agent's address to carry multicast traffic. The tunnel pseudo > interfaces must have link local addresses to support MLD (RFC 2710) > traffic between the home agent and the mobile node. Global addresses > on the tunnel pseudo-interfaces are not necessary. But then we might start to import more of RFC 2710 into the Mobile IPv6 specification. That is scary. > This sounds like quite a bit of overhead in the home agent > for a feature that may not be used often. Would it make sense > to add a flag to the binding update request/response options > to request support for such a tunnel? This might give home > agents an option to save memory when the overhead is not > needed. Maybe this kind of tunneling doesn't automatically require tunnel setup beforehand. What if the mobile node sends a tunneled packet to the home agent without any setup? Then the home agent would have to check to see whether it was legal to receive a packet. Any required setup could be done at that time, it seems to me. > Section 9.7 mentions that the home agent MUST support decapsulating > reverse tunneled packets. What is the tunnel source address in this > case, the mobile node's care-of address or its home address? Will > it use the same bi-directional configured tunnel that is used to > support multicast traffic? How about using the home address? > > > Section 10.19 Routing Multicast Packets > > > > > > > Alternatively, a mobile node MAY join multicast groups via a > > > > bi-directional tunnel to its home agent. The mobile > > node tunnels its > > > > multicast group membership control packets to its home > > agent, and the > > > > home agent forwards multicast packets down the tunnel to > > the mobile > > > > node. > > > > > > > > A mobile node that wishes to send packets to a multicast group > > > > also has two options: (1) send directly on the foreign > > link being > > > > visited; or (2) send via a tunnel to its home agent. Because > > > > multicast routing in general depends upon the Source > > Address used in > > > > the IPv6 header of the multicast packet, a mobile node > > that tunnels a > > > > multicast packet to its home agent MUST use its home > > address as the > > > > IPv6 Source Address of the inner multicast packet. > > > > > > Same concern with multicast messages as for section 9.6. We think > > > this spec should describe option (1) and leave option > > (2) as beyond > > > scope for now. > > > > Well, I hope we can keep the specification. It's likely to work well > > enough for Proposed Standard, and deployment and experience > > are clearly > > needed. > > I'm beginning to agree, just need to nail down what the tunnel > endpoints are, and that the tunnel pseudo-interfaces must be > configured with link-local addresses to carry MLD traffic. Also > be clear that we are using bi-directional tunnels as defined in > RFC 2473. Do you still think so after the discussion up until now? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Jun 30 22:45:21 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29635 for ; Sat, 30 Jun 2001 22:45:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00321; Sat, 30 Jun 2001 20:45:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17938; Sat, 30 Jun 2001 19:45:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f612j0dP021270 for ; Sat, 30 Jun 2001 19:45:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f612j0eB021269 for mobile-ip-dist; Sat, 30 Jun 2001 19:45:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f612iudP021260 for ; Sat, 30 Jun 2001 19:44:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06689 for ; Sat, 30 Jun 2001 19:45:05 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00150 for ; Sat, 30 Jun 2001 20:45:03 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA11940; Sat, 30 Jun 2001 19:45:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f612j4N00757; Sat, 30 Jun 2001 19:45:04 -0700 X-mProtect: Sat, 30 Jun 2001 19:45:04 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdXjX7Sy; Sat, 30 Jun 2001 19:45:01 PDT Message-ID: <3B3E8EAD.121266F2@iprg.nokia.com> Date: Sat, 30 Jun 2001 19:45:01 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "'T.J. Kniveton'" , Ken Powell CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile Prefix Advertisements References: <88BD5A70CA8BFA4CA15D0ED053E49D69509AE8@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Powell, Ken" wrote: > >> -----Original Message----- >> From: T.J. Kniveton [mailto:TJ@Kniveton.com] >> Sent: Tuesday, June 26, 2001 12:19 PM >> To: Powell, Ken; Perkins Charles (IPRG/MtView) >> Cc: mobile-ip@sunroof.eng.sun.com >> Subject: Re: [mobile-ip] Mobile Prefix Advertisements >> >> >> "Powell, Ken" wrote: >>> >>> I think we have a serious issue here. ...... >>>> No, my wording was bad. I was trying to say that the intention >>>> was _not_ to use addresses from routers that are not home agents, >>>> but since I was in a hurry I didn't put enough text around it to >>>> be clear. >>> >>> I disagree. When a mobile node is home, it will autoconfigure >>> to all prefixes advertised by any router. When the mobile node >>> moves off-link, the home agent will need to intercept all >>> traffic for the mobile node, otherwise you will get dropped >>> connections. The reason for creating the aggregate list >>> was to handle this problem. > > BTW, the statement above is the part that is critical we > fix and handle consistently. The rest was personal preference. I have clarified the wording. However, your statement about the reason for creating the aggregate list doesn't match my recollection, which is admittedly a bit fuzzy. I thought the aggregate list was created so that the home agent could deliver prefixes to the mobile node that supported mobility. >>> While playing in the lab, I discovered I could set up a home >>> agent that doesn't set the A or L bits on any prefixes. The >>> mobile node autoconfigures to another router on the home net. >>> I realized this could be a very handy feature, particularly >>> in cases where the network administrator doesn't want the >>> home agent to effect addresses configured on the non-mobile >>> nodes. >> >> Well first of all, if the home agent is willing to serve home >> addresses >> that are on prefixes it doesn't advertise (which it probably >> would be), >> then there is no issue with a mobile node leaving the home network - >> that will work fine regardless of what's in the MPA. > > Agreed. I believe its mandatory the home agent be able > to serve addresses it doesn't advertise, particularly for > cases like DHCP served addresses. In most such cases, > I would expect the mobile node to issue binding updates > with a zero prefix length. Ooohhh... but, still, the home agent wouldn't support any such address that doesn't live on the subnet. If DHCPv6 hands out addresses to a mobile node that don't live on the subnet, then I think it's just a plain error. There has to be some restriction here, I'm sure. >> It doesn't seem great to require every HA to advertise all of the >> prefixes on its link to all MNs (and my intention was to pare the >> aggregate list by removing unnecessary prefixes). Perhaps we >> could reach >> a compromise of a router rule under "should": add received >> prefixes that >> have the A bit set to the aggregate list. I would also >> suggest that the >> rule should specify that the prefixes should be added only if they do >> *not* have the L bit set. > > I don't think it matters what the L bit is set to. All the > L bit does is indicate to a host that it should treat the > a prefix as On-Link when sending messages. When a destination > of any scope is on-link, the host will use Neighbor Discovery > to find the destination instead of sending the message to > router. If we go for the rule of only aggregating prefixes that have the 'H' bit set, then wouldn't that express the semantics that the mobile node only gets prefixes that support mobility? >> As far as the rule that the mobile should be able to autoconfigure at >> least all of the prefixes (which are served by HAs) that it >> would on the >> home network, I think that still holds: the prefix still needs to be >> served by the HA for it to be relevant while roaming, even if >> the prefix >> is not explicitly advertised by the HA on the home link. > > I think this is the key point. The way I see it, the mobile > node can autoconfigure a set of home network addresses while > at home or while roaming. These sets of addresses must match > exactly to each other and to the addresses that the home > agent can serve. I define "serve" to mean the set of addresses > that a home agent can intercept and forward to the mobile node. > > Another way we could compromise is to introduce > a concept of home prefixes vs other prefixes on the home > network. Home prefixes could be prefixes advertised by > home agents. Other prefixes are prefixes not advertised > by home agents. A mobile node could autoconfigure to > any prefix while on the home subnet, but would "Prefer" > to use home prefixes only. The other prefixes would be > expected to come and go the same way care-of addresses > do now. I really thought that we already had made this determination, and that we were only supposed to advertise home prefixes. If I am missing something here, please let me know! It's been a long weekend already! Regards, Charlie P.