From 16ng-bounces@ietf.org Thu Feb 01 04:09:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXwk-0001OE-Nj; Thu, 01 Feb 2007 04:09:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCVjg-0006Yq-LV for 16ng@ietf.org; Thu, 01 Feb 2007 01:47:56 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCVjf-0003tw-U7 for 16ng@ietf.org; Thu, 01 Feb 2007 01:47:56 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l116lmIe004518; Thu, 1 Feb 2007 08:47:48 +0200 Date: Thu, 1 Feb 2007 08:47:48 +0200 (EET) From: Pekka Savola To: Basavaraj Patil In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2509/Thu Feb 1 02:36:58 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Thu, 01 Feb 2007 04:09:34 -0500 Cc: 16ng@ietf.org Subject: [16NG] Re: Review of the ipv6-over-ipv6cs draft X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Some responses inline, On Wed, 31 Jan 2007, Basavaraj Patil wrote: >> The design implications of raising RA intervals (intead of, say, filtering >> extra RAs out) may not be fully understood. How are other protocols (e.g., >> periodic MLD reports, Neighbor Solicitations due to port scanning or >> pinging >> the all nodes multicast address, etc.) handled? > > Filtering extra RAs is not an option. The MS expects an RA at > MaxAdvIntervals and filtering them would disrupt MS behavior. Which implementations expect this? Is this behaviour related to DNA? At least I have not seen this kind of dependency but I have a very limited view of fixed hosts only. Host implementations that I'm aware of just look at the lifetimes of PIO options (can be long) for address lifetimes and AdvDefaultLifetime (max 9000sec) for default route lifetime. Even if a default route would be lost while in suspend, I don't see this as an issue as immediately when the host gets woken up, the default route could be re-obtained by a) specific RA (if wake up call was sent by the AR -- at the same time or 20ms later) or b) a RS (if host decided to wake up). Later you also said that when a host gets paged it needs to establish the link, implying that in fact there is some delay before link can be used after paging. > The MS and AR are connected via a PtP link which is created via a > combination of the transport connection over the air interface and a > corresponding GRE tunnel between the BS and AR. Are there specific > issues w.r.t MLD reports etc. on a PtP link that you believe need to > be clarified? I don't see PtP specific issues, except that MLD specifications expect that hosts send periodic MLD reports about the groups they have joined (including the solicited-node link local addresses). Similarly, router is required to send MLD queries periodically on the link to check the multicast group memberships. How are you going to deal with this scenario? Will it require a protocol modification as well? Are there other protocols similar to ND and MLD which require periodical messaging that may be relevant in this scenario (I can't recall from the top of my head, but I'd suspect there may be, whether standardized or proprietary)? >> ==> However, if the MS is a router, RA is basically ignored in this kind of >> context. Hence, this approach of non-default MTU configuration seems >> applicable between host and a router only. > > Okay... Do you have any suggestion or text that would help in this > context? I'm not sure which specific text would be most helpful here, but you should probably point out that the proposed approach is only applicable in host-router scenarios so you can't depend on it for all cases. In other scenarios, other mechanisms (unfortunately, the only option I can think of is manual configuration at both ends) needs to be used. >> How do you deal with periodic MLD reports, for >> example? > > So what would break if periodic MLD reports are not sent. If there is MLD snooping (to restrict multicast flooding) along the path, it will break. I'm not sure how applicable this is in this context; if each MS (from the perspective of AR) has a separate link so that 10 multicast recipients of the same group would require 10 GRE tunneled packets (no optimization), this is maybe not an issue except for expandability. I think this is more of a procedural issue, i.e., what steps are required to standardize a mechanism that breaks existing standardized mechanisms? Do all the existing mechanisms need to be changed (first) or something else? Should this approach be reviewed by the people who standardized the old mechanisms? >> How do you prevent frequent port scanning from waking up the host >> every 5 minutes when the router wants to do Neighbor Solicititation for the >> address? > > It does not make sense to do wake up the host every 5 mins. Is there a > reason for the AR to do NS periodically? No -- unless AR has packets to send to the MS. >> 3) The text above seems technically incorrect. The key point here is what >> is the MTU on the wired link between BS and AR. If it supports MTUs higher >> than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling >> could >> possibly still be used. > > True... But the fact is that for WiMAX, the profile specifies a MAX > SDU of 1522 octets. So the packets on the air-interface cannot be > greater than 1522 bytes. So the existence of links with higher MTU > capability on the link between the BS<->AR does not matter. We may be talking past each other, because I don't see what air-interface has to do with this (I'm assuming that the interface between AR and BS is _not_ air-interface but I may be wrong). A 1500-byte packet on AR-BS interface could be encapsulated in GRE (resulting in ~1550 byte packet or something like that) between AR and BS. If AR-BS interface supports MTU higher than about 1550, this should be no problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Feb 01 21:51:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCoW3-0007W2-EZ; Thu, 01 Feb 2007 21:51:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCoW1-0007TK-Mr for 16ng@ietf.org; Thu, 01 Feb 2007 21:51:05 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCoW0-0001PA-EJ for 16ng@ietf.org; Thu, 01 Feb 2007 21:51:05 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1101520nfa for <16ng@ietf.org>; Thu, 01 Feb 2007 18:51:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rgKfFCtrVFfmTCGxkjm3KY83oMuH09/5hSyGHuS/GaxogOs0dFyL2cGKyNfCJiBmfPlVFCJgQVeJiMeO/H1C8G/Gt4wv3hapSyiWQFCTGKz7b4pSndRFoXU5XPpPd+R/qf5kPR22Mx6V54XVBn5fr17B+gmJAA1nC3bpVBJ2UC4= Received: by 10.49.27.11 with SMTP id e11mr3972510nfj.1170384663548; Thu, 01 Feb 2007 18:51:03 -0800 (PST) Received: by 10.48.217.6 with HTTP; Thu, 1 Feb 2007 18:51:03 -0800 (PST) Message-ID: <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> Date: Fri, 2 Feb 2007 11:51:03 +0900 From: "JinHyeock Choi" To: "Alexandru Petrescu" Subject: Re: [16NG] Re: traffic classification In-Reply-To: <45C0C057.5040402@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 16ng@ietf.org, Pekka Savola X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Dear Alex > JinHyeock, thanks for clarification. I think it confirms my > expectations of how 802.16spec intends IPv6CS classifiers to work: by > looking at IPv6 headers. > > Assume an IPv6 packet put by the SS's IPv6 stack on the 802.16MAC has > the Traffic Class equal to DSCP AF11 '001010' (rfc2597 - Class1 with Low > Drop Precedence). > > _How_ does this convert into a service flow? DSCP value doesn't decide a service flow by itself. Usually CID is determined in combination with the other values such as source/ destination addresses. > More specifically, what is the priority assigned to this service flow? > ("traffic priority": sec 11.13.5 of 802.16-2004). This encoding has > values from 0 to 7 with higher numbers indicating higher priority. If > not the "traffic priority" value then what are the other service > flow-specific constants that this IPv6 DSCP (diffserv codepoint) > converts into. As of my knowledge, there is no rule to convert IPv6 DSCP (diffserv codepoint) into 802.16 QoS parameter in a deterministic way. I understand its up to the implementation & policy. Thanks for your kind consideration. Best Regards JinHyeock _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Feb 01 22:20:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCoyN-0008F3-Jr; Thu, 01 Feb 2007 22:20:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCoyM-00085Y-1B for 16ng@ietf.org; Thu, 01 Feb 2007 22:20:22 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCoyL-0007u3-As for 16ng@ietf.org; Thu, 01 Feb 2007 22:20:22 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l123I1aY024043; Fri, 2 Feb 2007 05:18:08 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 05:20:13 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 21:19:55 -0600 Received: from 10.162.252.29 ([10.162.252.29]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Feb 2007 03:19:54 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 01 Feb 2007 21:17:05 -0600 From: Basavaraj Patil To: ext Pekka Savola Message-ID: Thread-Topic: Review of the ipv6-over-ipv6cs draft Thread-Index: AcdGeJ0n26EmkLJrEdu/UgARJNUNiA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 03:19:55.0054 (UTC) FILETIME=[0283FCE0:01C74679] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202051808-5DA39BB0-0FA7A3F1/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: 16ng@ietf.org Subject: [16NG] Re: Review of the ipv6-over-ipv6cs draft X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Hi Pekka, Reponses inline: On 2/1/07 12:47 AM, "ext Pekka Savola" wrote: > Some responses inline, > > On Wed, 31 Jan 2007, Basavaraj Patil wrote: >>> The design implications of raising RA intervals (intead of, say, filtering >>> extra RAs out) may not be fully understood. How are other protocols (e.g., >>> periodic MLD reports, Neighbor Solicitations due to port scanning or >>> pinging >>> the all nodes multicast address, etc.) handled? >> >> Filtering extra RAs is not an option. The MS expects an RA at >> MaxAdvIntervals and filtering them would disrupt MS behavior. > > Which implementations expect this? Is this behaviour related to > DNA? DNA for example. For DNA, a host relies on prefixes which were received within 3 * Maximum of MaxRtrAdvInterval. Well, the problem also is the fact if the MaxRtrAdvInterval as per RFC2461 is fairly small, the AR will send the periodic RAs and this would cause the MS being paged causing it to transition from Idle mode. Discussion on increasing the value of this parameter in the bis version of RFC2461 (during IETF LC) concluded that the value can be specified depending on the link or in specific IPv6 over foo documents. > At least I have not seen this kind of dependency but I have a very > limited view of fixed hosts only. Host implementations that I'm aware > of just look at the lifetimes of PIO options (can be long) for address > lifetimes and AdvDefaultLifetime (max 9000sec) for default route > lifetime. But the Max value of MaxRtrAdvInterval as per RFC2461 is 1800 secs. And this is not long enough. Hence the reason to increase the value of this parameter. > > Even if a default route would be lost while in suspend, I don't see > this as an issue as immediately when the host gets woken up, the > default route could be re-obtained by a) specific RA (if wake up call > was sent by the AR -- at the same time or 20ms later) or b) a RS (if > host decided to wake up). Later you also said that when a host gets > paged it needs to establish the link, implying that in fact there is > some delay before link can be used after paging. Well... If the AR is configured to send periodic RAs at regular intervals (MaxRtrAdvInterval), the AR would end up paging the host and waking it up to deliver an RA which is essentially not very useful to the host. In fact we had an I-D (draft-madanapalli-ipv6-periodic-rtr-advts-00.txt) proposing that it should be possible to not send RAs at all on certain links. But because of backward compatibility issues this has not progressed. Since a host can always send a Rtr solicitation whenever it needs to, why send periodic RAs at all? If movement detection is not based on RAs as an example.. The delay in establishing the link after the MS is paged is fairly small and there is buffering capability in the network to manage the delay. > >> The MS and AR are connected via a PtP link which is created via a >> combination of the transport connection over the air interface and a >> corresponding GRE tunnel between the BS and AR. Are there specific >> issues w.r.t MLD reports etc. on a PtP link that you believe need to >> be clarified? > > I don't see PtP specific issues, except that MLD specifications expect > that hosts send periodic MLD reports about the groups they have joined > (including the solicited-node link local addresses). Similarly, > router is required to send MLD queries periodically on the link to > check the multicast group memberships. How are you going to deal with > this scenario? Will it require a protocol modification as well? No. The draft only increases the Max value of MaxRtrAdvInterval. It doesn't change any standard w.r.t. periodic MLD report. > > Are there other protocols similar to ND and MLD which require > periodical messaging that may be relevant in this scenario (I can't > recall from the top of my head, but I'd suspect there may be, whether > standardized or proprietary)? > Cant think of any. >>> ==> However, if the MS is a router, RA is basically ignored in this kind of >>> context. Hence, this approach of non-default MTU configuration seems >>> applicable between host and a router only. >> >> Okay... Do you have any suggestion or text that would help in this >> context? > > I'm not sure which specific text would be most helpful here, but you > should probably point out that the proposed approach is only > applicable in host-router scenarios so you can't depend on it for all > cases. In other scenarios, other mechanisms (unfortunately, the only > option I can think of is manual configuration at both ends) needs to > be used. Okay. I can add some text to this effect. > >>> How do you deal with periodic MLD reports, for >>> example? >> >> So what would break if periodic MLD reports are not sent. > > If there is MLD snooping (to restrict multicast flooding) along the > path, it will break. I'm not sure how applicable this is in this > context; if each MS (from the perspective of AR) has a separate link > so that 10 multicast recipients of the same group would require 10 GRE > tunneled packets (no optimization), this is maybe not an issue except > for expandability. Yes. Because of the p2p link model, it won't break even in presence of MLD snooping. > > I think this is more of a procedural issue, i.e., what steps are > required to standardize a mechanism that breaks existing standardized > mechanisms? Do all the existing mechanisms need to be changed (first) > or something else? Should this approach be reviewed by the people who > standardized the old mechanisms? > >>> How do you prevent frequent port scanning from waking up the host >>> every 5 minutes when the router wants to do Neighbor Solicititation for the >>> address? >> >> It does not make sense to do wake up the host every 5 mins. Is there a >> reason for the AR to do NS periodically? > > No -- unless AR has packets to send to the MS. The AR does not do NS at all in the case of 802.16 because 802.16 doesn't use MAC address for traffic forwarding. The AR simply sends the packet destined to the MS to its virtual interface and if the MS is in idle mode, it is paged. If not the packet is delivered. > >>> 3) The text above seems technically incorrect. The key point here is what >>> is the MTU on the wired link between BS and AR. If it supports MTUs higher >>> than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling >>> could >>> possibly still be used. >> >> True... But the fact is that for WiMAX, the profile specifies a MAX >> SDU of 1522 octets. So the packets on the air-interface cannot be >> greater than 1522 bytes. So the existence of links with higher MTU >> capability on the link between the BS<->AR does not matter. > > We may be talking past each other, because I don't see what > air-interface has to do with this (I'm assuming that the interface > between AR and BS is _not_ air-interface but I may be wrong). A > 1500-byte packet on AR-BS interface could be encapsulated in GRE > (resulting in ~1550 byte packet or something like that) between AR and > BS. If AR-BS interface supports MTU higher than about 1550, this > should be no problem. Ahh... The BS<->AR link is what you were refering to.. I agree... But in general MTU size of 1500 on links is assumed or expected. And hence the recommendation. -Raj _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Feb 02 01:02:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCrUo-0007gG-0Z; Fri, 02 Feb 2007 01:02:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCrUm-0007gA-AB for 16ng@ietf.org; Fri, 02 Feb 2007 01:02:00 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCrUk-0006Rw-Mh for 16ng@ietf.org; Fri, 02 Feb 2007 01:02:00 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l1261qZ9001127; Fri, 2 Feb 2007 08:01:52 +0200 Date: Fri, 2 Feb 2007 08:01:52 +0200 (EET) From: Pekka Savola To: Basavaraj Patil In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2514/Thu Feb 1 23:50:10 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 16ng@ietf.org Subject: [16NG] Re: Review of the ipv6-over-ipv6cs draft X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org On Thu, 1 Feb 2007, Basavaraj Patil wrote: > DNA for example. For DNA, a host relies on prefixes which were received > within 3 * Maximum of MaxRtrAdvInterval. Such behaviour would be incorrect, as RFC2461 says: AdvDefaultLifetime The value to be placed in the Router Lifetime field of Router Advertisements sent from the interface, in seconds. MUST be either zero or between MaxRtrAdvInterval and 9000 seconds. A value of zero indicates that the router is not to be used as a default router. Default: 3 * MaxRtrAdvInterval So it is legitimate to have: 3*MaxRtrAdvInterval < AdvDefaultLifetime < 9000 If what you say is true, DNA specification is incorrect. >> Even if a default route would be lost while in suspend, I don't see >> this as an issue as immediately when the host gets woken up, the >> default route could be re-obtained by a) specific RA (if wake up call >> was sent by the AR -- at the same time or 20ms later) or b) a RS (if >> host decided to wake up). Later you also said that when a host gets >> paged it needs to establish the link, implying that in fact there is >> some delay before link can be used after paging. > > Well... If the AR is configured to send periodic RAs at regular > intervals (MaxRtrAdvInterval), the AR would end up paging the host and > waking it up to deliver an RA which is essentially not very useful > to the host. If this approach were to be chosen, MaxRtrAdvInterval would be set to something like 1800 seconds, but for example BS could filter out 80% of messages, so an RA would only be sent to MS every 8000 seconds. >From the perspective of MS, filtering out RAs is indistinguishable from it packets getting lost in the network, so this would require no host modifications. > In fact we had an I-D > (draft-madanapalli-ipv6-periodic-rtr-advts-00.txt) proposing that it > should be possible to not send RAs at all on certain links. But > because of backward compatibility issues this has not > progressed. Since a host can always send a Rtr solicitation whenever > it needs to, why send periodic RAs at all? If movement detection is > not based on RAs as an example.. In fact, I have experience from traditional ethernet links where hosts (when they boot up) send RS's too early so that they are lost, and you'll need to rely on the next periodic RA. While careful implementation may avoid this particular pitfall, at least on typical hosts "RS only" strategy would have been less effective in ensuring the hosts always have connectivity. >>>> How do you prevent frequent port scanning from waking up the host >>>> every 5 minutes when the router wants to do Neighbor Solicititation for the >>>> address? >>> >>> It does not make sense to do wake up the host every 5 mins. Is there a >>> reason for the AR to do NS periodically? >> >> No -- unless AR has packets to send to the MS. > > The AR does not do NS at all in the case of 802.16 because 802.16 > doesn't use MAC address for traffic forwarding. > The AR simply sends the packet destined to the MS to its virtual > interface and if the MS is in idle mode, it is paged. If not the > packet is delivered. Ok, this is something that needs to be spelled out better and was one of my earlier points, i.e., how do you do address mapping between IP addresses and link-layer addresses. RFC2461 section 7 specifies that in the typical case. It seems you diverge from that. Does that mean that NUD (as part of section 7) is also not used? In particular, NUD also applies to point-to-point interfaces which have no link-layer addresses (e.g., tunnels) even though the use of NS for address resolution wouldn't. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From hikita_tenkou_2000@yahoo.fr Fri Feb 02 04:29:03 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCuj9-0005UW-Kb for 16NG-ARCHIVE@LISTS.IETF.ORG; Fri, 02 Feb 2007 04:29:03 -0500 Received: from [59.44.235.166] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCuj2-0000GM-QZ for 16NG-ARCHIVE@LISTS.IETF.ORG; Fri, 02 Feb 2007 04:29:03 -0500 Received: from nocb7 (unknown [118.71.13.144]) by smtp11 (Coremail) with SMTP id 1l74DsihDxZ0AuJO.1 for <16ng-archive@lists.ietf.org>; Fri, 02 Feb 2007 17:28:59 +0800 (CST) X-Originating-IP: [118.71.13.144] X-Spam-Score: 1.6 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f From: To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 $B%a!<%k5qH](B maki_noda21@yahoo.co.uk From 16ng-bounces@ietf.org Fri Feb 02 04:55:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv8c-0000hT-NU; Fri, 02 Feb 2007 04:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv8c-0000et-2i for 16ng@ietf.org; Fri, 02 Feb 2007 04:55:22 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCv8a-0007bX-Ro for 16ng@ietf.org; Fri, 02 Feb 2007 04:55:22 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1170410118!9759150!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 482 invoked from network); 2 Feb 2007 09:55:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 2 Feb 2007 09:55:18 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l129tBOd017657; Fri, 2 Feb 2007 02:55:13 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l129tAK0006690; Fri, 2 Feb 2007 03:55:10 -0600 (CST) Message-ID: <45C30A7D.2050605@motorola.com> Date: Fri, 02 Feb 2007 10:55:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JinHyeock Choi Subject: Re: [16NG] Re: traffic classification References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> In-Reply-To: <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 16ng@ietf.org, Pekka Savola X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org JinHyeock Choi wrote: > Dear Alex > >> JinHyeock, thanks for clarification. I think it confirms my >> expectations of how 802.16spec intends IPv6CS classifiers to work: by >> looking at IPv6 headers. >> >> Assume an IPv6 packet put by the SS's IPv6 stack on the 802.16MAC has >> the Traffic Class equal to DSCP AF11 '001010' (rfc2597 - Class1 with Low >> Drop Precedence). >> >> _How_ does this convert into a service flow? > > DSCP value doesn't decide a service flow by itself. Usually CID is > determined in combination with the other values such as source/ > destination addresses. > >> More specifically, what is the priority assigned to this service flow? >> ("traffic priority": sec 11.13.5 of 802.16-2004). This encoding has >> values from 0 to 7 with higher numbers indicating higher priority. If >> not the "traffic priority" value then what are the other service >> flow-specific constants that this IPv6 DSCP (diffserv codepoint) >> converts into. > > As of my knowledge, there is no rule to convert IPv6 DSCP (diffserv > codepoint) into 802.16 QoS parameter in a deterministic way. I > understand its up to the implementation & policy. Isn't this an interoperability issue? (between one's phone to one other's base station). Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Feb 02 05:27:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCvdJ-00087d-Oh; Fri, 02 Feb 2007 05:27:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCvdI-00087X-Ti for 16ng@ietf.org; Fri, 02 Feb 2007 05:27:04 -0500 Received: from nf-out-0910.google.com ([64.233.182.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCvdG-0001So-GF for 16ng@ietf.org; Fri, 02 Feb 2007 05:27:04 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1194915nfa for <16ng@ietf.org>; Fri, 02 Feb 2007 02:27:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z/p1Nv/zwN+7a0ITXupkAG/WoGSJJsRrUiUmIKFrXOZ5tb3EIRujXogWdyzxTcdM+FsCzKRZPlzDV27pIyfPLiUGlhGEaMi79GAwECLihIZDDFLsLK1hbN4ucqCU7QRgopNynyAtZBDI0/2SXEqi/zsZm49BkIXQpotbHxlSJs0= Received: by 10.49.13.14 with SMTP id q14mr6134596nfi.1170412021121; Fri, 02 Feb 2007 02:27:01 -0800 (PST) Received: by 10.48.217.6 with HTTP; Fri, 2 Feb 2007 02:27:00 -0800 (PST) Message-ID: <92e919fb0702020227h387d3a7ct7ecfeea501712e7f@mail.gmail.com> Date: Fri, 2 Feb 2007 19:27:00 +0900 From: "JinHyeock Choi" To: "Pekka Savola" Subject: Re: [16NG] Re: Review of the ipv6-over-ipv6cs draft In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Dear Pekka Thanks for your helpful review. Kindly find my in-line comments. > > DNA for example. For DNA, a host relies on prefixes which were received > > within 3 * Maximum of MaxRtrAdvInterval. > > Such behaviour would be incorrect, as RFC2461 says: > > AdvDefaultLifetime > The value to be placed in the Router Lifetime field > of Router Advertisements sent from the interface, > in seconds. MUST be either zero or between > MaxRtrAdvInterval and 9000 seconds. A value of > zero indicates that the router is not to be used as > a default router. > > Default: 3 * MaxRtrAdvInterval > > So it is legitimate to have: > > 3*MaxRtrAdvInterval < AdvDefaultLifetime < 9000 > > If what you say is true, DNA specification is incorrect. I'm not sure why that's incorrect. First take notice that it is NOT MaxRtrAdvInterval BUT Maximum of MaxRtrAdvInterval. (This distinction is sometimes confusing, at least to me.) According to RFC 2461, Maximum of MaxRtrAdvInterval is 30 min but MaxRtrAdvInterval may differ from router to router. MaxRtrAdvInterval The maximum time allowed between sending unsolicited multicast Router Advertisements from the interface, in seconds. MUST be no less than 4 seconds and no greater than 1800 seconds. Second a host simply stops using for DNA operation a prefix which was not received within 3 * Maximum of MaxRtrAdvInterval but can keep using the prefix as of RFC 2461. This 3 * Maximum of MaxRtrAdvInterval rule is to remove the stale prefix information quickly because prefix lifetime can be quite long, days or even weeks, for DNA operation. > >> Even if a default route would be lost while in suspend, I don't see > >> this as an issue as immediately when the host gets woken up, the > >> default route could be re-obtained by a) specific RA (if wake up call > >> was sent by the AR -- at the same time or 20ms later) or b) a RS (if > >> host decided to wake up). Later you also said that when a host gets > >> paged it needs to establish the link, implying that in fact there is > >> some delay before link can be used after paging. > > > > Well... If the AR is configured to send periodic RAs at regular > > intervals (MaxRtrAdvInterval), the AR would end up paging the host and > > waking it up to deliver an RA which is essentially not very useful > > to the host. > > If this approach were to be chosen, MaxRtrAdvInterval would be set to > something like 1800 seconds, but for example BS could filter out 80% > of messages, so an RA would only be sent to MS every 8000 seconds. > From the perspective of MS, filtering out RAs is indistinguishable > from it packets getting lost in the network, so this would require no > host modifications. As you wrote above, assume MaxRtrAdvInterval is set to 1800 secs (which happens to be also the Maximum of MaxRtrAdvInterval) and BS filters out to deliver RA every 8000 secs. Then after 5400 secs, from the lack of RAs within 3 * Maximum of MaxRtrAdvInterval, hosts can deduce that it has missed at least 3 RAs and stop using advertised prefix for DNA operation. If MaxRtrAdvInterval is very close to Maximum of Max RtrAdvInterval, filtering out some RAs may give hosts the wrong impression that there is something wrong on the router/link. Thanks for your kind consideration. Best Regards JinHyeock _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Feb 02 09:20:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzHU-0003JT-KP; Fri, 02 Feb 2007 09:20:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCzHT-0003JL-Jl for 16ng@ietf.org; Fri, 02 Feb 2007 09:20:47 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCzHS-0002fw-VK for 16ng@ietf.org; Fri, 02 Feb 2007 09:20:47 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id l12EKeMG012890; Fri, 2 Feb 2007 16:20:40 +0200 Date: Fri, 2 Feb 2007 16:20:40 +0200 (EET) From: Pekka Savola To: JinHyeock Choi Subject: DNA and using 3*MaxRtrAdvInterval [Re: [16NG] Re: Review of the ipv6-over-ipv6cs draft] In-Reply-To: <92e919fb0702020227h387d3a7ct7ecfeea501712e7f@mail.gmail.com> Message-ID: References: <92e919fb0702020227h387d3a7ct7ecfeea501712e7f@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.7/2514/Thu Feb 1 23:50:10 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org On Fri, 2 Feb 2007, JinHyeock Choi wrote: >> > DNA for example. For DNA, a host relies on prefixes which were received >> > within 3 * Maximum of MaxRtrAdvInterval. >> >> Such behaviour would be incorrect, as RFC2461 says: >> >> AdvDefaultLifetime >> The value to be placed in the Router Lifetime field >> of Router Advertisements sent from the interface, >> in seconds. MUST be either zero or between >> MaxRtrAdvInterval and 9000 seconds. A value of >> zero indicates that the router is not to be used as >> a default router. >> >> Default: 3 * MaxRtrAdvInterval >> >> So it is legitimate to have: >> >> 3*MaxRtrAdvInterval < AdvDefaultLifetime < 9000 >> >> If what you say is true, DNA specification is incorrect. > > I'm not sure why that's incorrect. > > First take notice that it is NOT MaxRtrAdvInterval BUT Maximum of > MaxRtrAdvInterval. (This distinction is sometimes confusing, at least > to me.) According to RFC 2461, Maximum of MaxRtrAdvInterval is 30 min > but MaxRtrAdvInterval may differ from router to router. > > MaxRtrAdvInterval > The maximum time allowed between sending > unsolicited multicast Router Advertisements from > the interface, in seconds. MUST be no less than 4 > seconds and no greater than 1800 seconds. > > Second a host simply stops using for DNA operation a prefix which was > not received within 3 * Maximum of MaxRtrAdvInterval but can keep > using the prefix as of RFC 2461. > > This 3 * Maximum of MaxRtrAdvInterval rule is to remove the stale > prefix information quickly because prefix lifetime can be quite long, > days or even weeks, for DNA operation. OK, it is "correct" in the sense that DNA can certainly, at 3* Max_MaxRtrAdvInterval decide that the default router is rather stale (at 60% of its maximum lifetime) and stop using it, but Neighbor Discovery itself specifies the maximum as max{Max_MaxRtrAdvInterval,9000}. Hence if 3*Max_MaxRtrAdvInverval is felt to be too short a time to wake up a dormant host, but 9000 seconds would not be, DNA could be fixed to use the rest of the 9000 seconds the same way as ND is already using using it. >> > > Even if a default route would be lost while in suspend, I don't see >> > > this as an issue as immediately when the host gets woken up, the >> > > default route could be re-obtained by a) specific RA (if wake up call >> > > was sent by the AR -- at the same time or 20ms later) or b) a RS (if >> > > host decided to wake up). Later you also said that when a host gets >> > > paged it needs to establish the link, implying that in fact there is >> > > some delay before link can be used after paging. >> > >> > Well... If the AR is configured to send periodic RAs at regular >> > intervals (MaxRtrAdvInterval), the AR would end up paging the host and >> > waking it up to deliver an RA which is essentially not very useful >> > to the host. >> >> If this approach were to be chosen, MaxRtrAdvInterval would be set to >> something like 1800 seconds, but for example BS could filter out 80% >> of messages, so an RA would only be sent to MS every 8000 seconds. >> From the perspective of MS, filtering out RAs is indistinguishable >> from it packets getting lost in the network, so this would require no >> host modifications. > > As you wrote above, assume MaxRtrAdvInterval is set to 1800 secs > (which happens to be also the Maximum of MaxRtrAdvInterval) and BS > filters out to deliver RA every 8000 secs. > > Then after 5400 secs, from the lack of RAs within 3 * Maximum of > MaxRtrAdvInterval, hosts can deduce that it has missed at least 3 RAs > and stop using advertised prefix for DNA operation. And that is very much due to the way how DNA has been specified, not how ND has been specified. Perhaps DNA should change to look at 5*Max_MaxRtrAdvInterval (or in other words: 9000 seconds) rather than just 60% of the maximum. > If MaxRtrAdvInterval is very close to Maximum of Max RtrAdvInterval, > filtering out some RAs may give hosts the wrong impression that there > is something wrong on the router/link. That's correct in a way, if the hosts are (too) "smart" and e.g., report that something odd is going on if there is no RA seen in 30 minutes. A dumb host doesn't even need to know what Max_MaxRtrAdvInterval and don't care though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Feb 02 16:53:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6LH-0001Td-4Y; Fri, 02 Feb 2007 16:53:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD6LF-0001TY-VD for 16ng@ietf.org; Fri, 02 Feb 2007 16:53:09 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD6LD-0005V7-Gk for 16ng@ietf.org; Fri, 02 Feb 2007 16:53:09 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l12LoB94016081; Fri, 2 Feb 2007 23:50:12 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 23:52:48 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 15:52:36 -0600 Received: from 10.162.252.137 ([10.162.252.137]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 2 Feb 2007 21:52:35 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 02 Feb 2007 15:54:59 -0600 From: Basavaraj Patil To: ext Pekka Savola Message-ID: Thread-Topic: Review of the ipv6-over-ipv6cs draft Thread-Index: AcdHFMhfBy9Be7MIEduttQARJNUNiA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 21:52:36.0077 (UTC) FILETIME=[732FA9D0:01C74714] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070202235012-3EB8DBB0-6F4434B7/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 16ng@ietf.org Subject: [16NG] Re: Review of the ipv6-over-ipv6cs draft X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Inline: On 2/2/07 12:01 AM, "ext Pekka Savola" wrote: >>> Even if a default route would be lost while in suspend, I don't see >>> this as an issue as immediately when the host gets woken up, the >>> default route could be re-obtained by a) specific RA (if wake up call >>> was sent by the AR -- at the same time or 20ms later) or b) a RS (if >>> host decided to wake up). Later you also said that when a host gets >>> paged it needs to establish the link, implying that in fact there is >>> some delay before link can be used after paging. >> >> Well... If the AR is configured to send periodic RAs at regular >> intervals (MaxRtrAdvInterval), the AR would end up paging the host and >> waking it up to deliver an RA which is essentially not very useful >> to the host. > > If this approach were to be chosen, MaxRtrAdvInterval would be set to > something like 1800 seconds, but for example BS could filter out 80% > of messages, so an RA would only be sent to MS every 8000 seconds. > From the perspective of MS, filtering out RAs is indistinguishable > from it packets getting lost in the network, so this would require no > host modifications. > Well requiring the BS to filter such messages would be an additional requirement and not the best option. Also the BS would need to know which specific RAs are to be filtered, I.e the periodic ones vs the ones that are solicited by the MS. Additionally if the host implementation is such that it will wake up to receive an RA when the MaxRtrAdvInterval is reached it will have the adverse effect of waking up unnecessarily and wasting battery power and air0interface resources. Such a host may end up even sending an RS at the expiry of the MaxRtrAdvInterval in case the RA has been filtered out by the BS or lost. Hence it is better to increase the value of the MaxRtrAdvInterval. This change does no harm. -Raj _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sat Feb 03 00:33:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDDVz-0005dW-Rk; Sat, 03 Feb 2007 00:32:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDDVx-0005dK-PO for 16ng@ietf.org; Sat, 03 Feb 2007 00:32:41 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDDVw-0000iF-Go for 16ng@ietf.org; Sat, 03 Feb 2007 00:32:41 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1465796nfa for <16ng@ietf.org>; Fri, 02 Feb 2007 21:32:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oL0WY40rjUV+SWQPeMLWMsYtgAvxwcGHxvh3ZbduNZ75CjUXjSDRgzeEksKI5MjBPOdSKPzvVF5tV9r8ohjc2A85ynK41JUixgGXUttS2j/syYHbJbNar7SRFBg8BcLmIT+dFDd6hX4Rm5tUFPKDcUUKKqJcxyc4LnGusGsHPfw= Received: by 10.48.48.1 with SMTP id v1mr5874792nfv.1170480759683; Fri, 02 Feb 2007 21:32:39 -0800 (PST) Received: by 10.48.217.6 with HTTP; Fri, 2 Feb 2007 21:32:39 -0800 (PST) Message-ID: <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> Date: Sat, 3 Feb 2007 14:32:39 +0900 From: "JinHyeock Choi" To: "Alexandru Petrescu" Subject: Re: [16NG] Re: traffic classification In-Reply-To: <45C30A7D.2050605@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 16ng@ietf.org, Pekka Savola X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Alex > >> More specifically, what is the priority assigned to this service flow? > >> ("traffic priority": sec 11.13.5 of 802.16-2004). This encoding has > >> values from 0 to 7 with higher numbers indicating higher priority. If > >> not the "traffic priority" value then what are the other service > >> flow-specific constants that this IPv6 DSCP (diffserv codepoint) > >> converts into. > > > > As of my knowledge, there is no rule to convert IPv6 DSCP (diffserv > > codepoint) into 802.16 QoS parameter in a deterministic way. I > > understand its up to the implementation & policy. > > Isn't this an interoperability issue? (between one's phone to one > other's base station). I can't think of any but which, I admit, doesn't guarantee there exists none. :-) Best Regards JinHyeock _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sat Feb 03 01:15:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEBX-0001nl-0q; Sat, 03 Feb 2007 01:15:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDEBW-0001ng-7D for 16ng@ietf.org; Sat, 03 Feb 2007 01:15:38 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDEBV-0004cX-HM for 16ng@ietf.org; Sat, 03 Feb 2007 01:15:38 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1474002nfa for <16ng@ietf.org>; Fri, 02 Feb 2007 22:15:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RmBvmCyEn4lrg0KtyEfaoihN6oCDFd7vh+x9AUsvrb7EDoaRNmME5SCM6NRqIjjc/H07OslJKHrWK6zSjLRyaXQzWUN5v9l+0b97nof7RMKse3blGCtmdCa5lz3EYbopezEWahENm1JDSt+2uWyBF3jW+CdifRDIndVuIiAz+PE= Received: by 10.49.20.1 with SMTP id x1mr1520855nfi.1170483336708; Fri, 02 Feb 2007 22:15:36 -0800 (PST) Received: by 10.48.217.6 with HTTP; Fri, 2 Feb 2007 22:15:36 -0800 (PST) Message-ID: <92e919fb0702022215oea673e5we802ae59104e1940@mail.gmail.com> Date: Sat, 3 Feb 2007 15:15:36 +0900 From: "JinHyeock Choi" To: "Pekka Savola" Subject: Re: DNA and using 3*MaxRtrAdvInterval [Re: [16NG] Re: Review of the ipv6-over-ipv6cs draft] In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92e919fb0702020227h387d3a7ct7ecfeea501712e7f@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Pekka > >> > DNA for example. For DNA, a host relies on prefixes which were received > >> > within 3 * Maximum of MaxRtrAdvInterval. > >> > >> Such behaviour would be incorrect, as RFC2461 says: > >> > >> AdvDefaultLifetime > >> The value to be placed in the Router Lifetime field > >> of Router Advertisements sent from the interface, > >> in seconds. MUST be either zero or between > >> MaxRtrAdvInterval and 9000 seconds. A value of > >> zero indicates that the router is not to be used as > >> a default router. > >> > >> Default: 3 * MaxRtrAdvInterval > >> > >> So it is legitimate to have: > >> > >> 3*MaxRtrAdvInterval < AdvDefaultLifetime < 9000 > >> > >> If what you say is true, DNA specification is incorrect. > > > > I'm not sure why that's incorrect. > > > > First take notice that it is NOT MaxRtrAdvInterval BUT Maximum of > > MaxRtrAdvInterval. (This distinction is sometimes confusing, at least > > to me.) According to RFC 2461, Maximum of MaxRtrAdvInterval is 30 min > > but MaxRtrAdvInterval may differ from router to router. > > > > MaxRtrAdvInterval > > The maximum time allowed between sending > > unsolicited multicast Router Advertisements from > > the interface, in seconds. MUST be no less than 4 > > seconds and no greater than 1800 seconds. > > > > Second a host simply stops using for DNA operation a prefix which was > > not received within 3 * Maximum of MaxRtrAdvInterval but can keep > > using the prefix as of RFC 2461. > > > > This 3 * Maximum of MaxRtrAdvInterval rule is to remove the stale > > prefix information quickly because prefix lifetime can be quite long, > > days or even weeks, for DNA operation. > > OK, it is "correct" in the sense that DNA can certainly, at 3* > Max_MaxRtrAdvInterval decide that the default router is rather stale > (at 60% of its maximum lifetime) and stop using it, but Neighbor > Discovery itself specifies the maximum as > max{Max_MaxRtrAdvInterval,9000}. > > Hence if 3*Max_MaxRtrAdvInverval is felt to be too short a time to > wake up a dormant host, but 9000 seconds would not be, DNA could be > fixed to use the rest of the 9000 seconds the same way as ND is > already using using it. I am a little confused. First, 3 * Max_MaxRtrAdvInterval rule only prevents a host from using old prefixes for DNA operation, i.e. link identification. It doesn't mandate the host stop using any router. Second, since Max_MaxRtrAdvInterval is 1800 secs, max{Max_MaxRtrAdvInterval,9000} is simply 9000 sec. > >> > > Even if a default route would be lost while in suspend, I don't see > >> > > this as an issue as immediately when the host gets woken up, the > >> > > default route could be re-obtained by a) specific RA (if wake up call > >> > > was sent by the AR -- at the same time or 20ms later) or b) a RS (if > >> > > host decided to wake up). Later you also said that when a host gets > >> > > paged it needs to establish the link, implying that in fact there is > >> > > some delay before link can be used after paging. > >> > > >> > Well... If the AR is configured to send periodic RAs at regular > >> > intervals (MaxRtrAdvInterval), the AR would end up paging the host and > >> > waking it up to deliver an RA which is essentially not very useful > >> > to the host. > >> > >> If this approach were to be chosen, MaxRtrAdvInterval would be set to > >> something like 1800 seconds, but for example BS could filter out 80% > >> of messages, so an RA would only be sent to MS every 8000 seconds. > >> From the perspective of MS, filtering out RAs is indistinguishable > >> from it packets getting lost in the network, so this would require no > >> host modifications. > > > > As you wrote above, assume MaxRtrAdvInterval is set to 1800 secs > > (which happens to be also the Maximum of MaxRtrAdvInterval) and BS > > filters out to deliver RA every 8000 secs. > > > > Then after 5400 secs, from the lack of RAs within 3 * Maximum of > > MaxRtrAdvInterval, hosts can deduce that it has missed at least 3 RAs > > and stop using advertised prefix for DNA operation. > > And that is very much due to the way how DNA has been specified, not > how ND has been specified. Perhaps DNA should change to look at > 5*Max_MaxRtrAdvInterval (or in other words: 9000 seconds) rather than > just 60% of the maximum. It depends on how many lost RAs would constitute prefix invalidation. Maybe we'd better discuss this further in DNA WG ML. By chance, Sathya happened to submit an updated DNAv6 draft today. Your feedback on DNA solution would be appreciated. > > If MaxRtrAdvInterval is very close to Maximum of Max RtrAdvInterval, > > filtering out some RAs may give hosts the wrong impression that there > > is something wrong on the router/link. > > That's correct in a way, if the hosts are (too) "smart" and e.g., > report that something odd is going on if there is no RA seen in 30 > minutes. A dumb host doesn't even need to know what > Max_MaxRtrAdvInterval and don't care though. Right, we were concerned that MIPv6 hosts may be such a smart ones because RFC 3775 recommends mobile nodes to interpret the lack of RAs as an L3 handoff indication. the mobile node needs to perform Router Discovery to discover routers and prefixes on the new link, as described in Section 6.3.7 of RFC 2461 [12]. o If Router Advertisements that the mobile node receives include an Advertisement Interval option, the mobile node may use its Advertisement Interval field as an indication of the frequency with which it should expect to continue to receive future Advertisements from that router. This field specifies the minimum rate (the maximum amount of time between successive Advertisements) that the mobile node should expect. If this amount of time elapses without the mobile node receiving any Advertisement from this router, the mobile node can be sure that at least one Advertisement sent by the router has been lost. The mobile node can then implement its own policy to determine how many lost Advertisements from its current default router constitute an L3 handover indication. Thanks for your kind consideration. Best Regards JinHyeock _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sat Feb 03 08:12:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDKgK-0005zT-TF; Sat, 03 Feb 2007 08:11:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDKgJ-0005xy-6C for 16ng@ietf.org; Sat, 03 Feb 2007 08:11:51 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HDKgF-0003yT-R0 for 16ng@ietf.org; Sat, 03 Feb 2007 08:11:51 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1170508306!903078!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3262 invoked from network); 3 Feb 2007 13:11:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 3 Feb 2007 13:11:46 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l13DBdwN020338; Sat, 3 Feb 2007 06:11:42 -0700 (MST) Received: from [10.129.40.58] ([10.129.40.58]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l13DBcdM020990; Sat, 3 Feb 2007 07:11:39 -0600 (CST) Message-ID: <45C48A0A.1010301@motorola.com> Date: Sat, 03 Feb 2007 14:11:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JinHyeock Choi Subject: Re: [16NG] Re: traffic classification References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> In-Reply-To: <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 16ng@ietf.org, Pekka Savola X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org JinHyeock Choi wrote: > Alex > >>>> More specifically, what is the priority assigned to this >>>> service flow? ("traffic priority": sec 11.13.5 of 802.16-2004). >>>> This encoding has values from 0 to 7 with higher numbers >>>> indicating higher priority. If not the "traffic priority" >>>> value then what are the other service flow-specific constants >>>> that this IPv6 DSCP (diffserv codepoint) converts into. >>> >>> As of my knowledge, there is no rule to convert IPv6 DSCP >>> (diffserv codepoint) into 802.16 QoS parameter in a deterministic >>> way. I understand its up to the implementation & policy. >> >> Isn't this an interoperability issue? (between one's phone to one >> other's base station). > > I can't think of any but which, I admit, doesn't guarantee there > exists none. :-) JinHyeock, do you think there could have been an interoperability issue if rfc2464 didn't specify that ff02::1 was mapped into 33:33::1 (IP multicast address mapped into MAC multicast address)? Do you think that if my phone puts Traffic Class 001010 (Class 1 Low Drop Prec rfc2597) into 802.16 Unsolicited Grant Class forwarding class, but the AP expects Traffic Class 001010 to be on a 802.16 Best Effort forwarding class - there's no interoperability issue? I think there may be big interoperability issues. I agree though that these issues may be made much more relevant when they arise in deployments. Then we can try to document the issues, maybe as an upgrade to existing documents. Until then I'll continue putting whatever I want in my Traffic Class, ie what you call 'implementation and policy'. In this way we can agree :-) Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sun Feb 04 14:42:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDnFi-0005f6-4E; Sun, 04 Feb 2007 14:42:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDnFg-0005f0-Tj for 16ng@ietf.org; Sun, 04 Feb 2007 14:42:16 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDnFe-0000AQ-Gh for 16ng@ietf.org; Sun, 04 Feb 2007 14:42:16 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0C429198776; Sun, 4 Feb 2007 21:42:07 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 56ACE1986AF; Sun, 4 Feb 2007 21:42:04 +0200 (EET) Message-ID: <45C6370C.9090603@piuha.net> Date: Sun, 04 Feb 2007 14:42:04 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [16NG] Re: traffic classification References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> <45C48A0A.1010301@motorola.com> In-Reply-To: <45C48A0A.1010301@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org There are a couple of issues. The main technical question is whether host and base station need to be synchronized with respect to the CID etc that they use. For instance, if the host puts something in CID = X and the base station drops it because it felt that it should have travelled in CID = Y. If they need to be synchronized, then we can talk about whether that's something that should be left to policy or mandated in the standards. I think it is pretty obvious that we're not mandating what port numbers or address ranges should be treated in what way; that's a standard policy/qos filtering function. If you agree, then its not clear to me why DSCP is any different. The non-technical issue is whether the topic belongs to the IEEE or IETF standard. My thinking is that it should be an IETF function if and only if IP needs to do something for which there is no corresponding link layer functionality. For instance, we map multicast IP addresses to multicast L2 addresses because there is no L2 multicast address resolution function. In our 16ng case there appears to be a link layer function for mapping IP packets to CIDs. I don't know if that function is perfect or not, but it does seem to be an IEEE issue. Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sun Feb 04 15:57:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDoQc-0004W9-KV; Sun, 04 Feb 2007 15:57:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDoQb-0004Vz-Ds for 16ng@ietf.org; Sun, 04 Feb 2007 15:57:37 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDoQH-0004dc-IV for 16ng@ietf.org; Sun, 04 Feb 2007 15:57:37 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l14KvG3l028899; Sun, 4 Feb 2007 21:57:16 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l14KvGuX014594; Sun, 4 Feb 2007 21:57:16 +0100 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Feb 2007 21:57:16 +0100 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 Subject: RE: [16NG] Re: traffic classification Date: Sun, 4 Feb 2007 21:57:15 +0100 Message-ID: <4BB931F00625F54DA8B8563E5A5CA25A01347220@MCHP7I6A.ww002.siemens.net> In-Reply-To: <45C6370C.9090603@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Re: traffic classification Thread-Index: AcdIlNoiWbkOwr3gSi+Kz6glz1tU7gACERZA From: "Riegel, Maximilian" To: "Jari Arkko" , "Alexandru Petrescu" X-OriginalArrivalTime: 04 Feb 2007 20:57:16.0317 (UTC) FILETIME=[0D47FCD0:01C7489F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org The host is not aware of the CIDs. CIDs belong to the MAC layer, and it is the task of the convergence sublayer as upper part of the MAC layer to feed packets into CIDs according to filter rules. IEEE802.16 provides its own syntax for setting up filter rules. This syntax treats all header field the same way. IEEE802.16 is done, but it may be worth to consider in the IETF the definition of a generic way to specify filter rules for IP packets. The WiMAX Forum NWG has adopted the filter rule syntax of DIAMETER. So far it looks pretty sufficient. Bye Max -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Sunday, February 04, 2007 8:42 PM To: Alexandru Petrescu Cc: 16ng@ietf.org Subject: Re: [16NG] Re: traffic classification There are a couple of issues. The main technical question is whether host and base station need to be synchronized with respect to the CID etc that they use. For instance, if the host puts something in CID =3D X and the base station drops it because it felt that it should have travelled in CID =3D Y. If they need to be synchronized, then we can talk about whether that's something that should be left to policy or mandated in the standards. I think it is pretty obvious that we're not mandating what port numbers or address ranges should be treated in what way; that's a standard policy/qos filtering function. If you agree, then its not clear to me why DSCP is any different. The non-technical issue is whether the topic belongs to the IEEE or IETF standard. My thinking is that it should be an IETF function if and only if IP needs to do something for which there is no corresponding link layer functionality. For instance, we map multicast IP addresses to multicast L2 addresses because there is no L2 multicast address resolution function. In our 16ng case there appears to be a link layer function for mapping IP packets to CIDs. I don't know if that function is perfect or not, but it does seem to be an IEEE issue. Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sun Feb 04 20:11:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDsNU-0007e9-FV; Sun, 04 Feb 2007 20:10:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDsNS-0007Zb-LO for 16ng@ietf.org; Sun, 04 Feb 2007 20:10:38 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDsNO-00069b-UI for 16ng@ietf.org; Sun, 04 Feb 2007 20:10:38 -0500 Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JCY00DF5TXDWC@mailout2.samsung.com> for 16ng@ietf.org; Mon, 05 Feb 2007 10:10:25 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JCY00C67TXCZC@mmp2.samsung.com> for 16ng@ietf.org; Mon, 05 Feb 2007 10:10:24 +0900 (KST) Date: Mon, 05 Feb 2007 10:10:21 +0900 From: Daniel Park To: 16ng@ietf.org Message-id: <01a401c748c2$6a5af670$6dc6dba8@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [16NG] Draft Agenda in Prague X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Here is a draft agenda in prague. --- IP over IEEE 802.16 Networks Working Group (16ng) o 68th IETF - Prague, Czech Republic ======================================== AGENDA o #1 Timeslot 2 hours o 1520-1720 Monday March 19 o Afternoon Session II, Congress III 05 Administrator - Chairs - Blue sheets - Jabber scribe - Agenda bashing 05 Liaison report - IEEE 802.16 WG - DJ Johnston 60 IEEE 802.16 implication for 16ng - DJ Johnston - Abstract: IEEE 802.16 specifies a wireless communication standard with a variety MAC convergence sublayer options including ATM, IP, Ethernet and the in-development GPCS. This presentation describes the primary features and services of 802.16 systems with specific emphasis on the impact on the transport of IP and the work of the 16ng WG. 50 WiMAX Networking implication for 16ng - Max Riegel - Abstract: The Networking WG of the WiMAX Forum has defined a mobile radio access network architecture for providing IP connectivity over IEEE802.16/802.16e. The presentation shows the adoption of the work of the 16ng WG by the WiMAX network architecture putting emphasis on the implications coming out of the WiMAX network. o #2 Timeslot 2 hours o 1300-1500 Tuesday March 20 o Afternoon Session I, Grand Ballroom 10 Administrative - Chairs - Blue sheets - Jabber scribe - Agenda bashing - WG report 15 IPv6 transmission over IPv6CS - Basavaraj Patil - ID: draft-ietf-16ng- - Status: IESG Evaluation - GOAL: Clean up issues raised by reviewers 20 16ng problem statement - Junghoon Jee - ID: draft-ietf-16ng-ps-goals-00 - Status: Active WG Document - GOAL: Ready for IESG 30 IP over EthernetCS - Max Riegel - ID: draft-ietf-16ng-ip-over-ethernet-over-802.16-00 - Status: Active WG Document - GOAL: Ready for IESG 30 IPv4 over IPv4CS - Syam Madanapalli - ID: draft-madanapalli-16ng- - Status: Candidate WG Document - GOAL: WG Adoption 10 Using DHCPv6 and AAA Server for Mobile Station Prefix Delegation - Behcet Sarikaya - draft-sarikaya-16ng-prefix-delegation-01.txt - Status: Individual WG document - GOAL: Initial discussion 05 Closing - Chairs ===== 240 mins Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 04:34:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0EN-0005pG-3V; Mon, 05 Feb 2007 04:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0EL-0005pB-Le for 16ng@ietf.org; Mon, 05 Feb 2007 04:33:45 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE0EK-00088g-BN for 16ng@ietf.org; Mon, 05 Feb 2007 04:33:45 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1170668022!1017575!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9615 invoked from network); 5 Feb 2007 09:33:42 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 5 Feb 2007 09:33:42 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l159Xctt023898; Mon, 5 Feb 2007 02:33:38 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l159XXdJ018235; Mon, 5 Feb 2007 03:33:35 -0600 (CST) Message-ID: <45C6F9EB.6010007@motorola.com> Date: Mon, 05 Feb 2007 10:33:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Riegel, Maximilian" Subject: Re: [16NG] Re: traffic classification References: <4BB931F00625F54DA8B8563E5A5CA25A01347220@MCHP7I6A.ww002.siemens.net> In-Reply-To: <4BB931F00625F54DA8B8563E5A5CA25A01347220@MCHP7I6A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Riegel, Maximilian wrote: > The host is not aware of the CIDs. CIDs belong to the MAC layer, and > it is the task of the convergence sublayer as upper part of the MAC > layer to feed packets into CIDs according to filter rules. IEEE802.16 > provides its own syntax for setting up filter rules. This syntax > treats all header field the same way. Ok, I understand the principle. There are MAC filtering rules that match an IP packet to a CID. My question was about a specific value in Traffic Class field. > IEEE802.16 is done, Ah? This is something I'm not sure of. For example, a new corrigendum IEEE Std 802.16, Corrigendum 2 [Draft 2]) has been circulated among 802.16 members just a few days ago. (In my reading, there are some modifications that are relevant to the discussion around entry procedure, for example it now says that only for managed SSs the IP connectivity shall be performed over Secondary Management Connection; previously (802.16e-2005) it said that for any SS, not necessarily managed.) > but it may be worth to consider in the IETF the definition of a > generic way to specify filter rules for IP packets. The WiMAX Forum > NWG has adopted the filter rule syntax of DIAMETER. So far it looks > pretty sufficient. I think some monami6 WG drafts look at filtering rules, although not specific to particular link-layer (they're for filtering at HA and mobility). Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 04:48:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0SC-0004vw-Pn; Mon, 05 Feb 2007 04:48:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE0SC-0004ve-0J for 16ng@ietf.org; Mon, 05 Feb 2007 04:48:04 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE0SA-0002Kc-Lq for 16ng@ietf.org; Mon, 05 Feb 2007 04:48:03 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-153.messagelabs.com!1170668881!1417431!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19702 invoked from network); 5 Feb 2007 09:48:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-153.messagelabs.com with SMTP; 5 Feb 2007 09:48:01 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l159lvTV027462; Mon, 5 Feb 2007 02:48:01 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l159lsw5027067; Mon, 5 Feb 2007 03:47:55 -0600 (CST) Message-ID: <45C6FD49.1020501@motorola.com> Date: Mon, 05 Feb 2007 10:47:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [16NG] Re: traffic classification References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> <45C48A0A.1010301@motorola.com> <45C6370C.9090603@piuha.net> In-Reply-To: <45C6370C.9090603@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Jari Arkko wrote: > There are a couple of issues. The main technical question is whether > host and base station need to be synchronized with respect to the CID > etc that they use. For instance, if the host puts something in CID = > X and the base station drops it because it felt that it should have > travelled in CID = Y. If they need to be synchronized, then we can > talk about whether that's something that should be left to policy or > mandated in the standards. I think SS and BS need to be sync'ed about what traffic class they choose for what CIDs. Currently I think it should be mandated in standards that certain IPv6 Traffic Class DSCPs match to certain 802.16 Traffic Priority _or_ Service Class Name. > I think it is pretty obvious that we're not mandating what port > numbers or address ranges should be treated in what way; I agree. > that's a standard policy/qos filtering function. If you agree, then > its not clear to me why DSCP is any different. I think DSCP is a means to do exactly what 802.16MAC does, but at IP layer. An implementation that is written such to run over any link-layer but having the same QoS reservation behaviour can _only_ use DSCP. 802.16MAC could help such an implementation by following mapping rules recommendations. > The non-technical issue is whether the topic belongs to the IEEE or > IETF standard. My thinking is that it should be an IETF function if > and only if IP needs to do something for which there is no > corresponding link layer functionality. For instance, we map > multicast IP addresses to multicast L2 addresses because there is no > L2 multicast address resolution function. In our 16ng case there > appears to be a link layer function for mapping IP packets to CIDs. I > don't know if that function is perfect or not, but it does seem to > be an IEEE issue. For QoS, there exist no resolution function like ND or DNS that would resolve a DSCP into a 802.16 Traffic Priority. Remark I'm not talking about mapping an IPv6 Traffic Class DSCP into a CID but into a 802.16 Traffic Priority or a 802.16 Service Name. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 11:10:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6QN-0004ep-TE; Mon, 05 Feb 2007 11:10:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6QM-0004ec-Ik for 16ng@ietf.org; Mon, 05 Feb 2007 11:10:34 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6QL-0001LU-2t for 16ng@ietf.org; Mon, 05 Feb 2007 11:10:34 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15G854p003410; Mon, 5 Feb 2007 18:08:13 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 18:10:28 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 10:09:37 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Feb 2007 16:09:37 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 05 Feb 2007 10:12:12 -0600 Subject: Re: [16NG] Re: traffic classification From: Basavaraj Patil To: ext Jari Arkko , Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Re: traffic classification Thread-Index: AcdJQGS6o2HrTrUzEduL8AARJNUNiA== In-Reply-To: <45C6370C.9090603@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 16:09:37.0518 (UTC) FILETIME=[08A600E0:01C74940] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Hi Jari, Comments inline: On 2/4/07 1:42 PM, "ext Jari Arkko" wrote: > There are a couple of issues. The main technical question > is whether host and base station need to be synchronized > with respect to the CID etc that they use. For instance, if > the host puts something in CID = X and the base station > drops it because it felt that it should have travelled in > CID = Y. If they need to be synchronized, then we can > talk about whether that's something that should be > left to policy or mandated in the standards. An IP packet is processed by the IP specific part of the packet CS. On the uplink, the classification rules that are defined will map the packet to a service flow (Identified by Service flow ID). The service flow is mapped to a transport connection which is identified by a CID. The base-station when it receives the packet on the transport connection (CID) does not check against any classifiers. It simply sends it via the service flow (SFID) to its destination. Hence there is no check by the BS to see if the packet should have been received on CID =y instead of CID=x. On the downlink, it is the BS that applies the classification rules and maps a packet to a service flow/transport connection and the MS simply processes it. > I think it > is pretty obvious that we're not mandating what > port numbers or address ranges should be treated > in what way; that's a standard policy/qos filtering > function. If you agree, then its not clear to me why > DSCP is any different. Exactly.. IEEE 802.16 defines the fields of an IP/transport header that are used in the classification rules. It does not specify how to map DSCP to specific transport connections that may have different characteristics. And I do not believe we need to be defining DSCP to radio bearer type mappings either. > > The non-technical issue is whether the topic belongs > to the IEEE or IETF standard. My thinking is that > it should be an IETF function if and only if IP needs > to do something for which there is no corresponding > link layer functionality. For instance, we map multicast > IP addresses to multicast L2 addresses because there > is no L2 multicast address resolution function. In > our 16ng case there appears to be a link layer function > for mapping IP packets to CIDs. I don't know if that > function is perfect or not, but it does seem to be > an IEEE issue. I do not believe there is anything that the IETF needs to do at this time. IEEE has defined a identified a set of fields of the IP/transport header which are the basis for the classification rules for processing IP packets. For the purpose of mapping IP packets to specific transport connections, these are sufficient and we should let things be as they are, because I do not believe it is broken. -Raj > > Jari > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 11:27:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6gx-00078q-9F; Mon, 05 Feb 2007 11:27:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6gw-00078l-Qu for 16ng@ietf.org; Mon, 05 Feb 2007 11:27:42 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE6gv-00046g-ER for 16ng@ietf.org; Mon, 05 Feb 2007 11:27:42 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-153.messagelabs.com!1170692860!1482273!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19739 invoked from network); 5 Feb 2007 16:27:40 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-153.messagelabs.com with SMTP; 5 Feb 2007 16:27:40 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l15GRe1S021925; Mon, 5 Feb 2007 09:27:40 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l15GRa0B024211; Mon, 5 Feb 2007 10:27:37 -0600 (CST) Message-ID: <45C75AF7.7050403@motorola.com> Date: Mon, 05 Feb 2007 17:27:35 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Re: traffic classification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Hi again Raj, can I interfere here (again :-) Basically, care to suggest any other way to provide QoS-guarantees to an IP stack other than using DSCP and mapping it coherently on a MAC flow? If you do then ignore the below text... Basavaraj Patil wrote: > Hi Jari, > > Comments inline: > > > On 2/4/07 1:42 PM, "ext Jari Arkko" wrote: > >> There are a couple of issues. The main technical question is >> whether host and base station need to be synchronized with respect >> to the CID etc that they use. For instance, if the host puts >> something in CID = X and the base station drops it because it felt >> that it should have travelled in CID = Y. If they need to be >> synchronized, then we can talk about whether that's something that >> should be left to policy or mandated in the standards. > > An IP packet is processed by the IP specific part of the packet CS. > On the uplink, the classification rules that are defined will map the > packet to a service flow (Identified by Service flow ID). The > service flow is mapped to a transport connection which is identified > by a CID. The base-station when it receives the packet on the > transport connection (CID) does not check against any classifiers. It > simply sends it via the service flow (SFID) to its destination. > Hence there is no check by the BS to see if the packet should have > been received on CID =y instead of CID=x. On the downlink, it is the > BS that applies the classification rules and maps a packet to a > service flow/transport connection and the MS simply processes it. > >> I think it is pretty obvious that we're not mandating what port >> numbers or address ranges should be treated in what way; that's a >> standard policy/qos filtering function. If you agree, then its not >> clear to me why DSCP is any different. > > Exactly.. IEEE 802.16 defines the fields of an IP/transport header > that are used in the classification rules. It does not specify how to > map DSCP to specific transport connections that may have different > characteristics. Right, and it doesn't specify either how the DSCP maps to a Service Class Name, nor to a Traffic Priority. However, the whole goal of having a IP DSCP is to be able to map it into a qos-guaranteed flow on the first-hop and all subsequent hops. 802.16MAC does provide QoS-guarantees on flows for the first hop, so it looks like a great tool, why not using it. If not using this DSCP tool, then can you provide a suggestion how to provide QoS guarantees at IP layer for a stack running IPv6 over 802.16MAC? I think there's no other way, none that I know of. > And I do not believe we need to be defining DSCP to radio bearer type > mappings either. I think nobody mentioned Radio Bearer. I mentioned Service Class Name or Traffic Priority. There's no 802.16MAC rule that maps a particular IP DSCP (6leftmost bits of IPv6 Traffic Class) into a Class Name or Traffic Priority. >> The non-technical issue is whether the topic belongs to the IEEE or >> IETF standard. My thinking is that it should be an IETF function >> if and only if IP needs to do something for which there is no >> corresponding link layer functionality. For instance, we map >> multicast IP addresses to multicast L2 addresses because there is >> no L2 multicast address resolution function. In our 16ng case there >> appears to be a link layer function for mapping IP packets to >> CIDs. I don't know if that function is perfect or not, but it does >> seem to be an IEEE issue. > > I do not believe there is anything that the IETF needs to do at this > time. IEEE has defined a identified a set of fields of the > IP/transport header which are the basis for the classification rules > for processing IP packets. For the purpose of mapping IP packets to > specific transport connections, these are sufficient and we should > let things be as they are, because I do not believe it is broken. I think 802.16 defined classifiers but no contents. Filters and rules but not contents for these. But I agree with you it may be questionable whether it's the right time and place. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 11:42:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6vH-0006we-HD; Mon, 05 Feb 2007 11:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE6vF-0006wQ-Kz for 16ng@ietf.org; Mon, 05 Feb 2007 11:42:29 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE6vC-0006V1-Ui for 16ng@ietf.org; Mon, 05 Feb 2007 11:42:29 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id ACDD5198775; Mon, 5 Feb 2007 18:42:23 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A32E9198774; Mon, 5 Feb 2007 18:42:22 +0200 (EET) Message-ID: <45C75E6E.3040507@piuha.net> Date: Mon, 05 Feb 2007 11:42:22 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [16NG] Re: traffic classification References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> <45C48A0A.1010301@motorola.com> <45C6370C.9090603@piuha.net> <45C6FD49.1020501@motorola.com> In-Reply-To: <45C6FD49.1020501@motorola.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Alexandru, > > For QoS, there exist no resolution function like ND or DNS that would > resolve a DSCP into a 802.16 Traffic Priority. > > Remark I'm not talking about mapping an IPv6 Traffic Class DSCP into a > CID but into a 802.16 Traffic Priority or a 802.16 Service Name. > I browsed the relevant parts of 802.16 standards today. The standard clearly says that it has a capability to filter based on multiple fields in an IP packet, including the DSCP field. The standard also clearly says that the classification ensures the packet is delivered using the right QoS characteristics. I understand the desire to have an automatic mapping that operates without any configured policy. But in this case we clearly have functionality in the lower layer that is designed for the QoS purpose. We may disagree with that design. But it would be odd if the IETF added its own competing QoS mapping mechanisms on top of it. Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 12:45:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7uC-0008IJ-98; Mon, 05 Feb 2007 12:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7uB-0008I6-G3 for 16ng@ietf.org; Mon, 05 Feb 2007 12:45:27 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HE7u7-00015r-Rn for 16ng@ietf.org; Mon, 05 Feb 2007 12:45:27 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-3.tower-153.messagelabs.com!1170697522!1441937!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 4858 invoked from network); 5 Feb 2007 17:45:22 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-3.tower-153.messagelabs.com with SMTP; 5 Feb 2007 17:45:22 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l15HjMS8008880; Mon, 5 Feb 2007 10:45:22 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l15HjKwq016681; Mon, 5 Feb 2007 11:45:21 -0600 (CST) Message-ID: <45C76D2E.3060800@motorola.com> Date: Mon, 05 Feb 2007 18:45:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [16NG] Re: traffic classification References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> <45C0C057.5040402@motorola.com> <92e919fb0702011851v42ff4d03m76be205179a6cc43@mail.gmail.com> <45C30A7D.2050605@motorola.com> <92e919fb0702022132hc20a415k39ed496a111017f5@mail.gmail.com> <45C48A0A.1010301@motorola.com> <45C6370C.9090603@piuha.net> <45C6FD49.1020501@motorola.com> <45C75E6E.3040507@piuha.net> In-Reply-To: <45C75E6E.3040507@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Jari, it may be that the mappings are not yet clear. There seems to be no agreement on the necessity to map Traffic Class to certain 802.16 parameters. I agree. Maybe future work will look at these, if necessary. Jari Arkko wrote: > Alexandru, >> For QoS, there exist no resolution function like ND or DNS that >> would resolve a DSCP into a 802.16 Traffic Priority. >> >> Remark I'm not talking about mapping an IPv6 Traffic Class DSCP >> into a CID but into a 802.16 Traffic Priority or a 802.16 Service >> Name. >> > I browsed the relevant parts of 802.16 standards today. > > The standard clearly says that it has a capability to filter based on > multiple fields in an IP packet, including the DSCP field. Yes, absolutely, it does: > 802.16-2004 11.13.19.3.4.2 ...(DSCP)... > The values of the field specify the matching parameters for the IP > type of service/DSCP (rfc 2474) byte range and mask. An IP packet > with IP type of service (ToS) byte value "ip-tos" matches this > parameter if tos-low<=(ip-tos AND tos-mask)<=tos-high. If this field > is omitted, then comparison of the IP packet ToS byte for this entry > is irrelevant. I don't think there's any more DSCP-relevant text in 802.16-2004. Remark that (1) DSCP in Traffic Class is only 6bits and their values can't be ordered with semantics "lower to higher", DSCP is about selectors (2) last 2bits can be used for ECN (rfc3168), separately than the first 6bits. Thus classifying on contents with semantics like "a higher DSCP may need a higher bandwidth is not relevant. Also, there's no ToS byte in the IPv6 packet. > The standard also clearly says that the classification ensures the > packet is delivered using the right QoS characteristics. Can we state that ^ in the draft? Something like: 802.16MAC implementation ensures proper classification of packets whose IPv6 Traffic Class fields require a certain level of priority, bandwidth, latency. Once we put that in the draft and the draft becomes a RFC maybe one comment will be how actually that happens, because the spec doesn't say, or I don't seem to find that _how_. > I understand the desire to have an automatic mapping that operates > without any configured policy. But in this case we clearly have > functionality in the lower layer that is designed for the QoS > purpose. We may disagree with that design. But it would be odd if the > IETF added its own competing QoS mapping mechanisms on top of it. I don't find it odd, and I don't disagree with the MAC QoS design, it's necessary to have QoS mechanisms well adapted to the radio. And I also find it necessary for IP to take advantage of it. Traffic reservation with DSCP fields happens on the entire IP path, end-to-end. But the first-hop? DSCPs are IANA Assigned: http://www.iana.org/assignments/dscp-registry None of the IANA Assigned DSCP keywords (CS0-7, AF11-43, EF PHB) appear in the 802.16-2004 spec. That said, I agree that the mappings I'm proposing aren't yet tested. I haven't even proposed a concrete one. It may be too early to talk about it in this document. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 13:42:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8mx-0005CB-Ut; Mon, 05 Feb 2007 13:42:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8mx-0005C6-5b for 16ng@ietf.org; Mon, 05 Feb 2007 13:42:03 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8mu-0004u9-N3 for 16ng@ietf.org; Mon, 05 Feb 2007 13:42:03 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15IdS0g005693; Mon, 5 Feb 2007 20:39:50 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 20:40:57 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 12:40:54 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Feb 2007 18:40:54 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 05 Feb 2007 12:43:30 -0600 Subject: Re: [16NG] Re: traffic classification From: Basavaraj Patil To: ext Jari Arkko , Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Re: traffic classification Thread-Index: AcdJVYeixil1m7VIEdugIwARJNUNiA== In-Reply-To: <45C75E6E.3040507@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 18:40:54.0944 (UTC) FILETIME=[2B374A00:01C74955] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org On 2/5/07 10:42 AM, "ext Jari Arkko" wrote: > Alexandru, >> >> For QoS, there exist no resolution function like ND or DNS that would >> resolve a DSCP into a 802.16 Traffic Priority. >> >> Remark I'm not talking about mapping an IPv6 Traffic Class DSCP into a >> CID but into a 802.16 Traffic Priority or a 802.16 Service Name. >> > I browsed the relevant parts of 802.16 standards today. > > The standard clearly says that it has a capability to filter > based on multiple fields in an IP packet, including the DSCP > field. The standard also clearly says that the classification > ensures the packet is delivered using the right QoS > characteristics. > > I understand the desire to have an automatic mapping > that operates without any configured policy. But in > this case we clearly have functionality in the lower > layer that is designed for the QoS purpose. We may > disagree with that design. But it would be odd if the > IETF added its own competing QoS mapping mechanisms > on top of it. FWIW, I completely agree. -Raj > > Jari > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 16:05:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEB1u-0007ye-9S; Mon, 05 Feb 2007 16:05:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEB1t-0007yY-Lw for 16ng@ietf.org; Mon, 05 Feb 2007 16:05:37 -0500 Received: from vms046pub.verizon.net ([206.46.252.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEB1r-0000vH-Vf for 16ng@ietf.org; Mon, 05 Feb 2007 16:05:37 -0500 Received: from vms073.mailsrvcs.net ([192.168.1.2]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JD0009A2D9BHS31@vms046.mailsrvcs.net> for 16ng@ietf.org; Mon, 05 Feb 2007 15:05:35 -0600 (CST) Received: from 129.55.200.20 ([129.55.200.20]) by vms073.mailsrvcs.net (Verizon Webmail) with HTTP; Mon, 05 Feb 2007 15:05:35 -0600 (CST) Date: Mon, 05 Feb 2007 15:05:35 -0600 (CST) From: Tim Enos Subject: Re: [16NG] Re: traffic classification X-Originating-IP: [129.55.200.20] To: Jari Arkko , Alexandru Petrescu Message-id: <19174063.3261241170709535305.JavaMail.root@vms073.mailsrvcs.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Hi all, >From: Jari Arkko >Date: 2007/02/05 Mon AM 10:42:22 CST >To: Alexandru Petrescu >Cc: 16ng@ietf.org >Subject: Re: [16NG] Re: traffic classification >Alexandru, >> >> For QoS, there exist no resolution function like ND or DNS that would >> resolve a DSCP into a 802.16 Traffic Priority. >> >> Remark I'm not talking about mapping an IPv6 Traffic Class DSCP into a >> CID but into a 802.16 Traffic Priority or a 802.16 Service Name. >> >I browsed the relevant parts of 802.16 standards today. > >The standard clearly says that it has a capability to filter >based on multiple fields in an IP packet, including the DSCP >field. The standard also clearly says that the classification >ensures the packet is delivered using the right QoS >characteristics. > >I understand the desire to have an automatic mapping >that operates without any configured policy. But in >this case we clearly have functionality in the lower >layer that is designed for the QoS purpose. We may >disagree with that design. But it would be odd if the >IETF added its own competing QoS mapping mechanisms >on top of it. It seems that how to perform an automatic mapping (of an IPv6 Traffic Class value to a particular scheduling service) would be beyond the scope of the IEEE 802.16 standard. The text from which I derive that impression is in 6.3.14.7 which states in part: "The provisioning of service flows is done via means outside the scope of this standard, such as the network managment system." Not sure, but I'd figure we'd not try to define such an automatic mapping (in this draft at least). As an aside, it seems to me that traffic which would at the network layer be marked with Traffic Class EF (RFC 2598) (e.g. VoIP) could likely be traffic that would also be provisioned with a UGS service flow (6.3.5.2.1). In terms of priority, it seems the only scheduling service that requires the Traffic Priority QoS parameter (11.13.5) is nrtPS (6.3.5). Respectfully, Tim Enos Rom 8:28 > >Jari > > >_______________________________________________ >16NG mailing list >16NG@ietf.org >https://www1.ietf.org/mailman/listinfo/16ng _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 05 17:34:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HECPh-0005I9-30; Mon, 05 Feb 2007 17:34:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HECPg-0005Hd-Ir for 16ng@ietf.org; Mon, 05 Feb 2007 17:34:16 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HECPe-0002lh-UT for 16ng@ietf.org; Mon, 05 Feb 2007 17:34:16 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l15MVr6J004123; Tue, 6 Feb 2007 00:31:54 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 00:33:24 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 16:33:22 -0600 Received: from 10.162.253.253 ([10.162.253.253]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Mon, 5 Feb 2007 22:33:21 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 05 Feb 2007 16:35:56 -0600 Subject: Re: [16NG] Re: traffic classification From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Re: traffic classification Thread-Index: AcdJdgAZPsKRULVpEdukTAARJNUNiA== In-Reply-To: <45C75AF7.7050403@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 22:33:22.0112 (UTC) FILETIME=[A4603C00:01C74975] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070206003154-0EBA8BB0-13CD679F/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Hi Alex, Inline: On 2/5/07 10:27 AM, "ext Alexandru Petrescu" wrote: > Hi again Raj, can I interfere here (again :-) Not a problem ;) > > Basically, care to suggest any other way to provide QoS-guarantees to an > IP stack other than using DSCP and mapping it coherently on a MAC flow? First of all you have to realize that QoS is applicable primarily to the air interface in the scope of this discussion. The ability to map IP sessions to transport connections of various types (defined by IEEE, i.e uGS, rtPS, nrtPS etc.) is not just via DSCP. While DSCP may be intended for such purposes, it is not the only way. An API to the 802.16 MAC layer may/will be provided that will enable applications to request various types of transport connections with QoS characteristics. The API can provide mapping of IP sessions to specific QoS enabled transport connections based on the fact such as the codec type, RTP being used, transport header, port numbers or IP addresses. In such a scenario the classification rules would not need to look at DSCP to figure out which transport connection to send the packets over. DSCP is not the only means of guaranteeing that a packet be sent via a specific transport connection. > > If you do then ignore the below text... So I guess, I can ignore the rest of the text below... :) -Raj > > Basavaraj Patil wrote: >> Hi Jari, >> >> Comments inline: >> >> >> On 2/4/07 1:42 PM, "ext Jari Arkko" wrote: >> >>> There are a couple of issues. The main technical question is >>> whether host and base station need to be synchronized with respect >>> to the CID etc that they use. For instance, if the host puts >>> something in CID = X and the base station drops it because it felt >>> that it should have travelled in CID = Y. If they need to be >>> synchronized, then we can talk about whether that's something that >>> should be left to policy or mandated in the standards. >> >> An IP packet is processed by the IP specific part of the packet CS. >> On the uplink, the classification rules that are defined will map the >> packet to a service flow (Identified by Service flow ID). The >> service flow is mapped to a transport connection which is identified >> by a CID. The base-station when it receives the packet on the >> transport connection (CID) does not check against any classifiers. It >> simply sends it via the service flow (SFID) to its destination. >> Hence there is no check by the BS to see if the packet should have >> been received on CID =y instead of CID=x. On the downlink, it is the >> BS that applies the classification rules and maps a packet to a >> service flow/transport connection and the MS simply processes it. >> >>> I think it is pretty obvious that we're not mandating what port >>> numbers or address ranges should be treated in what way; that's a >>> standard policy/qos filtering function. If you agree, then its not >>> clear to me why DSCP is any different. >> >> Exactly.. IEEE 802.16 defines the fields of an IP/transport header >> that are used in the classification rules. It does not specify how to >> map DSCP to specific transport connections that may have different >> characteristics. > > Right, and it doesn't specify either how the DSCP maps to a Service > Class Name, nor to a Traffic Priority. > > However, the whole goal of having a IP DSCP is to be able to map it into > a qos-guaranteed flow on the first-hop and all subsequent hops. > 802.16MAC does provide QoS-guarantees on flows for the first hop, so it > looks like a great tool, why not using it. > > If not using this DSCP tool, then can you provide a suggestion how to > provide QoS guarantees at IP layer for a stack running IPv6 over > 802.16MAC? I think there's no other way, none that I know of. > >> And I do not believe we need to be defining DSCP to radio bearer type >> mappings either. > > I think nobody mentioned Radio Bearer. I mentioned Service Class Name > or Traffic Priority. There's no 802.16MAC rule that maps a particular > IP DSCP (6leftmost bits of IPv6 Traffic Class) into a Class Name or > Traffic Priority. > >>> The non-technical issue is whether the topic belongs to the IEEE or >>> IETF standard. My thinking is that it should be an IETF function >>> if and only if IP needs to do something for which there is no >>> corresponding link layer functionality. For instance, we map >>> multicast IP addresses to multicast L2 addresses because there is >>> no L2 multicast address resolution function. In our 16ng case there >>> appears to be a link layer function for mapping IP packets to >>> CIDs. I don't know if that function is perfect or not, but it does >>> seem to be an IEEE issue. >> >> I do not believe there is anything that the IETF needs to do at this >> time. IEEE has defined a identified a set of fields of the >> IP/transport header which are the basis for the classification rules >> for processing IP packets. For the purpose of mapping IP packets to >> specific transport connections, these are sufficient and we should >> let things be as they are, because I do not believe it is broken. > > I think 802.16 defined classifiers but no contents. Filters and rules > but not contents for these. > > But I agree with you it may be questionable whether it's the right time > and place. > > Alex > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Feb 08 19:17:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJRw-0006d7-FU; Thu, 08 Feb 2007 19:17:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJRu-0006bL-ME for 16ng@ietf.org; Thu, 08 Feb 2007 19:17:10 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJRt-0003aH-8u for 16ng@ietf.org; Thu, 08 Feb 2007 19:17:10 -0500 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JD600ICY64AOK@mailout3.samsung.com> for 16ng@ietf.org; Fri, 09 Feb 2007 09:16:58 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JD600E0V64AV0@mmp2.samsung.com> for 16ng@ietf.org; Fri, 09 Feb 2007 09:16:58 +0900 (KST) Date: Fri, 09 Feb 2007 09:16:40 +0900 From: Daniel Park To: 16ng@ietf.org Message-id: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org IPv4CS document is now available at: http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Feb 09 06:39:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFU64-0002LQ-MN; Fri, 09 Feb 2007 06:39:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFU63-0002LJ-51 for 16ng@ietf.org; Fri, 09 Feb 2007 06:39:19 -0500 Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFU61-0001Qz-M9 for 16ng@ietf.org; Fri, 09 Feb 2007 06:39:19 -0500 Received: from [10.3.1.109] (din-cisuc109.dei.uc.pt [10.3.1.109]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l19BaSiO021601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Feb 2007 11:36:31 GMT Message-ID: <45CC5CBB.4040103@dei.uc.pt> Date: Fri, 09 Feb 2007 11:36:27 +0000 From: Bruno Miguel Sousa User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: 16ng@ietf.org Subject: Re: [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt References: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61> In-Reply-To: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-51.8, required 3, autolearn=not spam, ALL_TRUSTED -1.80, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: bmsousa@dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Dears Here is my contribution to this draft. General comments: I think the text is well written and easy to understand. The overall operations of IPv4 (address assignment, multicast, ...) are presented in the document. Specific comments: 1) The sentences in the abstract: " access. IEEE has specified several service specific convergence sublayers (CS) for 802.16 which are used by upper layer protocols. The ATM CS and Packet CS are the two main service-specific convergence sublayers and these are a part of the 802.16 MAC which the upper layers interface to. " I suggest to rewrite since 802.16 defines two service specific convergence sublayers. The term several does not seem correct imho. The sentences present some repetition when referring to upper layers. My suggestion: IEEE has specified the service specific convergence sublayers (CS) in the 802.16 MAC to be used by upper layer protocols. The ATM CS and the Packet CS represent the two main service specific convergence sublayers for 802.16. 2) Some minor corrections. " Unit (MTU) and address assignment procedures for transmitting _IPv4_ packets over IP Convergence Sublayer (IPCS) of IEEE 802.16. This " " be sent to MSs before they acquire IP addresses. The figure below illustrates the network _architecture_. " IPv4 and not IPv6 " _IPv4_ packets are transmitted in Generic 802.16 MAC frames as shown in the following figure. " remove: is " must be established. This connection _is_ consists of 802.16 MAC transport connection between MS and BS and an L2 tunnel between BS and AR. " remove being " connection to the AR. BS reconstructs the payload header if the PHS is in use before _being_ the packet is tunneled to the AR. " 3) Section Maximum Transmission Unit The value of 2038 is justified in the text. In my opinion it is important to add references to justify the values 1920 and 576. For instance for the 576 value I would add a reference to the RFC 1122 to present the effective MTU to receive. Kindly, Bruno Sousa Daniel Park wrote: > IPv4CS document is now available at: > http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Feb 09 17:41:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeQi-0006ZU-2E; Fri, 09 Feb 2007 17:41:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeQh-0006ZK-7G for 16ng@ietf.org; Fri, 09 Feb 2007 17:41:19 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFeQd-0006Qv-PC for 16ng@ietf.org; Fri, 09 Feb 2007 17:41:19 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l19Mf81F014325; Fri, 9 Feb 2007 16:41:08 -0600 (CST) Received: from ILEXC2U02.ndc.lucent.com ([135.3.39.9]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 16:41:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt Date: Fri, 9 Feb 2007 16:41:07 -0600 Message-ID: <61B0DCC9767CDC4C91769592B12CCDD133A63F@ILEXC2U02.ndc.lucent.com> In-Reply-To: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt Thread-Index: AcdL3+NIkEo7RK6VSl+ERehzqYbNqQAuqK9Q References: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61> From: "Narvaez, Paolo \(Paolo\)" To: "Daniel Park" , <16ng@ietf.org> X-OriginalArrivalTime: 09 Feb 2007 22:41:08.0577 (UTC) FILETIME=[64102510:01C74C9B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org I have two general comments on this draft. 1. Section 7 assumes that ARP messages sent by the MS are received by the AR. The section states that ARP messages should be dropped by the AR. However, since ARP runs directly over Ethernet (there is no IP header) how can the 802.16 IPCS carry this type of packet over the air? 2. What is the subnet assignment? Can two MSs be on the same subnet? Or do we need to introduce some restrictions as in the IPv6-over-802.16 draft. Regards, Paolo =20 > -----Original Message----- > From: Daniel Park [mailto:soohong.park@samsung.com]=20 > Sent: Thursday, February 08, 2007 7:17 PM > To: 16ng@ietf.org > Subject: [16NG] Fw:=20 > I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt >=20 > IPv4CS document is now available at: > http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv > 4-over-802-dot-16-ipcs-00.txt >=20 > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. >=20 > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng >=20 _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sat Feb 10 00:52:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFl8j-00045S-8M; Sat, 10 Feb 2007 00:51:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFl8h-00045H-7U for 16ng@ietf.org; Sat, 10 Feb 2007 00:51:11 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFl8f-0007jY-SA for 16ng@ietf.org; Sat, 10 Feb 2007 00:51:11 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1457297nfa for <16ng@ietf.org>; Fri, 09 Feb 2007 21:51:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PfNKC63M1A9mXlPfpPMTXQiqWvEl/T2+sw/nGnktA/+0PxSPULqmEnbA9RIRCx2MWN6CUPDdk1+eW5ZJtaFgFu/VP0/gNUaFKHj+YhY9wDSr1neS2GmCjK2ASp9ylRsLWCoGSDeAE31izghx/DEweA9RomWO799JcSRzu78M/ZM= Received: by 10.49.65.15 with SMTP id s15mr2124270nfk.1171086668975; Fri, 09 Feb 2007 21:51:08 -0800 (PST) Received: by 10.49.92.12 with HTTP; Fri, 9 Feb 2007 21:51:08 -0800 (PST) Message-ID: <10e14db20702092151s2fa09fbevb5075206a52b1904@mail.gmail.com> Date: Sat, 10 Feb 2007 11:21:08 +0530 From: "Syam Madanapalli" To: "Bruno Miguel Sousa" Subject: Re: [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt In-Reply-To: <45CC5CBB.4040103@dei.uc.pt> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61> <45CC5CBB.4040103@dei.uc.pt> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Thanks Burno for the comments. On 2/9/07, Bruno Miguel Sousa wrote: > Dears > > > Here is my contribution to this draft. > > General comments: > > I think the text is well written and easy to understand. > The overall operations of IPv4 (address assignment, multicast, ...) > are presented in the document. > > > Specific comments: > > 1) > The sentences in the abstract: > " > access. IEEE has specified several service specific convergence > sublayers (CS) for 802.16 which are used by upper layer protocols. > The ATM CS and Packet CS are the two main service-specific > convergence sublayers and these are a part of the 802.16 MAC which > the upper layers interface to. > " > I suggest to rewrite since 802.16 defines two service specific > convergence sublayers. > The term several does not seem correct imho. The sentences present some > repetition > when referring to upper layers. My suggestion: > > IEEE has specified the service specific convergence sublayers (CS) > in the 802.16 MAC to be used by upper layer protocols. > The ATM CS and the Packet CS represent the two main > service specific convergence sublayers for 802.16. Yes, I will make this change in the next revision. > > 2) > Some minor corrections. > " > Unit (MTU) and address assignment procedures for transmitting _IPv4_ > packets over IP Convergence Sublayer (IPCS) of IEEE 802.16. This > " > > " > be sent to MSs before they acquire IP addresses. The figure below > illustrates the network _architecture_. > " > > IPv4 and not IPv6 > " > _IPv4_ packets are transmitted in Generic 802.16 MAC frames as shown in > the following figure. > " > > remove: is > " > must be established. This connection _is_ consists of 802.16 MAC > transport connection between MS and BS and an L2 tunnel between BS > and AR. > " > > remove being > " > connection to the AR. BS reconstructs the payload header if the PHS > is in use before _being_ the packet is tunneled to the AR. > " > OK. Thanks. > > 3) > Section Maximum Transmission Unit > The value of 2038 is justified in the text. > In my opinion it is important to add references to justify the values > 1920 and 576. > > For instance for the 576 value I would add a reference to the RFC 1122 > to present the effective MTU to receive. OK. I will add this reference. Regards, Syam > > > > Kindly, > Bruno Sousa > > > Daniel Park wrote: > > IPv4CS document is now available at: > > http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > Daniel (Soohong Daniel Park) > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > _______________________________________________ > > 16NG mailing list > > 16NG@ietf.org > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sat Feb 10 01:34:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFlow-0006iO-IY; Sat, 10 Feb 2007 01:34:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFlou-0006ha-Qy for 16ng@ietf.org; Sat, 10 Feb 2007 01:34:48 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFlot-0007qS-GD for 16ng@ietf.org; Sat, 10 Feb 2007 01:34:48 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1469260nfa for <16ng@ietf.org>; Fri, 09 Feb 2007 22:34:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EbUiPwCoDm5qc4dx1iMptBuPK6cDeR3DC3KvmKu/AYh6i3kYByLrQa2DfQxIWwEXm5y8VgnphilCMW6mnlv1vONVtTuTPGVfw5ijQIs0AyLxwPOcDejaeYejO/sTSWCwLnYayxe7PxfmOEwLD980VzCL6QKh7a4pFvteJ+KsKAE= Received: by 10.49.65.15 with SMTP id s15mr2156782nfk.1171089286775; Fri, 09 Feb 2007 22:34:46 -0800 (PST) Received: by 10.49.92.12 with HTTP; Fri, 9 Feb 2007 22:34:46 -0800 (PST) Message-ID: <10e14db20702092234k32ff9a01u376d72f655779f15@mail.gmail.com> Date: Sat, 10 Feb 2007 12:04:46 +0530 From: "Syam Madanapalli" To: "Narvaez, Paolo (Paolo)" Subject: Re: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt In-Reply-To: <61B0DCC9767CDC4C91769592B12CCDD133A63F@ILEXC2U02.ndc.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61> <61B0DCC9767CDC4C91769592B12CCDD133A63F@ILEXC2U02.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Hi Paolo, On 2/10/07, Narvaez, Paolo (Paolo) wrote: > > I have two general comments on this draft. > > 1. Section 7 assumes that ARP messages sent by the MS are received by > the AR. The section states that ARP messages should be dropped by the > AR. However, since ARP runs directly over Ethernet (there is no IP > header) how can the 802.16 IPCS carry this type of packet over the air? As mentioned the draft, ARP is not required for 802.16 because of the fact that the MAC address is not required for identifying the destination. There was a concern that an unmodified host may send ARP without knowing that the underlying interface is 802.16, because of this I added the above statement. If we think there is no such possibility, then I will remove this text. > > 2. What is the subnet assignment? Can two MSs be on the same subnet? Or > do we need to introduce some restrictions as in the IPv6-over-802.16 > draft. The draft assumes the p2p link, so no two MSs can be on the same subnet. Thanks, Syam > > Regards, > Paolo > > > > > > -----Original Message----- > > From: Daniel Park [mailto:soohong.park@samsung.com] > > Sent: Thursday, February 08, 2007 7:17 PM > > To: 16ng@ietf.org > > Subject: [16NG] Fw: > > I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > IPv4CS document is now available at: > > http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv > > 4-over-802-dot-16-ipcs-00.txt > > > > Daniel (Soohong Daniel Park) > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > _______________________________________________ > > 16NG mailing list > > 16NG@ietf.org > > https://www1.ietf.org/mailman/listinfo/16ng > > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sun Feb 11 20:20:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGPrX-0008Ro-I4; Sun, 11 Feb 2007 20:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGPrV-0008LZ-SV for 16ng@ietf.org; Sun, 11 Feb 2007 20:20:09 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGPrT-00063D-Sz for 16ng@ietf.org; Sun, 11 Feb 2007 20:20:09 -0500 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JDB0025XT16XD@mailout1.samsung.com> for 16ng@ietf.org; Mon, 12 Feb 2007 10:19:54 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JDB00CH7T15VE@mmp2.samsung.com> for 16ng@ietf.org; Mon, 12 Feb 2007 10:19:53 +0900 (KST) Date: Mon, 12 Feb 2007 10:19:52 +0900 From: Daniel Park To: 16ng@ietf.org Message-id: <012101c74e43$e6587280$6dc6dba8@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [16NG] 16ng session schedule (Monday & Friday) X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org The meeting schedule is modified: MONDAY, March 19, 2007 1520-1720 Afternoon Session II Congress I INT 16ng IP over IEEE 802.16 Networks WG FRIDAY, March 23, 2007 0900-1130 Morning Session I Congress I INT 16ng IP over IEEE 802.16 Networks WG Note: Please be sure your journey. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Feb 12 14:19:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGghh-000636-Gp; Mon, 12 Feb 2007 14:19:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGghg-00062n-87 for 16ng@ietf.org; Mon, 12 Feb 2007 14:19:08 -0500 Received: from web60323.mail.yahoo.com ([209.73.178.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGghe-0008Ij-Qg for 16ng@ietf.org; Mon, 12 Feb 2007 14:19:08 -0500 Received: (qmail 74977 invoked by uid 60001); 12 Feb 2007 19:19:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=oSRY7g+HTIQp5c630zZD7KVldWua8lR+kUDI840B8cTLl2ye3s8jFQDduaWNwWJZsMtfy0fMjCcdyeRQFG7gMbLebIoHfXiWf6bq6h13FS9ndetty7kA5/i2QvvFy4U8pH/7t6QkV6THeB1ONtaV9IdU0wMZTrCEUbtbwTaaNNQ=; X-YMail-OSG: 82JP724VM1nkh.m7yEdC41ldPBq_gGedqedUU1nPZNWrOflXsiMp7iO60EMDyhpjgQ-- Received: from [206.16.17.212] by web60323.mail.yahoo.com via HTTP; Mon, 12 Feb 2007 11:19:06 PST X-Mailer: YahooMailRC/368.7 YahooMailWebService/0.6.132.7 Date: Mon, 12 Feb 2007 11:19:06 -0800 (PST) From: Behcet Sarikaya Subject: Re: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt To: Syam Madanapalli MIME-Version: 1.0 Message-ID: <583400.71141.qm@web60323.mail.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1489627094==" Errors-To: 16ng-bounces@ietf.org --===============1489627094== Content-Type: multipart/alternative; boundary="0-1518751048-1171307946=:71141" --0-1518751048-1171307946=:71141 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Syam,=0A You mentioned P2P link here in this message but I could not se= e any text on this in the draft. Maybe a section should be added on the add= ress and subnet mask assignment given the P2P nature of the link and the fa= ct that such assignments are not commonly used.=0A You recommended AR to i= gnore ARP Requests from MS, I am not sure if this is OK or a Reply would be= needed according to ARP?=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Original = Message ----=0AFrom: Syam Madanapalli =0ATo: "Narva= ez, Paolo (Paolo)" =0ACc: 16ng@ietf.org=0ASent: S= aturday, February 10, 2007 12:34:46 AM=0ASubject: Re: [16NG] Fw: I-DACTION:= draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt=0A=0A=0AHi Paolo,= =0A=0AOn 2/10/07, Narvaez, Paolo (Paolo) wrote:= =0A>=0A> I have two general comments on this draft.=0A>=0A> 1. Section 7 as= sumes that ARP messages sent by the MS are received by=0A> the AR. The sect= ion states that ARP messages should be dropped by the=0A> AR. However, sinc= e ARP runs directly over Ethernet (there is no IP=0A> header) how can the 8= 02.16 IPCS carry this type of packet over the air?=0A=0AAs mentioned the dr= aft, ARP is not required for 802.16 because of the fact=0Athat the MAC addr= ess is not required for identifying the destination.=0AThere was a concern = that an unmodified host may send ARP without knowing=0Athat the underlying = interface is 802.16, because of this I added the=0Aabove statement.=0A=0AIf= we think there is no such possibility, then I will remove this text.=0A=0A= >=0A> 2. What is the subnet assignment? Can two MSs be on the same subnet? = Or=0A> do we need to introduce some restrictions as in the IPv6-over-802.16= =0A> draft.=0A=0AThe draft assumes the p2p link, so no two MSs can be on th= e same subnet.=0A=0AThanks,=0ASyam=0A=0A>=0A> Regards,=0A> Paolo=0A>=0A>=0A= >=0A>=0A> > -----Original Message-----=0A> > From: Daniel Park [mailto:sooh= ong.park@samsung.com]=0A> > Sent: Thursday, February 08, 2007 7:17 PM=0A> >= To: 16ng@ietf.org=0A> > Subject: [16NG] Fw:=0A> > I-DACTION:draft-madanapa= lli-16ng-ipv4-over-802-dot-16-ipcs-00.txt=0A> >=0A> > IPv4CS document is no= w available at:=0A> > http://www.ietf.org/internet-drafts/draft-madanapalli= -16ng-ipv=0A> > 4-over-802-dot-16-ipcs-00.txt=0A> >=0A> > Daniel (Soohong D= aniel Park)=0A> > Mobile Convergence Laboratory, SAMSUNG Electronics.=0A> >= =0A> > _______________________________________________=0A> > 16NG mailing l= ist=0A> > 16NG@ietf.org=0A> > https://www1.ietf.org/mailman/listinfo/16ng= =0A> >=0A>=0A> _______________________________________________=0A> 16NG mai= ling list=0A> 16NG@ietf.org=0A> https://www1.ietf.org/mailman/listinfo/16ng= =0A>=0A=0A_______________________________________________=0A16NG mailing li= st=0A16NG@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/16ng --0-1518751048-1171307946=:71141 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Syam,
=0A
  You mentioned P= 2P link here in this message but I could not see any text on this in the dr= aft. Maybe a section should be added on the address and subnet mask assignm= ent given the P2P nature of the link and the fact that such assignments are= not commonly used.
=0A
  You recommended AR to ignore A= RP Requests from MS, I am not sure if this is OK or a Reply would be needed= according to ARP?
=0A
 
=0A
Regards,=0A
 
=0A
Behcet

=0A
---= -- Original Message ----
From: Syam Madanapalli <smadanapalli@gmail.c= om>
To: "Narvaez, Paolo (Paolo)" <paolo@alcatel-lucent.com>
= Cc: 16ng@ietf.org
Sent: Saturday, February 10, 2007 12:34:46 AM
Subje= ct: Re: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ip= cs-00.txt

=0A
Hi Paolo,

On 2/10/07, Narvaez, Paolo (Paolo= ) <paolo@alcatel-lucent.com> wrote:
>
> I have two genera= l comments on this draft.
>
> 1. Section 7 assumes that ARP mes= sages sent by the MS are received by
> the AR. The section states tha= t ARP messages should be dropped by the
> AR. However, since ARP runs= directly over Ethernet (there is no IP
> header) how can the 802.16 = IPCS carry this type of packet over the air?

As mentioned the draft,= ARP is not required for 802.16 because of the fact
that the MAC address= is not required for identifying the destination.
There was a concern th= at an unmodified host may send ARP without knowing
that the underlying i= nterface is 802.16, because of this I added the
above statement.

= If we think there is no such possibility, then I will remove this text.
=
>
> 2. What is the subnet assignment? Can two MSs be on the sa= me subnet? Or
> do we need to introduce some restrictions as in the IPv6-over-802.16
> draft.
The draft assumes the p2p link, so no two MSs can be on the same subn= et.

Thanks,
Syam

>
> Regards,
> Paolo
&g= t;
>
>
>
> > -----Original Message-----
> = > From: Daniel Park [mailto:soohong.park@samsung.com]
> > Sent:= Thursday, February 08, 2007 7:17 PM
> > To: 16ng@ietf.org
>= > Subject: [16NG] Fw:
> > I-DACTION:draft-madanapalli-16ng-ipv= 4-over-802-dot-16-ipcs-00.txt
> >
> > IPv4CS document is = now available at:
> > http://www.ietf.org/internet= -drafts/draft-madanapalli-16ng-ipv
> > 4-over-802-dot-16-ipcs-= 00.txt
> >
> > Daniel (Soohong Daniel Park)
> > = Mobile Convergence Laboratory, SAMSUNG Electronics.
> >
> &g= t; _______________________________________________
> > 16NG mailing = list
> > 16NG@ietf.org
> > https://www1.ietf.org/mailman/lis= tinfo/16ng
> >
>
> _______________________________= ________________
> 16NG mailing list
> 16NG@ietf.org
> https= ://www1.ietf.org/mailman/listinfo/16ng
>

_________________= ______________________________
16NG mailing list
16NG@ietf.org
https:= //www1.ietf.org/mailman/listinfo/16ng
=0A

--0-1518751048-1171307946=:71141-- --===============1489627094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng --===============1489627094==-- From 16ng-bounces@ietf.org Mon Feb 12 15:06:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGhRe-0006bR-2m; Mon, 12 Feb 2007 15:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGhRd-0006bC-J6 for 16ng@ietf.org; Mon, 12 Feb 2007 15:06:37 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGhRb-0008P2-V4 for 16ng@ietf.org; Mon, 12 Feb 2007 15:06:37 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1CK6QLX024389; Mon, 12 Feb 2007 14:06:27 -0600 (CST) Received: from ILEXC2U02.ndc.lucent.com ([135.3.39.9]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:06:26 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [16NG] Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt Date: Mon, 12 Feb 2007 14:06:26 -0600 Message-ID: <61B0DCC9767CDC4C91769592B12CCDD136EB4A@ILEXC2U02.ndc.lucent.com> In-Reply-To: <583400.71141.qm@web60323.mail.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt Thread-Index: AcdO2tpZFEK2z8YXRCCYHLOgT5+lZwAAqLdQ References: <583400.71141.qm@web60323.mail.yahoo.com> From: "Narvaez, Paolo \(Paolo\)" To: "Behcet Sarikaya" , "Syam Madanapalli" X-OriginalArrivalTime: 12 Feb 2007 20:06:26.0856 (UTC) FILETIME=[46F72A80:01C74EE1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0015834325==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============0015834325== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74EE1.46A764EB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74EE1.46A764EB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 How can the MS and AR send ARP requests and responses to each other? These ARP messages have to go over IPCS and there is no IP packet in this case. =20 If there is concern for a legacy IPv4 stack at the MS sending ARP requests and perhaps even requiring ARP responses, why not recommend a shim layer between the IPv4 stack and the 802.16 IPCS layer at the MS. This layer would filter ARP requests arriving from the IPv4 stack and respond with any MAC address. The IPCS classifier should never see ARP messages, and they should never be sent over the air. =20 Regards, Paolo ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Monday, February 12, 2007 2:19 PM To: Syam Madanapalli Cc: 16ng@ietf.org Subject: Re: [16NG] Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt =09 =09 Hi Syam, You mentioned P2P link here in this message but I could not see any text on this in the draft. Maybe a section should be added on the address and subnet mask assignment given the P2P nature of the link and the fact that such assignments are not commonly used. You recommended AR to ignore ARP Requests from MS, I am not sure if this is OK or a Reply would be needed according to ARP? =20 Regards, =20 Behcet =09 =09 ----- Original Message ---- From: Syam Madanapalli To: "Narvaez, Paolo (Paolo)" Cc: 16ng@ietf.org Sent: Saturday, February 10, 2007 12:34:46 AM Subject: Re: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt =09 =09 Hi Paolo, =09 On 2/10/07, Narvaez, Paolo (Paolo) wrote: > > I have two general comments on this draft. > > 1. Section 7 assumes that ARP messages sent by the MS are received by > the AR. The section states that ARP messages should be dropped by the > AR. However, since ARP runs directly over Ethernet (there is no IP > header) how can the 802.16 IPCS carry this type of packet over the air? =09 As mentioned the draft, ARP is not required for 802.16 because of the fact that the MAC address is not required for identifying the destination. There was a concern that an unmodified host may send ARP without knowing that the underlying interface is 802.16, because of this I added the above statement. =09 If we think there is no such possibility, then I will remove this text. =09 > > 2. What is the subnet assignment? Can two MSs be on the same subnet? Or > do we need to introduce some restrictions as in the IPv6-over-802.16 > draft. =09 The draft assumes the p2p link, so no two MSs can be on the same subnet. =09 Thanks, Syam =09 > > Regards, > Paolo > > > > > > -----Original Message----- > > From: Daniel Park [mailto:soohong.park@samsung.com] > > Sent: Thursday, February 08, 2007 7:17 PM > > To: 16ng@ietf.org > > Subject: [16NG] Fw: > > I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > IPv4CS document is now available at: > > http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv > > 4-over-802-dot-16-ipcs-00.txt > > > > Daniel (Soohong Daniel Park) > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > _______________________________________________ > > 16NG mailing list > > 16NG@ietf.org > > https://www1.ietf.org/mailman/listinfo/16ng > > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > =09 _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng ------_=_NextPart_001_01C74EE1.46A764EB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
How can the MS and AR send ARP requests and = responses to=20 each other? These ARP messages have to go over IPCS and there is no IP = packet in=20 this case.
 
If there is concern for a legacy IPv4 stack at = the MS=20 sending ARP requests and perhaps even requiring ARP responses, why not=20 recommend a shim layer between the IPv4 stack and the = 802.16 IPCS layer=20 at the MS. This layer would filter ARP requests arriving from the IPv4 = stack and=20 respond with any MAC address. The IPCS classifier should never see = ARP=20 messages, and they should never be sent over the = air.
 
Regards,
Paolo

From: Behcet Sarikaya=20 [mailto:behcetsarikaya@yahoo.com]
Sent: Monday, February = 12, 2007=20 2:19 PM
To: Syam Madanapalli
Cc:=20 16ng@ietf.org
Subject: Re: [16NG]=20 = Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt
<= /FONT>
Hi=20 Syam,
 =20 You mentioned P2P link here in this message but I could not see any = text on=20 this in the draft. Maybe a section should be added on the address and = subnet=20 mask assignment given the P2P nature of the link and the fact that = such=20 assignments are not commonly used.
 =20 You recommended AR to ignore ARP Requests from MS, I am not sure if = this is OK=20 or a Reply would be needed according to ARP?   Regards,   Behcet

-----=20 Original Message ----
From: Syam Madanapalli=20 <smadanapalli@gmail.com>
To: "Narvaez, Paolo (Paolo)"=20 <paolo@alcatel-lucent.com>
Cc: 16ng@ietf.org
Sent: = Saturday,=20 February 10, 2007 12:34:46 AM
Subject: Re: [16NG] Fw:=20 = I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt

=
Hi Paolo,

On 2/10/07, Narvaez, Paolo (Paolo)=20 <paolo@alcatel-lucent.com> wrote:
>
> I have two = general=20 comments on this draft.
>
> 1. Section 7 assumes that ARP = messages=20 sent by the MS are received by
> the AR. The section states that = ARP=20 messages should be dropped by the
> AR. However, since ARP runs = directly=20 over Ethernet (there is no IP
> header) how can the 802.16 IPCS = carry=20 this type of packet over the air?

As mentioned the draft, ARP = is not=20 required for 802.16 because of the fact
that the MAC address is not = required for identifying the destination.
There was a concern that = an=20 unmodified host may send ARP without knowing
that the underlying = interface=20 is 802.16, because of this I added the
above statement.

If = we think=20 there is no such possibility, then I will remove this=20 text.

>
> 2. What is the subnet assignment? Can two = MSs be on=20 the same subnet? Or
> do we need to introduce some restrictions = as in=20 the IPv6-over-802.16
> draft.

The draft assumes the p2p = link, so=20 no two MSs can be on the same=20 subnet.

Thanks,
Syam

>
> Regards,
>=20 Paolo
>
>
>
>
> > -----Original=20 Message-----
> > From: Daniel Park=20 [mailto:soohong.park@samsung.com]
> > Sent: Thursday, = February 08,=20 2007 7:17 PM
> > To: 16ng@ietf.org
> > Subject: = [16NG]=20 Fw:
> >=20 = I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt
>= =20 >
> > IPv4CS document is now available at:
> > http://www.ietf.org/internet-drafts/draft-madanapalli-16n= g-ipv
>=20 > 4-over-802-dot-16-ipcs-00.txt
> >
> > Daniel = (Soohong=20 Daniel Park)
> > Mobile Convergence Laboratory, SAMSUNG=20 Electronics.
> >
> >=20 _______________________________________________
> > 16NG = mailing=20 list
> > 16NG@ietf.org
> > https://www1.ietf.org/mailman/listinfo/16ng
>=20 >
>
> = _______________________________________________
>=20 16NG mailing list
> 16NG@ietf.org
> https://www1.ietf.org/mailman/listinfo/16ng
>
_______________________________________________
16NG=20 mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng

------_=_NextPart_001_01C74EE1.46A764EB-- --===============0015834325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng --===============0015834325==-- From 16ng-bounces@ietf.org Wed Feb 14 02:58:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHF20-0007ZC-EH; Wed, 14 Feb 2007 02:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHF1z-0007YS-2E for 16ng@ietf.org; Wed, 14 Feb 2007 02:58:23 -0500 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHF1v-0007io-Ne for 16ng@ietf.org; Wed, 14 Feb 2007 02:58:23 -0500 Received: by wr-out-0506.google.com with SMTP id 67so141010wri for <16ng@ietf.org>; Tue, 13 Feb 2007 23:58:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lY4X7X2mLJdGfJdFb4ITvH4sOy+JLF1rG9hRLKfbxNvwwmnXapDxSd4HnyhVvhYT9+v22g257IOZm/1EiUWMz2vy+X71MitPiJtYDlxx1BoUE6139eDx/DUSubOq+cXm+5tw4EauAv9i1OEWNIihJybEQ+CM6k4bWrMkvllw3Y0= Received: by 10.114.145.1 with SMTP id s1mr7288448wad.1171439898998; Tue, 13 Feb 2007 23:58:18 -0800 (PST) Received: by 10.114.15.6 with HTTP; Tue, 13 Feb 2007 23:58:18 -0800 (PST) Message-ID: <10e14db20702132358y28711590lc3858c7efb59c0eb@mail.gmail.com> Date: Wed, 14 Feb 2007 13:28:18 +0530 From: "Syam Madanapalli" To: "Narvaez, Paolo (Paolo)" Subject: Re: [16NG] Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt In-Reply-To: <61B0DCC9767CDC4C91769592B12CCDD136EB4A@ILEXC2U02.ndc.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <583400.71141.qm@web60323.mail.yahoo.com> <61B0DCC9767CDC4C91769592B12CCDD136EB4A@ILEXC2U02.ndc.lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org Hi Bachet, Paolo, In the next revision I will add an explicit section for the subnet model. Please some inline text. On 2/13/07, Narvaez, Paolo (Paolo) wrote: > > > > How can the MS and AR send ARP requests and responses to each other? These > ARP messages have to go over IPCS and there is no IP packet in this case. I agree with this, as there is no IP header, IPCS cannot classify these frames. > > If there is concern for a legacy IPv4 stack at the MS sending ARP requests > and perhaps even requiring ARP responses, why not recommend a shim layer > between the IPv4 stack and the 802.16 IPCS layer at the MS. This layer would > filter ARP requests arriving from the IPv4 stack and respond with any MAC > address. The IPCS classifier should never see ARP messages, and they should > never be sent over the air. This can be a solution. But can we leave this for implementors? And in the draft we just say ARP is not required and MUST not be sent over the air. Thanks, Syam > > Regards, > Paolo > > > ________________________________ > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > Sent: Monday, February 12, 2007 2:19 PM > To: Syam Madanapalli > Cc: 16ng@ietf.org > > Subject: Re: [16NG] > Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > > Hi Syam, > You mentioned P2P link here in this message but I could not see any text > on this in the draft. Maybe a section should be added on the address and > subnet mask assignment given the P2P nature of the link and the fact that > such assignments are not commonly used. > You recommended AR to ignore ARP Requests from MS, I am not sure if this > is OK or a Reply would be needed according to ARP? > > Regards, > > Behcet > > > ----- Original Message ---- > From: Syam Madanapalli > To: "Narvaez, Paolo (Paolo)" > Cc: 16ng@ietf.org > Sent: Saturday, February 10, 2007 12:34:46 AM > Subject: Re: [16NG] Fw: > I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > Hi Paolo, > > On 2/10/07, Narvaez, Paolo (Paolo) wrote: > > > > I have two general comments on this draft. > > > > 1. Section 7 assumes that ARP messages sent by the MS are received by > > the AR. The section states that ARP messages should be dropped by the > > AR. However, since ARP runs directly over Ethernet (there is no IP > > header) how can the 802.16 IPCS carry this type of packet over the air? > > As mentioned the draft, ARP is not required for 802.16 because of the fact > that the MAC address is not required for identifying the destination. > There was a concern that an unmodified host may send ARP without knowing > that the underlying interface is 802.16, because of this I added the > above statement. > > If we think there is no such possibility, then I will remove this text. > > > > > 2. What is the subnet assignment? Can two MSs be on the same subnet? Or > > do we need to introduce some restrictions as in the IPv6-over-802.16 > > draft. > > The draft assumes the p2p link, so no two MSs can be on the same subnet. > > Thanks, > Syam > > > > > Regards, > > Paolo > > > > > > > > > > > -----Original Message----- > > > From: Daniel Park [mailto:soohong.park@samsung.com] > > > Sent: Thursday, February 08, 2007 7:17 PM > > > To: 16ng@ietf.org > > > Subject: [16NG] Fw: > > > > I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > > > IPv4CS document is now available at: > > > > http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv > > > 4-over-802-dot-16-ipcs-00.txt > > > > > > Daniel (Soohong Daniel Park) > > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > > > _______________________________________________ > > > 16NG mailing list > > > 16NG@ietf.org > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > _______________________________________________ > > 16NG mailing list > > 16NG@ietf.org > > https://www1.ietf.org/mailman/listinfo/16ng > > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Feb 14 18:17:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTN0-00079N-QF; Wed, 14 Feb 2007 18:17:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTMz-00079I-Rw for 16ng@ietf.org; Wed, 14 Feb 2007 18:17:01 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTMu-0003i0-Fl for 16ng@ietf.org; Wed, 14 Feb 2007 18:17:01 -0500 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JDH00BTD7C2LP@mailout3.samsung.com> for 16ng@ietf.org; Thu, 15 Feb 2007 08:16:50 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JDH00I1L7C1F2@mmp2.samsung.com> for 16ng@ietf.org; Thu, 15 Feb 2007 08:16:50 +0900 (KST) Date: Thu, 15 Feb 2007 08:16:38 +0900 From: Daniel Park Subject: Re: [16NG]Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt To: Syam Madanapalli , "Narvaez, Paolo (Paolo)" Message-id: <00cd01c7508e$2ddaca80$6dc6dba8@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <583400.71141.qm@web60323.mail.yahoo.com> <61B0DCC9767CDC4C91769592B12CCDD136EB4A@ILEXC2U02.ndc.lucent.com> <10e14db20702132358y28711590lc3858c7efb59c0eb@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org >> How can the MS and AR send ARP requests and responses to each other? These >> ARP messages have to go over IPCS and there is no IP packet in this case. So, we should discard ARP packets on the MS. >> If there is concern for a legacy IPv4 stack at the MS sending ARP requests >> and perhaps even requiring ARP responses, why not recommend a shim layer >> between the IPv4 stack and the 802.16 IPCS layer at the MS. This layer would >> filter ARP requests arriving from the IPv4 stack and respond with any MAC >> address. The IPCS classifier should never see ARP messages, and they should >> never be sent over the air. Interesting point. It does, however, not happen if the MS discard ARP packets. But your mention seems one of alternatives from the implementation point of view. Daniel _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Feb 14 18:31:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTap-0001o3-ES; Wed, 14 Feb 2007 18:31:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTao-0001ny-BQ for 16ng@ietf.org; Wed, 14 Feb 2007 18:31:18 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTal-0005i0-Uj for 16ng@ietf.org; Wed, 14 Feb 2007 18:31:18 -0500 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JDH00CXO7ZY32@mailout1.samsung.com> for 16ng@ietf.org; Thu, 15 Feb 2007 08:31:10 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JDH00KSI7ZXR7@mmp2.samsung.com> for 16ng@ietf.org; Thu, 15 Feb 2007 08:31:10 +0900 (KST) Date: Thu, 15 Feb 2007 08:30:58 +0900 From: Daniel Park Subject: Re: [16NG] Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt To: Behcet Sarikaya , Syam Madanapalli Message-id: <00dd01c75090$2e3841e0$6dc6dba8@your655e9d6f61> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <583400.71141.qm@web60323.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org >You mentioned P2P link here in this message but I could >not see any text on this in the draft. Maybe a section >should be added on the address and subnet mask assignment >given the P2P nature of the link and the fact that such >assignments are not commonly used. In case of IPv4, DHCP server has to allocate a different subnet address to each MS to provide P2P link model. >You recommended AR to ignore ARP Requests from MS, >I am not sure if this is OK or a Reply would be needed >according to ARP? As I pointed out, I tend to discard ARP messages on the MS iteself. What do you think ? Daniel _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Feb 14 18:49:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTsI-0004hh-PN; Wed, 14 Feb 2007 18:49:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTsH-0004hG-17 for 16ng@ietf.org; Wed, 14 Feb 2007 18:49:21 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTsF-00009Y-JD for 16ng@ietf.org; Wed, 14 Feb 2007 18:49:21 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l1ENn9vc003954; Wed, 14 Feb 2007 17:49:09 -0600 (CST) Received: from ILEXC2U02.ndc.lucent.com ([135.3.39.9]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 17:49:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [16NG] Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt Date: Wed, 14 Feb 2007 17:49:08 -0600 Message-ID: <61B0DCC9767CDC4C91769592B12CCDD136F98A@ILEXC2U02.ndc.lucent.com> In-Reply-To: <10e14db20702132358y28711590lc3858c7efb59c0eb@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt Thread-Index: AcdQDegbhYeWGl9DTzyX1Q0hXCnG5AAgr+EA References: <583400.71141.qm@web60323.mail.yahoo.com> <61B0DCC9767CDC4C91769592B12CCDD136EB4A@ILEXC2U02.ndc.lucent.com> <10e14db20702132358y28711590lc3858c7efb59c0eb@mail.gmail.com> From: "Narvaez, Paolo \(Paolo\)" To: "Syam Madanapalli" X-OriginalArrivalTime: 14 Feb 2007 23:49:09.0125 (UTC) FILETIME=[B8531B50:01C75092] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org =20 > > If there is concern for a legacy IPv4 stack at the MS sending ARP=20 > > requests and perhaps even requiring ARP responses, why not=20 > recommend a=20 > > shim layer between the IPv4 stack and the 802.16 IPCS layer=20 > at the MS.=20 > > This layer would filter ARP requests arriving from the IPv4=20 > stack and=20 > > respond with any MAC address. The IPCS classifier should=20 > never see ARP=20 > > messages, and they should never be sent over the air. >=20 > This can be a solution. But can we leave this for=20 > implementors? And in the draft we just say ARP is not=20 > required and MUST not be sent over the air. I agree. There is no need to provide details of how the MS deals with this issue. However, we cannot forbid ARPs over the air because ARP packets over the air (IPCS) do not exist nor are they defined. It might be more clear to say that the MS should not send any ARP-related messages over the air. Paolo > -----Original Message----- > From: Syam Madanapalli [mailto:smadanapalli@gmail.com]=20 > Sent: Wednesday, February 14, 2007 2:58 AM > To: Narvaez, Paolo (Paolo) > Cc: Behcet Sarikaya; 16ng@ietf.org > Subject: Re: [16NG]=20 > Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt >=20 > Hi Bachet, Paolo, >=20 > In the next revision I will add an explicit section for the=20 > subnet model. > Please some inline text. >=20 > On 2/13/07, Narvaez, Paolo (Paolo) wrote: > > > > > > > > How can the MS and AR send ARP requests and responses to=20 > each other?=20 > > These ARP messages have to go over IPCS and there is no IP=20 > packet in this case. >=20 > I agree with this, as there is no IP header, IPCS cannot=20 > classify these frames. >=20 > > > > If there is concern for a legacy IPv4 stack at the MS sending ARP=20 > > requests and perhaps even requiring ARP responses, why not=20 > recommend a=20 > > shim layer between the IPv4 stack and the 802.16 IPCS layer=20 > at the MS.=20 > > This layer would filter ARP requests arriving from the IPv4=20 > stack and=20 > > respond with any MAC address. The IPCS classifier should=20 > never see ARP=20 > > messages, and they should never be sent over the air. >=20 > This can be a solution. But can we leave this for=20 > implementors? And in the draft we just say ARP is not=20 > required and MUST not be sent over the air. >=20 >=20 > Thanks, > Syam >=20 > > > > Regards, > > Paolo > > > > > > ________________________________ > > From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com] > > Sent: Monday, February 12, 2007 2:19 PM > > To: Syam Madanapalli > > Cc: 16ng@ietf.org > > > > Subject: Re: [16NG] > > Fw:I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > > > > > > > Hi Syam, > > You mentioned P2P link here in this message but I could=20 > not see any=20 > > text on this in the draft. Maybe a section should be added on the=20 > > address and subnet mask assignment given the P2P nature of the link=20 > > and the fact that such assignments are not commonly used. > > You recommended AR to ignore ARP Requests from MS, I am=20 > not sure if=20 > > this is OK or a Reply would be needed according to ARP? > > > > Regards, > > > > Behcet > > > > > > ----- Original Message ---- > > From: Syam Madanapalli > > To: "Narvaez, Paolo (Paolo)" > > Cc: 16ng@ietf.org > > Sent: Saturday, February 10, 2007 12:34:46 AM > > Subject: Re: [16NG] Fw: > > I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > > > Hi Paolo, > > > > On 2/10/07, Narvaez, Paolo (Paolo) wrote: > > > > > > I have two general comments on this draft. > > > > > > 1. Section 7 assumes that ARP messages sent by the MS are=20 > received=20 > > > by the AR. The section states that ARP messages should be=20 > dropped by=20 > > > the AR. However, since ARP runs directly over Ethernet=20 > (there is no=20 > > > IP > > > header) how can the 802.16 IPCS carry this type of packet=20 > over the air? > > > > As mentioned the draft, ARP is not required for 802.16=20 > because of the=20 > > fact that the MAC address is not required for identifying=20 > the destination. > > There was a concern that an unmodified host may send ARP without=20 > > knowing that the underlying interface is 802.16, because of this I=20 > > added the above statement. > > > > If we think there is no such possibility, then I will=20 > remove this text. > > > > > > > > 2. What is the subnet assignment? Can two MSs be on the=20 > same subnet?=20 > > > Or do we need to introduce some restrictions as in the=20 > > > IPv6-over-802.16 draft. > > > > The draft assumes the p2p link, so no two MSs can be on the=20 > same subnet. > > > > Thanks, > > Syam > > > > > > > > Regards, > > > Paolo > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Daniel Park [mailto:soohong.park@samsung.com] > > > > Sent: Thursday, February 08, 2007 7:17 PM > > > > To: 16ng@ietf.org > > > > Subject: [16NG] Fw: > > > > > > I-DACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt > > > > > > > > IPv4CS document is now available at: > > > > > > http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv > > > > 4-over-802-dot-16-ipcs-00.txt > > > > > > > > Daniel (Soohong Daniel Park) > > > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > > > > > _______________________________________________ > > > > 16NG mailing list > > > > 16NG@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > > > > _______________________________________________ > > > 16NG mailing list > > > 16NG@ietf.org > > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > _______________________________________________ > > 16NG mailing list > > 16NG@ietf.org > > https://www1.ietf.org/mailman/listinfo/16ng > > > > >=20 _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Feb 16 02:20:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxOR-0000a2-0S; Fri, 16 Feb 2007 02:20:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxOO-0000ZQ-D8 for 16ng@ietf.org; Fri, 16 Feb 2007 02:20:28 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHxOL-0004dw-8K for 16ng@ietf.org; Fri, 16 Feb 2007 02:20:28 -0500 Received: from etrim ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 16:25:03 +0900 From: "Junghoon Jee" To: "'gabriel montenegro'" , "'Daniel Park'" , <16ng@ietf.org> References: <20070130015037.91197.qmail@web81908.mail.mud.yahoo.com> In-Reply-To: <20070130015037.91197.qmail@web81908.mail.mud.yahoo.com> Subject: draft-ietf-16ng-ps-goals-01 (was RE: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 Date: Fri, 16 Feb 2007 16:20:20 +0900 Message-ID: <002101c7519a$eab607c0$c0221740$@re.kr> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcdEEa/s92ojWJqGQ7ONAruiskVGKwNh2x9g Content-Language: ko X-OriginalArrivalTime: 16 Feb 2007 07:25:03.0589 (UTC) FILETIME=[9344D150:01C7519B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773 Cc: X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1975062710==" Errors-To: 16ng-bounces@ietf.org 여러 부분으로 구성된 MIME 형식의 메시지입니다. --===============1975062710== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C751E6.5A9DAFC0" Content-Language: ko 여러 부분으로 구성된 MIME 형식의 메시지입니다. ------=_NextPart_000_0022_01C751E6.5A9DAFC0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Dear All, =20 "Say hay boke-mahn he pah du say oh!" =20 The document, "IP over IEEE 802.16 Problem Statement and Goals" was = updated and submitted. Before seen through the IETF repository, that draft can be found at: http://my.dreamwiz.com/junghoon/draft-ietf-16ng-ps-goals-01.txt =20 Best Regards, Junghoon =20 From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]=20 Sent: Tuesday, January 30, 2007 10:51 AM To: Jee, Junghoon; Daniel Park; 16ng@ietf.org Subject: Re: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 =20 I guess that's before Feb 18 or so? Cool, thanks. say hay boke-mahn he pah du say oh. -gabriel ----- Original Message ---- From: "Jee, Junghoon" To: gabriel montenegro ; Daniel Park ; 16ng@ietf.org Sent: Monday, January 29, 2007 4:03:51 PM Subject: RE: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 Hello Gabriel, The PS update reflecting the DJ and Phil?=AFs comments have been = undertaken and still ongoing. The main reason of the unexpected delay was that proposed comments are = more than editorial and requires structural and major enhancement from the current version. I expect that new version should be available before the lunar new = year?=AFs day. I hope this works for the WG?=AFs agenda. =20 Best Regards, Junghoon =20 _____ =20 From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]=20 Sent: Monday, January 29, 2007 7:23 PM To: Junghoon Jee; Daniel Park; 16ng@ietf.org Subject: Re: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 =20 Any idea when the new version will be available? thanks, -gabriel ----- Original Message ---- From: Junghoon Jee < jhjee@etri.re.kr > To: Daniel Park ; 16ng@ietf.org Sent: Tuesday, December 26, 2006 11:12:20 PM Subject: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 Daniel, Sorry for the delay. The updated PS I-D will be available soon along with the related discussion if necessary. Junghoon=20 > -----Original Message----- > From: Daniel Park [mailto:soohong.park@samsung.com]=20 > Sent: Wednesday, December 27, 2006 1:58 PM > To: 16ng@ietf.org > Cc: ??? > Subject: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 >=20 >=20 > Folks,=20 >=20 > The WGLC expired long time ago, but WG does not think it is=20 > passed successfully. In order words, the authors need more=20 > works on the revision to increase the quality of this=20 > document. Once updating it including two experts review (DJ=20 > and Phil) as well as a new set of terms. We will solicit one=20 > more short WGLC to be ready for the IESG at that time.=20 >=20 > Junghoon, please update it as soon as possible, then submit=20 > it to the IETF secretariate.=20 >=20 > Thanks,=20 >=20 > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. >=20 > ----- Original Message ----- > From: "Soohong Daniel Park" > To: <16ng@eeca16.sogang.ac.kr> > Sent: Tuesday, October 17, 2006 9:19 AM > Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00 >=20 >=20 > > Folks, > >=20 > > This is a two week WGLC on draft-ietf-16ng-ps-goals-00. > >=20 > > Please review the I-D and submit your comments to the authors or to > > the list directly. The WGLC will exipre on October 31=20 > (Pacific Time). > >=20 > > o I-D:=20 > http://www.ietf.org/internet-drafts/draft-ietf-16ng-ps-goals-00.txt > >=20 > > o Intended publication: Informational RFC > >=20 > >=20 > > --=20 > >=20 > >=20 > > Daniel (Soohong Daniel Park) > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > _______________________________________________ > > 16ng mailing list > > 16ng@eeca16.sogang.ac.kr > > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng > >=20 > > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng =20 =20 ------=_NextPart_000_0022_01C751E6.5A9DAFC0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

Dear All,

 

“Say hay boke-mahn he pah du say = oh!”

 

The document, “IP over IEEE 802.16 Problem = Statement and Goals” was updated and submitted.

Before seen through the IETF repository, that draft can = be found at:

http://my.dreamwiz.com/junghoon/draft-ietf-16ng-ps-goals-0= 1.txt

 

Best Regards,

Junghoon

 

From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]
Sent: Tuesday, January 30, 2007 10:51 AM
To: Jee, Junghoon; Daniel Park; 16ng@ietf.org
Subject: Re: [16NG] RE: WG Decision: WGLC : = draft-ietf-16ng-ps-goals-00

 

I guess that's before Feb 18 or so? Cool, = thanks.

say hay boke-mahn he pah du say oh.

-gabriel

----- Original Message ----
From: "Jee, Junghoon" <jhjee@etri.re.kr>
To: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>; Daniel = Park <soohong.park@samsung.com>; 16ng@ietf.org
Sent: Monday, January 29, 2007 4:03:51 PM
Subject: RE: [16NG] RE: WG Decision: WGLC : = draft-ietf-16ng-ps-goals-00

Hello Gabriel,

The PS update reflecting the DJ and Phil=A1= =AFs = comments have been undertaken and still ongoing.

The main reason of the unexpected delay was that proposed = comments are more than editorial and requires structural and major enhancement = from the current version.

I expect that new version should be available before the = lunar new year=A1=AFs day.

I hope this works for the WG=A1= =AFs = agenda.

 

Best Regards,

Junghoon

 

From: gabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]
Sent: Monday, January 29, 2007 7:23 PM
To: Junghoon Jee; Daniel Park; 16ng@ietf.org
Subject: Re: [16NG] RE: WG Decision: WGLC : = draft-ietf-16ng-ps-goals-00

 

Any idea when the new version will be = available?

thanks,

-gabriel

----- Original Message ----
From: Junghoon Jee < jhjee@etri.re.kr >
To: Daniel Park <soohong.park@samsung.com>; 16ng@ietf.org
Sent: Tuesday, December 26, 2006 11:12:20 PM
Subject: [16NG] RE: WG Decision: WGLC : = draft-ietf-16ng-ps-goals-00

Daniel,
Sorry for the delay.
The updated PS I-D will be available soon along with the related
discussion if necessary.

Junghoon

> -----Original Message-----
> From: Daniel Park [mailto:soohong.park@samsung.com]
> Sent: Wednesday, December 27, 2006 1:58 PM
> To: 16ng@ietf.org
> Cc: ???
> Subject: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00
>
>
> Folks,
>
> The WGLC expired long time ago, but WG does not think it is
> passed successfully. In order words, the authors need more
> works on the revision to increase the quality of this
> document. Once updating it including two experts review (DJ
> and Phil) as well as a new set of terms. We will solicit one
> more short WGLC to be ready for the IESG at that time.
>
> Junghoon, please update it as soon as possible, then submit
> it to the IETF secretariate.
>
> Thanks,
>
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
>
> ----- Original Message -----
> From: "Soohong Daniel Park" = <soohongp@gmail.com>
> To: <16ng@eeca16.sogang.ac.kr>
> Sent: Tuesday, October 17, 2006 9:19 AM
> Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00
>
>
> > Folks,
> >
> > This is a two week WGLC on draft-ietf-16ng-ps-goals-00.
> >
> > Please review the I-D and submit your comments to the authors = or
to
> > the list directly. The WGLC will exipre on October 31
> (Pacific Time).
> >
> > o I-D:
> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ps-= goals-00.txt
> >
> > o Intended publication: Informational RFC
> >
> >
> > --
> >
> >
> > Daniel (Soohong Daniel Park)
> > Mobile Convergence Laboratory, SAMSUNG Electronics.
> > _______________________________________________
> > 16ng mailing list
> > 16ng@eeca16.sogang.ac.kr
> > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng > >
> >


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng

 

 

------=_NextPart_000_0022_01C751E6.5A9DAFC0-- --===============1975062710== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng --===============1975062710==-- From 16ng-bounces@ietf.org Fri Feb 16 15:50:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIA1y-0001RP-Cp; Fri, 16 Feb 2007 15:50:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIA1r-0001Pe-4C; Fri, 16 Feb 2007 15:50:03 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIA1q-0006vU-N6; Fri, 16 Feb 2007 15:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 920023290B; Fri, 16 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HIA1q-0000cp-FD; Fri, 16 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 16ng@ietf.org Subject: [16NG] I-D ACTION:draft-ietf-16ng-ps-goals-01.txt X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over IEEE 802.16 Networks Working Group of the IETF. Title : IP over 802.16 Problem Statement and Goals Author(s) : J. Jee, et al. Filename : draft-ietf-16ng-ps-goals-01.txt Pages : 15 Date : 2007-2-16 This document specifies problems in running the IETF IP protocols over IEEE 802.16 networks by identifying specific gaps in the 802.16 MAC for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. The common terminology to be used for the base guideline while defining the solution frameworks is also presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ps-goals-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-16ng-ps-goals-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-16ng-ps-goals-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-16123929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-16ng-ps-goals-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-16ng-ps-goals-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-16123929.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng --NextPart-- From 16ng-bounces@ietf.org Wed Feb 21 10:51:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtkx-0000sc-Gc; Wed, 21 Feb 2007 10:51:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJtjl-0007Av-7h; Wed, 21 Feb 2007 10:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJtjk-0007jw-Rp; Wed, 21 Feb 2007 10:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4278E2ACB0; Wed, 21 Feb 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HJtjF-0008SA-Vz; Wed, 21 Feb 2007 10:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Feb 2007 10:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 16ng@ietf.org Subject: [16NG] I-D ACTION:draft-ietf-16ng-ipv6-link-model-analysis-03.txt X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 16ng working group discussion list <16ng.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 16ng-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over IEEE 802.16 Networks Working Group of the IETF. Title : Analysis of IPv6 Link Models for 802.16 based Networks Author(s) : S. Madanapalli Filename : draft-ietf-16ng-ipv6-link-model-analysis-03.txt Pages : 17 Date : 2007-2-21 This document provides different IPv6 link models that are suitable for 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is result of a Design Team that was formed to analyze the IPv6 link models for 802.16 based networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-16ng-ipv6-link-model-analysis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-21084047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-16ng-ipv6-link-model-analysis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-21084047.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng --NextPart--