From jari.arkko@piuha.net Mon Feb 1 01:24:49 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF4628C108 for ; Mon, 1 Feb 2010 01:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZh52QCDpgNF for ; Mon, 1 Feb 2010 01:24:48 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 547E428C0CE for ; Mon, 1 Feb 2010 01:24:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 67E412D289; Mon, 1 Feb 2010 11:25:21 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sabHZzQqdr3e; Mon, 1 Feb 2010 11:25:20 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id DDDEF2D288; Mon, 1 Feb 2010 11:25:20 +0200 (EET) Message-ID: <4B669E00.1070406@piuha.net> Date: Mon, 01 Feb 2010 11:25:20 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <4B559E01.6030704@piuha.net> <853DD750D9C3724FBF2DF7164FCF641C03F9781D@FRVELSMBS14.ad2.ad.alcatel.com> <10171_1263982320_4B56D6F0_10171_25834_1_843DA8228A1BA74CA31FB4E111A5C462993FAA@ftrdmel0.rd.francetelecom.fr> <4B5E11DC.90408@piuha.net> <1264498503.3033.3.camel@acorde.it.uc3m.es> In-Reply-To: <1264498503.3033.3.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, Telemaco.Melia@alcatel-lucent.com Subject: Re: [netext] second revision of the new charter for theworking group X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 09:24:49 -0000 Carlos, > Well, I partially agree with this. Your laptop works OK with that > configuration, but if in addition to the USB stick you add a wifi > connection, then your laptop may not work just fine without assuming > something else. I think this is still fine -- most operating systems can deal with this situation, even if they use a very simple solution (such as employing just one of the many available interfaces). > Besides, if you want to benefit from sending http > traffic through one interface (e.g. wifi) and voip traffic through > another one (e.g. cellular), then you need something else (some > support/configuration at the laptop). If we want to enable flow mobility > in nodes with multiple interfaces in a PMIP domain, we may need to > assume that the mobile node is at least capable of doing some things > Yes, of course. Additional, better functionality needs new code. I think that's generally speaking fine, as long as (a) these additional things do not break connectivity for devices that do not have this new code, as might be the case for a majority of devices and (b) there's sufficient motivation to make the code changes. Jari From jari.arkko@piuha.net Mon Feb 1 01:25:23 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2E1628C15C for ; Mon, 1 Feb 2010 01:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaxOToj8tUqN for ; Mon, 1 Feb 2010 01:25:23 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9812628C0F3 for ; Mon, 1 Feb 2010 01:25:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DB5EE2D288; Mon, 1 Feb 2010 11:25:55 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMlLHyR+-zLy; Mon, 1 Feb 2010 11:25:55 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 4F7AE2CEA2; Mon, 1 Feb 2010 11:25:55 +0200 (EET) Message-ID: <4B669E23.7030604@piuha.net> Date: Mon, 01 Feb 2010 11:25:55 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Zuniga, Juan Carlos" References: <4B5EB08A.1000905@piuha.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] yet another charter version X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 09:25:23 -0000 Juan-Carlos, Thanks for the feedback. > I share views with Rajeev and others and I > believe that the new charter reads much better. Nonetheless, I'd suggest > removing the following sentence: > > " It is assumed that that an IP layer interface can simultaneously > attach to multiple MAGs (possibly over multiple media). " > > I had previously made a point that an MN may need to move from one MAG > to another and if the MN can only operate one radio technology at a time > (single-radio handover) then the multiple-MAG attachment does not apply. > I don't think we need to make this strong assumption. > > By removing that sentence we allow both singe-radio and simultaneous > attachment solutions to be documented. > Ok. I think your scenario is a valid one. Let me think about what this means for the charter text. And now that I read more e-mails I can see that in your later discussion you converged on this: > It is assumed that that an IP layer interface can simultaneously > and/or sequentially attach to multiple MAGs (possibly over multiple > media). Which is fine. Jari From jari.arkko@piuha.net Mon Feb 1 01:34:23 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765A728C0F7 for ; Mon, 1 Feb 2010 01:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEgFsReR6nrI for ; Mon, 1 Feb 2010 01:34:19 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 063DF28C122 for ; Mon, 1 Feb 2010 01:33:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B307B2D288; Mon, 1 Feb 2010 11:33:15 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl9lo9R9XAeU; Mon, 1 Feb 2010 11:33:15 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 561962CEA2; Mon, 1 Feb 2010 11:33:15 +0200 (EET) Message-ID: <4B669FDA.8030809@piuha.net> Date: Mon, 01 Feb 2010 11:33:14 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4B5E1DE8.4050008@piuha.net> <4D35478224365146822AE9E3AD4A26660F6599DD@exchtewks3.starentnetworks.com> <4B5EA5C2.40008@piuha.net> <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A26660F65A6EC@exchtewks3.starentnetworks.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netext@ietf.org Subject: Re: [netext] charter revision X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 09:34:23 -0000 Rajeev,

But maybe the answer is already obvious, and I'm just not 
seeing it. Can you list what extensions are necessary to 
support this functionality? Is there one or multiple?
    

Flow Mobility:

- protocol between LMA and (target) MAG to support forwarding of one or
more flows 
  - Request/Respone messaging
- the protocol will carry one or more MH options, including such flow
tuple parameters as HNP, IPv4 address, QoS parameters, etc.

Inter-access handover:

- MAG - MAG protocol: perhaps we can re-use PFMIP6 with appropriate MH
options
- Target MAG - AAA protocol: this is feasible when an auth protocol is
assumed to be in place upon inter-access handovers within the same PMIP6
domain; I am not sure extensions are necessary.

As you can see, this does not have to be complicated.

Yes, this is good.

But I'm not sure what the final list of documents will be -- you said "perhaps re-use" above, I don't know if the flow description format will be a separate document or re-use something existing, are we talking about one or two AAA protocols, etc.

I would suggest that we keep the milestone so that these details can be worked out. You are already well on your way to get this done. The purpose of the milestone is not to set up a hoop that you have to jump through or prevent you from doing the work. However, once you know what specific components will be developed, we can mark the milestone done, and edit the remaining milestones.

Jari

