From mobopts-bounces@ietf.org Wed Jun 4 11:33:24 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26E93A6CFF; Wed, 4 Jun 2008 11:33:24 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91E43A6CFA for ; Wed, 4 Jun 2008 11:33:23 -0700 (PDT) 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 J1A-MqWNlQJ1 for ; Wed, 4 Jun 2008 11:33:19 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id D79F83A6CFB for ; Wed, 4 Jun 2008 11:33:19 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 24so160208wfg.7 for ; Wed, 04 Jun 2008 11:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=l4wPQAr7G/2RUW/5EnsobdgN7bhY5RSUW/SzyVonltg=; b=L165GC9iFHQz3Ln2lLVw3bLcoXhQ00GGcdbnGYcLw6iaOTUaqiWW+2F//8PkpLKXx4 ZXdt35H4sD0xxv2Lh8pBMjLAlBzGVhg5WHYxtKF49upDLJoVdcRFuyNguWaRjXmc884X R+3uC2kNvZIcRKHylK4UNY/6JO2NGWxRxzbkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rkrQ2YfB0Ma9KsQDuL9F7mNlI+z/2/9Q9p9Y5FTeDNeNk9bR+NGAKS6BowAw3N18xY /6NiBT0RlTEihBS6m1TpwgvTtDCl4/eMVe8XTOp25MbKDRN/B3pRPOo2ZsE/thBL4R+B WIuFDZNp2gP1PGiTQHn26a8jN+ZJVz251f3l4= Received: by 10.143.33.12 with SMTP id l12mr93992wfj.272.1212604404250; Wed, 04 Jun 2008 11:33:24 -0700 (PDT) Received: by 10.142.166.13 with HTTP; Wed, 4 Jun 2008 11:33:24 -0700 (PDT) Message-ID: <3d57679a0806041133w671823cqee16d3294b87c768@mail.gmail.com> Date: Wed, 4 Jun 2008 11:33:24 -0700 From: "Rajeev Koodli" To: "mobopts@irtf.org" In-Reply-To: <13E2E485D9AA7240A1C55B0B464198B201E46202@ct11exm63.ds.mot.com> MIME-Version: 1.0 Content-Disposition: inline References: <4D35478224365146822AE9E3AD4A266602706812@exchtewks3.starentnetworks.com> <3d57679a0805161455l60264f1as95047174ebd0b0ed@mail.gmail.com> <13E2E485D9AA7240A1C55B0B464198B201DF500C@ct11exm63.ds.mot.com> <3d57679a0805221945r4d43416bwbf560b46ecc41749@mail.gmail.com> <3d57679a0805291124p2bb61609je8b3a3a89428e907@mail.gmail.com> <13E2E485D9AA7240A1C55B0B464198B201E46202@ct11exm63.ds.mot.com> Cc: Nakhjiri Madjid-VXT746 Subject: [Mobopts] Fwd: RG Last Call for Media-independent Pre-Authentication Document X-BeenThere: mobopts@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@ietf.org Errors-To: mobopts-bounces@ietf.org A Review. Thanks Madjid. ---------- Forwarded message ---------- From: Nakhjiri Madjid-VXT746 Date: Thu, May 29, 2008 at 5:24 PM Subject: RE: [Mobopts] RG Last Call for Media-independent Pre-Authentication Document To: Rajeev Koodli Cc: Nakhjiri Madjid-VXT746 ........................... I unfortunately think the doc has too much background material and abstraction that takes the user through a lot of text (15 pages) before it introduces any of its framework concepts and that makes reviewing very tough if you are time constraint, sorry I think one of the strong points that any doc about Pre-auth needs to make is that many of the procedures such as handover keying and reauthentication deal with cases where there is a single source of trust at the top and all underlying AAA domains trust that top source of trust and any keys it generates and distributes. In cases of multiple operators without roaming relationship, or without agreement to participate in a key management scheme, you do have to perform a pre-auth function to establish the security mechanisms without assuming a common source of trust. the first paragraph of the intro can be toned down a bit with respect to ordering of the challenges. Is this expects to solve the seamless mobility problem even when there is a single L2 interface? (intro) As much as this being a noble goal, I think with the advances in Silicon and wireless devices, this is overcomplication of the requirements. I do agree that the multi-interface assumption has been one of the barriers for 802.21 though. I am wondering how a mobile performs pre-auth with an authentication agent of a new access technology, while still connected to the old one if it is single interface, also not clear how the mobile acquires the IP address of this agent, as section 6.3 states if it is not tuned to the new technology, sorry if I have not gone to end of the document and not being far. Third, a mobility optimization mechanism needs to support not only multi-interface terminals where multiple simultaneous connectivity through multiple interfaces can be expected, but also single-interface terminals. section 1.1. I am not sure if the document needs to go into a serial analysis of every source of delay in the system. Since this is about pre-auth and IP address acquisition, etc, it could simply just talk about those things. so section 1.1 can undergo a serious diet. A QoS style description of delay would not be needed either, IMO. On the other hand, what that section really is missing is a description of issues around reestablishing link security (authentication, link key management, access authorization) in conjunction to network access and handovers (inter or intra domain), because that is really the focus of a pre-auth framework. section 2 This type of Inter-technology handover is often called as Vertical Handover since the mobile makes movement between two different cell sizes. I don't think Vertical handover is defined based on cell size, it is defined based on the type of access technology (as listed). I think an important point about Inter-domain, is not just where the mobile is authenticated, but also where his user profile, credentials are stored and where his payment is associated to. Because that will define the difference between home and visited domains from the security standpoint, the mobile has an initial and permanent trust relationship with its home and any interaction with a visited domain is based on a temporary and transitive trust established based on a mobile-home trust and a home-visited domain roaming relationship. I know it is a sticky subject, but probably AA (authentication agent) needs to provide some IETF or other wireless examples (EAP authenticator, ASN GW, etc) and also how the Authentication signaling is to traverse over the new network if there is only one interface. The parts with pre-configuration are ok from 802.21 perspective, however I don't think this doc or framework should get into decisions of which network to use is a network discover issue that assumes a general broadcasting broker (I think 802.21 calls it information server). Decision regarding which candidate network the mobile needs to pre-authenticate with will depend upon several policies, such as signaling overhead, bandwidth requirement (QoS), mobile's location, communication cost, and handover robustness etc. This just makes the framework for this protocol too large, and academic, specially if things like specific server (that nobody would take ownership of in a inter-domain scenario) come in. ....................... _______________________________________________ Mobopts mailing list Mobopts@ietf.org https://www.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@ietf.org Wed Jun 4 11:46:55 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92AD728C1EA; Wed, 4 Jun 2008 11:46:55 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9560D28C1EA for ; Wed, 4 Jun 2008 11:46:54 -0700 (PDT) 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 Y5vs9V3169HP for ; Wed, 4 Jun 2008 11:46:48 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 5FAE928C1E7 for ; Wed, 4 Jun 2008 11:46:46 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 03611C8033 for ; Wed, 4 Jun 2008 14:46:47 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00611-04 for ; Wed, 4 Jun 2008 14:46:45 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 4 Jun 2008 14:46:45 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 14:46:45 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 14:47:31 -0400 Message-ID: <4D35478224365146822AE9E3AD4A266602AA1EF3@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPA review thread-index: AcjGcKCkGmHQ0VXpSSmoMaKvqrHxMAAAlNoQ From: "Koodli, Rajeev" Importance: normal Priority: normal To: X-OriginalArrivalTime: 04 Jun 2008 18:46:45.0736 (UTC) FILETIME=[56A6A680:01C8C673] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Mobopts] MPA review X-BeenThere: mobopts@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@ietf.org Errors-To: mobopts-bounces@ietf.org Hi, my high-level comment is that the document captures many things. While this is a good thing in one way, it diminishes the focus as a bye product, unfortunately. So, I am suggesting that it should be streamlined to make it crisp to better retain its focus on pre-auth related issues, framework and procedures for inter-domain handovers. More comments below: Regards, -Rajeev The paragraph starting with "An end-to-end delay consists of several.." is too dense and long. I am not sure if all of the text is needed. Please consider making this brief, and keep only the parts which are essential. In general, detailed descriptions of the previous work should be referenced out, and not be repeated here. "This type of Inter-technology handover is often called as Vertical Handover since the mobile makes movement between two different cell sizes." ^^^^^^^^^^ ?? Section 2 is titled "Inter-domain handover", but it includes the definitions for different types of handovers. Perhaps revise the section heading to something like "Handover Types". Also, please provide more succinct definitions. You may move details which may be useful (but not crucial) to an Appendix. (I am trying to see if we can make the presentation little more crisper). Section 3 provides a good survey. You may want to revise the title to "Related Work" Section 4 - Applicability should be no more than two paragraphs I think Shouldn't the Terminology Section be earlier, say right after Introduction? Section 6.1: "MPA provides four basic procedures to provide this functionality. The first procedure is referred to as "pre-authentication", the second procedure is referred to as "pre-configuration", the combination of the third and fourth procedures are referred to as "secure proactive handover"." Either state 4 procedures or 3 procedures. Section 6.1, paragraph 3 is important for people to get a high-level overview. It is too condensed. Please try to make the steps clear. And, do no use acronyms (such as MMP) that are not defined earlier. PHT (Proactive Handover Tunnel) -> Proactive Handover Tunnel (PHT) Section 6.2: "..securely executing a configuration protocol to securely deliver an IP address .." too many 'securely' "An access router is a router that is responsible for the other part of pre-configuration, i.e., securely executing a tunnel management protocol to establish a proactive handover tunnel to the mobile node. The signaling messages of the configuration protocol MUST be protected using a key derived from the key corresponding to the MPA-SA." May be I missed it.. How does the AR get the corresponding keys? You describe it later, but please make a reference Section 6.3: Step 2: "It then performs pre-configuration, with the configuration agent using the configuration protocol to obtain an IP address, say nCoA (new care-of address), and other configuration parameters from the CTN, and with the access router using the tunnel management protocol to establish a proactive handover tunnel. " There are two distinct steps here: pre-configuration, tunnel set up. You should not combine them into a single sentence (this applies as a general rule). Also, specify what "other configuration parameters" mean; it should be clear. Step 4: "The mobile may execute the tunnel management protocol to delete or disable the proactive handover tunnel and cache nCoA after deletion or disabling of the tunnel. " Do you allow tunnel deletion prior to link switching? If so, what does the AR do for packets arriving for nCoA, once tunnel interface is deleted? "Caching" an address does not sound right. "An example call flow for MPA is shown in Figure 3 and Figure 4." Why is this an example call flow? This is _the_ call flow right? Section 7: Please focus on the parts essential to the MPA, and move rest of the description to the Appendix. Section 7.3.5. is perhaps not crucial, and can be moved to the appendix Section 7.4 is not necessary I think. You have created a tunnel interface between the MN and AR. There are references on how to ue ND over tunnel interfaces. You can also disable it. Sections 7.6 and 7.9 are related, and should be condensed into one section I think. Section 7.8 does not belong to the main body of the document Section 8 on Deployment Issues: IMHO, this may be a little early for the framework. I would consider a separate document once enough experience is obtained. If there are parts you consider worth documenting now, please move them to the Appendix. Section 9 is important since it is supposed to capture the Inter-domain Handover, which is the primary focus of this ID. I would consider the key issues that come up, and move multicast mobility out, or considerably condense it. In sum, please revise the ID keeping the essential parts in the main body, referencing known work (without too much description) and moving the adjoining and descriptive material you consider necessary to appendix. General presentation: please revise phrases such as "A mobile may like to.." to "A mobile may wish to.." And, please avoid sentences such as "..should not be a big problem". "Third, a mobility optimization mechanism needs to support not only multi-interface terminals where multiple simultaneous connectivity through multiple interfaces can be expected, but also single-interface terminals." RKo> I assume you mean single interface connectivity right? Even with multiple interfaces, you could still have a single interface connectivity. "References [RFC2679], [RFC2680] and 2681 [RFC2681] describe some of the measurement techniques for delay and jitter." RKo> "Measurement techniques for delay and jitter are described in [], [].." "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." _______________________________________________ Mobopts mailing list Mobopts@ietf.org https://www.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@ietf.org Thu Jun 5 19:56:36 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1163A6AB2; Thu, 5 Jun 2008 19:56:36 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5616A3A6A81 for ; Thu, 5 Jun 2008 19:56:34 -0700 (PDT) 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 hR6Uk-AVl8mO for ; Thu, 5 Jun 2008 19:56:33 -0700 (PDT) Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by core3.amsl.com (Postfix) with ESMTP id F1C633A6AC6 for ; Thu, 5 Jun 2008 19:56:29 -0700 (PDT) Received: from [128.96.58.166] (vpntnlA166.research.telcordia.com [128.96.58.166]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id m562umHu002264; Thu, 5 Jun 2008 22:56:48 -0400 (EDT) Message-ID: <4848A763.8050009@research.telcordia.com> Date: Thu, 05 Jun 2008 22:56:35 -0400 From: Ashutosh Dutta User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: "Koodli, Rajeev" , Nakhjiri Madjid-MNAKHJI1 References: <4D35478224365146822AE9E3AD4A266602AA1EF3@exchtewks3.starentnetworks.com> In-Reply-To: <4D35478224365146822AE9E3AD4A266602AA1EF3@exchtewks3.starentnetworks.com> Cc: mobopts@irtf.org Subject: Re: [Mobopts] MPA review X-BeenThere: mobopts@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobopts-bounces@ietf.org Errors-To: mobopts-bounces@ietf.org Rajeev, Madjid, Thanks for your review and comments on the MPA draft. We will submit a revised version addressing your comments and suggestions. Regards Ashutosh Koodli, Rajeev wrote: > > Hi, > > my high-level comment is that the document captures many things. While > this is a good thing in one way, it diminishes the focus as a bye > product, unfortunately. So, I am suggesting that it should be > streamlined to make it crisp to better retain its focus on pre-auth > related issues, framework and procedures for inter-domain handovers. > > More comments below: > > Regards, > > -Rajeev > > > The paragraph starting with "An end-to-end delay consists of several.." > is too dense and long. I am not sure if all of the text is needed. > Please consider making this brief, and keep only the parts which are > essential. In general, detailed descriptions of the previous work should > be referenced out, and not be repeated here. > > "This type of Inter-technology handover is often > called as Vertical Handover since the mobile makes movement between > two different cell sizes." > ^^^^^^^^^^ ?? > Section 2 is titled "Inter-domain handover", but it includes the > definitions for different types of handovers. Perhaps revise the section > heading to something like "Handover Types". Also, please provide more > succinct definitions. You may move details which may be useful (but not > crucial) to an Appendix. > (I am trying to see if we can make the presentation little more > crisper). > > Section 3 provides a good survey. You may want to revise the title to > "Related Work" > > Section 4 - Applicability should be no more than two paragraphs I think > > Shouldn't the Terminology Section be earlier, say right after > Introduction? > > Section 6.1: > "MPA provides four basic procedures to provide this functionality. > The first procedure is referred to as "pre-authentication", the > second procedure is referred to as "pre-configuration", the > combination of the third and fourth procedures are referred to as > "secure proactive handover"." > > Either state 4 procedures or 3 procedures. > > Section 6.1, paragraph 3 is important for people to get a high-level > overview. It is too condensed. Please try to make the steps clear. And, > do no use acronyms (such as MMP) that are not defined earlier. > > PHT (Proactive Handover Tunnel) -> Proactive Handover Tunnel (PHT) > > Section 6.2: > > "..securely executing a configuration protocol to > securely deliver an IP address .." > > too many 'securely' > > "An access router is a router that is responsible for the other part > of pre-configuration, i.e., securely executing a tunnel management > protocol to establish a proactive handover tunnel to the mobile node. > The signaling messages of the configuration protocol MUST be > protected using a key derived from the key corresponding to the > MPA-SA." > > May be I missed it.. How does the AR get the corresponding keys? You > describe it later, but please make a reference > > Section 6.3: > > Step 2: "It then performs pre-configuration, > with the configuration agent using the configuration protocol to > obtain an IP address, say nCoA (new care-of address), and other > configuration parameters from the CTN, and with the access router > using the tunnel management protocol to establish a proactive > handover tunnel. " > > There are two distinct steps here: pre-configuration, tunnel set up. > You should not combine them into a single sentence (this applies as a > general rule). Also, specify what "other configuration parameters" > mean; it should be clear. > > Step 4: > "The mobile may execute the tunnel > management protocol to delete or disable the proactive handover > tunnel and cache nCoA after deletion or disabling of the tunnel. " > > Do you allow tunnel deletion prior to link switching? If so, what does > the AR do for packets arriving for nCoA, once tunnel interface is > deleted? "Caching" an address does not sound right. > > "An example call flow for MPA is shown in Figure 3 and Figure 4." > > Why is this an example call flow? This is _the_ call flow right? > > Section 7: > > Please focus on the parts essential to the MPA, and move rest of the > description to the Appendix. > > Section 7.3.5. is perhaps not crucial, and can be moved to the appendix > > Section 7.4 is not necessary I think. You have created a tunnel > interface between the MN and AR. There are references on how to ue ND > over tunnel interfaces. You can also disable it. > > Sections 7.6 and 7.9 are related, and should be condensed into one > section I think. > > Section 7.8 does not belong to the main body of the document > > Section 8 on Deployment Issues: IMHO, this may be a little early for the > framework. I would consider a separate document once enough experience > is obtained. If there are parts you consider worth documenting now, > please move them to the Appendix. > > Section 9 is important since it is supposed to capture the Inter-domain > Handover, which is the primary focus of this ID. > I would consider the key issues that come up, and move multicast > mobility out, or considerably condense it. > > In sum, please revise the ID keeping the essential parts in the main > body, referencing known work (without too much description) and moving > the adjoining and descriptive material you consider necessary to > appendix. > > > General presentation: > > please revise phrases such as "A mobile may like to.." to "A mobile may > wish to.." And, please avoid sentences such as "..should not be a big > problem". > > "Third, a mobility optimization mechanism needs to support not only > multi-interface terminals where multiple simultaneous connectivity > through multiple interfaces can be expected, but also single-interface > terminals." > > RKo> I assume you mean single interface connectivity right? Even with > multiple interfaces, you could still have a single interface > connectivity. > > "References [RFC2679], [RFC2680] and 2681 [RFC2681] describe some of the > measurement techniques for delay and > jitter." > > RKo> "Measurement techniques for delay and jitter are described in [], > [].." > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > _______________________________________________ > Mobopts mailing list > Mobopts@ietf.org > https://www.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@ietf.org https://www.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@ietf.org Mon Jun 30 15:05:57 2008 Return-Path: X-Original-To: mobopts-archive@megatron.ietf.org Delivered-To: ietfarch-mobopts-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581F83A6AC3; Mon, 30 Jun 2008 15:05:57 -0700 (PDT) X-Original-To: mobopts@core3.amsl.com Delivered-To: mobopts@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC743A6AE2 for ; Mon, 30 Jun 2008 15:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] 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 aaJALzlxbX+m for ; Mon, 30 Jun 2008 15:05:51 -0700 (PDT) Received: from mx0.starentnetworks.com (mx0.starentnetworks.com [12.38.223.203]) by core3.amsl.com (Postfix) with ESMTP id 431E73A6A93 for ; Mon, 30 Jun 2008 15:05:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2C8C9C801E for ; Mon, 30 Jun 2008 18:05:59 -0400 (EDT) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12368-01 for ; Mon, 30 Jun 2008 18:05:58 -0400 (EDT) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [10.2.4.28]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 30 Jun 2008 18:05:58 -0400 (EDT) X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.] Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jun 2008 18:05:58 -0400 x-mimeole: Produced By Microsoft MimeOLE V6.00.3790.1830 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 18:07:33 -0400 Message-ID: <4D35478224365146822AE9E3AD4A26660302BFE7@exchtewks3.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5184 thread-index: Acja/bJJ87RoWYM1SiyJiobSmjNgwg== From: "Koodli, Rajeev" Importance: normal Priority: normal To: X-OriginalArrivalTime: 30 Jun 2008 22:05:58.0564 (UTC) FILETIME=[79D4F640:01C8DAFD] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com Subject: [Mobopts] RFC 5184 X-BeenThere: mobopts@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1622116303==" Sender: mobopts-bounces@ietf.org Errors-To: mobopts-bounces@ietf.org This is a multi-part message in MIME format. --===============1622116303== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DAFD.79C2D29F" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DAFD.79C2D29F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hello folks, =20 I don't know if you have already seen it, but I missed this announcement.. =20 =20 A new Request for Comments is now available in online RFC libraries. =20 =20 RFC 5184 =20 Title: Unified Layer 2 (L2) Abstractions=20 for Layer 3 (L3)-Driven Fast Handover=20 Author: F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani Status: Experimental Date: May 2008 =20 =20 http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04864.html =20 =20 Congratulations to the authors and the RG! =20 Regards, =20 -Rajeev =20 =20 "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C8DAFD.79C2D29F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello folks,

 

I don’t know if you have already seen it, but I = missed this announcement..

 

 

A new Request for Comments is now available =
in online RFC libraries.
 
        =

       &nbs=
p;RFC 5184
 
        =
Title:      Unified Layer 2 (L2) Abstractions =

       &nbs=
p;            =
;for Layer 3 (L3)-Driven Fast Handover =

       &nbs=
p;Author:     F. Teraoka, K. =
Gogo,
       &nbs=
p;            K. =
Mitsuya, R. Shibui,
       &nbs=
p;            K. =
Mitani
        =
Status:     =
Experimental
        =
Date:       May =
2008

 

 

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04= 864.html

 

 

Congratulations to the authors and the = RG!

 

Regards,

 

-Rajeev

 

 

"This email message and any attachments are confidential information = of Starent Networks, Corp. The information transmitted may not be used = to create or change any contractual obligations of Starent Networks, = Corp. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this e-mail and its attachments by = persons or entities other than the intended recipient is prohibited. If = you are not the intended recipient, please notify the sender immediately = -- by replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." ------_=_NextPart_001_01C8DAFD.79C2D29F-- --===============1622116303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@ietf.org https://www.ietf.org/mailman/listinfo/mobopts --===============1622116303==--