From mip4-bounces@ietf.org Thu Feb 01 14:36:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HChjo-00028y-0T; Thu, 01 Feb 2007 14:36:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HChjm-00027z-JF for mip4@ietf.org; Thu, 01 Feb 2007 14:36:50 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HChjl-0004uD-0j for mip4@ietf.org; Thu, 01 Feb 2007 14:36:50 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2007 11:36:48 -0800 X-IronPort-AV: i="4.13,268,1167638400"; d="scan'208"; a="384827324:sNHT104399726" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l11JalBD015390; Thu, 1 Feb 2007 11:36:47 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l11Jabho017976; Thu, 1 Feb 2007 11:36:38 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 11:36:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] WGLC: draft-ietf-mip4-gen-ext-00.txt Date: Thu, 1 Feb 2007 11:36:37 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520341706E@xmb-sjc-235.amer.cisco.com> In-Reply-To: <45401838.5070409@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] WGLC: draft-ietf-mip4-gen-ext-00.txt Thread-Index: Acb4o6ukTs3DbGKVRD2b+vQ/ch5DgxNkHh9g From: "Kent Leung \(kleung\)" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 01 Feb 2007 19:36:37.0598 (UTC) FILETIME=[49F0CFE0:01C74638] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7016; t=1170358607; x=1171222607; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip4]=20WGLC=3A=20draft-ietf-mip4-gen-ext-00.txt |Sender:=20; bh=u47gPZg60WA0NWo8bw53+394xFyhSUS8Tem5hE5FTnE=; b=A3r07nuPNZVZ72M4cPxCL2qxJ0ccK2lBUPGaW8fV2BseYths1F3dhuCM4MaQ1YQ4HvDkjDfP NhKQ8gHHvD+QzSc35G/t3xReHhc2rdyAgX7yE1EVCRqLH84+Uj3ST9qx; Authentication-Results: sj-dkim-8; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: McCann Peter-A001034 , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Vijay. Sorry for the delay. Appreciate your thorough review. Since most of your comments are accepted, I've only responded to the ones that need further discussion. My comments in "KL>" and Kuntal's in "[KC>]". -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 Sent: Wednesday, October 25, 2006 7:07 PM To: mip4@ietf.org Cc: McCann Peter-A001034; Henrik Levkowetz Subject: Re: [Mip4] WGLC: draft-ietf-mip4-gen-ext-00.txt this document needs some work before it can be sent to the IESG. at a high level we need to say that this document defines a new configuration options exchange extension, but we just use the extension to carry the DHCP and BOOTP options as defined in RFC 2132. the security considerations section needs some serious consideration. :) some specific comments. KL> This is same as last comment. =20 > This document describes the mechanism for providing the host > configuration information during Mobile IP registration. =20 perhaps mention here that this is primarily for home link information. for configuration information on the visited link, you are better off using DHCP on the visited link. KL> Agree that primarily the information is for home network parameters. But foreign network parameters may also be embedded as described in the draft. The reason is that in some cases, there is no DHCP exchange between MN and DHCP server in the foreign network. For example, a MIPv4 registration by the MN via the FA using FA CoA doesn't require DHCP. Some deployments use PPP/IPCP. Maybe it's possible to follow RFC 1877 to obtain DNS Server addresses, but not flexible to obtain other parameters. [KC>] A few other reasons: the visited domain is not guaranteed to have DHCP. The MN is not guaranteed to have DHCP Client either. These are true statements for many of the wireless networks we use today. Performance issue: If the config parameters are returned to the MN along with RRP w/o requiring another round trip using DHCP, it speeds up network entry. > One or more > Configuration Options Exchange Extensions may be included in the > registration message to provide the Mobile Node the configuration > parameters needed for network service usage (e.g. DNS). what is "network service usage"? network access? KL> This means use of network services such as DNS. > This field indicates which Mobility Agent was asked or inserted > the extension in the Registration Request or Registration > Reply, respectively. =20 suggest re-wording to This field indicates which mobility agent the request was sent to when the extension is present in a Registration Request and which mobility agent inserted the extension in a Registration Reply. or something like that... KL> maybe like this This field indicates which Mobility Agent is requested to provide configuration information when the extension is present in a Registration Request and which Mobility Agent=20 inserted the extension in a Registration Reply. > list of requested parameters is specified as a string of octets, > where each octet is a valid DHCP option code as defined in [RFC2132]. > If this extension is included in the Registration Request, the Home > Agent or Foreign Agent (indicated in the Entity-Type field) should > provide requested information in the Registration Reply. The > Configuration Options Exchange extension should be repeated in the > Registration Request for parameter(s) request based on the Entity- > Type. If there are no Configuration Options Exchange Extension in > the Registration Request, it's up to the Home Agent or Foreign Agent > to decide which configuration parameter to include in the > Configuration Options Exchange extension. The configuration > parameter(s) should not be overwritten by the Foreign Agent if the > Home Agent has included them in the Configuration Options Exchange > extension. The Entity-Type field is set to the Mobility Agent that > appended the extension in the Registration Reply. >=20 > When a network entity (identified in the Entity-Type field of the > extension) network entity includes the mobile node also in this case. wonder if "network entity" is the right term. KL> Will change to "Mobility Entity". < adds a Configuration Options Exchange Extension to a > Registration Request or Registration Reply message, this extension > MUST appear prior to any authentication extensions added by that > entity. >=20 > Example: >=20 > Mobile Node wants to obtain the home network prefix mask and DNS > servers' IP addresses from its Home Agent during registration. The > Registration Request would contain the following values in the > Configuration Options Exchange Extension. >=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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | =3D6 | =3D1 | =3D0 = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ what is "Rsv"? KL> Should be "=3D1". > | =3D55 | =3D2 | =3D1 | = =3D6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ what is "OpCode=3D55"? KL> This is Parameter Request List as defined in RFC 2132. Need to add description in the text. > 5. Security Considerations >=20 > There are no additional security aspects imposed by this document in > addition to the one defined in [RFC3344]. is that true? typically information that is being exchanged here is sent one-hop from the access network to the mobile node. or at least it is contained in the access network. now we are sending this information across the Internet unencrypted. for e.g. we are sending the IP address of the DNS server to a remote mobile node without encrypting the information. so its not possible that there are no new security considerations. KL> Today, no extensions are encrypted in the registration messages between foreign network and the home network. This is typically not an issue. If it is considered to be a problem, then usually some site to site security is set up using SLA between the MNOs. I don't see a need for encrypting the extensions. BTW, I'm thinking of writing up a draft that provides generic encryption of extensions (i.e. Encrypted Payload Extension which is a wrapper of other extensions, e.g. Type, Length, SPI, Payload=3Dextensions). But so far, there hasn't been a serious = need. If MIP extensions need to be encrypted, then it should be a generic function and not specific to host configuration, IMHO. Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 01 15:51:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCitq-0005zo-BN; Thu, 01 Feb 2007 15:51:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCit8-0003s1-6i; Thu, 01 Feb 2007 15:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCit7-0005c8-8S; Thu, 01 Feb 2007 15:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id E743F17644; Thu, 1 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCisc-00085c-G2; Thu, 01 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-radius-requirements-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 RADIUS requirements Author(s) : M. Nakhjiri, et al. Filename : draft-ietf-mip4-radius-requirements-01.txt Pages : 8 Date : 2007-2-1 This document provides an applicability statement as well as a scope definition for the specification provided in the document "RADIUS Mobile IPv4 extension" and its future revisions hereby collectively referred to as [I-D.nakhjiri-radius-mip4]. The goal is to justify qualification of [I-D.nakhjiri-radius-mip4] as a IETF work item. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-radius-requirements-01.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-mip4-radius-requirements-01.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: <2007-2-1114911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-radius-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-radius-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-1114911.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Fri Feb 02 17:21:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6mE-0003cp-RB; Fri, 02 Feb 2007 17:21:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6mD-0003ci-AB for mip4@ietf.org; Fri, 02 Feb 2007 17:21:01 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HD6mB-0001NC-BC for mip4@ietf.org; Fri, 02 Feb 2007 17:21:01 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1170454858!1948641!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12129 invoked from network); 2 Feb 2007 22:20:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 2 Feb 2007 22:20:58 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l12MKvua027077 for ; Fri, 2 Feb 2007 15:20:57 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l12MKvdS011418 for ; Fri, 2 Feb 2007 16:20:57 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Feb 2007 17:20:56 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus call: draft-tsirtsis-nemov4-dynamic-01.txt and draft-tsirtsis-nemov4-fa-01.txt Thread-Index: AcdHGGi3lBkMp+DOSX+0VMhlUJDf8Q== From: "McCann Peter-A001034" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Mip4] Consensus call: draft-tsirtsis-nemov4-dynamic-01.txt and draft-tsirtsis-nemov4-fa-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org During the mip4 meeting in San Diego, we saw a presentation from George Tsirtsis on two extensions of the nemov4 work. The charter calls out the work on dynamic address assignment and FA support as work items for the working group. This is a call for consensus to see whether we are ready to adopt these two drafts as working group items. Please respond by next Friday, February 9th, on whether you think we are ready to adopt these two drafts as working group items. -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 05 04:17:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDzyI-0007tN-3b; Mon, 05 Feb 2007 04:17:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDzyH-0007s0-1X for mip4@ietf.org; Mon, 05 Feb 2007 04:17:09 -0500 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDzyG-00038W-BV for mip4@ietf.org; Mon, 05 Feb 2007 04:17:09 -0500 Received: by an-out-0708.google.com with SMTP id d30so890010and for ; Mon, 05 Feb 2007 01:17:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lrQGCS2x/zAsXd2E9kQrp7oGe5QyjaKW5SEBYNicAN4WpK6BHYt3txY5Lo6gHRdp50fg9m32b9GcFXBy8F5kV2G//wlr3HsOSNDjjiEtMnQCFhli1cFB8VrCqy5WggEpUKWlzPTVAOhMuTYRXMB7987oSx90BZi5uKXkpryoW2U= Received: by 10.115.51.1 with SMTP id d1mr572260wak.1170667027243; Mon, 05 Feb 2007 01:17:07 -0800 (PST) Received: by 10.114.57.8 with HTTP; Mon, 5 Feb 2007 01:17:07 -0800 (PST) Message-ID: Date: Mon, 5 Feb 2007 01:17:07 -0800 From: "eduardo segura" To: deri.ie-iswc2005@lists.deri.org, ambient-intelligence@lists.andrew.cmu.edu, mip6@ietf.org, mip4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Cc: Subject: [Mip4] CFP: SPAC 07 - Software Patterns: Addressing Challenges X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org My apologies for duplicates The First IEEE International Workshop on Software Patterns: Addressing Challenges SPAC 2007 Call for Papers Beijing, China, July 24-27, 2007 (in conjunction with COMPSAC 2007) http://conferences.computer.org/compsac/2007/ (COMPSAC 2007 Link) http://conferences.computer.org/compsac/2007/workshops/SPAC (Workshop Link= -1) http://www.engr.sjsu.edu/~fayad/workshops/COMPSAC07 (Workshop Link-2) http://www.vrlsoft.com/workshops/SPAC07 (WorkshopLink-3) THEME OF THE WORKSHOP As software increases in size and becomes more complex and costly, the need for techniques to ease software development is likewise increasing. Over the last decade, pattern community has evolved and received more interest in both academia and industry. Developing software using patterns holds the promise to reduce the cost and condensing the time of developing software systems, while simultaneously maintaining the quality of these systems. However, the potential of using patterns in developing systems is not fully realized and we need to address many challenges. For example, developing pattern repositories and catalogs, from which patterns can be retrieved and reused, still forms a challenge to software engineering, knowledge engineering and information systems communities. In addition, the need for (semi-) automated approaches for patterns mining and integration poses several open research questions to the software engineering community. Many think these challenges and others preclude the realization of the benefit of patterns as a reuse approach. This workshop aims at bringing together researchers and practitioners who are interested in resolving research challenges or who have practical experience with the different issues of patterns reuse and integration to discuss and advance the state-of-the-art and the state-of-the-practice in patterns reuse. Patterns have emerged as a promising reuse technique for both improving the quality and reducing the cost and time of software development. However, there is an immense belief that patterns have not fulfilled the expectations software developers wanted. Nevertheless, this belief does not rebuff the fact that patterns, as a concept, have the potential to play a key role in developing systems in the near future. This near future will never come unless there are serious attempts from both developers and researchers to investigate and provide creative solutions to current challenges that hinder utilizing patterns in practice. Among these challenges, this workshop focuses on investigating how to develop systems using patterns. We are sure that this topic will attract many developers and researchers in the field to participate in this workshop. WORKSHOP CHALLENGES The workshop will address software patterns challenges and debate several issues related to the following questions. We want researchers, framework developers, and application developers to discuss and debate the following questions related to: I. Pattern Creation and Development a. Leaving experience claim on the side, can you show how to create and develop patterns? b. What are the bases of creating patterns? c. Are there guidelines, methodologies, and/or processes for pattern creations and developments? d. Would you show an example or two? II. Patterns Selection Process: a. How does one select analysis and design patterns to build any system? b. What is the basis for selecting these patterns? c. If someone would like to build a system from patterns, how does she select patterns? d. What kind of patterns should one select to build a system from patterns? e. Is there a guideline for the selection process? III. Patterns Composition a. How does one integrate the selected patterns to build any system? or How does one compose any system from patterns? b. What are the various claims related to patterns composition? Are they true? c. Are there guidelines or techniques for patterns composition? Would you illustrate how to use them? IV. System of Patterns and General Reuse a. What do we mean when we say "systems of patterns"? b. Are the various claims related to building any system from patterns reasonable? c. How to develop pattern repositories and catalogs, from which patterns can be retrieved and reused? d. Are there automated approaches for patterns mining and integration? e. What other concepts will help build any system from patter= ns? . V. Impacts a. What is the impact of software stability on the above issu= es? Check any of the following websites for all columns and accepted position papers: http://conferences.computer.org/compsac/2007/workshops/SPAC (Main Link) www.engr.sjsu.edu/~fayad//workshops/COMPSAC07 (Workshop Link 2) www.vrlsoft.com/workshops/SPAC07 (Workshop Link 3 -- Under Construction) PAPER FORMAT AND SUBMISSIONS Detailed instructions for electronic paper submission and review process can be found at http://www.compsac.org/. People interested in participating in the workshop are requested to submit a short position paper (3-5 pages) or regular workshop paper (limited to 6 pages, double spaced, including figures) representing views and experiences relevant to the discussion topic. The title page should include a maximum 150-word abstract, five keywords, full mailing address, e-mail address, phone number, fax number, and a designated contact author. Papers will be selected depending on the originality, quality and relevance to the workshop. All submitted papers will be evaluated according to its originality, significance, correctness, presentation and relevance. Papers should be submitted electronically at: http://compsac.cs.iastate.edu/2007/SPAC/ . Please follow the instructions given by the web page. Camera Ready manuscripts must be submitted following IEEE conference proceedings style and guidelines. We encourage authors to present novel ideas, critique of existing work, and practical studies. Each accepted paper must be presented in person by the author or one of the authors. To foster lively discussions, each author is encouraged to present open questions and one or two main statements that will be discussed at the workshop. Submissions must be either MS-Word or RTF formats (please, DO NOT compress files). Depending on the number and spread of contributions, the scope may be narrowed to ensure effective communication and information sharing. Accepted position papers will be distributed to the participants before the workshop and made generally available through the WWW and FTP. Accepted papers will be published in the Workshop Proceedings of the 31st IEEE Computer Software and Applications Conference (COMPSAC 2007). At least one of the authors of each accepted paper must register as a full participant in the workshop to have the paper published in the COMPSAC 2007 Proceedings. The workshop selected best papers will be published in online Journal of International Journal Of Patterns (IJOP) =96 www.ijop.org WORKSHOP PARTICIPATION Interested in participating in the workshop without submission are requested to fill out the participation form and e-mail to the co-chair Haitham Hamza , Eduardo Segura , or to the workshop chair M.E. Fayad . ------------------------------------------------- PARTICIPATION FORM: Name and Affiliation: Position: Address: E-mail: URL: Areas of interest: Why would you like to participate? ------------------------------------------------- Please note that registration is required in order to participate in the workshop. An early registration discount is available. An overhead projector and a flipchart will be available. For more information please visit any of the following websites: http://conferences.computer.org/compsac/2007/workshops/SPAC (Main Link) www.engr.sjsu.edu/~fayad//workshops/COMPSAC07 (Workshop Link 2) www.vrlsoft.com/workshops/SPAC07 (Workshop Link 3 -- Under Construction) You may also contact the organizers. PROPOSED AGENDA 1. Welcome and introduction of participants. The organizers will first give a short overview of any open issues and of the main arguments arising out of the position papers. (Estimated time: 20-30 minutes) 2. Selected authors (representing the main trends) will be given 20 minutes to explain how their position relates to other positions and what each sees as the three major issues. We expect about 5-10 position papers. (Estimated time: 120-130 minutes) 3. The organizers will propose an identification of the major issues, and the participants will then discuss and select what they think are the hottest issues to be examined. (Estimated time: 10-15 minutes) 4. The participants will work for 70-95 minutes in small groups, with a designated moderator in each group. The groups will each deal with two different hot issues identified and will produce a summary in the form of points and counterpoints, showing either how several views are irreducibly opposed or how they are complementary. The number of groups will depend on the number of participants and number of issues selected; ideally there should be 3-5 p people in each group. (Estimated time: 60-70 minutes) 5. Each group will be given 10-15 minutes to present its findings to the workshop. A closing discussion will follow. The workshop report will be written on the basis of these findings and will include an agenda for future exploration and cooperation; it will be made available through the WWW and FTP. (Estimated time: 50-60 minutes for five teams) (Total estimated time: 285-315 minutes, i.e. about five hours +/- 15 minutes; lunch and breaks are not included.) IMPORTANT DATES We will be updated based on acceptance process Feb. 23, 2007: Full paper and short paper due Mar. 25, 2007: Decision notification (electronic) Apr. 30, 2007: Camera-ready copy and author registration due July 24-27, 2007: The workshop Date ORGANIZERS Chair and Point of Contact: Dr. M.E. Fayad Professor of Computer Engineering Computer Engineering Dept., College of Engineering San Jos=E9 State University One Washington Square, San Jos=E9, CA 95192-0180 Ph: (408) 924-7364, Fax: (408) 924-4153 E-mail: m.fayad@sjsu.edu, me fayad@gmail.com http://www.engr.sjsu.edu/fayad Co-Chairs: Dr. H.S. Hamza (Co-Chair) Faculty of Computers and Informatics, Information Technology Department Cairo University, Orman, Giza 12613 - Egypt Ph: (02) 335-8355 (office) E-mail: hshamza@gmail.com Eduardo M. Segura vrlSoft, Inc. 2065 Martin Ave., Suite 103 Santa Clara, CA 95050-2707 Phone/Fax: (408) 654-8972 E-mail: esegura@vrlsoft.com, eduardo.segura@sjsu.edu http://www.vrlsoft.com PROGRAM COMMITTEE Leonor Barroca Open University, England Sjaak Brinkkemper Utrecht University, the Netherlands Chia-Chu Chiang University of Arkansas at Little Rock, U= SA Rogerio Atem de Carvalho CEFET Campos, Brazil Andrea D'Ambrogio University of Roma TorVergata, Italy Issam Wajih Damaj Dhofar University, Salalah - Sultanate of Oman Khalil DRIRA LAAS-CNRS, France Islam A. M. El-Maddah Ain Shams University, Egypt M.E. Fayad San Jose State University & vrlSoft, Inc., USA Joao M. Fernandes Universidade do Minho, Portugal IanGraham Trireme International Ltd, London, England Jiang Guo California State University Los Angeles, USA Wilhelm Hasselbring University of Oldenburg, Germany Tarek Helmy King Fahd Univ. of Petroleum and Minerals, Saudi Arabia H.S. Hamza Cairo University, Egypt Pilar Herrero Universidad Polit=E9cnica de Madrid , Spain. Hoda Hosny American University in Cairo, Egypt Pao-Ann Hsiung National Chung Cheng University, Chiayi, TAIWAN Ali Jaoua University of Qatar, Qatar Mohamed-Khireddine KHOLLADI University of Constantine, France Dae-Kyoo Kim Oakland University, MI, USA Seok-Won Lee The University of North Carolina at Charlotte, USA Jeff Lei University of Texas at Arlington, USA Ricardo J. Machado Universidade do Minho, Portugal Ahmed Mahdy Texas A&M University - Corpus Christi, U= SA Michael Oudshoorn Montana State University, MT, USA Srini Ramaswamy University of Arkansas at Little Rock, U= SA Gustavo Rossi LIFIA, Facultad de Informatica, UNLP, Argentina Stuart Rubin SPAWAR, SSC-San Diego, USA Kannamma Sampath Coimbatore Institute of Technology, India Sanchez, Arturo University of North Florida, USA Kassem A. Saleh American University of Sharjah, UAE Arno Schmidmeier AspectSoft, Hersbruck, Germa= ny E.M. Segura San Jose State University & vrlSoft, Inc., USA Manolis Tzagarakis Research Academic Technology Institute (RACTI), Greece Laurence T. Yang St Francis Xavier University, Canada I-Ling Yen University of Texas at Dallas, USA -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 05 12:26:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7cJ-0007Fc-Kt; Mon, 05 Feb 2007 12:26:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDzGu-0001lR-FG; Mon, 05 Feb 2007 03:32:20 -0500 Received: from reserv6.univ-lille1.fr ([193.49.225.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDzGp-0007FI-SK; Mon, 05 Feb 2007 03:32:20 -0500 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv6.univ-lille1.fr (8.13.7/jtpda-5.3.1) with ESMTP id l158UOdV032745 ; Mon, 5 Feb 2007 09:30:24 +0100 Received: from ROMY (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l158Tq317504 ; Mon, 5 Feb 2007 09:29:52 +0100 (MET) From: "Nathalie Mitton" To: Date: Mon, 5 Feb 2007 09:30:00 +0100 Message-ID: <00b201c748ff$e743a960$d80bce86@ROMY> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AccOR1mGwiOkvBT/Qoygmr1ifrv/zQAAPbzADq2VUiA= X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (reserv6.univ-lille1.fr [193.49.225.20]); Mon, 05 Feb 2007 09:30:27 +0100 (CET) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@inria.fr X-Spam-Status: No X-Spam-Score: 0.2 (/) X-Scan-Signature: 5aec5327a02d1dfe64fbd5ba060d1311 X-Mailman-Approved-At: Mon, 05 Feb 2007 12:26:58 -0500 Cc: Subject: [Mip4] CFP (dead line march 31) and Call for workshop (dead line February 9th) - MASS 2007 - Pisa, Italy - October 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2100388904==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============2100388904== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B3_01C74908.490A8260" This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01C74908.490A8260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This message is cross-posted to several lists. Apologies for any duplicate postings. IEEE MASS 2007 ( http://cnd.iit.cnr.it/mass2007/) The Fourth IEEE International Conference on Mobile Ad-hoc and Sensor Systems ---------------- IMPORTANT DATES: ---------------- MASS Conference: Manuscript Submission Due: March 31, 2007 Acceptance Notification: June 30, 2007 Final Manuscript Due: August 10, 2007 Workshop proposals: Proposals submission deadline: February 9, 2007 Acceptance/Reject notification: February 21, 2007 Papers due by: April 30, 2005 Paper selections due by: July 15, 2007 Final papers due to IEEE: August 10, 2007 ---- Call For Papers and call for workshop Wireless multi-hop communication is envisioned in multiple scenarios where network nodes communicate via other network nodes: conferences, hospitals, battlefields, rescue operations, environment control, cars-to-cars, and monitoring scenarios. Wireless mesh networks have been applied as alternatives for providing Internet access in remote business and residential areas. Wireless sensor networks are being deployed for several industrial control processes and for monitoring environment. This conference aims to address multi-hop ad-hoc and sensor networks systems, covering topics ranging from technology issues up to the applications aspects. Original manuscripts that focus on the analytical modeling, protocol/algorithm design, and/or experimental studies of the following topics of interest are sought: * physical layer impact on higher level protocols * MAC protocols for ad-hoc and sensor networks (802.11, 802.15.4, UWB) Provisioning of wireless QoS in terms of bandwidth and delay assurance * Routing protocols (unicast, multicast, broadcast, geocast) and routing metrics * Data transport in wireless ad hoc and sensor networks * Power-aware and energy-efficient design * Topology construction and coverage maintenance * Cross layer design and optimization * Incentives and game theoretic approaches in wireless ad-hoc networks * Localization and synchronization in wireless sensor networks * Data gathering, fusion, and dissemination in wireless sensor * Reliability, security, and trustworthiness issues in ad hoc and sensor networks * Operating system and middleware support * Measurements and practical experience from experimental systems and test-beds * Modeling, analysis and performance evaluation * Mesh networking * Delay tolerant networks and opportunistic networking * Handoff and mobility management and seamless internetworking * Peer-to-peer, overlay, and content distribution wireless ad hoc networks * Reliability, security, and trustworthiness issues in ad hoc and sensor networks Paper submission All submissions must be full papers in .pdf or .ps (PostScript) format. Papers must be uploaded to EDAS by March 31, 2007, and must not exceed 10 single-spaced, two-column pages using at least 11 point size fonts on 8.5 x 11 inch pages. Detailed submission instructions will be published in due time on the conference website http://www.ieee-mass.org together with format files. Workshops Proposals for full day workshops are solicited. Selections will be made considering the expertise and experience of the workshop organizers and the relevance of the topic to the central theme of the conference. Proposals of at most 4 pages, including a 1-page biographical sketch, should be submitted to the Workshops Chair by March 31, 2007 Demos Technical demonstration of experimental ad hoc networking and computing systems are solicited. To Instructions for submitting a demo proposal will be published in due time on the conference website. Important dates Manuscript Submission Due: March 31, 2007 Acceptance Notification: June 30, 2007 Final Manuscript Due: August 10, 2007 CALL FOR WORKSHOPS ---------------------------------------------------------------------------- -- IEEE MASS 2007 will be the fourth annual conference on the rapidly expanding area of multi-hop wireless computing and sensor networking, and will provide an exciting platform for discussing research vision of a digitally networked wireless environment. The MASS Organizing Committee invites proposals for one-day workshops affiliated with the conference. The workshops will be held prior to, or after, the main conference. The purpose of these workshops is to provide a platform for presenting novel ideas and more specific research areas in a less formal and possibly more focused way than at the conference itself. Please visit http://www.cse.fau.edu/mass2006/workshops.html to view information on workshops held last year at MASS 2006. Workshops Proposals are solicited in all areas and topics pertaining to ad-hoc wireless and sensor networking research and applications, including, but not limited to, theoretical performance bounds for ad-hoc networks, sensor and wireless network and application security/privacy, mesh networks, middleware platforms and applications of specific techniques (e.g., control theory or biological networks) to wireless networks. We expect all selected workshops to adhere to a common paper submission and reviewing schedule outlined below. All papers included in the MASS 2007 workshops will appear in the MASS 2007 Proceedings published by IEEE. ------------------------------- Proposal Submission Guidelines: ------------------------------- Each workshop proposal must include: 1. The name of the workshop. 2. The names, addresses, and a short bio (up to 200 words) of the organizers (maximum up to three). 3. A brief description (up to 1 page) of the technical issues that the workshop will address, and the reasons why the workshop is of interest this time. 4. The names of potential participants, such as program committee members, 5. Planned format of the workshop, such as number of refereed papers, keynotes, panels etc. 6. If appropriate, a description of past versions of the workshop, including: number of submitted and accepted papers, number of attendees. 7. A description of the publicity plan. 8. A call for papers 9. The workshop website address Workshop proposals should be submitted, no later than February 9, 2007, by e-mail (in PDF format) with "MASS 2007 Workshop Proposal" in the subject, to BOTH MASS 2007 Workshop Co-chairs: Luciano Bononi Department of Computer Science, University of Bologna, Italy Mura Anteo Zamboni 7, 40127, Bologna, Italy E-mail: bononi@cs.unibo.it and Archan Misra IBM T.J. Watson Research Centre 19 Skyline Drive, Room 2N-B18 Hawthorne, NY 10532 Email: archan@us.ibm.com ---------------- IMPORTANT DATES: ---------------- Proposals submission deadline: February 9, 2007 Acceptance/Reject notification: February 21, 2007 Papers due by: April 30, 2005 Paper selections due by: July 15, 2007 Final papers due to IEEE: August 10, 2007 -- ------=_NextPart_000_00B3_01C74908.490A8260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This message is cross-posted to several lists. = Apologies for any duplicate postings.

 

IEEE MASS 2007 =
(http://cnd.iit.cnr.it/mass2007/)=

 

The Fourth IEEE International Conference on Mobile = Ad-hoc and Sensor Systems

 

=  

----------------
IMPORTANT =
DATES:
----------------
MASS Conference:



Manuscript
Submission Due:         =
      March
31, 2007

Acceptance Notification:     =
            June
30, 2007

Final Manuscript Due:         =
            August
10, 2007



 
 
Workshop =
proposals:
Proposals submission =
deadline:          =
February 9, 2007
Acceptance/Reject =
notification:         February =
21, 2007
 
Papers due =
by:           &nbs=
p;            =
;  April 30, 2005
Paper selections due =
by:       =
         July 15, =
2007
Final papers due to =
IEEE:           &n=
bsp;   August 10, =
2007
 
----



=
 



Call For Papers and call for =
workshop



 



Wireless =
multi-hop communication
is envisioned in multiple scenarios where network nodes communicate via =
other
network nodes: conferences, hospitals, battlefields, rescue operations,
environment control, cars-to-cars, and monitoring scenarios. Wireless =
mesh
networks have been applied as alternatives for providing Internet access =
in
remote business and residential areas. Wireless sensor networks are =
being
deployed for several industrial control processes and for monitoring
environment. This conference aims to address multi-hop ad-hoc and sensor
networks systems, covering topics ranging from technology issues up to =
the
applications aspects. Original manuscripts that focus on the analytical
modeling, protocol/algorithm design, and/or experimental studies of the
following topics of interest are sought:

·        physical layer impact on higher level = protocols

·        MAC protocols for ad-hoc and sensor networks (802.11, = 802.15.4, UWB) Provisioning of wireless QoS in terms of bandwidth and delay = assurance

·        Routing protocols (unicast, multicast, broadcast, = geocast) and routing metrics

·        Data transport in wireless ad hoc and sensor = networks

·        Power-aware and energy-efficient = design

·        Topology construction and coverage maintenance

·        Cross layer design and optimization

·        Incentives and game theoretic approaches in wireless = ad-hoc networks

·        Localization and synchronization in wireless sensor = networks

·        Data gathering, fusion, and dissemination in wireless = sensor

·        Reliability, security, and trustworthiness issues in ad = hoc and sensor networks

·        Operating system and middleware support

·        Measurements and practical experience from experimental = systems and test-beds

·        Modeling, analysis and performance evaluation

·        Mesh networking

·        Delay tolerant networks and opportunistic = networking

·        Handoff and mobility management and seamless = internetworking

·        Peer-to-peer, overlay, and content distribution wireless = ad hoc networks

·        Reliability, security, and trustworthiness issues in ad = hoc and sensor networks

 <= /o:p>

Paper submission
All = submissions must be full papers in .pdf or .ps (PostScript) format. Papers must be = uploaded to EDAS by March 31, 2007, and must not exceed 10 single-spaced, two-column = pages using at least 11 point size fonts on 8.5 x 11 inch pages. = Detailed submission instructions will be published in due time on the conference = website http://ww= w.ieee-mass.org together with format files.

 

Workshops
Proposals = for full day workshops are solicited. Selections will be made considering the = expertise and experience of the workshop organizers and the relevance of the topic = to the central theme of the conference. Proposals of at most 4 pages, including = a 1-page biographical sketch, should be submitted to the Workshops Chair = by March 31, 2007

 <= /o:p>

Demos
Technical demonstration of experimental ad hoc networking and computing systems = are solicited. To Instructions for submitting a demo proposal will be = published in due time on the conference website.

 <= /o:p>

Important dates
Manuscript Submission Due: = March 31, 2007
Acceptance Notification: June 30, 2007
Final Manuscript Due: August 10, 2007

 

 

CALL FOR = WORKSHOPS

 

----------------------------------------------=
--------------------------------
 
 
IEEE MASS 2007 will be the fourth annual =
conference on the rapidly expanding =

area of multi-hop wireless computing and =
sensor networking, and will provide =

an exciting platform for discussing research =
vision of a digitally networked =

wireless environment. =

 
The MASS Organizing Committee invites =
proposals for one-day workshops =

affiliated with the conference. =

The workshops will be held prior to, or =
after, the main conference.
 
The purpose of these workshops is to provide =
a platform for presenting novel =

ideas and more specific research areas in a =
less formal and possibly more 
focused way than at the conference itself. =

Please visit http://www.cse.fau.edu/mass2006/workshops.html to view 
information on workshops held =
last year at MASS 2006.
 
Workshops Proposals are solicited in all =
areas and topics pertaining to 
ad-hoc wireless and sensor networking =
research and applications, including, =

but not limited to, theoretical performance =
bounds for ad-hoc networks, 
sensor and wireless network and application =
security/privacy, mesh networks, =

middleware platforms and applications of =
specific techniques (e.g., control =

theory or biological networks) to wireless =
networks. 
We expect all selected workshops to adhere to =
a common paper submission and 
reviewing schedule outlined below. All papers =
included in the MASS 2007 
workshops will appear in the MASS 2007 =
Proceedings published by IEEE.
 
-------------------------------
 
Proposal Submission =
Guidelines:
 
-------------------------------
 
Each workshop proposal must =
include:
 
1. The name of the =
workshop.
 
2. The names, addresses, and a short bio (up =
to 200 words) of the 
   organizers (maximum up to =
three).
 
3. =
A brief description (up to 1 page) of the technical issues =
that the 
   workshop will address, and =
the reasons why the workshop is of interest =

   this =
time.
 
4. The names of potential participants, such =
as program committee members,
 
5. Planned format of the workshop, such as =
number of refereed papers, 
   keynotes, panels =
etc.
 
6. If appropriate, a description of past =
versions of the workshop, 
   including: number of =
submitted and accepted papers, number of =
attendees.
 
7. =
A description of the publicity =
plan.
 
8. =
A call for papers
 
9. The workshop website =
address
 
Workshop proposals should be submitted, no =
later than February 9, 2007, 
by e-mail (in PDF format) with "MASS =
2007 Workshop Proposal" in the subject, =

to BOTH MASS 2007 Workshop =
Co-chairs:
 
 
  Luciano =
Bononi
  Department of Computer Science, =
University of Bologna, =
Italy =

  Mura Anteo Zamboni 7, 40127, Bologna, =
Italy
  E-mail: bononi@cs.unibo.it
 
  and
 
  Archan =
Misra
  IBM T.J. Watson Research =
Centre
  19 Skyline =
Drive, Room =
2N-B18
  Hawthorne, NY 10532
  Email: archan@us.ibm.com=

 
----------------
IMPORTANT =
DATES:
----------------
 
Proposals submission =
deadline:          February 9, =
2007
Acceptance/Reject =
notification:         February =
21, 2007
 
Papers due =
by:           &nbs=
p;            =
;  April 30, 2005
Paper selections due =
by:           &nbs=
p;    July 15, =
2007
Final papers due to =
IEEE:           &n=
bsp;   August 10, =
2007
 
-- =




 
------=_NextPart_000_00B3_01C74908.490A8260-- --===============2100388904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2100388904==-- From mip4-bounces@ietf.org Mon Feb 05 14:32:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9Zp-0007XW-Es; Mon, 05 Feb 2007 14:32:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9Zn-0007XG-Hv for mip4@ietf.org; Mon, 05 Feb 2007 14:32:31 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE9Zl-0006dZ-Tz for mip4@ietf.org; Mon, 05 Feb 2007 14:32:31 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15JTrdE030249; Mon, 5 Feb 2007 21:30:09 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 21:32:17 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 13:31:52 -0600 Received: from 10.162.253.189 ([10.162.253.189]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Feb 2007 19:31:52 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 05 Feb 2007 11:32:21 -0800 Subject: Re: [Mip4] FMIPv4 From: Rajeev Koodli To: ext Alexandru Petrescu , McCann Peter-A001034 Message-ID: Thread-Topic: [Mip4] FMIPv4 Thread-Index: Acc+TgMwzGRyT+OCSam6l4eu+AtWHQLDld3U In-Reply-To: <45B4F94B.7080309@motorola.com> Mime-version: 1.0 X-OriginalArrivalTime: 05 Feb 2007 19:31:52.0900 (UTC) FILETIME=[49E65840:01C7495C] X-Nokia-AV: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0370344864==" Errors-To: mip4-bounces@ietf.org > 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. --===============0370344864== Content-type: multipart/alternative; boundary="B_3253519941_17829697" > 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. --B_3253519941_17829697 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Alex, >> > 5.3. Router Solicitation for Proxy Advertisement (RtSolPr) > > Is this an RS carried as ICMP (RFC1256) or as ICMPv6. Encoding is > different. Remark that existing implementations of ICMPv4 RS could be > re-used for minimal modifications, or otherwise ICMPv6 could be re-used. > It's a choice. But in a FMIPv4 deployment one wouldn't assume > availability of ICMPv6... or maybe yes (?). Also it's strange to use > Checksum field as computed from rfc1256 but the format from ICMPv6. > > Same for Proxy Router Advertisement. > > > Rajeev:> I am coming back to this issue. > > The RS in 1256 has the format (hope it shows up right, but you get the idea): > > 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 | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > There is no room for options as such. ICMPv6 format is almost similar, but the > Reserved field is replaced by the Message Body field which allows room for > options. > > The RtSolPr/PrRtAdv messages need to have options. > > So, we need to use the base ICMPv6 format adapted for our purpose here (as was > done in FMIPv6). > So, the format looks like in Section 5.3. > > 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 | Code | Checksum | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Subtype | Reserved | Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options ... > +-+-+-+-+-+-+-+-+-+-+-+- > > > Now, the checksum calculation: > For ICMPv4, > > The 16-bit one's complement of the one's complement sum of the ICMP message, > starting with the ICMP Type. For computing the checksum, the Checksum field > is set to 0. > > For ICMPv6, > > The checksum is the 16-bit one's complement of the one's complement > sum of the entire ICMPv6 message starting with the ICMPv6 message > type field, prepended with a "pseudo-header" of IPv6 header fields, > as specified in [IPv6, section 8.1]. The Next Header value used in > the pseudo-header is 58. (NOTE: the inclusion of a pseudo-header in > the ICMPv6 checksum is a change from IPv4; see [IPv6] for the > rationale for this change.) > > Except for the inclusion of the pseudo-header, the calculation is identical. > > In our case, we have IPv4 header. Hence, the fmipv4 spec refers to 1256 for > checksum calculation. > > In summary, we need to use the expanded ICMPv6 format (which also allows > re-use of FMIPv6 software), but use ICMPv4 checksum because we use IPv4 > headers for the RtsolPr/PrRtAdv messages. > > Does this clarify? > > -Rajeev > > > > --B_3253519941_17829697 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Mip4] FMIPv4
Hi Alex,



> 5.3. Router Solicitation for Proxy Advertisement (= RtSolPr)

Is this an RS carried as ICMP (RFC1256) or as ICMPv6.  Encoding is
different.  Remark that existing implementations of ICMPv4 RS could be=
re-used for minimal modifications, or otherwise ICMPv6 could be re-used.   It's a choice.  But in a FMIPv4 deployment one wouldn't as= sume
availability of ICMPv6... or maybe yes (?).  Also it's strange to use<= BR> Checksum field as computed from rfc1256 but the format from ICMPv6.

Same for Proxy Router Advertisement.


Rajeev:> I am coming back to this issue.

The RS in 1256 has the format (hope it shows up right, but you get the idea= ):

0             &= nbsp;            = ;1             &= nbsp;            = ;2             &= nbsp;            = ; 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        &n= bsp;|     Code        = ; |            &= nbsp;Checksum           &n= bsp;  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             &= nbsp;            = ; Reserved           =             &nbs= p;            &n= bsp;         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



There is no room for options as such. ICMPv6 format is almost similar, but = the Reserved field is replaced by the Message Body field which allows room f= or options.

The RtSolPr/PrRtAdv messages need to have options.

So, we need to use the base ICMPv6 format adapted for our purpose here (as = was done in FMIPv6).
So, the format looks like in Section 5.3.

   0          &= nbsp;            = ;   1          &= nbsp;            = ;   2          &= nbsp;            = ;   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      &n= bsp;  |     Code      = ;   |          &= nbsp;  Checksum         &n= bsp;    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Subtype      |  &nb= sp;Reserved     |       &n= bsp;  Identifier         &= nbsp;         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
  +-+-+-+-+-+-+-+-+-+-+-+-


Now, the checksum calculation:
For ICMPv4,

The  16-bit one's complement of the one's complement sum of the ICMP m= essage, starting with the ICMP Type.  For computing the checksum, the C= hecksum field is set to 0.

For ICMPv6,

The checksum is the 16-bit one's complement of the one's complement
   sum of the entire ICMPv6 message starting with the ICMPv6= message
   type field, prepended with a "pseudo-header" of= IPv6 header fields,
   as specified in [IPv6, section 8.1].  The Next Heade= r value used in
   the pseudo-header is 58.  (NOTE: the inclusion of a = pseudo-header in
   the ICMPv6 checksum is a change from IPv4; see [IPv6] for= the
   rationale for this change.)

Except for the inclusion of the pseudo-header, the calculation is identical= .

In our case, we have IPv4 header. Hence, the fmipv4 spec refers to 1256 for= checksum calculation.

In summary, we need to use the expanded ICMPv6 format (which also allows re= -use of FMIPv6 software), but use ICMPv4 checksum because we use IPv4 header= s for the RtsolPr/PrRtAdv messages.

Does this clarify?

-Rajeev




--B_3253519941_17829697-- --===============0370344864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0370344864==-- From mip4-bounces@ietf.org Mon Feb 05 14:57:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9xy-0004Ky-Ls; Mon, 05 Feb 2007 14:57:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE9xw-0004Kt-Uc for mip4@ietf.org; Mon, 05 Feb 2007 14:57:28 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE9xv-0003j7-Ij for mip4@ietf.org; Mon, 05 Feb 2007 14:57:28 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1170705446!4830299!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32643 invoked from network); 5 Feb 2007 19:57:26 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 5 Feb 2007 19:57:26 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l15JvLCU025675; Mon, 5 Feb 2007 12:57:26 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l15JvJZN018538; Mon, 5 Feb 2007 13:57:20 -0600 (CST) Message-ID: <45C78C1E.1090107@motorola.com> Date: Mon, 05 Feb 2007 20:57:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip4] FMIPv4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: mip4@ietf.org, McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev Koodli wrote: > > Hi Alex, > > > > > 5.3. Router Solicitation for Proxy Advertisement (RtSolPr) > > Is this an RS carried as ICMP (RFC1256) or as ICMPv6. Encoding is > different. Remark that existing implementations of ICMPv4 RS could be > re-used for minimal modifications, or otherwise ICMPv6 could be re-used. > It's a choice. But in a FMIPv4 deployment one wouldn't assume > availability of ICMPv6... or maybe yes (?). Also it's strange to use > Checksum field as computed from rfc1256 but the format from ICMPv6. > > Same for Proxy Router Advertisement. > > > Rajeev:> I am coming back to this issue. > > The RS in 1256 has the format (hope it shows up right, but you get > the idea): > > 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 | Code | Checksum > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > There is no room for options as such. ICMPv6 format is almost > similar, but the Reserved field is replaced by the Message Body > field which allows room for options. > > The RtSolPr/PrRtAdv messages need to have options. > > So, we need to use the base ICMPv6 format adapted for our purpose > here (as was done in FMIPv6). > So, the format looks like in Section 5.3. > > 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 | Code | Checksum > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Subtype | Reserved | Identifier > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Options ... > +-+-+-+-+-+-+-+-+-+-+-+- > > > Now, the checksum calculation: > For ICMPv4, > > The 16-bit one's complement of the one's complement sum of the ICMP > message, starting with the ICMP Type. For computing the checksum, > the Checksum field is set to 0. > > For ICMPv6, > > The checksum is the 16-bit one's complement of the one's complement > sum of the entire ICMPv6 message starting with the ICMPv6 message > type field, prepended with a "pseudo-header" of IPv6 header fields, > as specified in [IPv6, section 8.1]. The Next Header value used in > the pseudo-header is 58. (NOTE: the inclusion of a pseudo-header in > the ICMPv6 checksum is a change from IPv4; see [IPv6] for the > rationale for this change.) > > Except for the inclusion of the pseudo-header, the calculation is > identical. > > In our case, we have IPv4 header. Hence, the fmipv4 spec refers to > 1256 for checksum calculation. > > In summary, we need to use the expanded ICMPv6 format (which also > allows re-use of FMIPv6 software), but use ICMPv4 checksum because > we use IPv4 headers for the RtsolPr/PrRtAdv messages. > > Does this clarify? Thanks for clarification on the motivation, I understand now why. Do you basically propose an expansion to the existing ICMPv4 RA format? Or a plain new ICMPv4 type message? You've put Type to be assigned by IANA for PrRtAdv. So I believe you propose a new ICMPv4 message. (otherwise you'd have put Type '9' RA)(?). The Checksum computation you refer to rfc1256 is designed only for Type 9 ICMPv4 messages, because they specify how the Checksum is computed at every RS, RA, etc. So I guess it makes sense to request a IANA number for a new ICMPv4 message and then put text in this draft that is exactly how to compute the checksum for this message. What do you think? Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 05 15:04:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEA4P-0000JM-VP; Mon, 05 Feb 2007 15:04:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEA4O-0000F7-1Q for mip4@ietf.org; Mon, 05 Feb 2007 15:04:08 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEA4M-0005di-J9 for mip4@ietf.org; Mon, 05 Feb 2007 15:04:08 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15K0dcK031260; Mon, 5 Feb 2007 22:01:00 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 22:03:34 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 14:03:23 -0600 Received: from 10.162.253.189 ([10.162.253.189]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Feb 2007 20:03:23 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 05 Feb 2007 12:03:52 -0800 Subject: Re: [Mip4] FMIPv4 From: Rajeev Koodli To: ext Alexandru Petrescu Message-ID: Thread-Topic: [Mip4] FMIPv4 Thread-Index: AcdJYMHFAIIteLVUEduwBQAWy5YJpw== In-Reply-To: <45C78C1E.1090107@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 20:03:23.0294 (UTC) FILETIME=[B0A993E0:01C74960] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip4@ietf.org, McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org On 2/5/07 11:57 AM, "ext Alexandru Petrescu" wrote: > Do you basically propose an expansion to the existing ICMPv4 RA format? > Or a plain new ICMPv4 type message? > > You've put Type to be assigned by IANA for PrRtAdv. So I believe you > propose a new ICMPv4 message. (otherwise you'd have put Type '9' RA)(?). Yes, it is a new Type. > > The Checksum computation you refer to rfc1256 is designed only for Type > 9 ICMPv4 messages, because they specify how the Checksum is computed at > every RS, RA, etc. > > So I guess it makes sense to request a IANA number for a new ICMPv4 > message and then put text in this draft that is exactly how to compute > the checksum for this message. Sounds good. The checksum calculation is identical, except for the new Type. So, if we put in text saying that calculation is the same as in rfc1256, but with the new Type number, would that suffice for us here? Thanks, -Rajeev > > What do you think? > > Alex > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 05 15:17:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEAHd-0007Vg-Rq; Mon, 05 Feb 2007 15:17:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEAHc-0007VU-Tk for mip4@ietf.org; Mon, 05 Feb 2007 15:17:48 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HEAHb-00005x-L7 for mip4@ietf.org; Mon, 05 Feb 2007 15:17:48 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1170706666!6946630!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16529 invoked from network); 5 Feb 2007 20:17:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 5 Feb 2007 20:17:47 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l15KHkGr000858; Mon, 5 Feb 2007 13:17:46 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l15KHjqr026751; Mon, 5 Feb 2007 14:17:45 -0600 (CST) Message-ID: <45C790E8.7000401@motorola.com> Date: Mon, 05 Feb 2007 21:17:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip4] FMIPv4 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: mip4@ietf.org, McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev Koodli wrote: > > > On 2/5/07 11:57 AM, "ext Alexandru Petrescu" > wrote: > >> Do you basically propose an expansion to the existing ICMPv4 RA format? >> Or a plain new ICMPv4 type message? >> >> You've put Type to be assigned by IANA for PrRtAdv. So I believe you >> propose a new ICMPv4 message. (otherwise you'd have put Type '9' RA)(?). > > Yes, it is a new Type. So one may suggest explicitely to IANA that the type is to be assigned from the ICMPv4 Type space, and not from ICMPv6 Type space, which are different. In the IANA Considerations section. >> The Checksum computation you refer to rfc1256 is designed only for Type >> 9 ICMPv4 messages, because they specify how the Checksum is computed at >> every RS, RA, etc. >> >> So I guess it makes sense to request a IANA number for a new ICMPv4 >> message and then put text in this draft that is exactly how to compute >> the checksum for this message. > > Sounds good. The checksum calculation is identical, except for the new Type. > So, if we put in text saying that calculation is the same as in rfc1256, but > with the new Type number, would that suffice for us here? Yes. When you say calculation is 'same as in rfc1256' then one may wonder 'which message of rfc1256 because each defines a checksum calculation'. One may go finer grain and say that the Reserved field is set to 0 for checksum calculation (1256 doesn't say so). That's why I was saying complete checksum text copypasting would be good. Otherwise it's fine, thanks, Alex > > Thanks, > > -Rajeev > > >> What do you think? >> >> Alex >> > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Feb 06 04:27:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMbe-0000BX-RR; Tue, 06 Feb 2007 04:27:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMbc-0000BM-R1 for mip4@ietf.org; Tue, 06 Feb 2007 04:27:16 -0500 Received: from web50114.mail.yahoo.com ([206.190.39.162]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HEMbX-0006GR-Ja for mip4@ietf.org; Tue, 06 Feb 2007 04:27:16 -0500 Received: (qmail 40620 invoked by uid 60001); 6 Feb 2007 09:27:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=glLLB+Bjb6p/+FDiug4fX/6fML6QOuNsiMk0Up4eMzrPY7vWxgtOt/VdBTHLPXPfP9iR8wUDUmJaa3B2s1e94CgEfw7GGk1fPBM/iJlK31AesRrHHUBSxpQBSQPIS1SO0VhEVw+1Rg2YUgkBx5HnH03ANT54nGQTLf8gB/2/70U=; X-YMail-OSG: TrZzZ8wVM1noM31o2U3KRfGSdNqn8DozdM8UblmbErpFjVHq4QYokct8CGO8aoSDvfyFmUTgvS_jxMTJ1JzfcebVvGI4k6MfDAGTJc7REbioLNFcwlXbNvuKzbIsAXfp1Mg4A9wh3JxvYD4- Received: from [124.195.55.73] by web50114.mail.yahoo.com via HTTP; Tue, 06 Feb 2007 01:27:11 PST Date: Tue, 6 Feb 2007 01:27:11 -0800 (PST) From: raja satria utama To: mip4@ietf.org MIME-Version: 1.0 Message-ID: <328020.40609.qm@web50114.mail.yahoo.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Mip4] windows exchange server 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0387050290==" Errors-To: mip4-bounces@ietf.org --===============0387050290== Content-Type: multipart/alternative; boundary="0-2107213275-1170754031=:40609" Content-Transfer-Encoding: 8bit --0-2107213275-1170754031=:40609 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit can i implement mobile ipv4 under windows exchange server 2007...? --------------------------------- Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. --0-2107213275-1170754031=:40609 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit can i implement mobile ipv4 under windows exchange server 2007...?

Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta. --0-2107213275-1170754031=:40609-- --===============0387050290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0387050290==-- From mip4-bounces@ietf.org Wed Feb 07 09:36:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnuZ-00078C-MN; Wed, 07 Feb 2007 09:36:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HECq9-0002BA-Jv for mip4@ietf.org; Mon, 05 Feb 2007 18:01:37 -0500 Received: from mail.di.uniroma1.it ([151.100.17.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HECq8-0000tN-0e for mip4@ietf.org; Mon, 05 Feb 2007 18:01:37 -0500 Received: from wmail.di.uniroma1.it (venere.di.uniroma1.it [151.100.17.6]) by mail.di.uniroma1.it (Postfix) with ESMTP id 80E271BD61F for ; Mon, 5 Feb 2007 23:56:07 +0100 (CET) Received: from 74-134-226-235.dhcp.insightbb.com ([74.134.226.235]) (SquirrelMail authenticated user maselli); by wmail.di.uniroma1.it with HTTP; Tue, 6 Feb 2007 00:13:38 +0100 (CET) Message-ID: <3421.74.134.226.235.1170717218.squirrel@74.134.226.235> Date: Tue, 6 Feb 2007 00:13:38 +0100 (CET) From: "Gaia Maselli" To: mip4@ietf.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-Mailman-Approved-At: Wed, 07 Feb 2007 09:36:38 -0500 Subject: [Mip4] CFP: Workshop on Systems and Networking Support for Healthcare and Assisted Living Environments X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org We apologize in advance if you receive multiple copies of this CFP. ------------------------------------------------------------ Call for Papers HealthNet 2007 The 1st International Workshop on Systems and Networking Support for Healthcare and Assisted Living Environments In conjunction with MobiSys 2007 June 11, 2007 Puerto Rico, USA http://healthnet07.cs.uiuc.edu Sponsored by ACM SIGMOBILE ------------------------------------------------------------ WORKSHOP SCOPE: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As the world's population grows older, healthcare and high-tech companies are joining forces. New technologies are being used to provide improved support for elderly and home bound people in their homes and in assisted living environments. The overall goal of these initiatives is to improve the quality of life by providing customized support to people in need of assistance. The main challenge is to provide this support according to the user's own specific situation in a non-intrusive and respectful way. These new technologies enable the automation of the observation and support for elderly and home bound people through the use of sensors, actuators, distributed intelligence, databases, ubiquitous connectivity and friendly adaptive interfaces, all connected mainly via a variety of wireless networking technologies. The ultimate goal is a system that can adapt to the users needs, helping them get through their daily routine in a way that is effective in providing support where needed without making them feel humiliated by excessive attention. To provide such support, it will be necessary to combine efforts from many areas of computer science, including networking, distributed systems, security, data management, HCI, AI and middleware. Given the inherent use of mobile and wireless communication and the need for comprehensive distributed systems as well as the multi-disciplinary nature of solutions for healthcare and assisted living environments, the goal of HealthNet is to provide a forum for the cross-area interactions that will be necessary for successful systems and applications. The specific focus of HealthNet will be on understanding what it takes to provide effective systems and communication support for healthcare and assisted living environments. Although the systems and networking community is very good at providing effective solutions to satisfying application requirements, they require input from experts in other disciples, including HCI, middleware, security, privacy and social networking, to provide a more accurate understanding of the specific requirements for these environments. Therefore, HealthNet aims to attract researchers working on cross-disciplinary projects, with a focus on understanding and supporting the requirements of these complex applications. Authors are invited to submit papers presenting new research related to the support of healthcare and assisted living environments. All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Areas of interest include, but are not limited to: * Enabling technologies * Service and device discovery * Security and privacy * Reliability and fault tolerance * User and device localization * Resource management architecture * User data management * Middleware for heterogeneous networks * Mobility and connectivity management * Cross-layer system architecture design * Human-centered Computing * Task and behavior analysis * Impact of user interface design on system design and management * Test-beds and simulations environments IMPORTANT DATES: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paper submission deadline: March 23, 2007 (5PM US EST) Notification of acceptance: April 27, 2007 Camera ready version due: May 17, 2007 Workshop date: June 11, 2007 PAPER SUBMISSION INSTRUCTIONS: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 6 pages, double-column, with a font size no smaller than 10 points, and must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. The first page of each paper should include the names and affiliations of the authors, i.e., the submissions should not be anonymous and reviewing is single-blind. Submissions will be judged on based on technical content and correctness, relevance to the workshop, as well as presentation of the research. Extended versions of selected workshop papers will be considered for fast track publication in a special issue of ACM Monet. ORGANIZING COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WORKSHOP Co-Chairs: * Robin Kravets, University of Illinois, USA * Chiara Petrioli, Rome University "La Sapienza," Italy PUBLICITY Co-Chairs: * Stefano Basagni, Northeastern University, USA * Gaia Maselli, Rome University "La Sapienza," Italy TECHNICAL PROGRAM COMMITTEE * Amy Murphy, IRST-ITC * Archan Misra, IBM * Gene Tsudik, ISI * Hans Gellersen, Lancaster University * Henry Kautz, University of Rochester * Jack Stankovic, University of Virginia * Karrie Karahalios, University of Illinois * Kay Connelly, Indiana University * Maria Ebling, IBM * Martha Pollack University of Michigan * Nigel Davies, Lancaster University * Sunny Consolvo, Intel * Taieb Znati, University of Pittsburgh * Tarek Abdelzaher, University of Illinois * Wendi Heinzelmann, University of Rochester * Yih-Chun Hu, University of Illinois Please email questions related to paper submission or the technical program to: healthnet07@cs.uiuc.edu. Organized by UIUC and Rome University "La Sapienza." --=20 Gaia Maselli, PhD Computer Science Dept. Rome University "La Sapienza" Via Salaria 113, 00198 Roma, Italy Email: maselli@di.uniroma1.it -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 07 15:51:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtlC-0005Sv-2Y; Wed, 07 Feb 2007 15:51:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEtkw-00052M-4i; Wed, 07 Feb 2007 15:51:06 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HEtkt-0002cu-P4; Wed, 07 Feb 2007 15:51:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 2C5E117610; Wed, 7 Feb 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HEtju-0001bU-Ts; Wed, 07 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Fast Handovers Author(s) : R. Koodli, C. Perkins Filename : draft-ietf-mip4-fmipv4-03.txt Pages : 28 Date : 2007-2-7 This document adapts the Mobile IPv6 Fast Handovers [1] to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-fmipv4-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-mip4-fmipv4-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. --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: <2007-2-7113554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-fmipv4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-fmipv4-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-7113554.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Sat Feb 10 10:25:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFu6E-0004q3-2f; Sat, 10 Feb 2007 10:25:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFHJR-00057q-LO; Thu, 08 Feb 2007 17:00:17 -0500 Received: from gremlin.ics.uci.edu ([128.195.1.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFHJN-0001K5-1z; Thu, 08 Feb 2007 17:00:17 -0500 Received: from gremlin.ics.uci.edu (localhost [127.0.0.1]) by gremlin.ics.uci.edu (8.13.6/8.13.5) with ESMTP id l18Lw6HG009372; Thu, 8 Feb 2007 13:59:25 -0800 (PST) Received: from zero.ics.uci.edu (zero.ics.uci.edu [128.195.1.35]) by gremlin.ics.uci.edu (8.13.6/8.13.5) with ESMTP id l18LulWN009252 for ; Thu, 8 Feb 2007 13:56:47 -0800 (PST) Received: from mail127.messagelabs.com (mail127.messagelabs.com [216.82.250.115]) by zero.ics.uci.edu (8.13.6/8.13.6) with SMTP id l18LuYLX016794 for ; Thu, 8 Feb 2007 13:56:34 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: mopy@labs.mot.com X-Msg-Ref: server-8.tower-127.messagelabs.com!1170971793!5224628!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3102 invoked from network); 8 Feb 2007 21:56:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-127.messagelabs.com with SMTP; 8 Feb 2007 21:56:33 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l18LuXd3018180 for ; Thu, 8 Feb 2007 14:56:33 -0700 (MST) Received: from localhost.localdomain (lynch-bages.labs.mot.com [10.2.201.18]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l18LuXdA011255 for ; Thu, 8 Feb 2007 15:56:33 -0600 (CST) Date: Thu, 08 Feb 2007 15:46:20 -0600 To: middleware2007@ics.uci.edu From: "shivajit mohapatra" Organization: Motorola Labs Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-16 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.02 (Linux) X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=0.077, required 5, autolearn=disabled, TW_ZS 0.08) X-ICS-MailScanner-From: mopy@labs.mot.com X-Mailman-Approved-At: Thu, 08 Feb 2007 13:58:02 -0800 X-BeenThere: middleware2007@mailman.ics.uci.edu X-Mailman-Version: 2.1.5 Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 X-Mailman-Approved-At: Sat, 10 Feb 2007 10:25:12 -0500 Cc: Subject: [Mip4] [ACM Middleware2007] CFP: Announcing ACM/IFIP/USENIX 8th International Middleware Conference X-BeenThere: mip4@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ***************************************************************************** CALL FOR PAPERS MIDDLEWARE 2007 ACM/IFIP/USENIX 8th International Middleware Conference (approvals pending) http://2007.middleware-conference.org/ Newport Beach, Orange County, California, USA November 26th - 30th, 2007 ***************************************************************************** The Middleware conference is a forum for the discussion of important innovations and recent advances in the design and construction of middleware. Middleware is distributed-systems software that resides between the applications and the underlying operating systems, network protocol stacks, and hardware. Its primary role is to functionally bridge the gap between application programs and the lower-level hardware and software infrastructure in order to coordinate how application components are connected and how they interoperate. Following the success of past conferences in this series, the 8th International Middleware Conference will be the premier event for middleware research and technology in 2007. The scope of the conference is the design, implementation, deployment, and evaluation of distributed system platforms and architectures for future computing and communication environments. Highlights of the conference will include a high quality technical program, invited speakers, poster and demo presentations, a doctoral symposium, and workshops. Submissions on a diversity of topics are sought, particularly ones that identify new research directions. Middleware 2007 is not limited to topics discussed in previous Middleware conferences. Authors concerned about the appropriateness of a topic may communicate by electronic mail with the program chair prior to submission. The proceedings of Middleware 2007 will be published as a Springer-Verlag volume in the Lecture Notes in Computer Science Series. Topics ------ The topics of the conference include, but are not limited to: Platforms and Architectures: * Middleware for Web services and Web-service composition * Middleware for cluster and grid computing * Peer-to-peer middleware solutions * Event-based, publish/subscribe, and message-oriented middleware * Communication protocols and architectures * Middleware for ubiquitous and mobile computing * Middleware for embedded systems and sensor networks * Service-oriented architectures * Reconfigurable, adaptable, and reflective middleware approaches Systems issues: * Reliability, fault tolerance, and quality-of-service in general * Scalability of middleware: replication and caching * Systems management, including solutions for autonomic and self-managing middleware * Middleware feedback control solutions for self-regulation * Real-time solutions for middleware platforms * Information assurance and security * Evaluation techniques for middleware solutions * Middleware support for multimedia streaming * Middleware solutions for (large scale) distributed databases Design principles and tools: * Formal methods and tools for designing, verifying, and evaluating middleware * Model-driven architectures * Software engineering for middleware * Engineering principles and approaches for middleware * Novel development paradigms, APIs, and languages * Existing paradigms revisited: object models, aspect orientation, etc. * On-the-fly management and configuration of middleware Organization ------------ General Chair: Nalini Venkatasubramanian (University of California at Irvine, USA) Program Chairs: Roy Campbell (University of Illinois at Urbana Champaign, USA) Renato Cerqueira (PUC-Rio, Brazil) Workshops Chair: TBA Doctoral Symposium Chair: TBA Industry Track Chair: TBA Publicity Chair: Shivajit Mohapatra (Motorola Labs, USA) Local Arrangements Chair: Ray Klefstad (University of California, Irvine) Local Arrangements Committee: Nalini Venkatasubramanian (University of California at Irvine, USA) Ray Klefstad (University of California, Irvine) Sharad Mehrotra (University of California, Irvine) Vana Kalogeraki (University of California, Irvine) Deborah Nielsen (OCTANE@UCI) Shellie Nazarenus (Calit2) Program Committee ----------------- Gustavo Alonso (ETH Zurich, Switzerland) Cristiana Amza (University of Toronto, Canada) Jean Bacon (Cambridge University, UK) Guruduth Banavar (IBM India Research Lab, India) Alberto Bartoli (University of Trieste, Italy) John Barton (IBM Almadem, USA) Christian Becker (University of Mannheim, Germany) Yolande Berbers (Leuven University, Belgium) Gordon Blair (Lancaster University, UK) Jean-Pierre Briot (Paris 6, France) Andrew Campbell (Columbia University, USA) Walfredo Cirne (Federal University of Campina Grande, Brazil) Clem Cole (USENIX, USA) Paolo Costa (Vrije Universiteit Amsterdam, Netherlands) Geoff Coulson (Lancaster University, UK) Jan de Meer (SmartSpaceLab, Germany) Fred Douglis (IBM Watson, USA) Naranker Dulay (Imperial College, UK) Markus Endler (PUC-Rio, Brazil) Pascal Felber (University of Neufchatel, Switzerland) Paulo Ferreira (INESC ID / Tech. Univ. of Lisbon, Portugal) Joni Fraga (Federal University of Santa Catarina, Brazil) Indranil Gupta (University of Illinois at Urbana-Champaign, USA) Valerie Issarny (INRIA, France) Arno Jacobsen (Toronto University, Canada) Shanika Karunasekera (University of Melbourne, Australia) Bettina Kemme (McGill University, Canada) Fabio Kon (IME/USP, Brazil) Doug Lea (Oswego State University, USA) Rodger Lea (University of British Columbia, Canada) Satoshi Matsuoka (Tokyo Institute of Technology, Japan) Elie Najm (ENST, France) Priya Narasimhan (CMU, USA) Tamer Ozsu (University of Waterloo, Canada) Christian Perez (IRISA, France) Gian Pietro Picco (Politecnico di Milano, Italy) Alexander Reinefeld (ZIB, Germany) Luis Rodrigues (University of Lisbon, Portugal) Antony Rowstron (Microsoft Research Cambridge, UK) Rick Schantz (BBN Technologies, USA) Douglas C. Schmidt (Vanderbilt University, USA) Jean-Bernard Stefani (INRIA, France) Joe Sventek (University of Glasgow, UK) Stefan Tai (IBM Watson, USA) Peter Triantafillou (University of Patras, Greece) Steve Vinoski (IONA, USA) Gregor von Laszewski (Argonne National Laboratory, USA) Important dates --------------- Paper registration: April 9 Paper submission: April 16 Notification of acceptance: July 16 Camera-ready copies: August 31st Submission guidelines --------------------- Papers must not exceed 20 pages, including abstract, all figures, all tables, and references. Papers should include a short abstract and up to 6 keywords. Submitted papers should follow the formatting instructions of the Springer LNCS Style (please check the Information for Authors page at Springer at http://www.springer.de/comp/lncs/authors.html for style and formatting guidelines). Submitted papers may not be submitted for conference publication, journal publication, or be under review for any other conference or journal. For any questions regarding this matter, please contact the program chairs. Submissions will be handled via the conference web page at http://2007.middleware-conference.org/Submission.htm You will be requested to upload the file of your paper (PDF format) to the conference server (please avoid bitmaps!). Please also fill in the appropriate information in the online form. Further information ------------------- For further information and submission instructions, please visit http://2007.middleware-conference.org/ or contact the Program Chairs. _______________________________________________ Middleware2007 mailing list Middleware2007@mailman.ics.uci.edu https://mailman.ics.uci.edu/mailman/listinfo/middleware2007 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 12 01:26:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGUdq-0006Hc-M9; Mon, 12 Feb 2007 01:26:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGUdp-0006HX-Ph for mip4@ietf.org; Mon, 12 Feb 2007 01:26:21 -0500 Received: from web50108.mail.yahoo.com ([206.190.38.36]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGUdk-00010o-Iv for mip4@ietf.org; Mon, 12 Feb 2007 01:26:21 -0500 Received: (qmail 66144 invoked by uid 60001); 12 Feb 2007 06:26:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=QBePIHt+PxxjgtDJjkHwbTbTQnIh2OscUhs6eZT+TrsS3h/sYZPVOjnyBwhoSQWBaXdQ0P7oU1LiGwA7r0jNEc5ry5CpomAKLX1dFj0kPRlhlpK8l/4fCuDAZiCnS5Y+RfzKeIfV03qjsHsEHz8kIqAPcAen+wIYCKJEin9tufY=; X-YMail-OSG: G.cSougVM1lG1DHNo2bJ8pfXB4ssbBi6LLmmpqDbHFaDk.VrO.pjkCbAOb7.CupAZFNZFO1nBGZm8j1oePXvRRjQygcRMQ0ob9rvUy6073KzaOOwMmR9YoG7MqtYRiwxkTo5UfwOvw2KkMc- Received: from [69.88.3.218] by web50108.mail.yahoo.com via HTTP; Sun, 11 Feb 2007 22:26:15 PST Date: Sun, 11 Feb 2007 22:26:15 -0800 (PST) From: raja satria utama To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <191463.65672.qm@web50108.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Mip4] mip4 under windows??? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org can i implement MIPv4 under windows..???? (windows xp, windows 2000) ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 12 04:45:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGXkR-0000gp-QH; Mon, 12 Feb 2007 04:45:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGXkP-0000gS-Td for mip4@ietf.org; Mon, 12 Feb 2007 04:45:21 -0500 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGXkO-00026T-Jt for mip4@ietf.org; Mon, 12 Feb 2007 04:45:21 -0500 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 89ADC37F0A; Mon, 12 Feb 2007 10:45:11 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 14BBA37F47; Mon, 12 Feb 2007 10:45:10 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id A3BE037E55; Mon, 12 Feb 2007 10:45:10 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1HGXkD-0007O9-VP; Mon, 12 Feb 2007 10:45:10 +0100 Message-ID: <45D0371A.1010702@levkowetz.com> Date: Mon, 12 Feb 2007 10:44:58 +0100 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: raja satria utama Subject: Re: [Mip4] mip4 under windows??? References: <191463.65672.qm@web50108.mail.yahoo.com> In-Reply-To: <191463.65672.qm@web50108.mail.yahoo.com> X-Enigmail-Version: 0.94.1.2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: radja_ichadz@yahoo.com, mip4@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0995266334==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0995266334== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF338A60A1B2F1CBBC5392B22" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF338A60A1B2F1CBBC5392B22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, writer of an unsigned message, on 2007-02-12 07:26 raja satria utama said the following: > can i implement MIPv4 under windows..???? > (windows xp, windows 2000) Maybe this answers your question: http://www.mip4.org/2006/implementations/ Henrik --------------enigF338A60A1B2F1CBBC5392B22 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFF0DckeVhrtTJkXCMRAiQZAKDDTKSAs2W4qDsQ8igjNjdxYB57JACgsaXo BUX6Ap1SdZBPVvn0s6QyA1E= =nVjk -----END PGP SIGNATURE----- --------------enigF338A60A1B2F1CBBC5392B22-- --===============0995266334== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0995266334==-- From mip4-bounces@ietf.org Mon Feb 12 06:20:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGZEp-0001GW-9W; Mon, 12 Feb 2007 06:20:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGZEn-0001GI-S8 for mip4@ietf.org; Mon, 12 Feb 2007 06:20:49 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGZEm-0003JJ-HO for mip4@ietf.org; Mon, 12 Feb 2007 06:20:49 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1171279247!969140!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 32016 invoked from network); 12 Feb 2007 11:20:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 12 Feb 2007 11:20:47 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1CBKgtK027797; Mon, 12 Feb 2007 04:20:47 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1CBKeAT007777; Mon, 12 Feb 2007 05:20:41 -0600 (CST) Message-ID: <45D04D80.3080300@motorola.com> Date: Mon, 12 Feb 2007 12:20:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: raja satria utama Subject: Re: [Mip4] mip4 under windows??? References: <191463.65672.qm@web50108.mail.yahoo.com> In-Reply-To: <191463.65672.qm@web50108.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org raja satria utama wrote: > can i implement MIPv4 under windows..???? (windows xp, windows 2000) Of course you can, why not. You will probably write first a simple UDP client on Windows, that sends a RegReq to a linux MIP4 HA pre-implemented by OpenSource software (maybe Dynamics). You will have to make sure the UDP Client on Windows interacts ok with the DHCP Client provided by Windows. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 12 12:56:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfPF-0002JJ-NH; Mon, 12 Feb 2007 12:56:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFx5e-00050q-8g for mip4@ietf.org; Sat, 10 Feb 2007 13:36:50 -0500 Received: from diomedes.noc.ntua.gr ([147.102.222.220]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HFx5Z-0003iU-C9 for mip4@ietf.org; Sat, 10 Feb 2007 13:36:50 -0500 Received: from ektor.telecom.ece.ntua.gr (ektor.telecom.ece.ntua.gr [147.102.7.1]) by diomedes.noc.ntua.gr (8.14.0/8.14.0) with ESMTP id l1AISW2x090266; Sat, 10 Feb 2007 20:28:34 +0200 (EET) (envelope-from pimrc07-bounces@telecom.ntua.gr) Received: from localhost (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id CB68F8A39B; Sat, 10 Feb 2007 20:28:33 +0200 (EET) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on diomedes.noc.ntua.gr X-Virus-Scanned: Clam AntiVirus on ektor.telecom.ece.ntua.gr Received: from ektor.telecom.ece.ntua.gr ([127.0.0.1]) by localhost (ektor.telecom.ece.ntua.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocpjGxb+Lvul; Sat, 10 Feb 2007 20:28:32 +0200 (EET) Received: from ektor.telecom.ece.ntua.gr (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id DEDBC8A2DB; Sat, 10 Feb 2007 20:25:40 +0200 (EET) X-Original-To: pimrc07@telecom.ntua.gr Delivered-To: pimrc07@telecom.ntua.gr Received: from localhost (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 4E6928A2AF for ; Sat, 10 Feb 2007 20:25:03 +0200 (EET) X-Virus-Scanned: Clam AntiVirus on ektor.telecom.ece.ntua.gr Received: from ektor.telecom.ece.ntua.gr ([127.0.0.1]) by localhost (ektor.telecom.ece.ntua.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAmh6l36YwU2 for ; Sat, 10 Feb 2007 20:24:59 +0200 (EET) Received: from harry (ppp048-056.dsl.hol.gr [89.210.48.56]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id CEFC48A2A8 for ; Sat, 10 Feb 2007 20:24:58 +0200 (EET) Message-ID: <01d801c74d40$c66fcd50$1ab2a8c0@telecom.ntua.gr> To: Date: Sat, 10 Feb 2007 20:24:59 +0200 Organization: NTUA MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 From: PIMRC 2007 X-BeenThere: pimrc07@telecom.ntua.gr X-Mailman-Version: 2.1.8 Precedence: list List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Virus-Status: Clean X-Spam-Score: 0.5 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c X-Mailman-Approved-At: Mon, 12 Feb 2007 12:56:00 -0500 Cc: Subject: [Mip4] [pimrc07] IEEE PIMRC 2007, Athens, Greece X-BeenThere: mip4@ietf.org Reply-To: pimrc07@telecom.ntua.gr List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Apologies if you receive multiple copies of this CFP] ***************************************************************** CALL FOR PAPERS, WORKSHOP, TUTORIAL AND SPECIAL SESSION PROPOSALS IEEE PIMRC 2007 18th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, September, 3-7, 2007, Athens, Greece http://www.pimrc2007.org ***************************************************************** Conference Main Theme: Wireless Entropy Overview PIMRC 2007 provides a global forum for presenting the most recent advances, the future technical challenges and business opportunities that comprise the contemporary landscape in wireless communications. The organizers endeavour to attract contributions covering not only conventional areas of wireless communications (e.g., physical layer), but also emerging areas with high potential for essential scientific and societal impact such as wireless sensors for biomedical applications and non-trivial pervasive computing services. The latter areas are expected to facilitate the development of a broad vision of innovative future applications in wireless communications. The high quality IEEE endorsed technical programme, will also include tutorials, workshops, exhibitions, panel discussions and keynote presentations from leading experts coming from the academic community, industry, as well as regulatory and standardisation bodies. PIMRC 2007 will be held in Athens, Greece, September 3-7, 2007 i.e. one week following the peak of Greece's beautiful summer season. Call for Papers Authors are invited to submit high-quality papers describing original and previously unpublished contributions in a wide range of topics in wireless communications. These topics are clustered into the following three major categories: 1) Physical Layer and MAC 2) Mobile and Wireless Networks 3) Applications, Services and Business Models Papers should be in English, strictly not exceeding 5 double-column pages (3,000 words), in Adobe PDF format (which is the only accepted format for PIMRC 2007). Authors should use the relevant IEEE template, ensuring an IEEE Xplore compatible PDF-format. To access the full list of topics, submission guidelines, as well as venue and travel information please visit: www.pimrc2007.org Important Dates Full papers due: March 3rd, 2007 Acceptance notice: May 31st, 2007 Final manuscript due: June 16th, 2007 Conference dates: September 3-7, 2007 Call for Workshop Proposals We solicit workshop proposals on new and emerging topics in wireless communication and networks, services, and applications. A proposal should focus on a specific theme of current interest seeking for high-quality submissions. Proposals for one-day workshops to be held in conjunction with the main conference are solicited. A proposal can be a maximum of 2 pages long and should clearly identify the theme and specific topics of interest which define the scope of the workshop. It should also stress how it intends to provide more insight into the proposed topics with respect to the main conference. The proposal should include the workshop chairs and a tentative list of program committee members. The organizers of approved workshops will be responsible for advertising their workshops, inviting experts, reviewing submitted papers, and collecting camera-ready copies of accepted papers. The rest of the organizational details (registrations, workshop rooms, etc.) will be covered by the PIMRC Organizing Committee. Proposal Submission: Please send workshop proposals in PDF format by March 1, 2007 to the workshop co-chairs, Dr. Charalambos Skianis (skianis@iit.demokritos.gr), Dr. Nikos Passas (passas@di.uoa.gr) and Dr. Nikos Papadakis (nkpap@telecom.ntua.gr). Important Dates: Proposal submission due: March 1, 2007 Notification of acceptance: April 1, 2007 Workshop date: September 3, 2007 Call for Tutorials Proposals for Tutorials (half/full day), are welcome based on the topics listed in the Call for Papers or others related to issues and opportunities for the future of wireless communications, systems and applications. Proposals should be submitted electronically, containing the following information: * Tutorial Title * Instructor(s) * Extended Abstract (1 page) * Table of Contents (as detailed as possible) * Proposed Duration (half day, full day) * Thematic Area * Target Group(s) * Titles and venues of related tutorials that you may have given in the past, indicating (roughly) attendance level * Biographical sketch of the instructor(s) Please submit this information electronically to: * papadias@ait.edu.gr and * gyov@ait.edu.gr in order to allow for a prompt and thorough evaluation of your tutorial proposal. The evaluation criteria for each proposal include the expertise and experience of the instructor(s), the relevance of the subject, as well as the general objectives of the conference. Important dates Tutorial submission deadline: April 30th, 2007 PIMRC 2007 Tutorials: September 2nd, 2007 Tutorial Sessions Co-Chairs Prof. Constantinos Papadias, Athens Information Technology Prof. Gregory Yovanof, Athens Information Technology Call for Special Sessions PIMRC 2007 invites proposals for special sessions to be held in conjunction with conference. We solicit proposals for half and full day special sessions related to the conference topics. The aim of a special session is to bring together professionals from academia and industry to exchange ideas, experiences and identify obstacles and propose solutions in different domains of communications and telecommunications concerning key innovative issues. Proposals for special sessions should stress how they intend to provide more insight into the proposed innovative topic with respect to the main conference. Proposal submission Spesial sessions proposals should be submitted to the spesial session co-chairs with the title, a description of the topic, and the names of key organizers and potential presenters, by March 12, 2007. Prior contact with the spesial session co-chairs is encouraged. The organizer(s) of approved spesial sessions will be responsible for advertising their special session, and for the reviewing process for their papers, and for the collection of camera-ready copies of accepted papers. The spesial session proposal should follow the specific proposal form available at the website. Imortant dates Proposal submission due: March 12, 2007 Notification of acceptance: April 1, 2007 Spesial Session Co-Chairs Dr. Didier Bourse, Motorola Labs, Didier.Bourse@motorola.com Prof. George Kormentzas, University of Aegean, gkorm@aegean.gr Prof. Andreas Polydoros, National and Kapodistrian University of Athens, polydoros@phys.uoa.gr _______________________________________________ pimrc07 mailing list pimrc07@telecom.ntua.gr http://www.telecom.ntua.gr/mailman/listinfo/pimrc07 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 12 12:56:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfPF-0002Jt-Ur; Mon, 12 Feb 2007 12:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0Il-0008FK-Sy; Sat, 10 Feb 2007 17:02:35 -0500 Received: from [2001:12f0:201:1:202:e3ff:fe0f:b8d] (helo=mailman.ufsc.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0Ih-00083N-J0; Sat, 10 Feb 2007 17:02:35 -0500 Received: from localhost (localhost [127.0.0.1]) by mailman.ufsc.br (Postfix) with ESMTP id 8658C7EF4C; Sat, 10 Feb 2007 19:58:57 -0200 (BRST) Received: from mailman.ufsc.br ([127.0.0.1]) by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00960-04; Sat, 10 Feb 2007 19:58:57 -0200 (BRST) Received: from mailman.ufsc.br (mailman.ufsc.br [150.162.1.5]) by mailman.ufsc.br (Postfix) with ESMTP id B8ED17ECD2; Sat, 10 Feb 2007 19:57:44 -0200 (BRST) X-Original-To: researchers@mailman.ufsc.br Delivered-To: researchers@mailman.ufsc.br Received: from localhost (localhost [127.0.0.1]) by mailman.ufsc.br (Postfix) with ESMTP id DD8507ECBF for ; Sat, 10 Feb 2007 19:57:36 -0200 (BRST) Received: from mailman.ufsc.br ([127.0.0.1]) by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00544-08 for ; Sat, 10 Feb 2007 19:57:30 -0200 (BRST) Received: from rot.barddal.br (44054.static.fln.virtua.com.br [200.174.44.54]) by mailman.ufsc.br (Postfix) with ESMTP id 6D41B7ECB5 for ; Sat, 10 Feb 2007 19:57:30 -0200 (BRST) Received: from mi0f9a3e303b4e (201-24-98-168.fnsce703.dsl.brasiltelecom.net.br [201.24.98.168]) (authenticated bits=0) by rot.barddal.br (8.13.1/8.13.1) with ESMTP id l1ALutsF024700; Sat, 10 Feb 2007 21:56:56 GMT Message-ID: <024701c74d5e$7802c320$6800a8c0@mi0f9a3e303b4e> From: "Profa Mirela Sechi Moretti Annoni Notare" To: Date: Sat, 10 Feb 2007 19:57:26 -0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-barddal-MailScanner-Information: Please contact the ISP for more information X-barddal-MailScanner: Found to be clean X-barddal-MailScanner-SpamScore: sss X-barddal-MailScanner-From: mirela@barddal.br X-Virus-Scanned: by amavisd-new at mailman.ufsc.br X-BeenThere: researchers@mailman.ufsc.br X-Mailman-Version: 2.1.5 Precedence: list X-Virus-Scanned: by amavisd-new at mailman.ufsc.br X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-Mailman-Approved-At: Mon, 12 Feb 2007 12:56:00 -0500 Cc: Subject: [Mip4] [Researchers] Globecom 2007 Ad Hoc and Sensor Netw. Symposium X-BeenThere: mip4@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org IEEE Globecom 2007 Ad Hoc and Sensor Networking Symposium - CALL FOR PAPERS 26-30 November 2007 Washington, DC, USA --------------------------------------------------------------------- Submission Date: March 15th, 2007 --------------------------------------------------------------------- Co-Chairs Prof. Azzedine Boukerche, Email: boukerch@site.uottawa.ca Prof. Hussein Mouftah, Email: mouftah@site.uottawa.ca Prof. Hsiao-Hwa Chen, Email: hshwchen@ieee.org Scope Multi-hop wireless Ad Hoc and sensor networks are self-organizing systems formed by co-operating nodes within communication range of each other that form temporary networks. Ad hoc wireless networks allow anywhere, anytime network connectivity with complete lack of control, ownership, and regulatory influence. The last few years have witnessed a wealth of research ideas on ad hoc and sensor networks that are moving rapidly into commercialization and standardization. Such networks can be randomly and rapidly deployed and reconfigured and easily tailored to specific applications including entertainment, civilian, military, etc. Moreover, an ad hoc architecture is highly robust to node failure and can provide a high-level of fault tolerance due to nodal redundancy and its distributed nature. Furthermore, energy efficiency can be achieved through multi-hop routing communication. Bandwidth reuse can also benefit from dividing the single long range hop to multiple short hops with each hop having a shorter range. Several challenges face are standing in the way to achieving ubiquitous deployment of ad hoc and sensor networks. These include variable topology, device heterogeneity, limited power supply and the lack of effective energy-efficient design, lack of QoS and application support, etc. This symposium aims at providing a forum for sharing ideas among researchers and practitioners working on state-of-the-art solutions to the challenges above. We are seeking papers that describe original and unpublished contributions addressing various aspects of ad hoc and sensor networks. You are invited to submit original technical papers covering but not limited to the following topics. Please visit the mail IEEE Globecom 2007 Webpage for submission details and on-line submissions at http://www.ieee-globecom.org/2007/. Topics of Interest . Algorithms and modeling for mobile user localization and target tracking . Analytical, mobility and validation models for ad hoc networks . Applications and evolutions of Ad hoc and sensor networks . Architectures of wireless communication and mobile computing . Co-existence issues of hybrid networks . Cross-layer design and interactions . Cryptography and security issues in ad hoc and sensor networks . Data management, data aggregation, data dissemination, and query processing . Distributed algorithms for wireless ad hoc and sensor networks . Frequency and channel allocation algorithms . IEEE 802.11 and Bluetooth based medium access control . MAC protocols for ad hoc and sensor networks . Mobile service and QoS management . Performance evaluation and modeling of mobile and ad hoc networks . Pervasive and wearable computing . Physical layer design of ad hoc networks . Power control protocols for ad hoc and sensor networks . Pricing modeling and solutions . QoS provisioning in medium access control and routing . Resource management algorithms in mobile, wireless and ad-hoc networks . RF channel capacity modeling and analysis . Service discovery in Ad hoc networks . Simulation and measurement based evaluation of ad hoc and sensor . Survivability and reliability evaluation and modeling . Synchronization and scheduling in mobile ad hoc and sensor networks systems . Topology control and management . Ubiquitous, pervasive and mobile access . Wireless ad hoc and sensor devices . Wireless PANs, LANs based Ad hoc networks Technical Program Committee, whose complete list can be found at Homepage: http://paradise.site.uottawa.ca/~Globecom07-SensorNet -- Esta mensagem foi verificada pelo sistema de antivírus e acredita-se estar livre de perigo. _______________________________________________ Researchers mailing list Researchers@mailman.ufsc.br http://mailman.ufsc.br/mailman/listinfo/researchers -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 12 12:56:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfPG-0002Kt-6K; Mon, 12 Feb 2007 12:56:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0fh-0006Sj-SK; Sat, 10 Feb 2007 17:26:17 -0500 Received: from [2001:12f0:201:1:202:e3ff:fe0f:b8d] (helo=mailman.ufsc.br) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0ff-0004m4-NU; Sat, 10 Feb 2007 17:26:17 -0500 Received: from localhost (localhost [127.0.0.1]) by mailman.ufsc.br (Postfix) with ESMTP id 138867F63F; Sat, 10 Feb 2007 20:24:07 -0200 (BRST) Received: from mailman.ufsc.br ([127.0.0.1]) by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02759-03; Sat, 10 Feb 2007 20:24:06 -0200 (BRST) Received: from mailman.ufsc.br (mailman.ufsc.br [150.162.1.5]) by mailman.ufsc.br (Postfix) with ESMTP id 030797EE31; Sat, 10 Feb 2007 20:04:16 -0200 (BRST) X-Original-To: researchers@mailman.ufsc.br Delivered-To: researchers@mailman.ufsc.br Received: from localhost (localhost [127.0.0.1]) by mailman.ufsc.br (Postfix) with ESMTP id CBF2E7F3A3 for ; Sat, 10 Feb 2007 20:04:04 -0200 (BRST) Received: from mailman.ufsc.br ([127.0.0.1]) by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01232-06 for ; Sat, 10 Feb 2007 20:03:55 -0200 (BRST) Received: from rot.barddal.br (44054.static.fln.virtua.com.br [200.174.44.54]) by mailman.ufsc.br (Postfix) with ESMTP id 3777F7F007 for ; Sat, 10 Feb 2007 19:59:11 -0200 (BRST) Received: from mi0f9a3e303b4e (201-24-98-168.fnsce703.dsl.brasiltelecom.net.br [201.24.98.168]) (authenticated bits=0) by rot.barddal.br (8.13.1/8.13.1) with ESMTP id l1ALwp7s024791; Sat, 10 Feb 2007 21:58:51 GMT Message-ID: <025101c74d5e$b9360be0$6800a8c0@mi0f9a3e303b4e> From: "Profa Mirela Sechi Moretti Annoni Notare" To: Date: Sat, 10 Feb 2007 19:59:21 -0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-barddal-MailScanner-Information: Please contact the ISP for more information X-barddal-MailScanner: Found to be clean X-barddal-MailScanner-SpamScore: sss X-barddal-MailScanner-From: mirela@barddal.br X-Virus-Scanned: by amavisd-new at mailman.ufsc.br X-BeenThere: researchers@mailman.ufsc.br X-Mailman-Version: 2.1.5 Precedence: list X-Virus-Scanned: by amavisd-new at mailman.ufsc.br X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-Mailman-Approved-At: Mon, 12 Feb 2007 12:56:00 -0500 Cc: Subject: [Mip4] [Researchers] 10th ACM/IEEE MSWiM 2007 - Chania, Crete Island, Greece - October 22-26, 2007 X-BeenThere: mip4@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Sorry if you have received multiple messages. --------------------------------------------------------------------------- 10th ACM/IEEE MSWiM 2007 --------------------------------------------------------------------------- Call for Papers The 10th ACM/IEEE* International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems Chania, Crete Island, Greece October 22 - 26, 2007 http://www.cs.unibo.it/mswim2007 -------------------------------------------------------------------------- * IEEE/ACM Pending Upon Approval -------------------------------------------------------------------------- Submission deadline: May 2, 2007 -------------------------------------------------------------------------- * Scope and Overview: ACM/IEEE MSWiM 2007 is the Tenth Annual International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems. MSWiM is an international forum dedicated to high level discussion of Wireless and Mobile systems, networks, algorithms and applications, with an emphasis on rigorous performance evaluation. MSWiM is a highly selective conference that is recognized as one of the most prestigious sources of innovative ideas and breakthroughs in the field. MSWiM 2007 will be held October 22 to 26, 2007, in the beautiful and sunny Chania, Crete Island, Greece. Authors are encouraged to submit full papers presenting new research related to the theory or practice of all aspects of modeling, analysis and simulation of mobile and wireless systems. Submitted papers must not have been published elsewhere nor currently be under review by another conference or journal. * Topics of Interest. Papers related to wireless and mobile network Modeling, Analysis, Design, and Simulation are solicited on, but not limited to, the following topics in mobile and wireless systems: - Performance evaluation and modeling - Analytical Models - Simulation languages and tools for wireless systems - Wireless measurements tools and experiences - Formal methods for analysis of wireless systems - Correctness, survivability and reliability evaluation - Mobility modeling and management - Capacity, coverage and connectivity modeling and analysis - Wireless network algorithms and protocols - Wireless PANs, LANs - Ad hoc networks - Sensor and actuator networks - Integration of wired and wireless systems - Pervasive computing and emerging models - Wireless multimedia systems - QoS provisioning in wireless and mobile networks - Security and privacy of mobile/wireless systems - Algorithms and protocols for energy efficient operation and power control - Mobile applications, system software and algorithms - RF channel modeling and analysis - Design methodologies - Tools, prototype and testbeds - Parallel and distributed simulation of wireless systems Submission instructions and publication can be found at (http://www.cs.unibo.it/mswim2007). Accepted papers will appear in the conference proceedings to be published by ACM press. A Journal Special Issue will be planned for extended versions of the best papers from MSWiM. -------------------------------------------------------------------------- *Important Dates: Paper submission deadline May 2, 2007 Notification of acceptance July 6, 2007 Tutorial submission deadline June 5, 2007 Workshop submission deadline March 30, 2007 -------------------------------------------------------------------------- General Chair: Carla-Fabiana Chiasserini, Politecnico di Torino, Italy Program Committee Chairs: Nael Abu-Ghazaleh, State University of New York at Binghamton, USA Sotiris Nikoletseas, University of Patras and CTI, Greece Tutorial Chair Stephan Olariu, Old Dominion University, USA Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan Workshop Chair Mohamed Ould-Khaoua, University of Glasgow, UK Poster Co-Chairs: Xi Zhang, Texas A&M University, USA Jelena Misic, University of Manitoba, Canada Publicity Chair Mirela Notare, Barddal University, Brazil Demo Co-Chairs Ioannis Chatzigiannakis, University of Patras and CTI, Greece Damla Turgut, University of Central Florida, USA Webmaster and System Chair Luciano Bononi, Uinversity of Bologna, Italy Steering Committee Chair Azzedine Boukerche, University of Ottawa, Canada Program Committee http://www.cs.unibo.it/projects/mswim2007/committee.htm -- Esta mensagem foi verificada pelo sistema de antivírus e acredita-se estar livre de perigo. _______________________________________________ Researchers mailing list Researchers@mailman.ufsc.br http://mailman.ufsc.br/mailman/listinfo/researchers -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 14 11:02:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMal-0008M7-EP; Wed, 14 Feb 2007 11:02:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHMaj-0008Lz-FX for mip4@ietf.org; Wed, 14 Feb 2007 11:02:45 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHMag-0007Ll-2V for mip4@ietf.org; Wed, 14 Feb 2007 11:02:45 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-13.tower-127.messagelabs.com!1171468960!11517434!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 2847 invoked from network); 14 Feb 2007 16:02:40 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-13.tower-127.messagelabs.com with SMTP; 14 Feb 2007 16:02:40 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l1EG2ecI010966 for ; Wed, 14 Feb 2007 09:02:40 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l1EG2dva019934 for ; Wed, 14 Feb 2007 10:02:40 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt Date: Wed, 14 Feb 2007 11:02:38 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt Thread-Index: AcdK+eDFrgz4osiRRXWy5BxLcFLOxwFVyeBg References: From: "McCann Peter-A001034" To: "Petrescu Alexandru-AAP021" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Alex, Does this new version address all of your comments? Rajeev, I note that there are a number of nits found by the idnits tool at=20 http://tools.ietf.org/wg/mip4/draft-ietf-mip4-fmipv4/draft-ietf-mip4-fmi pv4-03.nits.txt Could you please take care of them? Assuming Alex is ok and the nits are addressed, I will go ahead with requesting publication. -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 > This draft is a work item of the Mobility for IPv4 Working Group of > the IETF.=20 >=20 > Title : Mobile IPv4 Fast Handovers > Author(s) : R. Koodli, C. Perkins > Filename : draft-ietf-mip4-fmipv4-03.txt > Pages : 28 > Date : 2007-2-7 >=20 > This document adapts the Mobile IPv6 Fast Handovers [1] to > improve delay and packet loss resulting from Mobile IPv4 handover > operations. Specifically, this document addresses movement > detection, IP address configuration and location update latencies > during a handover. For reducing the IP address configuration > latency, the document proposes that the new Care-of Address is > always made to be the new access router's IP address. Additional > mechanisms may be defined in the future versions of this document. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-03.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > 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-mip4-fmipv4-03.txt". =20 >=20 > 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 =20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip4-fmipv4-03.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 14 13:45:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHP8N-0004wO-Dg; Wed, 14 Feb 2007 13:45:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHP8M-0004wJ-PE for mip4@ietf.org; Wed, 14 Feb 2007 13:45:38 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHP8K-00057T-Dl for mip4@ietf.org; Wed, 14 Feb 2007 13:45:38 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1171478735!858582!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1769 invoked from network); 14 Feb 2007 18:45:35 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 14 Feb 2007 18:45:35 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1EIjV4U002604 for ; Wed, 14 Feb 2007 11:45:35 -0700 (MST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1EIjUuK024672 for ; Wed, 14 Feb 2007 12:45:30 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Consensus call: draft-tsirtsis-nemov4-dynamic-01.txt and draft-tsirtsis-nemov4-fa-01.txt Date: Wed, 14 Feb 2007 13:45:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Consensus call: draft-tsirtsis-nemov4-dynamic-01.txt and draft-tsirtsis-nemov4-fa-01.txt Thread-Index: AcdHGGi3lBkMp+DOSX+0VMhlUJDf8QJT3siw References: From: "McCann Peter-A001034" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org We didn't get any responses to this consensus call. If you have an opinion on this please speak up. -Pete McCann Peter-A001034 wrote: > During the mip4 meeting in San Diego, we saw a presentation > from George Tsirtsis on two extensions of the nemov4 work. >=20 > The charter calls out the work on dynamic address assignment > and FA support as work items for the working group. >=20 > This is a call for consensus to see whether we are ready to > adopt these two drafts as working group items. >=20 > Please respond by next Friday, February 9th, on whether you > think we are ready to adopt these two drafts as working group > items. >=20 > -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 14 14:39:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPyh-00021w-UN; Wed, 14 Feb 2007 14:39:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPyg-00021r-R9 for mip4@ietf.org; Wed, 14 Feb 2007 14:39:42 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHPyf-0002ba-EP for mip4@ietf.org; Wed, 14 Feb 2007 14:39:42 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1171481980!10251990!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 12742 invoked from network); 14 Feb 2007 19:39:40 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-15.tower-119.messagelabs.com with SMTP; 14 Feb 2007 19:39:40 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l1EJdek6027756 for ; Wed, 14 Feb 2007 12:39:40 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l1EJdcKS006234; Wed, 14 Feb 2007 13:39:39 -0600 (CST) Message-ID: <45D36579.401@motorola.com> Date: Wed, 14 Feb 2007 20:39:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org McCann Peter-A001034 wrote: > Alex, > > Does this new version address all of your comments? Yes, it addresses most of the comments I've raised recently, thanks Rajeev. Checksum copypaste is there. There may be however some editorial consistency. I've read it detail, checking for consistency of spec, not of protocol, and I believe there are some text consistency issues. I went through the pain of reporting them all, but I realize that if some of them are addressed then new ones may arise, etc. So I'm not sure how much should I insist on this. For example I believe the document could benefit from its own Terminology section, easier for reader than to search for eg 'PAR' in the FMIPv6 RFC. Then the reference to 802.11r isn't here either, and 802.11r specifically uses MAC messages that look very much like FMIP (discovery of neighborhood through beacons, etc). Then are the following: reference [1][2], flags Codes and other contents decriptions, coherent address assignment, MAC address length, HI/HAck protection, etc. See below. Thanks for asking, Alex --------------------------------------------------------------------- > This document assumes that the reader is familiar with the basic > operation and terminology of Mobile IPv4 [1] and Fast Handovers for > Mobile IPv6 [1]. '[1]' is FMIPv6 and MIPv4 is none. Suggest replace the first '[1]' with a '[2]'. In several places throughout the document this should be made sure ok. Still editorial: "protocol disengages" instead of "protocol disengage". But these kinds could be caught by last stages of editing I believe. Figure 1 "Predictive" pictures at bottom an FBU sent to NAR and then NAR forwards it to PAR. In a way it makes sense for "Predictive" but it clashes with "Reactive" where the FBU is really sent to NAR IP address. Suggest FBU Predictive to NAR be not ">" but somehow ")". > In any case, NAR MUST forward the contents of this message, starting > from the Type field, to PAR, which means the Source and Destination > IP addresses now contain the IP addresses of NAR and PAR > respectively. Well, pure 'forwarding' doesn't modify any packet except for TTL. The above text seems to mistake 'forwarding' with creation of a new IP header and copying the ICMP contents from the received packet to the new. Suggest eliminate use of 'forward' and use 'transmit'. Or use the terms 'rewrite addresses in IP headers'. Or maybe I'm too picky on the term 'forwarding'... but should be clear to reader that this is either a new packet or address rewriting. > The protocol provides an option for NAR to return NCoA for use by the > mobile node. When NAR can provide an NCoA for exclusive use of the > mobile node, the address is supplied in the HAck message. The PAR > includes this NCoA in FBack. Suggest add text to say that this method of address allocation has strong implications on the use of DHCP or IPv4 Stateless Address Auto-configuration. If HAck-assigned addresses are used then DHCP and SLAAC shouldn't be used, or similar. > Sending FBU from the new link (i.e., reactive mode) is similar to > using the extension defined in [2]. Reference [2] is MIP4, should be [1] FMIPv6? > The FBU format is bitwise identical to the Registration Request > format in RFC 3344. Use '[2]' instead of RFC3344? Or '[RFC3344]'? Or '[2] (RFC3344)'? Rather than writing only 'RFC 3344'. FBU Flags: > x|x|D|M|G|r|T|x > Flags See RFC 3344 RFC3344 RegReq Flags: > S|B|D|M|G|r|T|x > S - simultaneous bindings > B - broadcast datagrams Suggest text to say that FMIPv4 on AR ignores flags S and B and MN sets them both to '0'. > Home Address MUST be PCoA (i.e., either co-located CoA or > Home Address) Suggest text 'MUST be PCoA, as a co-located CoA or as MN's Home Address', otherwise risk of reading 'Home Address MUST be Home Address'. FBack contents: > Identification a 64-bit number used for matching FBU. See > RFC 3344. Suggest text to say that the Id is copied from the FBU this is a reply to. This text is already written in the HAck id to HI. PrRtAdv contents: > Code 0, 1, 2, 3 or 4. See below. Below are described only Codes 0 and 1. But at least till the end of the section 5.4 there's no description of codes 2, 3 nor 4. Suggest to describe the effects of using all codes (0-4) in this section. Is this the same Codes in HAck (section 5.5.2)? HAck codes make no sense in PrRtAdv. What is it, sorry? PrRtAdv contents: > New CoA Option > MAY be present when PrRtAdv is sent > unsolicited. PAR MAY compute new CoA using NAR's > prefix information and the MN's L2 address, or by > any other means. Suggest text to say that in case the PrRtAdv option contains a new CoA to be assigned by the MN then this has strong impacts on the use of DHCP or SLAAC, in addition to the use of HAck-assigned addresses. HI Contents: > New Care of Address > The IP address the MN wishes to use when > connected to the destination. When the `S' bit is > set, NAR MAY assign this address. Specify that if this field is present then the NCoA in HAck and in PrRtAdv contain the same thing, and that it has impacts on the use of DHCP and SLAAC. Option formats: > Length The length of the option (including the type and > length fields) in units of octets. For example, > the length for IEEE 802 addresses is 1 [IPv6- > ETHER]. '[IPv6-ETHER]' reference is undefined. I don't know where it should point. IEEE 802 MAC addresses are 6octet long (48bits). Type+Len+MAC would make for 10 octets. I'm not sure what was the authors' intention on how to encode this, but it's not clear. Or maybe it was meant 'in units of 10 octets'? > 6.2. New IPv4 Address Option Format > > This option is used to provide the new router's IPv4 address in > PrRtAdv. ... or the NCoA in PrRtAdv. > New IPv4 Address > NAR's IPv4 address or the NCoA assigned by NAR. ...or the NCoA... > 7. Security Considerations > > The FBU and FBack messages MUST be protected Suggest text to say that HI/HAck must be protected too. > 8. IANA Considerations Suggest text to say that Types, Sub-types and Codes are to be assigned supposedly from two different spaces: ICMP and Mobile IP. Pete wrote: > > Rajeev, I note that there are a number of nits found by the idnits > tool at > http://tools.ietf.org/wg/mip4/draft-ietf-mip4-fmipv4/draft-ietf-mip4-fmi > pv4-03.nits.txt > > Could you please take care of them? > > Assuming Alex is ok and the nits are addressed, I will go ahead with > requesting publication. > > -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 14 14:44:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQ2q-0002j6-KX; Wed, 14 Feb 2007 14:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQ2p-0002iy-Ha for mip4@ietf.org; Wed, 14 Feb 2007 14:43:59 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHQ2o-0002wm-4c for mip4@ietf.org; Wed, 14 Feb 2007 14:43:59 -0500 X-VirusChecked: Checked X-Env-Sender: pete.mccann@motorola.com X-Msg-Ref: server-12.tower-153.messagelabs.com!1171482237!1942415!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 16436 invoked from network); 14 Feb 2007 19:43:57 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-153.messagelabs.com with SMTP; 14 Feb 2007 19:43:57 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l1EJhuU4000404 for ; Wed, 14 Feb 2007 13:43:56 -0600 (CST) Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l1EJhtJ6008801 for ; Wed, 14 Feb 2007 13:43:56 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] I-D ACTION:draft-ietf-mip4-radius-requirements-01.txt Date: Wed, 14 Feb 2007 14:43:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-radius-requirements-01.txt Thread-Index: AcdGQtsTKxEpLwmZRH2nZTh3buGbrAKLPTgg References: From: "McCann Peter-A001034" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org We haven't seen any list discussion of this draft. Do working group members feel it is ready for working group last call? One comment I had: the document repeatedly refers to=20 draft-nakhjiri-radius-mip4-02.txt which is a solutions document. To me, it would seem better to have a requirements document that stands on its own and isn't an attempt to justify a particular solution. In this same vein, I would recommend taking all of the "non-goals" and re-wording them to be "solution constraints". The constraints should be justified in terms of minimal impact to existing RADIUS deployments, etc. Any other thoughts? -Pete Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 > This draft is a work item of the Mobility for IPv4 Working Group of > the IETF.=20 >=20 > Title : Mobile IPv4 RADIUS requirements > Author(s) : M. Nakhjiri, et al. > Filename : draft-ietf-mip4-radius-requirements-01.txt > Pages : 8 > Date : 2007-2-1 >=20 > This document provides an applicability statement as well as a scope > definition for the specification provided in the document "RADIUS > Mobile IPv4 extension" and its future revisions hereby collectively > referred to as [I-D.nakhjiri-radius-mip4]. The goal is to justify > qualification of [I-D.nakhjiri-radius-mip4] as a IETF work item. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip4-radius-requirements- 01.txt >=20 > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. =20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > 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-mip4-radius-requirements-01.txt". =20 >=20 > 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 =20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mip4-radius-requirements-01.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 14 14:55:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQE1-0001Wa-O4; Wed, 14 Feb 2007 14:55:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQE0-0001WV-TN for mip4@ietf.org; Wed, 14 Feb 2007 14:55:32 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHQDz-0003xy-JB for mip4@ietf.org; Wed, 14 Feb 2007 14:55:32 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1171482930!1388777!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 11903 invoked from network); 14 Feb 2007 19:55:30 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-15.tower-128.messagelabs.com with SMTP; 14 Feb 2007 19:55:30 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l1EK06Pa014847 for ; Wed, 14 Feb 2007 13:00:06 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1EJphti029574; Wed, 14 Feb 2007 13:51:44 -0600 (CST) Message-ID: <45D3684E.80309@motorola.com> Date: Wed, 14 Feb 2007 20:51:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: McCann Peter-A001034 Subject: Re: [Mip4] Consensus call: draft-tsirtsis-nemov4-dynamic-01.txt and draft-tsirtsis-nemov4-fa-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org McCann Peter-A001034 wrote: > We didn't get any responses to this consensus call. > If you have an opinion on this please speak up. Oh yes, sorry it's the 14th already. I mainly do support the two drafts. However, I would appreciate if any competitor draft shows up in this same direction, such that we take on 'items' and decide for 'documents' as 'items' with a better perspective. I think I do support more the FA work, because it appears to only have interactions with NEMOv4 base. And the tsirtsis draft on FA work - I support. The DAA (dynamic address assignment) may have interactions with dynamic HA assignment RFC 4433. For example could a MR send only _one_ RegReq and receive both a MNP _and_ a HA address _and_ a HoA. The DAA in draft-tsirtsis-nemov4-dynamic-01.txt talks about use of Regreq and RegRep to assign prefixes to a NEMOv4 MR. This mechanism is useful and needed at least in the types of deployments I work for. However DAA may need to interact somehow with DHCP prefix delegation, or somehow state they're independent and work together or similar. It also depends what the NEMO WG does with the two dynamic MNP configuration drafts: is that MIP6-based or DHCP-based. I think v4 and v6 DAA should happen the same way (either MIP-based or DHCP-based). So that's what I think... Alex > > -Pete > > McCann Peter-A001034 wrote: >> During the mip4 meeting in San Diego, we saw a presentation >> from George Tsirtsis on two extensions of the nemov4 work. >> >> The charter calls out the work on dynamic address assignment >> and FA support as work items for the working group. >> >> This is a call for consensus to see whether we are ready to >> adopt these two drafts as working group items. >> >> Please respond by next Friday, February 9th, on whether you >> think we are ready to adopt these two drafts as working group >> items. >> >> -Pete > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 14 23:47:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYX3-0007jq-Mj; Wed, 14 Feb 2007 23:47:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYX1-0007jF-Ur for mip4@ietf.org; Wed, 14 Feb 2007 23:47:43 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHYWz-0006LO-4u for mip4@ietf.org; Wed, 14 Feb 2007 23:47:43 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1F4hkZ8018814; Thu, 15 Feb 2007 06:44:06 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 06:47:06 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 22:47:03 -0600 Received: from 10.162.253.9 ([10.162.253.9]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Feb 2007 04:47:03 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 14 Feb 2007 20:47:54 -0800 Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt From: Rajeev Koodli To: ext Alexandru Petrescu , McCann Peter-A001034 Message-ID: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt Thread-Index: AcdQvHRhsvw64LyvEdu4ewAWy5YJpw== In-Reply-To: <45D36579.401@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Feb 2007 04:47:03.0669 (UTC) FILETIME=[56621250:01C750BC] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070215064406-47FFDBB0-0E25C7EC/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Alex, On 2/14/07 11:39 AM, "ext Alexandru Petrescu" wrote: > McCann Peter-A001034 wrote: >> Alex, >> >> Does this new version address all of your comments? > > Yes, it addresses most of the comments I've raised recently, thanks > Rajeev. Checksum copypaste is there. > > There may be however some editorial consistency. I've read it detail, > checking for consistency of spec, not of protocol, and I believe there > are some text consistency issues. I went through the pain of reporting > them all, but I realize that if some of them are addressed then new ones > may arise, etc. So I'm not sure how much should I insist on this. I agree that any editorial issues need to be addressed, and thanks for doing the review. However, some may be more like "style" issues (e.g., the Figure for predictive handover, which is borrowed from RFC4068), which are best left alone at this stage. Also, RFC Editor will catch/suggest some changes too. Also, our thinking has been that folks should use RFC4068 alongside this document. Otherwise, we will be obliged to put large portions of that document here. Although I agree that the document should be self-contained as much as possible, we need to recognize the normative dependency both for concepts and protocol dynamics. I will look at the comments below and revise the document. -Rajeev > > For example I believe the document could benefit from its own > Terminology section, easier for reader than to search for eg 'PAR' in > the FMIPv6 RFC. > > Then the reference to 802.11r isn't here either, and 802.11r > specifically uses MAC messages that look very much like FMIP (discovery > of neighborhood through beacons, etc). > > Then are the following: reference [1][2], flags Codes and other contents > decriptions, coherent address assignment, MAC address length, HI/HAck > protection, etc. See below. > > Thanks for asking, > > Alex > > --------------------------------------------------------------------- >> This document assumes that the reader is familiar with the basic >> operation and terminology of Mobile IPv4 [1] and Fast Handovers for >> Mobile IPv6 [1]. > > '[1]' is FMIPv6 and MIPv4 is none. Suggest replace the first '[1]' with > a '[2]'. In several places throughout the document this should be made > sure ok. > > Still editorial: "protocol disengages" instead of "protocol disengage". > But these kinds could be caught by last stages of editing I believe. > > Figure 1 "Predictive" pictures at bottom an FBU sent to NAR and then NAR > forwards it to PAR. In a way it makes sense for "Predictive" but it > clashes with "Reactive" where the FBU is really sent to NAR IP address. > Suggest FBU Predictive to NAR be not ">" but somehow ")". > >> In any case, NAR MUST forward the contents of this message, starting >> from the Type field, to PAR, which means the Source and Destination >> IP addresses now contain the IP addresses of NAR and PAR >> respectively. > > Well, pure 'forwarding' doesn't modify any packet except for TTL. The > above text seems to mistake 'forwarding' with creation of a new IP > header and copying the ICMP contents from the received packet to the > new. Suggest eliminate use of 'forward' and use 'transmit'. Or use the > terms 'rewrite addresses in IP headers'. > > Or maybe I'm too picky on the term 'forwarding'... but should be clear > to reader that this is either a new packet or address rewriting. > >> The protocol provides an option for NAR to return NCoA for use by the >> mobile node. When NAR can provide an NCoA for exclusive use of the >> mobile node, the address is supplied in the HAck message. The PAR >> includes this NCoA in FBack. > > Suggest add text to say that this method of address allocation has > strong implications on the use of DHCP or IPv4 Stateless Address > Auto-configuration. If HAck-assigned addresses are used then DHCP and > SLAAC shouldn't be used, or similar. > >> Sending FBU from the new link (i.e., reactive mode) is similar to >> using the extension defined in [2]. > > Reference [2] is MIP4, should be [1] FMIPv6? > >> The FBU format is bitwise identical to the Registration Request >> format in RFC 3344. > > Use '[2]' instead of RFC3344? Or '[RFC3344]'? Or '[2] (RFC3344)'? > Rather than writing only 'RFC 3344'. > > FBU Flags: >> x|x|D|M|G|r|T|x >> Flags See RFC 3344 > > RFC3344 RegReq Flags: >> S|B|D|M|G|r|T|x >> S - simultaneous bindings >> B - broadcast datagrams > > Suggest text to say that FMIPv4 on AR ignores flags S and B and MN sets > them both to '0'. > >> Home Address MUST be PCoA (i.e., either co-located CoA or >> Home Address) > > Suggest text 'MUST be PCoA, as a co-located CoA or as MN's Home > Address', otherwise risk of reading 'Home Address MUST be Home Address'. > > FBack contents: >> Identification a 64-bit number used for matching FBU. See >> RFC 3344. > > Suggest text to say that the Id is copied from the FBU this is a reply > to. This text is already written in the HAck id to HI. > > > PrRtAdv contents: >> Code 0, 1, 2, 3 or 4. See below. > > Below are described only Codes 0 and 1. But at least till the end of > the section 5.4 there's no description of codes 2, 3 nor 4. Suggest to > describe the effects of using all codes (0-4) in this section. > > Is this the same Codes in HAck (section 5.5.2)? HAck codes make no > sense in PrRtAdv. What is it, sorry? > > PrRtAdv contents: >> New CoA Option >> MAY be present when PrRtAdv is sent >> unsolicited. PAR MAY compute new CoA using NAR's >> prefix information and the MN's L2 address, or by >> any other means. > > Suggest text to say that in case the PrRtAdv option contains a new CoA > to be assigned by the MN then this has strong impacts on the use of DHCP > or SLAAC, in addition to the use of HAck-assigned addresses. > > HI Contents: >> New Care of Address >> The IP address the MN wishes to use when >> connected to the destination. When the `S' bit is >> set, NAR MAY assign this address. > > Specify that if this field is present then the NCoA in HAck and in > PrRtAdv contain the same thing, and that it has impacts on the use of > DHCP and SLAAC. > > Option formats: >> Length The length of the option (including the type and >> length fields) in units of octets. For example, >> the length for IEEE 802 addresses is 1 [IPv6- >> ETHER]. > > '[IPv6-ETHER]' reference is undefined. I don't know where it should point. > > IEEE 802 MAC addresses are 6octet long (48bits). > > Type+Len+MAC would make for 10 octets. > > I'm not sure what was the authors' intention on how to encode this, but > it's not clear. > > Or maybe it was meant 'in units of 10 octets'? > >> 6.2. New IPv4 Address Option Format >> >> This option is used to provide the new router's IPv4 address in >> PrRtAdv. > > ... or the NCoA in PrRtAdv. > >> New IPv4 Address >> NAR's IPv4 address or the NCoA assigned by NAR. > ...or the NCoA... > >> 7. Security Considerations >> >> The FBU and FBack messages MUST be protected > > Suggest text to say that HI/HAck must be protected too. > >> 8. IANA Considerations > > Suggest text to say that Types, Sub-types and Codes are to be assigned > supposedly from two different spaces: ICMP and Mobile IP. > > Pete wrote: >> >> Rajeev, I note that there are a number of nits found by the idnits >> tool at >> http://tools.ietf.org/wg/mip4/draft-ietf-mip4-fmipv4/draft-ietf-mip4-fmi >> pv4-03.nits.txt >> >> Could you please take care of them? >> >> Assuming Alex is ok and the nits are addressed, I will go ahead with >> requesting publication. >> >> -Pete > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 15 04:07:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHcag-00044l-90; Thu, 15 Feb 2007 04:07:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHcaf-00044T-5k for mip4@ietf.org; Thu, 15 Feb 2007 04:07:45 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHcad-0005iM-Pp for mip4@ietf.org; Thu, 15 Feb 2007 04:07:45 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-153.messagelabs.com!1171530462!865738!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9366 invoked from network); 15 Feb 2007 09:07:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-153.messagelabs.com with SMTP; 15 Feb 2007 09:07:42 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1F97gR0019387; Thu, 15 Feb 2007 02:07:42 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1F97d9k006328; Thu, 15 Feb 2007 03:07:40 -0600 (CST) Message-ID: <45D422D8.3010309@motorola.com> Date: Thu, 15 Feb 2007 10:07:36 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mip4@ietf.org, McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev Koodli wrote: > Hi Alex, > > On 2/14/07 11:39 AM, "ext Alexandru Petrescu" > wrote: > >> McCann Peter-A001034 wrote: >>> Alex, >>> >>> Does this new version address all of your comments? >> Yes, it addresses most of the comments I've raised recently, thanks >> Rajeev. Checksum copypaste is there. >> >> There may be however some editorial consistency. I've read it detail, >> checking for consistency of spec, not of protocol, and I believe there >> are some text consistency issues. I went through the pain of reporting >> them all, but I realize that if some of them are addressed then new ones >> may arise, etc. So I'm not sure how much should I insist on this. > > I agree that any editorial issues need to be addressed, and thanks for doing > the review. However, some may be more like "style" issues (e.g., the Figure > for predictive handover, which is borrowed from RFC4068), which are best > left alone at this stage. Also, RFC Editor will catch/suggest some changes > too. I agree the Figure remark can be considered style, to the extent that one can talk 'style' with a text file :-) (use ')' arrows instead of '>' when forwarding through an entity). I agree that some nits will be caught by RFC Editor and they'll surely suggest additional changes. > Also, our thinking has been that folks should use RFC4068 alongside this > document. Otherwise, we will be obliged to put large portions of that > document here. Although I agree that the document should be self-contained > as much as possible, we need to recognize the normative dependency both for > concepts and protocol dynamics. I think folks reading two RFCs instead of one is a burden. If the two RFCs were dependent (implement rfc4068 in order to be able to implement this draft) then I agree with you. But they seem very separate, one can easily implement FMIPv4 w/o FMIPv6 and vice-versa. The dependency FMIPv4-FMIPv6 is much less than FMIPv4-MIPv4. This discussion is about inserting or not a Terminology section in this draft, right? I suggest to do it, for the reasons above. What do the others think about this? > I will look at the comments below and revise the document. Thanks Rajeev, Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 15 08:45:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHgvg-00069n-PV; Thu, 15 Feb 2007 08:45:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG69d-0003cn-Ax for mip4@ietf.org; Sat, 10 Feb 2007 23:17:33 -0500 Received: from ece.uprm.edu ([136.145.57.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG69W-0005RU-MN for mip4@ietf.org; Sat, 10 Feb 2007 23:17:33 -0500 Received: from kejielupc (perazzamac2.ece.uprm.edu [136.145.57.158]) by ece.uprm.edu (Postfix) with SMTP id C343254C27 for ; Sun, 11 Feb 2007 00:17:23 -0400 (AST) Organization: UPR-Mayaguez Message-ID: <2f31cd96101f033faf154145001ba1b8@ece.uprm.edu> From: "Kejie Lu" To: Date: Sun, 11 Feb 2007 00:17:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-Mailman-Approved-At: Thu, 15 Feb 2007 08:45:43 -0500 Subject: [Mip4] CALL FOR PAPERS MILCOM 2007 (Abstract Due on Feb. 16) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukejie@ece.uprm.edu List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ** Apologies if you receive multiple copies of this message ** ** The deadline for submitting the abstract is: 16 February 2007 ** ** The link for submitting the unclassified papers is: = https://wams.jspargo.com/milcom07/login.asp ** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL for PAPERS MILCOM 2007 October 29=9631, 2007 Gaylord Palms Convention Center Orlando, Florida USA Conference Theme:=20 Interoperability: Policy to Performance MILCOM 2007 is soliciting both unclassified and classified papers (up to = DoD Secret) relevant to communications and information processing system = technologies and capabilities that address the 21st century challenges of = National Defense, Homeland Security, Disaster Response and = Interoperability. Industry, academic, and government organizations from = both the U.S. and countries around the globe are invited and encouraged to = participate=2E Important Dates Abstracts Due: 16 February 2007 Draft Papers Due: 20 April 2007 Author Notification: 25 May 2007 Final Camera Ready Papers Due: 6 July 2007 Suggested technical areas of general interest include but are not limited to: =95 Interoperability =96 Policies and Standards =96 DoD and Federal Agencies =96 State and Local Governments =96 Emergency Grid Communications =96 Coalition Partners =96 Disaster Response =95 Service Oriented Architectures =95 Advanced Communications Technologies =95 Network Management =95 Mobile and Wireless Technologies =95 Radio Systems and Technologies =95 Network Centric Systems and Technologies =95 Applications and Operational Concepts =95 Systems, Programs and Initiatives =95 Information Management and Dissemination =95 Digital Signal Processing =95 Coding =95 Modulation =95 Advanced Waveforms =95 Next Generation Networks and Systems =95 Internet Protocols =95 Link Layer and Cross-Layer Protocols =95 Network Architectures and Routing =95 Transport Protocols and Performance =95 Quality of Service Architectures =95 Design Modeling and Simulation =95 Digital Video Broadcasting and Standards =95 IF/RF Technologies and Techniques =95 Advanced SATCOM systems =95 Airborne Technologies =95 Standards Based Datalinks =95 Mobile Satellite Systems =95 Space Networks and Protocols =95 Wireless Communications =95 Mobile Ad Hoc Networks =95 Computer and Network Security Systems =95 Software Defined Radios and Cognitive Radios =95 Sensor Networks =95 Advanced Antenna Technologies =95 Laser Communications and Optical Networks =95 Tests and Measurements =95 Ultra Wideband =95 Multimedia Communications and Management Technical Program Committee Technical Program Chair Dr. Vitas Mikenas Harris Corporation 321-729-7748 mikenas.milcom2007@harris.com Unclassified Program Chair Dr. Sastri Kota Harris Corporation 408-990-8301 kota.milcom2007@harris.com Classified Program Chair Terry Casto Harris Corporation 321-984-5600 casto.milcom2007@harris.com Panels Program Chair Leo deCardenas Harris Corporation 321-727-6202 decardenas.milcom2007@harris.com Tutorial Program Chair Rich Folio Harris Corporation 321-729-3629 folio.milcom2007@harris.com Unclassified Technical Program Submission Process:=20 The Web-based Abstract Management System (WAMS) (www.milcom.org) is used = to submit abstracts, full papers, and final camera ready papers. During = the abstract submission process, author and password information will need = to be entered and a Paper ID# will be assigned. This Paper ID# and = password will be used to upload papers. The abstract must NOT contain any = ITAR-related, classified, or proprietary information=2E Abstracts will only be used to help define the sessions. The Unclassified = Author=92s Kit provides instructions to authors for preparation of the = full and final manuscripts and the required forms. Full papers will be = reviewed for acceptance only when all appropriate forms have been = completed and received=2E Classified Technical Program Submission Process: All persons wishing to attend and/or participate in the Classified = Technical Program must, at a minimum, possess a current Secret personnel = security clearance and be a U.S. citizen. Non-U.S. originated papers will = NOT be accepted for the Classified Technical Program. All abstracts for = the Classified Technical Program must be unclassified. Please submit a = title and a brief unclassified abstract (up to 2000 characters) of your = intended paper via email to: casto.milcom2007@harris.com. Each submission = requires author name, affiliation, citizenship, address, phone and fax = numbers, email address, and the applicable area. For papers with more than = one author, indicate the point of contact. Do NOT use WAMS to submit = abstracts, full papers, or the final papers for the Classified Technical = Program. All papers for the Classified Technical Program must be prepared = following the instructions and formatting guidelines in the Classified = Author=92s Kit=2E Proposals for Tutorials and Panels:=20 MILCOM 2007 solicits proposals for unclassified half-day tutorials, and = unclassified and classified panels on state-of-the art communications, = networking, and interoperability technologies. The tutorial proposals = should include a brief outline of the tutorial, instructor biography, and = relevant instructor experience. The Unclassified Tutorials Kit provides the applicable forms and the formatting guidelines for the = tutorial material. Please forward your proposals to the MILCOM 2007 = Tutorial Program Chair, Rich Folio, at folio.milcom2007@harris.com=2E Proposals for Panels:=20 The proposals for panels should include a brief outline of the panel = discussion topics, panel participants, and panel moderator along with = their bios. A Panels Kit provides the information about the applicable = forms and the guidelines for the preparation of the panel material. Please = forward your proposals to the MILCOM 2007 Panels Program Chair, Leo = deCardenas, at decardenas.milcom2007@harris.com=2E Tutorials and Panels Important Dates: Proposals Due: 16 March 2007 Notification: 20 April 2007 Material Due: 13 July 2007 For further details and information about MILCOM 2007 please visit = www.milcom.org. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 15 08:46:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHgwt-0007li-Jv; Thu, 15 Feb 2007 08:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGhM4-00054A-UP for mip4@ietf.org; Mon, 12 Feb 2007 15:00:52 -0500 Received: from nucleon.liquidweb.com ([64.91.224.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGhM3-0007KJ-LO for mip4@ietf.org; Mon, 12 Feb 2007 15:00:52 -0500 Received: from c-69-136-253-7.hsd1.de.comcast.net ([69.136.253.7]:4629 helo=Oana2) by nucleon.liquidweb.com with esmtpa (Exim 4.52) id 1HGhLp-0005Pe-Bp for mip4@ietf.org; Mon, 12 Feb 2007 15:00:37 -0500 Message-ID: <30168161.1171310448875.JavaMail.Onitza@Oana2> Date: Mon, 12 Feb 2007 15:00:48 -0500 (EST) From: IARIA Invitation To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nucleon.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - iaria.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 X-Mailman-Approved-At: Thu, 15 Feb 2007 08:46:58 -0500 Subject: [Mip4] Call for Papers: ICIMP 2007 & ICDT 2007 & ICGD&BC 2007, Silicon Valley, July 1-6, 2007 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Invitation: Please consider contributing to the conferences ICIMP 2007 , ICDT 2007 and ICGD&BC 2007 as well as to the associated workshops listed below. Date: July 1-6, 2007 - Silicon Valley, USA Please forward the Call for Submissions to the appropriate groups. ======================================= CALL FOR PAPERS - ICDT 2007, The Second International Conference on Digital Telecommunications http://www.iaria.org/conferences2007/ICDT07.html - ICIMP 2007, The Second International Conference on Internet Monitoring and Protection http://www.iaria.org/conferences2007/ICIMP07.html - ICGD&BC 2007, The First International Conference on Global Defense and Business Continuity http://www.iaria.org/conferences2007/ICGDBC07.html _______________________________________________ Place: Silicon Valley, California Important deadlines: Full paper submission, February 20, 2007 Author notification, March 10, 2007 Registration and Camera ready March 31, 2007 ______________________________________________________________ Featuring the workshops: ICIMP 2007 Workshops: - SYVUL 2007: The First International Workshop on Systems Vulnerabilities - SYDIA 2007: The First International Workshop on Systems Diagnosis - CYBER-FRAUD 2007: The First International Workshop on Cyber-Fraud ICDT 2007 Workshops: - SARP 2007: The First International Workshop on Software Architecture Research and Practice - STREAM 2007: The First International Workshop on Data Stream Processing ICGD&BC 2007 Workshops: - TRACK 2007: The First International Workshop on Tracking Computing Technologies ______________________________________________________________ Conference Topics: ICIMP 2007 Tracks: TRASI: Internet traffic surveillance and interception IPERF: Internet Performance RTSEC: Security for Internet-based real-time systems DISAS: Disaster prevention and recovery EMERG: Networks and applications emergency services MONIT: End-to-end sampling, measurement, and monitoring REPORT: Experiences & lessons learnt in securing networks and applications USSAF: User safety, privacy, and protection over Interne ICDT 2007 Tracks: MULTE: Multimedia Telecommunications SIGNAL: Signal processing in telecommunications DATA: Data processing AUDIO: Audio transmission and reception systems VOICE: Voice over packet networks VIDEO: Video, conferencing, telephony IMAGE: Image producing, sending, and mining SPEECH: Speech producing and processing IPTV: IP/Mobile TV MULTI: Multicast/Broadcast Triple-Quadruple-play CONTENT: Production, distribution HXSIP: H-series towards SIP MEDMAN: Control and management of multimedia telecommunication ICGD&BC 2007 Tracks: BUSINESS: Business continuity RISK: Risk assessment DISASTER: Emergency services and disaster recovery TRUST: Privacy and trust in pervasive communications RIGHT: Digital rights management BIOTEC: Biometric techniques ======================================== Organizing Publicity Board ------------------------------------------------------------------------------------------------- To be removed from this announcement list, please reply with UNSUBSCRIBE in the subject field. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 15 12:06:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHk44-0001dK-7M; Thu, 15 Feb 2007 12:06:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHk43-0001dD-0k for mip4@ietf.org; Thu, 15 Feb 2007 12:06:35 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHk41-00054k-HO for mip4@ietf.org; Thu, 15 Feb 2007 12:06:35 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1FH2oLi026346; Thu, 15 Feb 2007 19:02:55 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 19:05:36 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 11:04:39 -0600 Received: from 10.162.253.7 ([10.162.253.7]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Thu, 15 Feb 2007 17:04:39 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 15 Feb 2007 09:05:34 -0800 Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt From: Rajeev Koodli To: ext Alexandru Petrescu Message-ID: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt Thread-Index: AcdRI4Fmv6qM970WEduPZAAWy5YJpw== In-Reply-To: <45D422D8.3010309@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Feb 2007 17:04:39.0481 (UTC) FILETIME=[60E71290:01C75123] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070215190255-65CCDBB0-68A9ED00/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip4@ietf.org, McCann Peter-A001034 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Okay, I will include the Terminology Section. Thanks, -Rajeev On 2/15/07 1:07 AM, "ext Alexandru Petrescu" wrote: > Rajeev Koodli wrote: >> Hi Alex, >> >> On 2/14/07 11:39 AM, "ext Alexandru Petrescu" >> wrote: >> >>> McCann Peter-A001034 wrote: >>>> Alex, >>>> >>>> Does this new version address all of your comments? >>> Yes, it addresses most of the comments I've raised recently, thanks >>> Rajeev. Checksum copypaste is there. >>> >>> There may be however some editorial consistency. I've read it detail, >>> checking for consistency of spec, not of protocol, and I believe there >>> are some text consistency issues. I went through the pain of reporting >>> them all, but I realize that if some of them are addressed then new ones >>> may arise, etc. So I'm not sure how much should I insist on this. >> >> I agree that any editorial issues need to be addressed, and thanks for doing >> the review. However, some may be more like "style" issues (e.g., the Figure >> for predictive handover, which is borrowed from RFC4068), which are best >> left alone at this stage. Also, RFC Editor will catch/suggest some changes >> too. > > I agree the Figure remark can be considered style, to the extent that > one can talk 'style' with a text file :-) (use ')' arrows instead of > '>' when forwarding through an entity). > > I agree that some nits will be caught by RFC Editor and they'll surely > suggest additional changes. > >> Also, our thinking has been that folks should use RFC4068 alongside this >> document. Otherwise, we will be obliged to put large portions of that >> document here. Although I agree that the document should be self-contained >> as much as possible, we need to recognize the normative dependency both for >> concepts and protocol dynamics. > > I think folks reading two RFCs instead of one is a burden. If the two > RFCs were dependent (implement rfc4068 in order to be able to implement > this draft) then I agree with you. But they seem very separate, one can > easily implement FMIPv4 w/o FMIPv6 and vice-versa. > > The dependency FMIPv4-FMIPv6 is much less than FMIPv4-MIPv4. > > This discussion is about inserting or not a Terminology section in this > draft, right? I suggest to do it, for the reasons above. What do the > others think about this? > >> I will look at the comments below and revise the document. > > Thanks Rajeev, > > Alex > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 15 17:47:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpNi-0002Wt-GH; Thu, 15 Feb 2007 17:47:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHpNh-0002WT-E2; Thu, 15 Feb 2007 17:47:13 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHpNe-0008PV-Q7; Thu, 15 Feb 2007 17:47:13 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8D5FF198775; Fri, 16 Feb 2007 00:47:09 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 38AB119862E; Fri, 16 Feb 2007 00:47:09 +0200 (EET) Message-ID: <45D4E2ED.8040702@piuha.net> Date: Fri, 16 Feb 2007 00:47:09 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , "Soliman, Hesham" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi George, Sorry for the delay in the answer. Too much going on elsewhere... I have reviewed your new version and the answer below. I'm not completely happy with the new text, but I would nevertheless like to take the draft forward. I do have three suggested changes below, which I have tentatively added as RFC Editor notes in the ID tracker. I'm putting the draft up for IESG evaluation and unless you object, the edits will be considered if and when the draft is approved. Or, if there are other reasons to edit the draft after the evaluation, you can adopt them for the next revision. Inline: > >>> Is this true under all circumstances? For instance, >>> is it true if one uses RFC 4285 or EAP for Mobile IPv6 >>> authentication? >>> >>> Depending on the answer, please reword >>> and add the necessary explanations. >>> >>> >> GT> I believe that, assuming nothing is changed, what the draft says >> > is > >> accurate since typically applications/protocols can not share keys >> unless security is implemented at a lower layer than that of the >> application/protocol. Still, I will add something to indicate that for >> some of the mechanisms listed and with further work, it might be >> possible to optimize operations. >> >> > Do you have text? We are not talking about typical applications, > we are talking about a very specific case. And there are many > applications that can share the same credentials through, say, > AAA. > > GT> Here is what I have. > " In addition, deploying both protocols will require duplication of > security credentials on mobile nodes and home agents. This includes, > IPsec security associations, keying material, and new authentication > protocols for Mobile IPv6, in addition to the security credentials > and associations required by Mobile IPv4. Depending on the security > mechanisms used and with some further work it might be possible to > optimize some of these processes. Assuming nothing else changes, > however, such duplication is again significant with no gain to the > operator or the mobile node." > Mumble. Perhaps "... possible to rely on one set of set common credentials. Assuming ..." But I wish the draft could say something specific about the actual possibility to do this. For instance, the draft could argue the neither RFC 4285 or EAP can support Mobile IPv4 authentication (if that is the case). > >>>> 3.1. Implementation burdens >>>> >>>> As mentioned above, a node that is IPv4 and IPv6 capable mustalso >>>> > be > >>>> >>>> MIPv4 and MIPv6 capable to roam within the Internet. Clearly this >>>> will add implementation efforts, which, we argue, are not >>>> > necessary. > >>>> >>>> In addition to the implementation efforts, some vendors may not >>>> support both protocols in either mobile nodes or home agents. >>>> Although this is more of a commercial issue, it does affect the >>>> large-scale deployment of mobile devices on the Internet. >>>> >>>> >>>> >>> I'm not sure this section reflects the complete >>> picture. In a situation where host vendors >>> are independent of those who deploy the >>> mobility infrastructure, for instance, its >>> not clear that there is any reduction in >>> implementation effort. >>> >>> Please reword for better balance. >>> >>> >>> >> GT> OK, I will clarify >> >> > Good. Again, I would like to see the text... > > GT> Here it is: > " As mentioned above, a node that is IPv4 and IPv6 capable must also be > MIPv4 and MIPv6 capable to roam within the Internet. Clearly this > increases the complexity of implementations for vendors that decide > to support both protocols. > Some vendors, however, may not support both protocols in either > mobile nodes or home agents. Although this is more of a commercial > issue, it does affect the large-scale deployment of mobile devices on > the Internet." > I don't think this reflects the issue that I had. Here's a different wording: As mentioned above, a node that is IPv4 and IPv6 capable must also be MIPv4 and MIPv6 capable to roam within the Internet. The ability to employ both IP versions from one mobility protocol makes it possible to implement just that one protocol, assuming the protocol choice is known. However, in situations where the mobile node must be capable of working in any network it may still need two protocols. > >>>> 3.0 Problem description >>>> >>>> >>> I am missing an explanation of why various existing, >>> non-mobility related transition mechanisms are insufficient >>> for solving the issues listed in this document. I believe >>> they are insufficient, but the document needs to explain >>> why. >>> >>> Please add the explanation. >>> >>> >> GT> It is a bit difficult to write general negative statements like >> this. I will add a section on this and add something generic about the >> fact that current transition mechanisms do not seem to deal with >> mobility. >> >> > Ok. Text needed. > > GT> Here it is: > "4.5. IPv4 to IPv6 Transition Mechanisms > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. A cursory examination of such > transition mechanisms indicates that none of them is designed to deal > with mobile nodes. While some transition mechanisms can be combined > with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have > been shown to assist with the issues described in this document." > Hmm... maybe it is not a good idea to reveal that we've only performed "a cursory examination" of the other possible approaches :-) Here's what I'd suggest: The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. However, while some transition mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of the known mechanisms have been shown to assist with the issues described in this document. Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Feb 16 05:34:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Py-0000DT-Eb; Fri, 16 Feb 2007 05:34:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Pw-0000AN-EV; Fri, 16 Feb 2007 05:34:16 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HI0Pt-0004Id-QJ; Fri, 16 Feb 2007 05:34:16 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-127.messagelabs.com!1171622052!9675610!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15894 invoked from network); 16 Feb 2007 10:34:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-127.messagelabs.com with SMTP; 16 Feb 2007 10:34:12 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1GAY7gp012770; Fri, 16 Feb 2007 03:34:08 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1GAY5Il026110; Fri, 16 Feb 2007 04:34:06 -0600 (CST) Message-ID: <45D5889C.3060701@motorola.com> Date: Fri, 16 Feb 2007 11:34:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> In-Reply-To: <45D4E2ED.8040702@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: Mobile IPv6 Mailing List , "Tsirtsis, George" , Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Jari Arkko wrote: > Hi George, [...] >>>>> 3.0 Problem description >>>>> >>>>> >>>> I am missing an explanation of why various existing, >>>> non-mobility related transition mechanisms are insufficient >>>> for solving the issues listed in this document. I believe >>>> they are insufficient, but the document needs to explain >>>> why. >>>> >>>> Please add the explanation. >>>> >>>> >>> GT> It is a bit difficult to write general negative statements like >>> this. I will add a section on this and add something generic about the >>> fact that current transition mechanisms do not seem to deal with >>> mobility. >>> >>> >> Ok. Text needed. >> >> GT> Here it is: >> "4.5. IPv4 to IPv6 Transition Mechanisms >> >> The IETF has standardized a number of transition mechanisms to allow >> networks and end nodes to gain IPv6 connectivity while the Internet >> is migrating from IPv4 to IPv6. A cursory examination of such >> transition mechanisms indicates that none of them is designed to deal >> with mobile nodes. While some transition mechanisms can be combined >> with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have >> been shown to assist with the issues described in this document." >> > Hmm... maybe it is not a good idea to reveal that we've > only performed "a cursory examination" of the other > possible approaches :-) > > Here's what I'd suggest: > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. However, while some transition > mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none > of the known mechanisms have been shown to assist with the issues > described in this document. I'm sorry to interfere here late at a pre-submission stage. Known mechanisms have been shown to assist with the issues described in this document: 6to4 tunnel between MN and a Gateway, RAs over that tunnel and HA separated from the gateway. Just 6to4, ND and Mobile IPv6, no protocol modifications. The experiment was described in a personal draft a few years ago, in the NEMO context with a vehicular MR attaching to IPv6-WiFi and IPv4-GPRS. The description was not using 6to4/MIP6 terms, it was targeted at showing network mobility is possible. I've not felt the need to document this 6to4/MIP6 behaviour because it is very straightforward. When discussing the dsmipv6 protocol and problem statement other WG members mentioned that this 6to4/MIP6 may be possible. NAT Traversal and MIP6 and 6to4 works ok too with _certain_ types of NATs, tried that in lab. MIP6 and MIP4-NAT Traversal works ok too, but in order to traverse more special NATs some protocol enhancements to MIP4-NAT Traversal are necessary. These enhancements have been implemented and tested routinely in my lab. New message formats were designed. I copypaste that in the postscriptum. Again, I am not trying to interfere with the advancement of the problem statement draft, just to say that alternatives to DS-MIPv6 exist live and well. Being rejected by IETF doesn't mean they don't exist. Alex PS: IPv4 NAT Traversal for IPv6 Mobile Nodes HA is an IPv4 HA (implementing Mobile IPv4). HA aka GW. MN HA | ---- Tunnel Request ------------> | | <--- Tunnel Reply --------------- | | ---- Tunnel "Acknowledgement" --> | ~ ... ~ | -----Tunnel "Keepalive" --------> | No NAT Present MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Accepted TMTA, reply code 0 | | TMTA | | | ---- Tunnel "Acknowledgement" --> | | Accepted THTA | | THTA | | Reply Code 2 (no NAT) | NAT Present MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 0 "Accepted TMTA" | | TMTA | | | | ---- Tunnel "Acknowledgement" --> | | Connection ID | | Reply Code 0 "Accepted HA and port" | THTA | | DPN (destination port number) | | | -----Tunnel "Keepalive" --------> | | Connection ID | ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | NAT Present, Dst Port Number Discovery MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number1 | Tentative MN Tunnel Address | ~ ... ~ | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number2 | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 0 "Accepted MN and port" | | TMTA | | | ---- Tunnel "Acknowledgement" --> | | Connection ID | | Reply Code 0 "Accepted HA and port" | | THTA | DPN ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | Auto-configuration of MN Tunnel Address MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address1 | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 1 "Not Accepted MN" | TMTA | | | ---- Tunnel Request ------------> | | Tentative MN Tunnel Address2 | | Sub-type 3 "Accepted HA, new MN" | THTA | | | <--- Tunnel Reply --------------- | | Reply Code 0 "Accepted MN" | | TMTA | | | ---- Tunnel "Acknowledgement" --> | | Reply Code 0 "Accepted" | | | ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | Auto-configuration of HA Tunnel Address MN HA | ---- Tunnel Request ------------> | | IP src address | | Tentative UDP dst port number| | Tentative MN Tunnel Address | | | | <--- Tunnel Reply --------------- | | Echoed Src Address | | Echoed Dst port number | | Tentative HA Tunnel Address | | Reply Code 0 "Accepted MN" | | | | ---- Tunnel Request ------------> | | Sub-type 4 "Not Accepted HA" | | | | <--- Tunnel Reply --------------- | | Tentative HA Tunnel Address2 | | | | ---- Tunnel "Acknowledgement" --> | | Connection ID | | Reply Code 0 "Accepted" | | | ~ ... ~ | -----Tunnel "Keepalive" --------> | | Connection ID | | | UDP Tunnel Request Extension, MN to HA 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 | Sub-Type | Reserved 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R| Reserved 2| Encapsulation | Reserved 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tentative MN Tunnel Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-type: 1 Discover NAT, port and propose address MN Tunnel Address: suggests local IPv4 address that will be used as local tunnel endpoint. UDP Tunnel Reply Extension, HA to MN 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 | Sub-Type | Reply Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Keepalive Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA Tunnel Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Echoed Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Echoed Dst Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 44 Sub-type: 1 Echoed src addr/port and propose address Reply Code: 0 Accepted MN Tunnel Address 1 Not Accepted MN Tunnel Address UDP Tunnel Reply Extension, "Acknowledgement", MN to HA 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 | Sub-Type | Reply Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Reserved | Keepalive Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 44 Sub-type: 2 Acknowledgement Reply Code: 0 Accepted HA Tunnel Address 1 Not Accepted HA Tunnel Address 2 No NAT Present, don't use any Connection ID (and Connection ID field not present). (and Keepalive Interval field not present). UDP Tunnel Request Extension, "Keepalive", MN to HA 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 | Sub-Type | Reserved 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|R| Reserved 2| Encapsulation | Reserved 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 144 Sub-type: 2 HA-NAT State Keepalive (TBA) Tunnel Data Message 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 | Next Header | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012, Generalized MIP Auth Extension 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 | Subtype | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Feb 16 05:41:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Wz-0006Yb-0k; Fri, 16 Feb 2007 05:41:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0Wx-0006YT-25; Fri, 16 Feb 2007 05:41:31 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI0Wv-0005RR-Pv; Fri, 16 Feb 2007 05:41:31 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8CB77198775; Fri, 16 Feb 2007 12:41:26 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4E2A71986DF; Fri, 16 Feb 2007 12:41:26 +0200 (EET) Message-ID: <45D58A57.7070901@piuha.net> Date: Fri, 16 Feb 2007 12:41:27 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> In-Reply-To: <45D5889C.3060701@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Mobile IPv6 Mailing List , "Tsirtsis, George" , Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Alex, > > Known mechanisms have been shown to assist with the issues described in > this document: 6to4 tunnel between MN and a Gateway, RAs over that > tunnel and HA separated from the gateway. Just 6to4, ND and Mobile IPv6, > no protocol modifications. > Ok. Do you have alternative suggested text that would better characterize the situation? Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Feb 16 05:59:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0oL-0004O6-71; Fri, 16 Feb 2007 05:59:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI0oJ-0004NT-Ld; Fri, 16 Feb 2007 05:59:27 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HI0oI-0008UD-Au; Fri, 16 Feb 2007 05:59:27 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-127.messagelabs.com!1171623066!11672103!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 17075 invoked from network); 16 Feb 2007 10:51:06 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-13.tower-127.messagelabs.com with SMTP; 16 Feb 2007 10:51:06 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l1GAp1oC021109; Fri, 16 Feb 2007 03:51:01 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l1GAox8W012162; Fri, 16 Feb 2007 04:51:00 -0600 (CST) Message-ID: <45D58C93.3000009@motorola.com> Date: Fri, 16 Feb 2007 11:50:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> <45D58A57.7070901@piuha.net> In-Reply-To: <45D58A57.7070901@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Mobile IPv6 Mailing List , "Tsirtsis, George" , Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Jari Arkko wrote: > Hi Alex, > > >> Known mechanisms have been shown to assist with the issues >> described in this document: 6to4 tunnel between MN and a Gateway, >> RAs over that tunnel and HA separated from the gateway. Just 6to4, >> ND and Mobile IPv6, no protocol modifications. >> > Ok. Do you have alternative suggested text that would better > characterize the situation? It is very difficult to write text along these lines. It is very difficult to discard existing IETF transitioning methods as not addressing the needs of DS-MIPv6. Maybe this: > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. However, while some transition > mechanisms could be combined with Mobile IPv6, it takes too much time > to analyze how they could work together, hence the need to design > from scratch a new extension to MIPv6. Not sure how else could I put it. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Feb 16 11:13:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI5iB-0005ZU-Rh; Fri, 16 Feb 2007 11:13:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI3b3-0003ov-An for mip4@ietf.org; Fri, 16 Feb 2007 08:57:57 -0500 Received: from www.nabble.com ([72.21.53.35] helo=talk.nabble.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI3b0-00037z-U1 for mip4@ietf.org; Fri, 16 Feb 2007 08:57:57 -0500 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1HI3az-0005ZM-T4 for mip4@ietf.org; Fri, 16 Feb 2007 05:57:53 -0800 Message-ID: <9004676.post@talk.nabble.com> Date: Fri, 16 Feb 2007 05:57:53 -0800 (PST) From: MoSO 2007 Workshop To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: moso2007@gmail.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e X-Mailman-Approved-At: Fri, 16 Feb 2007 11:13:27 -0500 Subject: [Mip4] cfp: MoSO 2007; Mobile Services-oriented Architectures and Ontologies Workshop X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ***Apologies for multiple postings***=20 Call for Submissions ---------------------------------------------------------------------------= -------------------- Mobile Services-oriented Architectures and Ontologies (MoSO 2007) http://events.deri.at/MoSO2007/ at The 8th International Conference on Mobile Data Management=20 (MDM'07) http://mdm2007.uni-mannheim.de/ TIME AND PLACE: May 11, 2007, Mannheim, Germany INVITED SPEAKER:=20 Dr. Henry Tirri, Nokia Fellow, Professor Theme of his talk: "MObile world 2015 and beyond" SUBMISSION DEADLINE FEBRUARY 28, 2007 (EXTENTED) All the papers should be submitted in electronic format (pdf version)=20 using the link:=20 http://www.easychair.org/MoSO2007/ -------------------------------------------------------- THEME OF THE WORKSHOP The theme of the workshop is the intersection of three major trends in today=E2=80=99s=20 computing: * mobile computing becomes more and more important. Mobile portable=20 devices have outnumbered already traditional desktop computers and=20 will mould the view of computers future generations will have. * service-oriented computing is viewed by many analysts as the computin= g=20 paradigm of the near future. It allows for the dynamic integration of= =20 functionality provided by different parties. * research on ontologies, in particular in connection with work on the= =20 semantic web and semantic web services allows for machine understandable=20 description of functionality and for automatic interaction of devices without=20 the need for human involvement. The proposed workshop investigates how mobile computing can benefit from=20 service-orientation and ontologies and vice versa. The vision is to extend the=20 typically rather limited capabilities of mobile devices by using services offered=20 by other devices, network providers or third parties. Adding ontologies to this=20 scenario allows this extension to be transparent to the human user. Further= ,=20 some high-end mobile telecom terminals can be called already multimedia=20 computers due their programmability,processor speed, and gigabytes of memory. Already in the near future these devices could also utilize ontologies locally during service provisioning. =20 GENERAL OVERVIEW Today, computers are changing from big, grey, and noisy things on our desks to=20 small, portable, and evernetworked devices most of us are carrying around. This=20 new form of mobility imposes a shift in how we view computers and the way w= e work=20 with them. In developing countries like India and China =E2=80=98Mobile Int= ernet=E2=80=99 can=20 become the only Internet a large portion of population will get access to. Services offer the possibility to overcome the limitations of individual mobile=20 devices by making functionality offered by others available to them on an =E2=80=9Cas-needed=E2=80=9D=20 basis. Thus, using the service-oriented computing paradigm in mobile environments=20 will considerably enlarge the variety of accessible applications and will enable=20 new business opportunities in the mobile space by delivering integrated functionalities=20 across wireless networks. Network hosted mobile services will allow mobile operators=20 and third party mobile services provider to extend their businesses by making their=20 network services available to a broader audience (e.g. developers, service providers,=20 etc.); device hosted service will allow great potential for big innovations for=20 applications and services that can be provided by individual mobile device owners. These mobile services offer functionalities and behaviors that can be described,=20 advertised, discovered, and composed by others. Eventually, they will be able to=20 interoperate even though they have not been designed to work together. This type=20 of interoperability is based on the ability to understand other services an= d reason=20 about their functionalities and behaviors when necessary. In this respect, mobile=20 services can benefit from marrying the Semantic Web, which provides the infrastructure=20 for the extensive usage of distributed knowledge, to be deployed for modeling services=20 and add meaning, through ontologies, enabling lightweight discovery and composition=20 of mobile services. The ability to appropriately combine mobility and semantic grounded=20 data sharing has generated and is continuously triggering challenging questions in=20 several areas of computer science, engineering and networking. This workshop aims to tackle the research problems around methods, concepts= , models,=20 languages and technologies that enable new opportunities in the mobile spac= e through=20 adoption, usage, and integration of mobile services and ontologies. Of particular=20 interest are the methodologies and technologies that would allow automatic tasks to=20 be performed with respect to mobile services and the use of ontologies in this context. This proposed workshop aims to bring together researchers and industry attendees=20 addressing many of these issues, and promote and foster a greater understanding of=20 mobile service and ontologies and their potential in enabling new business opportunities=20 in the mobile space. TOPICS The following indicates the general focus of the workshop. However, related= =20 contributions are welcome as well.=20 - Service-oriented architectures for mobile internet services - languages and methodologies for describing mobile Service-oriented system= s - discovery and matchmaking of ontology based services in the context of=20 mobile service-oriented architectures - adaptive selection of services in mobile service-oriented architectures - ontology management in mobile environments - contracting and negotiation with ontology-based mobile services (service= =20 level agreements) - approaches to composition of ontology based services in the context of mobile=20 service-oriented systems - invocation, adaptive execution, monitoring, and management of mobile services - interaction protocols and conversation models for mobile services-oriente= d=20 architectures - ontology-based security and privacy issues in mobile service-oriented systems - applications of mobile service-oriented architectures - analysis and design approaches for mobile service-oriented architectures= =20 and services - reasoning with mobile services - ontology-based policies for mobile service-oriented architectures - tools for discovery, matchmaking, selection, mediation, composition, management,=20 and monitoring of services in a mobile world - mobile service development - ontologies in dependable service provisioning WORKSHOP FORMAT AND ATTENDANCE The program will occupy a full day, and will include presentations of=20 papers selected from the full papers category (see 'submissions' below).=20 Please note that at least one author of each accepted submission must=20 attend the workshop. The MDM 2007 conference formalities are applied=20 for fees and respective organizational aspects. Submission of a paper=20 is not required for attendance at the workshop. However, in the event=20 that the workshop cannot accommodate all who would like to participate,=20 those who have submitted a paper (in any category) will be given=20 priority for registration. SUBMISSIONS Two categories of submissions are solicited: (1) Full papers (up to 5 pages). (2) Position papers (up to 2 pages). All submissions should be formatted in the IEEE style. Formatting=20 instructions and LaTeX macros are available on the IEEE computer society=20 site: LaTex macros: * ftp://pubftp.computer.org/Press/Outgoing/proceedings/IEEE_CS_Latex.zi= p Formatting instructions: * ftp://pubftp.computer.org/Press/Outgoing/proceedings/instruct.doc * ftp://pubftp.computer.org/Press/Outgoing/proceedings/instruct.pdf * ftp://pubftp.computer.org/Press/Outgoing/proceedings/instruct.ps All accepted full papers as well as all position papers of attendees=20 will be published in post workshop proceedings in IEEE DL. Additionally,=20 authors of selected papers will have the opportunity to submit extended=20 versions of their papers for the upcoming MoSO journal issue. All the papers should be submitted in electronic format (pdf version)=20 using the link: http://www.easychair.org/MoSO2007/. IMPORTANT DATES Submissions: February 28, 2007 Acceptance: March 20, 2007 Final copy: April 1, 2007 Workshops day: May 11, 2007 ORGANIZING COMMITTEE Nelson Baloian (University of Chile, Chile) Dumitru Roman (DERI Innsbruck, Austria) Jari Veijalainen (University of Jyv=C3=A4skyl=C3=A4, Finland) PROGRAM COMMITTEE (confirmed; to be extended) Martin Bauer, NEC Europe Ltd, Germany Sonia Ben Mokhtar, Inria, France Richard Benjamins, ISOCO, Spain Yolande Berbers, Katholieke Universiteit Leuven, Belgium Patricia Charlton. Motorola Labs, UK John Domingue, Open University, UK Fabien Gandon, INRIA Sophia Antipolis, France Nikolaos Georgantas, INRIA, France Martin Hepp, DERI Innsbruck, Austria Eero Hyv=C3=B6nen, Helsinki Univ. of Technology, Finland Qun Jin, Waseda University, Japan Wai Gen Yee, Illinois Institute of Technology, USA Takahiro Kawamura, Toshiba Corp, Japan Ryszard Kowalczyk, SWIN, Australia Antonio Liotta, Univ. of Essex, UK Vladimir Oleshchuk, HIA, Norway Stefan Poslad, Queen Mary Univ., UK Tore Risch, Uppsala University, Sweden Brahmananda Sapkota, DERI Galway, Ireland Steffen Staab, University of Koblenz, Germany Thomas Strang, University of Innsbruck, Austria Vlad Tanasescu, Open University, UK Do van Thanh, Telenor, Norway Ioan Toma, DERI Innsbruck, Austria Kristian Torp, Univ. of Aalborg, Denmark Aphrodite Tsalgatiodou, University of Athens, Greece Gustavo Zurita, Universidad de Chile, Chile Alexander Wahler, Hanival mbH, Austria Note: Check the workshop web site for updates to the PC members list. --=20 View this message in context: http://www.nabble.com/cfp%3A-MoSO-2007--Mobil= e-Services-oriented-Architectures-and-Ontologies-Workshop-tf3239585.html#a9= 004676 Sent from the IETF - Mip4 mailing list archive at Nabble.com. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 19 13:45:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJDW4-0004sy-1J; Mon, 19 Feb 2007 13:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJDW3-0004sm-Lt for mip4@ietf.org; Mon, 19 Feb 2007 13:45:35 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJDVz-0000Tm-AW for mip4@ietf.org; Mon, 19 Feb 2007 13:45:35 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2007 10:45:30 -0800 X-IronPort-AV: i="4.14,191,1170662400"; d="scan'208"; a="114250530:sNHT122642442" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1JIjUDi007092; Mon, 19 Feb 2007 10:45:30 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1JIjSUw017676; Mon, 19 Feb 2007 10:45:30 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 10:45:28 -0800 Received: from sgundavewxp ([10.32.246.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 10:45:27 -0800 From: "Sri Gundavelli" To: "'McCann Peter-A001034'" , References: Subject: RE: [Mip4] Consensus call: draft-tsirtsis-nemov4-dynamic-01.txt anddraft-tsirtsis-nemov4-fa-01.txt Date: Mon, 19 Feb 2007 10:45:26 -0800 Message-ID: <000501c75456$1f6e4730$d4f6200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdHGGi3lBkMp+DOSX+0VMhlUJDf8QJT3siwAGU676A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: X-OriginalArrivalTime: 19 Feb 2007 18:45:27.0856 (UTC) FILETIME=[1FAADB00:01C75456] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1249; t=1171910730; x=1172774730; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20=22Sri=20Gundavelli=22=20 |Subject:=20RE=3A=20[Mip4]=20Consensus=20call=3A=20draft-tsirtsis-nemov4- dynamic-01.txt=20anddraft-tsirtsis-nemov4-fa-01.txt |Sender:=20; bh=xxB7LCXq6SYrxtt86yFMuBS3EcSQ3w0r4z9uhKRwYEI=; b=J4yOfCX0ME937f2gJwKAj4CBas0dZPQvSFzbN2fI3vCKrAlyigvyr3Jm4t4khscmwVUiEEw2 djrI0iV6iIc3kBG4XG8FghhmUtej/t/rdOf3ZDv8NLKad9kPMYd8AzBa; Authentication-Results: sj-dkim-3; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I support the adoption of these two drafts. I want to send the review comments later. Sri -----Original Message----- From: McCann Peter-A001034 [mailto:pete.mccann@motorola.com] Sent: Wednesday, February 14, 2007 10:45 AM To: mip4@ietf.org Subject: RE: [Mip4] Consensus call: draft-tsirtsis-nemov4-dynamic-01.txt anddraft-tsirtsis-nemov4-fa-01.txt We didn't get any responses to this consensus call. If you have an opinion on this please speak up. -Pete McCann Peter-A001034 wrote: > During the mip4 meeting in San Diego, we saw a presentation from > George Tsirtsis on two extensions of the nemov4 work. > > The charter calls out the work on dynamic address assignment and FA > support as work items for the working group. > > This is a call for consensus to see whether we are ready to adopt > these two drafts as working group items. > > Please respond by next Friday, February 9th, on whether you think we > are ready to adopt these two drafts as working group items. > > -Pete -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Feb 20 10:52:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXIF-0007qb-D8; Tue, 20 Feb 2007 10:52:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXIE-0007pw-Ex; Tue, 20 Feb 2007 10:52:38 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXIB-0001fQ-Qn; Tue, 20 Feb 2007 10:52:37 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 38BD0198777; Tue, 20 Feb 2007 17:52:35 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DA18C1986AF; Tue, 20 Feb 2007 17:52:34 +0200 (EET) Message-ID: <45DB1943.80908@piuha.net> Date: Tue, 20 Feb 2007 17:52:35 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> <45D58A57.7070901@piuha.net> <45D58C93.3000009@motorola.com> In-Reply-To: <45D58C93.3000009@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , Alexandru Petrescu X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org George, others? I don't really like either the original formulation and I hope what Alex suggested isn't true either. I'm sure there are technical issues that you could talk about. Please suggest text -- the draft is up for discussion in Thursday's IESG telechat so I would like to see a better proposal before that. Jari Alexandru Petrescu kirjoitti: > Jari Arkko wrote: >> Hi Alex, >> >> >>> Known mechanisms have been shown to assist with the issues described >>> in this document: 6to4 tunnel between MN and a Gateway, RAs over >>> that tunnel and HA separated from the gateway. Just 6to4, ND and >>> Mobile IPv6, no protocol modifications. >>> >> Ok. Do you have alternative suggested text that would better >> characterize the situation? > > It is very difficult to write text along these lines. It is very > difficult to discard existing IETF transitioning methods as not > addressing the needs of DS-MIPv6. > > Maybe this: > >> The IETF has standardized a number of transition mechanisms to allow >> networks and end nodes to gain IPv6 connectivity while the Internet >> is migrating from IPv4 to IPv6. However, while some transition >> mechanisms could be combined with Mobile IPv6, it takes too much time >> to analyze how they could work together, hence the need to design >> from scratch a new extension to MIPv6. > > Not sure how else could I put it. > > Alex > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Feb 20 13:52:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa6F-0002IV-JG; Tue, 20 Feb 2007 13:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJa6E-0002IB-Sn; Tue, 20 Feb 2007 13:52:26 -0500 Received: from mail127.messagelabs.com ([216.82.250.115]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJa6D-00027s-Hh; Tue, 20 Feb 2007 13:52:26 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-127.messagelabs.com!1171997544!12131053!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14851 invoked from network); 20 Feb 2007 18:52:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-127.messagelabs.com with SMTP; 20 Feb 2007 18:52:24 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1KIqJtJ029177; Tue, 20 Feb 2007 11:52:19 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l1KIqItc012153; Tue, 20 Feb 2007 12:52:18 -0600 (CST) Message-ID: <45DB4361.9030200@motorola.com> Date: Tue, 20 Feb 2007 19:52:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] Re: FW: [Mip4] AD review of draft-ietf-mip6-dsmip-problem-02.txt References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com> <45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com> <45D58A57.7070901@piuha.net> <45D58C93.3000009@motorola.com> <45DB1943.80908@piuha.net> In-Reply-To: <45DB1943.80908@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Mobile IPv6 Mailing List , "Tsirtsis, George" , Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Jari Arkko wrote: > George, others? I don't really like either the original formulation > and I hope what Alex suggested isn't true either. I'm sure there are > technical issues that you could talk about. Please suggest text -- > the draft is up for discussion in Thursday's IESG telechat so I would > like to see a better proposal before that. YEs, please anybody else send a comment regarding the quoted paragraph in the DSMIP Problem Statement draft for section 4.5 IPv4 to IPv6 Transition Mechanisms. I also believe we can't simply write there wasn't enough time to deal with all issues. It may be that a way out of this is to _list_ the other IPv4-to-IPv6 transition mechanisms that this problem statement considered. I'm sure 6to4 was considered by the authors. I'm not sure whether STUN was considered. IKEv2 NAT traversal _was_ considered by authors. For each of those we list, we can say why they're not adapted for DSMIP problem. For example: list 6to4, abstract what it does, how it offers IPv6 connectivity through the NAT, and then say that it may work with certain NATs but not with others. It won't work with NATs that only allow MIP6 through. Also, list IKEv2 NAT traversal, say in short how it does it, then say about IKEv2 being independent of running over IPv4 and IPv6 and that it is necessary for MN-to-HA. However, say that MIP4 NAT Traversal may be better adapted for this task because many nodes already implement MIP4 NAT Traversal (as a reminiscent of their MIP4 implementation). I believe many of these things were discussed at least publicly. But this is more than one paragraph. Alex > > Jari > > Alexandru Petrescu kirjoitti: >> Jari Arkko wrote: >>> Hi Alex, >>> >>> >>>> Known mechanisms have been shown to assist with the issues >>>> described in this document: 6to4 tunnel between MN and a >>>> Gateway, RAs over that tunnel and HA separated from the >>>> gateway. Just 6to4, ND and Mobile IPv6, no protocol >>>> modifications. >>>> >>> Ok. Do you have alternative suggested text that would better >>> characterize the situation? >> It is very difficult to write text along these lines. It is very >> difficult to discard existing IETF transitioning methods as not >> addressing the needs of DS-MIPv6. >> >> Maybe this: >> >>> The IETF has standardized a number of transition mechanisms to >>> allow networks and end nodes to gain IPv6 connectivity while the >>> Internet is migrating from IPv4 to IPv6. However, while some >>> transition mechanisms could be combined with Mobile IPv6, it >>> takes too much time to analyze how they could work together, >>> hence the need to design from scratch a new extension to MIPv6. >> Not sure how else could I put it. >> >> Alex >> >> >> > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Feb 20 14:06:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaJt-0003jk-5B; Tue, 20 Feb 2007 14:06:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJaJq-0003jH-TG; Tue, 20 Feb 2007 14:06:30 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJaJp-0005Uj-Fd; Tue, 20 Feb 2007 14:06:30 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l1KJ6SmV031526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Feb 2007 11:06:28 -0800 Received: from SANEXCAS02.na.qualcomm.com (sanexcas02.qualcomm.com [172.30.36.176]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1KJ6R3D013618; Tue, 20 Feb 2007 11:06:27 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 11:06:27 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Date: Tue, 20 Feb 2007 11:06:25 -0800 Message-ID: In-Reply-To: <45DB1943.80908@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AcdVCFLlD4sRScf4T+69ZsmfiU5a7gAFx7Kw References: <2309978910A6A6478C2C7585692B0AF41FF808@NAEX16.na.qualcomm.com><45D4E2ED.8040702@piuha.net> <45D5889C.3060701@motorola.com><45D58A57.7070901@piuha.net> <45D58C93.3000009@motorola.com> <45DB1943.80908@piuha.net> From: "Narayanan, Vidya" To: "Jari Arkko" , "Tsirtsis, George" X-OriginalArrivalTime: 20 Feb 2007 19:06:27.0453 (UTC) FILETIME=[38DBDAD0:01C75522] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , Alexandru Petrescu X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I think what Alex is saying is somewhat true. It is feasible to use other transition mechanisms with MIP6. However, those will be heavier and less efficient. I think it is most straightforward to build the transition into MIP6 for the purpose of mobility. Without this, for instance, supporting IPv4-only access networks would mean that the MN supports some of these other transition mechanisms, which is quite painful. When there is already a transition mechanism used in the access network, it is feasible to use that, but, given we are dealing with mobile nodes and they can roam into any access network, that is not an assumption we can make.=20 Vidya > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Tuesday, February 20, 2007 7:53 AM > To: Tsirtsis, George > Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List;=20 > Alexandru Petrescu > Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof=20 > draft-ietf-mip6-dsmip-problem-02.txt >=20 > George, others? I don't really like either the original=20 > formulation and I hope what Alex suggested isn't true either.=20 > I'm sure there are technical issues that you could talk=20 > about. Please suggest text -- the draft is up for discussion=20 > in Thursday's IESG telechat so I would like to see a better=20 > proposal before that. >=20 > Jari >=20 > Alexandru Petrescu kirjoitti: > > Jari Arkko wrote: > >> Hi Alex, > >> > >> > >>> Known mechanisms have been shown to assist with the=20 > issues described=20 > >>> in this document: 6to4 tunnel between MN and a Gateway, RAs over=20 > >>> that tunnel and HA separated from the gateway. Just 6to4, ND and=20 > >>> Mobile IPv6, no protocol modifications. > >>> > >> Ok. Do you have alternative suggested text that would better=20 > >> characterize the situation? > > > > It is very difficult to write text along these lines. It is very=20 > > difficult to discard existing IETF transitioning methods as not=20 > > addressing the needs of DS-MIPv6. > > > > Maybe this: > > > >> The IETF has standardized a number of transition=20 > mechanisms to allow =20 > >> networks and end nodes to gain IPv6 connectivity while the=20 > Internet =20 > >> is migrating from IPv4 to IPv6. However, while some transition=20 > >> mechanisms could be combined with Mobile IPv6, it takes=20 > too much time=20 > >> to analyze how they could work together, hence the need to design=20 > >> from scratch a new extension to MIPv6. > > > > Not sure how else could I put it. > > > > Alex > > > > > > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Feb 20 15:47:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbtZ-0002ZT-7t; Tue, 20 Feb 2007 15:47:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJbtY-0002ZB-2Z; Tue, 20 Feb 2007 15:47:28 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJbtW-0008L6-HZ; Tue, 20 Feb 2007 15:47:28 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1KKiI1T015141; Tue, 20 Feb 2007 22:44:34 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:46:55 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 14:46:39 -0600 Received: from 172.19.244.105 ([172.19.244.105]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Feb 2007 20:46:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 20 Feb 2007 14:49:16 -0600 Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt From: Basavaraj Patil To: "ext Narayanan, Vidya" , Jari Arkko , "Tsirtsis, George" Message-ID: Thread-Topic: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Thread-Index: AcdVCFLlD4sRScf4T+69ZsmfiU5a7gAFx7KwAARI+8E= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Feb 2007 20:46:39.0645 (UTC) FILETIME=[38678CD0:01C75530] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Mobile IPv6 Mailing List , Mobile IPv4 Mailing List , Alexandru Petrescu X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Jari, You can consider DS-MIP as yet another transition mechanism. And one that is required or even essential for certain deployments even though we acknowledge there are several transition mechanisms that have been developed and can be used. The fact is that Mobile IP is being deployed and it makes sense for such deployments to use the Mobile IP infrastructure (i.e the HA in this case) as a transition solution as well. Hence this add-on capability/feature to Mobile IP is useful and needed. -Raj On 2/20/07 1:06 PM, "ext Narayanan, Vidya" wrote: > > I think what Alex is saying is somewhat true. It is feasible to use > other transition mechanisms with MIP6. However, those will be heavier > and less efficient. I think it is most straightforward to build the > transition into MIP6 for the purpose of mobility. Without this, for > instance, supporting IPv4-only access networks would mean that the MN > supports some of these other transition mechanisms, which is quite > painful. When there is already a transition mechanism used in the access > network, it is feasible to use that, but, given we are dealing with > mobile nodes and they can roam into any access network, that is not an > assumption we can make. > > Vidya > >> -----Original Message----- >> From: Jari Arkko [mailto:jari.arkko@piuha.net] >> Sent: Tuesday, February 20, 2007 7:53 AM >> To: Tsirtsis, George >> Cc: Mobile IPv6 Mailing List; Mobile IPv4 Mailing List; >> Alexandru Petrescu >> Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof >> draft-ietf-mip6-dsmip-problem-02.txt >> >> George, others? I don't really like either the original >> formulation and I hope what Alex suggested isn't true either. >> I'm sure there are technical issues that you could talk >> about. Please suggest text -- the draft is up for discussion >> in Thursday's IESG telechat so I would like to see a better >> proposal before that. >> >> Jari >> >> Alexandru Petrescu kirjoitti: >>> Jari Arkko wrote: >>>> Hi Alex, >>>> >>>> >>>>> Known mechanisms have been shown to assist with the >> issues described >>>>> in this document: 6to4 tunnel between MN and a Gateway, RAs over >>>>> that tunnel and HA separated from the gateway. Just 6to4, ND and >>>>> Mobile IPv6, no protocol modifications. >>>>> >>>> Ok. Do you have alternative suggested text that would better >>>> characterize the situation? >>> >>> It is very difficult to write text along these lines. It is very >>> difficult to discard existing IETF transitioning methods as not >>> addressing the needs of DS-MIPv6. >>> >>> Maybe this: >>> >>>> The IETF has standardized a number of transition >> mechanisms to allow >>>> networks and end nodes to gain IPv6 connectivity while the >> Internet >>>> is migrating from IPv4 to IPv6. However, while some transition >>>> mechanisms could be combined with Mobile IPv6, it takes >> too much time >>>> to analyze how they could work together, hence the need to design >>>> from scratch a new extension to MIPv6. >>> >>> Not sure how else could I put it. >>> >>> Alex >>> >>> >>> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Feb 20 17:06:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJd7c-0004Gy-2a; Tue, 20 Feb 2007 17:06:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJd7a-0004Fc-PY; Tue, 20 Feb 2007 17:06:02 -0500 Received: from omta02ps.mx.bigpond.com ([144.140.83.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJd7Z-0003Nn-9r; Tue, 20 Feb 2007 17:06:02 -0500 Received: from oaamta02ps.mx.bigpond.com ([124.191.178.123]) by omta02ps.mx.bigpond.com with ESMTP id <20070220220556.SIYE24597.omta02ps.mx.bigpond.com@oaamta02ps.mx.bigpond.com>; Tue, 20 Feb 2007 22:05:56 +0000 Received: from PC20005 ([124.191.178.123]) by oaamta02ps.mx.bigpond.com with ESMTP id <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005>; Tue, 20 Feb 2007 22:05:51 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" , "'Tsirtsis, George'" Subject: RE: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Date: Wed, 21 Feb 2007 09:05:44 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <45DB1943.80908@piuha.net> Thread-Index: AcdVB0L3pxAbbAGXTXGfCw93eMD0gQAMtoIQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'Mobile IPv6 Mailing List' , 'Mobile IPv4 Mailing List' , 'Alexandru Petrescu' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > George, others? I don't really like either the original > formulation and I hope what Alex suggested isn't > true either. I'm sure there are technical issues > that you could talk about. Please suggest text -- > the draft is up for discussion in Thursday's IESG > telechat so I would like to see a better proposal > before that. => Here is a suggestion: The IETF has standardized a number of transition mechanisms to allow networks and end nodes to gain IPv6 connectivity while the Internet is migrating from IPv4 to IPv6. These transition mechanisms can be categorised under two main items: Tunnelling and Protocol Translation. Protocol Translation mechanisms are not suitable for Mobile IP signalling as they break end to end integrity. Tunnelling mechanisms, (both static and dynamic), when suitable, add unnecessary overheads to the signalling and data between the mobile node and the home agent. Furthermore, none of those mechanisms can solve the scenario where IPv4 needs to be dynamically tunnelled in IPv6 (i.e. when a node uses an IPv4 home address in an IPv6 network). Due to these reasons, there is a need for a new transition mechanism that utilises the dynamic tunnelling capabilities of Mobile IP. Hesham > > Jari > > Alexandru Petrescu kirjoitti: > > Jari Arkko wrote: > >> Hi Alex, > >> > >> > >>> Known mechanisms have been shown to assist with the > issues described > >>> in this document: 6to4 tunnel between MN and a Gateway, RAs over > >>> that tunnel and HA separated from the gateway. Just 6to4, ND and > >>> Mobile IPv6, no protocol modifications. > >>> > >> Ok. Do you have alternative suggested text that would better > >> characterize the situation? > > > > It is very difficult to write text along these lines. It is very > > difficult to discard existing IETF transitioning methods as not > > addressing the needs of DS-MIPv6. > > > > Maybe this: > > > >> The IETF has standardized a number of transition > mechanisms to allow > >> networks and end nodes to gain IPv6 connectivity while > the Internet > >> is migrating from IPv4 to IPv6. However, while some transition > >> mechanisms could be combined with Mobile IPv6, it takes > too much time > >> to analyze how they could work together, hence the need to design > >> from scratch a new extension to MIPv6. > > > > Not sure how else could I put it. > > > > Alex > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 21 01:35:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl4C-0000TL-Sr; Wed, 21 Feb 2007 01:35:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl4C-0000TD-5z; Wed, 21 Feb 2007 01:35:04 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJl4A-0007Ve-PZ; Wed, 21 Feb 2007 01:35:04 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 89488198776; Wed, 21 Feb 2007 08:34:59 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3951D198775; Wed, 21 Feb 2007 08:34:59 +0200 (EET) Message-ID: <45DBE813.6080101@piuha.net> Date: Wed, 21 Feb 2007 08:34:59 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt References: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> In-Reply-To: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'Mobile IPv6 Mailing List' , "'Tsirtsis, George'" , 'Mobile IPv4 Mailing List' , 'Alexandru Petrescu' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hesham Soliman kirjoitti: > > > George, others? I don't really like either the original > > formulation and I hope what Alex suggested isn't > > true either. I'm sure there are technical issues > > that you could talk about. Please suggest text -- > > the draft is up for discussion in Thursday's IESG > > telechat so I would like to see a better proposal > > before that. > > => Here is a suggestion: > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. These transition mechanisms can be > categorised under two > main items: Tunnelling and Protocol Translation. Protocol Translation > mechanisms are not suitable for Mobile IP signalling as they break end to > end integrity. Tunnelling mechanisms, (both static and dynamic), when > suitable, add unnecessary overheads to the signalling and data between the > mobile node and the home agent. Furthermore, none of those mechanisms can > solve the scenario where IPv4 needs to be dynamically tunnelled in IPv6 > (i.e. when a node uses an IPv4 home address in an IPv6 network). Due to > these reasons, there is a need for a new transition mechanism that utilises > the dynamic tunnelling capabilities of Mobile IP. > Ok. This is closer to what I had in mind. Do people agree with this? Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 21 04:47:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJo3x-0001F0-79; Wed, 21 Feb 2007 04:47:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJo3v-0001ES-JC; Wed, 21 Feb 2007 04:46:59 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HJo3u-0001oJ-93; Wed, 21 Feb 2007 04:46:59 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1172051217!15503843!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6872 invoked from network); 21 Feb 2007 09:46:57 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 21 Feb 2007 09:46:57 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1L9km2T005749; Wed, 21 Feb 2007 02:46:48 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l1L9kjwb011024; Wed, 21 Feb 2007 03:46:46 -0600 (CST) Message-ID: <45DC1504.7030302@motorola.com> Date: Wed, 21 Feb 2007 10:46:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt References: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> In-Reply-To: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Mobile IPv6 Mailing List' , "'Tsirtsis, George'" , 'Mobile IPv4 Mailing List' , 'Jari Arkko' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hesham Soliman wrote: > >> George, others? I don't really like either the original formulation >> and I hope what Alex suggested isn't true either. I'm sure there >> are technical issues that you could talk about. Please suggest text >> -- the draft is up for discussion in Thursday's IESG telechat so I >> would like to see a better proposal before that. > > => Here is a suggestion: > > The IETF has standardized a number of transition mechanisms to allow > networks and end nodes to gain IPv6 connectivity while the Internet > is migrating from IPv4 to IPv6. These transition mechanisms can be > categorised under two main items: Tunnelling and Protocol > Translation. Protocol Translation mechanisms are not suitable for > Mobile IP signalling as they break end to end integrity. Tunnelling > mechanisms, (both static and dynamic), when suitable, add unnecessary > overheads to the signalling and data between the mobile node and the > home agent. Furthermore, none of those mechanisms can solve the > scenario where IPv4 needs to be dynamically tunnelled in IPv6 (i.e. > when a node uses an IPv4 home address in an IPv6 network). Due to > these reasons, there is a need for a new transition mechanism that > utilises the dynamic tunnelling capabilities of Mobile IP. I agree with the way it is formulated and it makes sense overall. I would like to insist on using specific protocol names with specific transitioning mechanisms and RFC numbers. For example: "Protocol Translation mechanisms (SIIT [xx]) are not suitable for Mobile IP signaling as they break end-to-end integrity." "Tunnelling mechanisms (6to4 [xx], STUN [xx]), when suitable, add unnecessary overheads to the signalling and data between the mobile node and the home agent" Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 21 09:09:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJs9f-0000iZ-Ta; Wed, 21 Feb 2007 09:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJs9f-0000iI-D5; Wed, 21 Feb 2007 09:09:11 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJs9e-00008p-0Q; Wed, 21 Feb 2007 09:09:11 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E6463198775; Wed, 21 Feb 2007 16:09:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A11C119862E; Wed, 21 Feb 2007 16:09:02 +0200 (EET) Message-ID: <45DC527F.5060301@piuha.net> Date: Wed, 21 Feb 2007 16:09:03 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Hesham Soliman Subject: Re: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt References: <20070220220551.OETC17816.oaamta02ps.mx.bigpond.com@PC20005> <45DC1504.7030302@motorola.com> In-Reply-To: <45DC1504.7030302@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'Mobile IPv6 Mailing List' , "'Tsirtsis, George'" , 'Mobile IPv4 Mailing List' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > Hesham Soliman wrote: >> >>> George, others? I don't really like either the original formulation >>> and I hope what Alex suggested isn't true either. I'm sure there >>> are technical issues that you could talk about. Please suggest text >>> -- the draft is up for discussion in Thursday's IESG telechat so I >>> would like to see a better proposal before that. >> >> => Here is a suggestion: >> >> The IETF has standardized a number of transition mechanisms to allow >> networks and end nodes to gain IPv6 connectivity while the Internet >> is migrating from IPv4 to IPv6. These transition mechanisms can be >> categorised under two main items: Tunnelling and Protocol >> Translation. Protocol Translation mechanisms are not suitable for >> Mobile IP signalling as they break end to end integrity. Tunnelling >> mechanisms, (both static and dynamic), when suitable, add unnecessary >> overheads to the signalling and data between the mobile node and the >> home agent. Furthermore, none of those mechanisms can solve the >> scenario where IPv4 needs to be dynamically tunnelled in IPv6 (i.e. >> when a node uses an IPv4 home address in an IPv6 network). Due to >> these reasons, there is a need for a new transition mechanism that >> utilises the dynamic tunnelling capabilities of Mobile IP. Isn't there also an issue with the two mobility protocol configurations, credentials, etc., even if we have perfect IPv4 and IPv6 connectivity everywhere through transition mechanisms? Jari -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 21 12:33:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvLc-00034G-T4; Wed, 21 Feb 2007 12:33:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJvLb-00033x-99; Wed, 21 Feb 2007 12:33:43 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJvLZ-00083l-HI; Wed, 21 Feb 2007 12:33:43 -0500 Received: from PC20005 ([124.191.178.123]) by omta05ps.mx.bigpond.com with ESMTP id <20070221173333.VOCF19269.omta05ps.mx.bigpond.com@PC20005>; Wed, 21 Feb 2007 17:33:33 +0000 From: "Hesham Soliman" To: "'Jari Arkko'" Subject: RE: [Mip6] Re: FW: [Mip4] AD reviewof draft-ietf-mip6-dsmip-problem-02.txt Date: Thu, 22 Feb 2007 04:33:27 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <45DC527F.5060301@piuha.net> Thread-Index: AcdVwd0cxoNs2Hi+ROalaZ2ELSmC1QAG/EZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070221173333.VOCF19269.omta05ps.mx.bigpond.com@PC20005> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'Mobile IPv6 Mailing List' , "'Tsirtsis, George'" , 'Mobile IPv4 Mailing List' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > >> The IETF has standardized a number of transition > mechanisms to allow > >> networks and end nodes to gain IPv6 connectivity while > the Internet > >> is migrating from IPv4 to IPv6. These transition mechanisms can be > >> categorised under two main items: Tunnelling and Protocol > >> Translation. Protocol Translation mechanisms are not suitable for > >> Mobile IP signalling as they break end to end integrity. > Tunnelling > >> mechanisms, (both static and dynamic), when suitable, add > unnecessary > >> overheads to the signalling and data between the mobile > node and the > >> home agent. Furthermore, none of those mechanisms can solve the > >> scenario where IPv4 needs to be dynamically tunnelled in > IPv6 (i.e. > >> when a node uses an IPv4 home address in an IPv6 network). Due to > >> these reasons, there is a need for a new transition mechanism that > >> utilises the dynamic tunnelling capabilities of Mobile IP. > > Isn't there also an issue with the two mobility protocol > configurations, > credentials, etc., even if we have perfect IPv4 and IPv6 connectivity > everywhere through transition mechanisms? => Yes but this point is mentioned elsewhere. I was trying to solve the issue of why current transition mechanisms are not sufficient. Hesham > > Jari > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 22 04:25:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKACr-0005J1-7z; Thu, 22 Feb 2007 04:25:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKACq-0005It-NQ for mip4@ietf.org; Thu, 22 Feb 2007 04:25:40 -0500 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKACp-00020K-8p for mip4@ietf.org; Thu, 22 Feb 2007 04:25:40 -0500 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1M9PcAk020450 for ; Thu, 22 Feb 2007 11:25:38 +0200 (EET) Received: from [131.177.105.186] (ws186.secureuser.sonera.fi [131.177.105.186]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l1M9PbxS020447 for ; Thu, 22 Feb 2007 11:25:37 +0200 (EET) Message-ID: <45DD6190.7050501@teliasonera.com> Date: Thu, 22 Feb 2007 11:25:36 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mip4] New I-D: Service Selection for MIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi all, Comments are welcome. http://www.ietf.org/internet-drafts/draft-korhonen-mip4-service-00.txt "Mobile IPv4 has a Network Access Identifier extension (MN-NAI) that provides a flexible way to identify mobile nodes using other identifiers than IPv4 addresses. An example of such an identifier is the Network Access Identifier (NAI). In some Mobile IPv4 deployments, however, just identifying the mobile node or the the mobility service subscriber via a proxy representative is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. The capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within the same mobility service subscription." Cheers, Jouni -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Feb 22 15:13:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKJM-0007NQ-Id; Thu, 22 Feb 2007 15:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKJL-0007N8-AU for mip4@ietf.org; Thu, 22 Feb 2007 15:13:03 -0500 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKKJK-0005Tp-PL for mip4@ietf.org; Thu, 22 Feb 2007 15:13:03 -0500 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 12:13:01 -0800 Message-ID: <45DDF94D.7010106@azairenet.com> Date: Thu, 22 Feb 2007 12:13:01 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Alexandru Petrescu References: <457E204A.5060609@azairenet.com> <45ABA670.6020308@motorola.com> In-Reply-To: <45ABA670.6020308@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Feb 2007 20:13:01.0819 (UTC) FILETIME=[DA833CB0:01C756BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: "Kent Leung \(kleung\)" , mip4@ietf.org Subject: [Mip4] Re: Comments on draft-ietf-nemo-v4-base-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Alex, I somehow missed replying to this email. Sorry about that. Alexandru Petrescu wrote: >> - Support for mobile networks using the FA CoA mode is not explained >> clearly. > > Ok, trying to clear that. The goal is to have as little as possible FA > talkin this document, ideally none at all. There's another draft > looking about enhancing FA for moving network support. > > The goal is also to have this draft work ok when 'legacy' FAs are present. > > Would you agree with the generic idea to completely avoid FA text in > this 'base' draft? It would involve removal of following text about: > (1) intermerdiary tunnel optimization (3) MR obtains a FA CoA (4) HA > replies back to FA (5) HA encapsulates to FA (6) MR routes packet to FA. You could say, that the current draft addresses only co-located CoA mode. FA CoA mode is addressed in a separate document. As far as this draft is concerned, the mobile router could ignore the FA on the access link, perform DHCP for address configuration and send a registration request to the HA directly. >>> IPv4 Network Mobility (NEMO) Basic Support Protocol >> >> Lets just call it "IPv4 Network Mobility (NEMO) Protocol". The Basic >> Support was used for NEMOv6 since there was a plan to work on route >> optimization for NEMOv6 and this was called Extended Support. Its >> not the same with MIPv4 and IPv4 NEMO. > > I agree. I've changed the title to "IPv4 Network Mobility (NEMO) > Protocol". If anybody is against this change in title please say so. > > Remark the Charter main nemo text doesn't use "basic support" but does > use "base protocol" in the timeline. If we change the draft title then > the timeline should be updated too. That milestone item needs to be update anyway. Sep 2007 Base MIPv4 Mobile Network Support (Draft Std.) to IESG It talks about Draft Standard. It should have said "Proposed Standard". :) >>> This document specifies an additional tunnel between Mobile Router's >>> Home Address and the Home Agent. This tunnel is encapsulated within >>> the normal tunnel between the Care-of Address (CoA) and Home Agent. >>> In Foreign Agent CoA mode, the tunnel between >>> the Mobile Router and Home Agent is needed to allow the Foreign >>> Agent to direct the decapsulated packet to the proper visiting Mobile >>> Router. >> >> Lets take an example. >> >> IPv4 hdr (src=HA, dst=FA-CoA) >> IPv4 hdr (src=HA, dst=HoA) >> IPv4 hdr (src=CN, dst=MNN) >> Payload >> >> I borrowed the MNN terminology for NEMOv6 to indicate a host that is >> attached to the mobile network. The above packet format is always >> used for FA CoA mode, correct? > > Yes, should be correct. > > I think that additional tunnel for FA-CoA mode should be specified in > the FA NEMO draft. Ok >>> However, in Collocated CoA mode, the additional tunnel is not >>> essential and can be eliminated because the Mobile Router is the >>> recipient of the encapsulated packets for the Mobile Network. >> >> This would give us >> >> IPv4 hdr (src=HA, dst=CoA) IPv4 hdr (src=CN, dst=MNN) Payload >> >> This gives us a unique case of the packet overhead being the same for >> the co-located CoA mode and the FA CoA mode. :) > > Yes, I understand. Looks strange to me too, but that's logical > conclusion - tunnel overhead same for CCoA and FACoA modes, for a MR, > not for a MH. > > I agree to remove the MR-FA-CoA tunnel overhead optimization, if that's > what you suggest. However, I find the idea of clearly showing what > encapsulated headers look like very appealing. Do you want me to add that? Sure. But since the FA CoA mode is going to be described in a separate document, do we need to? >>> 4.2. Mobile Network Acknowledgement Extension >>> >>> The Registration Reply contains zero, one or several Mobile Network >>> Acknowledgement extensions in addition to any other extensions >>> defined by or in the context of ([RFC3344]). For Implicit Mode, the >>> Mobile Network Acknowledgement informs the Mobile Router the prefixes >>> served by the Home Agent. >> >> You mean owned by the Mobile Router? The Home Agent only sets up >> forwarding for the mobile network prefix. Is this what you mean by >> "served by the Home Agent"? > > changed that too, look: >> The Registration Reply contains zero, one or several Mobile Network >> Acknowledgement extensions in addition to any other extensions defined >> by or in the context of ([RFC3344]). For Implicit Mode, the Mobile >> Network Acknowledgement informs the Mobile Router the prefixes >> for which the Home Agent sets up forwarding with respect to this >> Mobile Router. [...] Looks good. >>> In accordance with this specification, a Mobile Router may operate >>> in one of the following two modes: explicit and implicit. In >>> explicit mode, the Mobile Router includes Mobile Network Prefix >>> information in all Registration Requests (as Mobile Network Request >>> extensions), while in implicit mode it does not include this >>> information in any Registration Request. In this latter case, the >>> Home Agent obtains the Mobile Network Prefixes by other means than >>> Mobile IP. >> >> Perhaps give one example, like configuration on the home agent. > > What example would be more helpful to your reading? Can I say that the > HA obtains the MR's routes from its routing table, from an ICMP Redirect > sent by the BR or from a static configuration file. Or from all three. > From another? Perhaps mention just static configuration on the home agent for the implicit mode as an example. Other means are ofcourse possible. >>> A Mobile Router can obtain a Collocated or Foreign Agent Care-of- >>> Address while operating in explicit or implicit modes. >> >> Whether the mobile router is using the explicit or implicit mode it >> has no impact on FA or colocated CoA mode, right? Anyway re-phrase the >> above sentence to >> >> A Mobile Router MAY use either Co-located or Foreign Agent Care-of >> Address while operating in explicit or implicit mode. > > Ok. If we get rid entirely of specifying FA behaviour then I'd be > completely silent about MR obtaining a FA CoA, would you agree to remove > the FA CoA obtention. Ok. >>> If all checks are successful, the Home Agent either creates a new >>> entry(ies) for the Mobile Router or updates an existing binding >>> entry(ies) for it >> >> Isn't there only one entry per Mobile Router? > > If there are two egress interfaces and moving simultaneously then there > would be two HoAs, right? > >> Are you considering multiple home addresses per mobile router? > > Yes, one per interface. > >> Anyway a registration request can only modify one binding cache entry >> at a time. It cannot modify more than one, right? > > Yes, because of that HoA. So text became: >> If all checks are successful, the Home Agent either creates a new >> entry for the Mobile Router or updates an existing binding entry for >> it and returns a successful registration reply back to the Mobile >> Router or the Foreign Agent (if the registration request was received >> from a Foreign Agent). Ok. >>> If the Mobile Router updates the mobile network prefix routes via a >>> dynamic routing protocol, the Home Agent SHOULD propagate the routes >>> on the appropriate networks. >> >> This is the first mention of running a dynamic routing protocol >> between the MR and the HA. Perhaps it should be described briefly >> somewhere earlier on how to run a dynamic routing protocol between the >> mobile router and the HA. > > Not sure how to do that. I mean if I want to do it completely I'd split > it from this document. Not sure what kind of text would you like here. > A new subsection earlier than this? If I remove the mentioning of > dynamic routing protocol completely would it fit your reading? If you want to run a routing protocol over the tunnel between the Mobile Router and the Home Agent, it might be better if there is a separate section on it. Similar to what we did in RFC 3963. Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Feb 23 15:46:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhIv-0006GH-Jv; Fri, 23 Feb 2007 15:46:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhIu-0006GC-7R for mip4@ietf.org; Fri, 23 Feb 2007 15:46:08 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhIt-0005uY-G8 for mip4@ietf.org; Fri, 23 Feb 2007 15:46:08 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1NKh09B004574; Fri, 23 Feb 2007 22:43:12 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 22:45:50 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 14:45:47 -0600 Received: from 10.241.58.84 ([10.241.58.84]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Feb 2007 20:45:47 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 23 Feb 2007 12:45:52 -0800 Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt From: Rajeev Koodli To: ext Alexandru Petrescu , McCann Peter-A001034 Message-ID: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt Thread-Index: AcdXi5s+2dPfvMN+Edu3gwAWy5YJpw== In-Reply-To: <45D36579.401@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Feb 2007 20:45:47.0798 (UTC) FILETIME=[98BD9360:01C7578B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Alex, I have revised the draft again based on your input, which's been quite useful. It should show up on the ML soon. I provide some replies on-line. Thanks. I think I have addressed the issues. I would like to move forward. Regards, -Rajeev On 2/14/07 11:39 AM, "ext Alexandru Petrescu" wrote: > '[1]' is FMIPv6 and MIPv4 is none. Suggest replace the first '[1]' with > a '[2]'. In several places throughout the document this should be made > sure ok. The references should be okay now. > > Still editorial: "protocol disengages" instead of "protocol disengage". > But these kinds could be caught by last stages of editing I believe. Done. >> In any case, NAR MUST forward the contents of this message, starting >> from the Type field, to PAR, which means the Source and Destination >> IP addresses now contain the IP addresses of NAR and PAR >> respectively. > > Well, pure 'forwarding' doesn't modify any packet except for TTL. The > above text seems to mistake 'forwarding' with creation of a new IP > header and copying the ICMP contents from the received packet to the > new. Suggest eliminate use of 'forward' and use 'transmit'. Or use the > terms 'rewrite addresses in IP headers'. > > Or maybe I'm too picky on the term 'forwarding'... but should be clear > to reader that this is either a new packet or address rewriting. Revised the text a bit to indicate that it's a new packet with src/dst addresses set to NAR and PAR. > >> The protocol provides an option for NAR to return NCoA for use by the >> mobile node. When NAR can provide an NCoA for exclusive use of the >> mobile node, the address is supplied in the HAck message. The PAR >> includes this NCoA in FBack. > > Suggest add text to say that this method of address allocation has > strong implications on the use of DHCP or IPv4 Stateless Address > Auto-configuration. If HAck-assigned addresses are used then DHCP and > SLAAC shouldn't be used, or similar. > Added text " Nevertheless, the MN should be prepared to use this address instead of performing DHCP or similar operations to obtain an IPv4 address." I think it is sufficient to get across the point that there are implications to using DHCP. > > Use '[2]' instead of RFC3344? Or '[RFC3344]'? Or '[2] (RFC3344)'? > Rather than writing only 'RFC 3344'. Done. > > RFC3344 RegReq Flags: >> S|B|D|M|G|r|T|x >> S - simultaneous bindings >> B - broadcast datagrams > > Suggest text to say that FMIPv4 on AR ignores flags S and B and MN sets > them both to '0'. Done. > >> Home Address MUST be PCoA (i.e., either co-located CoA or >> Home Address) > > Suggest text 'MUST be PCoA, as a co-located CoA or as MN's Home > Address', otherwise risk of reading 'Home Address MUST be Home Address'. Revised text. > > FBack contents: >> Identification a 64-bit number used for matching FBU. See >> RFC 3344. > > Suggest text to say that the Id is copied from the FBU this is a reply > to. This text is already written in the HAck id to HI. > Done. > > PrRtAdv contents: >> Code 0, 1, 2, 3 or 4. See below. > > Below are described only Codes 0 and 1. But at least till the end of > the section 5.4 there's no description of codes 2, 3 nor 4. Suggest to > describe the effects of using all codes (0-4) in this section. > > Is this the same Codes in HAck (section 5.5.2)? HAck codes make no > sense in PrRtAdv. What is it, sorry? Okay, the remaining codes are defined in rfc4068. But, I have provided them here so that there is no need to go back to rfc4068. This also meant providing the details of neighborhood discovery in Option-Code field in the LLA format as in rfc4068. I think this has improved the readability and harmonized the ID with rfc4068 for maximum compatibility. > Suggest text to say that in case the PrRtAdv option contains a new CoA > to be assigned by the MN then this has strong impacts on the use of DHCP > or SLAAC, in addition to the use of HAck-assigned addresses. Added the text mentioned above. > > HI Contents: >> New Care of Address >> The IP address the MN wishes to use when >> connected to the destination. When the `S' bit is >> set, NAR MAY assign this address. > > Specify that if this field is present then the NCoA in HAck and in > PrRtAdv contain the same thing, and that it has impacts on the use of > DHCP and SLAAC. Same as above. > > Option formats: >> Length The length of the option (including the type and >> length fields) in units of octets. For example, >> the length for IEEE 802 addresses is 1 [IPv6- >> ETHER]. > > '[IPv6-ETHER]' reference is undefined. I don't know where it should point. > > IEEE 802 MAC addresses are 6octet long (48bits). > > Type+Len+MAC would make for 10 octets. > > I'm not sure what was the authors' intention on how to encode this, but > it's not clear. > > Or maybe it was meant 'in units of 10 octets'? > Actually, the length is in 8 octets. So, with Type+Len+MAC, it would be 1. However, the Option-Code field in the LLA would necessitate some padding. >> 6.2. New IPv4 Address Option Format >> >> This option is used to provide the new router's IPv4 address in >> PrRtAdv. > > ... or the NCoA in PrRtAdv. > Done. >> New IPv4 Address >> NAR's IPv4 address or the NCoA assigned by NAR. > ...or the NCoA... > >> 7. Security Considerations >> >> The FBU and FBack messages MUST be protected > > Suggest text to say that HI/HAck must be protected too. > Revised text. >> 8. IANA Considerations > > Suggest text to say that Types, Sub-types and Codes are to be assigned > supposedly from two different spaces: ICMP and Mobile IP. Done. Thanks again. -Rajeev > > Pete wrote: >> >> Rajeev, I note that there are a number of nits found by the idnits >> tool at >> http://tools.ietf.org/wg/mip4/draft-ietf-mip4-fmipv4/draft-ietf-mip4-fmi >> pv4-03.nits.txt >> >> Could you please take care of them? >> >> Assuming Alex is ok and the nits are addressed, I will go ahead with >> requesting publication. >> >> -Pete > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Feb 23 16:26:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhvd-0003Kj-Qh; Fri, 23 Feb 2007 16:26:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKhvd-0003KX-AX for mip4@ietf.org; Fri, 23 Feb 2007 16:26:09 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKhva-0005Iv-RB for mip4@ietf.org; Fri, 23 Feb 2007 16:26:09 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1NKtuXa014695; Fri, 23 Feb 2007 22:55:58 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 22:58:36 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 14:58:24 -0600 Received: from 10.241.58.141 ([10.241.58.141]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 23 Feb 2007 20:58:24 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Fri, 23 Feb 2007 12:58:29 -0800 Subject: Re: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt From: Rajeev Koodli To: Rajeev Koodli , ext Alexandru Petrescu , McCann Peter-A001034 Message-ID: Thread-Topic: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-03.txt Thread-Index: AcdXi5s+2dPfvMN+Edu3gwAWy5YJpwAAcM0y In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Feb 2007 20:58:24.0611 (UTC) FILETIME=[5BD61330:01C7578D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070223225558-394B1BB0-196B8528/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org On 2/23/07 12:45 PM, "ext Rajeev Koodli" wrote: > I have revised the draft again based on your input, which's been quite > useful. It should show up on the ML soon. I provide some replies on-line. > In the meanwhile, you can access it from http://people.nokia.net/~rajeev/draft-ietf-mip4-fmipv4-04.txt -Rajeev -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 26 08:27:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLfsr-0002Vx-QC; Mon, 26 Feb 2007 08:27:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLfsq-0002Us-Cc for mip4@ietf.org; Mon, 26 Feb 2007 08:27:16 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLfso-0000bi-Eb for mip4@ietf.org; Mon, 26 Feb 2007 08:27:16 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1172496433!17371973!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 21669 invoked from network); 26 Feb 2007 13:27:13 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 26 Feb 2007 13:27:13 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1QDRDLl013101; Mon, 26 Feb 2007 06:27:13 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l1QDRB5d006714; Mon, 26 Feb 2007 07:27:12 -0600 (CST) Message-ID: <45E2E02E.5020706@motorola.com> Date: Mon, 26 Feb 2007 14:27:10 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Vijay Devarapalli References: <457E204A.5060609@azairenet.com> <45ABA670.6020308@motorola.com> <45DDF94D.7010106@azairenet.com> In-Reply-To: <45DDF94D.7010106@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: "Gopal Dommety \(gdommety\)" , "Kent Leung \(kleung\)" , mip4@ietf.org, "Narayanan, Vidya" Subject: [Mip4] Re: Comments on draft-ietf-mip4-nemo-v4-base-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Vijay, I've submitted draft-ietf-mip4-nemo-v4-base-00.txt. It will show up soon on the I-D directory and hopefully on this mMIP4 mailing list. It's now nameed according to the MIP4 WG, no longer NEMO WG. Please check I've addressed correctly all your comments. There's changelog. The draft was reduced from 16 pages to 15. Please feed back. MIP4 members: please feedback on this draft, thank you, Alex Vijay Devarapalli wrote: > Hi Alex, > > I somehow missed replying to this email. Sorry about that. > > Alexandru Petrescu wrote: >>> - Support for mobile networks using the FA CoA mode is not >>> explained clearly. >> >> Ok, trying to clear that. The goal is to have as little as >> possible FA talkin this document, ideally none at all. There's >> another draft looking about enhancing FA for moving network >> support. >> >> The goal is also to have this draft work ok when 'legacy' FAs are >> present. >> >> Would you agree with the generic idea to completely avoid FA text >> in this 'base' draft? It would involve removal of following text >> about: (1) intermerdiary tunnel optimization (3) MR obtains a FA >> CoA (4) HA replies back to FA (5) HA encapsulates to FA (6) MR >> routes packet to FA. > > You could say, that the current draft addresses only co-located CoA > mode. FA CoA mode is addressed in a separate document. Done, right up in the Introduction. > As far as this draft is concerned, the mobile router could ignore the > FA on the access link, perform DHCP for address configuration and > send a registration request to the HA directly. Todo. >>>> IPv4 Network Mobility (NEMO) Basic Support Protocol >>> >>> Lets just call it "IPv4 Network Mobility (NEMO) Protocol". The >>> Basic Support was used for NEMOv6 since there was a plan to work >>> on route optimization for NEMOv6 and this was called Extended >>> Support. Its not the same with MIPv4 and IPv4 NEMO. >> >> I agree. I've changed the title to "IPv4 Network Mobility (NEMO) >> Protocol". If anybody is against this change in title please say >> so. >> >> Remark the Charter main nemo text doesn't use "basic support" but >> does use "base protocol" in the timeline. If we change the draft >> title then the timeline should be updated too. > > That milestone item needs to be update anyway. Right. >> I agree to remove the MR-FA-CoA tunnel overhead optimization, if >> that's what you suggest. However, I find the idea of clearly >> showing what encapsulated headers look like very appealing. Do you >> want me to add that? > > Sure. But since the FA CoA mode is going to be described in a > separate document, do we need to? No. >>>> In accordance with this specification, a Mobile Router may >>>> operate in one of the following two modes: explicit and >>>> implicit. In explicit mode, the Mobile Router includes Mobile >>>> Network Prefix information in all Registration Requests (as >>>> Mobile Network Request extensions), while in implicit mode it >>>> does not include this information in any Registration Request. >>>> In this latter case, the Home Agent obtains the Mobile Network >>>> Prefixes by other means than Mobile IP. >>> >>> Perhaps give one example, like configuration on the home agent. >> >> What example would be more helpful to your reading? Can I say that >> the HA obtains the MR's routes from its routing table, from an ICMP >> Redirect sent by the BR or from a static configuration file. Or >> from all three. From another? > > Perhaps mention just static configuration on the home agent for the > implicit mode as an example. Other means are ofcourse possible. Done, 1 phrase. >>>> If the Mobile Router updates the mobile network prefix routes >>>> via a dynamic routing protocol, the Home Agent SHOULD propagate >>>> the routes on the appropriate networks. >>> >>> This is the first mention of running a dynamic routing protocol >>> between the MR and the HA. Perhaps it should be described briefly >>> somewhere earlier on how to run a dynamic routing protocol >>> between the mobile router and the HA. >> >> Not sure how to do that. I mean if I want to do it completely I'd >> split it from this document. Not sure what kind of text would you >> like here. A new subsection earlier than this? If I remove the >> mentioning of dynamic routing protocol completely would it fit your >> reading? > > If you want to run a routing protocol over the tunnel between the > Mobile Router and the Home Agent, it might be better if there is a > separate section on it. Similar to what we did in RFC 3963. Do you want to write it? I want to keep the number of authors limited to the usual limit. Let's talk to group and co-authors as well about this option. The draft was reduced by 1 page (from 16 to 15 pages). Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 26 09:25:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLgms-0000sF-GI; Mon, 26 Feb 2007 09:25:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLgmr-0000rm-Ei for mip4@ietf.org; Mon, 26 Feb 2007 09:25:09 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLgmo-0008H4-M4 for mip4@ietf.org; Mon, 26 Feb 2007 09:25:09 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1172499905!8590827!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29492 invoked from network); 26 Feb 2007 14:25:05 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-128.messagelabs.com with SMTP; 26 Feb 2007 14:25:05 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1QEP5dH000793; Mon, 26 Feb 2007 07:25:05 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l1QEP3sU008055; Mon, 26 Feb 2007 08:25:04 -0600 (CST) Message-ID: <45E2EDBF.9090306@motorola.com> Date: Mon, 26 Feb 2007 15:25:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rajeev Koodli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Rajeev, thanks for revising so quickly. Rajeev Koodli wrote: >>> The protocol provides an option for NAR to return NCoA for use by the >>> mobile node. When NAR can provide an NCoA for exclusive use of the >>> mobile node, the address is supplied in the HAck message. The PAR >>> includes this NCoA in FBack. >> Suggest add text to say that this method of address allocation has >> strong implications on the use of DHCP or IPv4 Stateless Address >> Auto-configuration. If HAck-assigned addresses are used then DHCP and >> SLAAC shouldn't be used, or similar. >> > > Added text " Nevertheless, the MN should be prepared to use this address > instead of performing DHCP or similar operations to obtain an IPv4 address." > > I think it is sufficient to get across the point that there are implications > to using DHCP. That's a good point. >> PrRtAdv contents: >>> Code 0, 1, 2, 3 or 4. See below. >> Below are described only Codes 0 and 1. But at least till the end of >> the section 5.4 there's no description of codes 2, 3 nor 4. Suggest to >> describe the effects of using all codes (0-4) in this section. >> >> Is this the same Codes in HAck (section 5.5.2)? HAck codes make no >> sense in PrRtAdv. What is it, sorry? > > Okay, the remaining codes are defined in rfc4068. But, I have provided them > here so that there is no need to go back to rfc4068. This also meant > providing the details of neighborhood discovery in Option-Code field in the > LLA format as in rfc4068. I think this has improved the readability and > harmonized the ID with rfc4068 for maximum compatibility. Thanks, I'll have to read that in detail. >> Option formats: >>> Length The length of the option (including the type and >>> length fields) in units of octets. For example, >>> the length for IEEE 802 addresses is 1 [IPv6- >>> ETHER]. >> '[IPv6-ETHER]' reference is undefined. I don't know where it should point. >> >> IEEE 802 MAC addresses are 6octet long (48bits). >> >> Type+Len+MAC would make for 10 octets. >> >> I'm not sure what was the authors' intention on how to encode this, but >> it's not clear. >> >> Or maybe it was meant 'in units of 10 octets'? >> > > Actually, the length is in 8 octets. Right. > So, with Type+Len+MAC, it would be 1. Right. > However, the Option-Code field in the LLA would necessitate some padding. That's why you removed the reference to IPv6-ETHER? Or the talk about the 48bit MAC addresses? Do we have a standard IPv4 means to pad? I don't think. We do in IPv6 but not in IPv4... no? draft: > Depending on the size of the individual LLA option, appropriate > padding MUST be used to ensure that the entire option size is a > multiple of 8 octets. Sorry, just wondering whether we have an appropriate means of padding in IPv4. Or maybe we can say that the IPv6-style padding should be used. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 26 11:41:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLiv2-0002Yr-UR; Mon, 26 Feb 2007 11:41:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLiv1-0002Yg-UK for mip4@ietf.org; Mon, 26 Feb 2007 11:41:43 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLiuy-00027i-VE for mip4@ietf.org; Mon, 26 Feb 2007 11:41:43 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1QGcDai008595; Mon, 26 Feb 2007 18:38:45 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 18:41:28 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 10:41:23 -0600 Received: from 10.241.58.222 ([10.241.58.222]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Feb 2007 16:41:23 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 26 Feb 2007 08:41:33 -0800 From: Rajeev Koodli To: ext Alexandru Petrescu Message-ID: Thread-Topic: padding 48bit MAC addresses in FMIPv4 Thread-Index: AcdZxPkKN6TRiMW4EduLxAAWy5YJpw== In-Reply-To: <45E2EDBF.9090306@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 16:41:23.0420 (UTC) FILETIME=[F35451C0:01C759C4] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070226183845-1FF7FBB0-6C4806D6/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org On 2/26/07 6:25 AM, "ext Alexandru Petrescu" wrote: > >> However, the Option-Code field in the LLA would necessitate some padding. > > That's why you removed the reference to IPv6-ETHER? Or the talk about > the 48bit MAC addresses? Do we have a standard IPv4 means to pad? I > don't think. We do in IPv6 but not in IPv4... no? Actually, the reference to IPv6-ETHER was from RFC2461. > > draft: >> Depending on the size of the individual LLA option, appropriate >> padding MUST be used to ensure that the entire option size is a >> multiple of 8 octets. > > Sorry, just wondering whether we have an appropriate means of padding in > IPv4. Or maybe we can say that the IPv6-style padding should be used. > I think we could use IPv6-style (more specifically, RFC2461 style [see LLA definition]) padding. -Rajeev > Alex > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 26 12:18:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjV4-0003cc-La; Mon, 26 Feb 2007 12:18:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjV3-0003Z4-0m for mip4@ietf.org; Mon, 26 Feb 2007 12:18:57 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLjV1-0006tJ-Pn for mip4@ietf.org; Mon, 26 Feb 2007 12:18:57 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1172510333!16202061!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14574 invoked from network); 26 Feb 2007 17:18:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 26 Feb 2007 17:18:53 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1QHImN3002877; Mon, 26 Feb 2007 10:18:53 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l1QHIlLi026172; Mon, 26 Feb 2007 11:18:47 -0600 (CST) Message-ID: <45E31676.5080205@motorola.com> Date: Mon, 26 Feb 2007 18:18:46 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rajeev Koodli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev Koodli wrote: > > > On 2/26/07 6:25 AM, "ext Alexandru Petrescu" > wrote: > >>> However, the Option-Code field in the LLA would necessitate some padding. >> That's why you removed the reference to IPv6-ETHER? Or the talk about >> the 48bit MAC addresses? Do we have a standard IPv4 means to pad? I >> don't think. We do in IPv6 but not in IPv4... no? > > Actually, the reference to IPv6-ETHER was from RFC2461. > >> draft: >>> Depending on the size of the individual LLA option, appropriate >>> padding MUST be used to ensure that the entire option size is a >>> multiple of 8 octets. >> Sorry, just wondering whether we have an appropriate means of padding in >> IPv4. Or maybe we can say that the IPv6-style padding should be used. >> > > I think we could use IPv6-style (more specifically, RFC2461 style [see LLA > definition]) padding. Can we say that ^ in thid draft (explicitely rfc2461-style LLA padding), instead of simply 'appropriate' padding must be used? Thanks, Alex PS: because rfc3344 Mobile IPv4 defines a 'one-byte padding extension' which is only one byte. Should FMIPv4 use MIP4 7 one-byte paddings? Or rfc2461-style type-length paddings? What do you think. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 26 13:53:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkyX-0001Ro-JD; Mon, 26 Feb 2007 13:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkyW-0001Rd-EX for mip4@ietf.org; Mon, 26 Feb 2007 13:53:28 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLkyR-00037l-L8 for mip4@ietf.org; Mon, 26 Feb 2007 13:53:28 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1QImrbY026592; Mon, 26 Feb 2007 20:49:27 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 20:52:50 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 12:52:46 -0600 Received: from 10.241.58.45 ([10.241.58.45]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Feb 2007 18:52:45 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 26 Feb 2007 10:52:56 -0800 From: Rajeev Koodli To: ext Alexandru Petrescu Message-ID: Thread-Topic: padding 48bit MAC addresses in FMIPv4 Thread-Index: AcdZ11OskgQwnsXKEduLxAAWy5YJpw== In-Reply-To: <45E31676.5080205@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Feb 2007 18:52:46.0116 (UTC) FILETIME=[4DC84640:01C759D7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org On 2/26/07 9:18 AM, "ext Alexandru Petrescu" wrote: >> I think we could use IPv6-style (more specifically, RFC2461 style [see LLA >> definition]) padding. > > Can we say that ^ in thid draft (explicitely rfc2461-style LLA padding), > instead of simply 'appropriate' padding must be used? > Okay. > Thanks, > > Alex > PS: because rfc3344 Mobile IPv4 defines a 'one-byte padding extension' > which is only one byte. Should FMIPv4 use MIP4 7 one-byte paddings? > Or rfc2461-style type-length paddings? What do you think. Hmm.. I prefer 2461-style because we don't need to use 7 one-byte paddings. But I am okay with the latter too. Let me know. I would like to resolve this and get the draft forward. It's been long.. Thanks, -Rajeev -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 26 15:30:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmUm-0001na-B9; Mon, 26 Feb 2007 15:30:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmUl-0001nQ-4T for mip4@ietf.org; Mon, 26 Feb 2007 15:30:51 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLmUb-0002X8-Kk for mip4@ietf.org; Mon, 26 Feb 2007 15:30:51 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1172521839!16695738!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 17009 invoked from network); 26 Feb 2007 20:30:40 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-4.tower-128.messagelabs.com with SMTP; 26 Feb 2007 20:30:40 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l1QKdSWJ012048; Mon, 26 Feb 2007 13:39:29 -0700 (MST) Received: from [10.129.41.5] ([10.129.41.5]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1QKUbSP027276; Mon, 26 Feb 2007 14:30:38 -0600 (CST) Message-ID: <45E3435D.5010001@motorola.com> Date: Mon, 26 Feb 2007 21:30:21 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rajeev Koodli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev Koodli wrote: > > > On 2/26/07 9:18 AM, "ext Alexandru Petrescu" > wrote: > >>> I think we could use IPv6-style (more specifically, RFC2461 style [see LLA >>> definition]) padding. >> Can we say that ^ in thid draft (explicitely rfc2461-style LLA padding), >> instead of simply 'appropriate' padding must be used? >> > > Okay. > >> Thanks, >> >> Alex >> PS: because rfc3344 Mobile IPv4 defines a 'one-byte padding extension' >> which is only one byte. Should FMIPv4 use MIP4 7 one-byte paddings? >> Or rfc2461-style type-length paddings? What do you think. > > Hmm.. I prefer 2461-style because we don't need to use 7 one-byte paddings. > But I am okay with the latter too. Let me know. I would like to resolve this > and get the draft forward. It's been long.. Sorry for being long. I believe the draft is in much better shape now. I'm ok with mentioning 2461-style instead of 1-byte 3344-style. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Feb 26 15:53:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmr3-0003Uu-Dk; Mon, 26 Feb 2007 15:53:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmnp-0004Ga-L8; Mon, 26 Feb 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLmnp-0007dQ-3V; Mon, 26 Feb 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D6E2A2ACF5; Mon, 26 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLmnK-0004yr-JI; Mon, 26 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-fmipv4-04.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Fast Handovers Author(s) : R. Koodli, C. Perkins Filename : draft-ietf-mip4-fmipv4-04.txt Pages : 26 Date : 2007-2-26 This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations. Specifically, this document addresses movement detection, IP address configuration and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. Additional mechanisms may be defined in the future versions of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-fmipv4-04.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-mip4-fmipv4-04.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: <2007-2-26112634.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-fmipv4-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-fmipv4-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-26112634.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Mon Feb 26 18:52:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpdT-00024W-Qb; Mon, 26 Feb 2007 18:52:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpc0-0000i1-QT; Mon, 26 Feb 2007 18:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HLpc0-0004Y8-FU; Mon, 26 Feb 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 655EF2ACA9; Mon, 26 Feb 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HLpbW-0000IN-5M; Mon, 26 Feb 2007 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 26 Feb 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Extension for Configuration Options Exchange Author(s) : J. Bharatia, et al. Filename : draft-ietf-mip4-gen-ext-01.txt Pages : 13 Date : 2007-2-26 This document describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service (e.g. DNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mip4-gen-ext-01.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-mip4-gen-ext-01.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: <2007-2-26165104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-gen-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-gen-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-26165104.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Wed Feb 28 10:45:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzo-0005vr-36; Wed, 28 Feb 2007 10:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCMK-0001sg-Qp; Mon, 19 Feb 2007 12:31:28 -0500 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJCMF-0004hP-Sy; Mon, 19 Feb 2007 12:31:28 -0500 Received: from SNOOPY.unile.it (unknown [193.204.77.105]) by mailing.unile.it (Postfix) with ESMTP id 6AAA3104B4F; Mon, 19 Feb 2007 18:30:59 +0100 (CET) Message-Id: <7.0.1.0.2.20070219182411.02656a10@unile.it> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 19 Feb 2007 18:31:02 +0100 To: luigi.patrono@unile.it From: "Ing. Luigi Patrono" Mime-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: softcom@fesb.hr Subject: [Mip4] CfP: Symposium on Mobile Wireless Networks X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1943667431==" Errors-To: mip4-bounces@ietf.org --===============1943667431== Content-Type: multipart/alternative; boundary="=====================_4432156==.ALT" --=====================_4432156==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.) ************************************************************************************************************************************* Symposium on MOBILE WIRELESS NETWORKS September 27-29, 2007 Split-Dubrovnik (CROATIA) Symposium Chair: Mario De Blasi University of Lecce, Italy, (mario.deblasi@unile.it) The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2007/CfP_SS1.pdf for more details) will be held in the frame of the 15th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2007), co-sponsored by the IEEE Communication Society (COMSOC). The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility. We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication: * Ad Hoc Wireless Networks * Simulation, modelling or real-world test-beds of wireless networks and systems * Roadside-to-vehicle and vehicle-to-vehicle communication * Safety and non-safety applications * Wireless MAC protocols: design and analysis * Mobile Internet * Wireless Standards * Transport layer for Wireless Networks * Interoperability between heterogeneous Wireless Networks * Wireless Sensor Networks * Energy management in Ad Hoc Wireless Networks * Quality of Service in Wireless Networks Important dates: Paper submission: June 1, 2007 Notification of acceptance: July 1, 2007 Camera ready papers due: August 1, 2007 Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 (http://www.fesb.hr/SoftCOM). ---------------------------------------------------- Ing. Luigi Patrono, PhD ---------------------------------------------------- University of Lecce Dep. of Innovation Engineering Via Monteroni 73100 Lecce - ITALY Tel. +39 0832 297330 Fax. +39 0832 297279 e-mail: luigi.patrono@unile.it ---------------------------------------------------- --=====================_4432156==.ALT Content-Type: text/html; charset="us-ascii" (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.)
*************************************************************************************************************************************

Symposium on
MOBILE WIRELESS NETWORKS

September 27-29, 2007
Split-Dubrovnik (CROATIA)

Symposium Chair: Mario De Blasi
University of Lecce, Italy, (mario.deblasi@unile.it)


The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2007/CfP_SS1.pdf for more details) will be held in the frame of the 15th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2007), co-sponsored by the IEEE Communication Society (COMSOC).
 
The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility.
We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication:
* Ad Hoc Wireless Networks
* Simulation, modelling or real-world test-beds of wireless networks and systems
* Roadside-to-vehicle and vehicle-to-vehicle communication
* Safety and non-safety applications
* Wireless MAC protocols: design and analysis
* Mobile Internet
* Wireless Standards
* Transport layer for Wireless Networks
* Interoperability between heterogeneous Wireless Networks
* Wireless Sensor Networks
* Energy management in Ad Hoc Wireless Networks
* Quality of Service in Wireless Networks

Important dates:  
                          Paper submission: June 1, 2007
                          Notification of acceptance: July 1, 2007
                          Camera ready papers due: August 1, 2007


Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 ( http://www.fesb.hr/SoftCOM).






----------------------------------------------------
Ing.  Luigi Patrono,  PhD
----------------------------------------------------
University of Lecce
Dep. of Innovation Engineering
Via Monteroni
73100 Lecce - ITALY

Tel.  +39 0832 297330
Fax. +39 0832 297279
e-mail: luigi.patrono@unile.it
---------------------------------------------------- --=====================_4432156==.ALT-- --===============1943667431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1943667431==-- From mip4-bounces@ietf.org Wed Feb 28 10:45:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzp-0005wF-EF; Wed, 28 Feb 2007 10:45:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdSt-0001xM-Lp for mip4@ietf.org; Tue, 20 Feb 2007 17:28:03 -0500 Received: from ulysses.noc.ntua.gr ([2001:648:2000:de::230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJdSp-0000iF-90 for mip4@ietf.org; Tue, 20 Feb 2007 17:28:03 -0500 Received: from ektor.telecom.ece.ntua.gr (ektor.telecom.ece.ntua.gr [147.102.7.1]) by ulysses.noc.ntua.gr (8.14.0/8.14.0) with ESMTP id l1KMQVtA025150; Wed, 21 Feb 2007 00:27:06 +0200 (EET) (envelope-from pimrc07-bounces@telecom.ntua.gr) Received: from localhost (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 47FCC8A39C; Wed, 21 Feb 2007 00:27:05 +0200 (EET) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on ulysses.noc.ntua.gr X-Virus-Scanned: Clam AntiVirus on ektor.telecom.ece.ntua.gr Received: from ektor.telecom.ece.ntua.gr ([127.0.0.1]) by localhost (ektor.telecom.ece.ntua.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJAx2BMlrJjS; Wed, 21 Feb 2007 00:27:04 +0200 (EET) Received: from ektor.telecom.ece.ntua.gr (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 7E38C8A2D4; Wed, 21 Feb 2007 00:24:01 +0200 (EET) X-Original-To: pimrc07@telecom.ntua.gr Delivered-To: pimrc07@telecom.ntua.gr Received: from localhost (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 8CB208A2B8 for ; Wed, 21 Feb 2007 00:23:10 +0200 (EET) X-Virus-Scanned: Clam AntiVirus on ektor.telecom.ece.ntua.gr Received: from ektor.telecom.ece.ntua.gr ([127.0.0.1]) by localhost (ektor.telecom.ece.ntua.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J4WbWeZ8Ajt for ; Wed, 21 Feb 2007 00:23:04 +0200 (EET) Received: from harry (ppp022-012.dsl.hol.gr [89.210.22.12]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 312BC8A2BB for ; Wed, 21 Feb 2007 00:23:03 +0200 (EET) Message-ID: <050f01c7553d$b30df1b0$1ab2a8c0@telecom.ntua.gr> To: References: <01d801c74d40$c66fcd50$1ab2a8c0@telecom.ntua.gr> Date: Wed, 21 Feb 2007 00:23:08 +0200 Organization: NTUA MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 From: PIMRC 2007 X-BeenThere: pimrc07@telecom.ntua.gr X-Mailman-Version: 2.1.8 Precedence: list List-Archive: Content-Type: multipart/mixed; boundary="===============0910341611==" X-Virus-Status: Clean X-Spam-Score: 1.0 (+) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: Subject: [Mip4] [pimrc07] IEEE PIMRC 2007, Athens, Greece X-BeenThere: mip4@ietf.org Reply-To: pimrc07@telecom.ntua.gr List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0910341611== Content-Type: multipart/alternative; boundary="----=_NextPart_000_050C_01C7554E.7631E560" This is a multi-part message in MIME format. ------=_NextPart_000_050C_01C7554E.7631E560 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable [Apologies if you receive multiple copies of this CFP] ***************************************************************** CALL FOR PAPERS, WORKSHOP, TUTORIAL AND SPECIAL SESSION PROPOSALS IEEE PIMRC 2007 18th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, September, 3-7, 2007, Athens, Greece http://www.pimrc2007.org ***************************************************************** Conference Main Theme: Wireless Entropy Overview PIMRC 2007 provides a global forum for presenting the most recent advances, the future technical challenges and business opportunities = that comprise the contemporary landscape in wireless communications. The organizers endeavour to attract contributions covering not only conventional areas of wireless communications (e.g., physical layer), = but also emerging areas with high potential for essential scientific and societal impact such as wireless sensors for biomedical applications and non-trivial pervasive computing services. The latter areas are expected = to facilitate the development of a broad vision of innovative future applications in wireless communications. The high quality IEEE endorsed technical programme, will also include tutorials, workshops, = exhibitions, panel discussions and keynote presentations from leading experts coming from the academic community, industry, as well as regulatory and standardisation bodies. PIMRC 2007 will be held in Athens, Greece, September 3-7, 2007 i.e. one week following the peak of Greece's beautiful summer season. Call for Papers Authors are invited to submit high-quality papers describing original = and previously unpublished contributions in a wide range of topics in = wireless communications. These topics are clustered into the following three = major categories: 1) Physical Layer and MAC 2) Mobile and Wireless Networks 3) Applications, Services and Business Models Papers should be in English, strictly not exceeding 5 double-column = pages (3,000 words), in Adobe PDF format (which is the only accepted format = for PIMRC 2007). Authors should use the relevant IEEE template, ensuring an IEEE Xplore compatible PDF-format. To access the full list of topics, submission guidelines, as well as = venue and travel information please visit: www.pimrc2007.org Important Dates Full papers due: March 3rd, 2007 Acceptance notice: May 31st, 2007 Final manuscript due: June 16th, 2007 Conference dates: September 3-7, 2007 Call for Workshop Proposals We solicit workshop proposals on new and emerging topics in wireless communication and networks, services, and applications. A proposal = should focus on a specific theme of current interest seeking for high-quality submissions. Proposals for one-day workshops to be held in conjunction = with the main conference are solicited. A proposal can be a maximum of 2 = pages long and should clearly identify the theme and specific topics of = interest which define the scope of the workshop. It should also stress how it = intends to provide more insight into the proposed topics with respect to the = main conference. The proposal should include the workshop chairs and a = tentative list of program committee members. The organizers of approved workshops will be responsible for advertising their workshops, inviting experts, reviewing submitted papers, and collecting camera-ready copies of accepted papers. The rest of the organizational details (registrations, workshop rooms, etc.) will be covered by the PIMRC Organizing Committee. Proposal Submission: Please send workshop proposals in PDF format by March 1, 2007 to the workshop co-chairs, Dr. Charalambos Skianis (skianis@iit.demokritos.gr), = Dr. Nikos Passas (passas@di.uoa.gr) and Dr. Nikos Papadakis (nkpap@telecom.ntua.gr). Important Dates: Proposal submission due: March 1, 2007 Notification of acceptance: April 1, 2007 Workshop date: September 3, 2007 Call for Tutorials Proposals for Tutorials (half/full day), are welcome based on the topics = listed in the Call for Papers or others related to issues and = opportunities=20 for the future of wireless communications, systems and applications.=20 Proposals should be submitted electronically, containing the following=20 information: * Tutorial Title * Instructor(s) * Extended Abstract (1 page) * Table of Contents (as detailed as possible) * Proposed Duration (half day, full day) * Thematic Area * Target Group(s) * Titles and venues of related tutorials that you may have given in = the=20 past, indicating (roughly) attendance level * Biographical sketch of the instructor(s) Please submit this information electronically to: * papadias@ait.edu.gr and * gyov@ait.edu.gr in order to allow for a prompt and thorough evaluation of your tutorial=20 proposal. The evaluation criteria for each proposal include the = expertise=20 and experience of the instructor(s), the relevance of the subject, as = well=20 as the general objectives of the conference. Important dates Tutorial submission deadline: April 30th, 2007 PIMRC 2007 Tutorials: September 2nd, 2007 Tutorial Sessions Co-Chairs Prof. Constantinos Papadias, Athens Information Technology Prof. Gregory Yovanof, Athens Information Technology Call for Special Sessions PIMRC 2007 invites proposals for special sessions to be held in = conjunction=20 with conference. We solicit proposals for half and full day special = sessions=20 related to the conference topics. The aim of a special session is to = bring=20 together professionals from academia and industry to exchange ideas,=20 experiences and identify obstacles and propose solutions in different=20 domains of communications and telecommunications concerning key = innovative=20 issues. Proposals for special sessions should stress how they intend to=20 provide more insight into the proposed innovative topic with respect to = the=20 main conference. Proposal submission Spesial sessions proposals should be submitted to the spesial session=20 co-chairs with the title, a description of the topic, and the names of = key=20 organizers and potential presenters, by March 12, 2007. Prior contact = with=20 the spesial session co-chairs is encouraged. The organizer(s) of = approved=20 spesial sessions will be responsible for advertising their special = session,=20 and for the reviewing process for their papers, and for the collection = of=20 camera-ready copies of accepted papers. The spesial session proposal = should=20 follow the specific proposal form available at the website. Imortant dates Proposal submission due: March 12, 2007 Notification of acceptance: April 1, 2007 Spesial Session Co-Chairs Dr. Didier Bourse, Motorola Labs, Didier.Bourse@motorola.com Prof. George Kormentzas, University of Aegean, gkorm@aegean.gr Prof. Andreas Polydoros, National and Kapodistrian University of Athens, polydoros@phys.uoa.gr ------=_NextPart_000_050C_01C7554E.7631E560 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

[Apologies if you receive multiple = copies of this=20 CFP]


*********************************************************= ********

CALL=20 FOR PAPERS, WORKSHOP, TUTORIAL=20 AND
           =   =20 SPECIAL SESSION=20 PROPOSALS

         &n= bsp;           &nb= sp;     =20 IEEE PIMRC=20 2007

          &= nbsp;=20 18th IEEE International Symposium on
Personal, Indoor and Mobile = Radio=20 Communications,
         =   =20 September, 3-7, 2007, Athens,=20 Greece
          &nb= sp;         =20 http://www.pimrc2007.org

****************************************************************= *


Conference=20 Main Theme: Wireless Entropy

Overview

PIMRC 2007 provides = a global=20 forum for presenting the most recent
advances, the future technical=20 challenges and business opportunities that
comprise the contemporary=20 landscape in wireless communications. The
organizers endeavour to = attract=20 contributions covering not only
conventional areas of wireless = communications=20 (e.g., physical layer), but
also emerging areas with high potential = for=20 essential scientific and
societal impact such as wireless sensors for = biomedical applications and
non-trivial pervasive computing services. = The=20 latter areas are expected to
facilitate the development of a broad = vision of=20 innovative future
applications in wireless communications. The high = quality=20 IEEE endorsed
technical programme, will also include tutorials, = workshops,=20 exhibitions,
panel discussions and keynote presentations from leading = experts=20 coming
from the academic community, industry, as well as regulatory=20 and
standardisation
bodies.

PIMRC 2007 will be held in = Athens,=20 Greece, September 3-7, 2007 i.e. one
week following the peak of = Greece's=20 beautiful summer season.


Call for Papers

Authors are = invited=20 to submit high-quality papers describing original and
previously = unpublished=20 contributions in a wide range of topics in wireless
communications. = These=20 topics are clustered into the following three = major
categories:

1)=20 Physical Layer and MAC
2) Mobile and Wireless Networks
3) = Applications,=20 Services and Business Models

Papers should be in English, = strictly not=20 exceeding 5 double-column pages
(3,000 words), in Adobe PDF format = (which is=20 the only accepted format for
PIMRC 2007). Authors should use the = relevant=20 IEEE template, ensuring an
IEEE Xplore compatible = PDF-format.

To=20 access the full list of topics, submission guidelines, as well as = venue
and=20 travel information please visit: www.pimrc2007.org

Important=20 Dates

Full papers due:  March 3rd, 2007
Acceptance=20 notice:   May 31st, 2007
Final manuscript due:  June = 16th,=20 2007
Conference dates: September 3-7, 2007


Call for = Workshop=20 Proposals

We solicit workshop proposals on new and emerging = topics in=20 wireless
communication and networks, services, and applications. A = proposal=20 should
focus on a specific theme of current interest seeking for=20 high-quality
submissions. Proposals for one-day workshops to be held = in=20 conjunction with
the main conference are solicited. A proposal can be = a=20 maximum of 2 pages
long and should clearly identify the theme and = specific=20 topics of interest
which define the scope of the workshop. It should = also=20 stress how it intends
to provide more insight into the proposed = topics with=20 respect to the main
conference. The proposal should include the = workshop=20 chairs and a tentative
list of program committee members.

The=20 organizers of approved workshops will be responsible for = advertising
their=20 workshops, inviting experts, reviewing submitted papers, = and
collecting=20 camera-ready copies of accepted papers. The rest of = the
organizational=20 details (registrations, workshop rooms, etc.) will be
covered by the = PIMRC=20 Organizing Committee.

Proposal Submission:

Please send = workshop=20 proposals in PDF format by March 1, 2007 to the
workshop co-chairs, = Dr.=20 Charalambos Skianis (skianis@iit.demokritos.gr), = Dr.
Nikos Passas=20 (passas@di.uoa.gr) and=20 Dr. Nikos Papadakis
(nkpap@telecom.ntua.gr).

Important=20 Dates:

Proposal submission due: March 1, 2007
Notification of=20 acceptance: April 1, 2007
Workshop date: September 3, = 2007


Call=20 for Tutorials

Proposals for Tutorials (half/full day), are = welcome based=20 on the topics
listed in the Call for Papers or others related to = issues and=20 opportunities
for the future of wireless communications, systems and = applications.
Proposals should be submitted electronically, = containing the=20 following
information:

    * Tutorial=20 Title
    * Instructor(s)
    * = Extended=20 Abstract (1 page)
    * Table of Contents (as detailed = as=20 possible)
    * Proposed Duration (half day, full=20 day)
    * Thematic Area
    * = Target=20 Group(s)
    * Titles and venues of related tutorials = that you=20 may have given in the
past, indicating (roughly) attendance=20 level
    * Biographical sketch of the=20 instructor(s)

Please submit this information electronically=20 to:

    * papadias@ait.edu.gr = and
    *=20 gyov@ait.edu.gr

in=20 order to allow for a prompt and thorough evaluation of your tutorial=20
proposal. The evaluation criteria for each proposal include the = expertise=20
and experience of the instructor(s), the relevance of the subject, = as well=20
as the general objectives of the conference.

Important=20 dates

Tutorial submission deadline: April 30th, 2007
PIMRC = 2007=20 Tutorials: September 2nd, 2007

Tutorial Sessions = Co-Chairs

Prof.=20 Constantinos Papadias, Athens Information Technology
Prof. Gregory = Yovanof,=20 Athens Information Technology


Call for Special = Sessions

PIMRC=20 2007 invites proposals for special sessions to be held in conjunction =
with=20 conference. We solicit proposals for half and full day special sessions=20
related to the conference topics. The aim of a special session is to = bring=20
together professionals from academia and industry to exchange ideas, =
experiences and identify obstacles and propose solutions in = different=20
domains of communications and telecommunications concerning key = innovative=20
issues. Proposals for special sessions should stress how they intend = to=20
provide more insight into the proposed innovative topic with respect = to the=20
main conference.

Proposal submission

Spesial sessions=20 proposals should be submitted to the spesial session
co-chairs with = the=20 title, a description of the topic, and the names of key
organizers = and=20 potential presenters, by March 12, 2007. Prior contact with
the = spesial=20 session co-chairs is encouraged. The organizer(s) of approved =
spesial=20 sessions will be responsible for advertising their special session, =
and for=20 the reviewing process for their papers, and for the collection of=20
camera-ready copies of accepted papers. The spesial session proposal = should=20
follow the specific proposal form available at the = website.

Imortant=20 dates

Proposal submission due: March 12, 2007
Notification of=20 acceptance: April 1, 2007

Spesial Session Co-Chairs

Dr. = Didier=20 Bourse, Motorola Labs,
Didier.Bourse@motorola.com
Prof. = George=20 Kormentzas, University of Aegean,
gkorm@aegean.gr
Prof. Andreas = Polydoros,=20 National and Kapodistrian University of Athens,
polydoros@phys.uoa.gr=20
------=_NextPart_000_050C_01C7554E.7631E560-- --===============0910341611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pimrc07 mailing list pimrc07@telecom.ntua.gr http://www.telecom.ntua.gr/mailman/listinfo/pimrc07 --===============0910341611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0910341611==-- From mip4-bounces@ietf.org Wed Feb 28 10:45:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzo-0005vr-36; Wed, 28 Feb 2007 10:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJCMK-0001sg-Qp; Mon, 19 Feb 2007 12:31:28 -0500 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJCMF-0004hP-Sy; Mon, 19 Feb 2007 12:31:28 -0500 Received: from SNOOPY.unile.it (unknown [193.204.77.105]) by mailing.unile.it (Postfix) with ESMTP id 6AAA3104B4F; Mon, 19 Feb 2007 18:30:59 +0100 (CET) Message-Id: <7.0.1.0.2.20070219182411.02656a10@unile.it> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 19 Feb 2007 18:31:02 +0100 To: luigi.patrono@unile.it From: "Ing. Luigi Patrono" Mime-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: softcom@fesb.hr Subject: [Mip4] CfP: Symposium on Mobile Wireless Networks X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1943667431==" Errors-To: mip4-bounces@ietf.org --===============1943667431== Content-Type: multipart/alternative; boundary="=====================_4432156==.ALT" --=====================_4432156==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.) ************************************************************************************************************************************* Symposium on MOBILE WIRELESS NETWORKS September 27-29, 2007 Split-Dubrovnik (CROATIA) Symposium Chair: Mario De Blasi University of Lecce, Italy, (mario.deblasi@unile.it) The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2007/CfP_SS1.pdf for more details) will be held in the frame of the 15th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2007), co-sponsored by the IEEE Communication Society (COMSOC). The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility. We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication: * Ad Hoc Wireless Networks * Simulation, modelling or real-world test-beds of wireless networks and systems * Roadside-to-vehicle and vehicle-to-vehicle communication * Safety and non-safety applications * Wireless MAC protocols: design and analysis * Mobile Internet * Wireless Standards * Transport layer for Wireless Networks * Interoperability between heterogeneous Wireless Networks * Wireless Sensor Networks * Energy management in Ad Hoc Wireless Networks * Quality of Service in Wireless Networks Important dates: Paper submission: June 1, 2007 Notification of acceptance: July 1, 2007 Camera ready papers due: August 1, 2007 Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 (http://www.fesb.hr/SoftCOM). ---------------------------------------------------- Ing. Luigi Patrono, PhD ---------------------------------------------------- University of Lecce Dep. of Innovation Engineering Via Monteroni 73100 Lecce - ITALY Tel. +39 0832 297330 Fax. +39 0832 297279 e-mail: luigi.patrono@unile.it ---------------------------------------------------- --=====================_4432156==.ALT Content-Type: text/html; charset="us-ascii" (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.)
*************************************************************************************************************************************

Symposium on
MOBILE WIRELESS NETWORKS

September 27-29, 2007
Split-Dubrovnik (CROATIA)

Symposium Chair: Mario De Blasi
University of Lecce, Italy, (mario.deblasi@unile.it)


The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2007/CfP_SS1.pdf for more details) will be held in the frame of the 15th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2007), co-sponsored by the IEEE Communication Society (COMSOC).
 
The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility.
We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication:
* Ad Hoc Wireless Networks
* Simulation, modelling or real-world test-beds of wireless networks and systems
* Roadside-to-vehicle and vehicle-to-vehicle communication
* Safety and non-safety applications
* Wireless MAC protocols: design and analysis
* Mobile Internet
* Wireless Standards
* Transport layer for Wireless Networks
* Interoperability between heterogeneous Wireless Networks
* Wireless Sensor Networks
* Energy management in Ad Hoc Wireless Networks
* Quality of Service in Wireless Networks

Important dates:  
                          Paper submission: June 1, 2007
                          Notification of acceptance: July 1, 2007
                          Camera ready papers due: August 1, 2007


Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 ( http://www.fesb.hr/SoftCOM).






----------------------------------------------------
Ing.  Luigi Patrono,  PhD
----------------------------------------------------
University of Lecce
Dep. of Innovation Engineering
Via Monteroni
73100 Lecce - ITALY

Tel.  +39 0832 297330
Fax. +39 0832 297279
e-mail: luigi.patrono@unile.it
---------------------------------------------------- --=====================_4432156==.ALT-- --===============1943667431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1943667431==-- From mip4-bounces@ietf.org Wed Feb 28 10:45:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzp-0005wF-EF; Wed, 28 Feb 2007 10:45:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdSt-0001xM-Lp for mip4@ietf.org; Tue, 20 Feb 2007 17:28:03 -0500 Received: from ulysses.noc.ntua.gr ([2001:648:2000:de::230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJdSp-0000iF-90 for mip4@ietf.org; Tue, 20 Feb 2007 17:28:03 -0500 Received: from ektor.telecom.ece.ntua.gr (ektor.telecom.ece.ntua.gr [147.102.7.1]) by ulysses.noc.ntua.gr (8.14.0/8.14.0) with ESMTP id l1KMQVtA025150; Wed, 21 Feb 2007 00:27:06 +0200 (EET) (envelope-from pimrc07-bounces@telecom.ntua.gr) Received: from localhost (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 47FCC8A39C; Wed, 21 Feb 2007 00:27:05 +0200 (EET) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on ulysses.noc.ntua.gr X-Virus-Scanned: Clam AntiVirus on ektor.telecom.ece.ntua.gr Received: from ektor.telecom.ece.ntua.gr ([127.0.0.1]) by localhost (ektor.telecom.ece.ntua.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJAx2BMlrJjS; Wed, 21 Feb 2007 00:27:04 +0200 (EET) Received: from ektor.telecom.ece.ntua.gr (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 7E38C8A2D4; Wed, 21 Feb 2007 00:24:01 +0200 (EET) X-Original-To: pimrc07@telecom.ntua.gr Delivered-To: pimrc07@telecom.ntua.gr Received: from localhost (localhost.telecom.ece.ntua.gr [127.0.0.1]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 8CB208A2B8 for ; Wed, 21 Feb 2007 00:23:10 +0200 (EET) X-Virus-Scanned: Clam AntiVirus on ektor.telecom.ece.ntua.gr Received: from ektor.telecom.ece.ntua.gr ([127.0.0.1]) by localhost (ektor.telecom.ece.ntua.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J4WbWeZ8Ajt for ; Wed, 21 Feb 2007 00:23:04 +0200 (EET) Received: from harry (ppp022-012.dsl.hol.gr [89.210.22.12]) by ektor.telecom.ece.ntua.gr (Postfix) with ESMTP id 312BC8A2BB for ; Wed, 21 Feb 2007 00:23:03 +0200 (EET) Message-ID: <050f01c7553d$b30df1b0$1ab2a8c0@telecom.ntua.gr> To: References: <01d801c74d40$c66fcd50$1ab2a8c0@telecom.ntua.gr> Date: Wed, 21 Feb 2007 00:23:08 +0200 Organization: NTUA MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 From: PIMRC 2007 X-BeenThere: pimrc07@telecom.ntua.gr X-Mailman-Version: 2.1.8 Precedence: list List-Archive: Content-Type: multipart/mixed; boundary="===============0910341611==" X-Virus-Status: Clean X-Spam-Score: 1.0 (+) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: Subject: [Mip4] [pimrc07] IEEE PIMRC 2007, Athens, Greece X-BeenThere: mip4@ietf.org Reply-To: pimrc07@telecom.ntua.gr List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0910341611== Content-Type: multipart/alternative; boundary="----=_NextPart_000_050C_01C7554E.7631E560" This is a multi-part message in MIME format. ------=_NextPart_000_050C_01C7554E.7631E560 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable [Apologies if you receive multiple copies of this CFP] ***************************************************************** CALL FOR PAPERS, WORKSHOP, TUTORIAL AND SPECIAL SESSION PROPOSALS IEEE PIMRC 2007 18th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, September, 3-7, 2007, Athens, Greece http://www.pimrc2007.org ***************************************************************** Conference Main Theme: Wireless Entropy Overview PIMRC 2007 provides a global forum for presenting the most recent advances, the future technical challenges and business opportunities = that comprise the contemporary landscape in wireless communications. The organizers endeavour to attract contributions covering not only conventional areas of wireless communications (e.g., physical layer), = but also emerging areas with high potential for essential scientific and societal impact such as wireless sensors for biomedical applications and non-trivial pervasive computing services. The latter areas are expected = to facilitate the development of a broad vision of innovative future applications in wireless communications. The high quality IEEE endorsed technical programme, will also include tutorials, workshops, = exhibitions, panel discussions and keynote presentations from leading experts coming from the academic community, industry, as well as regulatory and standardisation bodies. PIMRC 2007 will be held in Athens, Greece, September 3-7, 2007 i.e. one week following the peak of Greece's beautiful summer season. Call for Papers Authors are invited to submit high-quality papers describing original = and previously unpublished contributions in a wide range of topics in = wireless communications. These topics are clustered into the following three = major categories: 1) Physical Layer and MAC 2) Mobile and Wireless Networks 3) Applications, Services and Business Models Papers should be in English, strictly not exceeding 5 double-column = pages (3,000 words), in Adobe PDF format (which is the only accepted format = for PIMRC 2007). Authors should use the relevant IEEE template, ensuring an IEEE Xplore compatible PDF-format. To access the full list of topics, submission guidelines, as well as = venue and travel information please visit: www.pimrc2007.org Important Dates Full papers due: March 3rd, 2007 Acceptance notice: May 31st, 2007 Final manuscript due: June 16th, 2007 Conference dates: September 3-7, 2007 Call for Workshop Proposals We solicit workshop proposals on new and emerging topics in wireless communication and networks, services, and applications. A proposal = should focus on a specific theme of current interest seeking for high-quality submissions. Proposals for one-day workshops to be held in conjunction = with the main conference are solicited. A proposal can be a maximum of 2 = pages long and should clearly identify the theme and specific topics of = interest which define the scope of the workshop. It should also stress how it = intends to provide more insight into the proposed topics with respect to the = main conference. The proposal should include the workshop chairs and a = tentative list of program committee members. The organizers of approved workshops will be responsible for advertising their workshops, inviting experts, reviewing submitted papers, and collecting camera-ready copies of accepted papers. The rest of the organizational details (registrations, workshop rooms, etc.) will be covered by the PIMRC Organizing Committee. Proposal Submission: Please send workshop proposals in PDF format by March 1, 2007 to the workshop co-chairs, Dr. Charalambos Skianis (skianis@iit.demokritos.gr), = Dr. Nikos Passas (passas@di.uoa.gr) and Dr. Nikos Papadakis (nkpap@telecom.ntua.gr). Important Dates: Proposal submission due: March 1, 2007 Notification of acceptance: April 1, 2007 Workshop date: September 3, 2007 Call for Tutorials Proposals for Tutorials (half/full day), are welcome based on the topics = listed in the Call for Papers or others related to issues and = opportunities=20 for the future of wireless communications, systems and applications.=20 Proposals should be submitted electronically, containing the following=20 information: * Tutorial Title * Instructor(s) * Extended Abstract (1 page) * Table of Contents (as detailed as possible) * Proposed Duration (half day, full day) * Thematic Area * Target Group(s) * Titles and venues of related tutorials that you may have given in = the=20 past, indicating (roughly) attendance level * Biographical sketch of the instructor(s) Please submit this information electronically to: * papadias@ait.edu.gr and * gyov@ait.edu.gr in order to allow for a prompt and thorough evaluation of your tutorial=20 proposal. The evaluation criteria for each proposal include the = expertise=20 and experience of the instructor(s), the relevance of the subject, as = well=20 as the general objectives of the conference. Important dates Tutorial submission deadline: April 30th, 2007 PIMRC 2007 Tutorials: September 2nd, 2007 Tutorial Sessions Co-Chairs Prof. Constantinos Papadias, Athens Information Technology Prof. Gregory Yovanof, Athens Information Technology Call for Special Sessions PIMRC 2007 invites proposals for special sessions to be held in = conjunction=20 with conference. We solicit proposals for half and full day special = sessions=20 related to the conference topics. The aim of a special session is to = bring=20 together professionals from academia and industry to exchange ideas,=20 experiences and identify obstacles and propose solutions in different=20 domains of communications and telecommunications concerning key = innovative=20 issues. Proposals for special sessions should stress how they intend to=20 provide more insight into the proposed innovative topic with respect to = the=20 main conference. Proposal submission Spesial sessions proposals should be submitted to the spesial session=20 co-chairs with the title, a description of the topic, and the names of = key=20 organizers and potential presenters, by March 12, 2007. Prior contact = with=20 the spesial session co-chairs is encouraged. The organizer(s) of = approved=20 spesial sessions will be responsible for advertising their special = session,=20 and for the reviewing process for their papers, and for the collection = of=20 camera-ready copies of accepted papers. The spesial session proposal = should=20 follow the specific proposal form available at the website. Imortant dates Proposal submission due: March 12, 2007 Notification of acceptance: April 1, 2007 Spesial Session Co-Chairs Dr. Didier Bourse, Motorola Labs, Didier.Bourse@motorola.com Prof. George Kormentzas, University of Aegean, gkorm@aegean.gr Prof. Andreas Polydoros, National and Kapodistrian University of Athens, polydoros@phys.uoa.gr ------=_NextPart_000_050C_01C7554E.7631E560 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

[Apologies if you receive multiple = copies of this=20 CFP]


*********************************************************= ********

CALL=20 FOR PAPERS, WORKSHOP, TUTORIAL=20 AND
           =   =20 SPECIAL SESSION=20 PROPOSALS

         &n= bsp;           &nb= sp;     =20 IEEE PIMRC=20 2007

          &= nbsp;=20 18th IEEE International Symposium on
Personal, Indoor and Mobile = Radio=20 Communications,
         =   =20 September, 3-7, 2007, Athens,=20 Greece
          &nb= sp;         =20 http://www.pimrc2007.org

****************************************************************= *


Conference=20 Main Theme: Wireless Entropy

Overview

PIMRC 2007 provides = a global=20 forum for presenting the most recent
advances, the future technical=20 challenges and business opportunities that
comprise the contemporary=20 landscape in wireless communications. The
organizers endeavour to = attract=20 contributions covering not only
conventional areas of wireless = communications=20 (e.g., physical layer), but
also emerging areas with high potential = for=20 essential scientific and
societal impact such as wireless sensors for = biomedical applications and
non-trivial pervasive computing services. = The=20 latter areas are expected to
facilitate the development of a broad = vision of=20 innovative future
applications in wireless communications. The high = quality=20 IEEE endorsed
technical programme, will also include tutorials, = workshops,=20 exhibitions,
panel discussions and keynote presentations from leading = experts=20 coming
from the academic community, industry, as well as regulatory=20 and
standardisation
bodies.

PIMRC 2007 will be held in = Athens,=20 Greece, September 3-7, 2007 i.e. one
week following the peak of = Greece's=20 beautiful summer season.


Call for Papers

Authors are = invited=20 to submit high-quality papers describing original and
previously = unpublished=20 contributions in a wide range of topics in wireless
communications. = These=20 topics are clustered into the following three = major
categories:

1)=20 Physical Layer and MAC
2) Mobile and Wireless Networks
3) = Applications,=20 Services and Business Models

Papers should be in English, = strictly not=20 exceeding 5 double-column pages
(3,000 words), in Adobe PDF format = (which is=20 the only accepted format for
PIMRC 2007). Authors should use the = relevant=20 IEEE template, ensuring an
IEEE Xplore compatible = PDF-format.

To=20 access the full list of topics, submission guidelines, as well as = venue
and=20 travel information please visit: www.pimrc2007.org

Important=20 Dates

Full papers due:  March 3rd, 2007
Acceptance=20 notice:   May 31st, 2007
Final manuscript due:  June = 16th,=20 2007
Conference dates: September 3-7, 2007


Call for = Workshop=20 Proposals

We solicit workshop proposals on new and emerging = topics in=20 wireless
communication and networks, services, and applications. A = proposal=20 should
focus on a specific theme of current interest seeking for=20 high-quality
submissions. Proposals for one-day workshops to be held = in=20 conjunction with
the main conference are solicited. A proposal can be = a=20 maximum of 2 pages
long and should clearly identify the theme and = specific=20 topics of interest
which define the scope of the workshop. It should = also=20 stress how it intends
to provide more insight into the proposed = topics with=20 respect to the main
conference. The proposal should include the = workshop=20 chairs and a tentative
list of program committee members.

The=20 organizers of approved workshops will be responsible for = advertising
their=20 workshops, inviting experts, reviewing submitted papers, = and
collecting=20 camera-ready copies of accepted papers. The rest of = the
organizational=20 details (registrations, workshop rooms, etc.) will be
covered by the = PIMRC=20 Organizing Committee.

Proposal Submission:

Please send = workshop=20 proposals in PDF format by March 1, 2007 to the
workshop co-chairs, = Dr.=20 Charalambos Skianis (skianis@iit.demokritos.gr), = Dr.
Nikos Passas=20 (passas@di.uoa.gr) and=20 Dr. Nikos Papadakis
(nkpap@telecom.ntua.gr).

Important=20 Dates:

Proposal submission due: March 1, 2007
Notification of=20 acceptance: April 1, 2007
Workshop date: September 3, = 2007


Call=20 for Tutorials

Proposals for Tutorials (half/full day), are = welcome based=20 on the topics
listed in the Call for Papers or others related to = issues and=20 opportunities
for the future of wireless communications, systems and = applications.
Proposals should be submitted electronically, = containing the=20 following
information:

    * Tutorial=20 Title
    * Instructor(s)
    * = Extended=20 Abstract (1 page)
    * Table of Contents (as detailed = as=20 possible)
    * Proposed Duration (half day, full=20 day)
    * Thematic Area
    * = Target=20 Group(s)
    * Titles and venues of related tutorials = that you=20 may have given in the
past, indicating (roughly) attendance=20 level
    * Biographical sketch of the=20 instructor(s)

Please submit this information electronically=20 to:

    * papadias@ait.edu.gr = and
    *=20 gyov@ait.edu.gr

in=20 order to allow for a prompt and thorough evaluation of your tutorial=20
proposal. The evaluation criteria for each proposal include the = expertise=20
and experience of the instructor(s), the relevance of the subject, = as well=20
as the general objectives of the conference.

Important=20 dates

Tutorial submission deadline: April 30th, 2007
PIMRC = 2007=20 Tutorials: September 2nd, 2007

Tutorial Sessions = Co-Chairs

Prof.=20 Constantinos Papadias, Athens Information Technology
Prof. Gregory = Yovanof,=20 Athens Information Technology


Call for Special = Sessions

PIMRC=20 2007 invites proposals for special sessions to be held in conjunction =
with=20 conference. We solicit proposals for half and full day special sessions=20
related to the conference topics. The aim of a special session is to = bring=20
together professionals from academia and industry to exchange ideas, =
experiences and identify obstacles and propose solutions in = different=20
domains of communications and telecommunications concerning key = innovative=20
issues. Proposals for special sessions should stress how they intend = to=20
provide more insight into the proposed innovative topic with respect = to the=20
main conference.

Proposal submission

Spesial sessions=20 proposals should be submitted to the spesial session
co-chairs with = the=20 title, a description of the topic, and the names of key
organizers = and=20 potential presenters, by March 12, 2007. Prior contact with
the = spesial=20 session co-chairs is encouraged. The organizer(s) of approved =
spesial=20 sessions will be responsible for advertising their special session, =
and for=20 the reviewing process for their papers, and for the collection of=20
camera-ready copies of accepted papers. The spesial session proposal = should=20
follow the specific proposal form available at the = website.

Imortant=20 dates

Proposal submission due: March 12, 2007
Notification of=20 acceptance: April 1, 2007

Spesial Session Co-Chairs

Dr. = Didier=20 Bourse, Motorola Labs,
Didier.Bourse@motorola.com
Prof. = George=20 Kormentzas, University of Aegean,
gkorm@aegean.gr
Prof. Andreas = Polydoros,=20 National and Kapodistrian University of Athens,
polydoros@phys.uoa.gr=20
------=_NextPart_000_050C_01C7554E.7631E560-- --===============0910341611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pimrc07 mailing list pimrc07@telecom.ntua.gr http://www.telecom.ntua.gr/mailman/listinfo/pimrc07 --===============0910341611== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0910341611==-- From mip4-bounces@ietf.org Wed Feb 28 10:45:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzq-0005ww-Jw; Wed, 28 Feb 2007 10:45:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJoce-0002a5-BW; Wed, 21 Feb 2007 05:22:52 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJocb-0001EW-RA; Wed, 21 Feb 2007 05:22:52 -0500 Received: From smtp-dist.unsw.edu.au ([149.171.97.17] == smtp-dist-02.services.comms.unsw.EDU.AU) By note With Smtp ; Wed, 21 Feb 2007 21:20:37 +1100 Received: from localhost (avspam-04.services.comms.unsw.edu.au [149.171.100.19]) by smtp-dist.unsw.edu.au (8.13.6/8.13.6) with ESMTP id l1LAKYBc024037; Wed, 21 Feb 2007 21:20:34 +1100 (EST) Received: from smtp.unsw.edu.au ([127.0.0.1]) by localhost (swoop.comms.unsw.edu.au [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id OEDUSsA0yJwE; Wed, 21 Feb 2007 21:20:32 +1100 (EST) Received: from note.orchestra.cse.unsw.EDU.AU (note.orchestra.cse.unsw.EDU.AU [129.94.242.24]) by smtp.unsw.edu.au (8.13.6/8.13.6) with ESMTP id l1LAKW5k002924; Wed, 21 Feb 2007 21:20:32 +1100 (EST) Received: From [192.168.1.150] ([220.233.14.104] == 104.14.233.220.exetel.com.au) (auth-user salilk) (cse-authentic-sender salilk) By note With Smtp ; Wed, 21 Feb 2007 21:20:31 +1100 From: Salil Kanhere To: , , , , , , , , , , , , , , , , , , , , Date: Wed, 21 Feb 2007 21:20:26 +1100 X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 required=5 tests=[AWL=0.086, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] X-CSE-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on note.orchestra.cse.unsw.EDU.AU X-CSE-Spam-Level: X-CSE-Spam-Status: No, score=-1.8 required=4.0 tests=BAYES_00,HTML_40_50, HTML_MESSAGE,UNPARSEABLE_RELAY autolearn=no version=3.1.3 Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: Subject: [Mip4] IEEE SenseApp 2007 - Call For Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0850210420==" Errors-To: mip4-bounces@ietf.org --===============0850210420== Content-Type: multipart/alternative; boundary=Apple-Mail-6-472498553 --Apple-Mail-6-472498553 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed We apologize in advance if you receive multiple copies of this CFP ________________________________________________________________________ __________ SENSEAPP 2007 SECOND IEEE INTERNATIONAL WORKSHOP ON PRACTICAL ISSUES IN BUILDING SENSOR NETWORK APPLICATIONS (in conjunction with IEEE LCN 2007) Dublin, Ireland 15 - 18 October 2007 Web: http://www.cse.unsw.edu.au/~senseapp CALL FOR PAPERS Sensor nodes are tiny autonomous devices that combine sensing, computing and wireless communication capabilities. These nodes are deeply embedded into the physical surroundings, and gather and process information such as temperature, humidity, light characteristics, seismic activities or images and sound samples from the physical world. Networked systems of such sensors are expected to be used in a variety of applications including habitat monitoring, precision agriculture, disaster recovery operations, healthcare and supply chain management. Real-world sensor network deployments and prototypic implementations are still not commonplace. However, experiences gained in such deployments are crucial for the sensor network research community. These results are needed to refine assumptions made when designing hardware, software, protocols and mechanisms for sensor networks. This workshop aims at bringing together researchers from academia and industry to showcase their work and obtain feedback. We expect the workshop to act as a forum for the sensor network research community to discuss open issues, novel solutions and the future development of wireless sensor networks in general. We encourage contributions describing innovative work in the realm of wireless sensor networks. Topics of interest include, but are not limited to: Experiences from real-world sensor network deployment and applications Innovative sensor network applications Middleware support for sensor networks Programming and debugging sensor networks Security, availability and dependability issues in sensor networks Experiences with new sensor hardware Practical problems in implementing localization and time synchronization Experiences with communication protocols Practical medium access control protocols (MACs) Topology control and routing protocols in existing sensor network deployments Fault-tolerance and troubleshooting sensor networks Antenna design and experiences with signal propagation Experiences regarding energy management and network lifetime Configuration and installation support Management of large-scale sensor networks Interconnection between IP and sensor networks Submitted papers will be reviewed by three independent experts in the field. Proceedings of the workshop will be published together with those of IEEE LCN, and will be available in digital format from the IEEE Explore Digital Library. SUBMISSION: FULL PAPERS: Authors are invited to submit original unpublished work, not currently under review by another conference, workshop or journal. Full papers should be restricted to 8 camera-ready pages (in 10 pt font, double column, US letter size, 8.5 x 11 inches, IEEE format), including text, figures and references. Authors should use only standard fonts, i.e. Times Roman, Courier, Symbol, Helvetica or equivalent. POSTER/DEMOS: Poster papers are an opportunity to present initial results and obtain feedback on on-going research. We also welcome submissions for demonstrations that showcase original research, practical implementations and realistic applications of wireless sensor networks. Poster/demo papers must be restricted to 2 camera- ready pages (in 10 pt font, double column, US letter size, 8.5 x 11 inches, IEEE format), including text, figures and references. Papers must be submitted electronically via EDAS. All papers must include title, complete contact information of all authors, abstract and up to 5 keywords on the cover page. The corresponding author must be clearly identified. Further information can be found at http:// www.cse.unsw.edu.au/~senseapp. IMPORTANT DATES: Paper Registration deadline: 23 April 2007 Paper Submission Deadline: 30 April 2007 Notification of Acceptance: 25 June 2007 Camera Ready Copy Due: 23 July 2007 PROGRAM COMMITTEE CO-CHAIRS: Salil Kanhere, The University of New South Wales, Sydney, Australia Utz Roedig, Lancaster University, Ireland STEERING COMMITTEE: Sanjay Jha, The University of New South Wales, Sydney, Australia Cormac Sreenan, University College, Cork, UK TECHNICAL PROGRAM COMMITTEE: Nael Abu-Ghazaleh, SUNY Binghamton, USA Ralf Ackermann, SAP Research, Germany Athanassios Boulis, National ICT Australia, Australia Yuanzhu Peter Chen, Memorial University of Newfoundland, Canada Uday Desai, Indian Institute of Technology Bombay, India Falko Dressler, University of Erlangen, Germany Mohamed Eltoweissy, Virginia Tech, USA Wendi Heinzelman, University of Rochester, USA Wen Hu, CSIRO, Australia Anura Jaysumana, Colorado State University, USA Vana Kalogeraki, University of California at Riverside, USA Gerd Kortuem, Lancaster University, UK Guoqiang Mao, University of Sydney, Australia Jelena Misic, University of Manitoba, Canada Farid Nait-Abdesselam, University of Science and Technology Lille, France Stephan Olariu, Old Dominion University, USA Raju Pandey, University of California at Davis, USA Kaustubh Phanse, Lulea University of Technology, Sweden Kay Roemer, ETH Zurich, Switzerland Ashraf Saad, Armstrong Atlantic State University, USA Selvakennedy Selvadurai, University of Sydney, Australia Vijay Sivaraman, University of New South Wales, Australia Pavan Sikka, CSIRO, Australia Sameer Tilak, University of California at San Diego, USA Thiemo Voigt, Swedish Institute of Computer Science, Sweden Mohamed Younis, University of Maryland at Baltimore County, USA ________________________________________________________________________ __________ regards salil _______________________________________________ Salil Kanhere Lecturer School of Computer Science and Engineering The University Of New South Wales Sydney NSW 2052 Australia E-mail: salilk@cse.unsw.edu.au Web: www.cse.unsw.edu.au/~salilk Tel: +61 2 9385 6927 Fax: +61 2 9385 5995 UNSW CRICOS Provider Code: 00098G Legal Disclaimer: http://www.eng.unsw.edu.au/emailids.htm ______________________________________________ --Apple-Mail-6-472498553 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
We apologize=A0= in advance if=A0 you receive multiple=A0 copies of
this CFP

_____________________________= _____________________________________________________

= =A0=A0 SENSEAPP 2007
SECOND IEEE INTERNATIONAL = WORKSHOP ON PRACTICAL ISSUES IN
BUILDING SENSOR = NETWORK APPLICATIONS
(in conjunction = with IEEE LCN 2007)
Dublin, = Ireland
15 - 18 = October 2007


= =A0=A0 CALL FOR PAPERS


Sensor nodes are tiny = autonomous devices that combine sensing, computing and wireless = communication capabilities. These nodes are deeply embedded into the = physical surroundings, and gather and process information such as = temperature, humidity, light characteristics, seismic activities or = images and sound samples from the physical world. Networked systems of = such sensors are expected to be used in a variety of applications = including habitat monitoring, precision agriculture, disaster recovery = operations, healthcare and supply chain management. Real-world sensor = network deployments and prototypic implementations are still not = commonplace. However, experiences gained in such deployments are crucial = for the sensor network research community. These results are needed to = refine assumptions made when designing hardware, software, protocols and = mechanisms for sensor networks.

This workshop aims at = bringing together researchers from academia and industry to showcase = their work and obtain feedback. We expect the workshop to act as a forum = for the sensor network research community to discuss open issues, novel = solutions and the future development of wireless sensor networks in = general. We encourage contributions describing innovative work in the = realm of wireless sensor networks. Topics of interest include, but are = not limited to:

Experiences from real-world = sensor network deployment and applications
Innovative sensor = network applications
Middleware support for sensor = networks
Programming and debugging sensor = networks
Security, availability and dependability issues in = sensor networks
Experiences with new sensor = hardware
Practical problems in implementing localization and = time synchronization
Experiences with communication = protocols
Practical medium access control protocols = (MACs)
Topology control and routing protocols in existing = sensor network deployments
Fault-tolerance and troubleshooting = sensor networks
Antenna design and experiences with signal = propagation
Experiences regarding energy management and = network lifetime
Configuration and installation = support
Management of large-scale sensor = networks
Interconnection between IP and sensor = networks

Submitted papers will be = reviewed by three independent experts in the field. Proceedings of the = workshop will be published together with those of IEEE LCN, and will be = available in digital format from the IEEE Explore Digital = Library.

SUBMISSION:

FULL PAPERS: Authors are = invited to submit original unpublished work, not currently under review = by another conference, workshop or journal. Full papers should be = restricted to 8 camera-ready pages (in 10 pt font, double column, US = letter size, 8.5 x 11 inches, IEEE format), including text, figures and = references. Authors should use only standard fonts, i.e. Times Roman, = Courier, Symbol, Helvetica or equivalent.

POSTER/DEMOS: Poster papers = are an opportunity to present initial results and obtain feedback on = on-going research. We also welcome submissions for demonstrations that = showcase original research, practical implementations and realistic = applications of wireless sensor networks. Poster/demo papers must be = restricted to 2 camera-ready pages (in 10 pt font, double column, US = letter size, 8.5 x 11 inches, IEEE format), including text, figures and = references.

Papers must be submitted = electronically via EDAS. All papers must include title, complete contact = information of all authors, abstract and up to 5 keywords on the cover = page. The corresponding author must be clearly identified. Further = information can be found at http://www.cse.unsw.edu.au/~= senseapp.

IMPORTANT DATES: =

Paper = Registration deadline: 23 April 2007
Paper Submission = Deadline: 30 April 2007
Notification of Acceptance: 25 June = 2007
Camera Ready Copy Due: 23 July 2007

PROGRAM COMMITTEE = CO-CHAIRS:

Salil Kanhere, The = University of New South Wales, Sydney, Australia
Utz Roedig, = Lancaster University, Ireland

STEERING = COMMITTEE:

Sanjay Jha, The University = of New South Wales, Sydney, Australia
Cormac Sreenan, = University College, Cork, UK

TECHNICAL PROGRAM = COMMITTEE:

Nael= Abu-Ghazaleh, SUNY Binghamton, USA
Ralf Ackermann, SAP = Research, Germany
Athanassios Boulis, National ICT Australia, = Australia
Yuanzhu Peter Chen, Memorial University of = Newfoundland, Canada
Uday Desai, Indian Institute of = Technology Bombay, India
Falko Dressler, University of = Erlangen, Germany
Mohamed Eltoweissy, Virginia Tech, = USA
Wendi Heinzelman, University of Rochester, = USA
Wen Hu, CSIRO, Australia
Anura Jaysumana, = Colorado State University, USA
Vana Kalogeraki, University of = California at Riverside, USA
Gerd Kortuem, Lancaster = University, UK
Guoqiang Mao, University of Sydney, = Australia
Jelena Misic, University of Manitoba, = Canada
Farid Nait-Abdesselam, University of Science and = Technology Lille, France
Stephan Olariu, Old Dominion = University, USA
Raju Pandey, University of California at = Davis, USA
Kaustubh Phanse, Lulea University of Technology, = Sweden
Kay Roemer, ETH Zurich, Switzerland
Ashraf = Saad, Armstrong Atlantic State University, USA
Selvakennedy = Selvadurai, University of Sydney, Australia
Vijay Sivaraman, = University of New South Wales, Australia
Pavan Sikka, CSIRO, = Australia
Sameer Tilak, University of California at San Diego, = USA
Thiemo Voigt, Swedish Institute of Computer Science, = Sweden
Mohamed Younis, University of Maryland at Baltimore = County, = USA
____________________________________________________________= ______________________


regards
salil
salilk@cse.unsw.edu.au
Web: www.cse.unsw.edu.au/~salilk

_____________________________________________= _


=
= --Apple-Mail-6-472498553-- --===============0850210420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0850210420==-- From mip4-bounces@ietf.org Wed Feb 28 10:45:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzs-0005ze-Ob; Wed, 28 Feb 2007 10:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwO0-00016P-IF for mip4@ietf.org; Wed, 21 Feb 2007 13:40:16 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwNz-0007xs-85 for mip4@ietf.org; Wed, 21 Feb 2007 13:40:16 -0500 Received: by nz-out-0506.google.com with SMTP id z6so2413025nzd for ; Wed, 21 Feb 2007 10:40:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Rqv2C5ecc5WwJnJHyWrOZ1qC9QvTgyzk9d6Zzx5e8gihvr5pX+6QqWPbUCpJKiTpqjGYRMEJA/U5EyX48WBvqUPJhGFNwxgcHVyItwYbVbWeYOgfuf3u7YVHn/Gya8LWqs/Lei+tqF8SJ1UeE6QFDcwV+A9Y8j6uZPutNryGbWU= Received: by 10.114.201.1 with SMTP id y1mr3910231waf.1172083214442; Wed, 21 Feb 2007 10:40:14 -0800 (PST) Received: by 10.114.36.4 with HTTP; Wed, 21 Feb 2007 10:40:14 -0800 (PST) Message-ID: <2cc68f00702211040o7696fa88m65750c5f8c61d322@mail.gmail.com> Date: Wed, 21 Feb 2007 10:40:14 -0800 From: "DSI'07 Chairs" To: "DSI'07 Chairs" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 004cb86e8665839f X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: Subject: [Mip4] IPSN Workshop DSI'07: Deadline extended X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Apologies if you receive multiple copies of this message.] Paper submission deadline extended to March 2, 2007 ************************************************************** C A L L F O R P A P E R S IPSN 2007 Workshop Data Sharing and Interoperability on the World-wide Sensor Web (DSI'07) (http://research.microsoft.com/~sumann/DSI07) April 24, 2007, Cambridge, Massachusetts, USA (co-located with IPSN 2007, http://www.cse.wustl.edu/~lu/ipsn07.html) ------------------------------------------------------------------- Over the last five years, the research community supporting embedded sensing has benefited from the experiences of numerous real-world deployments. Actual scientific applications are on the rise, and a number of new environmental observatories are moving from planning to implementation (NEON, WATERS). In parallel, we have seen an expansion in the use smartphones and other consumer devices, supported by the cellular network and capable of capturing acoustics and images, creating a host of citizen-initiated sensing projects (e.g., videothevote.org). While many algorithms for networking and control of embedded sensing platforms anticipate within-deployment scaling of observational resources, the introduction of diverse environmental observatories and the variety of new urban applications suggests that interoperability, and for the purpose of this workshop the ``sharing" of data and models, represents another, equally important, kind of scaling. In this workshop, we focus directly on the implications of widely shared sensor data, models and algorithms, and the systems that might support this. Simply put, data is the raison d'etre of any sensing exercise. While few researchers in the field would argue the point, too much attention has been paid to the networking of distributed sensing and not enough emphasis has been placed on the tools to manage, share, analyze, and understand the data. Hosted in coordination with IPSN (emphasizing algorithms for communications, coding theory, and distributed estimation) and SPOTS (focusing on hardware and complete platforms), this workshop will examine the various uses of data associated with embedded sensing. Topics of interest (but not limited to): - Data interoperability - Data Semantics - Extracting information from data and sensor data fusion - Managing data uncertainty - Systems for data integrity - Modeling sensor data - Managing spatial and temporal data (e.g., indexing, caching, query processing, etc.) - Automated or semi-automated processing of ad-hoc sensor data - Architecture to connect multiple sensor deployments together - Data visualization - Mash-up applications (the ability to pull in data/tools from multiple places and render it at a client) and workflows Submissions: Authors are requested to submit original papers of no more than 6 pages (standard IEEE proceedings two-column format), including figures, tables, and references in PDF that include contact information of all the authors. If you have any questions regarding the submission process, please send e-mail to either Mark Hansen (cocteau@stat.ucla.edu) or Suman Nath (sumann@microsoft.com). See http://research.microsoft.com/~sumann/DSI07/ for submission instructions. Important Dates: Papers due: Friday, March 2, 2007 (Extended and Firm) Notification: Friday, March 30, 2007 Camera Ready: Friday, April 13, 2007 Workshop: Tuesday, April 24, 2007 Organizing Committee: Mark Hansen, UCLA (PC Co-Chair) Suman Nath, Microsoft Research (PC Co-Chair) Program Committee: Karl Aberer, EPFL Matthew Arrott, UCSD Amol Deshpande, University of Maryland Max Egenhofer, University of Maine Mark Hansen, UCLA Suman Nath, Microsoft Research Mani Srivastava, UCLA Andreas Terzis, JHU John Wilbanks, Science Commons -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 10:45:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzt-00061A-Q5; Wed, 28 Feb 2007 10:45:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK43H-0005ay-SU for mip4@ietf.org; Wed, 21 Feb 2007 21:51:23 -0500 Received: from ece.uprm.edu ([136.145.57.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK43C-0006kS-4U for mip4@ietf.org; Wed, 21 Feb 2007 21:51:23 -0500 Received: from kejielupc (perazzamac2.ece.uprm.edu [136.145.57.158]) by ece.uprm.edu (Postfix) with SMTP id 824E8550D1 for ; Wed, 21 Feb 2007 22:51:13 -0400 (AST) Organization: UPR-Mayaguez Message-ID: <54093d5b08c6de8b6b254209001227b7@ece.uprm.edu> From: "Kejie Lu" To: Date: Wed, 21 Feb 2007 22:51:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Subject: [Mip4] CALL FOR PAPERS MILCOM 2007 (Abstracts Due on Mar. 09) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukejie@ece.uprm.edu List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ** Apologies if you receive multiple copies of this message ** ** The deadline for submitting the abstracts has been extended to 09 March = 2007 ** ** The link for submitting the unclassified papers is: = https://wams.jspargo.com/milcom07/login.asp ** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL for PAPERS MILCOM 2007 October 29=9631, 2007 Gaylord Palms Convention Center Orlando, Florida USA Conference Theme:=20 Interoperability: Policy to Performance MILCOM 2007 is soliciting both unclassified and classified papers (up to = DoD Secret) relevant to communications and information processing system = technologies and capabilities that address the 21st century challenges of = National Defense, Homeland Security, Disaster Response and = Interoperability. Industry, academic, and government organizations from = both the U.S. and countries around the globe are invited and encouraged to = participate=2E Important Dates: Abstracts Due: 09 March 2007 Draft Papers Due: 20 April 2007 Author Notification: 25 May 2007 Final Camera Ready Papers Due: 6 July 2007 Suggested technical areas of general interest include but are not limited to: =95 Interoperability =96 Policies and Standards =96 DoD and Federal Agencies =96 State and Local Governments =96 Emergency Grid Communications =96 Coalition Partners =96 Disaster Response =95 Service Oriented Architectures =95 Advanced Communications Technologies =95 Network Management =95 Mobile and Wireless Technologies =95 Radio Systems and Technologies =95 Network Centric Systems and Technologies =95 Applications and Operational Concepts =95 Systems, Programs and Initiatives =95 Information Management and Dissemination =95 Digital Signal Processing =95 Coding =95 Modulation =95 Advanced Waveforms =95 Next Generation Networks and Systems =95 Internet Protocols =95 Link Layer and Cross-Layer Protocols =95 Network Architectures and Routing =95 Transport Protocols and Performance =95 Quality of Service Architectures =95 Design Modeling and Simulation =95 Digital Video Broadcasting and Standards =95 IF/RF Technologies and Techniques =95 Advanced SATCOM systems =95 Airborne Technologies =95 Standards Based Datalinks =95 Mobile Satellite Systems =95 Space Networks and Protocols =95 Wireless Communications =95 Mobile Ad Hoc Networks =95 Computer and Network Security Systems =95 Software Defined Radios and Cognitive Radios =95 Sensor Networks =95 Advanced Antenna Technologies =95 Laser Communications and Optical Networks =95 Tests and Measurements =95 Ultra Wideband =95 Multimedia Communications and Management Technical Program Committee Technical Program Chair Dr. Vitas Mikenas Harris Corporation 321-729-7748 mikenas.milcom2007@harris.com Unclassified Program Chair Dr. Sastri Kota Harris Corporation 408-990-8301 kota.milcom2007@harris.com Classified Program Chair Terry Casto Harris Corporation 321-984-5600 casto.milcom2007@harris.com Panels Program Chair Leo deCardenas Harris Corporation 321-727-6202 decardenas.milcom2007@harris.com Tutorial Program Chair Rich Folio Harris Corporation 321-729-3629 folio.milcom2007@harris.com Unclassified Technical Program Submission Process:=20 The Web-based Abstract Management System (WAMS) (www.milcom.org) is used = to submit abstracts, full papers, and final camera ready papers. During = the abstract submission process, author and password information will need = to be entered and a Paper ID# will be assigned. This Paper ID# and = password will be used to upload papers. The abstract must NOT contain any = ITAR-related, classified, or proprietary information=2E Abstracts will only be used to help define the sessions. The Unclassified = Author=92s Kit provides instructions to authors for preparation of the = full and final manuscripts and the required forms. Full papers will be = reviewed for acceptance only when all appropriate forms have been = completed and received=2E Classified Technical Program Submission Process: All persons wishing to attend and/or participate in the Classified = Technical Program must, at a minimum, possess a current Secret personnel = security clearance and be a U.S. citizen. Non-U.S. originated papers will = NOT be accepted for the Classified Technical Program. All abstracts for = the Classified Technical Program must be unclassified. Please submit a = title and a brief unclassified abstract (up to 2000 characters) of your = intended paper via email to: casto.milcom2007@harris.com. Each submission = requires author name, affiliation, citizenship, address, phone and fax = numbers, email address, and the applicable area. For papers with more than = one author, indicate the point of contact. Do NOT use WAMS to submit = abstracts, full papers, or the final papers for the Classified Technical = Program. All papers for the Classified Technical Program must be prepared = following the instructions and formatting guidelines in the Classified = Author=92s Kit=2E Proposals for Tutorials and Panels:=20 MILCOM 2007 solicits proposals for unclassified half-day tutorials, and = unclassified and classified panels on state-of-the art communications, = networking, and interoperability technologies. The tutorial proposals = should include a brief outline of the tutorial, instructor biography, and = relevant instructor experience. The Unclassified Tutorials Kit provides the applicable forms and the formatting guidelines for the = tutorial material. Please forward your proposals to the MILCOM 2007 = Tutorial Program Chair, Rich Folio, at folio.milcom2007@harris.com=2E Proposals for Panels:=20 The proposals for panels should include a brief outline of the panel = discussion topics, panel participants, and panel moderator along with = their bios. A Panels Kit provides the information about the applicable = forms and the guidelines for the preparation of the panel material. Please = forward your proposals to the MILCOM 2007 Panels Program Chair, Leo = deCardenas, at decardenas.milcom2007@harris.com=2E Tutorials and Panels Important Dates: Proposals Due: 16 March 2007 Notification: 20 April 2007 Material Due: 13 July 2007 For further details and information about MILCOM 2007 please visit = www.milcom.org. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 10:45:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzu-00062T-St; Wed, 28 Feb 2007 10:45:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKgRw-0008NN-Oq; Fri, 23 Feb 2007 14:51:24 -0500 Received: from mail.comsocconferences.org ([140.98.194.93] helo=conan.comsoc.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HKgRs-0004v2-3k; Fri, 23 Feb 2007 14:51:24 -0500 Received: from conan.comsoc.org (conan.comsoc.org [140.98.194.93]) by conan.comsoc.org (GMS Comm 12.01.3461/NY9491.00.1c184a6e) with ESMTP id za3853720 for wcnccfp@comsocconferences.org; Fri, 23 Feb 2007 15:15:22 -0500 Received: from conan.comsoc.org (conan.comsoc.org [140.98.194.93]) by conan.comsoc.org (GMS Comm 12.01.3461/NY9491.00.1c184a6e) with ESMTP id za3853720 for wcnccfp@comsocconferences.org; Fri, 23 Feb 2007 15:11:47 -0500 Received: from [140.98.210.253] by conan.comsoc.org (GMS 12.01.3461/NY9491.00.1c184a6e) with ESMTP id ezgkddaa for wcnccfp@comsocconferences.org; Fri, 23 Feb 2007 15:05:11 -0500 From: Meetings@comsocconferences.org To: wcnccfp@comsocconferences.org Date: Fri, 23 Feb 2007 14:21:28 -0500 MIME-Version: 1.0 Message-ID: <1172240485664788eae43a08eb3ee71f830142f982@comsocconferences.org> X-Originating-IP: [140.98.210.253] X-ListVersion: 12 X-ListMember: [wcnccfp@comsocconferences.org] X-Spam-Score: 0.6 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: Subject: [Mip4] IEEE WCNC 2007: Hotel Deadline Correction: 28 February 2007! X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0650927658==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0650927658== Content-Type: multipart/alternative; boundary="--=_NextPart_00C0654C_0AE7DBFE_01C9F258.D84EF1C0" This is a multi-part message in MIME format. ----=_NextPart_00C0654C_0AE7DBFE_01C9F258.D84EF1C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit EARLY REGISTRATION DEADLINE: 27 JANUARY 2007 IEEE Wireless Communications & Networking Conference (WCNC 2007) 11 – 15 March 2007 /Hong Kong / http://www.ieee-wcnc.org Make sure you are a part of the first WCNC conference outside North America – held in Asia’s world city, Hong Kong, China, The WCNC is the one of the world’s foremost international technical conference for engineers and researchers at the forefront of development and deployment of wireless technologies. Highlights include: Tutorials, Technical Papers, Panels, Keynote Speakers, Poster Sessions and plenty of networking opportunities. Don’t forget to make your hotel reservations! ORGANIZATION General Chairs Technical Program Chair Khaled B. Letaief, Chih-Lin I Ross D. Murch For more WCNC 2007 details & updates, visit: http://www.ieee-wcnc.org To unsubscribe from this IEEE Communications Society Meetings and Conferences mailing list send a blank email message to WCNCcfp-remove@comsocconferences.org. You can also request removal by mail. Please send a note with your email address and the list name (WCNCcfp@comsocconferences.org) to ComSoc List Removal - IT 3 Park Avenue, 17th Floor New York, NY 10016 USA ----=_NextPart_00C0654C_0AE7DBFE_01C9F258.D84EF1C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 8bit

 

Don’t Delay – Please make your WCNC 2007 hotel reservations today!
 
·         Discount reservation deadline extended: Wednesday, 28 February 2007 (was 18 February 2007)  
 
For on-line reservations with the Sheraton Hong Kong Hotels & Towers; please visit:
 
·        http://www.ieee-wcnc.org/2007/hotel.html
 

IMPORTANT NOTICE
IEEE Communications Society has a contractual obligation with the Sheraton to fill a guaranteed block of hotel guest rooms. Very significant penalties will be assessed should this obligation not be met.  By staying at the Sheraton, you’ll enjoy the convenience of residing at the host conference hotel, maximizing peer-to-peer networking opportunities and provide valued assistance in support of IEEE ComSoc financial obligations necessary to ensure WCNC’s continued success.
For more WCNC 2007 details & updates, visit:  http://www.ieee-wcnc.org

 





To unsubscribe from this IEEE Communications Society Meetings and
Conferences mailing list send a blank email message
to WCNCcfp-remove@comsocconferences.org.

You can also request removal by mail. Please send a note with your email address
and the list name (WCNCcfp@comsocconferences.org) to

ComSoc List Removal - IT
3 Park Avenue, 17th Floor
New York, NY 10016 USA ----=_NextPart_00C0654C_0AE7DBFE_01C9F258.D84EF1C0-- --===============0650927658== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0650927658==-- From mip4-bounces@ietf.org Wed Feb 28 10:45:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzy-00063z-PX; Wed, 28 Feb 2007 10:45:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKky9-0007aI-K6 for mip4@ietf.org; Fri, 23 Feb 2007 19:40:57 -0500 Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKky8-000713-8A for mip4@ietf.org; Fri, 23 Feb 2007 19:40:57 -0500 Received: from saffron.ece.neu.edu (saffron.ece.neu.edu [129.10.60.111]) by SMTP1.ECE.NEU.EDU (8.12.5/8.12.5) with SMTP id l1O0eqM7022425 for ; Fri, 23 Feb 2007 19:40:56 -0500 (EST) Received: from ECE.NEU.EDU ([129.10.60.216]) by saffron.ece.neu.edu (SMSSMTP 4.1.5.31) with SMTP id M2007022319401228633 for ; Fri, 23 Feb 2007 19:40:12 -0500 Received: from localhost (basagni@localhost) by ECE.NEU.EDU (8.12.8/8.12.5/Submit) with ESMTP id l1O0eDwn013052 for ; Fri, 23 Feb 2007 19:40:13 -0500 Date: Fri, 23 Feb 2007 19:40:13 -0500 (EST) From: Stefano Basagni To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Subject: [Mip4] CfP: 18th Tyrrhenian Workshop on Digital Communications X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this announcement multiple times.) PRELIMINARY ANNOUNCEMENT and CALL FOR PAPERS 18th Tyrrhenian Workshop on Digital Communications Ischia island, Naples, Italy September 9-12, 2007 Workshop theme WIRELESS COMMUNICATIONS * OVERVIEW The Tyrrhenian workshop on digital communications is each year devoted to a specific theme in the area of digital communications and its applications. After several years the theme of wireless communications return. The scope of the workshop is a friendly exchange of ideas on the main research lines in the field of the workshop theme. This year we have chosen five chapters, and to each of them a session has been devoted: -4G wireless systems -Sensor and ad hoc networks -Security in wireless networks -QoS and efficiency in multimedia heterogeneous wireless networks -Wireless system applications The five sessions are in some sense complementary and interlaced each other. Suggested Technical areas included in the sessions, but are not limited, are: modulation, coding, effects of system impairments, channel modeling, MIMO and smart antennas, cross layer and radio resource management, protocols, routing in wireless networks, cognitive radio, multimedia wireless communications, Quality of Service architectures, security, architectures for security, etc. Some sessions are specifically devoted to and we are looking for the most advanced solutions for security and for applications of wireless systems in many different environment, like multimedia communications, infomobility, health care, emergency situations, etc. Interested authors are invited to submit their papers. Authors could also submit papers yet open for discussion in the area of wireless communications and its applications to the poster session. All submitted papers will be carefully reviewed and, due to the limited space available in the sessions some of them could be proposed for the inclusion in the poster session. * PAPER SUBMISSION GUIDELINES Authors are invited to submit extended summary of the final manuscript of maximum length 5 pages including the main results (figures, tables) electronically in PDF format. Selection of the final manuscripts will be based on the extended summary. Final manuscripts to be considered as regular papers should be limited to 15 double-spaced pages. Final manuscripts to be considered for the poster session should be limited to 10 double-spaced pages. Any paper submitted to the Workshop must not have been published in or submitted to other technical conferences/journals. Proceedings of the Conference will be published as a book by Springer. The web page of the workshop will be ready soon at http://www.cnit.it/html/workshops/2007 * IMPORTANT DATES Deadline for extended abstract: March 31, 2007 Notification of acceptance: April 30, 2007 Final manuscript submission: June 1, 2007 Workshop co-chairs Shingo Ohmori, NiCT, Japan Silvano Pupolin, University of Padova and CNIT, Italy Technical Program Committee Hiroyo Ogawa, NiCT, Japan Anand Prasad, Docomo Euro-Labs, Germany Kato Shuzo, NiCT, Japan Michele Zorzi, University of Padova and CNIT, Italy Publicity Stefano Basagni, Northeastern University, Boston, MA, USA Publications Tomaso Erseghe, University of Padova and CNIT, Italy -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntington Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu *** http://www.ece.neu.edu/faculty/basagni/ *** -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 10:45:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzz-00065P-2Z; Wed, 28 Feb 2007 10:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKnfx-00064n-7B; Fri, 23 Feb 2007 22:34:21 -0500 Received: from newman.cs.purdue.edu ([128.10.2.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKnfu-0005AJ-T7; Fri, 23 Feb 2007 22:34:21 -0500 Received: from aranjuez.cs.purdue.edu (IDENT:0@aranjuez.cs.purdue.edu [128.10.21.39]) by newman.cs.purdue.edu (8.13.6.20060614/8.13.6/PURDUE_CS-2.0) with ESMTP id l1O3QCcO016792; Fri, 23 Feb 2007 22:26:15 -0500 (EST) Received: from aranjuez.cs.purdue.edu (IDENT:166@localhost [127.0.0.1]) by aranjuez.cs.purdue.edu (8.13.6.20060614/8.13.6/PURDUE_CS-2.0) with ESMTP id l1O3QBDo017672; Fri, 23 Feb 2007 22:26:11 -0500 (EST) Received: from localhost (yau@localhost) by aranjuez.cs.purdue.edu (8.13.6.20060614/8.13.6/Submit) with ESMTP id l1O3Pui1017668; Fri, 23 Feb 2007 22:25:57 -0500 (EST) X-Authentication-Warning: aranjuez.cs.purdue.edu: yau owned process doing -bs Date: Fri, 23 Feb 2007 22:25:56 -0500 (EST) From: David K Y Yau To: metrologie@lip6.fr, tarot@hds.utc.fr, imrg@ietf.org, Sigmetrics-bb@merlot.usc.edu, SIGCOMM-MEMBERS@LISTSERV.ACM.ORG, multicomm@comsoc.org, wg2@wireless-world-research.org, wg3@wireless-world-research.org, mip6@ietf.org, mip4@ietf.org, tcos-announce@tcos.org, sigmob@acm.org, wg7_3@cs.umass.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: Subject: [Mip4] ICNP 2007 CFP X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Dear colleague: Our sincere apologies if you receive multiple copies of this announcement. -- ICNP 2007 organizers ICNP 2007 CALL FOR PAPER 15th IEEE International Conference on Network Protocols Beijing, CHINA, October 16-19, 2007 ICNP 2007, the fifteenth IEEE International Conference on Network Protocols, is a conference covering all aspects of network protocols, including design, analysis, specification, verification, implementation, and performance. ICNP 2007 will be held in Beijing, CHINA, October 16-19, 2007. Papers with significant research contributions to the field of network protocols are solicited for submission. Papers cannot be previously published nor under review by another conference or journal. Topics of interest include, but are not limited to: 1. Protocol testing, analysis, design and implementation 2. Measurement and monitoring of protocols 3. Protocols designed for specific functions, such as: routing, flow and congestion control, QoS, signaling, security, network management, or resiliency 4. Protocols designed for specific networks, such as: wireless and mobile networks, ad hoc and sensor networks, virtual networks, and ubiquitous networks Quality papers dealing specifically with protocols will be preferred over quality papers of a more general networking nature. ICNP will select an accepted full paper for the best paper award. IMPORTANT DATES Paper registration: April 8, 2007 Paper submission: April 15, 2007 Notification of acceptance: June 29, 2007 Camera ready version: July 20, 2007 For paper submission, please visit http://icnp2007.edu.cn/ ORGANIZING COMMITTEES EXECUTIVE COMMITTEE: David Lee, Ohio State University, USA (chair) Mostafa Ammar, Georgia Tech, USA Ken Calvert, University of Kentucky, USA Teruo Higashino, Osaka University, Japan Raymond Miller, University of Maryland, USA GENERAL CHAIR: Jianping Wu, Tsinghua University, CHINA John Lui, Chinese University of Hong Kong, CHINA VICE GENERAL CHAIR: Xia Yin,Tsinghua University, CHINA PROGRAM CHAIR: Kenneth L. Calvert, University of Kentucky, USA David Yau, Purdue University, USA WORKSHOP CHAIR: TBA LOCAL ARRANGEMENT CHAIR: Youjian Zhao,Tsinghua University, CHINA PUBLICATION CHAIR: Ke Xu,Tsinghua University, CHINA PUBLICITY CHAIR: Mingwei Xu,Tsinghua University, CHINA STEERING COMMITTEE: Simon Lam, University of Texas, USA (co-chair) David Lee, Ohio State University, USA (co-chair) Mostafa Ammar, Georgia Tech, USA Ken Calvert, University of Kentucky, USA Mohamed Gouda, University of Texas, USA Teruo Higashino, Osaka University, Japan Mike T. Liu, Ohio State University, USA Raymond Miller, University of Maryland, USA Krishan Sabnani, Bell Labs, USA PROGRAM COMMITTEE: See http://icnp2007.edu.cn/ FURTHER INFORMATION: Web site: http://icnp2007.edu.cn/ http://www.ieee-icnp.org/ E-mail: icnp2007@tsinghua.edu.cn TEL: +86 10 62788109 FAX: +86 10 62771527 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 10:45:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzz-00066V-Au; Wed, 28 Feb 2007 10:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLRbt-0001Pd-1o for mip4@ietf.org; Sun, 25 Feb 2007 17:12:49 -0500 Received: from kronos.cti.gr ([150.140.1.25]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HLRbp-0004XQ-3k for mip4@ietf.org; Sun, 25 Feb 2007 17:12:49 -0500 Received: (qmail 38393 invoked from network); 25 Feb 2007 22:12:37 -0000 Received: from hermes.cti.gr (150.140.1.34) by kronos.cti.gr with SMTP; 25 Feb 2007 22:12:37 -0000 Received: (qmail 12588 invoked by uid 41021); 25 Feb 2007 22:12:35 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Feb 2007 22:12:35 -0000 Date: Mon, 26 Feb 2007 00:12:35 +0200 (EET) From: Ioannis Chatzigiannakis To: Ioannis Chatzigiannakis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Cc: Subject: [Mip4] ALGOSENSORS 2007: First Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ************************************************************************** Third International Workshop on Algorithmic Aspects of Wireless Sensor Networks A L G O S E N S O R S 2 0 0 7 July 14, 2006, Wroclaw, Poland To be held in conjunction with ICALP 2007. http://algosensors2007.im.pwr.wroc.pl ************************************************************************** C A L L F O R P A P E R S ************************************************************************** SCOPE Wireless ad-hoc sensor networks have recently become a very active research subject due to their high potential of providing diverse services to numerous important applications, including remote monitoring and tracking in environmental applications and low maintenance ambient intelligence in everyday life. The effective and efficient realization of such large scale, complex ad-hoc networking environments requires intensive, coordinated technical research and development efforts, especially in power aware, scalable, robust wireless distributed protocols, due to the unusual application requirements and the severe resource constraints of the sensor devices. On the other hand, a solid foundational background seems necessary for sensor networks to achieve their full potential. It is a challenge for abstract modeling, algorithmic design and analysis to achieve provably efficient, scalable and fault-tolerant realizations of such huge, highly-dynamic, complex, non-conventional networks. Features including the extremely large number of sensor devices in the network, the severe power, computing and memory limitations, their dense, random deployment and frequent failures, pose new interesting abstract modeling, algorithmic design, analysis and implementation challenges of great practical impact. This Workshop aims to bring together research contributions related to diverse algorithmic and complexity theoretic aspects of wireless sensor networks. This is the third event in the series. ALGOSENSORS 2004 was held in Turku, Finland, ALGOSENSORS 2006 was held in Venice, Italy. Since its beginning ALGOSENSORS is collocated with ICALP. ************************************************************************** TOPICS Contributions solicited cover the algorithmic issues in a variety of topics including (but not limited to): * Abstract models of sensor networks * Methods for ad hoc deployment/topology control * Energy management * Data propagation and routing * Infrastructure discovery * Opportunistic Networking / DTN * Localization * Tracking * Data aggregation/data compression * Obstacle avoidance * Power saving schemes * Communication protocols * Medium access control * Fault tolerance and dependability * Security and trust * Time synchronization * Distributed computing issues ************************************************************************** PROGRAM COMMITTEE CHAIR * Miroslaw Kutylowski, Wroclaw University of Technology, Poland PROGRAM COMMITTEE * Alan A. Bertossi, University of Bologna, Italy * Costas Busch, Rensselaer Polytechnic Institute, USA * Bogdan Chlebus, University of Colorado at Denver, USA * Jacek Cichon, Wroclaw University of Technology, Poland * Andrea Clementi, University of Rome "Tor Vergata", Italy * Tassos Dimitriou, Athens Information Technology, Greece * Sandor Fekete, Braunschweig University of Technology, Germany * Antonio Alfredo Ferreira Loureiro, Universidade Federal de Minas Gerais, Brazil, * Eric Fleury, INRIA, France * Rachid Guerraoui, EPFL, Switzerland * Dariusz Kowalski, University of Liverpool, UK * Evangelos Kranakis, Carleton University, Canada, * Miroslaw Kutylowski, Wroclaw University of Technology, Poland * Jan van Leeuwen, Utrecht University, The Netherlands * Sotiris Nikoletseas, University of Patras and CTI, Greece * Pekka Orponen, Helsinki University of Technology TKK, Finland * Jose D. P. Rolim, University of Geneva, Switzerland, * Christian Scheideler, TU Munich, Germany * Christian Schindelhauer, University of Freiburg, Germany * Paul G. Spirakis, University of Patras and CTI, Greece, * Sebastien Tixeuil, Univ. Paris-Sud / INRIA, France * Peter Widmayer, ETH Zurich, Switzerland ORGANIZING COMMITTEE * Ioannis Chatzigiannakis, Publicity Chair, U. of Patras and CTI, Greece * Agnieszka Rozanska, Local Organization, Wroclaw University of Technology, Poland STEERING COMMITTEE * Josep Diaz, Technical University of Catalonia, Spain * Jan van Leeuwen, Utrecht University, The Netherlands * Sotiris Nikoletseas (Chair), University of Patras and CTI, Greece * Jose Rolim, University of Geneva, Switzerland * Paul Spirakis, University of Patras and CTI, Greece INVITED SPEAKERS * TBA ************************************************************************** PROCEEDINGS Accepted papers will be published in full text in a hardcopy Proceedings by the Lecture Notes in Computer Science (LNCS) Series of Springer Verlag. We are going to have post-proceedings i.e. authors will have the opportunity to revise their papers in the light of the discussion at the event and then submit their camera ready files by the end of August. Pre-proceedings will be available during the workshop for the participants. TCS JOURNAL SPECIAL ISSUE Selected high quality papers will be considered for publication in a Special Issue on Algorithmic Aspects of Wireless Sensor Networks of the Theoretical Computer Science (TCS) Journal. ************************************************************************** PAPER SUBMISSION Authors are invited to submit manuscripts reporting original research in the topics related to the workshop. Simultaneous submission to other conferences is not allowed. Papers should not exceed twelve (12) pages of text using at least 11 point size type, including references, figures, tables, etc., preferably formated in the LNCS style. Additional material may be added at a clearly marked Appendix to be read at the discretion of the Program Committee Members. Authors must submit their papers electronically via Web page: http://algosensors2007.im.pwr.wroc.pl/html/submission.php All papers will be peer reviewed and comments will be provided to the authors. Authors need to make sure that for each accepted paper at least one author will attend the workshop. ************************************************************************** IMPORTANT DATES * Submission Deadline: April 25, 2007 * Author Notification: May 30, 2007 * Camera Ready Manuscript Due: August 28, 2007 ************************************************************************** SPONSORS * Polish Ministry Of Science and Higher Education * Wroclaw University of Technology ************************************************************************** CONTACT * web: http://algosensors2007.im.pwr.wroc.pl * email: algosensors2007@im.pwr.wroc.pl * fax: +4871 320 2109 ************************************************************************** -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 10:45:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzz-00067d-Lc; Wed, 28 Feb 2007 10:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnpZ-0008Bk-5t for mip4@ietf.org; Mon, 26 Feb 2007 16:56:25 -0500 Received: from dynamo.ecn.purdue.edu ([128.46.200.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLnWd-0003zA-TU for mip4@ietf.org; Mon, 26 Feb 2007 16:37:03 -0500 Received: from dynamo.ecn.purdue.edu (localhost [127.0.0.1]) by dynamo.ecn.purdue.edu (8.13.8/8.13.8) with ESMTP id l1QLaPdk026149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Feb 2007 16:36:25 -0500 (EST) Received: (from vr@localhost) by dynamo.ecn.purdue.edu (8.13.8/8.13.8) id l1QLaOmK026141 for mip4@ietf.org; Mon, 26 Feb 2007 16:36:24 -0500 (EST) Date: Mon, 26 Feb 2007 16:36:24 -0500 (EST) From: Vijay Raghunathan Message-Id: <200702262136.l1QLaOmK026141@dynamo.ecn.purdue.edu> To: mip4@ietf.org X-Virus-Scanned-ECN: by amavisd-new X-ECN-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Subject: [Mip4] IEEE SECON 2007: Call for posters and demos X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this call multiple times.) *********************************************************************** CALL FOR POSTERS and DEMOS *Deadline: 3/29/2007, 5 pm EDT* IEEE SECON 2007 The Fourth IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks Merged with IEEE International Workshop on Wireless Ad-hoc and Sensor Networks (IWWAN) http://www.ieee-secon.org/2007/ Sponsored by IEEE Communications Society (www.comsoc.org) NOKIA and France Telecom June 18-21, 2007 San Diego, California, USA ************************************************************************ To provide a forum for discussion and personal interaction between presenter and participants, IEEE SECON 2007 will include poster and demonstration sessions: works in progress, industry demonstrations of new applications and techniques, practical implementations, military, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. One of the key goals of this conference is to foster collaboration between industry, government agencies and academia. Hence, participation of researchers/developers from industry or governement agencies and posters/demonstrations reporting joint work are especially encouraged. Topics considered for posters and demo include but are not limited to: * New architectures and protocols to support communication, localization, time synchronization, routing, data dissemination, and other distributed services in heterogeneous, large-scale distributed, mesh networks and sensor networks * Novel algorithms and theories for management, supervisory control, and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Modeling and performance evaluation of large-scale distributed ad hoc and sensor networks, practical implementations and deployments, and real-world experiences * Theories and models on fundamental information and communication aspects of wireless mesh and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and mesh networks * Algorithms and protocols to support quality of service in mesh and sensor networks, including admission control, resource allocation and fairness, and capacity planning * Integration of sensors into engineered systems, including novel techniques for on-sensor renewable power sources, mechanisms for on-sensor self-calibration and self-testing, and efficient schemes to maximize accuracy and minimize false alarms * Hardware platforms incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware, and tools for mesh and sensor network applications development, deployment, and management Submissions should be in the form of an abstract describing the main contributions of the poster/demo. If available, preliminary results can also be included. Abstracts will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas and promote collaborations. Accepted abstracts will be published in IEEE Xplore. Up to three best posters will be given the opportunity to be presented at the main conference. There will also be a best demo award and a best poster award judged by a panel of academic and/or venture capital participants. Submissions should not be more than three pages (preferably IEEE conference format, 2-column) in length. Demonstration submissions should include the space requirements and/or any other equipment-specific requirements. The documents must contain the authors' names, affiliations, and contact information and the designated corresponding author. Accepted authors of posters/demos will have a space in the poster/demo session room to display their posters or exhibit their demos and describe their work in discussions with interested attendees. IEEE Communications Society policy states that all accepted SECON 2007 posters/demos must have at least one registration at the regular rate. For authors co-authoring multiple posters/demos, one regular registration is valid for up to three presentations. Submission will be accepted until 3/29/2007, 5 pm EDT for demos and for posters. Please send the submission material to the poster/demo chairs in pdf format, and make sure to include the first author name and either POSTER or DEMO in the name of the pdf file: Mingyan Liu Jie Liu University of Michigan Microsoft Research mingyan@eecs.umich.edu Jie.Liu@microsoft.com IMPORTANT DATES: Abstract submission due on: 3/29/2007 Acceptance notification: 4/27/2007 Final abstract due on: 7/5/2007 (two weeks after the conference) ************************************************************************ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 10:45:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQzz-00068f-VX; Wed, 28 Feb 2007 10:45:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM5Cc-0003DL-6R for mip4@ietf.org; Tue, 27 Feb 2007 11:29:22 -0500 Received: from dynamo.ecn.purdue.edu ([128.46.200.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM5Ca-0002h8-S9 for mip4@ietf.org; Tue, 27 Feb 2007 11:29:22 -0500 Received: from dynamo.ecn.purdue.edu (localhost [127.0.0.1]) by dynamo.ecn.purdue.edu (8.13.8/8.13.8) with ESMTP id l1RGTDeB021804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 27 Feb 2007 11:29:13 -0500 (EST) Received: (from vr@localhost) by dynamo.ecn.purdue.edu (8.13.8/8.13.8) id l1RGT7ZD021710 for mip4@ietf.org; Tue, 27 Feb 2007 11:29:07 -0500 (EST) Date: Tue, 27 Feb 2007 11:29:07 -0500 (EST) From: Vijay Raghunathan Message-Id: <200702271629.l1RGT7ZD021710@dynamo.ecn.purdue.edu> To: mip4@ietf.org X-Virus-Scanned-ECN: by amavisd-new X-ECN-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Subject: [Mip4] CFP: IEEE Workshop on Networking Technologies for Software Defined Radio Networks X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ============================================================================= Second IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks (Held in Conjunction with IEEE SECON 2007) June 18, 2007, San Diego, California, USA http://www.winlab.rutgers.edu/~wenyuan/sdr07/index.htm Wireless systems have historically operated in relatively static frequency bands allocated to a single type of service. This compartmentalization of spectrum offered few incentives for common designs across frequency bands and limited opportunities for dynamic spectrum sharing. More recently, there has been a push to make more spectrum available, and in response there has been significant research towards developing new classes of “cognitive” radios and their associated protocols. Cognitive radios (CRs), or more generally software defined radios (SDRs), can tune their communication stack to take advantage of spectrum opportunities, adapt to a wide variety of radio interference conditions, and employ protocols that allow for collaboration between previously incompatible technologies. Dynamic physical layer adaptation is achieved by scanning available spectrum, selection from a wide range of operating frequencies, rapid adjustment of modulation waveforms and adaptive power co! ntrol. A suitably designed cognitive radio with a software-defined physical layer would be capable of collaborating with neighboring radios to ameliorate interference using higher-layer protocols. These higher layer coordination protocols could range from etiquette mechanisms to fully collaborative multi-hop forwarding. The potential impact of cognitive radios upon both commercial and military wireless communications is great as they could allow for improved spectrum utilization and improved interoperability between wireless data standards. The workshop builds upon the success of the First IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks. Although the potential for CR/SDR platforms is great, there remains a need for developing, testing, and prototyping the protocols that will allow the CR platforms to achieve their promise. The purpose of this workshop is to facilitate the exchange of cutting-edge research in cognitive radio and software defined radio technologies. The focus of this workshop is to explore the underlying networking and communication protocols needed to facilitate the interconnection of CR/SDR platforms. Since CR/SDR research is taking place across multiple communities, ranging from academic to government to industry, from physical layer to networking to hardware researchers, we intend for this workshop to serve as a forum for cross-pollination and collaboration that will accelerate the deployment and eventual success of CR/SDR platforms. PAPER SUBMISSION INSTRUCTIONS All submissions must be full papers in PDF format. Papers should be sent by email to SDRWorkshop07@winlab.rutgers.edu. Papers must not exceed 8 single-spaced, two-column pages using at least 11 point size fonts on 8.5 x 11 inch pages. IMPORTANT DATES Manuscript Submission Due: March 19, 2007, 5pm EDT Acceptance Notification: April 18, 2007 Camera-Ready Paper Due: May 5, 2007 WORKSHOP CHAIR Wade Trappe, WINLAB, Rutgers University trappe@winlab.rutgers.edu WORKSHOP ADVISORY BOARD Thomas Hou, Virginia Tech University Jeffrey H. Reed, Virginia Tech University Narayan Mandayam, WINLAB, Rutgers University (Preliminary) TECHNICAL PROGRAM COMMITTEE Joseph Evans, University of Kansas Xin Liu, University of California at Davis Jung-Min Park, Virginia Tech University Masahiro Kuroda, National Institute for Communications Technology (Japan) Haitao Zheng, University of California, Santa Barbara K.J.R. Liu, University of Maryland Wenyuan Xu, WINLAB, Rutgers University Yanyong Zhang, WINLAB, Rutgers University (Others to be determined) ============================================================================= -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 10:45:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMR00-00069g-8G; Wed, 28 Feb 2007 10:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMFx2-0003L0-Iq for mip4@ietf.org; Tue, 27 Feb 2007 22:58:00 -0500 Received: from borg.ece.uprm.edu ([136.145.57.24] helo=ece.uprm.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMFwn-00055V-91 for mip4@ietf.org; Tue, 27 Feb 2007 22:58:00 -0500 Received: from kejielupc (perazzamac2.ece.uprm.edu [136.145.57.158]) by ece.uprm.edu (Postfix) with SMTP id 4794954F61 for ; Tue, 27 Feb 2007 23:57:41 -0400 (AST) Organization: UPR-Mayaguez Message-ID: <9cceb8470d0ae39620b0f43f0010ff92@ece.uprm.edu> From: "Kejie Lu" To: Date: Tue, 27 Feb 2007 23:57:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 X-Mailman-Approved-At: Wed, 28 Feb 2007 10:45:35 -0500 Subject: [Mip4] CALL FOR PAPERS MILCOM 2007 (Abstracts Due on Mar. 09) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lukejie@ece.uprm.edu List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ** Apologies if you receive multiple copies of this message ** ** The deadline for submitting the abstracts has been extended to 09 March = 2007 ** ** The link for submitting the unclassified papers is: = https://wams.jspargo.com/milcom07/login.asp ** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL for PAPERS MILCOM 2007 October 29=9631, 2007 Gaylord Palms Convention Center Orlando, Florida USA Conference Theme:=20 Interoperability: Policy to Performance MILCOM 2007 is soliciting both unclassified and classified papers (up to = DoD Secret) relevant to communications and information processing system = technologies and capabilities that address the 21st century challenges of = National Defense, Homeland Security, Disaster Response and = Interoperability. Industry, academic, and government organizations from = both the U.S. and countries around the globe are invited and encouraged to = participate=2E Important Dates: Abstracts Due: 09 March 2007 Draft Papers Due: 20 April 2007 Author Notification: 25 May 2007 Final Camera Ready Papers Due: 6 July 2007 Suggested technical areas of general interest include but are not limited to: =95 Interoperability =96 Policies and Standards =96 DoD and Federal Agencies =96 State and Local Governments =96 Emergency Grid Communications =96 Coalition Partners =96 Disaster Response =95 Service Oriented Architectures =95 Advanced Communications Technologies =95 Network Management =95 Mobile and Wireless Technologies =95 Radio Systems and Technologies =95 Network Centric Systems and Technologies =95 Applications and Operational Concepts =95 Systems, Programs and Initiatives =95 Information Management and Dissemination =95 Digital Signal Processing =95 Coding =95 Modulation =95 Advanced Waveforms =95 Next Generation Networks and Systems =95 Internet Protocols =95 Link Layer and Cross-Layer Protocols =95 Network Architectures and Routing =95 Transport Protocols and Performance =95 Quality of Service Architectures =95 Design Modeling and Simulation =95 Digital Video Broadcasting and Standards =95 IF/RF Technologies and Techniques =95 Advanced SATCOM systems =95 Airborne Technologies =95 Standards Based Datalinks =95 Mobile Satellite Systems =95 Space Networks and Protocols =95 Wireless Communications =95 Mobile Ad Hoc Networks =95 Computer and Network Security Systems =95 Software Defined Radios and Cognitive Radios =95 Sensor Networks =95 Advanced Antenna Technologies =95 Laser Communications and Optical Networks =95 Tests and Measurements =95 Ultra Wideband =95 Multimedia Communications and Management Technical Program Committee Technical Program Chair Dr. Vitas Mikenas Harris Corporation 321-729-7748 mikenas.milcom2007@harris.com Unclassified Program Chair Dr. Sastri Kota Harris Corporation 408-990-8301 kota.milcom2007@harris.com Classified Program Chair Terry Casto Harris Corporation 321-984-5600 casto.milcom2007@harris.com Panels Program Chair Leo deCardenas Harris Corporation 321-727-6202 decardenas.milcom2007@harris.com Tutorial Program Chair Rich Folio Harris Corporation 321-729-3629 folio.milcom2007@harris.com Unclassified Technical Program Submission Process:=20 The Web-based Abstract Management System (WAMS) (www.milcom.org) is used = to submit abstracts, full papers, and final camera ready papers. During = the abstract submission process, author and password information will need = to be entered and a Paper ID# will be assigned. This Paper ID# and = password will be used to upload papers. The abstract must NOT contain any = ITAR-related, classified, or proprietary information=2E Abstracts will only be used to help define the sessions. The Unclassified = Author=92s Kit provides instructions to authors for preparation of the = full and final manuscripts and the required forms. Full papers will be = reviewed for acceptance only when all appropriate forms have been = completed and received=2E Classified Technical Program Submission Process: All persons wishing to attend and/or participate in the Classified = Technical Program must, at a minimum, possess a current Secret personnel = security clearance and be a U.S. citizen. Non-U.S. originated papers will = NOT be accepted for the Classified Technical Program. All abstracts for = the Classified Technical Program must be unclassified. Please submit a = title and a brief unclassified abstract (up to 2000 characters) of your = intended paper via email to: casto.milcom2007@harris.com. Each submission = requires author name, affiliation, citizenship, address, phone and fax = numbers, email address, and the applicable area. For papers with more than = one author, indicate the point of contact. Do NOT use WAMS to submit = abstracts, full papers, or the final papers for the Classified Technical = Program. All papers for the Classified Technical Program must be prepared = following the instructions and formatting guidelines in the Classified = Author=92s Kit=2E Proposals for Tutorials and Panels:=20 MILCOM 2007 solicits proposals for unclassified half-day tutorials, and = unclassified and classified panels on state-of-the art communications, = networking, and interoperability technologies. The tutorial proposals = should include a brief outline of the tutorial, instructor biography, and = relevant instructor experience. The Unclassified Tutorials Kit provides the applicable forms and the formatting guidelines for the = tutorial material. Please forward your proposals to the MILCOM 2007 = Tutorial Program Chair, Rich Folio, at folio.milcom2007@harris.com=2E Proposals for Panels:=20 The proposals for panels should include a brief outline of the panel = discussion topics, panel participants, and panel moderator along with = their bios. A Panels Kit provides the information about the applicable = forms and the guidelines for the preparation of the panel material. Please = forward your proposals to the MILCOM 2007 Panels Program Chair, Leo = deCardenas, at decardenas.milcom2007@harris.com=2E Tutorials and Panels Important Dates: Proposals Due: 16 March 2007 Notification: 20 April 2007 Material Due: 13 July 2007 For further details and information about MILCOM 2007 please visit = www.milcom.org. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 14:07:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMU8n-0003vN-Q7; Wed, 28 Feb 2007 14:07:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMU8m-0003ph-VZ for mip4@ietf.org; Wed, 28 Feb 2007 14:07:04 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMU8e-0001Qf-Ey for mip4@ietf.org; Wed, 28 Feb 2007 14:07:04 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1SJ4YxY010509; Wed, 28 Feb 2007 21:04:48 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 21:06:42 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 13:06:29 -0600 Received: from 10.241.58.142 ([10.241.58.142]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Feb 2007 19:06:29 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 28 Feb 2007 11:05:44 -0800 From: Rajeev Koodli To: ext Alexandru Petrescu Message-ID: Thread-Topic: padding 48bit MAC addresses in FMIPv4 Thread-Index: Acdba3JDsPCrHsdeEduFMAAWy5YJpw== In-Reply-To: <45E3435D.5010001@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Feb 2007 19:06:30.0110 (UTC) FILETIME=[8DBF47E0:01C75B6B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org On 2/26/07 12:30 PM, "ext Alexandru Petrescu" wrote: > > Sorry for being long. I believe the draft is in much better shape now. > > I'm ok with mentioning 2461-style instead of 1-byte 3344-style. > To be clear, there are no pad options in 2461. So, I will write that the entire LLA option must be a multiple of 8 octets, and the byte fields following the LLA must be initialized to zero by the sender and ignored by the receiver. I think this allows the implementations to choose whichever mechanism best suits. Ok? -Rajeev > Alex > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 15:09:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMV6u-0002ju-Km; Wed, 28 Feb 2007 15:09:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMV6t-0002gZ-6O for mip4@ietf.org; Wed, 28 Feb 2007 15:09:11 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMV6n-0002rH-Fu for mip4@ietf.org; Wed, 28 Feb 2007 15:09:11 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1172693344!16563692!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19363 invoked from network); 28 Feb 2007 20:09:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 28 Feb 2007 20:09:04 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l1SK94m3002973; Wed, 28 Feb 2007 13:09:04 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l1SK92An002535; Wed, 28 Feb 2007 14:09:03 -0600 (CST) Message-ID: <45E5E15E.4040605@motorola.com> Date: Wed, 28 Feb 2007 21:09:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rajeev Koodli References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Rajeev Koodli wrote: > > > On 2/26/07 12:30 PM, "ext Alexandru Petrescu" > wrote: > >> Sorry for being long. I believe the draft is in much better shape now. >> >> I'm ok with mentioning 2461-style instead of 1-byte 3344-style. >> > > To be clear, there are no pad options in 2461. > > So, I will write that the entire LLA option must be a multiple of 8 octets, > and the byte fields following the LLA must be initialized to zero by the > sender and ignored by the receiver. > I think this allows the implementations to choose whichever mechanism best > suits. Ok? Not sure this suits. We actually do byte-level padding with this. The init-0 ignore on receive is for bit-bound fields, not byte-bound. We can't use padding when the field is 17bits for example. I think 2460 says there are two types of padding, pad1 and padn, and we should say use padn with its Opt Data Len set to 5 and the 5 next bytes set to 0. IMHO Alex > > -Rajeev > > > >> Alex >> > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Feb 28 16:15:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMW8a-00042n-GP; Wed, 28 Feb 2007 16:15:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMW8Z-00042M-AS for mip4@ietf.org; Wed, 28 Feb 2007 16:14:59 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMW8X-0004Ut-Q4 for mip4@ietf.org; Wed, 28 Feb 2007 16:14:59 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1SLBlnB004140; Wed, 28 Feb 2007 23:12:03 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 23:14:27 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 15:14:05 -0600 Received: from 10.241.58.50 ([10.241.58.50]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Feb 2007 21:14:05 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Wed, 28 Feb 2007 13:14:17 -0800 From: Rajeev Koodli To: ext Alexandru Petrescu Message-ID: Thread-Topic: padding 48bit MAC addresses in FMIPv4 Thread-Index: AcdbdFz5BSb4obuoRVyuCs0ViGm/kQACQqbW In-Reply-To: <45E5E15E.4040605@motorola.com> Mime-version: 1.0 X-OriginalArrivalTime: 28 Feb 2007 21:14:05.0184 (UTC) FILETIME=[6086E000:01C75B7D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070228231204-0B9B5BB0-26110F19/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: mip4@ietf.org, McCann Peter-A001034 Subject: [Mip4] Re: padding 48bit MAC addresses in FMIPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385394271==" Errors-To: mip4-bounces@ietf.org > 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. --===============1385394271== Content-type: multipart/alternative; boundary="B_3255513257_19588795" > 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. --B_3255513257_19588795 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 2/28/07 12:09 PM, "ext Alexandru Petrescu" wrote: > > I think 2460 says there are two types of padding, pad1 and padn, and we > should say use padn with its Opt Data Len set to 5 and the 5 next bytes > set to 0. > > Allright. We can specify padN must be used. That would take away any > ambiguity. > > -Rajeev > > > > IMHO > > Alex > >> > >> > -Rajeev >> > >> > >> > >>> >> Alex >>> >> >> > >> > > > --B_3255513257_19588795 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: padding 48bit MAC addresses in FMIPv4


On 2/28/07 12:09 PM, "ext Alexandru Petrescu" <alexandru.petre= scu@motorola.com> wrote:


I think 2460 says there are two types of padding, pad1 and padn, and we
should say use padn with its Opt Data Len set to 5 and the 5 next bytes
set to 0.

Allright. We can specify padN must be used. That would take away any ambigu= ity.

-Rajeev



IMHO

Alex

>
> -Rajeev
>
>
>
>> Alex
>>
>
>



 --B_3255513257_19588795-- --===============1385394271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1385394271==--