From jari.arkko@piuha.net Mon Feb 1 01:34:31 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891A628C129; Mon, 1 Feb 2010 01:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOM1Zf9v6XJv; Mon, 1 Feb 2010 01:34:30 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E891C28C150; Mon, 1 Feb 2010 01:34:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3E6E42D288; Mon, 1 Feb 2010 11:34:42 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pNkUDbayJcA; Mon, 1 Feb 2010 11:34:41 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 85D6F2CEA2; Mon, 1 Feb 2010 11:34:41 +0200 (EET) Message-ID: <4B66A031.1020107@piuha.net> Date: Mon, 01 Feb 2010 11:34:41 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "netext@ietf.org" , IESG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 09:34:31 -0000 Hi all, I would like to propose the following charter text as the one to be approved on IESG's meeting on Thursday. The relevant points to make are: 1) There's slightly changed text on the assumption, based on Jual-Carlos' observation that the initial assumption did not cover all situations. I think we need to correct this mistake. And I do agree with Julien that we need to state the assumptions. 2) I would like to keep the milestone that asks the WG to determine what specific deliverables it will produce for the backend protocol extensions. I am happy that we have an initial idea, but I want to see this as an explicit milestone for management purposes. 3) Lets stop fine-tuning the charter text and get to actually doing this stuff. Jari Mobility Extensions (netext) Last Modified: 2010-02-01 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. The working group will produce a problem statement and a specification of the localized routing mechanism. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine what protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for an interface (at the IP layer) to transmit packets over different media, the ability to distribute specific traffic flows on different media components of that interface, and making this work with the handover hints in the base protocol. The relevant protocol extensions will be developed as necessary. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Goals and Milestones: Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Mar 2010 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Mar 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 May 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC May 2010 Initial WG draft on Localized Routing Solution Jul 2010 Initial WG document on Applicability Statement on Logical Interface over Multiple Physical Interfaces Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed to support logical lnterface over multiple physical interfaces Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Logical Interface over Multiple Physical Interfaces Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Logical Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC From julienl@qualcomm.com Mon Feb 1 06:51:47 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36BE3A6952; Mon, 1 Feb 2010 06:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.676 X-Spam-Level: X-Spam-Status: No, score=-106.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYaQWG8+k37o; Mon, 1 Feb 2010 06:51:46 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id ECF0D28C127; Mon, 1 Feb 2010 06:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1265035941; x=1296571941; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Jari=20Arkko=20,=20"netext@i etf.org"=20,=0D=0A=20=20=20=20=20=20=20 =20IESG=20|Date:=20Mon,=201=20Feb=202010 =2006:52:11=20-0800|Subject:=20RE:=20[netext]=20final=20c harter=20text|Thread-Topic:=20[netext]=20final=20charter =20text|Thread-Index:=20AcqjTTh+kP38mEroROOfFPTaMGfv6QAAL 7tg|Message-ID:=20|References:=20<4B66A031 .1020107@piuha.net>|In-Reply-To:=20<4B66A031.1020107@piuh a.net>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=17F4ivpHrHOHtC/LQDCeSAPvoaWsMdAyzQwkG8TLf5I=; b=T57jRtFzFmAcohgFHZE/52sSFxLr66l0j+9g/blWr/Ft48VLd0u5T8S1 ExZmFXaFKnyzc8bpEUljZiwvxPWebD/e+IJHA9mNM94shRADIfIhjkGrN /SzyR+oQJytwLc89RzfYyd0YN//h52m1yiuvIRpVe9fnjT72dPXYGOEr+ o=; X-IronPort-AV: E=McAfee;i="5400,1158,5878"; a="33219360" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 01 Feb 2010 06:52:16 -0800 Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o11EqG5n003990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Feb 2010 06:52:16 -0800 X-IronPort-AV: E=Sophos;i="4.49,383,1262592000"; d="scan'208";a="37210746" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 01 Feb 2010 06:52:16 -0800 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 1 Feb 2010 06:52:15 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Mon, 1 Feb 2010 06:52:14 -0800 From: "Laganier, Julien" To: Jari Arkko , "netext@ietf.org" , IESG Date: Mon, 1 Feb 2010 06:52:11 -0800 Thread-Topic: [netext] final charter text Thread-Index: AcqjTTh+kP38mEroROOfFPTaMGfv6QAAL7tg Message-ID: References: <4B66A031.1020107@piuha.net> In-Reply-To: <4B66A031.1020107@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 14:51:47 -0000 Hi Jari, The following charter text is fine with me. Thanks. --julien > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Jari Arkko > Sent: Monday, February 01, 2010 1:35 AM > To: netext@ietf.org; IESG > Subject: [netext] final charter text >=20 > Hi all, >=20 > I would like to propose the following charter text as the one to be > approved on IESG's meeting on Thursday. The relevant points to make > are: >=20 > 1) There's slightly changed text on the assumption, based on > Jual-Carlos' observation that the initial assumption did not cover all > situations. I think we need to correct this mistake. And I do agree > with Julien that we need to state the assumptions. >=20 > 2) I would like to keep the milestone that asks the WG to determine > what specific deliverables it will produce for the backend protocol > extensions. I am happy that we have an initial idea, but I want to see > this as an explicit milestone for management purposes. >=20 > 3) Lets stop fine-tuning the charter text and get to actually doing > this stuff. >=20 > Jari >=20 > Mobility Extensions (netext) >=20 > Last Modified: 2010-02-01 >=20 > Additional information is available at tools.ietf.org/wg/netext >=20 > Chair(s): >=20 > * Rajeev Koodli > * Basavaraj Patil >=20 > Internet Area Director(s): >=20 > * Ralph Droms > * Jari Arkko >=20 > Internet Area Advisor: >=20 > * Jari Arkko >=20 > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail- > archive/web/netext/current/maillist.html >=20 > Description of Working Group: >=20 > Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility > protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility > Anchor (LMA) to allow hosts to move around within a domain while > keeping > their address or address prefix stable. Proxy Mobile IPv6 has been > incorporated into a number of products and deployments are starting. > Certain deployment considerations, including localized routing and bulk > refresh of lifetime are already emerging. >=20 > The working group will focus on the following topics relevant for > network-based mobility: >=20 > Localized Routing: a specification for routing traffic between the > MAG(s) without involving the LMA. That is, allow the MAGs to route > traffic between hosts from one MAG to another, without being tunneled > all the way to the LMA. This reduces latency and backhaul load. > Applications such as voice can benefit from the reduced latency. > The working group will produce a problem statement and a > specification of the localized routing mechanism. >=20 > Bulk Refresh: a specification of improving the signaling load for > binding lifetime refresh. The current specifications call for the > handling of each mobility session independent of each other. When a > large number of hosts are served by a single MAG, a periodic refresh of > the binding lifetimes can lead to a signaling storm. The purpose of the > Bulk Refresh feature is to construct a protocol feature that allows > such > refreshes to occur on a per-MAG basis. >=20 > LMA Redirection: a specification for allowing an LMA to redirect a MAG > to another LMA. This is primarily needed as a way to perform load > balancing. This functionality is complementary to implementation > techniques that allow distributed MAG implementations to move tasks > around without a visible impact at the protocol level, and the > initial LMA discovery work in the NETLMM WG. An applicability statement > describing the situations where the new functionality is or is not > applicable has to be included in the specification. >=20 > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > "logical interface" at the IP layer may enable packet transmission and > reception over different physical media. Such techniques can be used > to achieve inter-access handovers or flow mobility, i.e., the movement > of selected flows from one access technology to another. It is > assumed that that an IP layer interface can simultaneously and/or > sequentially attach to multiple MAGs (possibly over multiple media). > The hiding mechanisms also need to work together with existing RFC > 5213 handover hint mechanisms. The specification of any actual link > layer mechanisms is outside the scope of the working group, but the > group works on the following: >=20 > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. >=20 > - The working group will determine what protocol extensions are > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) > to support the ability for an interface (at the IP layer) to > transmit packets over different media, the ability to distribute > specific traffic flows on different media components of that > interface, and making this work with the handover hints in the base > protocol. The relevant protocol extensions will be developed as > necessary. >=20 > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. >=20 > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to > signal > mobility related events between the host and the network. >=20 > The proposed activity will be complementary to the existing IETF > Working > Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will > also act as the primary forum where new extensions on top of the Proxy > Mobile IPv6 protocol can be developed. The addition of such new > extensions to the working group involves addition of the extension to > this charter through the normal rechartering process. >=20 > Goals and Milestones: >=20 > Done WG chartered > Done Initial WG draft on Bulk Refresh > Done Decision on the inclusion of possible additional work > items > Done Initial WG draft on LMA Redirection > Done Initial WG draft on Localized Routing Problem Statement > Mar 2010 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Mar 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > May 2010 Submit Localized Routing Problem Statement to IESG > for > publication as an Informational RFC > May 2010 Initial WG draft on Localized Routing Solution > Jul 2010 Initial WG document on Applicability Statement on > Logical Interface over Multiple Physical Interfaces > Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support logical lnterface over multiple physical interfaces > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Logical Interface over Multiple Physical Interfaces > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Logical Interface > over > Multiple Physical Interfaces to IESG for publication as Informational > RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Logical > Interface over Multiple Physical Interfaces for publication as Proposed > Standard RFC(s) > Feb 2011 Submit Localized Routing Solution to IESG for > publication as a Proposed Standard RFC >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From JuanCarlos.Zuniga@InterDigital.com Mon Feb 1 07:40:23 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2974C3A6826; Mon, 1 Feb 2010 07:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28AtPi2acmXY; Mon, 1 Feb 2010 07:40:21 -0800 (PST) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by core3.amsl.com (Postfix) with ESMTP id 8B8C328C131; Mon, 1 Feb 2010 07:40:21 -0800 (PST) Received: from interdigital.com ([10.0.128.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 10:40:55 -0500 Received: from SAM.InterDigital.com ([10.30.2.11]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 10:40:49 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Feb 2010 10:42:01 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] final charter text Thread-Index: AcqjTTh+kP38mEroROOfFPTaMGfv6QAAL7tgAAHDQ5A= References: <4B66A031.1020107@piuha.net> From: "Zuniga, Juan Carlos" To: "Laganier, Julien" , "Jari Arkko" , , "IESG" X-OriginalArrivalTime: 01 Feb 2010 15:40:49.0627 (UTC) FILETIME=[EDD5C2B0:01CAA354] Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 15:40:23 -0000 Hi Jari, The text is also fine with me too. Thanks, Juan-Carlos > -----Original Message----- > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > Behalf Of Laganier, Julien > Sent: Monday, 01 February, 2010 9:52 AM > To: Jari Arkko; netext@ietf.org; IESG > Subject: Re: [netext] final charter text >=20 > Hi Jari, >=20 > The following charter text is fine with me. >=20 > Thanks. >=20 > --julien >=20 > > -----Original Message----- > > From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On > > Behalf Of Jari Arkko > > Sent: Monday, February 01, 2010 1:35 AM > > To: netext@ietf.org; IESG > > Subject: [netext] final charter text > > > > Hi all, > > > > I would like to propose the following charter text as the one to be > > approved on IESG's meeting on Thursday. The relevant points to make > > are: > > > > 1) There's slightly changed text on the assumption, based on > > Jual-Carlos' observation that the initial assumption did not cover > all > > situations. I think we need to correct this mistake. And I do agree > > with Julien that we need to state the assumptions. > > > > 2) I would like to keep the milestone that asks the WG to determine > > what specific deliverables it will produce for the backend protocol > > extensions. I am happy that we have an initial idea, but I want to > see > > this as an explicit milestone for management purposes. > > > > 3) Lets stop fine-tuning the charter text and get to actually doing > > this stuff. > > > > Jari > > > > Mobility Extensions (netext) > > > > Last Modified: 2010-02-01 > > > > Additional information is available at tools.ietf.org/wg/netext > > > > Chair(s): > > > > * Rajeev Koodli > > * Basavaraj Patil > > > > Internet Area Director(s): > > > > * Ralph Droms > > * Jari Arkko > > > > Internet Area Advisor: > > > > * Jari Arkko > > > > Mailing Lists: > > General Discussion: netext@ietf.org > > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > > Archive: http://www.ietf.org/mail- > > archive/web/netext/current/maillist.html > > > > Description of Working Group: > > > > Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility > > protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility > > Anchor (LMA) to allow hosts to move around within a domain while > > keeping > > their address or address prefix stable. Proxy Mobile IPv6 has been > > incorporated into a number of products and deployments are starting. > > Certain deployment considerations, including localized routing and > bulk > > refresh of lifetime are already emerging. > > > > The working group will focus on the following topics relevant for > > network-based mobility: > > > > Localized Routing: a specification for routing traffic between the > > MAG(s) without involving the LMA. That is, allow the MAGs to route > > traffic between hosts from one MAG to another, without being tunneled > > all the way to the LMA. This reduces latency and backhaul load. > > Applications such as voice can benefit from the reduced latency. > > The working group will produce a problem statement and a > > specification of the localized routing mechanism. > > > > Bulk Refresh: a specification of improving the signaling load for > > binding lifetime refresh. The current specifications call for the > > handling of each mobility session independent of each other. When a > > large number of hosts are served by a single MAG, a periodic refresh > of > > the binding lifetimes can lead to a signaling storm. The purpose of > the > > Bulk Refresh feature is to construct a protocol feature that allows > > such > > refreshes to occur on a per-MAG basis. > > > > LMA Redirection: a specification for allowing an LMA to redirect a > MAG > > to another LMA. This is primarily needed as a way to perform load > > balancing. This functionality is complementary to implementation > > techniques that allow distributed MAG implementations to move tasks > > around without a visible impact at the protocol level, and the > > initial LMA discovery work in the NETLMM WG. An applicability > statement > > describing the situations where the new functionality is or is not > > applicable has to be included in the specification. > > > > Hiding access technology changes from host IP layer: Proxy mobility > is > > based on the assumption that changes in host IP stacks are > > undesirable. However, link layer implementations can hide the > > actually used physical interfaces from the IP stack. For instance, a > > "logical interface" at the IP layer may enable packet transmission > and > > reception over different physical media. Such techniques can be used > > to achieve inter-access handovers or flow mobility, i.e., the > movement > > of selected flows from one access technology to another. It is > > assumed that that an IP layer interface can simultaneously and/or > > sequentially attach to multiple MAGs (possibly over multiple media). > > The hiding mechanisms also need to work together with existing RFC > > 5213 handover hint mechanisms. The specification of any actual link > > layer mechanisms is outside the scope of the working group, but the > > group works on the following: > > > > - Informational applicability statement that analyzes the issues > > involved with this approach and characterizes the contexts in which > > such use is or is not appropriate. > > > > - The working group will determine what protocol extensions are > > required between the Proxy Mobile IPv6 network nodes (MAGs and > LMAs) > > to support the ability for an interface (at the IP layer) to > > transmit packets over different media, the ability to distribute > > specific traffic flows on different media components of that > > interface, and making this work with the handover hints in the base > > protocol. The relevant protocol extensions will be developed as > > necessary. > > > > Radius Extensions to PMIP6: In order to enable network based > > mobility using PMIP6, the policy profile needs to signal a set of > > attributes and policies to the MAG and LMA. New Radius attributes > > need to be specified that are relevant to PMIP6 based > > mobility. This work item will specify Radius extensions and > > attributes specific to PMIP6. > > > > The work in this charter is entirely internal to the network and does > > not affect host IP stack operation in any way (except perhaps through > > impacting packet forwarding capacity visible to the hosts). The > working > > group is not allowed to specify new IP layer protocol mechanisms to > > signal > > mobility related events between the host and the network. > > > > The proposed activity will be complementary to the existing IETF > > Working > > Groups, notably the NETLMM and MEXT WGs. The NETEXT working group > will > > also act as the primary forum where new extensions on top of the > Proxy > > Mobile IPv6 protocol can be developed. The addition of such new > > extensions to the working group involves addition of the extension to > > this charter through the normal rechartering process. > > > > Goals and Milestones: > > > > Done WG chartered > > Done Initial WG draft on Bulk Refresh > > Done Decision on the inclusion of possible additional work > > items > > Done Initial WG draft on LMA Redirection > > Done Initial WG draft on Localized Routing Problem Statement > > Mar 2010 Submit Bulk Refresh to IESG for publication as a > > Proposed Standard RFC > > Mar 2010 Submit LMA Redirection to IESG for publication as a > > Proposed Standard RFC > > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > > May 2010 Submit Localized Routing Problem Statement to IESG > > for > > publication as an Informational RFC > > May 2010 Initial WG draft on Localized Routing Solution > > Jul 2010 Initial WG document on Applicability Statement on > > Logical Interface over Multiple Physical Interfaces > > Jul 2010 WG decision on what Proxy Mobile IPv6 support is > needed > > to support logical lnterface over multiple physical interfaces > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 > Extensions > > to Support Logical Interface over Multiple Physical Interfaces > > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > > publication as a Proposed Standard > > Dec 2010 Submit Applicability Statement on Logical Interface > > over > > Multiple Physical Interfaces to IESG for publication as Informational > > RFC > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support > Logical > > Interface over Multiple Physical Interfaces for publication as > Proposed > > Standard RFC(s) > > Feb 2011 Submit Localized Routing Solution to IESG for > > publication as a Proposed Standard RFC > > > > _______________________________________________ > > netext mailing list > > netext@ietf.org > > https://www.ietf.org/mailman/listinfo/netext > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From Basavaraj.Patil@nokia.com Mon Feb 1 09:45:32 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF673A67AB; Mon, 1 Feb 2010 09:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfP+SGei6NNe; Mon, 1 Feb 2010 09:45:31 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 82F973A6767; Mon, 1 Feb 2010 09:45:30 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o11HjibU008429; Mon, 1 Feb 2010 19:46:02 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 19:46:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 19:45:55 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 1 Feb 2010 18:45:55 +0100 From: To: , , Date: Mon, 1 Feb 2010 18:45:51 +0100 Thread-Topic: [netext] final charter text Thread-Index: AcqjIfrYuwiG9BVRSo+3pR1yKvKFKwARGoqX Message-ID: In-Reply-To: <4B66A031.1020107@piuha.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2010 17:45:55.0937 (UTC) FILETIME=[67F1C510:01CAA366] X-Nokia-AV: Clean Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 17:45:32 -0000 Jari, The charter text is fine. Lets move forward with getting IESG approval and start working on the deliverables. -Raj On 2/1/10 3:34 AM, "ext Jari Arkko" wrote: > Hi all, >=20 > I would like to propose the following charter text as the one to be > approved on IESG's meeting on Thursday. The relevant points to make are: >=20 > 1) There's slightly changed text on the assumption, based on > Jual-Carlos' observation that the initial assumption did not cover all > situations. I think we need to correct this mistake. And I do agree with > Julien that we need to state the assumptions. >=20 > 2) I would like to keep the milestone that asks the WG to determine what > specific deliverables it will produce for the backend protocol > extensions. I am happy that we have an initial idea, but I want to see > this as an explicit milestone for management purposes. >=20 > 3) Lets stop fine-tuning the charter text and get to actually doing this > stuff. >=20 > Jari >=20 > Mobility Extensions (netext) >=20 > Last Modified: 2010-02-01 >=20 > Additional information is available at tools.ietf.org/wg/netext >=20 > Chair(s): >=20 > * Rajeev Koodli > * Basavaraj Patil >=20 > Internet Area Director(s): >=20 > * Ralph Droms > * Jari Arkko >=20 > Internet Area Advisor: >=20 > * Jari Arkko >=20 > Mailing Lists: > General Discussion: netext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netext > Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.htm= l >=20 > Description of Working Group: >=20 > Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility > protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility > Anchor (LMA) to allow hosts to move around within a domain while keeping > their address or address prefix stable. Proxy Mobile IPv6 has been > incorporated into a number of products and deployments are starting. > Certain deployment considerations, including localized routing and bulk > refresh of lifetime are already emerging. >=20 > The working group will focus on the following topics relevant for > network-based mobility: >=20 > Localized Routing: a specification for routing traffic between the > MAG(s) without involving the LMA. That is, allow the MAGs to route > traffic between hosts from one MAG to another, without being tunneled > all the way to the LMA. This reduces latency and backhaul load. > Applications such as voice can benefit from the reduced latency. > The working group will produce a problem statement and a > specification of the localized routing mechanism. >=20 > Bulk Refresh: a specification of improving the signaling load for > binding lifetime refresh. The current specifications call for the > handling of each mobility session independent of each other. When a > large number of hosts are served by a single MAG, a periodic refresh of > the binding lifetimes can lead to a signaling storm. The purpose of the > Bulk Refresh feature is to construct a protocol feature that allows such > refreshes to occur on a per-MAG basis. >=20 > LMA Redirection: a specification for allowing an LMA to redirect a MAG > to another LMA. This is primarily needed as a way to perform load > balancing. This functionality is complementary to implementation > techniques that allow distributed MAG implementations to move tasks > around without a visible impact at the protocol level, and the > initial LMA discovery work in the NETLMM WG. An applicability statement > describing the situations where the new functionality is or is not > applicable has to be included in the specification. >=20 > Hiding access technology changes from host IP layer: Proxy mobility is > based on the assumption that changes in host IP stacks are > undesirable. However, link layer implementations can hide the > actually used physical interfaces from the IP stack. For instance, a > "logical interface" at the IP layer may enable packet transmission and > reception over different physical media. Such techniques can be used > to achieve inter-access handovers or flow mobility, i.e., the movement > of selected flows from one access technology to another. It is > assumed that that an IP layer interface can simultaneously and/or > sequentially attach to multiple MAGs (possibly over multiple media). > The hiding mechanisms also need to work together with existing RFC > 5213 handover hint mechanisms. The specification of any actual link > layer mechanisms is outside the scope of the working group, but the > group works on the following: >=20 > - Informational applicability statement that analyzes the issues > involved with this approach and characterizes the contexts in which > such use is or is not appropriate. >=20 > - The working group will determine what protocol extensions are > required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) > to support the ability for an interface (at the IP layer) to > transmit packets over different media, the ability to distribute > specific traffic flows on different media components of that > interface, and making this work with the handover hints in the base > protocol. The relevant protocol extensions will be developed as > necessary. >=20 > Radius Extensions to PMIP6: In order to enable network based > mobility using PMIP6, the policy profile needs to signal a set of > attributes and policies to the MAG and LMA. New Radius attributes > need to be specified that are relevant to PMIP6 based > mobility. This work item will specify Radius extensions and > attributes specific to PMIP6. >=20 > The work in this charter is entirely internal to the network and does > not affect host IP stack operation in any way (except perhaps through > impacting packet forwarding capacity visible to the hosts). The working > group is not allowed to specify new IP layer protocol mechanisms to signa= l > mobility related events between the host and the network. >=20 > The proposed activity will be complementary to the existing IETF Working > Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will > also act as the primary forum where new extensions on top of the Proxy > Mobile IPv6 protocol can be developed. The addition of such new > extensions to the working group involves addition of the extension to > this charter through the normal rechartering process. >=20 > Goals and Milestones: >=20 > Done WG chartered > Done Initial WG draft on Bulk Refresh > Done Decision on the inclusion of possible additional work items > Done Initial WG draft on LMA Redirection > Done Initial WG draft on Localized Routing Problem Statement > Mar 2010 Submit Bulk Refresh to IESG for publication as a > Proposed Standard RFC > Mar 2010 Submit LMA Redirection to IESG for publication as a > Proposed Standard RFC > Mar 2010 Initial WG document on RADIUS extensions to PMIP6 > May 2010 Submit Localized Routing Problem Statement to IESG for > publication as an Informational RFC > May 2010 Initial WG draft on Localized Routing Solution > Jul 2010 Initial WG document on Applicability Statement on > Logical Interface over Multiple Physical Interfaces > Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support logical lnterface over multiple physical interfaces > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Logical Interface over Multiple Physical Interfaces > Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for > publication as a Proposed Standard > Dec 2010 Submit Applicability Statement on Logical Interface over > Multiple Physical Interfaces to IESG for publication as Informational RFC > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Logical > Interface over Multiple Physical Interfaces for publication as Proposed > Standard RFC(s) > Feb 2011 Submit Localized Routing Solution to IESG for > publication as a Proposed Standard RFC >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From rkoodli@cisco.com Mon Feb 1 10:12:43 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3173A659B; Mon, 1 Feb 2010 10:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uc85AdT1EG1; Mon, 1 Feb 2010 10:12:39 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 800AC3A686A; Mon, 1 Feb 2010 10:12:37 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABSoZkutJV2d/2dsb2JhbACBM8JmlwiERQQ X-IronPort-AV: E=Sophos;i="4.49,384,1262563200"; d="scan'208";a="210305283" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-3.cisco.com with ESMTP; 01 Feb 2010 18:13:12 +0000 Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o11IDBjJ013977; Mon, 1 Feb 2010 18:13:11 GMT Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Feb 2010 13:12:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Feb 2010 13:12:28 -0500 Message-ID: <4D35478224365146822AE9E3AD4A266609382C1E@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] final charter text Thread-Index: AcqjIcr7a0MelHyYSiyzkhnXVsJiVQARuzwS References: <4B66A031.1020107@piuha.net> From: "Koodli, Rajeev" To: "Jari Arkko" , , "IESG" X-OriginalArrivalTime: 01 Feb 2010 18:12:29.0515 (UTC) FILETIME=[1DCA79B0:01CAA36A] Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 18:12:43 -0000 =20 Hi Jari, =20 sorry, I would like to make sure, given the cycles spent on this, we are = on the same page here.. ________________________________ From: netext-bounces@ietf.org on behalf of Jari Arkko Sent: Mon 2/1/2010 1:34 AM To: netext@ietf.org; IESG Subject: [netext] final charter text [snip]. Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed to support logical lnterface over multiple physical interfaces =20 Rajeev:> This means supporting Flow Mobility and Inter-access handovers = (on a logical interface over multiple physical interfaces) right? I would like this to be explicit, such as: NEW: Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed to support flow mobility and inter-accss handovers on a logical = lnterface over multiple physical interfaces Similarly, OLD:=20 Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Logical Interface over Multiple Physical Interfaces NEW: Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flow mobility and Inter-accss handovers on a Logical = Interface over Multiple Physical Interfaces OLD: Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Logical Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) NEW: Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Flow = Mobility and Inter-acces handovers on a Logical Interface over Multiple Physical Interfaces for publication as Proposed = Standard RFC(s) _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext From behcetsarikaya@yahoo.com Mon Feb 1 11:44:04 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966003A697C for ; Mon, 1 Feb 2010 11:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MIucSip3ivw for ; Mon, 1 Feb 2010 11:44:03 -0800 (PST) Received: from web111403.mail.gq1.yahoo.com (web111403.mail.gq1.yahoo.com [67.195.15.144]) by core3.amsl.com (Postfix) with SMTP id 9BFAA3A6A4D for ; Mon, 1 Feb 2010 11:43:33 -0800 (PST) Received: (qmail 19469 invoked by uid 60001); 1 Feb 2010 19:44:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265053446; bh=gTmbg6qmLZSEPCGnYS/KUPXPsyCrtHGGLGd/ewHwEhY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=g7MbpzsN/RC0nULFZHFPcoTjpM0/+dYPlzypZZB8RRXNnsvG8mDdE1toLAvLUanC8B1zwz7hCbXzx1rt9iCFD09EM9jQ3awNtKZwLNZnUkEdHyb6pvgYIo0cK6cuIJS+sfrfxPq+2DjgjniF4Ka0/aw5+qSJgss9kkAHEgHieT8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KqWM33E86wM/0L8Rb24jXc/c3QXbwSvCf5Ij8UVwRMDb08HrAX5NfD6BAOQQlTYX4/5OLPTBGjSC2qabFl2MfzhCq5OJjUhs7LZvL28oc1EO2nAd3R1LydVfZ01DXKXK1Cq6CKvNT3hFF8lMoodnjJU7teD4KpadAPsc9sMz3jI=; Message-ID: <101594.19203.qm@web111403.mail.gq1.yahoo.com> X-YMail-OSG: UIlXdTcVM1nm20s4ySK2RrRrW98OPyxBw.WhqCXXj8pEGW.bzxmDjNZ4MWEN5rS2q8S39uQEcVlzDfhOAQCkM6IjLi6k.IYKhgOUuSDQkp__AUOGb0aqFpCU4Tm.erkalQ5K_DfY2ZQ5wW_RapiPHN_spDQeWuH4vDjWdruwGs67v2sJpZUY15T0LB2vIkyFlSZXpH4.t18HQAOCACq2MS1WAQbq.3J1fHE6cpz4vZr7YC6PXBoJjRrbIY5HbP44X76PF3E23rhZjgCmKbwbmi8K9BA.lDUt4x4RwN5Blkpbem83uYGGwbUBNNOIWgixRn4S1McZWkvWh.7o5cmNaC12zYWHeA_4PaNAjffh89jMuiLEHi9g Received: from [206.16.17.212] by web111403.mail.gq1.yahoo.com via HTTP; Mon, 01 Feb 2010 11:44:05 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B66A031.1020107@piuha.net> Date: Mon, 1 Feb 2010 11:44:05 -0800 (PST) From: Behcet Sarikaya To: "netext@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 19:44:04 -0000 ----- Original Message ---- > From: "Laganier, Julien" > To: Jari Arkko ; "netext@ietf.org" ; IESG > Sent: Mon, February 1, 2010 8:52:11 AM > Subject: Re: [netext] final charter text > > Hi Jari, > > The following charter text is fine with me. +1 Regards, Behcet From jhjee@etri.re.kr Mon Feb 1 16:27:22 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1409228C0E2; Mon, 1 Feb 2010 16:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.398 X-Spam-Level: X-Spam-Status: No, score=-99.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64lHy5G-Za0Y; Mon, 1 Feb 2010 16:27:21 -0800 (PST) Received: from email1.etri.info (email1.etri.re.kr [129.254.16.131]) by core3.amsl.com (Postfix) with ESMTP id CF5BE28C0D7; Mon, 1 Feb 2010 16:27:20 -0800 (PST) Received: from etriabcb8a0047 ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Feb 2010 09:27:55 +0900 Message-ID: From: "Junghoon Jee" To: "Koodli, Rajeev" , "Jari Arkko" , , "IESG" References: <4B66A031.1020107@piuha.net> <4D35478224365146822AE9E3AD4A266609382C1E@exchtewks3.starentnetworks.com> Date: Tue, 2 Feb 2010 09:27:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 02 Feb 2010 00:27:55.0957 (UTC) FILETIME=[9098BE50:01CAA39E] Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 00:27:22 -0000 SGkgYWxsLA0KDQpJIGFncmVlIHdpdGggUmFqZWV2IHRoYXQgd2UgbmVlZCB0byBleHBsaWNpdGx5 IG1lbnRpb24gYWJvdXQgIkZsb3cgTW9iaWxpdHkgYW5kIEludGVyLWFjY2VzcyBIYW5kb3ZlcnMi IGluIHRoZSBkZWxpdmVyYWJsZSBpdGVtcy4NCg0KQWxzbyBtaW5vciBlZGl0cyBhcmUgZm91bmQg ZnJvbSB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0cy4NCg0KPiBNb2JpbGl0eSBFeHRlbnNpb25z IChuZXRleHQpDQoNCkkgdGhpbmsgYWJvdmUgbWVhbnQgdG8gYmUgIk5ldHdvcmstQmFzZWQgTW9i aWxpdHkgRXh0ZW5zaW9ucyAobmV0ZXh0KSIuDQoNCj4gSGlkaW5nIGFjY2VzcyB0ZWNobm9sb2d5 IGNoYW5nZXMgZnJvbSBob3N0IElQIGxheWVyOiBQcm94eSBtb2JpbGl0eSBpcw0KPiBiYXNlZCBv biB0aGUgYXNzdW1wdGlvbiB0aGF0IGNoYW5nZXMgaW4gaG9zdCBJUCBzdGFja3MgYXJlDQo+IHVu ZGVzaXJhYmxlLiAgSG93ZXZlciwgbGluayBsYXllciBpbXBsZW1lbnRhdGlvbnMgY2FuIGhpZGUg dGhlDQo+IGFjdHVhbGx5IHVzZWQgcGh5c2ljYWwgaW50ZXJmYWNlcyBmcm9tIHRoZSBJUCBzdGFj ay4gRm9yIGluc3RhbmNlLCBhDQo+ICJsb2dpY2FsIGludGVyZmFjZSIgYXQgdGhlIElQIGxheWVy IG1heSBlbmFibGUgcGFja2V0IHRyYW5zbWlzc2lvbiBhbmQNCj4gcmVjZXB0aW9uIG92ZXIgZGlm ZmVyZW50IHBoeXNpY2FsIG1lZGlhLiAgU3VjaCB0ZWNobmlxdWVzIGNhbiBiZSB1c2VkDQo+IHRv IGFjaGlldmUgaW50ZXItYWNjZXNzIGhhbmRvdmVycyBvciBmbG93IG1vYmlsaXR5LCBpLmUuLCB0 aGUgbW92ZW1lbnQNCj4gb2Ygc2VsZWN0ZWQgZmxvd3MgZnJvbSBvbmUgYWNjZXNzIHRlY2hub2xv Z3kgdG8gYW5vdGhlci4gIA0KDQo+IEl0IGlzIGFzc3VtZWQgdGhhdCB0aGF0IGFuIElQIGxheWVy IGludGVyZmFjZSBjYW4gc2ltdWx0YW5lb3VzbHkgYW5kL29yDQo+IHNlcXVlbnRpYWxseSBhdHRh Y2ggdG8gbXVsdGlwbGUgTUFHcyAocG9zc2libHkgb3ZlciBtdWx0aXBsZSBtZWRpYSkuDQoNCkRv dWJsZSAndGhhdCcgc28gdGhlIHNlbnRlbmNlIHNob3VsZCBiZSB0aGUgZm9sbG93aW5nLiANCiJJ dCBpcyBhc3N1bWVkIHRoYXQgYW4gSVAgbGF5ZXIgaW50ZXJmYWNlIGNhbiBzaW11bHRhbmVvdXNs eSBhbmQvb3INCnNlcXVlbnRpYWxseSBhdHRhY2ggdG8gbXVsdGlwbGUgTUFHcyAocG9zc2libHkg b3ZlciBtdWx0aXBsZSBtZWRpYSkuIg0KDQotIEp1bmdob29uDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQpGcm9tOiAiS29vZGxpLCBSYWplZXYiIDxya29vZGxpQGNpc2NvLmNvbT4N ClRvOiAiSmFyaSBBcmtrbyIgPGphcmkuYXJra29AcGl1aGEubmV0PjsgPG5ldGV4dEBpZXRmLm9y Zz47ICJJRVNHIiA8aWVzZ0BpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDAyLCAy MDEwIDM6MTIgQU0NClN1YmplY3Q6IFJlOiBbbmV0ZXh0XSBmaW5hbCBjaGFydGVyIHRleHQNCg0K DQo+IA0KPiANCj4gSGkgSmFyaSwNCj4gDQo+IHNvcnJ5LCBJIHdvdWxkIGxpa2UgdG8gbWFrZSBz dXJlLCBnaXZlbiB0aGUgY3ljbGVzIHNwZW50IG9uIHRoaXMsIHdlIGFyZSBvbiB0aGUgc2FtZSBw YWdlIGhlcmUuLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+ IEZyb206IG5ldGV4dC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBKYXJpIEFya2tvDQo+ IFNlbnQ6IE1vbiAyLzEvMjAxMCAxOjM0IEFNDQo+IFRvOiBuZXRleHRAaWV0Zi5vcmc7IElFU0cN Cj4gU3ViamVjdDogW25ldGV4dF0gZmluYWwgY2hhcnRlciB0ZXh0DQo+IA0KPiBbc25pcF0uDQo+ IA0KPiBKdWwgMjAxMCAgICAgICAgV0cgZGVjaXNpb24gb24gd2hhdCBQcm94eSBNb2JpbGUgSVB2 NiBzdXBwb3J0IGlzIG5lZWRlZA0KPiB0byBzdXBwb3J0IGxvZ2ljYWwgbG50ZXJmYWNlIG92ZXIg bXVsdGlwbGUgcGh5c2ljYWwgaW50ZXJmYWNlcw0KPiANCj4gDQo+IFJhamVldjo+IFRoaXMgbWVh bnMgc3VwcG9ydGluZyBGbG93IE1vYmlsaXR5IGFuZCBJbnRlci1hY2Nlc3MgaGFuZG92ZXJzIChv biBhIGxvZ2ljYWwgaW50ZXJmYWNlIG92ZXIgbXVsdGlwbGUgcGh5c2ljYWwgaW50ZXJmYWNlcykg cmlnaHQ/DQo+IA0KPiBJIHdvdWxkIGxpa2UgdGhpcyB0byBiZSBleHBsaWNpdCwgc3VjaCBhczoN Cj4gDQo+IE5FVzoNCj4gDQo+IEp1bCAyMDEwICAgICAgICBXRyBkZWNpc2lvbiBvbiB3aGF0IFBy b3h5IE1vYmlsZSBJUHY2IHN1cHBvcnQgaXMgbmVlZGVkDQo+IHRvIHN1cHBvcnQgZmxvdyBtb2Jp bGl0eSBhbmQgaW50ZXItYWNjc3MgaGFuZG92ZXJzIG9uIGEgbG9naWNhbCBsbnRlcmZhY2Ugb3Zl ciBtdWx0aXBsZSBwaHlzaWNhbCBpbnRlcmZhY2VzDQo+IA0KPiANCj4gU2ltaWxhcmx5LA0KPiAN Cj4gT0xEOiANCj4gDQo+IE9jdCAyMDEwICAgICAgICBJbml0aWFsIFdHIGRvY3VtZW50KHMpIG9u IFByb3h5IE1vYmlsZSBJUHY2IEV4dGVuc2lvbnMNCj4gdG8gU3VwcG9ydCBMb2dpY2FsIEludGVy ZmFjZSBvdmVyIE11bHRpcGxlIFBoeXNpY2FsIEludGVyZmFjZXMNCj4gDQo+IA0KPiBORVc6DQo+ IA0KPiBPY3QgMjAxMCAgICAgICAgSW5pdGlhbCBXRyBkb2N1bWVudChzKSBvbiBQcm94eSBNb2Jp bGUgSVB2NiBFeHRlbnNpb25zDQo+IHRvIFN1cHBvcnQgRmxvdyBtb2JpbGl0eSBhbmQgSW50ZXIt YWNjc3MgaGFuZG92ZXJzIG9uIGEgTG9naWNhbCBJbnRlcmZhY2Ugb3ZlciBNdWx0aXBsZSBQaHlz aWNhbCBJbnRlcmZhY2VzDQo+IA0KPiANCj4gT0xEOg0KPiANCj4gDQo+IEZlYiAyMDExICAgICAg ICBTdWJtaXQgUHJveHkgTW9iaWxlIElQdjYgRXh0ZW5zaW9ucyB0byBTdXBwb3J0IExvZ2ljYWwN Cj4gSW50ZXJmYWNlIG92ZXIgTXVsdGlwbGUgUGh5c2ljYWwgSW50ZXJmYWNlcyBmb3IgcHVibGlj YXRpb24gYXMgUHJvcG9zZWQNCj4gU3RhbmRhcmQgUkZDKHMpDQo+IA0KPiANCj4gTkVXOg0KPiAN Cj4gRmViIDIwMTEgICAgICAgIFN1Ym1pdCBQcm94eSBNb2JpbGUgSVB2NiBFeHRlbnNpb25zIHRv IFN1cHBvcnQgRmxvdyBNb2JpbGl0eSBhbmQgSW50ZXItYWNjZXMgaGFuZG92ZXJzIG9uIGEgTG9n aWNhbA0KPiBJbnRlcmZhY2Ugb3ZlciBNdWx0aXBsZSBQaHlzaWNhbCBJbnRlcmZhY2VzIGZvciBw dWJsaWNhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZCBSRkMocykNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGV4dCBtYWlsaW5nIGxp c3QNCj4gbmV0ZXh0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0ZXh0DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbmV0ZXh0IG1haWxpbmcgbGlzdA0KPiBuZXRleHRAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRleHQ= From jari.arkko@piuha.net Wed Feb 3 06:38:36 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29B63A69F9; Wed, 3 Feb 2010 06:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPx08IQ0o0E5; Wed, 3 Feb 2010 06:38:36 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E294D3A691C; Wed, 3 Feb 2010 06:38:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1AE602D28B; Wed, 3 Feb 2010 16:39:18 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmOURwURKda4; Wed, 3 Feb 2010 16:39:17 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B22192D275; Wed, 3 Feb 2010 16:39:17 +0200 (EET) Message-ID: <4B698A95.1080800@piuha.net> Date: Wed, 03 Feb 2010 16:39:17 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Koodli, Rajeev" References: <4B66A031.1020107@piuha.net> <4D35478224365146822AE9E3AD4A266609382C1E@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266609382C1E@exchtewks3.starentnetworks.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netext@ietf.org, IESG Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 14:38:37 -0000 Rajeev, > > Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support logical lnterface over multiple physical interfaces > > > Rajeev:> This means supporting Flow Mobility and Inter-access handovers (on a logical interface over multiple physical interfaces) right? > > I would like this to be explicit, such as: > > NEW: > > Jul 2010 WG decision on what Proxy Mobile IPv6 support is needed > to support flow mobility and inter-accss handovers on a logical lnterface over multiple physical interfaces > Fine for me. > > Similarly, > > OLD: > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Logical Interface over Multiple Physical Interfaces > > > NEW: > > Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions > to Support Flow mobility and Inter-accss handovers on a Logical Interface over Multiple Physical Interfaces > > > OLD: > > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Logical > Interface over Multiple Physical Interfaces for publication as Proposed > Standard RFC(s) > > > NEW: > > Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-acces handovers on a Logical > Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) > Also fine, though a bit lengthy... Jari From jari.arkko@piuha.net Wed Feb 3 06:38:46 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC143A691C; Wed, 3 Feb 2010 06:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM+TBWmd+rKQ; Wed, 3 Feb 2010 06:38:46 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AEC783A68A7; Wed, 3 Feb 2010 06:38:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D8D532D28C; Wed, 3 Feb 2010 16:39:27 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13CBpWb01p83; Wed, 3 Feb 2010 16:39:27 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8036A2D275; Wed, 3 Feb 2010 16:39:27 +0200 (EET) Message-ID: <4B698A9F.3080403@piuha.net> Date: Wed, 03 Feb 2010 16:39:27 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Junghoon Jee References: <4B66A031.1020107@piuha.net> <4D35478224365146822AE9E3AD4A266609382C1E@exchtewks3.starentnetworks.com> In-Reply-To: Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: IESG , netext@ietf.org Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 14:38:46 -0000 Junghoon,

Mobility Extensions (netext)
    

I think above meant to be "Network-Based Mobility Extensions (netext)".

Ha! Good catch.

It is assumed that that an IP layer interface can simultaneously and/or
sequentially attach to multiple MAGs (possibly over multiple media).
    

Double 'that' so the sentence should be the following. 
"It is assumed that an IP layer interface can simultaneously and/or
sequentially attach to multiple MAGs (possibly over multiple media)."

Right. Thanks for the careful review.

Jari


From jari.arkko@piuha.net Wed Feb 3 06:41:33 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7794A3A6A0E; Wed, 3 Feb 2010 06:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llQqQi8XXWDe; Wed, 3 Feb 2010 06:41:32 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EE6843A68A7; Wed, 3 Feb 2010 06:41:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E8BA32D28B; Wed, 3 Feb 2010 16:42:13 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWhn2U3UctpG; Wed, 3 Feb 2010 16:42:12 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id D05872D275; Wed, 3 Feb 2010 16:42:12 +0200 (EET) Message-ID: <4B698B44.5020702@piuha.net> Date: Wed, 03 Feb 2010 16:42:12 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: IESG , "netext@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IAB Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 14:41:33 -0000 IESG Secretary (Bcced), This is the currently final charter text that will be discussed in tomorrow's IESG teleconference (up for approval). ----- Network-Based Mobility Extensions (netext) Last Modified: 2010-02-03 Additional information is available at tools.ietf.org/wg/netext Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. The working group will produce a problem statement and a specification of the localized routing mechanism. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine what protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for an interface (at the IP layer) to transmit packets over different media, the ability to distribute specific traffic flows on different media components of that interface, and making this work with the handover hints in the base protocol. The relevant protocol extensions will be developed as necessary. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Goals and Milestones: Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Mar 2010 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Mar 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 May 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC May 2010 Initial WG draft on Localized Routing Solution Jul 2010 Initial WG document on Applicability Statement on Logical Interface over Multiple Physical Interfaces Jul 2010 WG decision on what Proxy Mobile IPv6 mechanisms are needed to support flow mobility and inter-accss handovers on a logical lnterface over multiple physical interfaces Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-accss Handovers on a Logical Interface over Multiple Physical Interfaces Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-accss Handovers on a Logical Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC From behcetsarikaya@yahoo.com Wed Feb 3 09:06:00 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFEA63A6B2D for ; Wed, 3 Feb 2010 09:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnWJofQTbFvk for ; Wed, 3 Feb 2010 09:05:59 -0800 (PST) Received: from web111411.mail.gq1.yahoo.com (web111411.mail.gq1.yahoo.com [67.195.15.192]) by core3.amsl.com (Postfix) with SMTP id 8B67A3A69E2 for ; Wed, 3 Feb 2010 09:05:59 -0800 (PST) Received: (qmail 7999 invoked by uid 60001); 3 Feb 2010 17:06:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1265216800; bh=3kBROBYHVZimY1C+3sLjOGNUSp9bqfaTwJV00m7jD5A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6bQXWuV43PbR8z3H5t2pD33Vubd9WAGwuEUAtC5UkC3mAPPSIoxZZDvPorRad/qd1RIMMXLWJyeHRV6FfWcQe4LQjvrLJwZLdXnYOZUMVKcg8orHBnYLkAzEM88QY32d/vPut/2uj0vRHDOnb8w1EMnNiHc+0mNBma20hhHG2sU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GgnO01c2LVp5TMuPvNSTrf5kSkEl8IIFD9hHl8WwlmpiU6ncx1ykI34lgWhlwT1BH6wW7W1OUhHzI5K2t5ciViUzIrkt5AWbRdOT6GNLhUQLYC6R+DeAS6CxGYjhlOTopSHKFfx4ReHtI0FNpGrKGSNaMZekiNhNRbvs50C+rU8=; Message-ID: <117302.7438.qm@web111411.mail.gq1.yahoo.com> X-YMail-OSG: kay__1QVM1mvZqPf6bx.eo4Nsi75.PAruS1gbBLFTk1PFv2Ix2eZ__9ANnBCHPV1q27fhdd09_5OLMnwrEGv3jRg0gLBU3g57lxytGOv.dCc8dS7qK6RqKVYNdZipxKGrw4cysVHaZCNcCbQXuOEXrp5dXXdkZSSCnBaT9SmLJV1CO9Qp6PjQdJqa0EOzFVxEcc79kwRfGI9nA2pwLg_tjoGi2DMJJwqfZW0TGLCgw3hngKjgY17MGkFfHS8LQplY8jvhItkjGsz.ZkJw7YVm4vV_HlohURY2CLq1GbBP681gGwt2e.x.Z5BWZPxSz86MOvGWigOofYBX4fUIYPvT2RJTwI2DHlLaO29K4vk Received: from [206.16.17.212] by web111411.mail.gq1.yahoo.com via HTTP; Wed, 03 Feb 2010 09:06:39 PST X-Mailer: YahooMailRC/272.7 YahooMailWebService/0.8.100.260964 References: <4B698B44.5020702@piuha.net> Date: Wed, 3 Feb 2010 09:06:39 -0800 (PST) From: Behcet Sarikaya To: Jari Arkko , "netext@ietf.org" In-Reply-To: <4B698B44.5020702@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 17:06:01 -0000 Hi Jari,=0A=A0 Two points:=A0 =0A1. Inter-access is misspelled twice like I= nter-accss in the text.=0A=0A2. Feb 2011=A0 =A0 =A0 =A0 =A0 Submit Localize= d Routing Solution to IESG for publication as a =0A> Proposed Standard RFC= =0Ashould probably be followed by=0A=0ARecharter is there is work or close = down the WG.=0A=0A=0ARegards,=0A=0ABehcet=0A=0A=0A=A0=0A=0A=0A----- Origina= l Message ----=0A> From: Jari Arkko =0A> To: IESG ; "netext@ietf.org" =0A> Cc: IAB = =0A> Sent: Wed, February 3, 2010 8:42:12 AM=0A> Subject: Re: [netext] final= charter text=0A> =0A> IESG Secretary (Bcced),=0A> =0A> This is the current= ly final charter text that will be discussed in tomorrow's =0A> IESG teleco= nference (up for approval).=0A> =0A> -----=0A> =0A> =0A> Network-Based Mobi= lity Extensions (netext)=0A> =0A> Last Modified: 2010-02-03=0A> =0A> Additi= onal information is available at tools.ietf.org/wg/netext=0A> =0A> Chair(s)= :=0A> =0A> =A0 * Rajeev Koodli =0A> =A0 * Basavaraj Patil =0A> =0A> Interne= t Area Director(s):=0A> =0A> =A0 * Ralph Droms =0A> =A0 * Jari Arkko =0A> = =0A> Internet Area Advisor:=0A> =0A> =A0 * Jari Arkko =0A> =0A> Mailing Lis= ts:=0A> General Discussion: netext@ietf.org=0A> To Subscribe: https://www.i= etf.org/mailman/listinfo/netext=0A> Archive: http://www.ietf.org/mail-archi= ve/web/netext/current/maillist.html=0A> =0A> Description of Working Group:= =0A> =0A> Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobi= lity=0A> protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobili= ty=0A> Anchor (LMA) to allow hosts to move around within a domain while kee= ping=0A> their address or address prefix stable. Proxy Mobile IPv6 has been= =0A> incorporated into a number of products and deployments are starting.= =0A> Certain deployment considerations, including localized routing and bul= k=0A> refresh of lifetime are already emerging.=0A> =0A> The working group = will focus on the following topics relevant for=0A> network-based mobility:= =0A> =0A> Localized Routing: a specification for routing traffic between th= e=0A> MAG(s) without involving the LMA. That is, allow the MAGs to route=0A= > traffic between hosts from one MAG to another, without being tunneled=0A>= all the way to the LMA. This reduces latency and backhaul load.=0A> Applic= ations such as voice can benefit from the reduced latency.=0A> The working = group will produce a problem statement and a=0A> specification of the local= ized routing mechanism.=0A> =0A> Bulk Refresh: a specification of improving= the signaling load for=0A> binding lifetime refresh. The current specifica= tions call for the=0A> handling of each mobility session independent of eac= h other. When a=0A> large number of hosts are served by a single MAG, a per= iodic refresh of=0A> the binding lifetimes can lead to a signaling storm. T= he purpose of the=0A> Bulk Refresh feature is to construct a protocol featu= re that allows such=0A> refreshes to occur on a per-MAG basis.=0A> =0A> LMA= Redirection: a specification for allowing an LMA to redirect a MAG=0A> to = another LMA. This is primarily needed as a way to perform load=0A> balancin= g. This functionality is complementary to implementation=0A> techniques tha= t allow distributed MAG implementations to move tasks=0A> around without a = visible impact at the protocol level, and the=0A> initial LMA discovery wor= k in the NETLMM WG. An applicability statement=0A> describing the situation= s where the new functionality is or is not=0A> applicable has to be include= d in the specification.=0A> =0A> Hiding access technology changes from host= IP layer: Proxy mobility is=0A> based on the assumption that changes in ho= st IP stacks are=0A> undesirable.=A0 However, link layer implementations ca= n hide the=0A> actually used physical interfaces from the IP stack. For ins= tance, a=0A> "logical interface" at the IP layer may enable packet transmis= sion and=0A> reception over different physical media.=A0 Such techniques ca= n be used=0A> to achieve inter-access handovers or flow mobility, i.e., the= movement=0A> of selected flows from one access technology to another.=A0 I= t is=0A> assumed that an IP layer interface can simultaneously and/or=0A> s= equentially attach to multiple MAGs (possibly over multiple media).=0A> The= hiding mechanisms also need to work together with existing RFC=0A> 5213 ha= ndover hint mechanisms.=A0 The specification of any actual link=0A> layer m= echanisms is outside the scope of the working group, but the=0A> group work= s on the following:=0A> =0A> - Informational applicability statement that a= nalyzes the issues=0A> involved with this approach and characterizes the co= ntexts in which=0A> such use is or is not appropriate.=0A> =0A> - The worki= ng group will determine what protocol extensions are=0A> required between t= he Proxy Mobile IPv6 network nodes (MAGs and LMAs)=0A> to support the abili= ty for an interface (at the IP layer) to=0A> transmit packets over differen= t media, the ability to distribute=0A> specific traffic flows on different = media components of that=0A> interface, and making this work with the hando= ver hints in the base=0A> protocol. The relevant protocol extensions will b= e developed as=0A> necessary.=0A> =0A> Radius Extensions to PMIP6: In order= to enable network based=0A> mobility using PMIP6, the policy profile needs= to signal a set of=0A> attributes and policies to the MAG and LMA. New Rad= ius attributes=0A> need to be specified that are relevant to PMIP6 based=0A= > mobility. This work item will specify Radius extensions and=0A> attribute= s specific to PMIP6.=0A> =0A> The work in this charter is entirely internal= to the network and does=0A> not affect host IP stack operation in any way = (except perhaps through=0A> impacting packet forwarding capacity visible to= the hosts). The working=0A> group is not allowed to specify new IP layer p= rotocol mechanisms to signal=0A> mobility related events between the host a= nd the network.=0A> =0A> The proposed activity will be complementary to the= existing IETF Working=0A> Groups, notably the NETLMM and MEXT WGs. The NET= EXT working group will=0A> also act as the primary forum where new extensio= ns on top of the Proxy=0A> Mobile IPv6 protocol can be developed. The addit= ion of such new=0A> extensions to the working group involves addition of th= e extension to=0A> this charter through the normal rechartering process.=0A= > =0A> Goals and Milestones:=0A> =0A> Done=A0 =A0 =A0 =A0 =A0 WG chartered= =0A> Done=A0 =A0 =A0 =A0 =A0 Initial WG draft on Bulk Refresh=0A> Done=A0 = =A0 =A0 =A0 =A0 Decision on the inclusion of possible additional work items= =0A> Done=A0 =A0 =A0 =A0 =A0 Initial WG draft on LMA Redirection=0A> Done= =A0 =A0 =A0 =A0 =A0 Initial WG draft on Localized Routing Problem Statement= =0A> Mar 2010=A0 =A0 =A0 =A0 =A0 Submit Bulk Refresh to IESG for publicatio= n as a Proposed =0A> Standard RFC=0A> Mar 2010=A0 =A0 =A0 =A0 =A0 Submit LM= A Redirection to IESG for publication as a Proposed =0A> Standard RFC=0A> M= ar 2010=A0 =A0 =A0 =A0 Initial WG document on RADIUS extensions to PMIP6=0A= > May 2010=A0 =A0 =A0 =A0 =A0 Submit Localized Routing Problem Statement to= IESG for =0A> publication as an Informational RFC=0A> May 2010=A0 =A0 =A0 = =A0 Initial WG draft on Localized Routing Solution=0A> Jul 2010=A0 =A0 =A0 = =A0 Initial WG document on Applicability Statement on Logical =0A> Interfac= e over Multiple Physical Interfaces=0A> Jul 2010=A0 =A0 =A0 =A0 WG decision= on what Proxy Mobile IPv6 mechanisms are needed to =0A> support flow mobil= ity and inter-accss handovers on a logical lnterface over =0A> multiple phy= sical interfaces=0A> Oct 2010=A0 =A0 =A0 =A0 Initial WG document(s) on Prox= y Mobile IPv6 Extensions to =0A> Support Flow Mobility and Inter-accss Hand= overs on a Logical Interface over =0A> Multiple Physical Interfaces=0A> Dec= 2010=A0 =A0 =A0 =A0 Submit RADIUS extensions to PMIP6 to IESG for publicat= ion as a =0A> Proposed Standard=0A> Dec 2010=A0 =A0 =A0 =A0 Submit Applicab= ility Statement on Logical Interface over =0A> Multiple Physical Interfaces= to IESG for publication as Informational RFC=0A> Feb 2011=A0 =A0 =A0 =A0 S= ubmit Proxy Mobile IPv6 Extensions to Support Flow Mobility and =0A> Inter-= accss Handovers on a Logical Interface over Multiple Physical Interfaces = =0A> for publication as Proposed Standard RFC(s)=0A> Feb 2011=A0 =A0 =A0 = =A0 =A0 Submit Localized Routing Solution to IESG for publication as a =0A>= Proposed Standard RFC=0A> =0A> ___________________________________________= ____=0A> netext mailing list=0A> netext@ietf.org=0A> https://www.ietf.org/m= ailman/listinfo/netext=0A=0A=0A=0A From jari.arkko@piuha.net Wed Feb 3 11:53:59 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8595A3A6CED for ; Wed, 3 Feb 2010 11:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrIoWqfCV9MV for ; Wed, 3 Feb 2010 11:53:58 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id B1B813A6CEC for ; Wed, 3 Feb 2010 11:53:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C157E2D28C; Wed, 3 Feb 2010 21:54:41 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMn346si8zwc; Wed, 3 Feb 2010 21:54:41 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 612012D275; Wed, 3 Feb 2010 21:54:41 +0200 (EET) Message-ID: <4B69D481.5060907@piuha.net> Date: Wed, 03 Feb 2010 21:54:41 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Behcet Sarikaya References: <4B698B44.5020702@piuha.net> <117302.7438.qm@web111411.mail.gq1.yahoo.com> In-Reply-To: <117302.7438.qm@web111411.mail.gq1.yahoo.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netext@ietf.org" Subject: Re: [netext] final charter text X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 19:53:59 -0000 Behcet Sarikaya kirjoitti: 
Hi Jari,
  Two points:  
1. Inter-access is misspelled twice like Inter-accss in the text.

Ah. Thanks.

2. Feb 2011          Submit Localized Routing Solution to IESG for publication as a 
  
Proposed Standard RFC
    
should probably be followed by

Recharter is there is work or close down the WG.

We often have these items when we are planning specific new work. But it is not required for "normal" completion of the working group.

Jari

From root@core3.amsl.com Tue Feb 9 11:45:02 2010 Return-Path: X-Original-To: netext@ietf.org Delivered-To: netext@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5F4F33A75EA; Tue, 9 Feb 2010 11:45:02 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100209194502.5F4F33A75EA@core3.amsl.com> Date: Tue, 9 Feb 2010 11:45:02 -0800 (PST) Cc: netext@ietf.org, rkoodli@starentnetworks.com Subject: [netext] WG Action: RECHARTER: Network-Based Mobility Extensions (netext) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 19:45:02 -0000 The Network-Based Mobility Extensions (netext) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Network-Based Mobility Extensions (netext) --------------------------------------------------- Current Status: Active Working Group Chair(s): * Rajeev Koodli * Basavaraj Patil Internet Area Director(s): * Ralph Droms * Jari Arkko Internet Area Advisor: * Jari Arkko Mailing Lists: General Discussion: netext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netext Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html Description of Working Group: Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility Anchor (LMA) to allow hosts to move around within a domain while keeping their address or address prefix stable. Proxy Mobile IPv6 has been incorporated into a number of products and deployments are starting. Certain deployment considerations, including localized routing and bulk refresh of lifetime are already emerging. The working group will focus on the following topics relevant for network-based mobility: Localized Routing: a specification for routing traffic between the MAG(s) without involving the LMA. That is, allow the MAGs to route traffic between hosts from one MAG to another, without being tunneled all the way to the LMA. This reduces latency and backhaul load. Applications such as voice can benefit from the reduced latency. The working group will produce a problem statement and a specification of the localized routing mechanism. Bulk Refresh: a specification of improving the signaling load for binding lifetime refresh. The current specifications call for the handling of each mobility session independent of each other. When a large number of hosts are served by a single MAG, a periodic refresh of the binding lifetimes can lead to a signaling storm. The purpose of the Bulk Refresh feature is to construct a protocol feature that allows such refreshes to occur on a per-MAG basis. LMA Redirection: a specification for allowing an LMA to redirect a MAG to another LMA. This is primarily needed as a way to perform load balancing. This functionality is complementary to implementation techniques that allow distributed MAG implementations to move tasks around without a visible impact at the protocol level, and the initial LMA discovery work in the NETLMM WG. An applicability statement describing the situations where the new functionality is or is not applicable has to be included in the specification. Hiding access technology changes from host IP layer: Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. However, link layer implementations can hide the actually used physical interfaces from the IP stack. For instance, a "logical interface" at the IP layer may enable packet transmission and reception over different physical media. Such techniques can be used to achieve inter-access handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). The hiding mechanisms also need to work together with existing RFC 5213 handover hint mechanisms. The specification of any actual link layer mechanisms is outside the scope of the working group, but the group works on the following: - Informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. - The working group will determine what protocol extensions are required between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to support the ability for an interface (at the IP layer) to transmit packets over different media, the ability to distribute specific traffic flows on different media components of that interface, and making this work with the handover hints in the base protocol. The relevant protocol extensions will be developed as necessary. Radius Extensions to PMIP6: In order to enable network based mobility using PMIP6, the policy profile needs to signal a set of attributes and policies to the MAG and LMA. New Radius attributes need to be specified that are relevant to PMIP6 based mobility. This work item will specify Radius extensions and attributes specific to PMIP6. The work in this charter is entirely internal to the network and does not affect host IP stack operation in any way (except perhaps through impacting packet forwarding capacity visible to the hosts). The working group is not allowed to specify new IP layer protocol mechanisms to signal mobility related events between the host and the network. The proposed activity will be complementary to the existing IETF Working Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will also act as the primary forum where new extensions on top of the Proxy Mobile IPv6 protocol can be developed. The addition of such new extensions to the working group involves addition of the extension to this charter through the normal rechartering process. Goals and Milestones: Done WG chartered Done Initial WG draft on Bulk Refresh Done Decision on the inclusion of possible additional work items Done Initial WG draft on LMA Redirection Done Initial WG draft on Localized Routing Problem Statement Mar 2010 Submit Bulk Refresh to IESG for publication as a Proposed Standard RFC Mar 2010 Submit LMA Redirection to IESG for publication as a Proposed Standard RFC Mar 2010 Initial WG document on RADIUS extensions to PMIP6 May 2010 Submit Localized Routing Problem Statement to IESG for publication as an Informational RFC May 2010 Initial WG draft on Localized Routing Solution Jul 2010 Initial WG document on Applicability Statement on Logical Interface over Multiple Physical Interfaces Jul 2010 WG decision on what Proxy Mobile IPv6 mechanisms are needed to support flow mobility and inter-access handovers on a logical interface over multiple physical interfaces Oct 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces Dec 2010 Submit RADIUS extensions to PMIP6 to IESG for publication as a Proposed Standard Dec 2010 Submit Applicability Statement on Logical Interface over Multiple Physical Interfaces to IESG for publication as Informational RFC Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Flow Mobility and Inter-access Handovers on a Logical Interface over Multiple Physical Interfaces for publication as Proposed Standard RFC(s) Feb 2011 Submit Localized Routing Solution to IESG for publication as a Proposed Standard RFC From sunseawq@huawei.com Fri Feb 12 01:06:30 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DD8428C0E3 for ; Fri, 12 Feb 2010 01:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.247 X-Spam-Level: X-Spam-Status: No, score=-1.247 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_52=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 249EC-bpBmoF for ; Fri, 12 Feb 2010 01:06:29 -0800 (PST) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2BEAA3A7166 for ; Fri, 12 Feb 2010 01:06:29 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXQ000YV1COSQ@szxga02-in.huawei.com> for netext@ietf.org; Fri, 12 Feb 2010 17:07:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXQ00FGO1CO0N@szxga02-in.huawei.com> for netext@ietf.org; Fri, 12 Feb 2010 17:07:36 +0800 (CST) Received: from w53375 ([10.164.12.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXQ0023U1CNPF@szxml04-in.huawei.com> for netext@ietf.org; Fri, 12 Feb 2010 17:07:36 +0800 (CST) Date: Fri, 12 Feb 2010 17:07:35 +0800 From: Qin Wu To: netext@ietf.org Message-id: <033001caabc2$d19ddf30$260ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/mixed; boundary="Boundary_(ID_9cTEF4yHaED88K3LUQPy/g)" X-Priority: 3 X-MSMail-priority: Normal Subject: [netext] Fw: I-D Action:draft-wu-netext-local-ro-05.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 09:06:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_9cTEF4yHaED88K3LUQPy/g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Folks, Based on the comments in the mailinglist and from last IETF meeting, we have made a new version of "An Extension to PMIPv6 for Local Routing Optimization". we believe the new version addresses all the comments we received, Especially comments from Mohana, Glen. Many thanks to them. Given the clear milestone of localized routing topic,We look forward to move this work forward and would like to get more review and comments from all the folks who are intested in this topic. It would be great to get a discussion going before the next meeting. Regards! -Qin ----- Original Message ----- From: To: Sent: Friday, February 12, 2010 4:30 PM Subject: I-D Action:draft-wu-netext-local-ro-05.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : An Extension to Proxy Mobile IPv6 for Local Routing Optimization > Author(s) : W. Wu, B. Sarikaya > Filename : draft-wu-netext-local-ro-05.txt > Pages : 33 > Date : 2010-02-12 > > This document extends local routing in Proxy Mobile IPv6 (PMIPv6) and > defines a localized routing optimization protocol between Mobility > Access Gateways within a single provider domain. The protocol > supports operation over IPv4 transport networks, IPv4 home address > mobility and handover. The Local mobility anchor initiated and > mobile access gateway initiated local routing are allowed to setup > local routing path between the mobile and correspondent node by > sending messages to the corresponding mobile access gateway or local > mobility anchor. If the MN & CN are anchored with two different LMAs > then the MN-LMA must discover which LMA the CN is registered with > before an optimized local routing path can be established. Mobile > Access Gateways create and refresh bindings using proxy binding > update and acknowledgement messages. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-netext-local-ro-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --Boundary_(ID_9cTEF4yHaED88K3LUQPy/g) Content-type: text/plain; name=draft-wu-netext-local-ro-05.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-wu-netext-local-ro-05.txt Content-Type: text/plain Content-ID: <2010-02-12002715.I-D@ietf.org> --Boundary_(ID_9cTEF4yHaED88K3LUQPy/g)-- From Basavaraj.Patil@nokia.com Fri Feb 19 12:48:06 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CE393A6842 for ; Fri, 19 Feb 2010 12:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fm89pztSeMyU for ; Fri, 19 Feb 2010 12:48:05 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6E5943A7A97 for ; Fri, 19 Feb 2010 12:48:05 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o1JKnnYo029462 for ; Fri, 19 Feb 2010 22:49:50 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 22:49:50 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 22:49:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 22:49:40 +0200 Received: from NOK-EUMSG-03.mgdnok.nokia.com ([65.54.30.88]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 19 Feb 2010 21:49:39 +0100 From: To: Date: Fri, 19 Feb 2010 21:49:35 +0100 Thread-Topic: Request for slots on the agenda for IETF77 Thread-Index: AcqxpQtAInSeM01CjU6CluEmcTgnNA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Feb 2010 20:49:40.0868 (UTC) FILETIME=[0EC03C40:01CAB1A5] X-Nokia-AV: Clean Subject: [netext] Request for slots on the agenda for IETF77 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 20:48:06 -0000 Hello, We have requested a 2 hour slot for the Netext WG meeting at IETF77. If you need a slot on the agenda to present an I-D related to the Netext charter, please send a request including: 1. I-D name 2. Time required 3. How is the I-D associated with the charter and WG goals Please note that WG items will take priority over others. -Chairs From Mohana.Jeyatharan@sg.panasonic.com Mon Feb 22 00:12:48 2010 Return-Path: X-Original-To: netext@core3.amsl.com Delivered-To: netext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE8A3A7A46 for ; Mon, 22 Feb 2010 00:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgNcQUkVp1SF for ; Mon, 22 Feb 2010 00:12:47 -0800 (PST) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 18DCE3A7B1E for ; Mon, 22 Feb 2010 00:12:46 -0800 (PST) Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id o1M8EhM5013494; Mon, 22 Feb 2010 17:14:43 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili07) with ESMTP id o1M8EgG09749; Mon, 22 Feb 2010 17:14:43 +0900 (JST) 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: Mon, 22 Feb 2010 16:13:25 +0800 Message-ID: <5F09D220B62F79418461A978CA0921BD03DD60D4@pslexc01.psl.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netext] Request for slots on the agenda for IETF77 thread-index: AcqxpQtAInSeM01CjU6CluEmcTgnNAB8L3sg From: "Mohana Jeyatharan" To: , Subject: Re: [netext] Request for slots on the agenda for IETF77 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 08:12:48 -0000 Dear Chairs, I need presentation slots to present the following Ids [1]draft-jeyatharan-netext-pmip-partial-handoff-v01, 10mins, highlights mechanism to achieve flow mobility in the granularity of prefix =3D>tied to revised charter [2]draft-jeyatharan-netext-pmip-dormant-binding-v00, 10mins, highlights mechanism to achieve fast handoff using a dormant binding mechanism when there is sudden disconnection via one interface. Tied to fast vertical handoff in multiple interface scenario.=3D>tied to revised charter [3]draft-jeyatharan-netext-pmip-bulkpbu-bitmap-v00, 5mins, tied to bulk refersh optimization work of the charter. Thanks. BR, Mohana=20 > -----Original Message----- > From: netext-bounces@ietf.org=20 > [mailto:netext-bounces@ietf.org] On Behalf Of=20 > Basavaraj.Patil@nokia.com > Sent: Saturday, February 20, 2010 4:50 AM > To: netext@ietf.org > Subject: [netext] Request for slots on the agenda for IETF77 >=20 >=20 > Hello, >=20 > We have requested a 2 hour slot for the Netext WG meeting at IETF77. > If you need a slot on the agenda to present an I-D related to=20 > the Netext charter, please send a request including: > 1. I-D name > 2. Time required > 3. How is the I-D associated with the charter and WG goals >=20 > Please note that WG items will take priority over others. >=20 > -Chairs >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext >=20