From 16ng-bounces@ietf.org Mon Jan 01 23:46:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1bXI-0002NV-TL; Mon, 01 Jan 2007 23:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1bW4-0001V6-25 for 16ng@ietf.org; Mon, 01 Jan 2007 23:44:48 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1bT9-0008Al-QH for 16ng@ietf.org; Mon, 01 Jan 2007 23:41:51 -0500 Received: from ep_mmp1 (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 <0JB8009FZ51I1Y@mailout2.samsung.com> for 16ng@ietf.org; Tue, 02 Jan 2007 13:41:42 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JB800FCH51HKC@mmp1.samsung.com> for 16ng@ietf.org; Tue, 02 Jan 2007 13:41:42 +0900 (KST) Date: Tue, 02 Jan 2007 13:41:17 +0900 From: Daniel Park Subject: Re: use of fixed/nomadic term (was: [16ng] Common set of the 16ng terminologies) To: Alexandru Petrescu Message-id: <021501c72e28$3e2c2b00$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: <0J7S00BFA8VTDU@ms7.samsung.com> <015e01c6fe3f$635a39d0$6dc6dba8@your655e9d6f61> <45953DD1.3070104@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Alex, Your concern below make sense to me. In fact, Nomadic is one of types of wireless networks. So, most devices with 802.16 connections are operated in nomadic mode, but during operation, the devices are stationary. More precise, 16/16d are for "Air Interface for Fixed BWA Systems" and 16e is for "Air Interface for Fixed and Mobile BWA Systems". Thus, Fixed or Mobile would be workable in the 16ng stuff. Thanks your input. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ----- Original Message ----- From: "Alexandru Petrescu" To: "Soohong Daniel Park" Cc: <16ng@eeca16.sogang.ac.kr>; "Junghoon Jee" Sent: Saturday, December 30, 2006 1:09 AM Subject: Re: use of fixed/nomadic term (was: [16ng] Common set of the 16ng terminologies) > Soohong Daniel Park wrote: >> Folks, >> >> Here is a common set of the 16ng terms to be included in the >> draft-ietf-16ng-ps-goals. For further terms that are specific to >> others document, they can be in that document. >> >> Any comments are highly welcome. If I am missing anything that might >> be included in this common set, please let me know that. >> >> So far, thanks Raj for his good comments and feedbacks on that. >> >> ===================[BEGIN]==================== >> >> o Subscriber Station (SS): An end-user equipment that provides >> connectivity to the 802.16 networks. It can be either fixed/nomadic >> or mobile equipment. In mobile environment, SS represents the Mobile >> Subscriber Station (MS) introduced in IEEE 802.16e specification. > > Hi Daniel, here's some comments on my reading of the fixed/nomadic term. > I may be alone not really understanding fixed/mobile for IPv6. > > In one sense, saying either fixed/nomadic makes think that one wants to > say either fixed _or_ nomadic. But that slash, or divide sign, doesn't > make think of the _or_ operation, it makes think of fixed over nomadic, > or maybe fixed _and_ nomadic. It could better be expressed as > fixed-nomadic, note the dash. > > I've noticed the use of fixed/nomadic term by telecom operators > advertising a unique handset that would be able to work at home as a > normal fixed landline handset (e.g. with DECT) at the same time it can > be taken out of home and used as a nomadic cell-phone. In both cases > the handset is wireless (no wire) but uses different frequencies when > fixed or when nomadic. Also, the equipment is concerned about voice > calls and agenda sharing. Also, the advertised fixed/nomadic equipments > wouldn't run Mobile IPv6. > > What does fixed/nomadic term mean in case of mobility? Is a fixed DECT > phone mobile? Yes, one can move within a large house and even in the > garden. Is a nomadic phone mobile? Yes, and it can even _roam_ across > continents. > > What does fixed/nomadic term mean in case of IPv6? Is it that an IPv6 > fixed equipment runs DHCPv6 and that an IPv6 nomadic equipment runs > Mobile IPv6? Is it that a fixed/nomadic IPv6 equipment runs a special > set of IPv6 protocols? > > What does fixed/nomadic term mean in case of 802.16? Is it that an SS > is fixed and than an MS is nomadic? > > Would IPv6 over IPv6CS run differently on a 802.16 equipment that is > fixed, than on an equipment that is nomadic. > > I really can't find the necessity of the use of the term fixed/nomadic. > > That's why I think the above SS definition would read better as below, > remark the removal of term nomadic: >> o Subscriber Station (SS): An end-user equipment that provides >> connectivity to the 802.16 networks. It can be either fixed or mobile >> equipment. In mobile environment, SS represents the Mobile >> Subscriber Station (MS) introduced in IEEE 802.16e specification. > > What do you think? > > Alex > > > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 01 23:48:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ba3-0004fQ-3N; Mon, 01 Jan 2007 23:48:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ba1-0004f1-UZ for 16ng@ietf.org; Mon, 01 Jan 2007 23:48:53 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ba0-0001Yd-BV for 16ng@ietf.org; Mon, 01 Jan 2007 23:48:53 -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 <0JB800MF45DE1M@mailout1.samsung.com> for 16ng@ietf.org; Tue, 02 Jan 2007 13:48: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 <0JB800LA55DD3C@mmp2.samsung.com> for 16ng@ietf.org; Tue, 02 Jan 2007 13:48:50 +0900 (KST) Date: Tue, 02 Jan 2007 13:48:25 +0900 From: Daniel Park Subject: Re: router lifetimes and RA retransmissions (was: [16NG] 2nd WGLC : draft-ietf-16ng-ipv6-over-ipv6cs-04) To: Alexandru Petrescu Message-id: <022001c72e29$3d441f80$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: <45950C92.4000304@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Reply on the concern below: >> This is the 2nd WGLC on draft-ietf-16ng-ipv6-over-ipv6cs-04 - IPv6 >> Over the IP Specific part of the Packet Convergence sublayer in >> 802.16 Networks. >> >> The latest version can be found at: >> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-04.txt >> >> >> It will expire on January 5. 2007 > > I may be the only one thinking so but isn't this LC too short - ie 6 > days out which at least 3 are non-working. Alex, I thought this concern, but I'd like to live up to our milestone. Our official WGLC (2 weeks) expired before. It is not an offcial WGLC, but a supplement to get further comments on the document prior to sending it to the IESG internally. So, we decided one week for that. Thanks your kind understanding in advance. 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 Tue Jan 02 15:50:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qam-0005Fu-Ly; Tue, 02 Jan 2007 15:50:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qaf-00053e-68; Tue, 02 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H1qae-0004DT-RC; Tue, 02 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 88EA017716; Tue, 2 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H1qaA-0002mw-4u; Tue, 02 Jan 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: Tue, 02 Jan 2007 15:50:02 -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-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 : Analysis of IPv6 Link Models for 802.16 based Networks Author(s) : S. Madanapalli Filename : draft-ietf-16ng-ipv6-link-model-analysis-01.txt Pages : 17 Date : 2007-1-2 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-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-ipv6-link-model-analysis-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-ipv6-link-model-analysis-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-1-2114621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-16ng-ipv6-link-model-analysis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-2114621.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 Jan 03 07:11:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24xa-0004e5-7Q; Wed, 03 Jan 2007 07:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24xZ-0004dz-Dt for 16ng@ietf.org; Wed, 03 Jan 2007 07:11:09 -0500 Received: from mail.us.es ([193.147.175.20] helo=us.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H24xX-00075m-Vi for 16ng@ietf.org; Wed, 03 Jan 2007 07:11:09 -0500 Received: (qmail 10599 invoked from network); 3 Jan 2007 13:11:01 +0100 Received: from unknown (HELO us.es) (192.168.2.11) by us.es with SMTP; 3 Jan 2007 13:11:01 +0100 Received: (qmail 24688 invoked from network); 3 Jan 2007 12:11:01 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on antivirus1 X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.5 tests=BAYES_50 autolearn=disabled version=3.1.7 Received: from unknown (HELO us.es) (127.0.0.1) by us.es with SMTP; 3 Jan 2007 13:11:01 +0100 Received: (qmail 23357 invoked from network); 3 Jan 2007 13:11:02 +0100 Received: from trajano.us.es (193.147.162.130) by us.es with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Jan 2007 13:11:02 +0100 Received: from [193.147.162.142] (trajano.us.es [193.147.162.130]) by trajano.us.es (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l03CAtxk001744 for <16ng@ietf.org>; Wed, 3 Jan 2007 13:10:56 +0100 Message-ID: <459B9D4F.3070301@trajano.us.es> Date: Wed, 03 Jan 2007 13:10:55 +0100 From: "Juan A. Ternero" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: es,en MIME-Version: 1.0 To: 16ng@ietf.org Subject: Re: [16NG] Review comments on draft-ietf-16ng-ip-over-ethernet-over-802.16-00 References: <10e14db20612270120y667aa995ief03a46ee2cad044@mail.gmail.com> In-Reply-To: <10e14db20612270120y667aa995ief03a46ee2cad044@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 >> BS can construct link local address of each SS from adding prefix >> "FE80::/64" to last 24 bits of MAC address corresponding to the each >> SS > > > I think this is incorrect. Rather simply refer to RFC 3513. I agree, but refer to RFC 4291 (obsoletes 3513). _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 03 21:21:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2IEB-000716-LY; Wed, 03 Jan 2007 21:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2IEA-0006zm-7N for 16ng@ietf.org; Wed, 03 Jan 2007 21:21:10 -0500 Received: from m13-160.163.com ([220.181.13.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2IE7-0008BP-U7 for 16ng@ietf.org; Wed, 03 Jan 2007 21:21:10 -0500 Received: from 192.168.193.191(202.120.37.2, 192.168.208.44) ( 192.168.193.191(202.120.37.2, 192.168.208.44) [192.168.193.191(202.120.37.2, 192.168.208.44)] ) by webmail-app17 (Coremail) ; Thu, 4 Jan 2007 10:21:03 +0800 (CST) MIME-Version: 1.0 Message-ID: <459C648F.000021.30893@bj163app17.163.com> Date: Thu, 4 Jan 2007 10:21:03 +0800 (CST) From: "=?gb2312?B?wdbn5g==?=" To: "16ng@ietf.org" <16ng@ietf.org> Subject: Re: [16NG] Review comments on draft-ietf- 16ng-ip-over-ethernet-over-802.16-00 X-Priority: 1 X-Originating-IP: [192.168.193.191(202.120.37.2, 192.168.208.44)] X-Mailer: 163com X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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="===============1806890486==" Errors-To: 16ng-bounces@ietf.org --===============1806890486== Content-Type: Multipart/Alternative; boundary="Boundary-=_pemSBrVxgYMBWjZNyrUdOqsJUJBd" --Boundary-=_pemSBrVxgYMBWjZNyrUdOqsJUJBd Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit 4.4. Discovery of MAC addresses ... BS can construct link local address of each SS from adding prefix "FE80::/64" to last 24 bits of MAC address corresponding to the each SS and also derive solicited-node MAC address of each SS from prefix "33-33-FF" and last 24 bits of each SS's MAC address. I think the link local address of each SS by adding prefix FE80::/64 to last 24 bits of MAC address corresponding to the each SS couldn't assure that the link-local address is unique. In addition, "33-33-FF" prefix also couldn't make MAC address unique. Is these multicast address? I also think link-local address is for IPv6, why should IPv4 has link-local address? --Boundary-=_pemSBrVxgYMBWjZNyrUdOqsJUJBd Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable 4.4. Discovery of MAC addresses
...
BS can construct link local= address of each SS from adding prefix
"FE80::/64" to las= t 24 bits of MAC address corresponding to the each
SS and also deri= ve solicited-node MAC address of each SS from prefix
"33-33-FF= " and last 24 bits of each SS's MAC address.

I think the lin= k local address of each SS by adding prefix FE80::/64 to last 24 bits of = MAC address corresponding to the each SS couldn't assure that the link-lo= cal address is unique. In addition, "33-33-FF" prefix also coul= dn't make MAC address unique. Is these multicast address?

I also = think link-local address is for IPv6, why should IPv4 has link-local addr= ess?


=CF=EB=C3=E2=B7=D1=BB=F1=B5=C3=B8=DF=CB= =D9=CE=C8=B6=A8=B5=C43G=D3=CA=CF=E4=C2=F0=A3=BF www.126.com --Boundary-=_pemSBrVxgYMBWjZNyrUdOqsJUJBd-- --===============1806890486== 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 --===============1806890486==-- From 16ng-bounces@ietf.org Thu Jan 04 12:35:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WV8-0008LS-GR; Thu, 04 Jan 2007 12:35:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2WV6-0008LL-Id for 16ng@ietf.org; Thu, 04 Jan 2007 12:35:36 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H2WV5-0007mn-BU for 16ng@ietf.org; Thu, 04 Jan 2007 12:35:36 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1167932133!18533665!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 10815 invoked from network); 4 Jan 2007 17:35:34 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-13.tower-119.messagelabs.com with SMTP; 4 Jan 2007 17:35:34 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l04HZXOL010550; Thu, 4 Jan 2007 10:35:33 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l04HZVbg028993; Thu, 4 Jan 2007 11:35:32 -0600 (CST) Message-ID: <459D3AE2.6030506@motorola.com> Date: Thu, 04 Jan 2007 18:35:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: =?GB2312?B?wdbn5g==?= Subject: Re: [16NG] Review comments on draft-ietf- 16ng-ip-over-ethernet-over-802.16-00 References: <459C648F.000021.30893@bj163app17.163.com> In-Reply-To: <459C648F.000021.30893@bj163app17.163.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Linke Jacob wrote: > 4.4. Discovery of MAC addresses ... BS can construct link local > address of each SS from adding prefix "FE80::/64" to last 24 bits of > MAC address corresponding to the each SS and also derive > solicited-node MAC address of each SS from prefix "33-33-FF" and last > 24 bits of each SS's MAC address. > > I think the link local address of each SS by adding prefix FE80::/64 > to last 24 bits of MAC address corresponding to the each SS couldn't > assure that the link-local address is unique. That's right, I agree, should add to the IID (Interface ID) not to the 'last 24 bits'. The IID is derived by splitting the whole 48bits, inserting fffe somewhere and inverting a certain bit. Or one could add only the 24bits of the MAC address but then don't call it "IPv6 link-local address over Ethernet" because it's not. > In addition, "33-33-FF" prefix also couldn't make MAC address unique. > Is these multicast address? I guess it's the MAC-layer's 'solicited node multicast address'? > I also think link-local address is for IPv6, why should IPv4 has > link-local address? Well, Apple (and recently Microsoft) have IPv4 link-local addresses on their machines rfc3927. Both IPv4 and IPv6 construct locally these addresses (no message exchange), but an IPv6 ll address has more chances of being unique. That said, I do not agree with a single document IP-over-ETH covering both IPv6 and IPv4 because the semantics are very different at the Ethernet level. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 08 16:13:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H41na-00029S-Pt; Mon, 08 Jan 2007 16:12:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H40JQ-0005k5-6o for 16ng@ietf.org; Mon, 08 Jan 2007 14:37:40 -0500 Received: from mx1.blr.telsima.com ([203.200.43.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H40JG-00005Y-EP for 16ng@ietf.org; Mon, 08 Jan 2007 14:37:40 -0500 Received: from BLREXCH1.blr.telsima.com ([192.168.250.26]) by mx1.blr.telsima.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 01:06:06 +0530 Received: from MSONE.sc.telsima.com ([192.168.200.5]) by BLREXCH1.blr.telsima.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 01:06:04 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 8 Jan 2007 11:37:17 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt Thread-Index: AcczXGfR7nXEXQXtSmeu8nl7P/rFlw== From: "Burcak Beser" To: <16ng@ietf.org> X-OriginalArrivalTime: 08 Jan 2007 19:36:04.0875 (UTC) FILETIME=[3C85ADB0:01C7335C] X-Spam-Score: 0.0 (/) X-Scan-Signature: fd578f787bfd4c2f77b1fa8868561746 X-Mailman-Approved-At: Mon, 08 Jan 2007 16:12:53 -0500 Subject: [16NG] Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-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: , Content-Type: multipart/mixed; boundary="===============2114827190==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============2114827190== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7335C.692117CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7335C.692117CE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have to admit that at this point of time I am confused. The draft has some details and a lot of information that I am not sure how these interconnect. =20 Let me start from the beginning: =20 (The below described usage is the WiMAX mandatory supported transport of packets and all the descriptions and especially normative language has to deal with these details.) =20 =20 Per WiMAX specifications (see http://www.wimaxforum.org/technology/documents/WiMAX_End_to_End_Network_ Systems_Architecture.zip) each "connection" between SS and BS indicated by a unique CID within a single BS domain is mapped into a GRE tunnel in and in some other cases all CID's coming from a single SS is mapped into a GRE tunnel identified by a "GRE key". Now, it is important to note that the "connections" per IEEE 802.16 specifications is left very liberal in the means that they may be used. It is possible that there is a single uplink "connection" which has associated multiple downlink "connections". If there are no limitations on the CPE generated packets it is possible that the CPE packets will be fragmented as in the case of IPSEC tunnels, and will be fragmented again on the GRE level. =20 =20 SS_A CID1 BS GRE-key1 =20 CPE -----|------|------------\ | | \ CPE------| CID2 | GRE-key2 \ CPE -----|------|---------------\ | \ GRE . | = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= . | / | / CID3 SS_Z CID* | GRE-keyn / ---------|------|------------/ =20 =20 The BS sends these packets through the GRE tunnel to the ASN-GW which is a layer-3 device and designated in the draft as Access Router (AR). Per WiMAX specifications the ASN-GW actually can be divided into two as being serving ASN-GW which is the entity that the BS is connected (through the draft defined bridge) which re-maps the packets (GRE payloads) to another GRE tunnel to the anchored ASN-GW (again through the draft defined bridge). Where the final figure looks like as below: =20 =20 CID GRE_1 GRE_2 GRE_3 GRE_3 GRE_4 SS ---------- BS ------ Bridge ------ serving ----- arbitrary ----- Bridge -------- anchored (serving) ASN-GW network (anchored) ASN-GW =20 =20 We can say that for each CID there is a GRE tunnel where GRE_1 and GRE_2 are the same tunnel and GRE_3 and GRE_4 are the same tunnel further the GRE_1/2 and GRE_3/4 are one-to-one mapped. =20 This brings the draft introduced "Bridge", which has different interpretations; for the sake of taxonomy I think the bridge as having 3 layers: =20 =20 i. Layer 0: This is the 802.1d-2004 defined layer where the physical interfaces are the interfaces. It is very easy to decide where a packet is received and which interface you can send a packet. On this level the bridge supports a limited number of traffic: =20 * GRE tunnel: This is the traffic between the BS(s) and the ASN-GW(s). All BS(s) are sending packets to serving ASN-GW(s). =20 * ASN Control packets: These are packets exchanged between BS and ASN-GW for various purposes. =20 * Inter BS communications: This is the R8 interface of the WiMAX specification although it is not specified it may exist. =20 It is important to note that any packets generated by SS or any CPE behind it is send through the GRE tunnel which will always have the serving ASN-GW's MAC address for destination and BS' MAC address for source, and all the downstream packets destined for the SS or CPE's are send by the ASN-GW via the GRE tunnel with the source MAC address of the serving ASN-GW and destination MAC address of the BS. =20 For the anchored "bridge" even though the packets look almost the same on level-0 they are different. Since the packets are coming through an arbitrary network it is safe to assume that multiple GRE tunnels from different serving ASN-GW's will be connected through a single physical router port. In which case multiple GRE tunnels will have the same source and destination depending on the direction the packets are traversing. Since all the GRE packets are traversing arbitrary network it is possible that these packets being received out of sequence of some of these packets being dropped. =20 =20 ii. Layer 1: This is the GRE aware layer of the "bridge" on this level the "bridge" knows the individual GRE flows most probably via the IP addresses. This layer is defined for the sake of completeness only and hopefully there will not be any need to use this layer. =20 On this level the bridge has as many ports/interfaces as BS's and serving ASN-GW's. It is further assumed that the bridge loop detection will be performed on this level. =20 =20 iii. Layer 2: On this layer each "GRE key" acts as an port/interface. On this level the "bridge" can see the GRE payload and sees the MAC address of the source and destination for the SS or CPE packets. For the sake of taxonomy a bridge working on this level will be referred as "hyper-bridge" to make the distinction from the bridges that generally work on level-0. =20 Since the "connection" to GRE-key mapping has two forms it is important look these cases separately: =20 =20 iii.a. Per SS GRE-key: In this scheme the BS merges all the "connections" that are coming from a specific SS and send them using the same GRE-key. For the reverse direction the BS upon receiving a packet by applying the per flow classifiers as defined in 802.16 series. =20 This case is the simplest of two, for which each SS will have an interface at level_2 "hyper-bridge" with symmetric operations. =20 =20 iii.b. Per connection GRE-key: In this scheme the BS uses a GRE-key for each connection in both directions. Since there are no restrictions on how the "connection" classifiers are to be set it is not possible to predict how they will look like. Even in this case the "hyper-bridge" needs the information regarding the paired ingress and egress ports. This is due to the fact that the packets may be send and received through different GRE-keys and the bridge has no means of automatically figuring how to pair ingress and egress GRE sub-tunnels. =20 To give some examples and their implication at "hyper-bridge" level:=20 =20 =20 iii.b.I. There is a specific "connection" for one or many CPE's (including SS) in both directions.=20 =20 The fact that the GRE sub-tunnels can be paired helps a lot, but the fact that there are interface bundles that belong to the same broadcast group makes the broadcast and multicast decisions very hard on the "hyper-bridge" level. =20 =20 iii.b.II. There is one upstream "connection" and a number of downstream "connections".=20 =20 In this case the "hyper-bridge" needs to decide which connection the "hyper-bridge" generated packets is to be sent, meaning that the ingress port and egress ports will be different for the "hyper-bridge" in other words the connection classifier information is to reside in the "hyper-bridge". =20 =20 =20 iii.b.III. There are a number of upstream and downstream "connections". =20 This is the most general case that the "hyper-bridge" generated packets needs to be applied to the same classifiers as the connections meaning that the information is to reside in the "hyper-bridge" as well. =20 =20 =20 Above levels can be summed as illustrated below: =20 =20 =20 Hyper-bridge Level_2 Level_0 Level_1 _________ Level_1 Level_0 Physical | GRE_1 | GRE_1-Key1 | |GRE_1-Key1 | GRE_1 | Port |/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D------------| |------------=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\| Physical =3D=3D=3D=3D=3D=3D=3D=3D=3D| GRE_2 | |GRE_1-Key2 | = |GRE_1-Key2 | | GRE_2 | Port BS |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| \-----------| = |-----------/ |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D AR or | ... | ... | | ... | ... | ASN-GW Router | GRE_n | GRE_n_Key_m | | GRE_n-Keym | GRE_n | Port |\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|--------------| |--------------|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/| Carrying | | ---------- | | Multiple | | | | GRE | ---------------------------------------- | flows | level_1 "bridge" | from |--------------------------------------------------------------------| many Level_0 "bridge" BS's. =20 =20 =20 =20 Coming to normative requirements stated in the draft: =20 =20 =20 1. Section 5.3 states that: "The BS SHALL forward all the radio connections belonging to one SS to a port of a bridge between all ports on the radio side and the interfaces towards the network side." =20 I guess this means that if BS has multiple interfaces it will send all the packets through the physical interface that is connected to "the bridge". I have trouble to understand this requirement, is it desired that all the packets send through the same GRE tunnel?=20 =20 2. Section 5.3 further states: "If the SS functions as a bridge then it SHALL support a bridging between all its LAN ports and the airlink." =20 I am not sure why we have this as a requirement, as a principle I am against mandating unnecessary behavior. Further, I would like to point out that bridging is not defined. I am surprised to find that 802.1d-2004 is referenced as an informative. =20 3. The last paragraph/sentence of the section 5.3 states: "When performing bridging, any packets destined for one of the addresses in the Filtering Database SHALL be forwarded directly to that port, if appropriate for the particular scenario, and all packets received from a port, for which the packet's destination MAC address is also an entry for that port in the Filtering Database, SHALL be silently discarded." =20 First since it is not explicitly clear where it is applicable I assume that this behavior is applicable to both SS as a bridge and the "bridge". What is missing is the behavior when an entry is deleted from the Dynamic Filtering Entry. In the non-normative section the BRIDGETIMEOUT is used without a default value or definition. There is a non-normative shall that defines the use of BRIDGETIMEOUT that uses the term traffic but does not describe whether this is for bi-directional traffic or not. =20 It is not clear at which level this bridge operates: level_0, level_1 or level_2? Since the usage of SS (I would like the term CPE and would like to see CPE to include SS) implies that this is a behavior of "hyper-bridge".=20 =20 If the behavior is for a "hyper-bridge", the issue of interfaces as discussed in iii.b. is applicable. =20 4. Section 6.1 states: "In this scenario, the bridge SHALL forward all packets received from any radio side port to a network side port." =20 First of all the applicability of this normative statement is not clear, and second I am missing the difference between this statement and statement discussed in bullet 1. Having said that, I miss the need for this requirement. =20 It is not clear at which level this bridge operates: level_0, level_1 or level_2? The only evidence is against the level_0 is the fact that this defined behavior completely disables R8 interface of WiMAX specifications. =20 5. Section 7.2 states: "The bridge SHALL have the ability to enable or disable any filtering functionality defined herein." =20 It is not clear whether this is a flow specific or not. At this point of time my interpretation is that this is a global switch. =20 6. Section 7.2 further states: "If a packet is filtered it SHALL be silently discarded." =20 It is not clear at which level this bridge operates: level_0, level_1 or level_2? The context implies that this is a level_2 functionality thereby the bridge is actually a "hyper-bridge". =20 One of the side-effects of being a "hyper-bridge" is the fact that whenever a packet is dropped it, it will not be send through the GRE tunnel, and whenever a new packet is to be send by the "hyper-bridge" needs to insert an additional packet into the GRE tunnel with relevant GRE-key.=20 =20 The insertion/removal of GRE packets make the case that the GRE sequence numbers cannot be used without making the "hyper-bridge" a kind of back-to-back GRE relay that re-sequences. =20 If there are no re-sequencers in the "bridge" and sequence numbers are being used there needs to be either a dummy packet insertion or a missing packet within the GRE tunnel. Due to the fact that the missing sequence numbers has the impact of delaying the packets out of the tunnel, it is assumed that the dummy packet generation method is being suggested. For the sake of compatibility the dummy packet is to be defined clearly. =20 7. Section 7.2 states that: "The bridge SHALL support filtering of all packets received from a network side port to a destination MAC address or Multicast IP address not existing in the ICT or expired address." =20 If this sentence is taken to its face value, there is no way that an expired address to be reached by an external communication.=20 =20 As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2.=20 =20 It is important to point out that all the wording suggests that this is a bridge operating at level_2 "hyper-bridge". On this level the "hyper-bridge" receives a MAC packet through a physical port, if the packet is a GRE packet it opens the GRE packet, looks at the inner MAC address, and than makes a lookup against its Identification Cache Table, if the entry does match it sends the GRE packet to the port stated in the ICT. =20 8. Section 7.2 states that: "The bridge SHALL support filtering of all packets received from a network side port to a broadcast or all-nodes multicast MAC address." =20 What this requirement does is disabling the all means of communication from the network if the CPE MAC address has expired. When the fact that there are no normative requirements on the "bridge" to learn is added, it is very hard to have a predictable behavior between the "bridges" that are within this draft. =20 As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2. =20 It is important to point out that all the wording suggests that this is a bridge operating at level_2 "hyper-bridge". On this level the "hyper-bridge" receives a MAC packet through a physical port, if the packet is a GRE packet it opens the GRE packet, looks at the inner MAC address, if the inner MAC address is broadcast, removes the packet and sends the next packet with next sequence number (if sequence numbers are being used) to the ASN-GW thereby creating a hole in the GRE sequence. =20 =20 One question regarding the requirement is that some DHCP Offers are send as MAC broadcast messages, and this requirement prevents these hosts to get an IP address. =20 9. Section 7.2 further states: "The bridge SHALL support filtering of all packets received from a network side port to a broadcast or all-nodes multicast MAC address. =20 I am not sure why this restriction is in place.=20 =20 As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2. =20 It is important to point out that all the wording suggests that this is a bridge operating at level_2 "hyper-bridge". On this level the "hyper-bridge" receives a MAC packet through a physical port, if the packet is a GRE packet it opens the GRE packet, looks at the inner MAC address, and if the packet is coming from a radio side level_2 interface and the MAC address is broadcast the "hyper-bridge" deletes the packet and sends the next packet with next sequence number (if sequence numbers are being used) to the ASN-GW thereby creating a hole in the GRE sequence. =20 10. The last paragraph/sentence on section 7.2 states that: "If filtering is enabled the bridge SHALL permit all Address Resolution Protocol messages to pass to the ARP Proxy Agent and all Neighbor Discovery messages to pass to the Neighbor Discovery (ND) Relay Agent for additional processing as specified in following section." =20 As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2. =20 It is important to point out that all the wording suggests that this is a bridge operating at level_2 "hyper-bridge". It is important to note that the proxy ARP referred receives packets that are within GRE tunnel and send packets through GRE tunnel. =20 11. The Section 7.3 states: "For IPv4 over Ethernet, ICT contains MAC address and Port Map, which constitute a filtering entry in Filtering Database, tunnel ID, lifetime, and one or more unicast and multicast IPv4 addresses." =20 The mentioning of the tunnel ID strongly suggests a "hyper-bridge" operation. The problem of ingress and egress tunnel-ID has no solution offered and has to be mentioned using two tunnel ID's. =20 12. Section 7.4 states that: "The AR SHALL have packet-relay functionality." =20 The packet-relay is not defined within this document and since document only as informational references this is a hard to test item if not impossible. =20 13. Section 8.1.1 states that: "The bridge SHALL support an ARP Proxy." =20 As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2. =20 It is important to point out that all the wording suggests that this is a bridge operating at level_2 "hyper-bridge". On this level the "hyper-bridge" receives a MAC packet through a physical port, if the packet is a GRE packet it opens the GRE packet, looks at the inner packet, if the inner packet is ARP, it passes the packet to the proxy ARP. The Proxy ARP resolves a return MAC address which is set by an undetermined method. Than it will construct an ARP Reply packet and through an undetermined method decides which GRE sub-tunnel (GRE-key) will be used (see iii for issues). Next it will construct a GRE encapsulation, the GRE sequence number has to be recalculated, and than send it to the proper BS.=20 =20 =20 =20 These are some of the issues that has to be cleared before a through reading of the draft can be carried out. =20 -burcak =20 ------_=_NextPart_001_01C7335C.692117CE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have to admit that at this point of time I am = confused. The draft has some details and a lot of information that I am not sure = how these interconnect.

 

Let me start from the = beginning:

 

(The below described usage is the WiMAX mandatory = supported transport of packets and all the descriptions and especially normative = language has to deal with these details.)

 

 

Per WiMAX specifications (see http://www.wimaxforum.org/technology/documents/WiMAX_End_to_End_Network_S= ystems_Architecture.zip) each “connection” between SS and BS indicated by a unique = CID within a single BS domain is mapped into a GRE tunnel in and in some = other cases all CID’s coming from a single SS is mapped into a GRE = tunnel identified by a “GRE key”. Now, it is important to note that the  “connections” per IEEE 802.16 specifications is = left very liberal in the means that they may be used. It is possible that there is = a single uplink “connection” which has associated multiple = downlink “connections”. If there are no limitations on the CPE = generated packets it is possible that the CPE packets will be fragmented as in the = case of IPSEC tunnels, and will be fragmented again on the GRE = level.

 

 

      SS_A CID1 BS = GRE-key1

 

CPE = -----|------|------------\

         |      |            = \

CPE------| CID2 |  GRE-key2    = \

CPE = -----|------|---------------\

        &nbs= p;       |            =     \      GRE

.        &nb= sp;      |            =     /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

.        &nb= sp;      |            =    /

        &nbs= p;       |            =   /

CID3  SS_Z CID* |   GRE-keyn  = /

---------|------|------------/

 

 

The BS sends these packets through the GRE tunnel = to the ASN-GW which is a layer-3 device and designated in the draft as Access = Router (AR). Per WiMAX specifications the ASN-GW actually can be divided into = two as being serving ASN-GW which is the entity that the BS is connected = (through the draft defined bridge) which re-maps the packets (GRE payloads) to = another GRE tunnel to the anchored ASN-GW (again through the draft defined bridge). = Where the final figure looks like as below:

 

 

      CID         GRE_1        GRE_2           GRE_3          GRE_3      GRE_4

SS ---------- BS ------ Bridge ------ serving ----- arbitrary ----- Bridge -------- anchored

        &nbs= p;            = ;  (serving)      = ASN-GW         network      (anchored)         = ASN-GW

 

 

We can say that for each CID there is a GRE tunnel = where GRE_1 and GRE_2 are the same tunnel and GRE_3 and GRE_4 are the same = tunnel further the GRE_1/2 and GRE_3/4 are one-to-one = mapped.

 

This brings the draft introduced = “Bridge”, which has different interpretations; for the sake of taxonomy I think = the bridge as having 3 layers:

 

 

i. Layer 0: This is the 802.1d-2004 defined layer = where the physical interfaces are the interfaces. It is very easy to decide = where a packet is received and which interface you can send a packet. On this = level the bridge supports a limited number of = traffic:

 

* GRE tunnel: This is the traffic between the BS(s) = and the ASN-GW(s). All BS(s) are sending packets to serving = ASN-GW(s).

 

* ASN Control packets: These are packets exchanged = between BS and ASN-GW for various purposes.

 

* Inter BS communications: This is the R8 interface = of the WiMAX specification although it is not specified it may = exist.

 

It is important to note that any packets generated = by SS or any CPE behind it is send through the GRE tunnel which will always = have the serving ASN-GW’s MAC address for destination and  BS’ = MAC address for source, and all the downstream packets destined for the SS = or CPE’s are send by the ASN-GW via the GRE tunnel with the source MAC address of = the serving ASN-GW and destination MAC address of the = BS.

 

For the anchored “bridge” even though = the packets look almost the same on level-0 they are different. Since the = packets are coming through an arbitrary network it is safe to assume that = multiple GRE tunnels from different serving ASN-GW’s will be connected through = a single physical router port. In which case multiple GRE tunnels will = have the same source and destination depending on the direction the packets are traversing. Since all the GRE packets are traversing arbitrary network = it is possible that these packets being received out of sequence of some of = these packets being dropped.

 

 

ii. Layer 1: This is the GRE aware layer of the “bridge” on this level the “bridge” knows the individual GRE flows most probably via the IP addresses. This layer is = defined for the sake of completeness only and hopefully there will not be any = need to use this layer.

 

On this level the bridge has as many = ports/interfaces as BS’s and serving ASN-GW’s. It is further assumed that the = bridge loop detection will be performed on this = level.

 

 

iii. Layer 2: On this layer each “GRE = key” acts as an port/interface. On this level the “bridge” can = see the GRE payload and sees the MAC address of the source and destination for = the SS or CPE packets. For the sake of taxonomy a bridge working on this level = will be referred as “hyper-bridge” to make the distinction from the = bridges that generally work on level-0.

 

Since the “connection” to GRE-key = mapping has two forms it is important look these cases = separately:

 

 

iii.a. Per SS GRE-key: In this scheme the BS merges = all the “connections” that are coming from a specific SS and = send them using the same GRE-key. For the reverse direction the BS upon receiving = a packet by applying the per flow classifiers as defined in 802.16 = series.

 

This case is the simplest of two, for which each SS = will have an interface at level_2 “hyper-bridge” with symmetric operations.

 

 

iii.b. Per connection GRE-key: In this scheme the = BS uses a GRE-key for each connection in both directions. Since there are no restrictions on how the “connection” classifiers are to be = set it is not possible to predict how they will look like. Even in this case = the “hyper-bridge” needs the information regarding the paired = ingress and egress ports. This is due to the fact that the packets may be send = and received through different GRE-keys and the bridge has no means of automatically figuring how to pair ingress and egress GRE = sub-tunnels.

 

To give some examples and their implication at “hyper-bridge” level:

 

 

iii.b.I. There is a specific = “connection” for one or many CPE’s (including SS) in both directions. =

 

The fact that the GRE sub-tunnels can be paired = helps a lot, but the fact that there are interface bundles that belong to the same = broadcast group makes the broadcast and multicast decisions very hard on the “hyper-bridge” level.

 

 

iii.b.II. There is one upstream = “connection” and a number of downstream “connections”. =

 

In this case the “hyper-bridge” needs = to decide which connection the “hyper-bridge” generated packets = is to be sent, meaning that the ingress port and egress ports will be = different for the “hyper-bridge” in other words the connection classifier = information is to reside in the = “hyper-bridge”.

 

 

 

iii.b.III. There are a number of upstream and = downstream “connections”.

 

This is the most general case that the “hyper-bridge” generated packets needs to be applied to the = same classifiers as the connections meaning that the information is to reside = in the “hyper-bridge” as well.

 

 

 

Above levels can be summed as illustrated = below:

 

 

 

        &nbs= p;            = ;            =      Hyper-bridge

        &nbs= p;                  &= nbsp;           &n= bsp;Level_2

         Level_0   Level_1           =   _________          &nbs= p;  Level_1       = Level_0

Physical | = GRE_1        |   GRE_1-Key1 |        |GRE_1-Key1    | = GRE_1        |

Port     |/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D------------|  =       |------------=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\| = Physical

=3D=3D=3D=3D=3D=3D=3D=3D=3D| = GRE_2        |  |GRE_1-Key2 |        = |GRE_1-Key2 |  | GRE_2        | = Port

BS       |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|  = \-----------|        |-----------/  = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D = AR

or       |  ...         |  ...         |        |   ...        |  ...         |      ASN-GW

Router   | GRE_n        | GRE_n_Key_m  |        | GRE_n-Keym   | GRE_n        = |

Port     |\=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|--------------|  &nbs= p;     |--------------|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D/|

Carrying |            =   |            =   ----------          &nb= sp;   |            =   |

Multiple = |            =   |            =             &= nbsp;           &n= bsp; |            =   |

GRE      |            =   ----------------------------------------     &nb= sp;        |

flows    |                &= nbsp;           &n= bsp;  level_1 “bridge”         = ;            |

from     = |--------------------------------------------------------------------|

many        =       Level_0 “bridge”

BS’s.

 

 

 

 

Coming to normative requirements stated in the = draft:

 

 

 

1. Section 5.3 states that: “The BS SHALL = forward all the radio connections belonging to one SS to a port of a bridge = between all ports on the radio side and the interfaces towards the network = side.”

 

I guess this means that if BS has multiple = interfaces it will send all the packets through the physical interface that is = connected to “the bridge”. I have trouble to understand this requirement, = is it desired that all the packets send through the same GRE tunnel? =

 

2. Section 5.3 further states: “If the SS = functions as a bridge then it SHALL support a bridging between all its LAN ports = and the airlink.”

 

I am not sure why we have this as a requirement, as = a principle I am against mandating unnecessary behavior. Further, I would = like to point out that bridging is not defined. I am surprised to find that = 802.1d-2004 is referenced as an informative.

 

3. The last paragraph/sentence of the section 5.3 = states: “When performing bridging, any packets destined for one of the = addresses in the Filtering Database SHALL be forwarded directly to that port, if appropriate for the particular scenario, and all packets received from a = port, for which the packet's destination MAC address is also an entry for that = port in the Filtering Database, SHALL be silently = discarded.”

 

First since it is not explicitly clear where it is applicable I assume that this behavior is applicable to both SS as a = bridge and the “bridge”. What is missing is the behavior when an entry = is deleted from the Dynamic Filtering Entry. In the non-normative section = the BRIDGETIMEOUT is used without a default value or definition. There is a non-normative shall that defines the use of BRIDGETIMEOUT that uses the = term traffic but does not describe whether this is for bi-directional traffic = or not.

 

It is not clear at which level this bridge = operates: level_0, level_1 or level_2? Since the usage of SS (I would like the = term CPE and would like to see CPE to include SS) implies that this is a behavior = of “hyper-bridge”.

 

If the behavior is for a = “hyper-bridge”, the issue of interfaces as discussed in iii.b. is = applicable.

 

4. Section 6.1 states: “In this scenario, the = bridge SHALL forward all packets received from any radio side port to a network = side port.”

 

First of all the applicability of this normative = statement is not clear, and second I am missing the difference between this = statement and statement discussed in bullet 1. Having said that, I miss the need for = this requirement.

 

It is not clear at which level this bridge = operates: level_0, level_1 or level_2? The only evidence is against the level_0 is = the fact that this defined behavior completely disables R8 interface of = WiMAX specifications.

 

5. Section 7.2 states: “The bridge SHALL have = the ability to enable or disable any filtering functionality defined = herein.”

 

It is not clear whether this is a flow specific or = not. At this point of time my interpretation is that this is a global = switch.

 

6. Section 7.2 further states: “If a packet = is filtered it SHALL be silently = discarded.”

 

It is not clear at which level this bridge = operates: level_0, level_1 or level_2? The context implies that this is a level_2 functionality thereby the bridge is actually a = “hyper-bridge”.

 

One of the side-effects of being a “hyper-bridge” is the fact that whenever a packet is dropped = it, it will not be send through the GRE tunnel, and whenever a new packet is to = be send by the “hyper-bridge” needs to insert an additional = packet into the GRE tunnel with relevant GRE-key.

 

The insertion/removal of GRE packets make the case = that the GRE sequence numbers cannot be used without making the “hyper-bridge” a kind of back-to-back GRE relay that = re-sequences.

 

If there are no re-sequencers in the = “bridge” and sequence numbers are being used there needs to be either a dummy = packet insertion or a missing packet within the GRE tunnel. Due to the fact = that the missing sequence numbers has the impact of delaying the packets out of = the tunnel, it is assumed that the dummy packet generation method is being suggested. For the sake of compatibility the dummy packet is to be = defined clearly.

 

7. Section 7.2 states that: “The bridge SHALL support filtering of all packets received from a network side port to a destination MAC address or Multicast IP address not existing in the ICT = or expired address.”

 

If this sentence is taken to its face value, there = is no way that an expired address to be reached by an external communication. =

 

As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2.

 

It is important to point out that all the wording = suggests that this is a bridge operating at level_2 “hyper-bridge”. = On this level the “hyper-bridge” receives a MAC packet through a = physical port, if the packet is a GRE packet it opens the GRE packet, looks at = the inner MAC address, and than makes a lookup against its Identification Cache = Table, if the entry does match it sends the GRE packet to the port stated in the = ICT.

 

8. Section 7.2 states that: “The bridge SHALL support filtering of all packets received from a network side port to a = broadcast or all-nodes multicast MAC address.”

 

What this requirement does is disabling the all = means of communication from the network if the CPE MAC address has expired. When = the fact that there are no normative requirements on the = “bridge” to learn is added, it is very hard to have a predictable behavior between = the “bridges” that are within this = draft.

 

As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2.

 

It is important to point out that all the wording = suggests that this is a bridge operating at level_2 “hyper-bridge”. = On this level the “hyper-bridge” receives a MAC packet through a = physical port, if the packet is a GRE packet it opens the GRE packet, looks at = the inner MAC address, if the inner MAC address is broadcast, removes the packet = and sends the next packet with next sequence number (if sequence numbers are = being used) to the ASN-GW thereby creating a hole in the GRE sequence.  =

 

One question regarding the requirement is that some = DHCP Offers are send as MAC broadcast messages, and this requirement prevents = these hosts to get an IP address.

 

9. Section 7.2 further states: “The bridge = SHALL support filtering of all packets received from a network side port to a broadcast or all-nodes multicast MAC = address.

 

I am not sure why this restriction is in place. =

 

As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2.

 

It is important to point out that all the wording = suggests that this is a bridge operating at level_2 “hyper-bridge”. = On this level the “hyper-bridge” receives a MAC packet through a = physical port, if the packet is a GRE packet it opens the GRE packet, looks at = the inner MAC address, and if the packet is coming from a radio side level_2 = interface and the MAC address is broadcast the “hyper-bridge” deletes = the packet and sends the next packet with next sequence number (if sequence = numbers are being used) to the ASN-GW thereby creating a hole in the GRE = sequence.

 

10. The last paragraph/sentence on section 7.2 = states that: “If filtering is enabled the bridge SHALL permit all Address Resolution Protocol messages to pass to the ARP Proxy Agent and all = Neighbor Discovery messages to pass to the Neighbor Discovery (ND) Relay Agent = for additional processing as specified in following = section.”

 

As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2.

 

It is important to point out that all the wording = suggests that this is a bridge operating at level_2 “hyper-bridge”. = It is important to note that the proxy ARP referred receives packets that are = within GRE tunnel and send packets through GRE = tunnel.

 

11. The Section 7.3 states: “For IPv4 over = Ethernet, ICT contains MAC address and Port Map, which constitute a filtering = entry in Filtering Database, tunnel ID, lifetime, and one or more unicast and = multicast IPv4 addresses.”

 

The mentioning of the tunnel ID strongly suggests a “hyper-bridge” operation. The problem of ingress and egress tunnel-ID has no solution  offered and has to be mentioned using = two tunnel ID’s.

 

12. Section 7.4 states that: “The AR SHALL = have packet-relay functionality.”

 

The packet-relay is not defined within this = document and since document only as informational references this is a hard to test = item if not impossible.

 

13. Section 8.1.1 states that: “The bridge = SHALL support an ARP Proxy.”

 

As usual it is not clear at which level this bridge operates: level_0, level_1 or level_2.

 

It is important to point out that all the wording = suggests that this is a bridge operating at level_2 “hyper-bridge”. = On this level the “hyper-bridge” receives a MAC packet through a = physical port, if the packet is a GRE packet it opens the GRE packet, looks at = the inner packet, if the inner packet is ARP, it passes the packet to the proxy = ARP. The Proxy ARP resolves a return MAC address which is set by an undetermined = method. Than it will construct an ARP Reply packet and through an undetermined = method decides which GRE sub-tunnel (GRE-key) will be used (see iii for = issues). Next it will construct a GRE encapsulation, the GRE sequence number has to be recalculated, and than send it to the proper BS. =

 

 

 

These are some of the issues that has to be cleared = before a through reading of the draft can be carried = out.

 

-burcak

 

------_=_NextPart_001_01C7335C.692117CE-- --===============2114827190== 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 --===============2114827190==-- From 16ng-bounces@ietf.org Mon Jan 08 16:43:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42HC-0002Cq-Cw; Mon, 08 Jan 2007 16:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H42Eu-0001WJ-6C for 16ng@ietf.org; Mon, 08 Jan 2007 16:41:08 -0500 Received: from web81909.mail.mud.yahoo.com ([68.142.207.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H42Es-0000we-Qu for 16ng@ietf.org; Mon, 08 Jan 2007 16:41:08 -0500 Received: (qmail 93140 invoked by uid 60001); 8 Jan 2007 21:41:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=qp72dZTNe22ShJoEqgfuykXcM9ENjus3+8YZJj1O7Z/3rvOicAPv/c8zcDA5meJvevEo0Cp1DRu81gErQh19byhbsN/OGfWB0EQe9dlCPM0N9q4DRicVZ2R+oTJ5oDcZTR5hnoESROE8fmGcHTRxiZapWJ31klgoZmQqxk4tfgM= ; Message-ID: <20070108214106.93138.qmail@web81909.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81909.mail.mud.yahoo.com via HTTP; Mon, 08 Jan 2007 13:41:06 PST Date: Mon, 8 Jan 2007 13:41:06 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] 2nd WGLC : draft-ietf-16ng-ipv6-over-ipv6cs-04 To: Daniel Park , 16ng@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Mon, 08 Jan 2007 16:43:29 -0500 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="===============1828126144==" Errors-To: 16ng-bounces@ietf.org --===============1828126144== Content-Type: multipart/alternative; boundary="0-1763457278-1168292466=:88966" --0-1763457278-1168292466=:88966 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Folks,=0A=0AThis 2nd WG LC was over last Friday. The authors are revising t= he draft based on received=0Acomments before we send it off to the IESG.=0A= =0A-gabriel=0A=0A----- Original Message ----=0AFrom: Daniel Park =0ATo: 16ng@ietf.org=0ASent: Thursday, December 28, 2006 3:48:09 = PM=0ASubject: [16NG] 2nd WGLC : draft-ietf-16ng-ipv6-over-ipv6cs-04=0A=0AFo= lks,=0A=0AThis is the 2nd WGLC on draft-ietf-16ng-ipv6-over-ipv6cs-04 - IPv= 6=0AOver the IP Specific part of the Packet Convergence sublayer in 802.16= =0ANetworks.=0A=0AThe latest version can be found at:=0Ahttp://www.ietf.org= /internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-04.txt=0A=0AIt will expir= e on January 5. 2007=0A=0A-- =0A=0A=0ADaniel (Soohong Daniel Park)=0AMobile= Convergence Laboratory, SAMSUNG Electronics.=0A=0A________________________= _______________________=0A16NG mailing list=0A16NG@ietf.org=0Ahttps://www1.= ietf.org/mailman/listinfo/16ng=0A=0A=0A=0A=0A --0-1763457278-1168292466=:88966 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Folks,

This 2nd WG LC was over last Friday. Th= e authors are revising the draft based on received
comments before we se= nd it off to the IESG.

-gabriel

----- Original Messag= e ----
From: Daniel Park <soohongp@gmail.com>
To: 16ng@ietf.org=
Sent: Thursday, December 28, 2006 3:48:09 PM
Subject: [16NG] 2nd WGL= C : draft-ietf-16ng-ipv6-over-ipv6cs-04

Folks,

This is t= he 2nd WGLC on draft-ietf-16ng-ipv6-over-ipv6cs-04 - IPv6
Over the IP Sp= ecific part of the Packet Convergence sublayer in 802.16
Networks.
The latest version can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ip= v6cs-04.txt

It will expire on January 5. 2007

--

=
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG = Electronics.

_______________________________________________
16NG= mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16n= g

--0-1763457278-1168292466=:88966-- --===============1828126144== 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 --===============1828126144==-- From 16ng-bounces@ietf.org Tue Jan 09 10:27:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4It9-0001Zl-SR; Tue, 09 Jan 2007 10:27:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4It8-0001Zf-KR for 16ng@ietf.org; Tue, 09 Jan 2007 10:27:46 -0500 Received: from mxs1.siemens.at ([194.138.12.131] helo=atvies1zqx.siemens.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4Isw-0006Jh-Su for 16ng@ietf.org; Tue, 09 Jan 2007 10:27:46 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by atvies1zqx.siemens.at with ESMTP id l09FOvRJ014975; Tue, 9 Jan 2007 16:24:57 +0100 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id l09FRUgM031637; Tue, 9 Jan 2007 16:27:31 +0100 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 16:27:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subject: RE: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs) Date: Tue, 9 Jan 2007 16:27:29 +0100 Message-ID: <3C31CDD06342EA4A8137716247B1CD680169EFF6@zagh223a.ww300.siemens.net> In-Reply-To: <458C071F.7020201@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs) Thread-Index: Accl5f/eXpwZpoKiQISZ8JhpuRdeQwOFNogw From: "Premec, Domagoj" To: "Alexandru Petrescu" X-OriginalArrivalTime: 09 Jan 2007 15:27:30.0309 (UTC) FILETIME=[AD294350:01C73402] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 149917::070109162457-55E2CBB0-2C71B157/0-0/0-15 X-purgate-size: 5813/999999 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: v6ops@ops.ietf.org, 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, Please see my responses inline domagoj=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: 22. prosinac 2006 17:26 > To: Premec, Domagoj > Cc: Daniel Park; v6ops@ops.ietf.org; 16ng@ietf.org > Subject: Re: [16NG] FW: Review on v6ops 802.16 deployment=20 > scenario (J Kim of AT&TLabs) >=20 > Premec, Domagoj wrote: > > Hi, > >=20 > > Thanks for the comments, the section 2.2.2.3 was written by=20 > me, please=20 > > find my response below: > >=20 > >> * Section 2.2.2.3: - In the first sentence, which "end-to-end"? > >=20 > > "end-to-end" means subscriber device <-> BRAS. >=20 > To my reading one may need to change this use of 'end-to-end'=20 > term, better don't here. In IP terms traditionally it means=20 > from one end of the Internet, across all of it, and down to=20 > another end, traversing a potentially large number of=20 > link-layer types, defined and undefined. > Related to what TCP is. >=20 > The use of 'end-to-end' as local subscriber to BRAS is=20 > confusing in a context where IP needs to run over this link. =20 > This sounds as a 'pico-e2e". >=20 > I personally would completely avoid use this term unless doing TCP I agree with you, the term end-to-end is misleading here. I should come = up with a better wording.=20 >=20 > >> - Any reference or description of "Relay DAD"? there are earlier=20 > >> occurrences > >=20 > > Relay DAD is described in 2.2.2.3. Are you just pointing out that=20 > > Relay DAD is mentioned before 2.2.2.3, so the explanation=20 > should also =20 > > be moved to the first occurance of Relay DAD? >=20 > "Relay DAD" and "ND Relay" are terms also used in=20 > draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt >=20 > I would point out to more than just moving the definition=20 > text next to the first use. >=20 > ND is defined in rfc2461 and DAD in rfc2462. None of these=20 > documents defines what a "Relay ND" or a "Relay DAD" would =20 > do. An IP machine 'relaying' ND packets from left to right,=20 > across links, instead of forwarding or routing them needs to=20 > be specified clearly and separately I believe, provided=20 > there's an identified need. >=20 > For example, the draft says: > > Relay DAD means that the Neighbor Solicitation message used in DAD=20 > > process will be relayed only to the MS which already has configured=20 > > the solicited address as its own address (if such MS exist at all). >=20 > In one sense, this is what DAD does already (not Relay DAD). > RFC2462: > > Before sending a Neighbor Solicitation, an interface MUST join the=20 > > all-nodes multicast address and the solicited-node=20 > multicast address=20 > > of the tentative address. The former insures that the node=20 > receives=20 > > Neighbor Advertisements from other nodes already using the address;=20 > > the latter insures that two nodes attempting to use the=20 > same address=20 > > simultaneously detect each other's presence. >=20 > So I could suggest removing the word 'Relay' from the draft=20 > text, just leave "DAD", and all would be fine. No, relay DAD is no ordinary DAD. The standard DAD procedure assumes = that the DAD solicitation is delivered to all the nodes using the same = prefix. Relay DAD delivers the DAD solicitation only to the node that = already owns the address being verified.=20 >=20 > In another sense, reading the draft text suggesting to send=20 > the NS to only some MSs (maybe another criteria than joining=20 > an address) makes think that it may defeat the DAD's main=20 > goal. What happens if some MS autoconfigures an address that=20 > conflicts with the one in NS and that MS doesn't see that NS. This must not happen. It is the responsibility of the bridge (the = authorative address cache) to deliver the DAD solicitation to the right = MS (the one that already owns the address being verified). >=20 > Related to 'Relay' in this context is the concept of 'proxy=20 > ND' whereby a node would do ND on behalf on another node. =20 > This is partly defined in ND rfc2461 and largely used by a=20 > Mobile IPv6 HA rfc3775. Just wanted to mention them. The intention of the relay DAD is to save the radio resources. When a = host sends a DAD solicitation, 802.16 MAC will deliver it to the BS. = Normal behavior as per RFC 2461 would be that the DAD message is = delivered to all MSs sharing the same prefix. But many of the MSs may be = in the idle mode, meaning that the delivery of the DAD message would = incur paging and wake up from idle mode, in addition to radio bandwidth = necessary to transfer the DAD solicitation itself. In relay DAD = approach, the bridge (from figure 5) is aware of all attached MSs and = their IP addresses (authorative address cache). Using this knowledge, = the bridge can deliver the DAD solicitation only to the MS that has = already configured the address being verified as its own address. And = this MS will then defend its address.=20 Yes, this is similar to HA performing proxy ND on behalf of the mobile = node. And the bridge may indeed defend the verified address on behalf of = another node (which owns the address being verified). But it is my = understanding that such (proxy ND) approach would't work with secure ND, = that's why the bridge, in case of address conflict, will relay the DAD = solicitation to the MS so that the MS itslef can defend the address. I-D draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt also mentiones = relay DAD. It does provide some additional details. We should probaby = define relay DAD just in one document and then refer to it form other = documents. domagoj >=20 > Thanks, >=20 > Alex >=20 _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 09 17:02:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4P2r-0002Xv-LL; Tue, 09 Jan 2007 17:02:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4P2q-0002Xp-E7 for 16ng@ietf.org; Tue, 09 Jan 2007 17:02:12 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4P2p-0008Cd-TS for 16ng@ietf.org; Tue, 09 Jan 2007 17:02:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1168380130!12583335!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2953 invoked from network); 9 Jan 2007 22:02:10 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 9 Jan 2007 22:02:10 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l09M28uP027999; Tue, 9 Jan 2007 15:02:10 -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 l09M25m5010416; Tue, 9 Jan 2007 16:02:06 -0600 (CST) Message-ID: <45A410DC.4070702@motorola.com> Date: Tue, 09 Jan 2007 23:02:04 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Premec, Domagoj" Subject: Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs) References: <3C31CDD06342EA4A8137716247B1CD680169EFF6@zagh223a.ww300.siemens.net> In-Reply-To: <3C31CDD06342EA4A8137716247B1CD680169EFF6@zagh223a.ww300.siemens.net> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: v6ops@ops.ietf.org, 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 Domagoj, thanks for the email, skipping the parts we agree... Premec, Domagoj wrote: >>>> - Any reference or description of "Relay DAD"? there are >>>> earlier occurrences >>> Relay DAD is described in 2.2.2.3. Are you just pointing out that >>> Relay DAD is mentioned before 2.2.2.3, so the explanation should >>> also be moved to the first occurance of Relay DAD? "Relay DAD" >>> and "ND Relay" are terms also used in >>> draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt >> >> I would point out to more than just moving the definition text next >> to the first use. >> >> ND is defined in rfc2461 and DAD in rfc2462. None of these >> documents defines what a "Relay ND" or a "Relay DAD" would do. An >> IP machine 'relaying' ND packets from left to right, across links, >> instead of forwarding or routing them needs to be specified >> clearly and separately I believe, provided there's an identified >> need. >> >> For example, the draft says: >>> Relay DAD means that the Neighbor Solicitation message used in >>> DAD process will be relayed only to the MS which already has >>> configured the solicited address as its own address (if such MS >>> exist at all). >> In one sense, this is what DAD does already (not Relay DAD). >> RFC2462: >>> Before sending a Neighbor Solicitation, an interface MUST join >>> the all-nodes multicast address and the solicited-node multicast >>> address of the tentative address. The former insures that the >>> node receives Neighbor Advertisements from other nodes already >>> using the address; the latter insures that two nodes attempting >>> to use the same address simultaneously detect each other's >>> presence. >> So I could suggest removing the word 'Relay' from the draft text, >> just leave "DAD", and all would be fine. > > No, relay DAD is no ordinary DAD. The standard DAD procedure assumes > that the DAD solicitation is delivered to all the nodes using the > same prefix. Relay DAD delivers the DAD solicitation only to the node > that already owns the address being verified. Not very sure about that. The DADing NS is sent to an IP solicited-node multicast address. Not all nodes in the subnet join that address, only the ones whose last 24bits of MAC address match the Tentative Address. The DAD procedure doesn't assume the DADing NS is sent to all nodes multicast address (with link-scope). rfc2462 5.4.2: "IP destination is set to the solicited-node multicast address of the target address." The IP dst address would be FF02:0:0:0:0:1:FFXX:XXXX (X: last 24bits of MAC address). The link-layer dst multicast address would be 33-33-FF-XX-XX-XX I believe (X: last 24bits of MAC address, for IPv4 it's different: 23bits). If one desires to deliver the DADing NS only to one particular node (and not to a group) then one would put the full IP address in the dst, and the full MAC address in the link-layer dst. And this behaviour is not specified by DAD (not sure whether it's forbidden, but it's not spec'ed in rfc2462). >> In another sense, reading the draft text suggesting to send the NS >> to only some MSs (maybe another criteria than joining an address) >> makes think that it may defeat the DAD's main goal. What happens >> if some MS autoconfigures an address that conflicts with the one in >> NS and that MS doesn't see that NS. > > This must not happen. It is the responsibility of the bridge (the > authorative address cache) to deliver the DAD solicitation to the > right MS (the one that already owns the address being verified). Ok, I think we have identified a good responsability for the bridge, and this is inline with my understanding of bridge making link-layer multicast work ok. This bridge could also implement 802.1D and 802.1Q. More precisely maybe the GARP Multicast Registration Protocol (GMRP). With this link-layer LLC protocol, a GARP participant declares to another about the group it wants to receive. This happens with LLC PDUs (not IP packets). I think, no? In this case the BS would not forward the DADing NS to the nodes that haven't joined the link-layer solicited node multicast address. So if the BS does that then bandwidth wouldn't be wasted and waking up idle modes wouldn't be, no? >> Related to 'Relay' in this context is the concept of 'proxy ND' >> whereby a node would do ND on behalf on another node. This is >> partly defined in ND rfc2461 and largely used by a Mobile IPv6 HA >> rfc3775. Just wanted to mention them. > > The intention of the relay DAD is to save the radio resources. When a > host sends a DAD solicitation, 802.16 MAC will deliver it to the BS. > > > Ok. > Normal behavior as per RFC 2461 would be that the DAD message is > delivered to all MSs sharing the same prefix. Not to all, just those that joined the group (small, maybe 1-sized) of solicited node mc address. No? > But many of the MSs may be in the idle mode, meaning that the > delivery of the DAD message would incur paging and wake up from idle > mode, in addition to radio bandwidth necessary to transfer the DAD > solicitation itself. Yes, two things: avoid waking up and avoid unnecessary bw consumption. To avoid consuming bandwidth the BS shouldn't send the DADing NS to all nodes under it. This can be achieved with a link-layer multicast protocol (not IP) and normal DAD. To avoid waking up the idle node, the SS Eth drivers (under a BS not doing that multicast link-layer stuff) can avoid putting the received packet to the kernel stack, based on the local driver table it maintains about the link-layer multicast groups it listens too. Most Eth drivers on a SS are able to filter what they receive (not deliver to IP stack). Some drivers are sensitive to packets received on Eth and will wake up the node for any packet, some are more picky. I agree though that _if_ DADing NS were sent to all-nodes multicast address then it would potentially involve waking up all those who joined that group, thus all nodes in a subnet. > In relay DAD approach, the bridge (from figure 5) is aware of all > attached MSs and their IP addresses (authorative address cache). > Using this knowledge, the bridge can deliver the DAD solicitation > only to the MS that has already configured the address being verified > as its own address. And this MS will then defend its address. Yes, this is what normal DAD would do too (not Relay), provided the node joined that solicited-node address. No? The bridge should be able to do Ethernet multicast and I believe many are, no? Otherwise in a hierarchy of bridges all broadcasted packets would be seen by everyone, and this doesn't happen in the wired world. > Yes, this is similar to HA performing proxy ND on behalf of the > mobile node. And the bridge may indeed defend the verified address on > behalf of another node (which owns the address being verified). But > it is my understanding that such (proxy ND) approach would't work > with secure ND, that's why the bridge, in case of address conflict, > will relay the DAD solicitation to the MS so that the MS itslef can > defend the address. Ah I see! But Relay ND would have its own issues with SeND - right? I think one can build attacks on both proxy ND and on 'Relay' ND. > I-D draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt also > mentiones relay DAD. It does provide some additional details. We > should probaby define relay DAD just in one document and then refer > to it form other documents. Yes, Relay ND looks as a new functionality that deserves separate documentation. For one it's obviously different IPv4 (Relay ARP?) than IPv6 at least because (1) IPv4 doesn't require the use of link-local multicast addresses and (2) address duplication detection for IPv4 link-local addresses is different than DAD. So I would suggest separation that the IPv6-over-ETH draft in two: IPv6 and IPv4. And the Relay DAD draft too in two: Relay DAD and Relay ARP. For Relay DAD, if there's enough energy and need to document as a specific functionality (like proxy ND) then I think it needs requirements and goals too. Otherwise it could be documented as an informational feature that has probably been implemented(?) or needed by an SDO(?). Thanks, Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 10 06:01:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bCT-0005p5-VF; Wed, 10 Jan 2007 06:00:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4bCS-0005p0-BX for 16ng@ietf.org; Wed, 10 Jan 2007 06:00:56 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4bCQ-0002Ta-J7 for 16ng@ietf.org; Wed, 10 Jan 2007 06:00:56 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1168426853!2882468!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25477 invoked from network); 10 Jan 2007 11:00:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 10 Jan 2007 11:00:53 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0AB0meF027280; Wed, 10 Jan 2007 04:00:48 -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 l0AB0j6v019280; Wed, 10 Jan 2007 05:00:46 -0600 (CST) Message-ID: <45A4C75A.8020903@motorola.com> Date: Wed, 10 Jan 2007 12:00:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Burcak Beser Subject: Re: [16NG] Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 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 Burcak, I'm not author of the document. I agree with some points in your mail. The authors' point of view (when expressed) should be taken as clarification to your request. In what follows I snipped the bridge description you provide (layer0,1,2 and hyperbridge) and responded to the points I agree in your mail, giving my motivation. Overall, I don't think IPv6/ETHCS should use GRE keys, nor GRE seq no, and that this document shouldn't specify at all link-layer behaviour (the 'SHALL' statements on bridge behaviour are useless here). A clarification on DHCP/broadcast and router behaviour is in too. Burcak Beser wrote: > (The below described usage is the WiMAX mandatory supported transport > of packets and all the descriptions and especially normative > language has to deal with these details.) Allow me to just suggest that some discussion may be raised to you about this point, in that it may be suggested to you that this group doesn't do WiMax at all but 802.16. It's also been pointed out that WiMax is the only user of 802.16, as well as it's too early to know which will get widespread acceptance WiMax or 802.16 (Ethernet vs 802.3 for IP took like 10years to clear out, was said). > Per WiMAX specifications (see > http://www.wimaxforum.org/technology/documents/WiMAX_End_to_End_Network_Systems_Architecture.zip) > each “connection” between SS and BS indicated by a unique CID within > a single BS domain is mapped into a GRE tunnel in and in some other > cases all CID’s coming from a single SS is mapped into a GRE tunnel > identified by a “GRE key”. Just a note that the most recent GRE spec (rfc2784) deprecates the use of GRE key (rfc2784). The GRE header is also changed - optional parts disappeared. I don't know why WiMax would continue use GRE keys to identify the tunnels. Other ways can be done, with the short rfc2784 GRE header. [skipping description of layer 0, 1, 2 of bridges and hyper-bridges, check the original poster's mail] > Coming to normative requirements stated in the draft: > > 1. Section 5.3 states that: “The BS SHALL forward all the radio > connections belonging to one SS to a port of a bridge between all > ports on the radio side and the interfaces towards the network side.” > > > > > I guess this means that if BS has multiple interfaces it will send > all the packets through the physical interface that is connected to > “the bridge”. I have trouble to understand this requirement, is it > desired that all the packets send through the same GRE tunnel? I think it shouldn't be required for BS to send all packets through the same GRE tunnel. I think some deployments may use a full bridge instead of a simple BS. Or even a full access router instead of a dumb BS. In these cases GRE tunnels won't be needed. > 2. Section 5.3 further states: “If the SS functions as a bridge then > it SHALL support a bridging between all its LAN ports and the > airlink.” > > I am not sure why we have this as a requirement, as a principle I am > against mandating unnecessary behavior. Further, I would like to > point out that bridging is not defined. I am surprised to find that > 802.1d-2004 is referenced as an informative. I think that requirement is not necessary, but not because bridging is not defined. It's simply because this document shouldn't specify a link-layer behaviour. This is an IETF document and can't define link-layer behaviour in such strong terms. It should interpret the link-layer behaviour as defined outside IETF and see how IP runs on it, but not define it. > 3. The last paragraph/sentence of the section 5.3 states: “When > performing bridging, any packets destined for one of the addresses in > the Filtering Database SHALL be forwarded directly to that port, if > appropriate for the particular scenario, and all packets received > from a port, for which the packet's destination MAC address is also > an entry for that port in the Filtering Database, SHALL be silently > discarded.” > > First since it is not explicitly clear where it is applicable I > assume that this behavior is applicable to both SS as a bridge and > the “bridge”. What is missing is the behavior when an entry is > deleted from the Dynamic Filtering Entry. In the non-normative > section the BRIDGETIMEOUT is used without a default value or > definition. There is a non-normative shall that defines the use of > BRIDGETIMEOUT that uses the term traffic but does not describe > whether this is for bi-directional traffic or not. Same thing for this paragraph. I don't agree this draft can use the word "SHALL" to define how an entity performs bridging. It's simply not the place to do that here. This is about networking behaviour not link-layer behaviour. > It is not clear at which level this bridge operates: level_0, level_1 > or level_2? Since the usage of SS (I would like the term CPE and > would like to see CPE to include SS) implies that this is a behavior > of “hyper-bridge”. What does CPE stand for? Customer Premises? (sorry I don't know). > 4. Section 6.1 states: “In this scenario, the bridge SHALL forward > all packets received from any radio side port to a network side > port.” > > First of all the applicability of this normative statement is not > clear, and second I am missing the difference between this statement > and statement discussed in bullet 1. Having said that, I miss the > need for this requirement. Yes, they look the same to me, and redundant. I agree I think there's no need for this requirement. IEEE can require a bridge to forward packets and this document will use this behaviour. > It is not clear at which level this bridge operates: level_0, level_1 > or level_2? The only evidence is against the level_0 is the fact > that this defined behavior completely disables R8 interface of WiMAX > specifications. In this context here I don't care about the R8 interface of the WiMax spec. If this draft proposal breaks a WiMax spec then it's to be solved between this draft's authors and WiMax. > 5. Section 7.2 states: “The bridge SHALL have the ability to enable > or disable any filtering functionality defined herein.” > > It is not clear whether this is a flow specific or not. At this point > of time my interpretation is that this is a global switch. I think I do not agree with adding filtering functionalities to a bridge in the context of making IPv6 work over EthCS. > 6. Section 7.2 further states: “If a packet is filtered it SHALL be > silently discarded.” > > It is not clear at which level this bridge operates: level_0, level_1 > or level_2? The context implies that this is a level_2 functionality > thereby the bridge is actually a “hyper-bridge”. Well, the sentence is not very clear to me either. > One of the side-effects of being a “hyper-bridge” is the fact that > whenever a packet is dropped it, it will not be send through the GRE > tunnel, and whenever a new packet is to be send by the > “hyper-bridge” needs to insert an additional packet into the GRE > tunnel with relevant GRE-key. > > > > The insertion/removal of GRE packets make the case that the GRE > sequence numbers cannot be used without making the “hyper-bridge” a > kind of back-to-back GRE relay that re-sequences. The GRE seq number is also deprecated in the newer GRE spec. So why would one use it. > If there are no re-sequencers in the “bridge” and sequence numbers > are being used there needs to be either a dummy packet insertion or a > missing packet within the GRE tunnel. Due to the fact that the > missing sequence numbers has the impact of delaying the packets out > of the tunnel, it is assumed that the dummy packet generation method > is being suggested. For the sake of compatibility the dummy packet > is to be defined clearly. I agree. I think that there may be a need to define clearly how GRE works in 802.16. Probably 802.16 already done that (I don't know). Don't know either whether GRE for 802.16 should be done in this IPv6 over ETHCS document. Especially knowing that one could use 802.16 between the mobile and the network but not use GRE at all. But, GRE is a generic encapsulation method, a GRE header is added between the IP header and the link-layer header. There may be a need to specify what is the used link-layer header, what is the Protocol Type field in the GRE header, etc. > 7. Section 7.2 states that: “The bridge SHALL support filtering of > all packets received from a network side port to a destination MAC > address or Multicast IP address not existing in the ICT or expired > address.” > > > > If this sentence is taken to its face value, there is no way that an > expired address to be reached by an external communication. I personally think this is not the place to specify link-layer behaviour on the bridge. > 8. Section 7.2 states that: “The bridge SHALL support filtering of > all packets received from a network side port to a broadcast or > all-nodes multicast MAC address.” > > > > What this requirement does is disabling the all means of > communication from the network if the CPE MAC address has expired. > When the fact that there are no normative requirements on the > “bridge” to learn is added, it is very hard to have a predictable > behavior between the “bridges” that are within this draft. I personally think this is not the place to specify link-layer behaviour on the bridge. > As usual it is not clear at which level this bridge operates: > level_0, level_1 or level_2. > > It is important to point out that all the wording suggests that this > is a bridge operating at level_2 “hyper-bridge”. On this level the > “hyper-bridge” receives a MAC packet through a physical port, if the > packet is a GRE packet it opens the GRE packet, looks at the inner > MAC address, if the inner MAC address is broadcast, removes the > packet and sends the next packet with next sequence number (if > sequence numbers are being used) to the ASN-GW thereby creating a > hole in the GRE sequence. > > One question regarding the requirement is that some DHCP Offers are > send as MAC broadcast messages, and this requirement prevents these > hosts to get an IP address. Well, DHCP offers aren't sent as broadcast but unicast. DHCP discover are. And indeed if link-layer broadcast for IPv4 doesn't work, or if link-layer multicast for IPv6 doesn't work, then DHCP doesn't work. > 9. Section 7.2 further states: “The bridge SHALL support filtering of > all packets received from a network side port to a broadcast or > all-nodes multicast MAC address. > > > > I am not sure why this restriction is in place. I'm not sure this is the place to specify link-layer filtering for a bridge. > 10. The last paragraph/sentence on section 7.2 states that: “If > filtering is enabled the bridge SHALL permit all Address Resolution > Protocol messages to pass to the ARP Proxy Agent and all Neighbor > Discovery messages to pass to the Neighbor Discovery (ND) Relay Agent > for additional processing as specified in following section.” > > > > As usual it is not clear at which level this bridge operates: > level_0, level_1 or level_2. To me, it is not clear what's the necessity of ND Relay Agent in first place. > It is important to point out that all the wording suggests that this > is a bridge operating at level_2 “hyper-bridge”. It is important to > note that the proxy ARP referred receives packets that are within > GRE tunnel and send packets through GRE tunnel. > > > > 11. The Section 7.3 states: “For IPv4 over Ethernet, ICT contains MAC > address and Port Map, which constitute a filtering entry in > Filtering Database, tunnel ID, lifetime, and one or more unicast and > multicast IPv4 addresses.” > > The mentioning of the tunnel ID strongly suggests a “hyper-bridge” > operation. The problem of ingress and egress tunnel-ID has no > solution offered and has to be mentioned using two tunnel ID’s. I have much more problems with that spec of the ICT (Identification Cache Table). I can rely separately. > 12. Section 7.4 states that: “The AR SHALL have packet-relay > functionality.” > > The packet-relay is not defined within this document and since > document only as informational references this is a hard to test item > if not impossible. (Maybe authors wanted to say packet forwarding functionality. But because the 'relay' and 'proxy' words are such a buzz (no pun intended) in this context then everything looks as a relay and a proxy.) That said, I do have other issues with section 7.6 Access Router behaviour. For example this: draft: > In the Public Access scenario, all unicast packets originated from a > SS should be delivered to an AR even though the SS sends packets to > on-link SSs. Therefore, it is necessary for the AR to relay the on- > link packets. The first phrase makes think that packets from SS to SS are unnecessarily flying through AR. So one immediately thinks the solution would be for packets to fly directly from SS to SS. But no, authors propose that AR relays on-link packets; well this is already the case, router will put packets from link to same link if addresses indicate so. That's why that paragraph is confusing. > 13. Section 8.1.1 states that: “The bridge SHALL support an ARP > Proxy.” > > As usual it is not clear at which level this bridge operates: > level_0, level_1 or level_2. Well, to me it's not clear why should we have both IPv4 and IPv6 in the same document. If this document is to become IPv6 only then it shouldn't talk ARP at all. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 10 11:21:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gCf-00010k-Az; Wed, 10 Jan 2007 11:21:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4gCe-00010f-BK for 16ng@ietf.org; Wed, 10 Jan 2007 11:21:28 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4gCb-00071e-Hn for 16ng@ietf.org; Wed, 10 Jan 2007 11:21:28 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1168446084!12107643!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7393 invoked from network); 10 Jan 2007 16:21:24 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 10 Jan 2007 16:21:24 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0AGLOAo002954; Wed, 10 Jan 2007 09:21:24 -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 l0AGLMUv006308; Wed, 10 Jan 2007 10:21:23 -0600 (CST) Message-ID: <45A5127D.1090108@motorola.com> Date: Wed, 10 Jan 2007 17:21:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: GRE keys and seqnos (was: [16NG] Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt) References: <45A4C75A.8020903@motorola.com> In-Reply-To: <45A4C75A.8020903@motorola.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: Burcak Beser , 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 Just a note that I've been notified privately that GRE Keys were reinstated then by rfc2890. In which case the use by WiMax of GRE keys would be ok, so please discard my comments on GRE keys and seqnos. Alex Alexandru Petrescu wrote: > Hi Burcak, I'm not author of the document. I agree with some points > in your mail. The authors' point of view (when expressed) should be > taken as clarification to your request. > > In what follows I snipped the bridge description you provide > (layer0,1,2 and hyperbridge) and responded to the points I agree in > your mail, giving my motivation. > > Overall, I don't think IPv6/ETHCS should use GRE keys, nor GRE seq > no, and that this document shouldn't specify at all link-layer > behaviour (the 'SHALL' statements on bridge behaviour are useless > here). A clarification on DHCP/broadcast and router behaviour is in > too. > > Burcak Beser wrote: >> (The below described usage is the WiMAX mandatory supported >> transport of packets and all the descriptions and especially >> normative language has to deal with these details.) > > Allow me to just suggest that some discussion may be raised to you > about this point, in that it may be suggested to you that this group > doesn't do WiMax at all but 802.16. It's also been pointed out that > WiMax is the only user of 802.16, as well as it's too early to know > which will get widespread acceptance WiMax or 802.16 (Ethernet vs > 802.3 for IP took like 10years to clear out, was said). > >> Per WiMAX specifications (see >> http://www.wimaxforum.org/technology/documents/WiMAX_End_to_End_Network_Systems_Architecture.zip) >> >> >> >> each “connection” between SS and BS indicated by a unique CID >> within a single BS domain is mapped into a GRE tunnel in and in >> some other cases all CID’s coming from a single SS is mapped into a >> GRE tunnel identified by a “GRE key”. > > Just a note that the most recent GRE spec (rfc2784) deprecates the > use of GRE key (rfc2784). The GRE header is also changed - optional > parts disappeared. I don't know why WiMax would continue use GRE keys > to identify the tunnels. Other ways can be done, with the short > rfc2784 GRE header. > > [skipping description of layer 0, 1, 2 of bridges and hyper-bridges, > check the original poster's mail] > >> Coming to normative requirements stated in the draft: >> >> 1. Section 5.3 states that: “The BS SHALL forward all the radio >> connections belonging to one SS to a port of a bridge between all >> ports on the radio side and the interfaces towards the network >> side.” >> >> >> >> >> I guess this means that if BS has multiple interfaces it will send >> all the packets through the physical interface that is connected to >> “the bridge”. I have trouble to understand this requirement, is it >> desired that all the packets send through the same GRE tunnel? > > I think it shouldn't be required for BS to send all packets through > the same GRE tunnel. > > I think some deployments may use a full bridge instead of a simple > BS. Or even a full access router instead of a dumb BS. In these > cases GRE tunnels won't be needed. > >> 2. Section 5.3 further states: “If the SS functions as a bridge >> then it SHALL support a bridging between all its LAN ports and the >> airlink.” >> >> I am not sure why we have this as a requirement, as a principle I >> am against mandating unnecessary behavior. Further, I would like to >> point out that bridging is not defined. I am surprised to find >> that 802.1d-2004 is referenced as an informative. > > I think that requirement is not necessary, but not because bridging > is not defined. It's simply because this document shouldn't specify > a link-layer behaviour. This is an IETF document and can't define > link-layer behaviour in such strong terms. It should interpret the > link-layer behaviour as defined outside IETF and see how IP runs on > it, but not define it. > >> 3. The last paragraph/sentence of the section 5.3 states: “When >> performing bridging, any packets destined for one of the addresses >> in the Filtering Database SHALL be forwarded directly to that port, >> if appropriate for the particular scenario, and all packets >> received from a port, for which the packet's destination MAC >> address is also an entry for that port in the Filtering Database, >> SHALL be silently discarded.” >> >> First since it is not explicitly clear where it is applicable I >> assume that this behavior is applicable to both SS as a bridge and >> the “bridge”. What is missing is the behavior when an entry is >> deleted from the Dynamic Filtering Entry. In the non-normative >> section the BRIDGETIMEOUT is used without a default value or >> definition. There is a non-normative shall that defines the use of >> BRIDGETIMEOUT that uses the term traffic but does not describe >> whether this is for bi-directional traffic or not. > > Same thing for this paragraph. I don't agree this draft can use the > word "SHALL" to define how an entity performs bridging. It's simply > not the place to do that here. This is about networking behaviour > not link-layer behaviour. > >> It is not clear at which level this bridge operates: level_0, >> level_1 or level_2? Since the usage of SS (I would like the term >> CPE and would like to see CPE to include SS) implies that this is a >> behavior of “hyper-bridge”. > > What does CPE stand for? Customer Premises? (sorry I don't know). > >> 4. Section 6.1 states: “In this scenario, the bridge SHALL forward >> all packets received from any radio side port to a network side >> port.” >> >> First of all the applicability of this normative statement is not >> clear, and second I am missing the difference between this >> statement and statement discussed in bullet 1. Having said that, I >> miss the need for this requirement. > > Yes, they look the same to me, and redundant. I agree I think > there's no need for this requirement. IEEE can require a bridge to > forward packets and this document will use this behaviour. > >> It is not clear at which level this bridge operates: level_0, >> level_1 or level_2? The only evidence is against the level_0 is the >> fact that this defined behavior completely disables R8 interface >> of WiMAX specifications. > > In this context here I don't care about the R8 interface of the WiMax > spec. If this draft proposal breaks a WiMax spec then it's to be > solved between this draft's authors and WiMax. > >> 5. Section 7.2 states: “The bridge SHALL have the ability to enable >> or disable any filtering functionality defined herein.” >> >> It is not clear whether this is a flow specific or not. At this >> point of time my interpretation is that this is a global switch. > > I think I do not agree with adding filtering functionalities to a > bridge in the context of making IPv6 work over EthCS. > >> 6. Section 7.2 further states: “If a packet is filtered it SHALL be >> silently discarded.” >> >> It is not clear at which level this bridge operates: level_0, >> level_1 or level_2? The context implies that this is a level_2 >> functionality thereby the bridge is actually a “hyper-bridge”. > > Well, the sentence is not very clear to me either. > >> One of the side-effects of being a “hyper-bridge” is the fact that >> whenever a packet is dropped it, it will not be send through the >> GRE tunnel, and whenever a new packet is to be send by the >> “hyper-bridge” needs to insert an additional packet into the GRE >> tunnel with relevant GRE-key. >> >> >> >> The insertion/removal of GRE packets make the case that the GRE >> sequence numbers cannot be used without making the “hyper-bridge” a >> kind of back-to-back GRE relay that re-sequences. > > The GRE seq number is also deprecated in the newer GRE spec. So why > would one use it. > >> If there are no re-sequencers in the “bridge” and sequence numbers >> are being used there needs to be either a dummy packet insertion or >> a missing packet within the GRE tunnel. Due to the fact that the >> missing sequence numbers has the impact of delaying the packets out >> of the tunnel, it is assumed that the dummy packet generation >> method is being suggested. For the sake of compatibility the dummy >> packet is to be defined clearly. > > I agree. I think that there may be a need to define clearly how GRE > works in 802.16. Probably 802.16 already done that (I don't know). > Don't know either whether GRE for 802.16 should be done in this IPv6 > over ETHCS document. Especially knowing that one could use 802.16 > between the mobile and the network but not use GRE at all. > > But, GRE is a generic encapsulation method, a GRE header is added > between the IP header and the link-layer header. There may be a need > to specify what is the used link-layer header, what is the Protocol > Type field in the GRE header, etc. > >> 7. Section 7.2 states that: “The bridge SHALL support filtering of >> all packets received from a network side port to a destination MAC >> address or Multicast IP address not existing in the ICT or expired >> address.” >> >> >> >> If this sentence is taken to its face value, there is no way that >> an expired address to be reached by an external communication. > > I personally think this is not the place to specify link-layer > behaviour on the bridge. > >> 8. Section 7.2 states that: “The bridge SHALL support filtering of >> all packets received from a network side port to a broadcast or >> all-nodes multicast MAC address.” >> >> >> >> What this requirement does is disabling the all means of >> communication from the network if the CPE MAC address has expired. >> When the fact that there are no normative requirements on the >> “bridge” to learn is added, it is very hard to have a predictable >> behavior between the “bridges” that are within this draft. > > I personally think this is not the place to specify link-layer > behaviour on the bridge. > >> As usual it is not clear at which level this bridge operates: >> level_0, level_1 or level_2. >> >> It is important to point out that all the wording suggests that >> this is a bridge operating at level_2 “hyper-bridge”. On this level >> the “hyper-bridge” receives a MAC packet through a physical port, >> if the packet is a GRE packet it opens the GRE packet, looks at the >> inner MAC address, if the inner MAC address is broadcast, removes >> the packet and sends the next packet with next sequence number (if >> sequence numbers are being used) to the ASN-GW thereby creating a >> hole in the GRE sequence. >> >> One question regarding the requirement is that some DHCP Offers are >> send as MAC broadcast messages, and this requirement prevents >> these hosts to get an IP address. > > Well, DHCP offers aren't sent as broadcast but unicast. DHCP > discover are. And indeed if link-layer broadcast for IPv4 doesn't > work, or if link-layer multicast for IPv6 doesn't work, then DHCP > doesn't work. > >> 9. Section 7.2 further states: “The bridge SHALL support filtering >> of all packets received from a network side port to a broadcast or >> all-nodes multicast MAC address. >> >> >> >> I am not sure why this restriction is in place. > > I'm not sure this is the place to specify link-layer filtering for a > bridge. > >> 10. The last paragraph/sentence on section 7.2 states that: “If >> filtering is enabled the bridge SHALL permit all Address Resolution >> Protocol messages to pass to the ARP Proxy Agent and all Neighbor >> Discovery messages to pass to the Neighbor Discovery (ND) Relay >> Agent for additional processing as specified in following section.” >> >> >> >> >> >> As usual it is not clear at which level this bridge operates: >> level_0, level_1 or level_2. > > To me, it is not clear what's the necessity of ND Relay Agent in > first place. > >> It is important to point out that all the wording suggests that >> this is a bridge operating at level_2 “hyper-bridge”. It is >> important to note that the proxy ARP referred receives packets that >> are within GRE tunnel and send packets through GRE tunnel. >> >> >> >> 11. The Section 7.3 states: “For IPv4 over Ethernet, ICT contains >> MAC address and Port Map, which constitute a filtering entry in >> Filtering Database, tunnel ID, lifetime, and one or more unicast >> and multicast IPv4 addresses.” >> >> The mentioning of the tunnel ID strongly suggests a “hyper-bridge” >> operation. The problem of ingress and egress tunnel-ID has no >> solution offered and has to be mentioned using two tunnel ID’s. > > I have much more problems with that spec of the ICT (Identification > Cache Table). I can rely separately. > >> 12. Section 7.4 states that: “The AR SHALL have packet-relay >> functionality.” >> >> The packet-relay is not defined within this document and since >> document only as informational references this is a hard to test >> item if not impossible. > > (Maybe authors wanted to say packet forwarding functionality. But > because the 'relay' and 'proxy' words are such a buzz (no pun > intended) in this context then everything looks as a relay and a > proxy.) > > That said, I do have other issues with section 7.6 Access Router > behaviour. For example this: > > draft: >> In the Public Access scenario, all unicast packets originated from >> a SS should be delivered to an AR even though the SS sends packets >> to on-link SSs. Therefore, it is necessary for the AR to relay the >> on- link packets. > > The first phrase makes think that packets from SS to SS are > unnecessarily flying through AR. So one immediately thinks the > solution would be for packets to fly directly from SS to SS. But no, > authors propose that AR relays on-link packets; well this is already > the case, router will put packets from link to same link if > addresses indicate so. > > That's why that paragraph is confusing. > >> 13. Section 8.1.1 states that: “The bridge SHALL support an ARP >> Proxy.” >> >> As usual it is not clear at which level this bridge operates: >> level_0, level_1 or level_2. > > Well, to me it's not clear why should we have both IPv4 and IPv6 in > the same document. If this document is to become IPv6 only then it > shouldn't talk ARP at all. > > Alex > > _______________________________________________ 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 Jan 10 14:41:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4jJx-0005oM-Ar; Wed, 10 Jan 2007 14:41:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4jJw-0005oG-Hr for 16ng@ietf.org; Wed, 10 Jan 2007 14:41:12 -0500 Received: from web81914.mail.mud.yahoo.com ([68.142.207.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4jJt-0006Zl-Kz for 16ng@ietf.org; Wed, 10 Jan 2007 14:41:12 -0500 Received: (qmail 28321 invoked by uid 60001); 10 Jan 2007 19:40:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=s/k3hsUC1RCZLJyHFqjn7tn46mNE+OEARIjt2Z55sT0P25VDVClawK0HUvG+e60vzZX+CzjaJoIqVj7V62yevBQBoTDhTDsMvL3eYY1oCaV/a7dI5ZPfUaE2De9xvlD977FdWurHU6uDn1dqN48maCALzEOCDXo4i6Hk4Naa7V4= ; Message-ID: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81914.mail.mud.yahoo.com via HTTP; Wed, 10 Jan 2007 11:40:54 PST Date: Wed, 10 Jan 2007 11:40:53 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs) To: Alexandru Petrescu , "Premec, Domagoj" MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: v6ops@ops.ietf.org, 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="===============1689111591==" Errors-To: 16ng-bounces@ietf.org --===============1689111591== Content-Type: multipart/alternative; boundary="0-432116321-1168458053=:26320" --0-432116321-1168458053=:26320 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable GARP/GMRP is not widely deployed, and seems to be obsoleted at the IEEE alr= eady.=0ARFC 4541 (MLD snooping) is the deployed solution, as Max already di= scussed =0Ain the November meeting:=0A=0A http://www3.ietf.org/proceedin= gs/06nov/slides/16ng-4/sld7.htm=0A=0ANotice that the last bullet mentions t= hat no ND changes are required, so =0Aa future revision of the IP-over-ETH-= CS draft will have much simpler ND-related=0Atext.=0A=0AA good reference in= this respect is:=0A 2.7.2. Host/Router Flooding Reduction in=0A http:= //www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.txt=0ATo po= int out that solutions exist, of which RFC4541 is the most widely deployed.= =0A=0A-gabriel=0A=0A----- Original Message ----=0AFrom: Alexandru Petrescu = =0ATo: "Premec, Domagoj" =0ACc: v6ops@ops.ietf.org; 16ng@ietf.org=0ASent: Tuesday, Januar= y 9, 2007 2:02:04 PM=0ASubject: Re: [16NG] FW: Review on v6ops 802.16 deplo= yment scenario (J Kim of AT&TLabs)=0A=0AHi Domagoj, thanks for the email, s= kipping the parts we agree...=0A=0APremec, Domagoj wrote:=0A>>>> - Any refe= rence or description of "Relay DAD"? there are =0A>>>> earlier occurrences= =0A>>> Relay DAD is described in 2.2.2.3. Are you just pointing out that=0A= >>> Relay DAD is mentioned before 2.2.2.3, so the explanation should=0A>>>= also be moved to the first occurance of Relay DAD? "Relay DAD" =0A>>> and= "ND Relay" are terms also used in =0A>>> draft-ietf-16ng-ip-over-ethernet-= over-802.16-00.txt=0A>> =0A>> I would point out to more than just moving th= e definition text next=0A>> to the first use.=0A>> =0A>> ND is defined in = rfc2461 and DAD in rfc2462. None of these =0A>> documents defines what a "= Relay ND" or a "Relay DAD" would do. An=0A>> IP machine 'relaying' ND pac= kets from left to right, across links,=0A>> instead of forwarding or routi= ng them needs to be specified=0A>> clearly and separately I believe, provid= ed there's an identified=0A>> need.=0A>> =0A>> For example, the draft says= :=0A>>> Relay DAD means that the Neighbor Solicitation message used in =0A>= >> DAD process will be relayed only to the MS which already has =0A>>> conf= igured the solicited address as its own address (if such MS =0A>>> exist at= all).=0A>> In one sense, this is what DAD does already (not Relay DAD). = =0A>> RFC2462:=0A>>> Before sending a Neighbor Solicitation, an interface M= UST join =0A>>> the all-nodes multicast address and the solicited-node mult= icast =0A>>> address of the tentative address. The former insures that the= =0A>>> node receives Neighbor Advertisements from other nodes already =0A>= >> using the address; the latter insures that two nodes attempting =0A>>> t= o use the same address simultaneously detect each other's =0A>>> presence.= =0A>> So I could suggest removing the word 'Relay' from the draft text, =0A= >> just leave "DAD", and all would be fine.=0A> =0A> No, relay DAD is no or= dinary DAD. The standard DAD procedure assumes=0A> that the DAD solicitati= on is delivered to all the nodes using the =0A> same prefix. Relay DAD deli= vers the DAD solicitation only to the node=0A> that already owns the addre= ss being verified.=0A=0ANot very sure about that. The DADing NS is sent to= an IP solicited-node=0Amulticast address. Not all nodes in the subnet joi= n that address, only=0Athe ones whose last 24bits of MAC address match the = Tentative Address.=0A=0AThe DAD procedure doesn't assume the DADing NS is s= ent to all nodes=0Amulticast address (with link-scope). rfc2462 5.4.2: "IP = destination is=0Aset to the solicited-node multicast address of the target = address." The=0AIP dst address would be FF02:0:0:0:0:1:FFXX:XXXX (X: last = 24bits of MAC=0Aaddress). The link-layer dst multicast address would be=0A= 33-33-FF-XX-XX-XX I believe (X: last 24bits of MAC address, for IPv4=0Ait's= different: 23bits).=0A=0AIf one desires to deliver the DADing NS only to o= ne particular node (and=0Anot to a group) then one would put the full IP ad= dress in the dst, and=0Athe full MAC address in the link-layer dst. And th= is behaviour is not=0Aspecified by DAD (not sure whether it's forbidden, bu= t it's not spec'ed=0Ain rfc2462).=0A=0A>> In another sense, reading the dra= ft text suggesting to send the NS =0A>> to only some MSs (maybe another cri= teria than joining an address) =0A>> makes think that it may defeat the DAD= 's main goal. What happens =0A>> if some MS autoconfigures an address that= conflicts with the one in=0A>> NS and that MS doesn't see that NS.=0A> =0A= > This must not happen. It is the responsibility of the bridge (the =0A> au= thorative address cache) to deliver the DAD solicitation to the =0A> right = MS (the one that already owns the address being verified).=0A=0AOk, I think= we have identified a good responsability for the bridge, and=0Athis is inl= ine with my understanding of bridge making link-layer=0Amulticast work ok.= =0A=0AThis bridge could also implement 802.1D and 802.1Q. More precisely= =0Amaybe the GARP Multicast Registration Protocol (GMRP). With this=0Alink= -layer LLC protocol, a GARP participant declares to another about=0Athe gro= up it wants to receive. This happens with LLC PDUs (not IP=0Apackets). I = think, no?=0A=0AIn this case the BS would not forward the DADing NS to the = nodes that=0Ahaven't joined the link-layer solicited node multicast address= .=0A=0ASo if the BS does that then bandwidth wouldn't be wasted and waking = up=0Aidle modes wouldn't be, no?=0A=0A>> Related to 'Relay' in this context= is the concept of 'proxy ND' =0A>> whereby a node would do ND on behalf o= n another node. This is =0A>> partly defined in ND rfc2461 and largely used= by a Mobile IPv6 HA =0A>> rfc3775. Just wanted to mention them.=0A> =0A> = The intention of the relay DAD is to save the radio resources. When a=0A> = host sends a DAD solicitation, 802.16 MAC will deliver it to the BS.=0A> = =0A> =0A> =0AOk.=0A=0A> Normal behavior as per RFC 2461 would be that the D= AD message is =0A> delivered to all MSs sharing the same prefix.=0A=0ANot t= o all, just those that joined the group (small, maybe 1-sized) of=0Asolicit= ed node mc address. No?=0A=0A> But many of the MSs may be in the idle mode= , meaning that the =0A> delivery of the DAD message would incur paging and = wake up from idle=0A> mode, in addition to radio bandwidth necessary to tr= ansfer the DAD =0A> solicitation itself.=0A=0AYes, two things: avoid waking= up and avoid unnecessary bw consumption.=0A=0ATo avoid consuming bandwidth= the BS shouldn't send the DADing NS to all=0Anodes under it. This can be = achieved with a link-layer multicast=0Aprotocol (not IP) and normal DAD.=0A= =0ATo avoid waking up the idle node, the SS Eth drivers (under a BS not=0Ad= oing that multicast link-layer stuff) can avoid putting the received=0Apack= et to the kernel stack, based on the local driver table it maintains=0Aabou= t the link-layer multicast groups it listens too. Most Eth drivers=0Aon a = SS are able to filter what they receive (not deliver to IP stack).=0A Some = drivers are sensitive to packets received on Eth and will wake up=0Athe nod= e for any packet, some are more picky.=0A=0AI agree though that _if_ DADing= NS were sent to all-nodes multicast=0Aaddress then it would potentially in= volve waking up all those who joined=0Athat group, thus all nodes in a subn= et.=0A=0A> In relay DAD approach, the bridge (from figure 5) is aware of al= l =0A> attached MSs and their IP addresses (authorative address cache). =0A= > Using this knowledge, the bridge can deliver the DAD solicitation =0A> on= ly to the MS that has already configured the address being verified=0A> as= its own address. And this MS will then defend its address.=0A=0AYes, this = is what normal DAD would do too (not Relay), provided the node=0Ajoined tha= t solicited-node address. No?=0A=0AThe bridge should be able to do Etherne= t multicast and I believe many=0Aare, no? Otherwise in a hierarchy of brid= ges all broadcasted packets=0Awould be seen by everyone, and this doesn't h= appen in the wired world.=0A=0A> Yes, this is similar to HA performing prox= y ND on behalf of the =0A> mobile node. And the bridge may indeed defend th= e verified address on=0A> behalf of another node (which owns the address b= eing verified). But =0A> it is my understanding that such (proxy ND) approa= ch would't work =0A> with secure ND, that's why the bridge, in case of addr= ess conflict, =0A> will relay the DAD solicitation to the MS so that the MS= itslef can =0A> defend the address.=0A=0AAh I see! But Relay ND would hav= e its own issues with SeND - right?=0A=0AI think one can build attacks on b= oth proxy ND and on 'Relay' ND.=0A=0A> I-D draft-ietf-16ng-ip-over-ethernet= -over-802.16-00.txt also =0A> mentiones relay DAD. It does provide some add= itional details. We =0A> should probaby define relay DAD just in one docume= nt and then refer =0A> to it form other documents.=0A=0AYes, Relay ND looks= as a new functionality that deserves separate=0Adocumentation. For one it= 's obviously different IPv4 (Relay ARP?)=0Athan IPv6 at least because (1) I= Pv4 doesn't require the use of=0Alink-local multicast addresses and (2) add= ress duplication detection for=0AIPv4 link-local addresses is different tha= n DAD. So I would suggest=0Aseparation that the IPv6-over-ETH draft in two= : IPv6 and IPv4. And the=0ARelay DAD draft too in two: Relay DAD and Relay= ARP.=0A=0AFor Relay DAD, if there's enough energy and need to document as = a=0Aspecific functionality (like proxy ND) then I think it needs=0Arequirem= ents and goals too. Otherwise it could be documented as an=0Ainformational= feature that has probably been implemented(?) or needed by=0Aan SDO(?).=0A= =0AThanks,=0A=0AAlex=0A=0A=0A______________________________________________= _=0A16NG mailing list=0A16NG@ietf.org=0Ahttps://www1.ietf.org/mailman/listi= nfo/16ng=0A=0A=0A=0A=0A --0-432116321-1168458053=:26320 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
GARP/GMRP is not widely deployed, and seems to be obs= oleted at the IEEE already.
RFC 4541 (MLD snooping) is the deployed solu= tion, as Max already discussed
in the November meeting:

&n= bsp;   http://www3.ietf.org/proceedings/06nov/sl= ides/16ng-4/sld7.htm

Notice that the last bullet mentions= that no ND changes are required, so
a future revision of the IP-over-E= TH-CS draft will have much simpler ND-related
text.

A good refere= nce in this respect is:
   2.7.2.  Host/Router Flooding Reduction i=
n
   http://www.ietf.org/internet-dra=
fts/draft-ietf-mboned-routingarch-07.txt
To point out t= hat solutions exist, of which RFC4541 is the most widely deployed.

-= gabriel

----- Original Message ----
From: Alexandru Petre= scu <alexandru.petrescu@motorola.com>
To: "Premec, Domagoj" <do= magoj.premec@siemens.com>
Cc: v6ops@ops.ietf.org; 16ng@ietf.org
Se= nt: Tuesday, January 9, 2007 2:02:04 PM
Subject: Re: [16NG] FW: Review o= n v6ops 802.16 deployment scenario (J Kim of AT&TLabs)

Hi D= omagoj, thanks for the email, skipping the parts we agree...

Premec,= Domagoj wrote:
>>>> - Any reference or description of "Rela= y DAD"? there are
>>>> earlier occurrences
>>> = Relay DAD is described in 2.2.2.3. Are you just pointing out that
>>> =  Relay DAD is mentioned before 2.2.2.3, so the explanation should
&= gt;>>  also be moved to the first occurance of Relay DAD? "= Relay DAD"
>>> and "ND Relay" are terms also used in
>&= gt;> draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
>> >> I would point out to more than just moving the definition text ne= xt
>>  to the first use.
>>
>> ND is = defined in rfc2461 and DAD in rfc2462.  None of these
>>= ; documents defines what a "Relay ND" or a "Relay DAD" would do.  = ;An
>>  IP machine 'relaying' ND packets from left to ri= ght, across links,
>>  instead of forwarding or routing = them needs to be specified
>> clearly and separately I believe, pr= ovided there's an identified
>> need.
>>
>> For= example, the draft  says:
>>> Relay DAD means that the Neighbor S= olicitation message used in
>>> DAD process will be relayed on= ly to the MS which already has
>>> configured the solicited ad= dress as its own address (if such MS
>>> exist at all).
>= ;> In one sense, this is what DAD does already (not Relay DAD).
>= > RFC2462:
>>> Before sending a Neighbor Solicitation, an in= terface MUST join
>>> the all-nodes multicast address and the = solicited-node multicast
>>> address of the tentative address.=   The former insures that the
>>> node receives Neig= hbor Advertisements from other nodes already
>>> using the add= ress; the latter insures that two nodes attempting
>>> to use = the same address simultaneously detect each other's
>>> presen= ce.
>> So I could suggest removing the word 'Relay' from the draft= text,
>> just leave "DAD", and all would be fine.
>
> No,= relay DAD is no ordinary DAD. The standard DAD procedure assumes
>&n= bsp; that the DAD solicitation is delivered to all the nodes using the=
> same prefix. Relay DAD delivers the DAD solicitation only to the = node
>  that already owns the address being verified.
Not very sure about that.  The DADing NS is sent to an IP solic= ited-node
multicast address.  Not all nodes in the subnet join= that address, only
the ones whose last 24bits of MAC address match the = Tentative Address.

The DAD procedure doesn't assume the DADing NS is= sent to all nodes
multicast address (with link-scope). rfc2462 5.4.2: "= IP destination is
set to the solicited-node multicast address of the tar= get address."  The
IP dst address would be FF02:0:0:0:0:1:FFXX= :XXXX (X: last 24bits of MAC
address).  The link-layer dst mul= ticast address would be
33-33-FF-XX-XX-XX I believe (X: last 24bits of MAC add= ress, for IPv4
it's different: 23bits).

If one desires to deliver= the DADing NS only to one particular node (and
not to a group) then one= would put the full IP address in the dst, and
the full MAC address in t= he link-layer dst.  And this behaviour is not
specified by DAD= (not sure whether it's forbidden, but it's not spec'ed
in rfc2462).
=
>> In another sense, reading the draft text suggesting to send th= e NS
>> to only some MSs (maybe another criteria than joining an = address)
>> makes think that it may defeat the DAD's main goal.&n= bsp; What happens
>> if some MS autoconfigures an address th= at conflicts with the one in
>> NS and that MS doesn't see that NS= .
>
> This must not happen. It is the responsibility of the br= idge (the
> authorative address cache) to deliver the DAD solicitati= on to the
> right MS (the one that already owns the address being verified).<= br>
Ok, I think we have identified a good responsability for the bridge,= and
this is inline with my understanding of bridge making link-layermulticast work ok.

This bridge could also implement 802.1D and 802.= 1Q.  More precisely
maybe the GARP Multicast Registration Prot= ocol (GMRP).  With this
link-layer LLC protocol, a GARP partic= ipant declares to another about
the group it wants to receive. &nbs= p;This happens with LLC PDUs (not IP
packets).  I think, no?
In this case the BS would not forward the DADing NS to the nodes that=
haven't joined the link-layer solicited node multicast address.

= So if the BS does that then bandwidth wouldn't be wasted and waking up
i= dle modes wouldn't be, no?

>> Related to 'Relay' in this conte= xt is the concept of 'proxy ND'
>> whereby a node would do ND&nbs= p; on behalf on another node. This is
>> partly defined in ND rfc2461 = and largely used by a Mobile IPv6 HA
>> rfc3775.  Just = wanted to mention them.
>
> The intention of the relay DAD is = to save the radio resources. When a
>  host sends a DAD sol= icitation, 802.16 MAC will deliver it to the BS.
>
>
> =
Ok.

> Normal behavior as per RFC 2461 would be that the DAD m= essage is
> delivered to all MSs sharing the same prefix.

Not= to all, just those that joined the group (small, maybe 1-sized) of
soli= cited node mc address.  No?

> But many of the MSs may b= e in the idle mode, meaning that the
> delivery of the DAD message w= ould incur paging and wake up from idle
>  mode, in additio= n to radio bandwidth necessary to transfer the DAD
> solicitation it= self.

Yes, two things: avoid waking up and avoid unnecessary bw consumption.

To avoid consuming bandwidth the BS shouldn't send the= DADing NS to all
nodes under it.  This can be achieved with a= link-layer multicast
protocol (not IP) and normal DAD.

To avoid = waking up the idle node, the SS Eth drivers (under a BS not
doing that m= ulticast link-layer stuff) can avoid putting the received
packet to the = kernel stack, based on the local driver table it maintains
about the lin= k-layer multicast groups it listens too.  Most Eth drivers
on = a SS are able to filter what they receive (not deliver to IP stack).
So= me drivers are sensitive to packets received on Eth and will wake up
the= node for any packet, some are more picky.

I agree though that _if_ = DADing NS were sent to all-nodes multicast
address then it would potenti= ally involve waking up all those who joined
that group, thus all nodes i= n a subnet.

> In relay DAD approach, the bridge (from figure 5) i= s aware of all
> attached MSs and their IP addresses (authorative address cach= e).
> Using this knowledge, the bridge can deliver the DAD solicitat= ion
> only to the MS that has already configured the address being v= erified
>  as its own address. And this MS will then defend= its address.

Yes, this is what normal DAD would do too (not Relay),= provided the node
joined that solicited-node address.  No?
The bridge should be able to do Ethernet multicast and I believe many<= br>are, no?  Otherwise in a hierarchy of bridges all broadcasted = packets
would be seen by everyone, and this doesn't happen in the wired = world.

> Yes, this is similar to HA performing proxy ND on behalf= of the
> mobile node. And the bridge may indeed defend the verified= address on
>  behalf of another node (which owns the addre= ss being verified). But
> it is my understanding that such (proxy ND= ) approach would't work
> with secure ND, that's why the bridge, in case of ad= dress conflict,
> will relay the DAD solicitation to the MS so that = the MS itslef can
> defend the address.

Ah I see!  = But Relay ND would have its own issues with SeND - right?

I think on= e can build attacks on both proxy ND and on 'Relay' ND.

> I-D dra= ft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt also
> mentiones re= lay DAD. It does provide some additional details. We
> should probab= y define relay DAD just in one document and then refer
> to it form = other documents.

Yes, Relay ND looks as a new functionality that des= erves separate
documentation.  For one it's obviously differen= t IPv4 (Relay ARP?)
than IPv6 at least because (1) IPv4 doesn't require = the use of
link-local multicast addresses and (2) address duplication de= tection for
IPv4 link-local addresses is different than DAD.  = So I would suggest
separation that the IPv6-over-ETH draft in two: IPv6 and IPv4.&= nbsp; And the
Relay DAD draft too in two: Relay DAD and Relay ARP.<= br>
For Relay DAD, if there's enough energy and need to document as aspecific functionality (like proxy ND) then I think it needs
requiremen= ts and goals too.  Otherwise it could be documented as an
info= rmational feature that has probably been implemented(?) or needed by
an = SDO(?).

Thanks,

Alex


_____________________________= __________________
16NG mailing list
16NG@ietf.org
https://www1.iet= f.org/mailman/listinfo/16ng

--0-432116321-1168458053=:26320-- --===============1689111591== 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 --===============1689111591==-- From 16ng-bounces@ietf.org Wed Jan 10 15:16:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4jsA-0004zu-E6; Wed, 10 Jan 2007 15:16:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4js8-0004yX-TY for 16ng@ietf.org; Wed, 10 Jan 2007 15:16:32 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4js6-0001lt-Ct for 16ng@ietf.org; Wed, 10 Jan 2007 15:16:32 -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 l0AKGH6I017614; Wed, 10 Jan 2007 14:16:17 -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, 10 Jan 2007 14:16:17 -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] Comments ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt Date: Wed, 10 Jan 2007 14:16:16 -0600 Message-ID: <61B0DCC9767CDC4C91769592B12CCDD11A7CD1@ILEXC2U02.ndc.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Comments ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt Thread-Index: Acci8N0mhuhkeWBKTomP8c55cnvPcgCLQ17gAB+yF1AD1Gbu8A== From: "Narvaez, Paolo \(Paolo\)" To: "Hongseok Jeon" X-OriginalArrivalTime: 10 Jan 2007 20:16:17.0331 (UTC) FILETIME=[2F48C030:01C734F4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 Hongseok,=20 Thanks for the reply. Please find below some additional comments to your response. Thanks, Paolo > -----Original Message----- > From: Hongseok Jeon [mailto:jeonhs@etri.re.kr]=20 > Sent: Friday, December 22, 2006 5:31 AM > To: Narvaez, Paolo (Paolo) > Cc: 16ng@ietf.org > Subject: RE: [16NG] Comments=20 > ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt=20 > >=20 > > Section 5.3 -=20 > >=20 > >=20 > > "When performing bridging, any packets destined for one of the > > addresses in the Filtering Database SHALL be forwarded=20 > directly to > > that port, if appropriate for the particular scenario, and all > > packets received from a port, for which the packet's=20 > > destination MAC > > address is also an entry for that port in the Filtering Database, > > SHALL be silently discarded." > >=20 > >=20 > > 2) It does not mention what happens to packets with a MAC DA=20 > > equal to the MAC address of a SS. These should not be forwarded. >=20 > It depends on the scenario. In case of public access=20 > scenario, the packets=20 > should be transmitted to AR and then relayed to the intended=20 > SS by relaying=20 > function on AR. In VLAN scenario, the packets are directly=20 > forwarded to the=20 > intended SS by bridge.=20 For the public access case, I understand why the AR would want to forward a packet back to another SS based on a destination IP address. But why would the AR forward based on a MAC DA? That MAC address should not even have been known to the originating SS. In fact, the AR should drop any Ethernet frame with a unicast MAC DA that does not match the MAC address of one of its interfaces.=20 If the public access case is supposed to prevent direct Ethernet connectivity between SSs, packets with a MAC DA =3D SS MAC address = should be dropped. Forwarding them to the AR is a waste of bandwidth, since they will be dropped by the AR anyway. > > Section 6.1 - > >=20 > > "Figure 3 depicts an IEEE 802.16 network deployment scenario without > > direct host-to-host communication. In the general public access > > case, direct communication between nodes is restricted because of > > security and accounting issues. In this scenario, the=20 > bridge SHALL > > forward all packets received from any radio side port to=20 > a network > > side port. Peer-to-peer communication is not supported by=20 > > the bridge > > and all packets originated from a SS should be delivered=20 > to an AR." > >=20 > > 4) What is the behavior of the bridge in the public access=20 > > scenario when the Ethernet frame arriving over the air (or=20 > > from the AR) has one or more VLAN tags? Is the VLAN tag=20 > > stripped off? Is it ignored? Are SSs and ARs forbidden from=20 > > sending VLAN-tagged frames to the bridge? >=20 > Public access scenario does not consider Ethernet frames=20 > embedded with VLAN > tag. > Ethernet frames with VLAN tag are handled in VLAN scenario and we will > provide=20 > the detail procedures in next version document.=20 In the public access scenario how do you guarantee that the terminal does not send Ethernet frames with VLAN tags? How does the bridge react if this happens? The text should explain how this is prevented or should explain how the bridge deals with these packets. > > Section 7.2 - > >=20 > > "The bridge SHALL support filtering of all packets received from a > > network side port to a destination MAC address or Multicast IP > > address not existing in the ICT or expired address." > >=20 > >=20 > > 7) What happens if there are multiple network side ports? In=20 > > that case, I think you would want to filter broadcasting to=20 > > the air interfaces, but you will still want to broadcast on=20 > > the remaining network ports. >=20 > Filtering in this document focuses on multicast data, and=20 > broadcasting=20 > data destined for sleep mode SSs. Broadcast data for wake-up=20 > SSs does=20 > not be filtered. Hosts in network side always wake up and=20 > thus broadcast=20 > data for the host does not need to be filtered.=20 I agree. The document should make a distinction between the different types of ports and clarify that filtering only applies to the air ports. > > Section 7.6 - > >=20 > > "The AR SHALL have packet-relay functionality. The AR=20 > relays packets > > destined for IP broadcast address and link-local scoped multicast > > addresses to incoming interface again. When relaying,=20 > AR does not > > decrease the value of TTL or Hop Limit." > >=20 > > 8) Can this on-link packet-relay functionality be performed=20 > > at the bridge instead of the AR? Since the bridge already has=20 > > several IP-snooping capabilities (ARP-proxy, ND-relay) and=20 > > has knowledge of IP addresses, it seems that it could also=20 > > perform this function. In this case, the AR would not require=20 > > any modifications and would behave like a standard AR. The=20 > > bridge requires modifications anyways. >=20 > The position of packet-relay functionality on AR is based on=20 > the assumption > which=20 > all traffics from SS should be transmitted to AR in the public access > scenario.=20 I understand that the current draft is placing the relay functionality in the AR. My question is about the rationale behind it. It seems that this functionality could also be performed by the bridge. Two benefits of placing this functionality at the bridge is that 1) it eliminates the round-trip multicast traffic to and from the AR and 2) no modifications are required at the AR (the AR is a standard router). Therefore, what is the design rationale for placing the relay functionality in the AR? _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 10 15:39:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kDn-0005ui-Iw; Wed, 10 Jan 2007 15:38:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kDm-0005ud-JL for 16ng@ietf.org; Wed, 10 Jan 2007 15:38:54 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4kDl-0004sh-8c for 16ng@ietf.org; Wed, 10 Jan 2007 15:38:54 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-3.tower-128.messagelabs.com!1168461531!3722003!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 26531 invoked from network); 10 Jan 2007 20:38:52 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-3.tower-128.messagelabs.com with SMTP; 10 Jan 2007 20:38:52 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l0AKjqaU006073; Wed, 10 Jan 2007 13:45:53 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0AKcmAg006592; Wed, 10 Jan 2007 14:38:49 -0600 (CST) Message-ID: <45A54ED7.9020203@motorola.com> Date: Wed, 10 Jan 2007 21:38:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gabriel montenegro Subject: Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs) References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> In-Reply-To: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: v6ops@ops.ietf.org, 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 gabriel montenegro wrote: > GARP/GMRP is not widely deployed, and seems to be obsoleted at the > IEEE already. Thanks for clarification. Maybe IEEE proposes something else instead, in order to have link-layer multicast? > RFC 4541 (MLD snooping) is the deployed solution, as Max already > discussed in the November meeting: > > http://www3.ietf.org/proceedings/06nov/slides/16ng-4/sld7.htm Yes, remark though that the MLD snooping doc rfc4541 is informational, will that alter the status of IPv6-over-ETHCS. I am not sure the IPv6-over-ETHCS could make a recommendation to use rfc4541, because of its informational status. IPv6-over-ETHCS could simply assume that ETHCS offers link-layer multicast service to the IPv6 stack. This could be a goal for ETHCS. Whether ETHCS fullfills that by using MLD snooping or another IEEE link-layer protocol, that should be irrelevant to the IPv6 stack. But I don't think the IPv6-over-ETHCS should recommend use of MLD snooping. > Notice that the last bullet mentions that no ND changes are required, > so a future revision of the IP-over-ETH-CS draft will have much > simpler ND-related text. Yes, I agree. > A good reference in this respect is: > > 2.7.2. Host/Router Flooding Reduction in > http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.txt > > > > > > To point out that solutions exist, of which RFC4541 is the most > widely deployed. I can not comment on the deployed widely comment, but the fact that it's informational it may mean it's not interoperable although widely deployed? I don't know, just asking. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 11 12:23:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53eQ-0004j8-Ut; Thu, 11 Jan 2007 12:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53eP-0004ix-I9 for 16ng@ietf.org; Thu, 11 Jan 2007 12:23:41 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H53eM-0006Zo-JX for 16ng@ietf.org; Thu, 11 Jan 2007 12:23:41 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1168536217!12808729!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15556 invoked from network); 11 Jan 2007 17:23:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 11 Jan 2007 17:23:37 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0BHNaqn027306; Thu, 11 Jan 2007 10:23:36 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0BHNWtR013689; Thu, 11 Jan 2007 11:23:33 -0600 (CST) Message-ID: <45A67293.6030504@motorola.com> Date: Thu, 11 Jan 2007 18:23:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: multicast and IPv6 over ETHCS (was: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs)) References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> In-Reply-To: <45A54ED7.9020203@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: v6ops@ops.ietf.org, 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, sorry for following-up on my own email... Alexandru Petrescu wrote: > gabriel montenegro wrote: >> GARP/GMRP is not widely deployed, and seems to be obsoleted at the >> IEEE already. > > Thanks for clarification. Maybe IEEE proposes something else > instead, in order to have link-layer multicast? > >> RFC 4541 (MLD snooping) is the deployed solution, as Max already >> discussed in the November meeting: >> >> http://www3.ietf.org/proceedings/06nov/slides/16ng-4/sld7.htm Absent GARP/GMRP I think a thing to write in the future version of IPv6-over-ETHCS draft with respect to multicast is about the multicast features of the 802.16 MAC and ETHCS? More than the current section 4.3 saying just that 802.16 MAC dl is mc while ul is not mc (download/upload/multicast). It's clear that IPv6 ND needs a link-layer that is multicast capable, and in both directions. 802.16 MAC seems to be mc-capable (CID for multiple links, MCA-REQ/RSP, etc). However, it's not clear to me from IEEE spec whether (1) both directions are mc capable and (2) the ETHCS (_over_ 802.16MAC) offers a multicast capable link interface to IP. Ie the questions are: (1) will a multicasted NS sent by SS get delivered to that mc group? or just the RA sent by BS? (is 802.16 MAC mc-capable in both directions)? and (2) will an IPv6 RA sent to all-nodes IP and all-nodes MAC address get delivered as such, when it's put on ETHCS (not on 802.16MAC SAP)? (will the ETHCS classifiers understand MAC multicast dst addresses.) If ETHCS is link-layer multicast capable then it is enough to say in the document that ETHCS is link-layer multicast capable, with an example. If ETHCS is not link-layer multicast capable, bidirectionally, I think the draft should say that ETHCS should be link-layer multicast capable, bidirectionally, otherwise IPv6 doesn't work on it. I don't think the draft should develop a technique to make ETHCS link-layer multicast capable, bidirectionally. If there is agreement or incentive I can provide text as I suggested above. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 11 15:33:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56bc-0006YZ-MP; Thu, 11 Jan 2007 15:33:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56bb-0006YS-9l for 16ng@ietf.org; Thu, 11 Jan 2007 15:32:59 -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 1H56bY-0004DJ-Ox for 16ng@ietf.org; Thu, 11 Jan 2007 15:32:59 -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 l0BKVAOZ007764 for <16ng@ietf.org>; Thu, 11 Jan 2007 22:31:28 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 22:32:52 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 14:32:47 -0600 Received: from 172.19.244.131 ([172.19.244.131]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Jan 2007 20:32:50 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Thu, 11 Jan 2007 14:34:27 -0600 From: Basavaraj Patil To: <16ng@ietf.org> Message-ID: Thread-Topic: Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] Thread-Index: Acc1v+MwIbDKnKGzEdubzQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jan 2007 20:32:47.0887 (UTC) FILETIME=[A81D59F0:01C735BF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] 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 Issues raised during the LC of I-D: [Junghoon Jee] 1. [Page 8] For transmission of IPv6 packets via the IP specific part of the Packet CS of 802.16, the IPv6 layer interfaces with the 802.6 MAC directly. s/802.6/802.16 Raj> Done. 2. 13.2. Informative References [FRD] Choi, JH., Shin, DongYun., and W. Haddad, "Fast Router Discovery with L2 support", August 2006, . [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005, . Raj> Based on feedback and earlier discussion, we decided to not reference the DNA work. However the reference section has not been revised. I have deleted both these references from the IR section. [Alex Petrescu] 3. draft says: > The AdvDefaultLifetime in the router advertisement MUST be either > zero or between MaxRtrAdvInterval and 43200 seconds. The default > value is 2 * MaxRtrAdvInterval. This formulation is ambiguous. I'd prefer using 'MUST' followed by a single sentence, not by an 'or'. If the Router Lifetime is 0 then the BS or AR is not a Default Router. Or I don't see a deployment scenario where the BS/AR are not default routers for the SS. Raj> If you look at the AdvDefaultLifetime specification in 2461bis, its is specified the same way (MUST be either zero or between MaxRtrAdvInterval and 9000 seconds). So I think the sentence is acceptable as written. There are situations when you would want to configure a RTR that you are adding to the network with Lifetime=0. For hosts that are being served by an AR, the lifetime is obviously non-zero. I think this is pretty well understood. 4. draft: > The MaxRtrAdvInterval value specified in this document over-rides the > recommendation in RFC2461 [RFC2461]. The MaxRtrAdvInterval MUST be > no less than 4 seconds and no greater than 21600 seconds. Thee > default value for MaxRtrAdvInterval is 10800 seconds. [nit: Thee] Raj> Fixed. Actually it only over-rides the upper limit and the default value (2461 says 1800s vs draft 21600s, and 600s vs draft 10800s respectively). This draft does not override 2461's lower limit of 4s. Raj> True. Practically speaking you would not want to send periodic RAs over an air-interface. I had co-authored an I-D earlier where I had proposed that it should be possible to configure an RA to not send periodic RAs at all (draft-madanapalli-ipv6-periodic-rtr-advts-00.txt). However because of backward compatibility issues this is not possible. The next best thing is to have a large gap (time) between periodic RAs. Hence the lower limit of 4s is just fine. It means that an IPv6-over-IPv6CS handover would take a long 4s in the worst case; which is too long. But Mobile IPv6 3775 allows for MaxRtrAdvInterval as low as 0.03s. How does this draft position with respect to 3775? Can this draft be over-ridden by 3775 in addition to over-riding 2461? Raj> Movement detection as specified in RFC3775 is based on RAs. Hence it makes sense to have a small value in that case. However movement detection in 802.16 is handled by the lower layer and there is no reason for the host to depend on RAs to detect if it has moved across ARs. Hence there is no reason for any change w.r.t 3775 and I do not see RFC3775 over-riding the values specified here. -Raj _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 11 15:50:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56sv-0006Vg-7t; Thu, 11 Jan 2007 15:50:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56se-00066Y-G7; Thu, 11 Jan 2007 15:50:36 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H56sb-0003m2-KG; Thu, 11 Jan 2007 15:50:36 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 1530E17628; Thu, 11 Jan 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H56s6-0007vB-LG; Thu, 11 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 11 Jan 2007 15:50:02 -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-02.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-02.txt Pages : 17 Date : 2007-1-11 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-02.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-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-11124834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-16ng-ipv6-link-model-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-11124834.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 Thu Jan 11 16:20:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57LN-0001h0-9x; Thu, 11 Jan 2007 16:20:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57LM-0001gu-WE for 16ng@ietf.org; Thu, 11 Jan 2007 16:20:17 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H57LL-0005uX-Jn for 16ng@ietf.org; Thu, 11 Jan 2007 16:20:16 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1168550414!13732411!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20504 invoked from network); 11 Jan 2007 21:20:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 11 Jan 2007 21:20:14 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0BLKEhP008083; Thu, 11 Jan 2007 14:20:14 -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 l0BLKD7n019337; Thu, 11 Jan 2007 15:20:13 -0600 (CST) Message-ID: <45A6AA0C.7040508@motorola.com> Date: Thu, 11 Jan 2007 22:20:12 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] 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: 932cba6e0228cc603da43d861a7e09d8 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 Basavaraj Patil wrote: > > Issues raised during the LC of I-D: > > [Junghoon Jee] 1. [Page 8] For transmission of IPv6 packets via the > IP specific part of the Packet CS of 802.16, the IPv6 layer > interfaces with the 802.6 MAC directly. > > s/802.6/802.16 > > Raj> Done. > > 2. 13.2. Informative References > > [FRD] Choi, JH., Shin, DongYun., and W. Haddad, "Fast Router > Discovery with L2 support", August 2006, www.ietf.org/internet-drafts/draft-ietf-dna-frd-02.txt>. > > [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network > Attachment in IPv6", RFC 4135, August 2005, > . > > Raj> Based on feedback and earlier discussion, we decided to not > reference the DNA work. However the reference section has not been > revised. I have deleted both these references from the IR section. > > > [Alex Petrescu] Raj, thanks for taking into account my comments. > 3. draft says: >> The AdvDefaultLifetime in the router advertisement MUST be either >> zero or between MaxRtrAdvInterval and 43200 seconds. The default >> value is 2 * MaxRtrAdvInterval. > > This formulation is ambiguous. I'd prefer using 'MUST' followed by a > single sentence, not by an 'or'. > > If the Router Lifetime is 0 then the BS or AR is not a Default > Router. Or I don't see a deployment scenario where the BS/AR are not > default routers for the SS. > > Raj> If you look at the AdvDefaultLifetime specification in 2461bis, > its is specified the same way (MUST be either zero or between > MaxRtrAdvInterval and 9000 seconds). So I think the sentence is > acceptable as written. Ok. > There are situations when you would want to configure a RTR that you > are adding to the network with Lifetime=0. For hosts that are being > served by an AR, the lifetime is obviously non-zero. I think this is > pretty well understood. Yes, the situation is understood in general (not necessarily pretty well), where there may be several access routers on the same link, for reliability. But I'm pretty sure this is not a 802.16 capability, nor a requirement. Maybe in WiMax? > 4. draft: >> The MaxRtrAdvInterval value specified in this document over-rides >> the recommendation in RFC2461 [RFC2461]. The MaxRtrAdvInterval >> MUST be no less than 4 seconds and no greater than 21600 seconds. >> Thee default value for MaxRtrAdvInterval is 10800 seconds. > > [nit: Thee] > > Raj> Fixed. > > Actually it only over-rides the upper limit and the default value > (2461 says 1800s vs draft 21600s, and 600s vs draft 10800s > respectively). This draft does not override 2461's lower limit of 4s. > > > Raj> True. Practically speaking you would not want to send periodic > RAs over an air-interface. YEs, but also practically speaking that depends largely on the type of the air interface. Much simpler air interfaces (than 802.16e) send many messages on the air interfaces, not related to IP, and still works. One RA every second on a high-bandwidth air interface is not overkill. One can compute that easily: on a 1Mbps air interface there are that many messages possible. 1RA more or less... > I had co-authored an I-D earlier where I had proposed that it should > be possible to configure an RA to not send periodic RAs at all > (draft-madanapalli-ipv6-periodic-rtr-advts-00.txt). However because > of backward compatibility issues this is not possible. The next best > thing is to have a large gap (time) between periodic RAs. Hence the > lower limit of 4s is just fine. So maybe too because of backward compatibility issues with MIP6 it shouldn't be possible to limit the upper limit on the frequency of RAs to 4s. > It means that an IPv6-over-IPv6CS handover would take a long 4s in > the worst case; which is too long. But Mobile IPv6 3775 allows for > MaxRtrAdvInterval as low as 0.03s. How does this draft position with > respect to 3775? Can this draft be over-ridden by 3775 in addition > to over-riding 2461? > > Raj> Movement detection as specified in RFC3775 is based on RAs. > Hence it makes sense to have a small value in that case. However > movement detection in 802.16 is handled by the lower layer I am not sure 802.16e specifies movement detection. I believe it doesn't, at least not for the IP layer, and not in the IEEE 802.16e doc. It may do it for its PHY but that's irrelevant for IP: IP doesn't see PHY changing BS. If you look at the 802.16 network-entry procedure there's no clear sign of which of the messages should be considered as a trigger of movement for the IP stack; none contains IPv6 subnet prefix or default router address. There's only DHCP(v4) in that scheme and RA. RA is best candidate. The procedure doesn't even say an RS could be sent right after a certain message, instead of waiting for next RA. Besides, you seemed to oppose completely any change or clarification to 802.16e network-entry procedure. > and there is no reason for the host to depend on RAs to detect if it > has moved across ARs. Hence there is no reason for any change w.r.t > 3775 and I do not see RFC3775 over-riding the values specified here. There is no other means for an IP stack on top of IPv6CS to know that the subnet has changed. This is where MIP6 reacts, on subnet change, not on PHY change. So the 802.16 BS, if it sends RAs, it should send them quickly. One may think that 802.16 link layer triggers are possible to speed up the handover - yes, ok, but there's no documented method for that. Not to mention agreed upon. Until 802.21 figures out how to normalize all IEEE MACs plus 3G links, I suggest leave place for fast RAs in IPv6overIPv6CS. Maybe a MAY would suffice. Thanks, Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 11 19:43:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AVj-0004wG-8g; Thu, 11 Jan 2007 19:43:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5AVh-0004w2-AC; Thu, 11 Jan 2007 19:43:09 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5AVd-0002D1-LE; Thu, 11 Jan 2007 19:43:09 -0500 Received: from ep_mmp1 (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 <0JBQ0047ACM6CE@mailout1.samsung.com>; Fri, 12 Jan 2007 09:42:06 +0900 (KST) Received: from your655e9d6f61 ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JBQ00HNPCM5AK@mmp1.samsung.com>; Fri, 12 Jan 2007 09:42:05 +0900 (KST) Date: Fri, 12 Jan 2007 09:41:27 +0900 From: Daniel Park To: Jari Arkko , INT AD , The IESG Message-id: <026f01c735e2$65d9c4c0$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: ee80a2074afbfe28d15369f4e74e579d Cc: 16ng@ietf.org, "Madanapalli, Syam" Subject: [16NG] Advancing the document: Analysis of IPv6 Link Models for 802.16 based Networks 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, The 16ng WG document, "Analysis of IPv6 Link Model for 802.16 based Networks" has completed its WGLC. It's ready for the advancement. o Filename: draft-ietf-16ng-ipv6-link-model-analysis-02 o Intended Publication: Informational RFC o Document shepherd write-up for the ID: Below ============================================================== Document shepherd questions and writeup format (21 November 2006) (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Daniel Park is the Document Shepherd for this document. I've reviewed this document and it is ready for advancing to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Many 802.16 and IPv6 experts reviewed this document. This document is result of a Design Team including the 16ng WG technical advisors, IEEE 802.16 liaison as well as WiMAX key members that was formed to analysis the IPv6 link models for 802.16 networks. This document went through the 2 weeks WGLC in the 16ng WG. I have no concern about the depth or breadth of the reviews that have been performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? None. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is strong WG consensus in advancing this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? No nits found. There is a minor nit in RFC 3978 boilerplate that was reported by the idnits tool. This will be fixed in the subsequent revision. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document splits its references into normative and informative. In Normative References, [3]'s WGLC ended on October last year and several comments as well as expert reviews happened to this document. After revision, it will be ready for advancement soon. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists. This document has no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Does not apply to this document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Relevent content can frequently and easily be found in the abstract and introduction of this document. This document explains different IPv6 link models that are suitable for 802.16 based networks and analyzes them and their applicability under different deployment scenarios. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? None. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? This document suggests a couple of link model to be used for 802.16 networks. Ethernet like link model would be used when the deployment requires the use of Ethernet CS. For IPv6CS, point-to-point link model appears to the choice because of its simplicity for performing the DAD and does not break any existing applications or require defining any new protocol. Those will be implemented in 802.16 networks soon. The quality of the document is good. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? Daniel Park is the Document Shepherd for this document. Jari Arkko is the Responsible Area Director. ============================================================== 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 Thu Jan 11 20:03:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Aoy-0007ub-Un; Thu, 11 Jan 2007 20:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Aox-0007uT-HS for 16ng@ietf.org; Thu, 11 Jan 2007 20:03:03 -0500 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Aox-0006z4-4T for 16ng@ietf.org; Thu, 11 Jan 2007 20:03:03 -0500 Received: by wr-out-0506.google.com with SMTP id i4so482721wra for <16ng@ietf.org>; Thu, 11 Jan 2007 17:03:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=i0NV5glB0W2zpRUlqQcCNP03QSyTuQlPcmrWxUYQ1lzRgEkmhLqjRifUcBQ7oJEnr7Wlt3rdQMlRFTZrsJmrNApRBkgrnOCzFMLpcxYeCWlq/AOKmiKZsnN+8hNRNyHAYBFEfi353vS2LyX1F0AT/7S+vnb6HAaAQzPId/I7ZHM= Received: by 10.65.237.19 with SMTP id o19mr107541qbr.1168563782220; Thu, 11 Jan 2007 17:03:02 -0800 (PST) Received: by 10.65.225.19 with HTTP; Thu, 11 Jan 2007 17:03:02 -0800 (PST) Message-ID: Date: Fri, 12 Jan 2007 10:03:02 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" Subject: Re: multicast and IPv6 over ETHCS (was: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&TLabs)) In-Reply-To: <45A67293.6030504@motorola.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> X-Google-Sender-Auth: a8c0046595477766 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: v6ops@ops.ietf.org, 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="===============0049479508==" Errors-To: 16ng-bounces@ietf.org --===============0049479508== Content-Type: multipart/alternative; boundary="----=_Part_21903_21380906.1168563782155" ------=_Part_21903_21380906.1168563782155 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, Let me jump into discussion. 1) 802.16/16e MAC has no capability to do uplink multicast. In DL, 802.16provides multicast CIDs which is initiated by DSA messages. In UL, however, there is no way for an MS to access others' UL data fundamentally, in 802.16PHY/MAC. In case of ETH over 802.16, the ETH(bridge) may cover this (an MS sends multicast data in UL, and then a bridge forwards it back). But, there is still a difficulty in multicasting data back except for the source MS. Best regards, Jihoon Lee ============================================================== Jihoon(Brandon) Lee (jhlee@mmlab.snu.ac.kr, brandon.jihoon@gmail.com) Multimedia and Mobile Communication Laboratory, Seoul National University. 2007/1/12, Alexandru Petrescu : > > Hi, sorry for following-up on my own email... > > Alexandru Petrescu wrote: > > gabriel montenegro wrote: > >> GARP/GMRP is not widely deployed, and seems to be obsoleted at the > >> IEEE already. > > > > Thanks for clarification. Maybe IEEE proposes something else > > instead, in order to have link-layer multicast? > > > >> RFC 4541 (MLD snooping) is the deployed solution, as Max already > >> discussed in the November meeting: > >> > >> http://www3.ietf.org/proceedings/06nov/slides/16ng-4/sld7.htm > > Absent GARP/GMRP I think a thing to write in the future version of > IPv6-over-ETHCS draft with respect to multicast is about the multicast > features of the 802.16 MAC and ETHCS? More than the current section 4.3 > saying just that 802.16 MAC dl is mc while ul is not mc > (download/upload/multicast). > > It's clear that IPv6 ND needs a link-layer that is multicast capable, > and in both directions. 802.16 MAC seems to be mc-capable (CID for > multiple links, MCA-REQ/RSP, etc). However, it's not clear to me from > IEEE spec whether (1) both directions are mc capable and (2) the ETHCS > (_over_ 802.16MAC) offers a multicast capable link interface to IP. > > Ie the questions are: (1) will a multicasted NS sent by SS get delivered > to that mc group? or just the RA sent by BS? (is 802.16 MAC mc-capable > in both directions)? and (2) will an IPv6 RA sent to all-nodes IP and > all-nodes MAC address get delivered as such, when it's put on ETHCS (not > on 802.16MAC SAP)? (will the ETHCS classifiers understand MAC multicast > dst addresses.) > > If ETHCS is link-layer multicast capable then it is enough to say in the > document that ETHCS is link-layer multicast capable, with an example. > If ETHCS is not link-layer multicast capable, bidirectionally, I think > the draft should say that ETHCS should be link-layer multicast capable, > bidirectionally, otherwise IPv6 doesn't work on it. I don't think the > draft should develop a technique to make ETHCS link-layer multicast > capable, bidirectionally. > > If there is agreement or incentive I can provide text as I suggested > above. > > Alex > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > ------=_Part_21903_21380906.1168563782155 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
Let me jump into discussion.
1) 802.16/16e MAC has no capability to do uplink multicast. In DL, 802.16 provides multicast CIDs which is initiated by DSA messages. In UL, however, there is no way for an MS to access others' UL data fundamentally, in 802.16 PHY/MAC. In case of ETH over 802.16, the ETH(bridge) may cover this (an MS sends multicast data in UL, and then a bridge forwards it back). But, there is still a difficulty in multicasting data back except for the source MS.
 
Best regards,
Jihoon Lee
 
==============================================================

Jihoon(Brandon) Lee (jhlee@mmlab.snu.ac.kr, brandon.jihoon@gmail.com )
Multimedia  and Mobile Communication Laboratory, Seoul National University.

 
2007/1/12, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Hi, sorry for following-up on my own email...

Alexandru Petrescu wrote:
> gabriel montenegro wrote:
>> GARP/GMRP is not widely deployed, and seems to be obsoleted at the
>>  IEEE already.
>
> Thanks for clarification.  Maybe IEEE proposes something else
> instead, in order to have link-layer multicast?
>
>> RFC 4541 (MLD snooping) is the deployed solution, as Max already
>> discussed in the November meeting:
>>
>> http://www3.ietf.org/proceedings/06nov/slides/16ng-4/sld7.htm

Absent GARP/GMRP I think a thing to write in the future version of
IPv6-over-ETHCS draft with respect to multicast is about the multicast
features of the 802.16 MAC and ETHCS?  More than the current section 4.3
saying just that 802.16 MAC dl is mc while ul is not mc
(download/upload/multicast).

It's clear that IPv6 ND needs a link-layer that is multicast capable,
and in both directions.  802.16 MAC seems to be mc-capable (CID for
multiple links, MCA-REQ/RSP, etc).  However, it's not clear to me from
IEEE spec whether (1) both directions are mc capable and (2) the ETHCS
(_over_ 802.16MAC) offers a multicast capable link interface to IP.

Ie the questions are: (1) will a multicasted NS sent by SS get delivered
to that mc group?  or just the RA sent by BS? (is 802.16 MAC mc-capable
in both directions)? and (2) will an IPv6 RA sent to all-nodes IP and
all-nodes MAC address get delivered as such, when it's put on ETHCS (not
on 802.16MAC SAP)?  (will the ETHCS classifiers understand MAC multicast
dst addresses.)

If ETHCS is link-layer multicast capable then it is enough to say in the
document that ETHCS is link-layer multicast capable, with an example.
If ETHCS is not link-layer multicast capable, bidirectionally, I think
the draft should say that ETHCS should be link-layer multicast capable,
bidirectionally, otherwise IPv6 doesn't work on it.  I don't think the
draft should develop a technique to make ETHCS link-layer multicast
capable, bidirectionally.

If there is agreement or incentive I can provide text as I suggested above.

Alex

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

------=_Part_21903_21380906.1168563782155-- --===============0049479508== 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 --===============0049479508==-- From 16ng-bounces@ietf.org Thu Jan 11 21:23:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5C4a-0003BI-9A; Thu, 11 Jan 2007 21:23:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5C4Y-0003A0-Is for 16ng@ietf.org; Thu, 11 Jan 2007 21:23:14 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5C1p-0001i0-Gp for 16ng@ietf.org; Thu, 11 Jan 2007 21:20:27 -0500 Received: by wr-out-0506.google.com with SMTP id 36so506706wra for <16ng@ietf.org>; Thu, 11 Jan 2007 18:20:25 -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=RQVIc35WAhw9SX7PnFUjymySyUIVuF2K9/PkJC2hdthSreGFmoOi6Y8LZ3ip3RavEse+FokQDuR5iN4Cp8oF/2TG4z9l4DxXksjXahFpEg2pLu3qUHnw6gFlEaE710E0OkwI6HbE4QsodxQrO6jZvSAF3/bOErfJQ8vwOoV68vk= Received: by 10.35.75.1 with SMTP id c1mr173842pyl.1168568425124; Thu, 11 Jan 2007 18:20:25 -0800 (PST) Received: by 10.35.35.13 with HTTP; Thu, 11 Jan 2007 18:20:24 -0800 (PST) Message-ID: <92e919fb0701111820k3aa970aft5001f778e8e46d93@mail.gmail.com> Date: Fri, 12 Jan 2007 11:20:25 +0900 From: "JinHyeock Choi" To: "Alexandru Petrescu" Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] In-Reply-To: <45A6AA0C.7040508@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45A6AA0C.7040508@motorola.com> 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 Dear Alex Thanks for your feedback. Kindly find my in-line comments. > > and there is no reason for the host to depend on RAs to detect if it > > has moved across ARs. Hence there is no reason for any change w.r.t > > 3775 and I do not see RFC3775 over-riding the values specified here. > > There is no other means for an IP stack on top of IPv6CS to know that > the subnet has changed. This is where MIP6 reacts, on subnet change, > not on PHY change. So the 802.16 BS, if it sends RAs, it should send > them quickly. Allow me to make is more clear. A 802.16 host doesn't have to rely on unsolicited PERIODIC RAs for movement detection. Upon network attachment, either 1) the access router sends an unsolicted RA as of FRD (draft-ietf-dna-frd-02) or 2) the host sends an RS to get a solicited RA as of DNAv6 (draft-ietf-dna-protocol-03.txt). So RA interval won't affect movement detection (or DNA) delay. 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 Jan 12 06:06:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5KF5-0000Bg-9K; Fri, 12 Jan 2007 06:06:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5KF3-0000Bb-R9 for 16ng@ietf.org; Fri, 12 Jan 2007 06:06:37 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5KF1-0004gR-JO for 16ng@ietf.org; Fri, 12 Jan 2007 06:06:37 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1168599994!8429305!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1207 invoked from network); 12 Jan 2007 11:06:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 12 Jan 2007 11:06:34 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0CB6YsV012730; Fri, 12 Jan 2007 04:06:34 -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 l0CB6XBX016055; Fri, 12 Jan 2007 05:06:33 -0600 (CST) Message-ID: <45A76BB7.9070604@motorola.com> Date: Fri, 12 Jan 2007 12:06:31 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JinHyeock Choi Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] References: <45A6AA0C.7040508@motorola.com> <92e919fb0701111820k3aa970aft5001f778e8e46d93@mail.gmail.com> In-Reply-To: <92e919fb0701111820k3aa970aft5001f778e8e46d93@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: e1e48a527f609d1be2bc8d8a70eb76cb 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 JinHyeock, JinHyeock Choi wrote: > Dear Alex > > Thanks for your feedback. Kindly find my in-line comments. > >>> and there is no reason for the host to depend on RAs to detect if >>> it has moved across ARs. Hence there is no reason for any change >>> w.r.t 3775 and I do not see RFC3775 over-riding the values >>> specified here. >> >> There is no other means for an IP stack on top of IPv6CS to know >> that the subnet has changed. This is where MIP6 reacts, on subnet >> change, not on PHY change. So the 802.16 BS, if it sends RAs, it >> should send them quickly. > > Allow me to make is more clear. > > A 802.16 host doesn't have to rely on unsolicited PERIODIC RAs for > movement detection. Upon network attachment, either 1) the access > router sends an unsolicted RA as of FRD (draft-ietf-dna-frd-02) or 2) > the host sends an RS to get a solicited RA as of DNAv6 > (draft-ietf-dna-protocol-03.txt). I am not sure what you mean by 'network attachment'? I suppose you mean the network entry procedure of 802.16? ('Attach' in 802.16 mostly means to attach a part of message to another part, and only in one single place a SS to a BS). In the network entry procedure of the 802.16 document there is nothing that suggests the behaviour you suggest above (DNA). Only ND is suggested, not DNA. Periodic RA is in widespread use for movement detection. I do not understand the opposition to use periodic RAs as allowed by rfc3775. What breaks if we use periodic RAs with a frequency higher than 1/4s? (remark arguments of air interface gains are different on high-bandwidth links). Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 06:19:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5KRe-0007Pu-Dh; Fri, 12 Jan 2007 06:19:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5KRc-0007PN-Ly for 16ng@ietf.org; Fri, 12 Jan 2007 06:19:36 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5KRb-0007LZ-Eu for 16ng@ietf.org; Fri, 12 Jan 2007 06:19:36 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1168600774!8048589!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10454 invoked from network); 12 Jan 2007 11:19:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 12 Jan 2007 11:19:34 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0CBJYkO016072; Fri, 12 Jan 2007 04:19:34 -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 l0CBJXeq020618; Fri, 12 Jan 2007 05:19:33 -0600 (CST) Message-ID: <45A76EC4.7070304@motorola.com> Date: Fri, 12 Jan 2007 12:19:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: v6ops@ops.ietf.org, 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS 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 Jihoon, thanks for reply, Jihoon Lee wrote: > Hi Alex, > > Let me jump into discussion. 1) 802.16/16e MAC has no capability to > do uplink multicast. In DL, 802.16 provides multicast CIDs which is > initiated by DSA messages. In UL, however, there is no way for an MS > to access others' UL data fundamentally, in 802.16 PHY/MAC. Ok. For one, if the 802.16MAC is not capable to do bidirectional (or normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to mention the word 'multicast'.) The issue is that a SS running IPv6 needs to multicast a NA, from time to time. For DAD it needs to send a NS to a multicast address too. > In case of ETH over 802.16, the ETH(bridge) may cover this (an MS > sends multicast data in UL, and then a bridge forwards it back). But, > there is still a difficulty in multicasting data back except for the > source MS. You mean the bridge in BS? I was thinking ETHCS in SS may offer a multicast interface to the IP stack. In both cases (bridge in BS or bridge in SS), I think it is not up to this document to specify how the ETHCS transforms a asymmetric ul/dl multicast feature into a symmetric one. But it should be a goal for ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6 stack won't work. What do you think? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 09:25:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NLC-0000HR-O6; Fri, 12 Jan 2007 09:25:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NLB-0000HJ-Gz for 16ng@ietf.org; Fri, 12 Jan 2007 09:25:09 -0500 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NLA-0006RR-3t for 16ng@ietf.org; Fri, 12 Jan 2007 09:25:09 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 0FA6B2FFD4; Fri, 12 Jan 2007 15:24:56 +0100 (CET) Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS From: Pars Mutaf To: Alexandru Petrescu In-Reply-To: <45A76EC4.7070304@motorola.com> References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> Content-Type: text/plain Organization: INT Evry Date: Fri, 12 Jan 2007 15:25:00 +0100 Message-Id: <1168611900.3013.9.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: v6ops@ops.ietf.org, 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr 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, sorry for popping up, On Fri, 2007-01-12 at 12:19 +0100, Alexandru Petrescu wrote: > Hi Jihoon, thanks for reply, > > Jihoon Lee wrote: > > Hi Alex, > > > > Let me jump into discussion. 1) 802.16/16e MAC has no capability to > > do uplink multicast. In DL, 802.16 provides multicast CIDs which is > > initiated by DSA messages. In UL, however, there is no way for an MS > > to access others' UL data fundamentally, in 802.16 PHY/MAC. Do you think this is an accidental design choice (i.e. no uplink multicast)? Or 802.16/16e MAC designers had very good fundamental reasons? (I'm sorry. This question looks out-of IETF scope. But I think we may learn something more general i.e. useful to IP perhaps?) Thank you. pars > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and > surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to > mention the word 'multicast'.) > > The issue is that a SS running IPv6 needs to multicast a NA, from time > to time. For DAD it needs to send a NS to a multicast address too. > > > In case of ETH over 802.16, the ETH(bridge) may cover this (an MS > > sends multicast data in UL, and then a bridge forwards it back). But, > > there is still a difficulty in multicasting data back except for the > > source MS. > > You mean the bridge in BS? I was thinking ETHCS in SS may offer a > multicast interface to the IP stack. > > In both cases (bridge in BS or bridge in SS), I think it is not up to > this document to specify how the ETHCS transforms a asymmetric ul/dl > multicast feature into a symmetric one. But it should be a goal for > ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6 > stack won't work. What do you think? > > Alex > > _______________________________________________ > 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 Jan 12 09:46:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NfJ-0004BU-Q6; Fri, 12 Jan 2007 09:45:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5NfI-0004BE-Bd for 16ng@ietf.org; Fri, 12 Jan 2007 09:45:56 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5NfH-0003QJ-LI for 16ng@ietf.org; Fri, 12 Jan 2007 09:45:56 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0CEhhaJ007338; Fri, 12 Jan 2007 16:43:50 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 16:45:43 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 08:45:41 -0600 Received: from 10.162.252.86 ([10.162.252.86]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jan 2007 14:45:39 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 12 Jan 2007 08:47:19 -0600 From: Basavaraj Patil To: <16ng@ietf.org> Message-ID: Thread-Topic: Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] Thread-Index: Acc2WI8lzawCGKJLEduZwQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 14:45:41.0293 (UTC) FILETIME=[54E90DD0:01C73658] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112164350-1C2BFBB0-66DC7E68/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Subject: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] 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 Comments by Bruno Sousa: >Here is my contribution to the draft-ietf-16ng-ipv6-over-ipv6cs-04, >many of the issues I'm pointing come from the previous version of this >draft. > >1) Typos (besides the ones pointed by Junghoon Jee) > - inclide (page 5) --> include > - service specific or service-specific (page 5 and others) I think we >should be coherent. > - enacapsulated (page 7) --> encapsulated > - specfic (page 7, section 4.1) --> specific > - sucesful (page 10, section 6.2 and page 17 appendix C) --> >successful Could not find this typo. > - succesfull (page 10, section 6.2) --> successful > - Hader (page 11, section 6.3) --> Header > Fixed the rest of the typos. > >2) Terminology (section 3 and section 5). >I'm questioning myself why only the definition of the ASN? >For instance, important terms, used through out the memo are IPv6 link, >L2 link. >I think these ones should also be clarified from the beginning. The intent is to use common terminology and ASN is the only term that is specific to this document. The rest of the terms are intended to be included in the next rev of the 16NG PS I-D. The terminology proposed for inclusion in the PS I-D is in the email: http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html > >I agree with the term ASN here, nevertheless it does not appear cited on >the document, >with the exception of the appendixes A and C. >I think it is important to refer it on the section 5, >the generic network architecture, when talking on the access network. If you were to look back to rev 2 of this I-D, you will see the WiMAX specifics being a part of the normative part of the I-D. However based on the WG objectives and the goal for this I-D, it was decided that the draft would be applicable to a generic 802.16 network and not just WiMAX. Hence the WiMAX specific parts are now in an appendix. Maybe I could even move the term ASN to the appendix. Adding WiMAX specific text in the main body of the I-D is not an option. > > >3) IPv6 link (section 6) >" A link is bounded by routers that decrement TTL." >If we are talking about IPv6, shouldn't we refer Hop Limit instead of TTL?! > Yes, I agree. Fixed it. > >4) IPv6 link in 802.16 >" > In 802.16, there exists an L2 Transport Connection between an MS and > a BS which is used to transport user data, i.e IPv6 packets in this > case. A Transport Connection is represented by a CID (Connection > Identifier) and multiple Transport Connections can exist between an > MS and BS. >" >I think the first sentence is somehow contradictory with the rest of the >paragraph. >It is possible to have more then one transport connection between MS and BS. >These transport connections are defined on the MAC layer (L2), >so why refer "there exists an L2 Transport Connection?!" > >(If my thoughts are correct) I propose to change the first sentence to: > > In 802.16, the Transport Connection between an MS and a BS is used > to transport user data, i.e. IPv6 packets in this case. Agreed. Incorporated the proposed sentence. > > >5) Maximum transmission unit in 802.16 (section 6.3) > >" > The 802.16 MAC header is a 6 byte header followed by the payload and > a 4 byte CRC which covers the whole PDU (Protocol Data Unit). The > length of the PDU is indicated by the Len parameter in the Generic > MAC HDR. >" >As reading, we may think that the payload and the CRC are always present >on the MAC frames. >They are not included in all messages. So I suggest to rewrite this, >starting with: > > The 802.16 MAC PDU (Protocol Data Unit) is composed by > a 6 byte header followed by an optional payload and > an optional CRC covering the header and the payload. > Okay... I changed the text in the I-D as proposed. >This introduction has also the propose to clarify the covering of the >CRC (header + payload) >and not the whole PDU (since this one can include the CRC). > > >6) IPv6 prefix assignment (section 7) >I suggest to add a reference to the RFC2461, to clarify where the >on-link flag is defined: > > The prefixes are advertised with the on-link (L-bit) flag set as >specified in RFC2461. Okay. Done. > > >This section starts with: >" > Each MS can be considered to be on a separate subnet as a result of >the point-to-point connection. >" >In the middle there is a sentence: >" > Each MS MUST be considered to be on a separate subnet as a result of >the point-to-point connection. >" >Shouldn't here we have a consensus also? >(probably this is an issue related with RFC2119) So can or MUST?! >And the sentences aren't repeating themselves in the same section? > Agree. Fixed it. > >7) Appendix D >This section introduces the SDU size proposed by the WiMAX forum. >I just want to point that there is no a relation with the SDU and >the IPv6 payload spoken along the document. >Shouldn't this be clarified?! I dont think that is necessary. Within the main body of the text it is clear what the MAX IPv6 payload size can be. And in the appendix, the I-D is making a recomendation that the MAX MTU be 1400 bytes by default but obviously can be anything between 1280 and 1500. Thanks for reviewing and your comments on the I-D. -Raj > > >Kindly, >Bruno Sousa > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 11:51:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PcL-0003eE-6L; Fri, 12 Jan 2007 11:51:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PcK-0003dl-1Y for 16ng@ietf.org; Fri, 12 Jan 2007 11:51:00 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5PcI-00082J-GA for 16ng@ietf.org; Fri, 12 Jan 2007 11:51:00 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1168620247!12721283!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 956 invoked from network); 12 Jan 2007 16:44:07 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-4.tower-128.messagelabs.com with SMTP; 12 Jan 2007 16:44:07 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l0CGpBfJ010796; Fri, 12 Jan 2007 09:51:11 -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 l0CGi1Sg029912; Fri, 12 Jan 2007 10:44:02 -0600 (CST) Message-ID: <45A7BACF.9070200@motorola.com> Date: Fri, 12 Jan 2007 17:43:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: pars.mutaf@int-evry.fr Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <1168611900.3013.9.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1168611900.3013.9.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: v6ops@ops.ietf.org, 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 Pars, I would like so see others' oppinions on this too. Pars Mutaf wrote: > Hi, sorry for popping up, > > On Fri, 2007-01-12 at 12:19 +0100, Alexandru Petrescu wrote: >> Hi Jihoon, thanks for reply, >> >> Jihoon Lee wrote: >>> Hi Alex, >>> >>> Let me jump into discussion. 1) 802.16/16e MAC has no capability >>> to do uplink multicast. In DL, 802.16 provides multicast CIDs >>> which is initiated by DSA messages. In UL, however, there is no >>> way for an MS to access others' UL data fundamentally, in 802.16 >>> PHY/MAC. > > Do you think this is an accidental design choice (i.e. no uplink > multicast)? Or 802.16/16e MAC designers had very good fundamental > reasons? I'm not a link-layer designer. I think the choice for 802.16MAC to design multicast only downlink (not ul) is inline with the widespread usage of mobile terminals: clients download stuff, rarely upload. Multi-party video calls (not even IP) need however multicast to run bothways ok to gain in efficiency. And there are link-layers (802.11) that offer a multicast appearence to the IP stack, bothways, despite the lower layer packet being sent through the AP always. This should happen over 802.16MAC ETHCS too, otherwise ND won't work. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 11:57:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Pia-0000eI-Kt; Fri, 12 Jan 2007 11:57:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5PiZ-0000eD-LE for 16ng@ietf.org; Fri, 12 Jan 2007 11:57:27 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5PiY-0000yr-6o for 16ng@ietf.org; Fri, 12 Jan 2007 11:57:27 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1168621043!8067058!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5042 invoked from network); 12 Jan 2007 16:57:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 12 Jan 2007 16:57:23 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0CGvKVx023534; Fri, 12 Jan 2007 09:57:23 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0CGvGPe014093; Fri, 12 Jan 2007 10:57:17 -0600 (CST) Message-ID: <45A7BDEB.1000306@motorola.com> Date: Fri, 12 Jan 2007 17:57:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] 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: 97adf591118a232206bdb5a27b217034 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, please allow me to interfere with clarifications. Basavaraj Patil wrote: > > Comments by Bruno Sousa: [skip parts I agree] >> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 Transport >> Connection between an MS and a BS which is used to transport user >> data, i.e IPv6 packets in this case. A Transport Connection is >> represented by a CID (Connection Identifier) and multiple Transport >> Connections can exist between an MS and BS. " I think the first >> sentence is somehow contradictory with the rest of the paragraph. >> It is possible to have more then one transport connection between >> MS and BS. These transport connections are defined on the MAC layer >> (L2), so why refer "there exists an L2 Transport Connection?!" >> >> (If my thoughts are correct) I propose to change the first sentence >> to: >> >> In 802.16, the Transport Connection between an MS and a BS is used >> to transport user data, i.e. IPv6 packets in this case. > > Agreed. Incorporated the proposed sentence. But there are IPv6 packets that are sent on the Secondary Management Connection as well (RS/RA at least) 6.3.9.10 802.16e-2005. I suggest saying that only _some_ of the IPv6 packets are transported on some Transport Connection, or along these lines. Probably best for reader would be to enumerate the different types of Connections the SS can handle and where do IPv6 packets appear. What do you think? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 12:04:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ppm-0004jH-1s; Fri, 12 Jan 2007 12:04:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ppk-0004iD-UY for 16ng@ietf.org; Fri, 12 Jan 2007 12:04:52 -0500 Received: from mail714.megamailservers.com ([69.49.98.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Ppi-0002mz-R6 for 16ng@ietf.org; Fri, 12 Jan 2007 12:04:52 -0500 X-Authenticated-User: ray.grid-net.com Received: from RBLAPTOP (h-68-167-203-98.snfccasy.covad.net [68.167.203.98]) (authenticated bits=0) by mail714.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id l0CH4iHm000539; Fri, 12 Jan 2007 12:04:47 -0500 From: "Ray Bell" To: "'Alexandru Petrescu'" , Subject: RE: [16NG] Re: multicast and IPv6 over ETHCS Date: Fri, 12 Jan 2007 09:04:40 -0800 Message-ID: <000801c7366b$c0d566c0$62cba744@RBLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acc2aeXnr/cOKnprSS620hw3ABuyrAAAF2gg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45A7BACF.9070200@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: v6ops@ops.ietf.org, 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 Alex, I agree with your comments, and believe it is important to point out that while 802.16e will be used by moble terminals, it will also be used by fixed terminals (e.g., LAN WiMAX modem) -- by both retail & enterprise customers. I believe that this reinforces the requirements which you have noted... Ray -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] Sent: Friday, January 12, 2007 8:44 AM To: pars.mutaf@int-evry.fr Cc: v6ops@ops.ietf.org; 16ng@ietf.org Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS Hi Pars, I would like so see others' oppinions on this too. Pars Mutaf wrote: > Hi, sorry for popping up, > > On Fri, 2007-01-12 at 12:19 +0100, Alexandru Petrescu wrote: >> Hi Jihoon, thanks for reply, >> >> Jihoon Lee wrote: >>> Hi Alex, >>> >>> Let me jump into discussion. 1) 802.16/16e MAC has no capability >>> to do uplink multicast. In DL, 802.16 provides multicast CIDs >>> which is initiated by DSA messages. In UL, however, there is no >>> way for an MS to access others' UL data fundamentally, in 802.16 >>> PHY/MAC. > > Do you think this is an accidental design choice (i.e. no uplink > multicast)? Or 802.16/16e MAC designers had very good fundamental > reasons? I'm not a link-layer designer. I think the choice for 802.16MAC to design multicast only downlink (not ul) is inline with the widespread usage of mobile terminals: clients download stuff, rarely upload. Multi-party video calls (not even IP) need however multicast to run bothways ok to gain in efficiency. And there are link-layers (802.11) that offer a multicast appearence to the IP stack, bothways, despite the lower layer packet being sent through the AP always. This should happen over 802.16MAC ETHCS too, otherwise ND won't work. Alex _______________________________________________ 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 Jan 12 12:15:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Pzi-0003hg-MF; Fri, 12 Jan 2007 12:15:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Pzg-0003h2-Nb for 16ng@ietf.org; Fri, 12 Jan 2007 12:15:08 -0500 Received: from mail.deterministicnetworks.com ([205.179.45.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Pza-0005Q0-Pt for 16ng@ietf.org; Fri, 12 Jan 2007 12:15:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.deterministicnetworks.com (Postfix) with ESMTP id 4D567E400E; Fri, 12 Jan 2007 08:58:57 -0800 (PST) Received: from mail.deterministicnetworks.com ([127.0.0.1]) by localhost (mail [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03040-02; Fri, 12 Jan 2007 08:58:56 -0800 (PST) Received: from Deterministic1 (iftp.deterministicnetworks.com [205.179.45.3]) by mail.deterministicnetworks.com (Postfix) with SMTP id 9A818E400D; Fri, 12 Jan 2007 08:58:55 -0800 (PST) Message-ID: <001501c7366d$2ca2f240$6700a8c0@Deterministic1> From: "Steve Jackowski" To: "Alexandru Petrescu" , References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com><1168611900.3013.9.camel@lor-maknavic3.int-evry.fr> <45A7BACF.9070200@motorola.com> Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS Date: Fri, 12 Jan 2007 09:14:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at DeterministicNetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: v6ops@ops.ietf.org, 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 All, My 2 cents: We work with WiMax and Satellite providers (who have the same basic topology). The issue we've seen is the contention for the RF channels. This can be avoided on the downlinks, but is critical on the uplinks. The asymmetry between up and downlinks combined with the point-multipoint topology exacerbates the problem. At this time, most WiMax vendors are trying to block uplink broadcast/multicast to maximize uplink bandwidth available to subscribers (and to maximize the number of subscribers). While historically networks had more download traffic than upload, the trend towards more peer-oriented networking creates a challenge that will ultmately be addressed, but is currently one of the biggest problems in WiMax. Steve ---------------------------------------------------------------- Steve Jackowski President/CEO Deterministic Networks, Inc. 1200 Pacific Avenue, Ste 280 Santa Cruz, Ca 95060 Office: (831) 421-0388 x18 Mobile: (408) 813-6294 Fax: (831) 421-0394 www.DeterministicNetworks.com "Secure Network Acceleration" ----- Original Message ----- From: "Alexandru Petrescu" To: Cc: ; <16ng@ietf.org> Sent: Friday, January 12, 2007 8:43 AM Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS > Hi Pars, I would like so see others' oppinions on this too. > > Pars Mutaf wrote: >> Hi, sorry for popping up, >> >> On Fri, 2007-01-12 at 12:19 +0100, Alexandru Petrescu wrote: >>> Hi Jihoon, thanks for reply, >>> >>> Jihoon Lee wrote: >>>> Hi Alex, >>>> >>>> Let me jump into discussion. 1) 802.16/16e MAC has no capability to do >>>> uplink multicast. In DL, 802.16 provides multicast CIDs which is >>>> initiated by DSA messages. In UL, however, there is no way for an MS to >>>> access others' UL data fundamentally, in 802.16 PHY/MAC. >> >> Do you think this is an accidental design choice (i.e. no uplink >> multicast)? Or 802.16/16e MAC designers had very good fundamental >> reasons? > > I'm not a link-layer designer. I think the choice for 802.16MAC to > design multicast only downlink (not ul) is inline with the widespread > usage of mobile terminals: clients download stuff, rarely upload. > > Multi-party video calls (not even IP) need however multicast to run > bothways ok to gain in efficiency. > > And there are link-layers (802.11) that offer a multicast appearence to > the IP stack, bothways, despite the lower layer packet being sent > through the AP always. This should happen over 802.16MAC ETHCS too, > otherwise ND won't work. > > Alex > > _______________________________________________ > 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 Jan 12 12:20:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q5L-00014Y-Us; Fri, 12 Jan 2007 12:20:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q5K-00014S-DR for 16ng@ietf.org; Fri, 12 Jan 2007 12:20:58 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5Q5H-0000Qn-RE for 16ng@ietf.org; Fri, 12 Jan 2007 12:20:58 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0CHJRRu003595; Fri, 12 Jan 2007 19:19:31 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 19:20:49 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 11:20:46 -0600 Received: from 172.19.244.117 ([172.19.244.117]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jan 2007 17:20:46 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 12 Jan 2007 11:22:25 -0600 Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] Thread-Index: Acc2bjn0eK79aaJhEduv0AARJNUNiA== In-Reply-To: <45A7BDEB.1000306@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 17:20:46.0831 (UTC) FILETIME=[FF7177F0:01C7366D] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112191931-0DC7ABB0-1E8BFAC4/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Alex, Inline: On 1/12/07 10:57 AM, "ext Alexandru Petrescu" wrote: > Hi, please allow me to interfere with clarifications. > > Basavaraj Patil wrote: >> >> Comments by Bruno Sousa: > [skip parts I agree] >>> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 Transport >>> Connection between an MS and a BS which is used to transport user >>> data, i.e IPv6 packets in this case. A Transport Connection is >>> represented by a CID (Connection Identifier) and multiple Transport >>> Connections can exist between an MS and BS. " I think the first >>> sentence is somehow contradictory with the rest of the paragraph. >>> It is possible to have more then one transport connection between >>> MS and BS. These transport connections are defined on the MAC layer >>> (L2), so why refer "there exists an L2 Transport Connection?!" >>> >>> (If my thoughts are correct) I propose to change the first sentence >>> to: >>> >>> In 802.16, the Transport Connection between an MS and a BS is used >>> to transport user data, i.e. IPv6 packets in this case. >> >> Agreed. Incorporated the proposed sentence. > > But there are IPv6 packets that are sent on the Secondary Management > Connection as well (RS/RA at least) 6.3.9.10 802.16e-2005. I suggest > saying that only _some_ of the IPv6 packets are transported on some > Transport Connection, or along these lines. The secondary management connection is typically not used for user data. As the .16 spec says it can be used for address configuration, TFTP etc. Also to be noted is the fact that secondary management connections are not mandatorily required. The usage for which it has been defined can be accomplished via a regular transport connection. >From a practical standapoint, I do not see hosts or BS' implementing or using the secondary management connection. So I can mention it in the text of the I-D, but it would not be very useful. > > Probably best for reader would be to enumerate the different types of > Connections the SS can handle and where do IPv6 packets appear. What do > you think? I don't think we should get into the details of the various types of connections in the I-D. The reference to the .16 spec is sufficient for that. But I can mention that there does exist the secondary management connection which may be used for host configuration with a caveat that for all practical purposes it is better to use a transport connection for the same. The reason why the secondary management connection does not make sense is because it is limited in its capability. Establishing a transport connection instead allows you to do the same host configuration as well as use it for user traffic. -Raj > > Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 12:35:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QJU-0002Rx-14; Fri, 12 Jan 2007 12:35:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QJT-0002QW-Ay for 16ng@ietf.org; Fri, 12 Jan 2007 12:35:35 -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 1H5QHY-0002UA-9K for 16ng@ietf.org; Fri, 12 Jan 2007 12:33:37 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0CHV7dX008167; Fri, 12 Jan 2007 19:31:37 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 19:33:26 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 11:33:23 -0600 Received: from 172.19.244.117 ([172.19.244.117]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jan 2007 17:33:22 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 12 Jan 2007 11:35:02 -0600 Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] From: Basavaraj Patil To: ext Alexandru Petrescu , JinHyeock Choi Message-ID: Thread-Topic: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] Thread-Index: Acc2b/0pO4HewqJjEduv0AARJNUNiA== In-Reply-To: <45A76BB7.9070604@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 17:33:23.0473 (UTC) FILETIME=[C26FE010:01C7366F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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, On 1/12/07 5:06 AM, "ext Alexandru Petrescu" wrote: > > Periodic RA is in widespread use for movement detection. I do not > understand the opposition to use periodic RAs as allowed by rfc3775. > What breaks if we use periodic RAs with a frequency higher than 1/4s? > (remark arguments of air interface gains are different on high-bandwidth > links). The fact is that sending periodic RAs on an air interface irrespective of BW capacity is suboptimal. A host in Idle mode is not listening for periodic RAs. Listening for periodic RAs would prevent the host from transitioning to idle mode which has an adverse impact on battery life. 802.16 has defined paging and Idle mode support. In air-interfaces that do not support such capability, sending of very frequent RAs is possible but IMO still not the most efficient usage of the bandwidth. In licensed spectrum the optimization and efficiency of the air interface is critical. Periodic RAs are unavoidable at this time. The best that we can do without breaking backward compatibility is to send it with large time intervals as the I-D suggests. Movement detection can be done be accomplished by other means. If the host is only relying on RAs for movement detection (at the IP layer), then it could just as well send a Rtr solicitation. This is not prevented. In Unlicensed spectrum you may have a bit more liberty about how the air-interface is used but even in those cases, optimizing it is a better choice. -Raj > > Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 12:53:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QaE-0004BT-Mt; Fri, 12 Jan 2007 12:52:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QaD-0004AW-HV for 16ng@ietf.org; Fri, 12 Jan 2007 12:52:53 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5QaC-0007aS-4t for 16ng@ietf.org; Fri, 12 Jan 2007 12:52:53 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1168624370!5119429!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 11812 invoked from network); 12 Jan 2007 17:52:51 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-8.tower-128.messagelabs.com with SMTP; 12 Jan 2007 17:52:51 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l0CHqkfC007481; Fri, 12 Jan 2007 10:52:50 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0CHqiA2014562; Fri, 12 Jan 2007 11:52:45 -0600 (CST) Message-ID: <45A7CAEB.5080906@motorola.com> Date: Fri, 12 Jan 2007 18:52:43 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] 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: 0fa76816851382eb71b0a882ccdc29ac 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 Basavaraj Patil wrote: > Alex, > > Inline: > > > On 1/12/07 10:57 AM, "ext Alexandru Petrescu" > wrote: > >> Hi, please allow me to interfere with clarifications. >> >> Basavaraj Patil wrote: >>> Comments by Bruno Sousa: >> [skip parts I agree] >>>> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 >>>> Transport Connection between an MS and a BS which is used to >>>> transport user data, i.e IPv6 packets in this case. A >>>> Transport Connection is represented by a CID (Connection >>>> Identifier) and multiple Transport Connections can exist >>>> between an MS and BS. " I think the first sentence is somehow >>>> contradictory with the rest of the paragraph. It is possible to >>>> have more then one transport connection between MS and BS. >>>> These transport connections are defined on the MAC layer (L2), >>>> so why refer "there exists an L2 Transport Connection?!" >>>> >>>> (If my thoughts are correct) I propose to change the first >>>> sentence to: >>>> >>>> In 802.16, the Transport Connection between an MS and a BS is >>>> used to transport user data, i.e. IPv6 packets in this case. >>> Agreed. Incorporated the proposed sentence. >> But there are IPv6 packets that are sent on the Secondary >> Management Connection as well (RS/RA at least) 6.3.9.10 >> 802.16e-2005. I suggest saying that only _some_ of the IPv6 >> packets are transported on some Transport Connection, or along >> these lines. > > The secondary management connection is typically not used for user > data. As the .16 spec says it can be used for address configuration, > TFTP etc. Not only that it can but it must, by that spec. > Also to be noted is the fact that secondary management connections > are not mandatorily required. The usage for which it has been defined > can be accomplished via a regular transport connection. I don't think the 802.16 spec says anywhere that RS/RA could be sent on anything else than Secondary Management Connection. Do you? >> From a practical standapoint, I do not see hosts or BS' >> implementing or using the secondary management connection. So I can >> mention it in the text of the I-D, but it would not be very >> useful. >> > >> Probably best for reader would be to enumerate the different types >> of Connections the SS can handle and where do IPv6 packets appear. >> What do you think? > > I don't think we should get into the details of the various types of > connections in the I-D. The reference to the .16 spec is sufficient > for that. But I can mention that there does exist the secondary > management connection which may be used for host configuration with a > caveat that for all practical purposes it is better to use a > transport connection for the same. > > The reason why the secondary management connection does not make > sense is because it is limited in its capability. Establishing a > transport connection instead allows you to do the same host > configuration as well as use it for user traffic. I am afraid the 802.16 spec clearly says RS/RA only happen on the Secondary Management Connection and we can't suggest do it otherwise. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 13:07:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qo6-00058V-0x; Fri, 12 Jan 2007 13:07:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qo4-00058P-00 for 16ng@ietf.org; Fri, 12 Jan 2007 13:07:12 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5Qo1-0001y0-Kg for 16ng@ietf.org; Fri, 12 Jan 2007 13:07:11 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1168625228!4678708!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 530 invoked from network); 12 Jan 2007 18:07:08 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-12.tower-128.messagelabs.com with SMTP; 12 Jan 2007 18:07:08 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0CI78ju017368; Fri, 12 Jan 2007 11:07:08 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0CI752U006363; Fri, 12 Jan 2007 12:07:06 -0600 (CST) Message-ID: <45A7CE49.7080003@motorola.com> Date: Fri, 12 Jan 2007 19:07:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] 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: c1c65599517f9ac32519d043c37c5336 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 Basavaraj Patil wrote: > Hi Alex, > > On 1/12/07 5:06 AM, "ext Alexandru Petrescu" > wrote: > >> Periodic RA is in widespread use for movement detection. I do not >> understand the opposition to use periodic RAs as allowed by >> rfc3775. What breaks if we use periodic RAs with a frequency higher >> than 1/4s? (remark arguments of air interface gains are different >> on high-bandwidth links). > > The fact is that sending periodic RAs on an air interface > irrespective of BW capacity is suboptimal. A host in Idle mode is not > listening for periodic RAs. Listening for periodic RAs would prevent > the host from transitioning to idle mode which has an adverse impact > on battery life. 802.16 has defined paging and Idle mode support. In > air-interfaces that do not support such capability, sending of very > frequent RAs is possible but IMO still not the most efficient usage > of the bandwidth. In licensed spectrum the optimization and > efficiency of the air interface is critical. Periodic RAs are > unavoidable at this time. The best that we can do without breaking > backward compatibility is to send it with large time intervals as the > I-D suggests. Movement detection can be done be accomplished by > other means. If the host is only relying on RAs for movement > detection (at the IP layer), then it could just as well send a Rtr > solicitation. This is not prevented. > > In Unlicensed spectrum you may have a bit more liberty about how the > air-interface is used but even in those cases, optimizing it is a > better choice. Raj, I understand a strong pushback from you about having periodic RAs with less than 4s. I think it's not motivated. Let's then discuss the RS method for quick movement detection. Do you agree that (1) an SS can't multicast an RS because 802.16e IPv6CS doesn't support ul multicast? and that (2) there's no means for SS to unicast the RS because it doesn't know the BS's link-local address because no message in the network entry procedure delivers BS's link-local address? What do you think? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 13:11:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qrq-00016d-Ud; Fri, 12 Jan 2007 13:11:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Qrp-0000xH-B4 for 16ng@ietf.org; Fri, 12 Jan 2007 13:11:05 -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 1H5Qrm-0002j6-R9 for 16ng@ietf.org; Fri, 12 Jan 2007 13:11:05 -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 l0CI96Ju022257; Fri, 12 Jan 2007 20:09:32 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 20:10:29 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 12:10:27 -0600 Received: from 172.19.244.117 ([172.19.244.117]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jan 2007 18:10:27 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 12 Jan 2007 12:12:06 -0600 Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] Thread-Index: Acc2dSrFaX+8dKJoEduv0AARJNUNiA== In-Reply-To: <45A7CAEB.5080906@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 18:10:27.0640 (UTC) FILETIME=[F024D380:01C73674] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Alex, Let me just say that in the current realizations of 802.16, the secondary management connection is not used for either configuration or for sending RAs or sending router solicitations. Essentially the secondary management connection is not used at all. It is true that IEEE 802.16 defines the secondary management connection but is not mandatory that it be used. A transport connection that is established for IPv6 is used for RA/RS, DHCPv6 and everything else. -Raj On 1/12/07 11:52 AM, "ext Alexandru Petrescu" wrote: > Basavaraj Patil wrote: >> Alex, >> >> Inline: >> >> >> On 1/12/07 10:57 AM, "ext Alexandru Petrescu" >> wrote: >> >>> Hi, please allow me to interfere with clarifications. >>> >>> Basavaraj Patil wrote: >>>> Comments by Bruno Sousa: >>> [skip parts I agree] >>>>> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 >>>>> Transport Connection between an MS and a BS which is used to >>>>> transport user data, i.e IPv6 packets in this case. A >>>>> Transport Connection is represented by a CID (Connection >>>>> Identifier) and multiple Transport Connections can exist >>>>> between an MS and BS. " I think the first sentence is somehow >>>>> contradictory with the rest of the paragraph. It is possible to >>>>> have more then one transport connection between MS and BS. >>>>> These transport connections are defined on the MAC layer (L2), >>>>> so why refer "there exists an L2 Transport Connection?!" >>>>> >>>>> (If my thoughts are correct) I propose to change the first >>>>> sentence to: >>>>> >>>>> In 802.16, the Transport Connection between an MS and a BS is >>>>> used to transport user data, i.e. IPv6 packets in this case. >>>> Agreed. Incorporated the proposed sentence. >>> But there are IPv6 packets that are sent on the Secondary >>> Management Connection as well (RS/RA at least) 6.3.9.10 >>> 802.16e-2005. I suggest saying that only _some_ of the IPv6 >>> packets are transported on some Transport Connection, or along >>> these lines. >> >> The secondary management connection is typically not used for user >> data. As the .16 spec says it can be used for address configuration, >> TFTP etc. > > Not only that it can but it must, by that spec > >> Also to be noted is the fact that secondary management connections >> are not mandatorily required. The usage for which it has been defined >> can be accomplished via a regular transport connection. > > I don't think the 802.16 spec says anywhere that RS/RA could be sent on > anything else than Secondary Management Connection. Do you? > >>> From a practical standapoint, I do not see hosts or BS' >>> implementing or using the secondary management connection. So I can >>> mention it in the text of the I-D, but it would not be very >>> useful. >>> >> >>> Probably best for reader would be to enumerate the different types >>> of Connections the SS can handle and where do IPv6 packets appear. >>> What do you think? >> >> I don't think we should get into the details of the various types of >> connections in the I-D. The reference to the .16 spec is sufficient >> for that. But I can mention that there does exist the secondary >> management connection which may be used for host configuration with a >> caveat that for all practical purposes it is better to use a >> transport connection for the same. >> >> The reason why the secondary management connection does not make >> sense is because it is limited in its capability. Establishing a >> transport connection instead allows you to do the same host >> configuration as well as use it for user traffic. > > I am afraid the 802.16 spec clearly says RS/RA only happen on the > Secondary Management Connection and we can't suggest do it otherwise. > > Alex > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 13:13:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QuQ-0003dE-Ur; Fri, 12 Jan 2007 13:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QuP-0003d9-Nr for 16ng@ietf.org; Fri, 12 Jan 2007 13:13:45 -0500 Received: from web81905.mail.mud.yahoo.com ([68.142.207.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5QuN-00034Y-3t for 16ng@ietf.org; Fri, 12 Jan 2007 13:13:45 -0500 Received: (qmail 11109 invoked by uid 60001); 12 Jan 2007 18:13:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=nOh0l8VVoXcQKayGSfQPBzWo5otmpR/J85I890Ox0LRU+D5tYhW6UYyrgLBWbvcYih05QDKcET0awcY/oiIcab+8n6D1EFEupw5q1YNHkZO9kRJGD6ryE6KRiFI2plKq5szyro73W0PRX4uWxCKEX9l1CF8GjSO7mlVtyjjb5j4= ; Message-ID: <20070112181342.11107.qmail@web81905.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81905.mail.mud.yahoo.com via HTTP; Fri, 12 Jan 2007 10:13:42 PST Date: Fri, 12 Jan 2007 10:13:42 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] To: Alexandru Petrescu , Basavaraj Patil MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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="===============1965564011==" Errors-To: 16ng-bounces@ietf.org --===============1965564011== Content-Type: multipart/alternative; boundary="0-1096455467-1168625622=:436" --0-1096455467-1168625622=:436 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Alex,=0A=0ADJ Jonhston already clarified this in his email on Dec. 20. Extr= acting from=0Athat message:=0A=0A"However the establishment of IP connectiv= ity described in the network=0Aentry in 802.16 has nothing to do with the I= P connectivity we are=0Adealing with in 16ng."=0A=0A-gabriel=0A=0A----- Ori= ginal Message ----=0AFrom: Alexandru Petrescu =0ATo: Basavaraj Patil =0ACc: 16ng@ietf.org= =0ASent: Friday, January 12, 2007 9:52:43 AM=0ASubject: Re: [16NG] Resoluti= ons to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6c= s-04 [2]=0A=0ABasavaraj Patil wrote:=0A> Alex,=0A> =0A> Inline:=0A> =0A> = =0A> On 1/12/07 10:57 AM, "ext Alexandru Petrescu" =0A> wrote:=0A> =0A>> Hi, please allow me to interfere with clari= fications.=0A>> =0A>> Basavaraj Patil wrote:=0A>>> Comments by Bruno Sousa:= =0A>> [skip parts I agree]=0A>>>> 4) IPv6 link in 802.16 " In 802.16, there= exists an L2 =0A>>>> Transport Connection between an MS and a BS which is = used to =0A>>>> transport user data, i.e IPv6 packets in this case. A =0A>= >>> Transport Connection is represented by a CID (Connection =0A>>>> Identi= fier) and multiple Transport Connections can exist =0A>>>> between an MS an= d BS. " I think the first sentence is somehow =0A>>>> contradictory with th= e rest of the paragraph. It is possible to=0A>>>> have more then one trans= port connection between MS and BS. =0A>>>> These transport connections are = defined on the MAC layer (L2), =0A>>>> so why refer "there exists an L2 Tra= nsport Connection?!"=0A>>>> =0A>>>> (If my thoughts are correct) I propose = to change the first =0A>>>> sentence to:=0A>>>> =0A>>>> In 802.16, the Tran= sport Connection between an MS and a BS is =0A>>>> used to transport user d= ata, i.e. IPv6 packets in this case.=0A>>> Agreed. Incorporated the propose= d sentence.=0A>> But there are IPv6 packets that are sent on the Secondary = =0A>> Management Connection as well (RS/RA at least) 6.3.9.10 =0A>> 802.16e= -2005. I suggest saying that only _some_ of the IPv6 =0A>> packets are tra= nsported on some Transport Connection, or along =0A>> these lines.=0A> =0A>= The secondary management connection is typically not used for user =0A> da= ta. As the .16 spec says it can be used for address configuration, =0A> TFT= P etc.=0A=0ANot only that it can but it must, by that spec.=0A=0A> Also to = be noted is the fact that secondary management connections =0A> are not man= datorily required. The usage for which it has been defined=0A> can be acco= mplished via a regular transport connection.=0A=0AI don't think the 802.16 = spec says anywhere that RS/RA could be sent on=0Aanything else than Seconda= ry Management Connection. Do you?=0A=0A>> From a practical standapoint, I = do not see hosts or BS' =0A>> implementing or using the secondary managemen= t connection. So I can=0A>> mention it in the text of the I-D, but it woul= d not be very=0A>> useful.=0A>> =0A> =0A>> Probably best for reader would b= e to enumerate the different types =0A>> of Connections the SS can handle a= nd where do IPv6 packets appear. =0A>> What do you think?=0A> =0A> I don't = think we should get into the details of the various types of=0A> connectio= ns in the I-D. The reference to the .16 spec is sufficient=0A> for that. B= ut I can mention that there does exist the secondary =0A> management connec= tion which may be used for host configuration with a=0A> caveat that for a= ll practical purposes it is better to use a =0A> transport connection for t= he same.=0A> =0A> The reason why the secondary management connection does n= ot make =0A> sense is because it is limited in its capability. Establishing= a =0A> transport connection instead allows you to do the same host =0A> co= nfiguration as well as use it for user traffic.=0A=0AI am afraid the 802.16= spec clearly says RS/RA only happen on the=0ASecondary Management Connecti= on and we can't suggest do it otherwise.=0A=0AAlex=0A=0A=0A________________= _______________________________=0A16NG mailing list=0A16NG@ietf.org=0Ahttps= ://www1.ietf.org/mailman/listinfo/16ng=0A=0A=0A=0A=0A --0-1096455467-1168625622=:436 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Alex,

DJ Jonhston already clarified this in hi= s email on Dec. 20. Extracting from
that message:

"However the es= tablishment of IP connectivity described in the network
entry in 802.16 = has nothing to do with the IP connectivity we are
dealing with in 16ng."=

-gabriel

----- Original Message ----
From: Alexan= dru Petrescu <alexandru.petrescu@motorola.com>
To: Basavaraj Patil= <basavaraj.patil@nokia.com>
Cc: 16ng@ietf.org
Sent: Friday, Ja= nuary 12, 2007 9:52:43 AM
Subject: Re: [16NG] Resolutions to issues rais= ed during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2]

Basavaraj Patil wrote:
> Alex,
>
> Inline:
>
>
> On= 1/12/07 10:57 AM, "ext Alexandru Petrescu"
> <alexandru.petrescu= @motorola.com> wrote:
>
>> Hi, please allow me to interf= ere with clarifications.
>>
>> Basavaraj Patil wrote:>>> Comments by Bruno Sousa:
>> [skip parts I agree]
= >>>> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 >>>> Transport Connection between an MS and a BS which is used= to
>>>> transport user data, i.e IPv6 packets in this case= .  A
>>>> Transport Connection is represented by = a CID (Connection
>>>> Identifier) and multiple Transport C= onnections can exist
>>>> between an MS and BS. " I think t= he first sentence is somehow
>>>> contradictory with the re= st of the paragraph. It is possible to
>>>>  have = more then one transport connection between MS and BS.
>>>> These transpo= rt connections are defined on the MAC layer (L2),
>>>> so w= hy refer "there exists an L2 Transport Connection?!"
>>>> >>>> (If my thoughts are correct) I propose to change the fir= st
>>>> sentence to:
>>>>
>>>&g= t; In 802.16, the Transport Connection between an MS and a BS is
>&g= t;>> used to transport user data, i.e. IPv6 packets in this case.
= >>> Agreed. Incorporated the proposed sentence.
>> But th= ere are IPv6 packets that are sent on the Secondary
>> Management= Connection as well (RS/RA at least) 6.3.9.10
>> 802.16e-2005.&nb= sp; I suggest saying that only _some_ of the IPv6
>> packets= are transported on some Transport Connection, or along
>> these = lines.
>
> The secondary management connection is typically no= t used for user
> data. As the .16 spec says it can be used for address config= uration,
> TFTP etc.

Not only that it can but it must, by tha= t spec.

> Also to be noted is the fact that secondary management = connections
> are not mandatorily required. The usage for which it h= as been defined
>  can be accomplished via a regular transp= ort connection.

I don't think the 802.16 spec says anywhere that RS/= RA could be sent on
anything else than Secondary Management Connection.&= nbsp; Do you?

>> From a practical standapoint, I do not s= ee hosts or BS'
>> implementing or using the secondary management= connection. So I can
>>  mention it in the text of the = I-D, but it would not be very
>> useful.
>>
>
= >> Probably best for reader would be to enumerate the different types=
>> of Connections the SS can handle and where do IPv6 packets ap= pear.
>> What do you think?
>
> I don't think we should g= et into the details of the various types of
>  connections = in the I-D. The reference to the .16 spec is sufficient
>  = for that. But I can mention that there does exist the secondary
> ma= nagement connection which may be used for host configuration with a
>=   caveat that for all practical purposes it is better to use a > transport connection for the same.
>
> The reason why t= he secondary management connection does not make
> sense is because = it is limited in its capability. Establishing a
> transport connecti= on instead allows you to do the same host
> configuration as well as= use it for user traffic.

I am afraid the 802.16 spec clearly says R= S/RA only happen on the
Secondary Management Connection and we can't sug= gest do it otherwise.

Alex


________________________________________= _______
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mail= man/listinfo/16ng

--0-1096455467-1168625622=:436-- --===============1965564011== 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 --===============1965564011==-- From 16ng-bounces@ietf.org Fri Jan 12 13:17:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QyQ-0005CU-IB; Fri, 12 Jan 2007 13:17:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QyP-0005A2-6J for 16ng@ietf.org; Fri, 12 Jan 2007 13:17:53 -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 1H5QyN-0003bN-N7 for 16ng@ietf.org; Fri, 12 Jan 2007 13:17:53 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0CIFiaD023048; Fri, 12 Jan 2007 20:16:19 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 20:17:44 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 12:17:41 -0600 Received: from 172.19.244.117 ([172.19.244.117]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jan 2007 18:17:41 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 12 Jan 2007 12:19:20 -0600 Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] Thread-Index: Acc2di10bBeKP6JpEduv0AARJNUNiA== In-Reply-To: <45A7CE49.7080003@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 18:17:41.0770 (UTC) FILETIME=[F2E7CEA0:01C73675] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112201620-58669BB0-6309124F/1378628085-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Alex, On 1/12/07 12:07 PM, "ext Alexandru Petrescu" wrote: > Basavaraj Patil wrote: >> Hi Alex, >> >> On 1/12/07 5:06 AM, "ext Alexandru Petrescu" >> wrote: >> >>> Periodic RA is in widespread use for movement detection. I do not >>> understand the opposition to use periodic RAs as allowed by >>> rfc3775. What breaks if we use periodic RAs with a frequency higher >>> than 1/4s? (remark arguments of air interface gains are different >>> on high-bandwidth links). >> >> The fact is that sending periodic RAs on an air interface >> irrespective of BW capacity is suboptimal. A host in Idle mode is not >> listening for periodic RAs. Listening for periodic RAs would prevent >> the host from transitioning to idle mode which has an adverse impact >> on battery life. 802.16 has defined paging and Idle mode support. In >> air-interfaces that do not support such capability, sending of very >> frequent RAs is possible but IMO still not the most efficient usage >> of the bandwidth. In licensed spectrum the optimization and >> efficiency of the air interface is critical. Periodic RAs are >> unavoidable at this time. The best that we can do without breaking >> backward compatibility is to send it with large time intervals as the >> I-D suggests. Movement detection can be done be accomplished by >> other means. If the host is only relying on RAs for movement >> detection (at the IP layer), then it could just as well send a Rtr >> solicitation. This is not prevented. >> >> In Unlicensed spectrum you may have a bit more liberty about how the >> air-interface is used but even in those cases, optimizing it is a >> better choice. > > Raj, I understand a strong pushback from you about having periodic RAs > with less than 4s. I think it's not motivated. > > Let's then discuss the RS method for quick movement detection. > > Do you agree that (1) an SS can't multicast an RS because 802.16e IPv6CS > doesn't support ul multicast? and that (2) there's no means for SS to > unicast the RS because it doesn't know the BS's link-local address > because no message in the network entry procedure delivers BS's > link-local address? Why do you need UL multicast capability in order to send the RS? Once the IPv6 link has been established between the MS and the AR (a PtP link BTW in the context of this I-D), the MS can send an RS to the all-routers multicast address. I don't see any problem with the MS sending an RS at all once the IPv6 link is up (implying a PtP connection between the MS and AR). -Raj > > What do you think? > > Alex > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 13:38:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RHw-0002SM-PB; Fri, 12 Jan 2007 13:38:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RHv-0002S8-DK for 16ng@ietf.org; Fri, 12 Jan 2007 13:38:03 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5RHu-0006mt-6P for 16ng@ietf.org; Fri, 12 Jan 2007 13:38:03 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1168627079!8455660!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 5186 invoked from network); 12 Jan 2007 18:37:59 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 12 Jan 2007 18:37:59 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0CIbxpE027246; Fri, 12 Jan 2007 11:37:59 -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 l0CIbwa2018575; Fri, 12 Jan 2007 12:37:58 -0600 (CST) Message-ID: <45A7D585.5040603@motorola.com> Date: Fri, 12 Jan 2007 19:37:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gabriel montenegro Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] References: <20070112181342.11107.qmail@web81905.mail.mud.yahoo.com> In-Reply-To: <20070112181342.11107.qmail@web81905.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 gabriel montenegro wrote: > Alex, > > DJ Jonhston already clarified this in his email on Dec. 20. > Extracting from that message: > > "However the establishment of IP connectivity described in the > network entry in 802.16 has nothing to do with the IP connectivity we > are dealing with in 16ng." That is indeed a strong statement about the extent of differences between the 802.16 network entry procedure and the IP connectivity we (who's we) dealing with in 16ng. But I wouldn't see any clearer by that statement. If there were an amendment to the 802.16 spec saying that the SMC (2ry mgmt connect'n) is discarded and that IPv6 RS/RA happens on a transport connection then yes, it would have been a clarification. Actually, I don't know to what extent can _any_ statement made in this draft (IPv6-overIPv6CS), of which this RS/RA transport connection is but one, can over-ride the 802.16 statements. I personally thought the draft can only suggest things to the 802.16 document, not plain over-riding. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 13:46:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RPc-0007WF-TR; Fri, 12 Jan 2007 13:46:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5RPb-0007VP-CX for 16ng@ietf.org; Fri, 12 Jan 2007 13:45:59 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5RPZ-0000Zx-13 for 16ng@ietf.org; Fri, 12 Jan 2007 13:45:59 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1168627555!10183035!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12854 invoked from network); 12 Jan 2007 18:45:55 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 12 Jan 2007 18:45:55 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0CIjsjH001763; Fri, 12 Jan 2007 11:45:54 -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 l0CIjsYa026348; Fri, 12 Jan 2007 12:45:54 -0600 (CST) Message-ID: <45A7D761.9000705@motorola.com> Date: Fri, 12 Jan 2007 19:45:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: David Johnston Subject: Re: [16NG] Network entry procedure for IPv6 over IP CS 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: 082a9cbf4d599f360ac7f815372a6a15 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 David Johnston wrote: > Alex, > > I've just gone back and taken a look at this.. I think this > discussion is based on a huge, but easily made misconception. David, sorry for this very late reply. I just saw this email, pointed to by WG Chairs. > 802.16 has management connections and transport connection. MPDUs on > management connections contain management messages defined by > 802.16, upper layers never see them. Transport connections carry > MSDUs to and from upper layers. These are what upper layers see. > > The last 2 items on the network entry list.. "set up provisioned > connections, operational" refer to the setting up of the transport > connections that will carry IP. > > So what is 3) establish IP connectivity? How can it be before the > setting up of transport connections that carry IP? > > The answer is in 6.3.9.10.. "Establishment of IP connectivity shall > be performed on the SS's Secondary Management Connection". > > The reality is that there is a thing called a secondary management > connection (SMC) that may, but doesn't have to be, established on > network entry. > > Unlike the Primary, Basic, Ranging and other management connections, > the SMC doesn't carry well defined MAC management messages. It is > bolted to an IP stack. Not the one you are thinking of, but a > parallel IP service dedicated to managing subscriber stations. The > things that are defined that can happen over the SMC are DHCP, > 'establish time of day' as per RFC 868 (see 6.3.9.11) , 'transfer > operational parameters' using TFTP to get a file containing those > parameters, SNMP and anything else the makers of the box chooses. The > contents of the configuration file are defined in clause 9 of > 802.16. > > > 6.3.1.1 says "Bearer or data services shall never be transferred on > the Basic, Primary, or Secondary Management connections." > > The SMC is a little controversial, and I don't think it should be in > the spec, but the majority of 802.16 disagree with me (or did when I > tried to kill it). So what is the documented conclusion of that IEEE discussion? > However the establishment of IP connectivity described in the network > entry in 802.16 has nothing to do with the IP connectivity we are > dealing with in 16ng. DO you mean the IPv6-over-IPv6CS (or over ETHCS) documents could completely override the 802.16 network entry procedure? The 802.16 network-entry procedure is a sequence of several steps, only about a 3rd of them are IP. Starting what step can IPv6-over-CS IETF document can override? Is it right after Reg-Rsp? Or right after SBC-RSP (So do authentication with EAP or PANA instead)? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 14:48:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SNO-0006fw-Kf; Fri, 12 Jan 2007 14:47:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SNN-0006fq-Je for 16ng@ietf.org; Fri, 12 Jan 2007 14:47:45 -0500 Received: from web81907.mail.mud.yahoo.com ([68.142.207.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5SNM-0008F8-1h for 16ng@ietf.org; Fri, 12 Jan 2007 14:47:45 -0500 Received: (qmail 56292 invoked by uid 60001); 12 Jan 2007 19:47:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=EtULWaFvjTTcYBr6ecNoy2MjPtx//cphguAJb7R7TGYxUkkZNUlPoYxomiJ7TPa1K3zU1v9N9WvecM5RRfE7OEXS1RX5VCkqB8F+CWBhfyQhjK6zl9+Zoe8N1CCQxym3TbF3zaUnJ+FuYPLT/Hg4bgvkRQNCHDy1Br3Lk46jVKc= ; Message-ID: <20070112194736.56290.qmail@web81907.mail.mud.yahoo.com> Received: from [131.107.0.71] by web81907.mail.mud.yahoo.com via HTTP; Fri, 12 Jan 2007 11:47:36 PST Date: Fri, 12 Jan 2007 11:47:36 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] Network entry procedure for IPv6 over IP CS To: Alexandru Petrescu , David Johnston MIME-Version: 1.0 X-Spam-Score: 1.4 (+) 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: , Content-Type: multipart/mixed; boundary="===============0753336166==" Errors-To: 16ng-bounces@ietf.org --===============0753336166== Content-Type: multipart/alternative; boundary="0-358131304-1168631256=:55898" --0-358131304-1168631256=:55898 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Alex,=0A=0ASection 6.3.9 of 802.16-2004 referred to by DJ has the answer, d= id you look at it?=0AOne of the steps in the network entry procedure is est= ablishing IP connectivity.=0AThis is step "g" and that section clearly stat= es: =0A=0A "Implementation of phases=0A g), h) and i) at the SS is opti= onal."=0A=0A-gabriel=0A=0A----- Original Message ----=0AFrom: Alexandru Pet= rescu =0ATo: David Johnston =0ACc: 16ng@ietf.org=0ASent: Friday, January 12, 2007 10:45:53 AM= =0ASubject: Re: [16NG] Network entry procedure for IPv6 over IP CS=0A=0ADav= id Johnston wrote:=0A> Alex,=0A> =0A> I've just gone back and taken a look = at this.. I think this =0A> discussion is based on a huge, but easily made = misconception.=0A=0ADavid, sorry for this very late reply. I just saw this= email, pointed=0Ato by WG Chairs.=0A=0A> 802.16 has management connections= and transport connection. MPDUs on=0A> management connections contain man= agement messages defined by=0A> 802.16, upper layers never see them. Transp= ort connections carry=0A> MSDUs to and from upper layers. These are what up= per layers see.=0A> =0A> The last 2 items on the network entry list.. "set = up provisioned =0A> connections, operational" refer to the setting up of th= e transport =0A> connections that will carry IP.=0A> =0A> So what is 3) est= ablish IP connectivity? How can it be before the =0A> setting up of transpo= rt connections that carry IP?=0A> =0A> The answer is in 6.3.9.10.. "Establi= shment of IP connectivity shall =0A> be performed on the SS's Secondary Man= agement Connection".=0A> =0A> The reality is that there is a thing called a= secondary management =0A> connection (SMC) that may, but doesn't have to b= e, established on =0A> network entry.=0A> =0A> Unlike the Primary, Basic, R= anging and other management connections, =0A> the SMC doesn't carry well de= fined MAC management messages. It is =0A> bolted to an IP stack. Not the on= e you are thinking of, but a =0A> parallel IP service dedicated to managing= subscriber stations. The =0A> things that are defined that can happen over= the SMC are DHCP, =0A> 'establish time of day' as per RFC 868 (see 6.3.9.1= 1) , 'transfer =0A> operational parameters' using TFTP to get a file contai= ning those =0A> parameters, SNMP and anything else the makers of the box ch= ooses. The=0A> contents of the configuration file are defined in clause 9 = of=0A> 802.16.=0A> =0A> =0A> 6.3.1.1 says "Bearer or data services shall ne= ver be transferred on =0A> the Basic, Primary, or Secondary Management conn= ections."=0A> =0A> The SMC is a little controversial, and I don't think it = should be in =0A> the spec, but the majority of 802.16 disagree with me (or= did when I =0A> tried to kill it).=0A=0ASo what is the documented conclusi= on of that IEEE discussion?=0A=0A> However the establishment of IP connecti= vity described in the network=0A> entry in 802.16 has nothing to do with t= he IP connectivity we are =0A> dealing with in 16ng.=0A=0ADO you mean the I= Pv6-over-IPv6CS (or over ETHCS) documents could=0Acompletely override the 8= 02.16 network entry procedure?=0A=0AThe 802.16 network-entry procedure is a= sequence of several steps, only=0Aabout a 3rd of them are IP. Starting wh= at step can IPv6-over-CS IETF=0Adocument can override? Is it right after R= eg-Rsp? Or right after=0ASBC-RSP (So do authentication with EAP or PANA in= stead)?=0A=0AAlex=0A=0A_______________________________________________=0A16= NG mailing list=0A16NG@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/16= ng=0A=0A=0A=0A=0A --0-358131304-1168631256=:55898 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Alex,

Section 6.3.9 of 802.16-2004 referred to= by DJ has the answer, did you look at it?
One of the steps in the netwo= rk entry procedure is establishing IP connectivity.
This is step "g" and= that section clearly states:

   "Implementation of phase= s
   g), h) and i) at the SS is optional."

-gabriel
=
----- Original Message ----
From: Alexandru Petrescu <ale= xandru.petrescu@motorola.com>
To: David Johnston <Djohnston@nextwa= ve.com>
Cc: 16ng@ietf.org
Sent: Friday, January 12, 2007 10:45:53 = AM
Subject: Re: [16NG] Network entry procedure for IPv6 over IP CS
David Johnston wrote:
> Alex,
>
> I've just gone back and taken a look= at this.. I think this
> discussion is based on a huge, but easily = made misconception.

David, sorry for this very late reply. &nbs= p;I just saw this email, pointed
to by WG Chairs.

> 802.16 has= management connections and transport connection. MPDUs on
> &nb= sp;management connections contain management messages defined by
> 80= 2.16, upper layers never see them. Transport connections carry
> MSDU= s to and from upper layers. These are what upper layers see.
>
&g= t; The last 2 items on the network entry list.. "set up provisioned
>= ; connections, operational" refer to the setting up of the transport
&g= t; connections that will carry IP.
>
> So what is 3) establish= IP connectivity? How can it be before the
> setting up of transport= connections that carry IP?
>
> The answer is in 6.3.9.10.. "E= stablishment of IP connectivity shall
> be performed on the SS's Secondary Manag= ement Connection".
>
> The reality is that there is a thing ca= lled a secondary management
> connection (SMC) that may, but doesn't= have to be, established on
> network entry.
>
> Unlike= the Primary, Basic, Ranging and other management connections,
> the= SMC doesn't carry well defined MAC management messages. It is
> bol= ted to an IP stack. Not the one you are thinking of, but a
> paralle= l IP service dedicated to managing subscriber stations. The
> things= that are defined that can happen over the SMC are DHCP,
> 'establis= h time of day' as per RFC 868 (see 6.3.9.11) , 'transfer
> operation= al parameters' using TFTP to get a file containing those
> parameter= s, SNMP and anything else the makers of the box chooses. The
> &= nbsp;contents of the configuration file are defined in clause 9 of
> 802.16.
>
>
> 6.3.1.1 says "Bearer or data services sh= all never be transferred on
> the Basic, Primary, or Secondary Manag= ement connections."
>
> The SMC is a little controversial, and= I don't think it should be in
> the spec, but the majority of 802.1= 6 disagree with me (or did when I
> tried to kill it).

So wha= t is the documented conclusion of that IEEE discussion?

> However= the establishment of IP connectivity described in the network
> = ; entry in 802.16 has nothing to do with the IP connectivity we are > dealing with in 16ng.

DO you mean the IPv6-over-IPv6CS (or ov= er ETHCS) documents could
completely override the 802.16 network entry p= rocedure?

The 802.16 network-entry procedure is a sequence of severa= l steps, only
about a 3rd of them are IP.  Starting what step = can IPv6-over-CS IETF
document can override?  Is it right afte= r Reg-Rsp?  Or right after
SBC-RSP (So do authentication with E= AP or PANA instead)?

Alex

___________________________________= ____________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/= mailman/listinfo/16ng

--0-358131304-1168631256=:55898-- --===============0753336166== 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 --===============0753336166==-- From 16ng-bounces@ietf.org Fri Jan 12 15:01:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SaB-0007ET-KH; Fri, 12 Jan 2007 15:00:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Sa9-0007EO-G4 for 16ng@ietf.org; Fri, 12 Jan 2007 15:00:57 -0500 Received: from web81907.mail.mud.yahoo.com ([68.142.207.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5Sa6-0002Yu-Ud for 16ng@ietf.org; Fri, 12 Jan 2007 15:00:57 -0500 Received: (qmail 61804 invoked by uid 60001); 12 Jan 2007 20:00:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Y7YVz0kaOAw41cD7DhxmtmyA5nhiR4aul0B7xcn46BlnjFrOh3JFDfLCLjI3pbTyg8wemX2SP3N/Pj7oAlu5tC4WciLXCwiQmy113xIgXqIOdDtWGh3d1vOouhrzqkKHfmQTkgfS7ol/9z1VoW48n6nf4EyMSCF5udrOs69g5s4= ; Message-ID: <20070112200054.61802.qmail@web81907.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81907.mail.mud.yahoo.com via HTTP; Fri, 12 Jan 2007 12:00:54 PST Date: Fri, 12 Jan 2007 12:00:54 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] To: Alexandru Petrescu , Basavaraj Patil MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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="===============0465700099==" Errors-To: 16ng-bounces@ietf.org --===============0465700099== Content-Type: multipart/alternative; boundary="0-98615718-1168632054=:60678" --0-98615718-1168632054=:60678 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Alex,=0A=0AJust looking at this statement of yours below:=0A=0A"Do you agre= e that (1) an SS can't multicast an RS because 802.16e IPv6CS=0Adoesn't sup= port ul multicast?"=0A=0AFor this issue of multicast support, I refer you a= gain =0Ato clarification by our 802.16 liaison, e.g.,=0A=0Ahttp://eeca16.so= gang.ac.kr/pipermail/16ng/Week-of-Mon-20061106/000392.html=0Ahttp://eeca16.= sogang.ac.kr/pipermail/16ng/Week-of-Mon-20061106/000394.html=0A=0A-gabriel= =0A=0A----- Original Message ----=0AFrom: Alexandru Petrescu =0ATo: Basavaraj Patil =0ACc:= 16ng@ietf.org=0ASent: Friday, January 12, 2007 10:07:05 AM=0ASubject: Re: = [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-= ipv6-over-ipv6cs-04 [1]=0A=0ABasavaraj Patil wrote:=0A> Hi Alex,=0A> =0A> O= n 1/12/07 5:06 AM, "ext Alexandru Petrescu" =0A> wrote:=0A> =0A>> Periodic RA is in widespread use for movement dete= ction. I do not=0A>> understand the opposition to use periodic RAs as all= owed by =0A>> rfc3775. What breaks if we use periodic RAs with a frequency = higher=0A>> than 1/4s? (remark arguments of air interface gains are differ= ent =0A>> on high-bandwidth links).=0A> =0A> The fact is that sending perio= dic RAs on an air interface =0A> irrespective of BW capacity is suboptimal.= A host in Idle mode is not=0A> listening for periodic RAs. Listening for = periodic RAs would prevent=0A> the host from transitioning to idle mode wh= ich has an adverse impact=0A> on battery life. 802.16 has defined paging a= nd Idle mode support. In=0A> air-interfaces that do not support such capab= ility, sending of very =0A> frequent RAs is possible but IMO still not the = most efficient usage =0A> of the bandwidth. In licensed spectrum the optimi= zation and =0A> efficiency of the air interface is critical. Periodic RAs a= re =0A> unavoidable at this time. The best that we can do without breaking = =0A> backward compatibility is to send it with large time intervals as the= =0A> I-D suggests. Movement detection can be done be accomplished by=0A> o= ther means. If the host is only relying on RAs for movement=0A> detection (= at the IP layer), then it could just as well send a Rtr=0A> solicitation. T= his is not prevented.=0A> =0A> In Unlicensed spectrum you may have a bit mo= re liberty about how the=0A> air-interface is used but even in those cases= , optimizing it is a =0A> better choice.=0A=0ARaj, I understand a strong pu= shback from you about having periodic RAs=0Awith less than 4s. I think it'= s not motivated.=0A=0ALet's then discuss the RS method for quick movement d= etection.=0A=0ADo you agree that (1) an SS can't multicast an RS because 80= 2.16e IPv6CS=0Adoesn't support ul multicast? and that (2) there's no means= for SS to=0Aunicast the RS because it doesn't know the BS's link-local add= ress=0Abecause no message in the network entry procedure delivers BS's=0Ali= nk-local address?=0A=0AWhat do you think?=0A=0AAlex=0A=0A=0A_______________= ________________________________=0A16NG mailing list=0A16NG@ietf.org=0Ahttp= s://www1.ietf.org/mailman/listinfo/16ng=0A=0A=0A=0A=0A --0-98615718-1168632054=:60678 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Alex,

Just looking at this statement of yours = below:

"Do you agree that (1) an SS can't multicast an RS because 80= 2.16e IPv6CS
doesn't support ul multicast?"

For this issue of mul= ticast support, I refer you again
to clarification by our 802.16 liaiso= n, e.g.,

http://eeca16.sogang.ac= .kr/pipermail/16ng/Week-of-Mon-20061106/000392.html
http://eeca16.sogang.ac.kr/pipermail/16ng/Week-o= f-Mon-20061106/000394.html

-gabriel

----- Original Message ----<= br>From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
To: = Basavaraj Patil <basavaraj.patil@nokia.com>
Cc: 16ng@ietf.org
S= ent: Friday, January 12, 2007 10:07:05 AM
Subject: Re: [16NG] Resolution= s to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-= 04 [1]

Basavaraj Patil wrote:
> Hi Alex,
>
>= On 1/12/07 5:06 AM, "ext Alexandru Petrescu"
> <alexandru.petres= cu@motorola.com> wrote:
>
>> Periodic RA is in widesprea= d use for movement detection.  I do not
>>  un= derstand the opposition to use periodic RAs as allowed by
>> rfc3= 775. What breaks if we use periodic RAs with a frequency higher
>>=   than 1/4s? (remark arguments of air interface gains are differe= nt
>> on high-bandwidth links).
>
> The fact is that= sending periodic RAs on an air interface
> irrespective of BW capacity is s= uboptimal. A host in Idle mode is not
>  listening for peri= odic RAs. Listening for periodic RAs would prevent
>  the h= ost from transitioning to idle mode which has an adverse impact
>&nbs= p; on battery life. 802.16 has defined paging and Idle mode support. I= n
>  air-interfaces that do not support such capability, se= nding of very
> frequent RAs is possible but IMO still not the most = efficient usage
> of the bandwidth. In licensed spectrum the optimiz= ation and
> efficiency of the air interface is critical. Periodic RA= s are
> unavoidable at this time. The best that we can do without br= eaking
> backward compatibility is to send it with large time interv= als as the
>  I-D suggests. Movement detection can be done = be accomplished by
> other means. If the host is only relying on RAs = for movement
> detection (at the IP layer), then it could just as well s= end a Rtr
> solicitation. This is not prevented.
>
> In = Unlicensed spectrum you may have a bit more liberty about how the
>&n= bsp; air-interface is used but even in those cases, optimizing it is a=
> better choice.

Raj, I understand a strong pushback from yo= u about having periodic RAs
with less than 4s.  I think it's n= ot motivated.

Let's then discuss the RS method for quick movement de= tection.

Do you agree that (1) an SS can't multicast an RS because 8= 02.16e IPv6CS
doesn't support ul multicast?  and that (2) ther= e's no means for SS to
unicast the RS because it doesn't know the BS's l= ink-local address
because no message in the network entry procedure deli= vers BS's
link-local address?

What do you think?

Alex
<= br>
_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng

--0-98615718-1168632054=:60678-- --===============0465700099== 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 --===============0465700099==-- From 16ng-bounces@ietf.org Fri Jan 12 15:16:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Sp1-00071Q-JT; Fri, 12 Jan 2007 15:16:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Sp0-00071I-9s for 16ng@ietf.org; Fri, 12 Jan 2007 15:16:18 -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 1H5Sox-0006Av-Qq for 16ng@ietf.org; Fri, 12 Jan 2007 15:16:18 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0CKE3Bc029062; Fri, 12 Jan 2007 22:14:16 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 22:16:13 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 14:16:07 -0600 Received: from 172.19.244.117 ([172.19.244.117]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jan 2007 20:16:03 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Fri, 12 Jan 2007 14:17:43 -0600 Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] Thread-Index: Acc2hrcs9Z1tBqJ5Eduv0AARJNUNiA== In-Reply-To: <45A7DE9B.4090809@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Jan 2007 20:16:07.0910 (UTC) FILETIME=[7E7EB860:01C73686] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070112221416-71565BB0-72C62337/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Alex, Inline: On 1/12/07 1:16 PM, "ext Alexandru Petrescu" wrote: > Basavaraj Patil wrote: >> Alex, >> >> >> On 1/12/07 12:07 PM, "ext Alexandru Petrescu" >> wrote: >> >>> Basavaraj Patil wrote: >>>> Hi Alex, >>>> >>>> On 1/12/07 5:06 AM, "ext Alexandru Petrescu" >>>> wrote: >>> Let's then discuss the RS method for quick movement detection. >>> >>> Do you agree that (1) an SS can't multicast an RS because 802.16e >>> IPv6CS doesn't support ul multicast? and that (2) there's no means >>> for SS to unicast the RS because it doesn't know the BS's >>> link-local address because no message in the network entry >>> procedure delivers BS's link-local address? >> >> Why do you need UL multicast capability in order to send the RS? > > Because a multicasted RS is sent to a multicast address, and that is > uplink towards BS. When the MS sends the RS to the all-routers multicast address, the 802.16 sends this packet as it does any other IPv6 packet via the transport connection that has been established previously on the uplink. The host at the IPcv6 layer does not need to know the BS' link-local address or even its existence in this case. The RS that is carried via the transport connection is delivered to the BS which forwards it to the AR (via an L2 tunnel if required) and note that the BS does not even look at the IPv6 packet. It simply forwards the payload coming on a specific CID to an L2 tunnel which results in the RS now arriving at an AR. If you are thinking that the MAC in the host will convert the all-routers multicast destination address to a BS' link local address or any such thing, then you are mistaken. It does not work that way. > >> Once the IPv6 link has been established between the MS and the AR (a >> PtP link BTW in the context of this I-D), the MS can send an RS to >> the all-routers multicast address. > > The AR to be part of that all-routers multicast address it must have > joined that group (MUST in 2461 6.2.2). How does AR join a multicast > group at 802.16 MAC level? It does not join the multicast group at the .16 MAC level. > > Is it by sending an MLD report? An MCA-REQ/RSP telling all SSs? Is it > by configuring a implicit filtering rule in its database? Is it by not > joining that group at all and assuming that on that ptp link it will see > all peer's packets? On the PtP link it will see all the peers packets. > >> I don't see any problem with the MS sending an RS at all once the >> IPv6 link is up (implying a PtP connection between the MS and AR). > > Well, I've configured something similar: "multicast" RS/RA over tunnel > ptp interfaces. It works. Doesn't mean it's conforming or agreed. So you agree that it works. Good. -Raj > > Alex > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 16:20:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ton-0008Ub-BJ; Fri, 12 Jan 2007 16:20:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Tom-0008UV-Af for 16ng@ietf.org; Fri, 12 Jan 2007 16:20:08 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5Tok-0003nw-Bb for 16ng@ietf.org; Fri, 12 Jan 2007 16:20:07 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1168636802!12921580!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 6175 invoked from network); 12 Jan 2007 21:20:02 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-5.tower-128.messagelabs.com with SMTP; 12 Jan 2007 21:20:02 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l0CLK2Ql003576; Fri, 12 Jan 2007 14:20:02 -0700 (MST) Received: from [10.169.4.173] (mvp-10-169-4-173.corp.mot.com [10.169.4.173]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l0CLJxgl026708; Fri, 12 Jan 2007 15:20:00 -0600 (CST) Message-ID: <45A7FB7C.6070005@motorola.com> Date: Fri, 12 Jan 2007 22:19:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] 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: 3002fc2e661cd7f114cb6bae92fe88f1 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 Basavaraj Patil wrote: > Alex, > > Inline: > > > On 1/12/07 1:16 PM, "ext Alexandru Petrescu" > wrote: > >> Basavaraj Patil wrote: >>> Alex, >>> >>> >>> On 1/12/07 12:07 PM, "ext Alexandru Petrescu" >>> wrote: >>> >>>> Basavaraj Patil wrote: >>>>> Hi Alex, >>>>> >>>>> On 1/12/07 5:06 AM, "ext Alexandru Petrescu" >>>>> wrote: > >>>> Let's then discuss the RS method for quick movement detection. >>>> >>>> Do you agree that (1) an SS can't multicast an RS because >>>> 802.16e IPv6CS doesn't support ul multicast? and that (2) >>>> there's no means for SS to unicast the RS because it doesn't >>>> know the BS's link-local address because no message in the >>>> network entry procedure delivers BS's link-local address? >>> Why do you need UL multicast capability in order to send the RS? >> Because a multicasted RS is sent to a multicast address, and that >> is uplink towards BS. > > When the MS sends the RS to the all-routers multicast address, the > 802.16 sends this packet as it does any other IPv6 packet via the > transport connection that has been established previously on the > uplink. The host at the IPcv6 layer does not need to know the BS' > link-local address or even its existence in this case. The RS that is > carried via the transport connection is delivered to the BS which > forwards it to the AR (via an L2 tunnel if required) and note that > the BS does not even look at the IPv6 packet. It simply forwards the > payload coming on a specific CID to an L2 tunnel which results in the > RS now arriving at an AR. If you are thinking that the MAC in the > host will convert the all-routers multicast destination address to a > BS' link local address or any such thing, then you are mistaken. It > does not work that way. Yes, I'm thinking the IP-multicasted RS should be addressed to a link-layer multicast address. The 802.16MAC does have 48bit MAC addresses, so supposedly it has 48bit _multicast_ MAC addresses too. >>> Once the IPv6 link has been established between the MS and the AR >>> (a PtP link BTW in the context of this I-D), the MS can send an >>> RS to the all-routers multicast address. >> The AR to be part of that all-routers multicast address it must >> have joined that group (MUST in 2461 6.2.2). How does AR join a >> multicast group at 802.16 MAC level? > > It does not join the multicast group at the .16 MAC level. Well, this is against, or over-riding, 2461 6.2.2. That section says the router must join. >> Is it by sending an MLD report? An MCA-REQ/RSP telling all SSs? >> Is it by configuring a implicit filtering rule in its database? Is >> it by not joining that group at all and assuming that on that ptp >> link it will see all peer's packets? > > On the PtP link it will see all the peers packets. Yes. >>> I don't see any problem with the MS sending an RS at all once the >>> IPv6 link is up (implying a PtP connection between the MS and >>> AR). >> Well, I've configured something similar: "multicast" RS/RA over >> tunnel ptp interfaces. It works. Doesn't mean it's conforming or >> agreed. > > So you agree that it works. Good. Yes, I agree that it works and that it's not specified. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 12 16:34:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U2a-0001Zc-Ac; Fri, 12 Jan 2007 16:34:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5U2Z-0001Z3-23 for 16ng@ietf.org; Fri, 12 Jan 2007 16:34:23 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5U2X-0007GK-Q7 for 16ng@ietf.org; Fri, 12 Jan 2007 16:34:23 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1168637661!8469448!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14530 invoked from network); 12 Jan 2007 21:34:21 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 12 Jan 2007 21:34:21 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0CLYK26000584; Fri, 12 Jan 2007 14:34:20 -0700 (MST) Received: from [10.169.4.173] (mvp-10-169-4-173.corp.mot.com [10.169.4.173]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0CLYJOU013230; Fri, 12 Jan 2007 15:34:19 -0600 (CST) Message-ID: <45A7FEDA.8010907@motorola.com> Date: Fri, 12 Jan 2007 22:34:18 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gabriel montenegro Subject: Re: [16NG] Network entry procedure for IPv6 over IP CS References: <20070112194736.56290.qmail@web81907.mail.mud.yahoo.com> In-Reply-To: <20070112194736.56290.qmail@web81907.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: David Johnston , 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 gabriel montenegro wrote: > Alex, > > Section 6.3.9 of 802.16-2004 referred to by DJ has the answer, did > you look at it? One of the steps in the network entry procedure is > establishing IP connectivity. This is step "g" and that section > clearly states: > > "Implementation of phases g), h) and i) at the SS is optional." Yes, I've read that, they're optional, and they must be performed (so non optional) if the REG-REQ says it's a managed SS. At which point the IPv6-over-IPv6CS document should say that the REG-REQ MUST contain "0 - Unmanaged mode", no? It currently doesn't. And I think (not sure) that saying SS unmamanaged then many 802.16mac functionalities won't be available. 802.16-2004 6.3.9: > Implementation of phases g), h), and i) at the SS is optional. These > phases shall only be performed if the SS has indicated in the SS has > indicated in the REG-REQ message that it is a managed SS. Thanks, Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sat Jan 13 06:43:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5hIJ-0008Pt-Bo; Sat, 13 Jan 2007 06:43:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5hIG-0008Pd-UQ for 16ng@ietf.org; Sat, 13 Jan 2007 06:43:29 -0500 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5hID-0001mF-Bx for 16ng@ietf.org; Sat, 13 Jan 2007 06:43:28 -0500 Received: from [87.103.59.110] (110.59.103.87.rev.vodafone.pt [87.103.59.110]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l0DBh2jh023870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Jan 2007 11:43:07 GMT Message-ID: <45A8C5C2.5020005@dei.uc.pt> Date: Sat, 13 Jan 2007 11:42:58 +0000 From: Bruno Miguel Sousa User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Basavaraj Patil References: In-Reply-To: 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=-48.913, required 3, autolearn=not spam, ALL_TRUSTED -1.80, AWL 2.89, HTML_MESSAGE 0.00, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: bmsousa@dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.5 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f Cc: 16ng@ietf.org Subject: [16NG] Re: Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2] 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="===============1577788535==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============1577788535== Content-Type: multipart/alternative; boundary="------------000701040207060007040204" This is a multi-part message in MIME format. --------------000701040207060007040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Raj for taking into account my comments. Basavaraj Patil wrote: > Comments by Bruno Sousa: > > >> Here is my contribution to the draft-ietf-16ng-ipv6-over-ipv6cs-04, >> many of the issues I'm pointing come from the previous version of this >> draft. >> >> 1) Typos (besides the ones pointed by Junghoon Jee) >> - inclide (page 5) --> include >> - service specific or service-specific (page 5 and others) I think we >> should be coherent. >> - enacapsulated (page 7) --> encapsulated >> - specfic (page 7, section 4.1) --> specific >> - sucesful (page 10, section 6.2 and page 17 appendix C) --> >> successful >> > > Could not find this typo. > Strange, but better that way! > >> - succesfull (page 10, section 6.2) --> successful >> - Hader (page 11, section 6.3) --> Header >> >> > > Fixed the rest of the typos. > > >> 2) Terminology (section 3 and section 5). >> I'm questioning myself why only the definition of the ASN? >> For instance, important terms, used through out the memo are IPv6 link, >> L2 link. >> I think these ones should also be clarified from the beginning. >> > > The intent is to use common terminology and ASN is the only term that > is specific to this document. The rest of the terms are intended to be > included in the next rev of the 16NG PS I-D. The terminology proposed > for inclusion in the PS I-D is in the email: > http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html > Ok. I'm clarified! > >> I agree with the term ASN here, nevertheless it does not appear cited on >> the document, >> with the exception of the appendixes A and C. >> I think it is important to refer it on the section 5, >> the generic network architecture, when talking on the access network. >> > > If you were to look back to rev 2 of this I-D, you will see the WiMAX > specifics being a part of the normative part of the I-D. However based > on the WG objectives and the goal for this I-D, it was decided that > the draft would be applicable to a generic 802.16 network and not just > WiMAX. Hence the WiMAX specific parts are now in an appendix. Maybe I > could even move the term ASN to the appendix. > Adding WiMAX specific text in the main body of the I-D is not an > option. > I agree with you. It's better to have the draft applied to a generic .16 network, then a WiMAX network. Probably the idea to move the term ASN to the appendix is not a bad idea. Since it comes from WiMAX spec. > >> 3) IPv6 link (section 6) >> " A link is bounded by routers that decrement TTL." >> If we are talking about IPv6, shouldn't we refer Hop Limit instead of TTL?! >> >> > > Yes, I agree. Fixed it. > > >> 4) IPv6 link in 802.16 >> " >> In 802.16, there exists an L2 Transport Connection between an MS and >> a BS which is used to transport user data, i.e IPv6 packets in this >> case. A Transport Connection is represented by a CID (Connection >> Identifier) and multiple Transport Connections can exist between an >> MS and BS. >> " >> I think the first sentence is somehow contradictory with the rest of the >> paragraph. >> It is possible to have more then one transport connection between MS and BS. >> These transport connections are defined on the MAC layer (L2), >> so why refer "there exists an L2 Transport Connection?!" >> >> (If my thoughts are correct) I propose to change the first sentence to: >> >> In 802.16, the Transport Connection between an MS and a BS is used >> to transport user data, i.e. IPv6 packets in this case. >> > > Agreed. Incorporated the proposed sentence. > > >> 5) Maximum transmission unit in 802.16 (section 6.3) >> >> " >> The 802.16 MAC header is a 6 byte header followed by the payload and >> a 4 byte CRC which covers the whole PDU (Protocol Data Unit). The >> length of the PDU is indicated by the Len parameter in the Generic >> MAC HDR. >> " >> As reading, we may think that the payload and the CRC are always present >> on the MAC frames. >> They are not included in all messages. So I suggest to rewrite this, >> starting with: >> >> The 802.16 MAC PDU (Protocol Data Unit) is composed by >> a 6 byte header followed by an optional payload and >> an optional CRC covering the header and the payload. >> >> > > Okay... I changed the text in the I-D as proposed. > > >> This introduction has also the propose to clarify the covering of the >> CRC (header + payload) >> and not the whole PDU (since this one can include the CRC). >> >> >> 6) IPv6 prefix assignment (section 7) >> I suggest to add a reference to the RFC2461, to clarify where the >> on-link flag is defined: >> >> The prefixes are advertised with the on-link (L-bit) flag set as >> specified in RFC2461. >> > > Okay. Done. > > >> This section starts with: >> " >> Each MS can be considered to be on a separate subnet as a result of >> the point-to-point connection. >> " >> In the middle there is a sentence: >> " >> Each MS MUST be considered to be on a separate subnet as a result of >> the point-to-point connection. >> " >> Shouldn't here we have a consensus also? >> (probably this is an issue related with RFC2119) So can or MUST?! >> And the sentences aren't repeating themselves in the same section? >> >> > > Agree. Fixed it. > > >> 7) Appendix D >> This section introduces the SDU size proposed by the WiMAX forum. >> I just want to point that there is no a relation with the SDU and >> the IPv6 payload spoken along the document. >> Shouldn't this be clarified?! >> > > I dont think that is necessary. Within the main body of the text it is > clear what the MAX IPv6 payload size can be. And in the appendix, the > I-D is making a recomendation that the MAX MTU be 1400 bytes by > default but obviously can be anything between 1280 and 1500. > Ok. I agree with you. Kindly, Bruno Sousa --------------000701040207060007040204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Thanks Raj for taking into account my comments.

Basavaraj Patil wrote: 
Comments by Bruno Sousa:

  
Here is my contribution to the draft-ietf-16ng-ipv6-over-ipv6cs-04,
many of the issues I'm pointing come from the previous version of this
draft.

1) Typos (besides the ones pointed by Junghoon Jee)
- inclide (page 5) --> include
- service specific or service-specific (page 5 and others) I think we
should be coherent.
- enacapsulated (page 7) --> encapsulated
- specfic (page 7, section 4.1) --> specific
- sucesful (page 10, section 6.2 and page 17 appendix C) -->
successful
    

Could not find this typo.
Strange, but better that way!
  
- succesfull (page 10, section 6.2) --> successful
- Hader (page 11, section 6.3) --> Header

    

Fixed the rest of the typos.

  
2) Terminology (section 3 and section 5).
I'm questioning myself why only the definition of the ASN?
For instance, important terms, used through out the memo are IPv6 link,
L2 link.
I think these ones should also be clarified from the beginning.
    

The intent is to use common terminology and ASN is the only term that
is specific to this document. The rest of the terms are intended to be
included in the next rev of the 16NG PS I-D. The terminology proposed
for inclusion in the PS I-D is in the email:
http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html
Ok. I'm clarified!
  
I agree with the term ASN here, nevertheless it does not appear cited on
the document,
with the exception of the appendixes A and C.
I think it is important to refer it on the section 5,
the generic network architecture, when talking on the access network.
    

If you were to look back to rev 2 of this I-D, you will see the WiMAX
specifics being a part of the normative part of the I-D. However based
on the WG objectives and the goal for this I-D, it was decided that
the draft would be applicable to a generic 802.16 network and not just
WiMAX. Hence the WiMAX specific parts are now in an appendix. Maybe I
could even move the term ASN to the appendix.
Adding WiMAX specific text in the main body of the I-D is not an
option.
I agree with you. It's better to have the draft applied to a generic .16 network, then a WiMAX network.
Probably the idea to move the term ASN to the appendix is not a bad idea. Since it comes from WiMAX spec.
  
3) IPv6 link (section 6)
" A link is bounded by routers that decrement TTL."
If we are talking about IPv6, shouldn't we refer Hop Limit instead of TTL?!

    

Yes, I agree. Fixed it.

  
4) IPv6 link in 802.16
"
  In 802.16, there exists an L2 Transport Connection between an MS and
  a BS which is used to transport user data, i.e IPv6 packets in this
  case.  A Transport Connection is represented by a CID (Connection
  Identifier) and multiple Transport Connections can exist between an
  MS and BS.
"
I think the first sentence is somehow contradictory with the rest of the
paragraph.
It is possible to have more then one transport connection between MS and BS.
These transport connections are defined on the MAC layer (L2),
so why refer "there exists an L2 Transport Connection?!"

(If my thoughts are correct) I propose to change the first sentence to:

 In 802.16, the Transport Connection between an MS and a BS is used
 to transport user data, i.e. IPv6 packets in this case.
    

Agreed. Incorporated the proposed sentence.

  
5) Maximum transmission unit in 802.16 (section 6.3)

"
  The 802.16 MAC header is a 6 byte header followed by the payload and
  a 4 byte CRC which covers the whole PDU (Protocol Data Unit).  The
  length of the PDU is indicated by the Len parameter in the Generic
  MAC HDR. 
"
As reading, we may think that the payload and the CRC are always present
on the MAC frames.
They are not included in all messages. So I suggest to rewrite this,
starting with:

 The 802.16 MAC PDU (Protocol Data Unit) is composed by
 a 6 byte header followed by an optional payload and
 an optional CRC covering the header and the payload.

    

Okay... I changed the text in the I-D as proposed.

  
This introduction has also the propose to clarify the covering of the
CRC (header + payload)
and not the whole PDU (since this one can include the CRC).


6) IPv6 prefix assignment (section 7)
I suggest to add a reference to the RFC2461, to clarify where the
on-link flag is defined:

The prefixes are advertised with the on-link (L-bit) flag set as
specified in RFC2461.
    

Okay. Done.

  
This section starts with:
"
 Each MS can be considered to be on a separate subnet as a result of
the point-to-point connection.
"
In the middle there is a sentence:
"
 Each MS MUST be considered to be on a separate subnet as a result of
the point-to-point connection.
"
Shouldn't here we have a consensus also?
(probably this is an issue related with RFC2119) So can or MUST?!
And the sentences aren't repeating themselves in the same section?

    

Agree. Fixed it.

  
7) Appendix D
This section introduces the SDU size proposed by the WiMAX forum.
I just want to point that there is no a relation with the SDU and
the IPv6 payload spoken along the document.
Shouldn't this be clarified?!
    

I dont think that is necessary. Within the main body of the text it is
clear what the MAX IPv6 payload size can be. And in the appendix, the
I-D is making a recomendation that the MAX MTU be 1400 bytes by
default but obviously can be anything between 1280 and 1500.
Ok. I agree with you.

Kindly,
Bruno Sousa

--------------000701040207060007040204-- --===============1577788535== 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 --===============1577788535==-- From 16ng-bounces@ietf.org Sat Jan 13 09:54:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kGf-0004Zi-Ed; Sat, 13 Jan 2007 09:54:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kGe-0004Zd-4s for 16ng@ietf.org; Sat, 13 Jan 2007 09:54:00 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5kGb-0002Jh-ME for 16ng@ietf.org; Sat, 13 Jan 2007 09:54:00 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1168700036!12964414!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18955 invoked from network); 13 Jan 2007 14:53:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 13 Jan 2007 14:53:56 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0DEruMQ015192; Sat, 13 Jan 2007 07:53:56 -0700 (MST) Received: from [10.129.40.116] ([10.129.40.116]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l0DErsRU009866; Sat, 13 Jan 2007 08:53:55 -0600 (CST) Message-ID: <45A8F282.6080908@motorola.com> Date: Sat, 13 Jan 2007 15:53:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gabriel montenegro Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] References: <20070112200054.61802.qmail@web81907.mail.mud.yahoo.com> In-Reply-To: <20070112200054.61802.qmail@web81907.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 gabriel montenegro wrote: > Alex, > > Just looking at this statement of yours below: > > "Do you agree that (1) an SS can't multicast an RS because 802.16e > IPv6CS doesn't support ul multicast?" > > For this issue of multicast support, I refer you again to > clarification by our 802.16 liaison, e.g., > > http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20061106/000392.html > > > > > > > http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20061106/000394.html > > Gabriel, Thanks for referring to the two mails. They indeed provide liaison explanation about what multicast and broadcast mean in the context of 802.16 links, topology and PHY. However, what an IPv6 stack needs to know is what to put in dst addresses when sending IP multicast packets. The resolution of this as suggested by IPv6-over-IPv6CS is to not care at all about what to put there, one can put anything, the other end will see it because point-to-point. This is incomplete, underspecified and as vague as fog, but can be however inline with both implementation and with some other RFCs. Depends how one reads it the word 'join' and the word 'multicast'. Let me raise another case where link-layer multicast is needed even for ptp links - OSPF advertisements. If the AR sees all packets from SS (ie no multicast filtering on ptp) then SS sees all packets from SS too. This means that without a link-layer multicast technique the SS will see things only routers are interested in. For example if AR multicasts OSPF messages (SS is not interested in, but new MR software on SS may). Without a multicast feature in the link-layer the SS will see these messages, and they'll also consume air interface. A solution to this problem is to have that MR software on SS to send MLD report when it starts, it's known - so only then will the OSPF advs sent over the air interface. But without a clear means from the link-layer to have multicast on the ptp link it won't work. And also I wanted to say that if in the group the necessity for link-layer multicast over the 802.16 ptp (IPv6-over-IPv6CS) is not felt as necessary then I align with the group. Alex > > -gabriel > > ----- Original Message ---- From: Alexandru Petrescu > To: Basavaraj Patil > Cc: 16ng@ietf.org Sent: Friday, January > 12, 2007 10:07:05 AM Subject: Re: [16NG] Resolutions to issues raised > during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] > > Basavaraj Patil wrote: >> Hi Alex, >> >> On 1/12/07 5:06 AM, "ext Alexandru Petrescu" >> wrote: >> >>> Periodic RA is in widespread use for movement detection. I do >>> not understand the opposition to use periodic RAs as allowed by >>> rfc3775. What breaks if we use periodic RAs with a frequency >>> higher than 1/4s? (remark arguments of air interface gains are >>> different on high-bandwidth links). >> >> The fact is that sending periodic RAs on an air interface >> irrespective of BW capacity is suboptimal. A host in Idle mode is >> not listening for periodic RAs. Listening for periodic RAs would >> prevent the host from transitioning to idle mode which has an >> adverse impact on battery life. 802.16 has defined paging and Idle >> mode support. In air-interfaces that do not support such >> capability, sending of very frequent RAs is possible but IMO still >> not the most efficient usage of the bandwidth. In licensed spectrum >> the optimization and efficiency of the air interface is critical. >> Periodic RAs are unavoidable at this time. The best that we can do >> without breaking backward compatibility is to send it with large >> time intervals as the I-D suggests. Movement detection can be done >> be accomplished by other means. If the host is only relying on RAs >> for movement detection (at the IP layer), then it could just as >> well send a Rtr solicitation. This is not prevented. >> >> In Unlicensed spectrum you may have a bit more liberty about how >> the air-interface is used but even in those cases, optimizing it is >> a better choice. > > Raj, I understand a strong pushback from you about having periodic > RAs with less than 4s. I think it's not motivated. > > Let's then discuss the RS method for quick movement detection. > > Do you agree that (1) an SS can't multicast an RS because 802.16e > IPv6CS doesn't support ul multicast? and that (2) there's no means > for SS to unicast the RS because it doesn't know the BS's link-local > address because no message in the network entry procedure delivers > BS's link-local address? > > What do you think? > > Alex > > > _______________________________________________ 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 Jan 13 10:27:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kmn-0005wa-Rc; Sat, 13 Jan 2007 10:27:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kmm-0005vE-EW for 16ng@ietf.org; Sat, 13 Jan 2007 10:27:12 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5kml-0000Fe-3K for 16ng@ietf.org; Sat, 13 Jan 2007 10:27:12 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1535441nfa for <16ng@ietf.org>; Sat, 13 Jan 2007 07:27:10 -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=N5Zytu7Hh4G2yH9cYBnd0MbwX17jGPLjwH7OA1K0NT8Ks4JUlqgAoDBXbDr5CckATQ1lj1OQmdmC11jJkLCxYjTX/saep0Ww6phIEhWiAwQWziGFioum4jUPwEsufpJzbXQDs3/NrcYmSCIX7stNwywSwIwMwg628L0ELB0Evqg= Received: by 10.49.57.1 with SMTP id j1mr1817062nfk.1168702030046; Sat, 13 Jan 2007 07:27:10 -0800 (PST) Received: by 10.49.92.12 with HTTP; Sat, 13 Jan 2007 07:27:09 -0800 (PST) Message-ID: <10e14db20701130727o1cd4671er1b1b3a238a5e3353@mail.gmail.com> Date: Sat, 13 Jan 2007 20:57:09 +0530 From: "Syam Madanapalli" To: "Alexandru Petrescu" Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] In-Reply-To: <45A76BB7.9070604@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45A6AA0C.7040508@motorola.com> <92e919fb0701111820k3aa970aft5001f778e8e46d93@mail.gmail.com> <45A76BB7.9070604@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 some text inline. > > JinHyeock Choi wrote: > > Dear Alex > > > > Thanks for your feedback. Kindly find my in-line comments. > > > >>> and there is no reason for the host to depend on RAs to detect if > >>> it has moved across ARs. Hence there is no reason for any change > >>> w.r.t 3775 and I do not see RFC3775 over-riding the values > >>> specified here. > >> > >> There is no other means for an IP stack on top of IPv6CS to know > >> that the subnet has changed. This is where MIP6 reacts, on subnet > >> change, not on PHY change. So the 802.16 BS, if it sends RAs, it > >> should send them quickly. > > > > Allow me to make is more clear. > > > > A 802.16 host doesn't have to rely on unsolicited PERIODIC RAs for > > movement detection. Upon network attachment, either 1) the access > > router sends an unsolicted RA as of FRD (draft-ietf-dna-frd-02) or 2) > > the host sends an RS to get a solicited RA as of DNAv6 > > (draft-ietf-dna-protocol-03.txt). > > I am not sure what you mean by 'network attachment'? I suppose you mean > the network entry procedure of 802.16? ('Attach' in 802.16 mostly means > to attach a part of message to another part, and only in one single > place a SS to a BS). > In the network entry procedure of the 802.16 document there is nothing > that suggests the behaviour you suggest above (DNA). Only ND is > suggested, not DNA. DNA is nothing to do with 802.16, it is layer 3 mechanism, you can find the details at http://www.ietf.org/internet-drafts/draft-ietf-dna-protocol-03.txt > > Periodic RA is in widespread use for movement detection. I do not > understand the opposition to use periodic RAs as allowed by rfc3775. > What breaks if we use periodic RAs with a frequency higher than 1/4s? > (remark arguments of air interface gains are different on high-bandwidth > links). Frequent periodic RAs consume the air bandwidth and may cause problems for dormant devices. Even if the above is not a problem, still depending RAs for movement detection may not be a good idea. The better way is to solicit for an RA when the device observes a L2 movement, to check if the device is on the same link or new one. Thanks, Syam > > Alex > > _______________________________________________ > 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 Jan 13 10:44:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5l3r-000864-L2; Sat, 13 Jan 2007 10:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5l3r-00085o-0A for 16ng@ietf.org; Sat, 13 Jan 2007 10:44:51 -0500 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5l3p-0003B7-Ku for 16ng@ietf.org; Sat, 13 Jan 2007 10:44:50 -0500 Received: by wr-out-0506.google.com with SMTP id 36so756840wra for <16ng@ietf.org>; Sat, 13 Jan 2007 07:44:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JoFHEyTBO5QWtPlgj2w5NmDdV12DndvwE94DMcCJZAkB1mUGBlZ+sjyHHmrzkI5sOgPOuKysNaZdOBLixN8dK2ASFEo3Z9V90A3JwvqbfWzSkIW6xMvkwmDTXNQ7QG+9ihAdEYZBqId1ILmn/MT1tyWq2tcRgAlsz7FV7krksWE= Received: by 10.65.224.11 with SMTP id b11mr2505883qbr.1168703088872; Sat, 13 Jan 2007 07:44:48 -0800 (PST) Received: by 10.65.225.19 with HTTP; Sat, 13 Jan 2007 07:44:48 -0800 (PST) Message-ID: Date: Sun, 14 Jan 2007 00:44:48 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45A76EC4.7070304@motorola.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> X-Google-Sender-Auth: dd54d87b3e3d5038 X-Spam-Score: 0.5 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: v6ops@ops.ietf.org, 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS 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="===============0188554790==" Errors-To: 16ng-bounces@ietf.org --===============0188554790== Content-Type: multipart/alternative; boundary="----=_Part_34668_16481665.1168703088593" ------=_Part_34668_16481665.1168703088593 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, Sorry for my late response. Basically I agree with your opinion. An IPv6 node requires a link local multicast address in order to perform DAD, ND, and RA. Contrary to our expectations, 802.16/16e don't support UL multicast (which means an MS forwards data directly to other MSs in the same cell). (BTW, I think I need to clarify the UL multicast I mentioned. I believe you already know this: the multicast/broadcast which is sent by an MS to other MSs in the same cell (BS) cannot be supported in 802.16. However, other MSs in another cell (BS) may receive this since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.) I agree that the document needs to specify how to deal with this problem. Best regards, Jihoon 2007/1/12, Alexandru Petrescu : > > Hi Jihoon, thanks for reply, > > Jihoon Lee wrote: > > Hi Alex, > > > > Let me jump into discussion. 1) 802.16/16e MAC has no capability to > > do uplink multicast. In DL, 802.16 provides multicast CIDs which is > > initiated by DSA messages. In UL, however, there is no way for an MS > > to access others' UL data fundamentally, in 802.16 PHY/MAC. > > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and > surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to > mention the word 'multicast'.) > > The issue is that a SS running IPv6 needs to multicast a NA, from time > to time. For DAD it needs to send a NS to a multicast address too. > > > In case of ETH over 802.16, the ETH(bridge) may cover this (an MS > > sends multicast data in UL, and then a bridge forwards it back). But, > > there is still a difficulty in multicasting data back except for the > > source MS. > > You mean the bridge in BS? I was thinking ETHCS in SS may offer a > multicast interface to the IP stack. > > In both cases (bridge in BS or bridge in SS), I think it is not up to > this document to specify how the ETHCS transforms a asymmetric ul/dl > multicast feature into a symmetric one. But it should be a goal for > ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6 > stack won't work. What do you think? > > Alex > ------=_Part_34668_16481665.1168703088593 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
Sorry for my late response. Basically I agree with your opinion.
An IPv6 node requires a link local multicast address in order to perform DAD, ND, and RA.
 
Contrary to our expectations, 802.16/16e don't support UL multicast (which means an MS forwards data directly to other MSs in the same cell).
 
(BTW, I think I need to clarify the UL multicast I mentioned. I believe you already know this: the multicast/broadcast which is sent by an MS  to other MSs in the same cell (BS) cannot be supported in 802.16. However, other MSs in another cell (BS) may receive this since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.)   
 
I agree that the document needs to specify how to deal with this problem. 
 
Best regards,
Jihoon

 
2007/1/12, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Hi Jihoon, thanks for reply,

Jihoon Lee wrote:
> Hi Alex,
>
> Let me jump into discussion. 1) 802.16/16e MAC has no capability to
> do uplink multicast. In DL, 802.16 provides multicast CIDs which is
> initiated by DSA messages. In UL, however, there is no way for an MS
> to access others' UL data fundamentally, in 802.16 PHY/MAC.

Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and
surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to
mention the word 'multicast'.)

The issue is that a SS running IPv6 needs to multicast a NA, from time
to time.  For DAD it needs to send a NS to a multicast address too.

> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS
> sends multicast data in UL, and then a bridge forwards it back). But,
>  there is still a difficulty in multicasting data back except for the
>  source MS.

You mean the bridge in BS?  I was thinking ETHCS in SS may offer a
multicast interface to the IP stack.

In both cases (bridge in BS or bridge in SS), I think it is not up to
this document to specify how the ETHCS transforms a asymmetric ul/dl
multicast feature into a symmetric one.  But it should be a goal for
ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6
stack won't work.  What do you think?

Alex

------=_Part_34668_16481665.1168703088593-- --===============0188554790== 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 --===============0188554790==-- From 16ng-bounces@ietf.org Sat Jan 13 15:50:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ppt-0000Hb-5P; Sat, 13 Jan 2007 15:50:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5ppr-0000D8-Sb for 16ng@ietf.org; Sat, 13 Jan 2007 15:50:43 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5ppq-0006BV-GH for 16ng@ietf.org; Sat, 13 Jan 2007 15:50:43 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1168721441!10998506!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 1414 invoked from network); 13 Jan 2007 20:50:41 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-6.tower-128.messagelabs.com with SMTP; 13 Jan 2007 20:50:41 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0DKobUr009952; Sat, 13 Jan 2007 13:50:41 -0700 (MST) Received: from [10.129.40.14] ([10.129.40.14]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0DKoYwL028098; Sat, 13 Jan 2007 14:50:35 -0600 (CST) Message-ID: <45A9461A.7000106@motorola.com> Date: Sat, 13 Jan 2007 21:50:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Syam Madanapalli Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1] References: <45A6AA0C.7040508@motorola.com> <92e919fb0701111820k3aa970aft5001f778e8e46d93@mail.gmail.com> <45A76BB7.9070604@motorola.com> <10e14db20701130727o1cd4671er1b1b3a238a5e3353@mail.gmail.com> In-Reply-To: <10e14db20701130727o1cd4671er1b1b3a238a5e3353@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: d8ae4fd88fcaf47c1a71c804d04f413d 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 Syam, thanks for the reply, Syam Madanapalli wrote: > some text inline. > >> >> JinHyeock Choi wrote: >>> Dear Alex >>> >>> Thanks for your feedback. Kindly find my in-line comments. >>> >>>>> and there is no reason for the host to depend on RAs to >>>>> detect if it has moved across ARs. Hence there is no reason >>>>> for any change w.r.t 3775 and I do not see RFC3775 >>>>> over-riding the values specified here. >>>> >>>> There is no other means for an IP stack on top of IPv6CS to >>>> know that the subnet has changed. This is where MIP6 reacts, >>>> on subnet change, not on PHY change. So the 802.16 BS, if it >>>> sends RAs, it should send them quickly. >>> >>> Allow me to make is more clear. >>> >>> A 802.16 host doesn't have to rely on unsolicited PERIODIC RAs >>> for movement detection. Upon network attachment, either 1) the >>> access router sends an unsolicted RA as of FRD >>> (draft-ietf-dna-frd-02) or 2) the host sends an RS to get a >>> solicited RA as of DNAv6 (draft-ietf-dna-protocol-03.txt). >> >> I am not sure what you mean by 'network attachment'? I suppose you >> mean the network entry procedure of 802.16? ('Attach' in 802.16 >> mostly means to attach a part of message to another part, and only >> in one single place a SS to a BS). In the network entry procedure >> of the 802.16 document there is nothing that suggests the >> behaviour you suggest above (DNA). Only ND is suggested, not DNA. >> > > DNA is nothing to do with 802.16, it is layer 3 mechanism, you can > find the details at > http://www.ietf.org/internet-drafts/draft-ietf-dna-protocol-03.txt Yes, it is a layer 3 mechanism. Only layer 3 mechanisms can be designed at IETF, or layer-2-3, but not layer 3. I think we agree. >> Periodic RA is in widespread use for movement detection. I do not >> understand the opposition to use periodic RAs as allowed by >> rfc3775. What breaks if we use periodic RAs with a frequency higher >> than 1/4s? (remark arguments of air interface gains are different >> on high-bandwidth links). > > Frequent periodic RAs consume the air bandwidth and may cause > problems for dormant devices. I agree they may be an issue. But to what extent? Dormant devices always have something listening and executing code. > Even if the above is not a problem, still depending RAs for movement > detection may not be a good idea. The better way is to solicit for > an RA when the device observes a L2 movement, to check if the device > is on the same link or new one. YEs, it is a very good idea to send an RS to get an RA and compare the prefix see whether MIP6 needs to be triggered. But where to send this RS? To the IP all-nodes multicast address? I agree it works to send it and the BS will receive it, and respond RA. But remark it will receive it even if SS puts the digit '5' there, not necessarily 'ff02::1'. Which to me is a door open to incompatibilities and potential inter-operability issues. But, if it's thought that this is not an issue I will not insist. I agree with the group. The mechanism to send an RS is good enough to detect a subnet-layer handover and many implementations can do. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Sat Jan 13 23:57:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5xQO-0001wD-OF; Sat, 13 Jan 2007 23:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5xQN-0001w8-0X for 16ng@ietf.org; Sat, 13 Jan 2007 23:56:55 -0500 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5xQM-0000jo-J5 for 16ng@ietf.org; Sat, 13 Jan 2007 23:56:54 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1252519wxd for <16ng@ietf.org>; Sat, 13 Jan 2007 20:56:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jRsL81FZ0xQtfsZ73VvMMeherAf0t9aXWUbOI6Ukz0cFbYlLLIfqpm4gQiYVH5a7vmdt0oMBKl/XM3xs2vBFr+lhQ6rkTUvH/V2z6itN1pM3PHEs9ZOVP8sdUL0dtT5G9uF1GCrEWhmU6QXIKYllmkmfaPh4fnvKjKY5L+TcObA= Received: by 10.70.33.10 with SMTP id g10mr4900917wxg.1168750614214; Sat, 13 Jan 2007 20:56:54 -0800 (PST) Received: by 10.70.102.13 with HTTP; Sat, 13 Jan 2007 20:56:53 -0800 (PST) Message-ID: <4a8dceef0701132056t6a8fb498k161f82b90bed7001@mail.gmail.com> Date: Sat, 13 Jan 2007 23:56:53 -0500 From: "Qiang Zhang" To: "Jihoon Lee" Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS In-Reply-To: MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: v6ops@ops.ietf.org, 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qiangieee@gmail.com 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="===============1717597462==" Errors-To: 16ng-bounces@ietf.org --===============1717597462== Content-Type: multipart/alternative; boundary="----=_Part_45686_3271484.1168750613913" ------=_Part_45686_3271484.1168750613913 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Physical layer UL/DL multicast or multiPackets should not be confused with the access network multicast which can go across multiple cells managed by one ASN, I think there should be no restriction for the design to incorporate the IP or Eth level multicast initiated from the ASN after receiving a IP multicast packet from the MS, am confused why can't the ASN also broadcast/multicast back to the same cell the MS is residing if you can clarify Qiang On 1/13/07, Jihoon Lee wrote: > > Hi Alex, > > Sorry for my late response. Basically I agree with your opinion. > An IPv6 node requires a link local multicast address in order to perform > DAD, ND, and RA. > > Contrary to our expectations, 802.16/16e don't support UL multicast > (which means an MS forwards data directly to other MSs in the same cell). > > (BTW, I think I need to clarify the UL multicast I mentioned. I believe > you already know this: the multicast/broadcast which is sent by an MS to > other MSs in the same cell (BS) cannot be supported in 802.16. However, > other MSs in another cell (BS) may receive this since the 802.16 backhaul > (WiMAX ASN) may multicast/broadcast at ETH or IP layer.) > > I agree that the document needs to specify how to deal with this problem. > > Best regards, > Jihoon > > > 2007/1/12, Alexandru Petrescu : > > > > Hi Jihoon, thanks for reply, > > > > Jihoon Lee wrote: > > > Hi Alex, > > > > > > Let me jump into discussion. 1) 802.16/16e MAC has no capability to > > > do uplink multicast. In DL, 802.16 provides multicast CIDs which is > > > initiated by DSA messages. In UL, however, there is no way for an MS > > > to access others' UL data fundamentally, in 802.16 PHY/MAC. > > > > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > > normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and > > surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to > > mention the word 'multicast'.) > > > > The issue is that a SS running IPv6 needs to multicast a NA, from time > > to time. For DAD it needs to send a NS to a multicast address too. > > > > > In case of ETH over 802.16, the ETH(bridge) may cover this (an MS > > > sends multicast data in UL, and then a bridge forwards it back). But, > > > there is still a difficulty in multicasting data back except for the > > > source MS. > > > > You mean the bridge in BS? I was thinking ETHCS in SS may offer a > > multicast interface to the IP stack. > > > > In both cases (bridge in BS or bridge in SS), I think it is not up to > > this document to specify how the ETHCS transforms a asymmetric ul/dl > > multicast feature into a symmetric one. But it should be a goal for > > ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6 > > stack won't work. What do you think? > > > > Alex > > > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > > > ------=_Part_45686_3271484.1168750613913 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi All,

Physical layer UL/DL multicast or multiPackets should not be confused with the access network multicast which can go across multiple cells managed by one ASN, I think there should be no restriction for the design to incorporate the IP or Eth level multicast initiated from  the ASN after receiving a IP multicast packet from the MS, am confused why can't the ASN also broadcast/multicast back to the same cell the MS is residing if you can clarify

Qiang

On 1/13/07, Jihoon Lee <jhlee@mmlab.snu.ac.kr> wrote:
Hi Alex,
 
Sorry for my late response. Basically I agree with your opinion.
An IPv6 node requires a link local multicast address in order to perform DAD, ND, and RA.
 
Contrary to our expectations, 802.16/16e don't support UL multicast (which means an MS forwards data directly to other MSs in the same cell).
 
(BTW, I think I need to clarify the UL multicast I mentioned. I believe you already know this: the multicast/broadcast which is sent by an MS  to other MSs in the same cell (BS) cannot be supported in 802.16. However, other MSs in another cell (BS) may receive this since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.)   
 
I agree that the document needs to specify how to deal with this problem. 
 
Best regards,
Jihoon

 
2007/1/12, Alexandru Petrescu <alexandru.petrescu@motorola.com >:
Hi Jihoon, thanks for reply,

Jihoon Lee wrote:
> Hi Alex,
>
> Let me jump into discussion. 1) 802.16/16e MAC has no capability to
> do uplink multicast. In DL, 802.16 provides multicast CIDs which is
> initiated by DSA messages. In UL, however, there is no way for an MS
> to access others' UL data fundamentally, in 802.16 PHY/MAC.

Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and
surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to
mention the word 'multicast'.)

The issue is that a SS running IPv6 needs to multicast a NA, from time
to time.  For DAD it needs to send a NS to a multicast address too.

> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS
> sends multicast data in UL, and then a bridge forwards it back). But,
>  there is still a difficulty in multicasting data back except for the
>  source MS.

You mean the bridge in BS?  I was thinking ETHCS in SS may offer a
multicast interface to the IP stack.

In both cases (bridge in BS or bridge in SS), I think it is not up to
this document to specify how the ETHCS transforms a asymmetric ul/dl
multicast feature into a symmetric one.  But it should be a goal for
ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6
stack won't work.  What do you think?

Alex


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



------=_Part_45686_3271484.1168750613913-- --===============1717597462== 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 --===============1717597462==-- From 16ng-bounces@ietf.org Sun Jan 14 19:32:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Flb-0001g1-8k; Sun, 14 Jan 2007 19:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Fla-0001fw-Jh for 16ng@ietf.org; Sun, 14 Jan 2007 19:32:02 -0500 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6FlY-00053C-1u for 16ng@ietf.org; Sun, 14 Jan 2007 19:32:02 -0500 Received: by wr-out-0506.google.com with SMTP id i4so919861wra for <16ng@ietf.org>; Sun, 14 Jan 2007 16:31:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=uYXv4teD/PgsLKQMoUqvESNbeQn/vDWyEFkuvSxxAJ3jmua8AVjqkmuNROIqlCDJk4yTUG/E23zlqaxYCBnJv+hvDX5okIZ7BhtWiBNnCIjzD997bsx1ArVNAPiE7wD9iWyeduOmJItLSHwmD/2jpmP/kwIdb/DQKM5sfB4uZhg= Received: by 10.65.193.16 with SMTP id v16mr4610847qbp.1168821119447; Sun, 14 Jan 2007 16:31:59 -0800 (PST) Received: by 10.65.225.19 with HTTP; Sun, 14 Jan 2007 16:31:59 -0800 (PST) Message-ID: Date: Mon, 15 Jan 2007 09:31:59 +0900 From: "Jihoon Lee" To: qiangieee@gmail.com Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS In-Reply-To: <4a8dceef0701132056t6a8fb498k161f82b90bed7001@mail.gmail.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <4a8dceef0701132056t6a8fb498k161f82b90bed7001@mail.gmail.com> X-Google-Sender-Auth: 1481287032ccb400 X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: v6ops@ops.ietf.org, 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="===============1677740646==" Errors-To: 16ng-bounces@ietf.org --===============1677740646== Content-Type: multipart/alternative; boundary="----=_Part_42057_19740063.1168821119376" ------=_Part_42057_19740063.1168821119376 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Qiang, Let me add on a few more words. As you know, normally ETH switches and IP routers don't forward multicast/broadcast packets back to their source port. It's based on assumption that local multicast has already done locally in the network which is connected to the source port. Let's say an multicast packet sent by an 802.16 MS is delivered to an ETH bridge or IP access router. It will be forwarded to other ETH/IP interfaces (ports), but may not be forwarded to its source interface. However, there may be other MSs which have never receive the packets, since the source interface is actually connected to an 802.16 link layer. As I understood, the question starts from here; why doesn't 802.16 link layer support uplink multicast/broadcast? Then, which entity could handle this?. Anyway it has to be specified. There must be various feasible solutions. Regarding per-MS(service flow) IP tunnel, the tunnel end point may differentiate the source MS. I'm not sure that there has ever been a firm resolution made. Whatever the solution made, it should be transparent to IP/ETH layer. Moreover, the link-layer performance in terms of air bandwith efficiency is also important. Best regards, Jihoon 2007/1/14, Qiang Zhang : > > > Hi All, > > Physical layer UL/DL multicast or multiPackets should not be confused with > the access network multicast which can go across multiple cells managed by > one ASN, I think there should be no restriction for the design to > incorporate the IP or Eth level multicast initiated from the ASN after > receiving a IP multicast packet from the MS, am confused why can't the ASN > also broadcast/multicast back to the same cell the MS is residing if you can > clarify > > Qiang > > On 1/13/07, Jihoon Lee wrote: > > > Hi Alex, > > > > Sorry for my late response. Basically I agree with your opinion. > > An IPv6 node requires a link local multicast address in order to perform > > DAD, ND, and RA. > > > > Contrary to our expectations, 802.16/16e don't support UL multicast > > (which means an MS forwards data directly to other MSs in the same cell). > > > > (BTW, I think I need to clarify the UL multicast I mentioned. I believe > > you already know this: the multicast/broadcast which is sent by an MS to > > other MSs in the same cell (BS) cannot be supported in 802.16. However, > > other MSs in another cell (BS) may receive this since the 802.16backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.) > > > > I agree that the document needs to specify how to deal with this > > problem. > > > > Best regards, > > Jihoon > > > > > > 2007/1/12, Alexandru Petrescu : > > > > > > Hi Jihoon, thanks for reply, > > > > > > Jihoon Lee wrote: > > > > Hi Alex, > > > > > > > > Let me jump into discussion. 1) 802.16/16e MAC has no capability to > > > > do uplink multicast. In DL, 802.16 provides multicast CIDs which is > > > > initiated by DSA messages. In UL, however, there is no way for an MS > > > > to access others' UL data fundamentally, in 802.16 PHY/MAC. > > > > > > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > > > normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and > > > surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to > > > > > > mention the word 'multicast'.) > > > > > > The issue is that a SS running IPv6 needs to multicast a NA, from time > > > to time. For DAD it needs to send a NS to a multicast address too. > > > > > > > In case of ETH over 802.16, the ETH(bridge) may cover this (an MS > > > > sends multicast data in UL, and then a bridge forwards it back). > > > But, > > > > there is still a difficulty in multicasting data back except for > > > the > > > > source MS. > > > > > > You mean the bridge in BS? I was thinking ETHCS in SS may offer a > > > multicast interface to the IP stack. > > > > > > In both cases (bridge in BS or bridge in SS), I think it is not up to > > > this document to specify how the ETHCS transforms a asymmetric ul/dl > > > multicast feature into a symmetric one. But it should be a goal for > > > ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6 > > > stack won't work. What do you think? > > > > > > Alex > > > > > > > > > _______________________________________________ > > 16NG mailing list > > 16NG@ietf.org > > https://www1.ietf.org/mailman/listinfo/16ng > > > > > > > ------=_Part_42057_19740063.1168821119376 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Qiang,
 
Let me add on a few more words. As you know, normally ETH switches and IP routers don't forward multicast/broadcast packets back to their source port. It's based on assumption that local multicast has already done locally in the network which is connected to the source port.
 
Let's say an multicast packet sent by an 802.16 MS is delivered to an ETH bridge or IP access router. It will be forwarded to other ETH/IP interfaces (ports), but may not be forwarded to its source interface. However, there may be other MSs which have never receive the packets, since the source interface is actually connected to an 802.16 link layer. As I understood, the question starts from here; why doesn't 802.16 link layer support uplink multicast/broadcast? Then, which entity could handle this?. Anyway it has to be specified.
 
There must be various feasible solutions. Regarding per-MS(service flow) IP tunnel, the tunnel end point may differentiate the source MS. I'm not sure that there has ever been a firm resolution made. Whatever the solution made, it should be transparent to IP/ETH layer. Moreover, the link-layer performance in terms of air bandwith efficiency is also important.
 
Best regards,
Jihoon
 
 
2007/1/14, Qiang Zhang <qiangieee@gmail.com>:

Hi All,

Physical layer UL/DL multicast or multiPackets should not be confused with the access network multicast which can go across multiple cells managed by one ASN, I think there should be no restriction for the design to incorporate the IP or Eth level multicast initiated from  the ASN after receiving a IP multicast packet from the MS, am confused why can't the ASN also broadcast/multicast back to the same cell the MS is residing if you can clarify

Qiang
On 1/13/07, Jihoon Lee < jhlee@mmlab.snu.ac.kr> wrote:
Hi Alex,
 
Sorry for my late response. Basically I agree with your opinion.
An IPv6 node requires a link local multicast address in order to perform DAD, ND, and RA.
 
Contrary to our expectations, 802.16/16e don't support UL multicast (which means an MS forwards data directly to other MSs in the same cell).
 
(BTW, I think I need to clarify the UL multicast I mentioned. I believe you already know this: the multicast/broadcast which is sent by an MS  to other MSs in the same cell (BS) cannot be supported in 802.16. However, other MSs in another cell (BS) may receive this since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH or IP layer.)   
 
I agree that the document needs to specify how to deal with this problem. 
 
Best regards,
Jihoon

 
2007/1/12, Alexandru Petrescu <alexandru.petrescu@motorola.com >:
Hi Jihoon, thanks for reply,

Jihoon Lee wrote:
> Hi Alex,
>
> Let me jump into discussion. 1) 802.16/16e MAC has no capability to
> do uplink multicast. In DL, 802.16 provides multicast CIDs which is
> initiated by DSA messages. In UL, however, there is no way for an MS
> to access others' UL data fundamentally, in 802.16 PHY/MAC.

Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
normal) multicast then that is a big issue for IPv6-over-IPv6CS. (and
surprisingly, apparently the document IPv6-over-IPv6CS doesn't seem to
mention the word 'multicast'.)

The issue is that a SS running IPv6 needs to multicast a NA, from time
to time.  For DAD it needs to send a NS to a multicast address too.

> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS
> sends multicast data in UL, and then a bridge forwards it back). But,
>  there is still a difficulty in multicasting data back except for the
>  source MS.

You mean the bridge in BS?  I was thinking ETHCS in SS may offer a
multicast interface to the IP stack.

In both cases (bridge in BS or bridge in SS), I think it is not up to
this document to specify how the ETHCS transforms a asymmetric ul/dl
multicast feature into a symmetric one.  But it should be a goal for
ETHCS to offer such an interface to the IPv6 stack, otherwise the IPv6
stack won't work.  What do you think?

Alex


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




------=_Part_42057_19740063.1168821119376-- --===============1677740646== 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 --===============1677740646==-- From 16ng-bounces@ietf.org Sun Jan 14 21:12:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6HL1-0002T1-IY; Sun, 14 Jan 2007 21:12:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6HL0-0002Sd-HR for 16ng@ietf.org; Sun, 14 Jan 2007 21:12:42 -0500 Received: from kc-msxproto3.kc.umkc.edu ([134.193.44.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6HKy-00087X-8U for 16ng@ietf.org; Sun, 14 Jan 2007 21:12:42 -0500 Received: from KC-MSX4.kc.umkc.edu ([134.193.32.14]) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jan 2007 20:12:39 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Jan 2007 20:12:39 -0600 Message-ID: <1C1A133246EC8344B22D2FDFF3D341E603C45E93@KC-MSX4.kc.umkc.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: Acc4SqGLtzAw30KBTne6gWwNrmYKMw== From: "Rongala, Venkat Rao \(UMKC-Student\)" To: <16ng@ietf.org> X-OriginalArrivalTime: 15 Jan 2007 02:12:39.0567 (UTC) FILETIME=[A1BE09F0:01C7384A] X-Spam-Score: 3.2 (+++) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [16NG] (no subject) 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 hello my email id is vrr7b2@umkc.edu. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 15 07:24:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Qsu-00008Z-UN; Mon, 15 Jan 2007 07:24:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Qst-00008F-PO for 16ng@ietf.org; Mon, 15 Jan 2007 07:24:19 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6Qsq-0005C8-IQ for 16ng@ietf.org; Mon, 15 Jan 2007 07:24:19 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1168863855!6876222!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 30067 invoked from network); 15 Jan 2007 12:24:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 15 Jan 2007 12:24:15 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0FCODu7026241; Mon, 15 Jan 2007 05:24:13 -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 l0FCOCsk001300; Mon, 15 Jan 2007 06:24:12 -0600 (CST) Message-ID: <45AB7268.7020609@motorola.com> Date: Mon, 15 Jan 2007 13:24:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> 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: a2c12dacc0736f14d6b540e805505a86 Cc: v6ops@ops.ietf.org, 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS 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 Jihoon, Jihoon Lee wrote: > Hi Alex, > > Sorry for my late response. Basically I agree with your opinion. An > IPv6 node requires a link local multicast address in order to perform > DAD, ND, and RA. > > Contrary to our expectations, 802.16/16e don't support UL multicast > (which means an MS forwards data directly to other MSs in the same > cell). > > (BTW, I think I need to clarify the UL multicast I mentioned. I > believe you already know this: the multicast/broadcast which is sent > by an MS to other MSs in the same cell (BS) cannot be supported in > 802.16. However, other MSs in another cell (BS) may receive this > since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH > or IP layer.) > > I agree that the document needs to specify how to deal with this > problem. Yes, I think the IPv6-over-ETHCS document should make clear the assumption of IPv6 using link-layer multicast for IPv6. I don't think the IPv6-over-ETHCS document should solve the problem you mention above between parenthesis (uplink mc, or mc between BSs) at link layer. The IPv6-over-ETHCS document could list the behaviour of ETHCS it expects. Ie: -when MS sends NS to a IP solicited-node multicast address the node who has joined group must receive it. -when BS or AR advertises an RA to all-nodes multicast address then all SSs who have joined that group must receive it. -mapping an IPv6 link-local multicast address should happen (eg sending a packet to IP dst ff02::1 should have the link-layer dst 33:33:33:0:0:0:1). The document IPv6-over-ETHCS should list what are the means for SS to _join_ a link-layer multicast group. There are few of them (send a link-layer message, send a MLD message, establish a local filtering rule, always receiving all packets, etc). But I don't think the IPv6-over-ETHCS document should specify the link-layer behaviour for an implementation of ETHCS link-layer multicast. Do you agree with this latter item? Alex > > Best regards, Jihoon > > > 2007/1/12, Alexandru Petrescu >: > > Hi Jihoon, thanks for reply, > > Jihoon Lee wrote: >> Hi Alex, >> >> Let me jump into discussion. 1) 802.16/16e MAC has no capability to >> do uplink multicast. In DL, 802.16 provides multicast CIDs which >> is initiated by DSA messages. In UL, however, there is no way for >> an MS to access others' UL data fundamentally, in 802.16 PHY/MAC. > > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > normal) multicast then that is a big issue for IPv6-over-IPv6CS. > (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't > seem to mention the word 'multicast'.) > > The issue is that a SS running IPv6 needs to multicast a NA, from > time to time. For DAD it needs to send a NS to a multicast address > too. > >> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS >> sends multicast data in UL, and then a bridge forwards it back). >> But, there is still a difficulty in multicasting data back except >> for the source MS. > > You mean the bridge in BS? I was thinking ETHCS in SS may offer a > multicast interface to the IP stack. > > In both cases (bridge in BS or bridge in SS), I think it is not up to > this document to specify how the ETHCS transforms a asymmetric ul/dl > multicast feature into a symmetric one. But it should be a goal for > ETHCS to offer such an interface to the IPv6 stack, otherwise the > IPv6 stack won't work. What do you think? > > Alex > > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 15 15:50:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Ymq-0001FH-92; Mon, 15 Jan 2007 15:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Ymn-00019y-4V; Mon, 15 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6Ymm-0006OM-Q8; Mon, 15 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 847D3176E9; Mon, 15 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H6YmI-0002ew-4D; Mon, 15 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 15 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 16ng@ietf.org Subject: [16NG] I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-05.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 : IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks Author(s) : B. Patil, et al. Filename : draft-ietf-16ng-ipv6-over-ipv6cs-05.txt Pages : 20 Date : 2007-1-15 IEEE Std 802.16 is an air interface specification. 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.The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv6 packets directly over the MAC. This document specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-05.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-over-ipv6cs-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-15110016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-16ng-ipv6-over-ipv6cs-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-15110016.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 Mon Jan 15 19:11:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bvU-00085O-38; Mon, 15 Jan 2007 19:11:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6bvT-00085J-CZ for 16ng@ietf.org; Mon, 15 Jan 2007 19:11:43 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6bvS-0004Kc-UH for 16ng@ietf.org; Mon, 15 Jan 2007 19:11:43 -0500 Received: by an-out-0708.google.com with SMTP id d30so487603and for <16ng@ietf.org>; Mon, 15 Jan 2007 16:11:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ndhH4dh9gsNBtmIIiAnjwciHVVwZaTUdeYsevsY3PNIyVQbEFmTVNJYbZJWfdrFDMC52O1PZWGmI9sKm2SnsW6q3XQwCR6xfn8UFllD/Fv8KFaELXBO+5MiVBGm3F5SfTG8Dh+ECyGnO9jclj+K57BuGmwzDe2YrR8VhSkK9F5I= Received: by 10.65.188.4 with SMTP id q4mr6685118qbp.1168906302147; Mon, 15 Jan 2007 16:11:42 -0800 (PST) Received: by 10.65.225.19 with HTTP; Mon, 15 Jan 2007 16:11:42 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 09:11:42 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45AB7268.7020609@motorola.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> X-Google-Sender-Auth: 171f5d877fd8fa93 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: v6ops@ops.ietf.org, 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS 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="===============0131461756==" Errors-To: 16ng-bounces@ietf.org --===============0131461756== Content-Type: multipart/alternative; boundary="----=_Part_51813_16314892.1168906302085" ------=_Part_51813_16314892.1168906302085 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, I agree with that. Thanks, Jihoon 2007/1/15, Alexandru Petrescu : > > Hi Jihoon, > > Jihoon Lee wrote: > > Hi Alex, > > > > Sorry for my late response. Basically I agree with your opinion. An > > IPv6 node requires a link local multicast address in order to perform > > DAD, ND, and RA. > > > > Contrary to our expectations, 802.16/16e don't support UL multicast > > (which means an MS forwards data directly to other MSs in the same > > cell). > > > > (BTW, I think I need to clarify the UL multicast I mentioned. I > > believe you already know this: the multicast/broadcast which is sent > > by an MS to other MSs in the same cell (BS) cannot be supported in > > 802.16. However, other MSs in another cell (BS) may receive this > > since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH > > or IP layer.) > > > > I agree that the document needs to specify how to deal with this > > problem. > > Yes, I think the IPv6-over-ETHCS document should make clear the > assumption of IPv6 using link-layer multicast for IPv6. I don't think > the IPv6-over-ETHCS document should solve the problem you mention above > between parenthesis (uplink mc, or mc between BSs) at link layer. > > The IPv6-over-ETHCS document could list the behaviour of ETHCS it > expects. Ie: > > -when MS sends NS to a IP solicited-node multicast address the node who > has joined group must receive it. > -when BS or AR advertises an RA to all-nodes multicast address then all > SSs who have joined that group must receive it. > -mapping an IPv6 link-local multicast address should happen (eg sending > a packet to IP dst ff02::1 should have the link-layer dst > 33:33:33:0:0:0:1). > > The document IPv6-over-ETHCS should list what are the means for SS to > _join_ a link-layer multicast group. There are few of them (send a > link-layer message, send a MLD message, establish a local filtering > rule, always receiving all packets, etc). > > But I don't think the IPv6-over-ETHCS document should specify the > link-layer behaviour for an implementation of ETHCS link-layer > multicast. Do you agree with this latter item? > > Alex > > > > > Best regards, Jihoon > > > > > > 2007/1/12, Alexandru Petrescu > >: > > > > Hi Jihoon, thanks for reply, > > > > Jihoon Lee wrote: > >> Hi Alex, > >> > >> Let me jump into discussion. 1) 802.16/16e MAC has no capability to > >> do uplink multicast. In DL, 802.16 provides multicast CIDs which > >> is initiated by DSA messages. In UL, however, there is no way for > >> an MS to access others' UL data fundamentally, in 802.16 PHY/MAC. > > > > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > > normal) multicast then that is a big issue for IPv6-over-IPv6CS. > > (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't > > seem to mention the word 'multicast'.) > > > > The issue is that a SS running IPv6 needs to multicast a NA, from > > time to time. For DAD it needs to send a NS to a multicast address > > too. > > > >> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS > >> sends multicast data in UL, and then a bridge forwards it back). > >> But, there is still a difficulty in multicasting data back except > >> for the source MS. > > > > You mean the bridge in BS? I was thinking ETHCS in SS may offer a > > multicast interface to the IP stack. > > > > In both cases (bridge in BS or bridge in SS), I think it is not up to > > this document to specify how the ETHCS transforms a asymmetric ul/dl > > multicast feature into a symmetric one. But it should be a goal for > > ETHCS to offer such an interface to the IPv6 stack, otherwise the > > IPv6 stack won't work. What do you think? > > > > Alex > > > > > > ------=_Part_51813_16314892.1168906302085 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
I agree with that.
 
Thanks,
Jihoon
 


 
2007/1/15, Alexandru Petrescu <alexandru.petrescu@motorola.com >:
Hi Jihoon,

Jihoon Lee wrote:
> Hi Alex,
>
> Sorry for my late response. Basically I agree with your opinion. An
> IPv6 node requires a link local multicast address in order to perform
>  DAD, ND, and RA.
>
> Contrary to our expectations, 802.16/16e don't support UL multicast
> (which means an MS forwards data directly to other MSs in the same
> cell).
>
> (BTW, I think I need to clarify the UL multicast I mentioned. I
> believe you already know this: the multicast/broadcast which is sent
> by an MS  to other MSs in the same cell (BS) cannot be supported in
> 802.16. However, other MSs in another cell (BS) may receive this
> since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH
> or IP layer.)
>
> I agree that the document needs to specify how to deal with this
> problem.

Yes, I think the IPv6-over-ETHCS document should make clear the
assumption of IPv6 using link-layer multicast for IPv6.  I don't think
the IPv6-over-ETHCS document should solve the problem you mention above
between parenthesis (uplink mc, or mc between BSs) at link layer.

The IPv6-over-ETHCS document could list the behaviour of ETHCS it
expects.  Ie:

-when MS sends NS to a IP solicited-node multicast address the node who
has joined group must receive it.
-when BS or AR advertises an RA to all-nodes multicast address then all
SSs who have joined that group must receive it.
-mapping an IPv6 link-local multicast address should happen (eg sending
a packet to IP dst ff02::1 should have the link-layer dst
33:33:33:0:0:0:1).

The document IPv6-over-ETHCS should list what are the means for SS to
_join_ a link-layer multicast group.  There are few of them (send a
link-layer message, send a MLD message, establish a local filtering
rule, always receiving all packets, etc).

But I don't think the IPv6-over-ETHCS document should specify the
link-layer behaviour for an implementation of ETHCS link-layer
multicast.  Do you agree with this latter item?

Alex

>
> Best regards, Jihoon
>
>
> 2007/1/12, Alexandru Petrescu < alexandru.petrescu@motorola.com
> <mailto:alexandru.petrescu@motorola.com>>:
>
> Hi Jihoon, thanks for reply,
>
> Jihoon Lee wrote:
>> Hi Alex,
>>
>> Let me jump into discussion. 1) 802.16/16e MAC has no capability to
>>  do uplink multicast. In DL, 802.16 provides multicast CIDs which
>> is initiated by DSA messages. In UL, however, there is no way for
>> an MS to access others' UL data fundamentally, in 802.16 PHY/MAC.
>
> Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
>  normal) multicast then that is a big issue for IPv6-over-IPv6CS.
> (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't
> seem to mention the word 'multicast'.)
>
> The issue is that a SS running IPv6 needs to multicast a NA, from
> time to time.  For DAD it needs to send a NS to a multicast address
> too.
>
>> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS
>> sends multicast data in UL, and then a bridge forwards it back).
>> But, there is still a difficulty in multicasting data back except
>> for the source MS.
>
> You mean the bridge in BS?  I was thinking ETHCS in SS may offer a
> multicast interface to the IP stack.
>
> In both cases (bridge in BS or bridge in SS), I think it is not up to
>  this document to specify how the ETHCS transforms a asymmetric ul/dl
>  multicast feature into a symmetric one.  But it should be a goal for
>  ETHCS to offer such an interface to the IPv6 stack, otherwise the
> IPv6 stack won't work.  What do you think?
>
> Alex
>
>


------=_Part_51813_16314892.1168906302085-- --===============0131461756== 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 --===============0131461756==-- From 16ng-bounces@ietf.org Tue Jan 16 03:54:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6k5N-0003Dk-UP; Tue, 16 Jan 2007 03:54:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6k5M-0003DI-Bv for 16ng@ietf.org; Tue, 16 Jan 2007 03:54: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 1H6k5K-0001yA-Er for 16ng@ietf.org; Tue, 16 Jan 2007 03:54:28 -0500 Received: from etriabcb8a0047 ([129.254.12.182]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 17:58:54 +0900 From: "Hongseok Jeon" To: "'Narvaez, Paolo \(Paolo\)'" References: <61B0DCC9767CDC4C91769592B12CCDD11A7CD1@ILEXC2U02.ndc.lucent.com> Subject: RE: [16NG] Comments ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt Date: Tue, 16 Jan 2007 17:54:28 +0900 Message-ID: <007c01c7394b$ee3c7b20$b60cfe81@etriabcb8a0047> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <61B0DCC9767CDC4C91769592B12CCDD11A7CD1@ILEXC2U02.ndc.lucent.com> Thread-Index: Acci8N0mhuhkeWBKTomP8c55cnvPcgCLQ17gAB+yF1AD1Gbu8AEWehug X-OriginalArrivalTime: 16 Jan 2007 08:58:54.0975 (UTC) FILETIME=[8D07E0F0:01C7394C] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 Paolo, Thank you for your comments. Now we are going to update our draft. It will have lots of change. The updated draft does not use any tunnels between bridges. In the updated draft, MAC-Forced Forwarding [RFC4562] can be used to send all the packets from SSs toward AR in case of public access scenario and IGMP/MLD snooping [RFC4541] provides an efficient transmission of IP multicast data. Also some additional functionalities is to be presented for broadcast filtering. Best Regards, Hongseok > -----Original Message----- > From: Narvaez, Paolo (Paolo) [mailto:paolo@alcatel-lucent.com] > Sent: Thursday, January 11, 2007 5:16 AM > To: Hongseok Jeon > Cc: 16ng@ietf.org > Subject: RE: [16NG] Comments > ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt > > > > > Hongseok, > > Thanks for the reply. Please find below some additional > comments to your response. > > Thanks, > Paolo > > > -----Original Message----- > > From: Hongseok Jeon [mailto:jeonhs@etri.re.kr] > > Sent: Friday, December 22, 2006 5:31 AM > > To: Narvaez, Paolo (Paolo) > > Cc: 16ng@ietf.org > > Subject: RE: [16NG] Comments > > ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt > > > > > > Section 5.3 - > > > > > > > > > "When performing bridging, any packets destined for one of the > > > addresses in the Filtering Database SHALL be forwarded > > directly to > > > that port, if appropriate for the particular scenario, and all > > > packets received from a port, for which the packet's > destination > > > MAC > > > address is also an entry for that port in the > Filtering Database, > > > SHALL be silently discarded." > > > > > > > > > 2) It does not mention what happens to packets with a MAC > DA equal > > > to the MAC address of a SS. These should not be forwarded. > > > > It depends on the scenario. In case of public access scenario, the > > packets should be transmitted to AR and then relayed to the > intended > > SS by relaying function on AR. In VLAN scenario, the packets are > > directly forwarded to the intended SS by bridge. > > > For the public access case, I understand why the AR would > want to forward a packet back to another SS based on a > destination IP address. > But why would the AR forward based on a MAC DA? That MAC > address should not even have been known to the originating > SS. In fact, the AR should drop any Ethernet frame with a > unicast MAC DA that does not match the MAC address of one of > its interfaces. > > If the public access case is supposed to prevent direct > Ethernet connectivity between SSs, packets with a MAC DA = SS > MAC address should be dropped. Forwarding them to the AR is a > waste of bandwidth, since they will be dropped by the AR anyway. > > > > > > > Section 6.1 - > > > > > > "Figure 3 depicts an IEEE 802.16 network deployment > scenario without > > > direct host-to-host communication. In the general > public access > > > case, direct communication between nodes is restricted > because of > > > security and accounting issues. In this scenario, the > > bridge SHALL > > > forward all packets received from any radio side port to > > a network > > > side port. Peer-to-peer communication is not supported by the > > > bridge > > > and all packets originated from a SS should be delivered > > to an AR." > > > > > > 4) What is the behavior of the bridge in the public > access scenario > > > when the Ethernet frame arriving over the air (or from > the AR) has > > > one or more VLAN tags? Is the VLAN tag stripped off? Is > it ignored? > > > Are SSs and ARs forbidden from sending VLAN-tagged frames to the > > > bridge? > > > > Public access scenario does not consider Ethernet frames > embedded with > > VLAN tag. > > Ethernet frames with VLAN tag are handled in VLAN scenario > and we will > > provide the detail procedures in next version document. > > In the public access scenario how do you guarantee that the > terminal does not send Ethernet frames with VLAN tags? How > does the bridge react if this happens? The text should > explain how this is prevented or should explain how the > bridge deals with these packets. > > > > > > Section 7.2 - > > > > > > "The bridge SHALL support filtering of all packets received from a > > > network side port to a destination MAC address or Multicast IP > > > address not existing in the ICT or expired address." > > > > > > > > > 7) What happens if there are multiple network side ports? In that > > > case, I think you would want to filter broadcasting to the air > > > interfaces, but you will still want to broadcast on the remaining > > > network ports. > > > > Filtering in this document focuses on multicast data, and > broadcasting > > data destined for sleep mode SSs. Broadcast data for > wake-up SSs does > > not be filtered. Hosts in network side always wake up and thus > > broadcast data for the host does not need to be filtered. > > I agree. The document should make a distinction between the > different types of ports and clarify that filtering only > applies to the air ports. > > > > > > Section 7.6 - > > > > > > "The AR SHALL have packet-relay functionality. The AR > > relays packets > > > destined for IP broadcast address and link-local > scoped multicast > > > addresses to incoming interface again. When relaying, > > AR does not > > > decrease the value of TTL or Hop Limit." > > > > > > 8) Can this on-link packet-relay functionality be > performed at the > > > bridge instead of the AR? Since the bridge already has several > > > IP-snooping capabilities (ARP-proxy, ND-relay) and has > knowledge of > > > IP addresses, it seems that it could also perform this > function. In > > > this case, the AR would not require any modifications and would > > > behave like a standard AR. The bridge requires modifications > > > anyways. > > > > The position of packet-relay functionality on AR is based on the > > assumption which all traffics from SS should be transmitted > to AR in > > the public access scenario. > > > I understand that the current draft is placing the relay > functionality in the AR. My question is about the rationale > behind it. It seems that this functionality could also be > performed by the bridge. Two benefits of placing this > functionality at the bridge is that 1) it eliminates the > round-trip multicast traffic to and from the AR and 2) no > modifications are required at the AR (the AR is a standard > router). Therefore, what is the design rationale for placing > the relay functionality in the AR? _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 16 04:12:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kND-0006CW-HF; Tue, 16 Jan 2007 04:12:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kNC-0006CO-64 for 16ng@ietf.org; Tue, 16 Jan 2007 04:12:54 -0500 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6kNA-0005p8-Vz for 16ng@ietf.org; Tue, 16 Jan 2007 04:12:54 -0500 Received: by wr-out-0506.google.com with SMTP id 71so1204724wri for <16ng@ietf.org>; Tue, 16 Jan 2007 01:12:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=bbrUmCIJdgr3duQ1TptDctvkDptWmu3UAhOcqMZwz/RQ4sYLBjPpzSXUvjLD4X4p7OepLhu4JC8cao5IA7v/8WGahfIMz7r2KGtU1DWk8yIFnLAIrliH+6qgDElRmlvUvUx0NdpnNhDsRtSEOLApo8LaBlgGlxY1nqGl5qAeX+M= Received: by 10.65.154.10 with SMTP id g10mr7297230qbo.1168938772393; Tue, 16 Jan 2007 01:12:52 -0800 (PST) Received: by 10.64.204.5 with HTTP; Tue, 16 Jan 2007 01:12:52 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 18:12:52 +0900 From: "Daniel Park" To: jeonhs@etri.re.kr, "Basavaraj Patil" , jhjee@etri.re.kr MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 16ng@ietf.org Subject: [16NG] Recommending authors for change history 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 authors of the 16ng deliverables, (particularly, PS track documents) First off, thanks much for your all efforts on the 16ng deliverable. Through the 16ng mailing list, we have a number of discussion regarding them. Given the 16ng folks interest as well as comment, the quality of each document is being increased I believe. However, some folks are really hard to follow up what happened in the revision from the previous version because of lack of change log section into the document. If allowed, please attach this section to each document for folks convenience. That would be really great and helpful. My 99.9 cents. Thanks in advance. Daniel _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 16 08:29:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6oNJ-0004CP-50; Tue, 16 Jan 2007 08:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6oNI-0004AU-9P for 16ng@ietf.org; Tue, 16 Jan 2007 08:29:16 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6oK9-00075r-Lj for 16ng@ietf.org; Tue, 16 Jan 2007 08:26:02 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1168953960!8717333!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 29547 invoked from network); 16 Jan 2007 13:26:00 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-119.messagelabs.com with SMTP; 16 Jan 2007 13:26:00 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0GDQ0MA025445; Tue, 16 Jan 2007 06:26:00 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0GDPwZp009138; Tue, 16 Jan 2007 07:25:59 -0600 (CST) Message-ID: <45ACD265.2080601@motorola.com> Date: Tue, 16 Jan 2007 14:25:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> 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: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS 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 Jihoon Lee wrote: > Hi Alex, > I agree with that. I also agree, more specifically for IPv6-over-ETHCS document to not specify how to implement link-layer multicast behaviour. If the draft is separated in two separated documents IPv6-over-ETHCS and IPv4-over-ETHCS, then I will suggest the following multicast text, for the IPv6-over-ETHCS document. Do you think this text makes sense in the context of this document? Do you agree with the text or portions of it? Anything wrong with this text? Thanks, Alex > Running IPv6 over an Ethernet link needs the support of link-layer > multicast. In the 802.16 context, the Ethernet Convergence Sublayer > (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE > 802.16 Packet Convergence Sublayer) must (1) support multicast > link-layer addresses (2) map IPv6 multicast addresses to link-layer > addresses and vice-versa, (3) offer the capability of joining and > leaving IPv6 link-local multicast groups and (4) send and receive > IPv6 link-local multicast packets whose link-layer headers contain > link-layer multicast addresses. > > The following link-layer multicast addresses are recommended by > RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill]. > > The rules for mapping IPv6 link-local multicast addresses to > link-layer multicast addresses are recommended by RFCxxxx and are the > following: > > - ff02::1 maps into 33:33:00:00:00:1 > - and the others. > > The IPv6 stack must join a certain link-local IPv6 multicast group > before receiving packets addressed to that group. For example, > before receiving a Router Advertisement the stack MUST join the IPv6 > link-local multicast address 'all-nodes'. When the IPv6 stack on the > Subscriber Station joins a certain IPv6 link-local multicast group it > MUST receive all packets addressed to that group. The join operation > can happen in several ways: sending a MLD REPORT (RFCxxx), setting a > local filtering rule, etc. > > The IPv6 stack must be able to leave a certain IPv6 link-local > multicast group. When the IPv6 stack leaves a group must no longer > receive the IPv6 packets addressed to that group. Similarly to the > joining operation the leaving operation can happen in several ways: > sending a MLD REPORT, setting a local filtering rule, etc. > > The following Neighbour Discovery messages are sent by a Subscriber > Station to IPv6 link-local multicast addresses: Neighbour > Advertisement, Neighbour Solicitation, Router Solicitation (RFCxxxx). > The following Neighbour Discovery messages are received by a > Subscriber Station, addressed to IPv6 link-local multicast addresses: > Router Advertisement, Neighbour Advertisement, Neighbour > Solicitation. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 16 08:57:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ooh-0004UJ-89; Tue, 16 Jan 2007 08:57:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6oof-0004UE-HJ for 16ng@ietf.org; Tue, 16 Jan 2007 08:57:33 -0500 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ooe-00045o-9K for 16ng@ietf.org; Tue, 16 Jan 2007 08:57:33 -0500 Received: by an-out-0708.google.com with SMTP id d30so578235and for <16ng@ietf.org>; Tue, 16 Jan 2007 05:57:31 -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=Sz+v92UdayluEL4YzGWEcajX2vwnabkHWpM/P944YZ/0Sr7JXm9X5wJV30y62EkUzNK08+evd8/yfCpMZQoFni076Vim1fbF1CiNLF2JRqp4crfx/WeA6KhbrJP2DiNB0/ysaP0lUiEZfKMGffxUIyZVlnYMWwykW6X1kDUU63U= Received: by 10.65.194.13 with SMTP id w13mr7869724qbp.1168955850627; Tue, 16 Jan 2007 05:57:30 -0800 (PST) Received: by 10.64.204.5 with HTTP; Tue, 16 Jan 2007 05:57:30 -0800 (PST) Message-ID: Date: Tue, 16 Jan 2007 22:57:30 +0900 From: "Daniel Park" To: "Alexandru Petrescu" Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS In-Reply-To: <45ACD265.2080601@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Folks, > If the draft is separated in two separated documents IPv6-over-ETHCS and > IPv4-over-ETHCS, then I will suggest the following multicast text, for > the IPv6-over-ETHCS document. [chair hat-on] The thread is digressing from the point at issue. Following the 16ng charter, we will definitely work on a single EthernetCS document to be ready for publication. While chartering, we (chairs, IAB, IESG and several experts on this field) had many discussion and ended up to this conclusion. Thus, please focus on the technical aspect itself not inputing to separate it. [chair hat-off] Alex, your contribution on the current EthernetCS document would be valuable and acceptable to me. So, please do this...:-) Thanks, -- 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 Tue Jan 16 10:25:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qBK-0007uK-A0; Tue, 16 Jan 2007 10:25:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qBI-0007mo-Qj for 16ng@ietf.org; Tue, 16 Jan 2007 10:25:00 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6qBH-0000fM-Jm for 16ng@ietf.org; Tue, 16 Jan 2007 10:25:00 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1168961098!8348701!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4091 invoked from network); 16 Jan 2007 15:24:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-119.messagelabs.com with SMTP; 16 Jan 2007 15:24:58 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0GFOwLu029573; Tue, 16 Jan 2007 08:24:58 -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 l0GFOve6011405; Tue, 16 Jan 2007 09:24:58 -0600 (CST) Message-ID: <45ACEE48.6050504@motorola.com> Date: Tue, 16 Jan 2007 16:24:56 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Daniel Park Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 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 Daniel Park wrote: > Folks, > >> If the draft is separated in two separated documents >> IPv6-over-ETHCS and IPv4-over-ETHCS, then I will suggest the >> following multicast text, for the IPv6-over-ETHCS document. > > [chair hat-on] > > The thread is digressing from the point at issue. Following the 16ng > charter, we will definitely work on a single EthernetCS document to > be ready for publication. While chartering, we (chairs, IAB, IESG and > several experts on this field) had many discussion and ended up to > this conclusion. Thus, please focus on the technical aspect itself > not inputing to separate it. Dear Chair, I was not aware of the decision. > [chair hat-off] > > Alex, your contribution on the current EthernetCS document would be > valuable and acceptable to me. So, please do this...:-) Thanks, I can only submit contribution about IPv6-over-ETHCS (maybe section in the full IPv6-IPv4 document). I can not write text about IPv4-over-ETHCS for several reasons. I have implemented IPv6 not IPv4. IPv4 does not have stringent requirements with respect to the link-layer supporting multicast. IPv4 requires link-layer to be broadcast capable, not multicast. I will agree with the group's decisions. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 16 10:35:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qL6-00016A-Rj; Tue, 16 Jan 2007 10:35:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6qL1-00015f-It for 16ng@ietf.org; Tue, 16 Jan 2007 10:35:03 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6qKz-0002H4-H0 for 16ng@ietf.org; Tue, 16 Jan 2007 10:35:02 -0500 Received: by an-out-0708.google.com with SMTP id d30so608309and for <16ng@ietf.org>; Tue, 16 Jan 2007 07:35: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=PegW2iCBc6HscbPd0PFQPpQc3LqjaHWZtTfKnAtvzpcSnVMxaB59wGFYa6nVFmh1TmnPy03C0oleWjU48c/1LnWOsuASMDboaQAgvz6Iu8PIU1PknI002DCu9dKhhI4ti4c8YxgZQZrl5TmIxd5quu22zVwoP2R2ZN4OMkLoOSQ= Received: by 10.65.154.4 with SMTP id g4mr8035067qbo.1168961698289; Tue, 16 Jan 2007 07:34:58 -0800 (PST) Received: by 10.64.204.5 with HTTP; Tue, 16 Jan 2007 07:34:58 -0800 (PST) Message-ID: Date: Wed, 17 Jan 2007 00:34:58 +0900 From: "Daniel Park" To: "Alexandru Petrescu" Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS In-Reply-To: <45ACEE48.6050504@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> <45ACEE48.6050504@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 much Alex for your prompt and kind understanding. I'd recommend authors of EthernetCS document to devide technical sections into IPv4 and IPv6. Then, you who are willing to contribution IPv6 only will be able to do your work more efficient than now. Also, who are interesting in IPv4 only will be able to contribute their efforts to IPv4 section as well... Author of EthernetCS document, please take care of Alex' concern...:-) Thanks in advance, Daniel On 1/17/07, Alexandru Petrescu wrote: > Daniel Park wrote: > > Folks, > > > >> If the draft is separated in two separated documents > >> IPv6-over-ETHCS and IPv4-over-ETHCS, then I will suggest the > >> following multicast text, for the IPv6-over-ETHCS document. > > > > [chair hat-on] > > > > The thread is digressing from the point at issue. Following the 16ng > > charter, we will definitely work on a single EthernetCS document to > > be ready for publication. While chartering, we (chairs, IAB, IESG and > > several experts on this field) had many discussion and ended up to > > this conclusion. Thus, please focus on the technical aspect itself > > not inputing to separate it. > > Dear Chair, I was not aware of the decision. > > > [chair hat-off] > > > > Alex, your contribution on the current EthernetCS document would be > > valuable and acceptable to me. So, please do this...:-) > > Thanks, I can only submit contribution about IPv6-over-ETHCS (maybe > section in the full IPv6-IPv4 document). I can not write text about > IPv4-over-ETHCS for several reasons. I have implemented IPv6 not IPv4. > IPv4 does not have stringent requirements with respect to the > link-layer supporting multicast. IPv4 requires link-layer to be > broadcast capable, not multicast. > > I will agree with the group's decisions. > > Alex > -- 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 Tue Jan 16 11:41:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rMl-0001gO-UC; Tue, 16 Jan 2007 11:40:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rMk-0001gB-7v for 16ng@ietf.org; Tue, 16 Jan 2007 11:40:54 -0500 Received: from ca2-msx-c01.nw.net ([206.15.67.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6rMj-0003o3-Gv for 16ng@ietf.org; Tue, 16 Jan 2007 11:40:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [16NG] Re: multicast and IPv6 over ETHCS Date: Tue, 16 Jan 2007 08:42:43 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc5A0mht6EdKptmSVSXopqMb0eEyQAiSAkA From: "David Johnston" To: "Jihoon Lee" , "Alexandru Petrescu" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a3b79fd9d7bf2ef1762376a62c51ec4 Cc: v6ops@ops.ietf.org, 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="===============1780007102==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============1780007102== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7398D.59002992" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7398D.59002992 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't agree with that. =20 An UL Ethernet MSDU with a multicast or broadcast DA should get sent to members of the multicast group/everyone in the bridged LAN. Since 802.16 implements a point to point Ethernet similarly to modern cat 5 ethernet, then either everyone=3Dthe Ethernet termination in the BS, or it hits an 802.1D bridge in the BS and so the bridge deals with sending it to the other 802=20 LANs to which is it has bridge ports, including other SSs. =20 As I mentioned before, an 802.16 BS does not implement one network, it implements a bunch of point to point networks that may be joined by a bridge or IP routing or any other scheme that is implemented in the BS. =20 DJ =20 =20 =20 ________________________________ From: Jihoon Lee [mailto:jhlee@mmlab.snu.ac.kr]=20 Sent: Monday, January 15, 2007 4:12 PM To: Alexandru Petrescu Cc: v6ops@ops.ietf.org; 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS =20 Hi Alex, I agree with that. =20 Thanks, Jihoon =20 =20 2007/1/15, Alexandru Petrescu :=20 Hi Jihoon, Jihoon Lee wrote: > Hi Alex, > > Sorry for my late response. Basically I agree with your opinion. An=20 > IPv6 node requires a link local multicast address in order to perform > DAD, ND, and RA. > > Contrary to our expectations, 802.16/16e don't support UL multicast > (which means an MS forwards data directly to other MSs in the same=20 > cell). > > (BTW, I think I need to clarify the UL multicast I mentioned. I > believe you already know this: the multicast/broadcast which is sent > by an MS to other MSs in the same cell (BS) cannot be supported in=20 > 802.16. However, other MSs in another cell (BS) may receive this > since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH > or IP layer.) > > I agree that the document needs to specify how to deal with this=20 > problem. Yes, I think the IPv6-over-ETHCS document should make clear the assumption of IPv6 using link-layer multicast for IPv6. I don't think the IPv6-over-ETHCS document should solve the problem you mention above=20 between parenthesis (uplink mc, or mc between BSs) at link layer. The IPv6-over-ETHCS document could list the behaviour of ETHCS it expects. Ie: -when MS sends NS to a IP solicited-node multicast address the node who=20 has joined group must receive it. -when BS or AR advertises an RA to all-nodes multicast address then all SSs who have joined that group must receive it. -mapping an IPv6 link-local multicast address should happen (eg sending=20 a packet to IP dst ff02::1 should have the link-layer dst 33:33:33:0:0:0:1). The document IPv6-over-ETHCS should list what are the means for SS to _join_ a link-layer multicast group. There are few of them (send a=20 link-layer message, send a MLD message, establish a local filtering rule, always receiving all packets, etc). But I don't think the IPv6-over-ETHCS document should specify the link-layer behaviour for an implementation of ETHCS link-layer=20 multicast. Do you agree with this latter item? Alex > > Best regards, Jihoon > > > 2007/1/12, Alexandru Petrescu < alexandru.petrescu@motorola.com =20 > >: > > Hi Jihoon, thanks for reply, > > Jihoon Lee wrote: >> Hi Alex, >> >> Let me jump into discussion. 1) 802.16/16e MAC has no capability to >> do uplink multicast. In DL, 802.16 provides multicast CIDs which >> is initiated by DSA messages. In UL, however, there is no way for=20 >> an MS to access others' UL data fundamentally, in 802.16 PHY/MAC. > > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > normal) multicast then that is a big issue for IPv6-over-IPv6CS.=20 > (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't > seem to mention the word 'multicast'.)=20 > > The issue is that a SS running IPv6 needs to multicast a NA, from > time to time. For DAD it needs to send a NS to a multicast address > too. > >> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS=20 >> sends multicast data in UL, and then a bridge forwards it back).=20 >> But, there is still a difficulty in multicasting data back except >> for the source MS. > > You mean the bridge in BS? I was thinking ETHCS in SS may offer a=20 > multicast interface to the IP stack.=20 > > In both cases (bridge in BS or bridge in SS), I think it is not up to > this document to specify how the ETHCS transforms a asymmetric ul/dl > multicast feature into a symmetric one. But it should be a goal for=20 > ETHCS to offer such an interface to the IPv6 stack, otherwise the > IPv6 stack won't work. What do you think? > > Alex > > =20 ------_=_NextPart_001_01C7398D.59002992 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t agree with = that.

 

An UL Ethernet MSDU with a = multicast or broadcast DA should get sent to members of the multicast group/everyone = in the bridged LAN. Since 802.16 implements a point to point Ethernet similarly = to modern cat 5 ethernet, then either everyone=3Dthe Ethernet termination = in the BS, or it hits an 802.1D bridge in the BS and so the bridge deals with = sending it to the other 802
LANs to which is it has bridge ports, including other = SSs.

 

As I mentioned before, an 802.16 BS = does not implement one network, it implements a bunch of point to point = networks that may be joined by a bridge or IP routing or any other scheme that is = implemented in the BS.

 

DJ

 

 

 

From: = Jihoon Lee [mailto:jhlee@mmlab.snu.ac.kr]
Sent: Monday, January 15, = 2007 4:12 PM
To: Alexandru = Petrescu
Cc: v6ops@ops.ietf.org; 16ng@ietf.org
Subject: [16NG] Re: = multicast and IPv6 over ETHCS

 

Hi Alex,

I agree with that.

 

Thanks,

Jihoon

 



 

2007/1/15, Alexandru Petrescu <alexandru.petrescu@motorola.com >:

Hi Jihoon,

Jihoon Lee wrote:
> Hi Alex,
>
> Sorry for my late response. Basically I agree with your opinion. An =
> IPv6 node requires a link local multicast address in order to = perform
>  DAD, ND, and RA.
>
> Contrary to our expectations, 802.16/16e don't support UL = multicast
> (which means an MS forwards data directly to other MSs in the same =
> cell).
>
> (BTW, I think I need to clarify the UL multicast I mentioned. I
> believe you already know this: the multicast/broadcast which is = sent
> by an MS  to other MSs in the same cell (BS) cannot be = supported in
> 802.16. However, other MSs in another cell (BS) may receive = this
> since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at = ETH
> or IP layer.)
>
> I agree that the document needs to specify how to deal with this =
> problem.

Yes, I think the IPv6-over-ETHCS document should make clear the
assumption of IPv6 using link-layer multicast for IPv6.  I = don't think
the IPv6-over-ETHCS document should solve the problem you mention above =
between parenthesis (uplink mc, or mc between BSs) at link layer.

The IPv6-over-ETHCS document could list the behaviour of ETHCS it
expects.  Ie:

-when MS sends NS to a IP solicited-node multicast address the node who =
has joined group must receive it.
-when BS or AR advertises an RA to all-nodes multicast address then = all
SSs who have joined that group must receive it.
-mapping an IPv6 link-local multicast address should happen (eg sending =
a packet to IP dst ff02::1 should have the link-layer dst
33:33:33:0:0:0:1).

The document IPv6-over-ETHCS should list what are the means for SS = to
_join_ a link-layer multicast group.  There are few of them = (send a
link-layer message, send a MLD message, establish a local filtering
rule, always receiving all packets, etc).

But I don't think the IPv6-over-ETHCS document should specify the
link-layer behaviour for an implementation of ETHCS link-layer
multicast.  Do you agree with this latter item?

Alex

>
> Best regards, Jihoon
>
>
> 2007/1/12, Alexandru Petrescu < alexandru.petrescu@motorola.com
> <mailto:alexandru.petrescu@motorola.com>>:
>
> Hi Jihoon, thanks for reply,
>
> Jihoon Lee wrote:
>> Hi Alex,
>>
>> Let me jump into discussion. 1) 802.16/16e MAC has no = capability to
>>  do uplink multicast. In DL, 802.16 provides = multicast CIDs which
>> is initiated by DSA messages. In UL, however, there is no way = for
>> an MS to access others' UL data fundamentally, in 802.16 = PHY/MAC.
>
> Ok.  For one, if the 802.16MAC is not capable to do bidirectional (or
>  normal) multicast then that is a big issue for IPv6-over-IPv6CS.
> (and surprisingly, apparently the document IPv6-over-IPv6CS = doesn't
> seem to mention the word 'multicast'.)
>
> The issue is that a SS running IPv6 needs to multicast a NA, = from
> time to time.  For DAD it needs to send a NS to a = multicast address
> too.
>
>> In case of ETH over 802.16, the ETH(bridge) may cover this (an = MS
>> sends multicast data in UL, and then a bridge forwards it = back).
>> But, there is still a difficulty in multicasting data back = except
>> for the source MS.
>
> You mean the bridge in BS?  I was thinking ETHCS in SS = may offer a
> multicast interface to the IP stack.
>
> In both cases (bridge in BS or bridge in SS), I think it is not up = to
>  this document to specify how the ETHCS transforms a = asymmetric ul/dl
>  multicast feature into a symmetric one.  But = it should be a goal for
>  ETHCS to offer such an interface to the IPv6 stack, = otherwise the
> IPv6 stack won't work.  What do you think?
>
> Alex
>
>

 

------_=_NextPart_001_01C7398D.59002992-- --===============1780007102== 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 --===============1780007102==-- From 16ng-bounces@ietf.org Tue Jan 16 11:52:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rXS-0002Tb-7l; Tue, 16 Jan 2007 11:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rXQ-0002TF-4w for 16ng@ietf.org; Tue, 16 Jan 2007 11:51:56 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6rXO-0005Xl-Pw for 16ng@ietf.org; Tue, 16 Jan 2007 11:51:56 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1168966313!7259390!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 1097 invoked from network); 16 Jan 2007 16:51:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-119.messagelabs.com with SMTP; 16 Jan 2007 16:51:53 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0GGpnuF004906; Tue, 16 Jan 2007 09:51:49 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0GGpm4Y012797; Tue, 16 Jan 2007 10:51:48 -0600 (CST) Message-ID: <45AD02A3.8090407@motorola.com> Date: Tue, 16 Jan 2007 17:51:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: David Johnston Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: v6ops@ops.ietf.org, 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 David Johnston wrote: > I don’t agree with that. David, I'm trying to identify whether your disagreement matches my understanding. What don't you agree with? You don't agree that IP-over-ETHCS document should not specify how the link-layer implements link-layer multicast? In other words do you suggest that the document _should_ specify how the link-layer implements link-layer multicast? > An UL Ethernet MSDU with a multicast or broadcast DA should get sent > to members of the multicast group/everyone in the bridged LAN. Yes. Is this a problem? > Since 802.16 implements a point to point Ethernet similarly to modern > cat 5 ethernet, then either everyone=the Ethernet termination in the > BS, or it hits an 802.1D bridge in the BS and so the bridge deals > with sending it to the other 802 LANs to which is it has bridge > ports, including other SSs. I sense this is a way of implementing it. It is however a link-layer method. > As I mentioned before, an 802.16 BS does not implement one network, > it implements a bunch of point to point networks that may be joined > by a bridge or IP routing or any other scheme that is implemented in > the BS. What is that IP routing scheme that implements a link-layer? Is it MPLS? What other? Do you suggest that the draft IP-over-ETHCS recommends the 802.16 BS to implement a bunch of point to point networks joined by an IP router? I think the draft _could_ list some means by which the link-layer multicast _could_ be implemented (major use of word 'MAY') but not to make any recommendation about that. Alex > > > DJ > > > > > > > > ------------------------------------------------------------------------ > > > > > > *From:* Jihoon Lee [mailto:jhlee@mmlab.snu.ac.kr] *Sent:* Monday, > January 15, 2007 4:12 PM *To:* Alexandru Petrescu *Cc:* > v6ops@ops.ietf.org; 16ng@ietf.org *Subject:* [16NG] Re: multicast and > IPv6 over ETHCS > > > > Hi Alex, > > I agree with that. > > > > Thanks, > > Jihoon > > > > > > > > 2007/1/15, Alexandru Petrescu >: > > Hi Jihoon, > > Jihoon Lee wrote: >> Hi Alex, >> >> Sorry for my late response. Basically I agree with your opinion. An >> IPv6 node requires a link local multicast address in order to >> perform DAD, ND, and RA. >> >> Contrary to our expectations, 802.16/16e don't support UL multicast >> (which means an MS forwards data directly to other MSs in the same >> cell). >> >> (BTW, I think I need to clarify the UL multicast I mentioned. I >> believe you already know this: the multicast/broadcast which is >> sent by an MS to other MSs in the same cell (BS) cannot be >> supported in 802.16. However, other MSs in another cell (BS) may >> receive this since the 802.16 backhaul (WiMAX ASN) may >> multicast/broadcast at ETH or IP layer.) >> >> I agree that the document needs to specify how to deal with this >> problem. > > Yes, I think the IPv6-over-ETHCS document should make clear the > assumption of IPv6 using link-layer multicast for IPv6. I don't > think the IPv6-over-ETHCS document should solve the problem you > mention above between parenthesis (uplink mc, or mc between BSs) at > link layer. > > The IPv6-over-ETHCS document could list the behaviour of ETHCS it > expects. Ie: > > -when MS sends NS to a IP solicited-node multicast address the node > who has joined group must receive it. -when BS or AR advertises an RA > to all-nodes multicast address then all SSs who have joined that > group must receive it. -mapping an IPv6 link-local multicast address > should happen (eg sending a packet to IP dst ff02::1 should have the > link-layer dst 33:33:33:0:0:0:1). > > The document IPv6-over-ETHCS should list what are the means for SS to > _join_ a link-layer multicast group. There are few of them (send a > link-layer message, send a MLD message, establish a local filtering > rule, always receiving all packets, etc). > > But I don't think the IPv6-over-ETHCS document should specify the > link-layer behaviour for an implementation of ETHCS link-layer > multicast. Do you agree with this latter item? > > Alex > >> >> Best regards, Jihoon >> >> >> 2007/1/12, Alexandru Petrescu < alexandru.petrescu@motorola.com > >> >>: >> >> Hi Jihoon, thanks for reply, >> >> Jihoon Lee wrote: >>> Hi Alex, >>> >>> Let me jump into discussion. 1) 802.16/16e MAC has no capability >>> to do uplink multicast. In DL, 802.16 provides multicast CIDs >>> which is initiated by DSA messages. In UL, however, there is no >>> way for an MS to access others' UL data fundamentally, in 802.16 >>> PHY/MAC. >> >> Ok. For one, if the 802.16MAC is not capable to do bidirectional >> (or normal) multicast then that is a big issue for >> IPv6-over-IPv6CS. (and surprisingly, apparently the document >> IPv6-over-IPv6CS doesn't seem to mention the word 'multicast'.) >> >> The issue is that a SS running IPv6 needs to multicast a NA, from >> time to time. For DAD it needs to send a NS to a multicast address >> too. >> >>> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS >>> sends multicast data in UL, and then a bridge forwards it back). >>> But, there is still a difficulty in multicasting data back >>> except for the source MS. >> >> You mean the bridge in BS? I was thinking ETHCS in SS may offer a >> multicast interface to the IP stack. >> >> In both cases (bridge in BS or bridge in SS), I think it is not up >> to this document to specify how the ETHCS transforms a asymmetric >> ul/dl multicast feature into a symmetric one. But it should be a >> goal for ETHCS to offer such an interface to the IPv6 stack, >> otherwise the IPv6 stack won't work. What do you think? >> >> Alex >> >> > > > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 16 11:56:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rbW-0004de-UF; Tue, 16 Jan 2007 11:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rbV-0004cf-86 for 16ng@ietf.org; Tue, 16 Jan 2007 11:56:09 -0500 Received: from ca2-msx-c01.nw.net ([206.15.67.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6rbS-00064L-N8 for 16ng@ietf.org; Tue, 16 Jan 2007 11:56:09 -0500 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] Re: multicast and IPv6 over ETHCS Date: Tue, 16 Jan 2007 08:58:03 -0800 Message-ID: In-Reply-To: <45AD02A3.8090407@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc5jvhn4ILNDvZbTraSUlOKKEOE8gAACjjg From: "David Johnston" To: "Alexandru Petrescu" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: v6ops@ops.ietf.org, 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 I was disagreeing with the statement that 802.16e doesn't support UL multicast. It doesn't down in the depths of the 802.16 MAC, but at the MAC service it does, using the existing 802 rules of addressing, bridging and point to point LANs. I don't think it is necessary for the IETF to specify how link layer multicast is implemented, since 802 already does. DJ > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Tuesday, January 16, 2007 8:52 AM > To: David Johnston > Cc: Jihoon Lee; v6ops@ops.ietf.org; 16ng@ietf.org > Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS >=20 > David Johnston wrote: > > I don't agree with that. >=20 > David, I'm trying to identify whether your disagreement matches my > understanding. >=20 > What don't you agree with? You don't agree that IP-over-ETHCS > document should not specify how the link-layer implements link-layer > multicast? In other words do you suggest that the document _should_ > specify how the link-layer implements link-layer multicast? >=20 > > An UL Ethernet MSDU with a multicast or broadcast DA should get sent > > to members of the multicast group/everyone in the bridged LAN. >=20 > Yes. Is this a problem? >=20 > > Since 802.16 implements a point to point Ethernet similarly to modern > > cat 5 ethernet, then either everyone=3Dthe Ethernet termination in the > > BS, or it hits an 802.1D bridge in the BS and so the bridge deals > > with sending it to the other 802 LANs to which is it has bridge > > ports, including other SSs. >=20 > I sense this is a way of implementing it. It is however a link-layer > method. >=20 > > As I mentioned before, an 802.16 BS does not implement one network, > > it implements a bunch of point to point networks that may be joined > > by a bridge or IP routing or any other scheme that is implemented in > > the BS. >=20 > What is that IP routing scheme that implements a link-layer? Is it > MPLS? What other? >=20 > Do you suggest that the draft IP-over-ETHCS recommends the 802.16 BS to > implement a bunch of point to point networks joined by an IP router? >=20 > I think the draft _could_ list some means by which the link-layer > multicast _could_ be implemented (major use of word 'MAY') but not to > make any recommendation about that. >=20 > Alex >=20 > > > > > > DJ > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > *From:* Jihoon Lee [mailto:jhlee@mmlab.snu.ac.kr] *Sent:* Monday, > > January 15, 2007 4:12 PM *To:* Alexandru Petrescu *Cc:* > > v6ops@ops.ietf.org; 16ng@ietf.org *Subject:* [16NG] Re: multicast and > > IPv6 over ETHCS > > > > > > > > Hi Alex, > > > > I agree with that. > > > > > > > > Thanks, > > > > Jihoon > > > > > > > > > > > > > > > > 2007/1/15, Alexandru Petrescu > >: > > > > Hi Jihoon, > > > > Jihoon Lee wrote: > >> Hi Alex, > >> > >> Sorry for my late response. Basically I agree with your opinion. An > >> IPv6 node requires a link local multicast address in order to > >> perform DAD, ND, and RA. > >> > >> Contrary to our expectations, 802.16/16e don't support UL multicast > >> (which means an MS forwards data directly to other MSs in the same > >> cell). > >> > >> (BTW, I think I need to clarify the UL multicast I mentioned. I > >> believe you already know this: the multicast/broadcast which is > >> sent by an MS to other MSs in the same cell (BS) cannot be > >> supported in 802.16. However, other MSs in another cell (BS) may > >> receive this since the 802.16 backhaul (WiMAX ASN) may > >> multicast/broadcast at ETH or IP layer.) > >> > >> I agree that the document needs to specify how to deal with this > >> problem. > > > > Yes, I think the IPv6-over-ETHCS document should make clear the > > assumption of IPv6 using link-layer multicast for IPv6. I don't > > think the IPv6-over-ETHCS document should solve the problem you > > mention above between parenthesis (uplink mc, or mc between BSs) at > > link layer. > > > > The IPv6-over-ETHCS document could list the behaviour of ETHCS it > > expects. Ie: > > > > -when MS sends NS to a IP solicited-node multicast address the node > > who has joined group must receive it. -when BS or AR advertises an RA > > to all-nodes multicast address then all SSs who have joined that > > group must receive it. -mapping an IPv6 link-local multicast address > > should happen (eg sending a packet to IP dst ff02::1 should have the > > link-layer dst 33:33:33:0:0:0:1). > > > > The document IPv6-over-ETHCS should list what are the means for SS to > > _join_ a link-layer multicast group. There are few of them (send a > > link-layer message, send a MLD message, establish a local filtering > > rule, always receiving all packets, etc). > > > > But I don't think the IPv6-over-ETHCS document should specify the > > link-layer behaviour for an implementation of ETHCS link-layer > > multicast. Do you agree with this latter item? > > > > Alex > > > >> > >> Best regards, Jihoon > >> > >> > >> 2007/1/12, Alexandru Petrescu < alexandru.petrescu@motorola.com > > > >> > >>: > >> > >> Hi Jihoon, thanks for reply, > >> > >> Jihoon Lee wrote: > >>> Hi Alex, > >>> > >>> Let me jump into discussion. 1) 802.16/16e MAC has no capability > >>> to do uplink multicast. In DL, 802.16 provides multicast CIDs > >>> which is initiated by DSA messages. In UL, however, there is no > >>> way for an MS to access others' UL data fundamentally, in 802.16 > >>> PHY/MAC. > >> > >> Ok. For one, if the 802.16MAC is not capable to do bidirectional > >> (or normal) multicast then that is a big issue for > >> IPv6-over-IPv6CS. (and surprisingly, apparently the document > >> IPv6-over-IPv6CS doesn't seem to mention the word 'multicast'.) > >> > >> The issue is that a SS running IPv6 needs to multicast a NA, from > >> time to time. For DAD it needs to send a NS to a multicast address > >> too. > >> > >>> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS > >>> sends multicast data in UL, and then a bridge forwards it back). > >>> But, there is still a difficulty in multicasting data back > >>> except for the source MS. > >> > >> You mean the bridge in BS? I was thinking ETHCS in SS may offer a > >> multicast interface to the IP stack. > >> > >> In both cases (bridge in BS or bridge in SS), I think it is not up > >> to this document to specify how the ETHCS transforms a asymmetric > >> ul/dl multicast feature into a symmetric one. But it should be a > >> goal for ETHCS to offer such an interface to the IPv6 stack, > >> otherwise the IPv6 stack won't work. What do you think? > >> > >> Alex > >> > >> > > > > > > >=20 _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 16 12:11:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rqF-0002WI-2u; Tue, 16 Jan 2007 12:11:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6rqD-0002Vt-Bl for 16ng@ietf.org; Tue, 16 Jan 2007 12:11:21 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6rqA-0008Tx-Lw for 16ng@ietf.org; Tue, 16 Jan 2007 12:11:21 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l0GHBHu2028552; Tue, 16 Jan 2007 18:11:17 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l0GHBGOx000334; Tue, 16 Jan 2007 18:11:17 +0100 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 18:11:16 +0100 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] Re: multicast and IPv6 over ETHCS Date: Tue, 16 Jan 2007 18:11:14 +0100 Message-ID: <4BB931F00625F54DA8B8563E5A5CA25A0190CFF0@MCHP7I6A.ww002.siemens.net> In-Reply-To: <45AB7268.7020609@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc4oEIQMJuaNaO3QWq/Z+hHm3yDXAA3AVWQ From: "Riegel, Maximilian" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Jan 2007 17:11:16.0853 (UTC) FILETIME=[555CBA50:01C73991] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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, I do not agree with your proposal. It is the aim of the draft to specify the particular behavior of the link layer when forwarding IPv6 multicast messages. The IPv6 solution does not relay on the multicast implementation in the ETH link layer, but specifies what should be provided in the ETH link layer to more efficiently handle IPv6 multicast messages over IEEE802.16. Bye Max -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Monday, January 15, 2007 1:24 PM To: Jihoon Lee Cc: v6ops@ops.ietf.org; 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS Hi Jihoon, Jihoon Lee wrote: > Hi Alex, >=20 > Sorry for my late response. Basically I agree with your opinion. An=20 > IPv6 node requires a link local multicast address in order to perform > DAD, ND, and RA. >=20 > Contrary to our expectations, 802.16/16e don't support UL multicast=20 > (which means an MS forwards data directly to other MSs in the same=20 > cell). >=20 > (BTW, I think I need to clarify the UL multicast I mentioned. I=20 > believe you already know this: the multicast/broadcast which is sent=20 > by an MS to other MSs in the same cell (BS) cannot be supported in=20 > 802.16. However, other MSs in another cell (BS) may receive this=20 > since the 802.16 backhaul (WiMAX ASN) may multicast/broadcast at ETH=20 > or IP layer.) >=20 > I agree that the document needs to specify how to deal with this=20 > problem. Yes, I think the IPv6-over-ETHCS document should make clear the assumption of IPv6 using link-layer multicast for IPv6. I don't think the IPv6-over-ETHCS document should solve the problem you mention above between parenthesis (uplink mc, or mc between BSs) at link layer. The IPv6-over-ETHCS document could list the behaviour of ETHCS it expects. Ie: -when MS sends NS to a IP solicited-node multicast address the node who has joined group must receive it. -when BS or AR advertises an RA to all-nodes multicast address then all SSs who have joined that group must receive it. -mapping an IPv6 link-local multicast address should happen (eg sending a packet to IP dst ff02::1 should have the link-layer dst 33:33:33:0:0:0:1). The document IPv6-over-ETHCS should list what are the means for SS to _join_ a link-layer multicast group. There are few of them (send a link-layer message, send a MLD message, establish a local filtering rule, always receiving all packets, etc). But I don't think the IPv6-over-ETHCS document should specify the link-layer behaviour for an implementation of ETHCS link-layer multicast. Do you agree with this latter item? Alex >=20 > Best regards, Jihoon >=20 >=20 > 2007/1/12, Alexandru Petrescu >: >=20 > Hi Jihoon, thanks for reply, >=20 > Jihoon Lee wrote: >> Hi Alex, >>=20 >> Let me jump into discussion. 1) 802.16/16e MAC has no capability to >> do uplink multicast. In DL, 802.16 provides multicast CIDs which=20 >> is initiated by DSA messages. In UL, however, there is no way for=20 >> an MS to access others' UL data fundamentally, in 802.16 PHY/MAC. >=20 > Ok. For one, if the 802.16MAC is not capable to do bidirectional (or > normal) multicast then that is a big issue for IPv6-over-IPv6CS.=20 > (and surprisingly, apparently the document IPv6-over-IPv6CS doesn't=20 > seem to mention the word 'multicast'.) >=20 > The issue is that a SS running IPv6 needs to multicast a NA, from=20 > time to time. For DAD it needs to send a NS to a multicast address=20 > too. >=20 >> In case of ETH over 802.16, the ETH(bridge) may cover this (an MS=20 >> sends multicast data in UL, and then a bridge forwards it back).=20 >> But, there is still a difficulty in multicasting data back except=20 >> for the source MS. >=20 > You mean the bridge in BS? I was thinking ETHCS in SS may offer a=20 > multicast interface to the IP stack. >=20 > In both cases (bridge in BS or bridge in SS), I think it is not up to > this document to specify how the ETHCS transforms a asymmetric ul/dl > multicast feature into a symmetric one. But it should be a goal for > ETHCS to offer such an interface to the IPv6 stack, otherwise the=20 > IPv6 stack won't work. What do you think? >=20 > Alex >=20 >=20 _______________________________________________ 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 Jan 17 04:54:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77V9-0004dP-BZ; Wed, 17 Jan 2007 04:54:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77V7-0004XM-QL for 16ng@ietf.org; Wed, 17 Jan 2007 04:54:37 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H77V6-0006Fa-Dv for 16ng@ietf.org; Wed, 17 Jan 2007 04:54:37 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1169027674!12658358!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20219 invoked from network); 17 Jan 2007 09:54:34 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 17 Jan 2007 09:54:34 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0H9sUDq017522; Wed, 17 Jan 2007 02:54:30 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0H9sRdS009929; Wed, 17 Jan 2007 03:54:28 -0600 (CST) Message-ID: <45ADF252.7080001@motorola.com> Date: Wed, 17 Jan 2007 10:54:26 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Riegel, Maximilian" Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: <4BB931F00625F54DA8B8563E5A5CA25A0190CFF0@MCHP7I6A.ww002.siemens.net> In-Reply-To: <4BB931F00625F54DA8B8563E5A5CA25A0190CFF0@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: 25620135586de10c627e3628c432b04a 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 Max, Let me try to understand this. You suggest that it is the aim of the draft to specify the link layer behaviour when forwarding IPv6 multicast messages. I suggest that no link-layer behaviour should be specified, but the interface. (a distinction akin to OO programming, but may not be that obvious). I think we may be saying the same thing but with different words. So, in order to clarify whether we agree or not: do you agree with the multicast text I've sent, see below? Do you think that text has its place in the draft? Thanks, Alex Riegel, Maximilian wrote: > Hi Alex, > > I do not agree with your proposal. It is the aim of the draft to > specify the particular behavior of the link layer when forwarding > IPv6 multicast messages. > > The IPv6 solution does not relay on the multicast implementation in > the ETH link layer, but specifies what should be provided in the ETH > link layer to more efficiently handle IPv6 multicast messages over > IEEE802.16. > > Bye Max [snipping the rest of thread and inserting the multicast for IPv6 on ETHCS proposal text] > Running IPv6 over an Ethernet link needs the support of link-layer > multicast. In the 802.16 context, the Ethernet Convergence Sublayer > (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE > 802.16 Packet Convergence Sublayer) must (1) support multicast > link-layer addresses (2) map IPv6 multicast addresses to link-layer > addresses and vice-versa, (3) offer the capability of joining and > leaving IPv6 link-local multicast groups and (4) send and receive > IPv6 link-local multicast packets whose link-layer headers contain > link-layer multicast addresses. > > The following link-layer multicast addresses are recommended by > RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill]. > > The rules for mapping IPv6 link-local multicast addresses to > link-layer multicast addresses are recommended by RFCxxxx and are the > following: - ff02::1 maps into 33:33:00:00:00:1 - and the others. > > > The IPv6 stack must join a certain link-local IPv6 multicast group > before receiving packets addressed to that group. For example, before > receiving a Router Advertisement the stack MUST join the IPv6 > link-local multicast address 'all-nodes'. When the IPv6 stack on the > Subscriber Station joins a certain IPv6 link-local multicast group > it MUST receive all packets addressed to that group. The join > operation can happen in several ways: sending a MLD REPORT (RFCxxx), > setting a local filtering rule, etc. > > The IPv6 stack must be able to leave a certain IPv6 link-local > multicast group. When the IPv6 stack leaves a group must no longer > receive the IPv6 packets addressed to that group. Similarly to the > joining operation the leaving operation can happen in several ways: > sending a MLD REPORT, setting a local filtering rule, etc. > > The following Neighbour Discovery messages are sent by a Subscriber > Station to IPv6 link-local multicast addresses: Neighbour > Advertisement, Neighbour Solicitation, Router Solicitation (RFCxxxx). > The following Neighbour Discovery messages are received by a > Subscriber Station, addressed to IPv6 link-local multicast addresses: > Router Advertisement, Neighbour Advertisement, Neighbour > Solicitation. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 05:20:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77u1-0001IL-IT; Wed, 17 Jan 2007 05:20:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H77u1-0001IG-1G for 16ng@ietf.org; Wed, 17 Jan 2007 05:20:21 -0500 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H77u0-0002ID-GU for 16ng@ietf.org; Wed, 17 Jan 2007 05:20:21 -0500 Received: by nz-out-0506.google.com with SMTP id z6so449353nzd for <16ng@ietf.org>; Wed, 17 Jan 2007 02:20:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=TP6TOy5ZS9VRGmuZld7/2or23N3nMjTDfcHZ6N2nd8jZoDNfr9qYNmP2byiahvA7mPJZVvP+8eSbxbOC66ZxnMWNEcpTlfcjsm2l4ndmgpFfAddgx5NrKEUQj1j16Rcx4Zl3Sx21fwm6r2C8Xa6CWYjHyrdu1vOIhdPuiJzbArA= Received: by 10.65.219.16 with SMTP id w16mr3119027qbq.1169029219888; Wed, 17 Jan 2007 02:20:19 -0800 (PST) Received: by 10.65.225.19 with HTTP; Wed, 17 Jan 2007 02:20:19 -0800 (PST) Message-ID: Date: Wed, 17 Jan 2007 19:20:19 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45ACD265.2080601@motorola.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> X-Google-Sender-Auth: ce226fdf9d0a2f72 X-Spam-Score: 0.5 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS 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="===============1013594088==" Errors-To: 16ng-bounces@ietf.org --===============1013594088== Content-Type: multipart/alternative; boundary="----=_Part_68647_25286918.1169029219456" ------=_Part_68647_25286918.1169029219456 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, My comments are inline. Best regards, Jihoon 2007/1/16, Alexandru Petrescu : > > Jihoon Lee wrote: > > Hi Alex, > > I agree with that. > > I also agree, more specifically for IPv6-over-ETHCS document to not > specify how to implement link-layer multicast behaviour. > > If the draft is separated in two separated documents IPv6-over-ETHCS and > IPv4-over-ETHCS, then I will suggest the following multicast text, for > the IPv6-over-ETHCS document. > > Do you think this text makes sense in the context of this document? Do > you agree with the text or portions of it? Anything wrong with this text? > > Thanks, > > Alex > > > Running IPv6 over an Ethernet link needs the support of link-layer > > multicast. In the 802.16 context, the Ethernet Convergence Sublayer > > (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE > > 802.16 Packet Convergence Sublayer) must (1) support multicast > > link-layer addresses (2) map IPv6 multicast addresses to link-layer > > addresses and vice-versa, (3) offer the capability of joining and > > leaving IPv6 link-local multicast groups and (4) send and receive > > IPv6 link-local multicast packets whose link-layer headers contain > > link-layer multicast addresses. I agree with you on the clarification of the requirements/assumptions related to MS's UL multicasting. In particular, however, I think (2) and (3) above are not required in ETHCS. They should be upper layer or upper management function (that is, 802.3 bridge function) comparing to the ETHCS layer (Here I assume that ETHCS differs from 802.3 Ethernet bridge). Since ETHCS is a part of IEEE 802.16, it basically supports packet classification (matching 802.16 CID) and header suppression only, which we should not touch. Therefore, "In the 802.16 context, the Ethernet Convergence Sublayer must..." may be inappropriate. Regarding others' comments, I think you don't have to specify this on 802.16CS layer. There should be multiple choices to implement this. However, I think it's worth mentioning what (+ where) should be done. Although, the draft-ietf-16ng-ip-over-ethernet-over-802.16 says: "Multicast is not enabled in the uplink but must be realized by an entity on top the IEEE 802.16 MAC sending packets received on a unicast uplink downstream on a multicast channel.", it's too simple and general to describe uplink multicast transmission of IPv6 packets over ETHCS. For example, you may describe what should be done based on the network model: (the followings may depend on the network model which the draft refers. Assumption: IPv6 ND messages cannot be transmitted to other MSs served by the same BS without any additional supporting function. 1) 802.16 BS support a local multicast function. (How? keep this open. Where? Inside BS. maybe a function implemented over ETHCS.) This supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering them to a bridge or an AR. 2) There is a bridge between BSs and ARs. Firstly, the bridge relays (multicasts) IPv6 ND messages except for the source MS. Then, it delivers to AR. (How? keep this open. Where? bridge and AR in case of utilizing VLAN ). 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND messages to other MSs except for the source MS. (How? keep this open. Where? AR). 4) ... I could not find any flaw in the following text. But, I'm not sure there is another message in IPv6 which is not mentioned in the last paragraph. > > > The following link-layer multicast addresses are recommended by > > RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill]. > > > > The rules for mapping IPv6 link-local multicast addresses to > > link-layer multicast addresses are recommended by RFCxxxx and are the > > following: > > > > - ff02::1 maps into 33:33:00:00:00:1 > > - and the others. > > > > > The IPv6 stack must join a certain link-local IPv6 multicast group > > before receiving packets addressed to that group. For example, > > before receiving a Router Advertisement the stack MUST join the IPv6 > > link-local multicast address 'all-nodes'. When the IPv6 stack on the > > Subscriber Station joins a certain IPv6 link-local multicast group it > > MUST receive all packets addressed to that group. The join operation > > can happen in several ways: sending a MLD REPORT (RFCxxx), setting a > > local filtering rule, etc. > > > > The IPv6 stack must be able to leave a certain IPv6 link-local > > multicast group. When the IPv6 stack leaves a group must no longer > > receive the IPv6 packets addressed to that group. Similarly to the > > joining operation the leaving operation can happen in several ways: > > sending a MLD REPORT, setting a local filtering rule, etc. > > > > The following Neighbour Discovery messages are sent by a Subscriber > > Station to IPv6 link-local multicast addresses: Neighbour > > Advertisement, Neighbour Solicitation, Router Solicitation (RFCxxxx). > > The following Neighbour Discovery messages are received by a > > Subscriber Station, addressed to IPv6 link-local multicast addresses: > > Router Advertisement, Neighbour Advertisement, Neighbour > > Solicitation. > ------=_Part_68647_25286918.1169029219456 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
My comments are inline.

Best regards,
Jihoon
 
2007/1/16, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Jihoon Lee wrote:
> Hi Alex,
> I agree with that.

I also agree, more specifically for IPv6-over-ETHCS document to not
specify how to implement link-layer multicast behaviour.

If the draft is separated in two separated documents IPv6-over-ETHCS and
IPv4-over-ETHCS, then I will suggest the following multicast text, for
the IPv6-over-ETHCS document.

Do you think this text makes sense in the context of this document?  Do
you agree with the text or portions of it?  Anything wrong with this text?

Thanks,

Alex

> Running IPv6 over an Ethernet link needs the support of link-layer
> multicast.  In the 802.16 context, the Ethernet Convergence Sublayer
> (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE
> 802.16 Packet Convergence Sublayer) must (1) support multicast
> link-layer addresses (2) map IPv6 multicast addresses to link-layer
> addresses and vice-versa, (3) offer the capability of joining and
> leaving IPv6 link-local multicast groups and (4) send and receive
> IPv6 link-local multicast packets whose link-layer headers contain
> link-layer multicast addresses.
 
I agree with you on the clarification of the requirements/assumptions related to MS's UL multicasting.
 
In particular, however,  I think (2) and (3) above are not required in ETHCS. They should be upper layer or upper management function (that is, 802.3 bridge function) comparing to the ETHCS layer (Here I assume that ETHCS differs from 802.3 Ethernet bridge). Since ETHCS is a part of IEEE 802.16, it basically supports packet classification (matching 802.16 CID) and header suppression only, which we should not touch. Therefore, "In the 802.16 context, the Ethernet Convergence Sublayer must..."  may be inappropriate.
 
Regarding others' comments, I think you don't have to specify this on 802.16 CS layer. There should be multiple choices to implement this. However, I think it's worth mentioning what (+ where) should be done. Although, the draft-ietf-16ng-ip-over-ethernet-over-802.16 says: "Multicast is not enabled in the uplink but must be realized by an entity on top the IEEE 802.16 MAC sending packets received on a unicast uplink downstream on a multicast channel.", it's too simple and general to describe uplink multicast transmission of IPv6 packets over ETHCS.
 
For example, you may describe what should be done based on the network model:
(the followings may depend on the network model which the draft refers.
 
Assumption: IPv6 ND messages cannot be transmitted to other MSs served by the same BS without any additional supporting function.
 
1) 802.16 BS support a local multicast function. (How? keep this open. Where? Inside BS. maybe a function implemented over ETHCS.) This supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering them to a bridge or an AR.
2) There is a bridge between BSs and ARs. Firstly, the bridge relays (multicasts) IPv6 ND messages except for the source MS. Then, it delivers to AR. (How? keep this open. Where? bridge and AR in case of utilizing VLAN ).
3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND messages to other MSs except for the source MS. (How? keep this open. Where? AR).
4) ...
 
I could not find any flaw in the following text. But, I'm not sure there is another message in IPv6 which is not mentioned in the last paragraph.
 

>
> The following link-layer multicast addresses are recommended by
> RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill].
>
> The rules for mapping IPv6 link-local multicast addresses to
> link-layer multicast addresses are recommended by RFCxxxx and are the
> following:
>
>     - ff02::1 maps into 33:33:00:00:00:1
>     - and the others.
>

> The IPv6 stack must join a certain link-local IPv6 multicast group
> before receiving packets addressed to that group.  For example,
> before receiving a Router Advertisement the stack MUST join the IPv6
> link-local multicast address 'all-nodes'.  When the IPv6 stack on the
> Subscriber Station joins a certain IPv6 link-local multicast group it
> MUST receive all packets addressed to that group.  The join operation
> can happen in several ways: sending a MLD REPORT (RFCxxx), setting a
> local filtering rule, etc.
>
> The IPv6 stack must be able to leave a certain IPv6 link-local
> multicast group.  When the IPv6 stack leaves a group must no longer
> receive the IPv6 packets addressed to that group.  Similarly to the
> joining operation the leaving operation can happen in several ways:
> sending a MLD REPORT, setting a local filtering rule, etc.
>
> The following Neighbour Discovery messages are sent by a Subscriber
> Station to IPv6 link-local multicast addresses: Neighbour
> Advertisement, Neighbour Solicitation, Router Solicitation (RFCxxxx).
> The following Neighbour Discovery messages are received by a
> Subscriber Station, addressed to IPv6 link-local multicast addresses:
> Router Advertisement, Neighbour Advertisement, Neighbour
> Solicitation.

------=_Part_68647_25286918.1169029219456-- --===============1013594088== 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 --===============1013594088==-- From 16ng-bounces@ietf.org Wed Jan 17 06:00:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78Wb-00050A-JP; Wed, 17 Jan 2007 06:00:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H78Wa-000504-DU for 16ng@ietf.org; Wed, 17 Jan 2007 06:00:12 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H78WY-0002tX-Tw for 16ng@ietf.org; Wed, 17 Jan 2007 06:00:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1169031609!13285356!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 23360 invoked from network); 17 Jan 2007 11:00:09 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-13.tower-128.messagelabs.com with SMTP; 17 Jan 2007 11:00:09 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0HB09QJ004320; Wed, 17 Jan 2007 04:00:09 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0HB07m8003967; Wed, 17 Jan 2007 05:00:08 -0600 (CST) Message-ID: <45AE01AF.7070104@motorola.com> Date: Wed, 17 Jan 2007 11:59:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> 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: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: 16ng@ietf.org Subject: [16NG] Re: multicast and IPv6 over ETHCS 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 Jihoon, thanks for your comments. Jihoon Lee wrote: > 2007/1/16, Alexandru Petrescu >: > > Running IPv6 over an Ethernet link needs the support of link-layer > > multicast. In the 802.16 context, the Ethernet Convergence Sublayer > > (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE > > 802.16 Packet Convergence Sublayer) must (1) support multicast > > link-layer addresses (2) map IPv6 multicast addresses to link-layer > > addresses and vice-versa, (3) offer the capability of joining and > > leaving IPv6 link-local multicast groups and (4) send and receive > > IPv6 link-local multicast packets whose link-layer headers contain > > link-layer multicast addresses. > > > I agree with you on the clarification of the requirements/assumptions > related to MS's UL multicasting. > > In particular, however, I think (2) and (3) above are not required in > ETHCS. They should be upper layer or upper management function (that is, > 802.3 bridge function) comparing to the ETHCS layer (Here I assume that > ETHCS differs from 802.3 Ethernet bridge). Since ETHCS is a part of IEEE > 802.16, it basically supports packet classification (matching 802.16 > CID) and header suppression only, which we should not touch. Therefore, > "In the 802.16 context, the Ethernet Convergence Sublayer must..." may > be inappropriate. I think (2) wasn't clear. I think mapping between link-layer multicast addresses and IPv6 link-local addresses is mainly done by the IPv6 stack, not by the link layer. That mapping should happen, because it's the IPv6 stack building the MAC headers. I think I can rewrite that to say that the IPv6 stack does the mapping, would this be ok? I agree we should not touch ETHCS packet classiffication. But I think (3 - offer the capability of joining and leaving IPv6 link-local multicast addresses) is in the scope below the IPv6 stack. > Regarding others' comments, I think you don't have to specify this on > 802.16 CS layer. There should be multiple choices to implement this. > However, I think it's worth mentioning what (+ where) should be done. Maybe. But if it's done, these methods should be 'MAY' and in Appendix I believe. > Although, the draft-ietf-16ng-ip-over-ethernet-over-802.16 says: > "Multicast is not enabled in the uplink but must be realized by an > entity on top the IEEE 802.16 MAC sending packets received on a unicast > uplink downstream on a multicast channel.", it's too simple and > general to describe uplink multicast transmission of IPv6 packets over > ETHCS. I agree it's too simple, and doesn't cover all that 802.16 MACs can do. > For example, you may describe what should be done based on the network > model: > (the followings may depend on the network model which the draft refers. > > Assumption: IPv6 ND messages cannot be transmitted to other MSs served > by the same BS without any additional supporting function. > > 1) 802.16 BS support a local multicast function. (How? keep this open. > Where? Inside BS. maybe a function implemented over ETHCS.) This > supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering > them to a bridge or an AR. > 2) There is a bridge between BSs and ARs. Firstly, the bridge relays > (multicasts) IPv6 ND messages except for the source MS. > Then, it delivers to AR. (How? keep this open. Where? bridge and AR in > case of utilizing VLAN ). > 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND > messages to other MSs except for the source MS. (How? keep this > open. Where? AR). > 4) ... Sounds as a good plan, as an example of implementing link-layer multicast. But I strongly suggest it to contain 'MAY' statements everywhere and have it entirely in appendix, as an example of potential implementation of link-layer multicast. This is very good for easing readers and understand what the authors tried to say. > I could not find any flaw in the following text. But, I'm not sure there > is another message in IPv6 which is not mentioned in the last paragraph. You're right. There are at least DHCP Discovers that are sent to link-local multicast addresses (and thus link-layer multicast addresses). There may be many others I don't know, or currently under development in other WGs. I could reformulate to be clear that that list is not exhaustive. But I would like to get first clear agreement from draft's authors whether it makes sense to include this text, and where in the draft. Once I know that I can finely tune it better to WG members' acceptance. Alex > > > > > > The following link-layer multicast addresses are recommended by > > RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill]. > > > > The rules for mapping IPv6 link-local multicast addresses to > > link-layer multicast addresses are recommended by RFCxxxx and are the > > following: > > > > - ff02::1 maps into 33:33:00:00:00:1 > > - and the others. > > > > > The IPv6 stack must join a certain link-local IPv6 multicast group > > before receiving packets addressed to that group. For example, > > before receiving a Router Advertisement the stack MUST join the IPv6 > > link-local multicast address 'all-nodes'. When the IPv6 stack on the > > Subscriber Station joins a certain IPv6 link-local multicast group it > > MUST receive all packets addressed to that group. The join > operation > > can happen in several ways: sending a MLD REPORT (RFCxxx), setting a > > local filtering rule, etc. > > > > The IPv6 stack must be able to leave a certain IPv6 link-local > > multicast group. When the IPv6 stack leaves a group must no longer > > receive the IPv6 packets addressed to that group. Similarly to the > > joining operation the leaving operation can happen in several ways: > > sending a MLD REPORT, setting a local filtering rule, etc. > > > > The following Neighbour Discovery messages are sent by a Subscriber > > Station to IPv6 link-local multicast addresses: Neighbour > > Advertisement, Neighbour Solicitation, Router Solicitation > (RFCxxxx). > > The following Neighbour Discovery messages are received by a > > Subscriber Station, addressed to IPv6 link-local multicast addresses: > > Router Advertisement, Neighbour Advertisement, Neighbour > > Solicitation. > > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 08:44:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7B5Y-0005CU-Tm; Wed, 17 Jan 2007 08:44:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7B5X-0005CO-IG for 16ng@ietf.org; Wed, 17 Jan 2007 08:44:27 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7B5V-0001Dp-Vb for 16ng@ietf.org; Wed, 17 Jan 2007 08:44:27 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id l0HDiPtl018615; Wed, 17 Jan 2007 14:44:25 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l0HDiObd009017; Wed, 17 Jan 2007 14:44:25 +0100 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 14:44:24 +0100 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] Re: multicast and IPv6 over ETHCS Date: Wed, 17 Jan 2007 14:44:24 +0100 Message-ID: <4BB931F00625F54DA8B8563E5A5CA25A013471A9@MCHP7I6A.ww002.siemens.net> In-Reply-To: <45ADF252.7080001@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc6HvKuqKPAqn8ZTTGTFvTp6xLqGAAG1vAg From: "Riegel, Maximilian" To: "Alexandru Petrescu" X-OriginalArrivalTime: 17 Jan 2007 13:44:24.0762 (UTC) FILETIME=[9997B1A0:01C73A3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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, Your text on the behavior of the IPv6 stack on handling multicast looks like standard IPv6 behavior. If this is true, than your text may be added for informational purposes but do not add anything to the normative part of the specification. If your text is defining special IPv6 behavior, i.e. changing standard IPv6 behavior, then it is not acceptable for the IPoETH-CS solution. The IPoETH solution does not allow any change to the standard behavior of the IP stack, when sending IP packets over Ethernet, but implements IP specific extensions in the Ethernet layer to make the transmission of IP over Ethernet more 'wireless friendly'. RFC4541 is an example of such an extension to the Ethernet layer. There is a real-world reason behind: an IP host may be connected by an Ethernet cable to an IEEE802.16 bridge device. The host does not have any awareness that its IP over Ethernet packets are transferred over an IEEE802.16 radio link. All the IP specific optimization must take place in the Ethernet layer over IEEE802.16. Bye Max BTW: Link layer multicast is not provided by the Ethernet Convergence Layer but by a bridge device in the system deploying the ETH-CS for transmitting Ethernet frames over IEEE802.16. -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Wednesday, January 17, 2007 10:54 AM To: Riegel, Maximilian Cc: 16ng@ietf.org; Jihoon Lee Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS Hi Max, Let me try to understand this. You suggest that it is the aim of the draft to specify the link layer behaviour when forwarding IPv6 multicast messages. I suggest that no link-layer behaviour should be specified, but the interface. (a distinction akin to OO programming, but may not be that obvious). I think we may be saying the same thing but with different words. So, in order to clarify whether we agree or not: do you agree with the multicast text I've sent, see below? Do you think that text has its place in the draft? Thanks, Alex Riegel, Maximilian wrote: > Hi Alex, >=20 > I do not agree with your proposal. It is the aim of the draft to=20 > specify the particular behavior of the link layer when forwarding=20 > IPv6 multicast messages. >=20 > The IPv6 solution does not relay on the multicast implementation in=20 > the ETH link layer, but specifies what should be provided in the ETH=20 > link layer to more efficiently handle IPv6 multicast messages over=20 > IEEE802.16. >=20 > Bye Max [snipping the rest of thread and inserting the multicast for IPv6 on ETHCS proposal text] > Running IPv6 over an Ethernet link needs the support of link-layer=20 > multicast. In the 802.16 context, the Ethernet Convergence Sublayer=20 > (also known as the IEEE Std 802.3/Ethernet-specific part of the IEEE > 802.16 Packet Convergence Sublayer) must (1) support multicast=20 > link-layer addresses (2) map IPv6 multicast addresses to link-layer=20 > addresses and vice-versa, (3) offer the capability of joining and=20 > leaving IPv6 link-local multicast groups and (4) send and receive=20 > IPv6 link-local multicast packets whose link-layer headers contain=20 > link-layer multicast addresses. >=20 > The following link-layer multicast addresses are recommended by=20 > RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill]. >=20 > The rules for mapping IPv6 link-local multicast addresses to=20 > link-layer multicast addresses are recommended by RFCxxxx and are the > following: - ff02::1 maps into 33:33:00:00:00:1 - and the others. >=20 >=20 > The IPv6 stack must join a certain link-local IPv6 multicast group=20 > before receiving packets addressed to that group. For example, before > receiving a Router Advertisement the stack MUST join the IPv6=20 > link-local multicast address 'all-nodes'. When the IPv6 stack on the > Subscriber Station joins a certain IPv6 link-local multicast group > it MUST receive all packets addressed to that group. The join > operation can happen in several ways: sending a MLD REPORT (RFCxxx), > setting a local filtering rule, etc. >=20 > The IPv6 stack must be able to leave a certain IPv6 link-local=20 > multicast group. When the IPv6 stack leaves a group must no longer=20 > receive the IPv6 packets addressed to that group. Similarly to the=20 > joining operation the leaving operation can happen in several ways:=20 > sending a MLD REPORT, setting a local filtering rule, etc. >=20 > The following Neighbour Discovery messages are sent by a Subscriber=20 > Station to IPv6 link-local multicast addresses: Neighbour=20 > Advertisement, Neighbour Solicitation, Router Solicitation (RFCxxxx). > The following Neighbour Discovery messages are received by a=20 > Subscriber Station, addressed to IPv6 link-local multicast addresses: > Router Advertisement, Neighbour Advertisement, Neighbour=20 > Solicitation. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 10:56:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7D9D-0001By-5f; Wed, 17 Jan 2007 10:56:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7D9B-00019o-0g for 16ng@ietf.org; Wed, 17 Jan 2007 10:56:21 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7D98-0003DP-Nk for 16ng@ietf.org; Wed, 17 Jan 2007 10:56:20 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1169049377!9476043!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 2674 invoked from network); 17 Jan 2007 15:56:17 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-6.tower-119.messagelabs.com with SMTP; 17 Jan 2007 15:56:17 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0HFuG41029554; Wed, 17 Jan 2007 08:56:16 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0HFuD8b027128; Wed, 17 Jan 2007 09:56:14 -0600 (CST) Message-ID: <45AE471D.9090205@motorola.com> Date: Wed, 17 Jan 2007 16:56:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Riegel, Maximilian" Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: <4BB931F00625F54DA8B8563E5A5CA25A013471A9@MCHP7I6A.ww002.siemens.net> In-Reply-To: <4BB931F00625F54DA8B8563E5A5CA25A013471A9@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: 10d3e4e3c32e363f129e380e644649be 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 Max, thanks for your comments. It seems our disagreement is larger than I thought :-) In another mail I've tried to suggest that there is value in text that doesn't specify new behaviour (ie IPv6 runs over ETHCS as usual, no new behaviour) while you think that a new behaviour should be specified (albeit link-layer). I think there are other people on the list who agree that this document should not specify link-layer behaviour. Riegel, Maximilian wrote: > Hi Alex, > > Your text on the behavior of the IPv6 stack on handling multicast > looks like standard IPv6 behavior. Yes, it is standard behaviour of IPv6 stack over a link-layer multicast capable link, nothing new, that's the intention. > If this is true, than your text may be added for informational > purposes but do not add anything to the normative part of the > specification. Well if it's standard behaviour then it can't be informational, right? It should be formulated such as to not tresspass the main documents specifying this (2464, 2461, dhcp, etc) and to _recommend_ them - I agree. > If your text is defining special IPv6 behavior, i.e. changing > standard IPv6 behavior, then it is not acceptable for the IPoETH-CS > solution. I agree if it were so. But no the text doesn't change standard IPv6 behaviour, far from my intention. At some point it gets a little more than standard behaviour: it requires the SS to put link-layer multicast addresses in the link-layer header, something that current RFCs don't require, but implementations do. If you need, I can change that formulation to not tresspass at all, ie to say that implementations MAY use link-layer multicast addresses in link-layer header fields. Do you want me to do that? > The IPoETH solution does not allow any change to the standard > behavior of the IP stack, when sending IP packets over Ethernet, but > implements IP specific extensions in the Ethernet layer to make the > transmission of IP over Ethernet more 'wireless friendly'. I think this Proposed Standards document is not the place to specify link-layer behaviour. > RFC4541 is an example of such an extension to the Ethernet layer. YEs, and it's INFORMATIONAL at IETF. Do you think this IPv6-over-ETHCS document should be INFORMATIONAL? > There is a real-world reason behind: an IP host may be connected by > an Ethernet cable to an IEEE802.16 bridge device. The host does not > have any awareness that its IP over Ethernet packets are transferred > over an IEEE802.16 radio link. All the IP specific optimization must > take place in the Ethernet layer over IEEE802.16. Sounds reasonable to me. But how that happens shouldn't be specified here. > Bye Max BTW: Link layer multicast is not provided by the Ethernet > Convergence Layer but by a bridge device in the system deploying the > ETH-CS for transmitting Ethernet frames over IEEE802.16. Thanks for this clarification. So one is tempted to call the document "IP over bridge device in the system deploying the ETH-CS for transmitting Ethernet frames over IEEE 802.16". A terminology issue. I can re-formulate the multicast phrases in my text to say the the link-layer multicast goals MAY be implemented by the bridge device in the system deploying the ETH-CS for transmitting Ethernet frames over IEEE 802.16. Do you agree that I re-formulate it that way? Do you or co-authors accept to introduce my text in the draft? If yes - where? I'm not pushing to do it now - please take the time - but if you or co-authors do, and when you do, please let me know. Once I know we have agreement to include the multicast text in the draft I can modify it according to all suggestions raised on the list. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 11:04:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DGV-0004T2-Kg; Wed, 17 Jan 2007 11:03:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7DGQ-0004Qu-JC for 16ng@ietf.org; Wed, 17 Jan 2007 11:03:51 -0500 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7DGO-0004kX-SC for 16ng@ietf.org; Wed, 17 Jan 2007 11:03:50 -0500 Received: (qmail 14173 invoked by uid 60001); 17 Jan 2007 16:03:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=5DTFTvJP9Uu2761sMj2AU3jXgBCzMhxI/Kv24PlMsjr/lmjMi82CVt8H3Jtd4PrfrAvc1pDbwqWS7nge9bfo6NCdhCRAiA3KKWrjIhB0edGz6CdAqIbuNoOrHu2qi3tQKni8gEDd4lFic5v7EsmvFi+dmZeSn4RjDSgknsL8YYc= ; Message-ID: <20070117160348.14171.qmail@web81913.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81913.mail.mud.yahoo.com via HTTP; Wed, 17 Jan 2007 08:03:48 PST Date: Wed, 17 Jan 2007 08:03:47 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS To: "Riegel, Maximilian" , Alexandru Petrescu MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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="===============1184730027==" Errors-To: 16ng-bounces@ietf.org --===============1184730027== Content-Type: multipart/alternative; boundary="0-1974012021-1169049827=:13715" --0-1974012021-1169049827=:13715 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable =0AI'd suggest less rather than more text. If it's standard behavior=0A(as = suggested by Max), rather than describing it again and risking getting it w= rong (even=0Ainformatively), I think it's better to just refer to the prope= r=0Asources (and sections within them if need be). The whole point of ETH C= S is that=0Athe data path should look very similar to most (switched) ether= net nowadays=0A("point-to-point LAN" as per section 6.5.1--Support by IEEE = Std 802.3--of IEEE 802.1D-2004). =0A=0AThe problem of limiting potential fl= ooding at the link-layer is not new and=0Awe can just point at section 2.7 = of=0Ahttp://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.t= xt=0Afor existing procedures.=0A=0ANow, if there's anything normative that = needs to change, Alex, please point=0Athat out. =0A=0A-gabriel=0A=0A----- O= riginal Message ----=0AFrom: "Riegel, Maximilian" =0ATo: Alexandru Petrescu =0ACc: 16n= g@ietf.org=0ASent: Wednesday, January 17, 2007 5:44:24 AM=0ASubject: RE: [1= 6NG] Re: multicast and IPv6 over ETHCS=0A=0AHi Alex,=0A=0AYour text on the = behavior of the IPv6 stack on handling multicast looks=0Alike standard IPv6= behavior. If this is true, than your text may be=0Aadded for informational= purposes but do not add anything to the=0Anormative part of the specificat= ion.=0A=0AIf your text is defining special IPv6 behavior, i.e. changing sta= ndard=0AIPv6 behavior, then it is not acceptable for the IPoETH-CS solution= .=0A=0AThe IPoETH solution does not allow any change to the standard behavi= or=0Aof the IP stack, when sending IP packets over Ethernet, but implements= =0AIP specific extensions in the Ethernet layer to make the transmission of= =0AIP over Ethernet more 'wireless friendly'. RFC4541 is an example of such= =0Aan extension to the Ethernet layer.=0AThere is a real-world reason behin= d: an IP host may be connected by an=0AEthernet cable to an IEEE802.16 brid= ge device. The host does not have=0Aany awareness that its IP over Ethernet= packets are transferred over an=0AIEEE802.16 radio link. All the IP specif= ic optimization must take place=0Ain the Ethernet layer over IEEE802.16.=0A= =0ABye=0AMax=0ABTW: Link layer multicast is not provided by the Ethernet Co= nvergence=0ALayer but by a bridge device in the system deploying the ETH-CS= for=0Atransmitting Ethernet frames over IEEE802.16.=0A=0A-----Original Mes= sage-----=0AFrom: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.co= m] =0ASent: Wednesday, January 17, 2007 10:54 AM=0ATo: Riegel, Maximilian= =0ACc: 16ng@ietf.org; Jihoon Lee=0ASubject: Re: [16NG] Re: multicast and IP= v6 over ETHCS=0A=0AHi Max,=0A=0ALet me try to understand this. You suggest= that it is the aim of the=0Adraft to specify the link layer behaviour when= forwarding IPv6 multicast=0Amessages. I suggest that no link-layer behavi= our should be specified,=0Abut the interface. (a distinction akin to OO pr= ogramming, but=0Amay not be that obvious). I think we may be saying the s= ame thing but=0Awith different words.=0A=0ASo, in order to clarify whether = we agree or not: do you agree with the=0Amulticast text I've sent, see belo= w? Do you think that text has its=0Aplace in the draft?=0A=0AThanks,=0A= =0AAlex=0A=0ARiegel, Maximilian wrote:=0A> Hi Alex,=0A> =0A> I do not agree= with your proposal. It is the aim of the draft to =0A> specify the particu= lar behavior of the link layer when forwarding =0A> IPv6 multicast messages= .=0A> =0A> The IPv6 solution does not relay on the multicast implementation= in =0A> the ETH link layer, but specifies what should be provided in the E= TH =0A> link layer to more efficiently handle IPv6 multicast messages over = =0A> IEEE802.16.=0A> =0A> Bye Max=0A=0A[snipping the rest of thread and ins= erting the multicast for IPv6 on=0A ETHCS proposal text]=0A=0A> Running IP= v6 over an Ethernet link needs the support of link-layer =0A> multicast. In= the 802.16 context, the Ethernet Convergence Sublayer =0A> (also known as = the IEEE Std 802.3/Ethernet-specific part of the IEEE=0A> 802.16 Packet Co= nvergence Sublayer) must (1) support multicast =0A> link-layer addresses (2= ) map IPv6 multicast addresses to link-layer =0A> addresses and vice-versa,= (3) offer the capability of joining and =0A> leaving IPv6 link-local multi= cast groups and (4) send and receive =0A> IPv6 link-local multicast packets= whose link-layer headers contain =0A> link-layer multicast addresses.=0A> = =0A> The following link-layer multicast addresses are recommended by =0A> R= FCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [fill].=0A> =0A> Th= e rules for mapping IPv6 link-local multicast addresses to =0A> link-layer = multicast addresses are recommended by RFCxxxx and are the=0A> following: = - ff02::1 maps into 33:33:00:00:00:1 - and the others.=0A> =0A> =0A> The IP= v6 stack must join a certain link-local IPv6 multicast group =0A> before re= ceiving packets addressed to that group. For example, before=0A> receiving= a Router Advertisement the stack MUST join the IPv6 =0A> link-local multic= ast address 'all-nodes'. When the IPv6 stack on the=0A> Subscriber Station= joins a certain IPv6 link-local multicast group=0A> it MUST receive all pa= ckets addressed to that group. The join=0A> operation can happen in several= ways: sending a MLD REPORT (RFCxxx),=0A> setting a local filtering rule, e= tc.=0A> =0A> The IPv6 stack must be able to leave a certain IPv6 link-local= =0A> multicast group. When the IPv6 stack leaves a group must no longer = =0A> receive the IPv6 packets addressed to that group. Similarly to the =0A= > joining operation the leaving operation can happen in several ways: =0A> = sending a MLD REPORT, setting a local filtering rule, etc.=0A> =0A> The fol= lowing Neighbour Discovery messages are sent by a Subscriber =0A> Station t= o IPv6 link-local multicast addresses: Neighbour =0A> Advertisement, Neighb= our Solicitation, Router Solicitation (RFCxxxx).=0A> The following Neighbo= ur Discovery messages are received by a =0A> Subscriber Station, addressed = to IPv6 link-local multicast addresses:=0A> Router Advertisement, Neighbou= r Advertisement, Neighbour =0A> Solicitation.=0A=0A________________________= _______________________=0A16NG mailing list=0A16NG@ietf.org=0Ahttps://www1.= ietf.org/mailman/listinfo/16ng=0A=0A=0A=0A=0A --0-1974012021-1169049827=:13715 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable

I'd suggest less rather than more text. If it's s= tandard behavior
(as suggested by Max), rather than describing it again = and risking getting it wrong (even
informatively), I think it's better t= o just refer to the proper
sources (and sections within them if need be)= . The whole point of ETH CS is that
the data path should look very simil= ar to most (switched) ethernet nowadays
("point-to-point LAN" as per sec= tion 6.5.1--Support by IEEE Std 802.3--of IEEE 802.1D-2004).

The pr= oblem of limiting potential flooding at the link-layer is not new and
we= can just point at section 2.7 of
http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-0= 7.txt
for existing procedures.

Now, if there's anythin= g normative that needs to change, Alex, please point
that out.

-= gabriel

----- Original Message ----
From: "Riegel, Maximi= lian" <maximilian.riegel@siemens.com>
To: Alexandru Petrescu <a= lexandru.petrescu@motorola.com>
Cc: 16ng@ietf.org
Sent: Wednesday,= January 17, 2007 5:44:24 AM
Subject: RE: [16NG] Re: multicast and IPv6 = over ETHCS

Hi Alex,

Your text on the behavior of the IPv= 6 stack on handling multicast looks
like standard IPv6 behavior. If this= is true, than your text may be
added for informational purposes but do = not add anything to the
normative part of the specification.

If y= our text is defining special IPv6 behavior, i.e. changing standard
IPv6 behavior, t= hen it is not acceptable for the IPoETH-CS solution.

The IPoETH solu= tion does not allow any change to the standard behavior
of the IP stack,= when sending IP packets over Ethernet, but implements
IP specific exten= sions in the Ethernet layer to make the transmission of
IP over Ethernet= more 'wireless friendly'. RFC4541 is an example of such
an extension to= the Ethernet layer.
There is a real-world reason behind: an IP host may= be connected by an
Ethernet cable to an IEEE802.16 bridge device. The h= ost does not have
any awareness that its IP over Ethernet packets are tr= ansferred over an
IEEE802.16 radio link. All the IP specific optimizatio= n must take place
in the Ethernet layer over IEEE802.16.

Bye
M= ax
BTW: Link layer multicast is not provided by the Ethernet Convergence=
Layer but by a bridge device in the system deploying the ETH-CS for
= transmitting Ethernet frames over IEEE802.16.

-----Original Message-----
From= : Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]
Sent: Wed= nesday, January 17, 2007 10:54 AM
To: Riegel, Maximilian
Cc: 16ng@iet= f.org; Jihoon Lee
Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS<= br>
Hi Max,

Let me try to understand this.  You suggest= that it is the aim of the
draft to specify the link layer behaviour whe= n forwarding IPv6 multicast
messages.  I suggest that no link-= layer behaviour should be specified,
but the interface.  (a di= stinction akin to OO programming, but
may not be that obvious). &nb= sp;I think we  may be saying the same thing but
with different= words.

So, in order to clarify whether we agree or not: do you agre= e with the
multicast text I've sent, see below?   Do you think= that text has its
place in the draft?

Thanks,

Alex
Riegel, Maximilian wrote:
> Hi Alex,
>
> I do not agree with yo= ur proposal. It is the aim of the draft to
> specify the particular = behavior of the link layer when forwarding
> IPv6 multicast messages= .
>
> The IPv6 solution does not relay on the multicast implem= entation in
> the ETH link layer, but specifies what should be provi= ded in the ETH
> link layer to more efficiently handle IPv6 multicas= t messages over
> IEEE802.16.
>
> Bye Max

[snipp= ing the rest of thread and inserting the multicast for IPv6 on
 &nb= sp;ETHCS proposal text]

> Running IPv6 over an Ethernet link need= s the support of link-layer
> multicast. In the 802.16 context, the = Ethernet Convergence Sublayer
> (also known as the IEEE Std 802.3/Et= hernet-specific part of the IEEE
>  802.16 Packet Convergen= ce Sublayer) must (1) support multicast
> link-layer addresses (2) m= ap IPv6 multicast addresses to link-layer
> addresses and vice-versa, (3) o= ffer the capability of joining and
> leaving IPv6 link-local multica= st groups and (4) send and receive
> IPv6 link-local multicast packe= ts whose link-layer headers contain
> link-layer multicast addresses= .
>
> The following link-layer multicast addresses are recomme= nded by
> RFCXXXX: 33:33:0:0:0:1, 2, 33:33:ff:XX:XX:XX, and others [= fill].
>
> The rules for mapping IPv6 link-local multicast add= resses to
> link-layer multicast addresses are recommended by RFCxxx= x and are the
>  following: - ff02::1 maps into 33:33:00:00= :00:1 - and the others.
>
>
> The IPv6 stack must join = a certain link-local IPv6 multicast group
> before receiving packets= addressed to that group. For example, before
>  receiving = a Router Advertisement the stack MUST join the IPv6
> link-local mul= ticast address 'all-nodes'. When the IPv6 stack on the
>  Subscri= ber Station joins a certain IPv6 link-local multicast group
> it MUST= receive all packets addressed to that group. The join
> operation ca= n happen in several ways: sending a MLD REPORT (RFCxxx),
> setting a = local filtering rule, etc.
>
> The IPv6 stack must be able to = leave a certain IPv6 link-local
> multicast group. When the IPv6 sta= ck leaves a group must no longer
> receive the IPv6 packets addresse= d to that group. Similarly to the
> joining operation the leaving op= eration can happen in several ways:
> sending a MLD REPORT, setting = a local filtering rule, etc.
>
> The following Neighbour Disco= very messages are sent by a Subscriber
> Station to IPv6 link-local = multicast addresses: Neighbour
> Advertisement, Neighbour Solicitati= on, Router Solicitation (RFCxxxx).
>  The following Neighbo= ur Discovery messages are received by a
> Subscriber Station, addressed to IPv6 = link-local multicast addresses:
>  Router Advertisement, Ne= ighbour Advertisement, Neighbour
> Solicitation.

____________= ___________________________________
16NG mailing list
16NG@ietf.orghttps://www1.ietf.org/mailman/listinfo/16ng

<= /div> --0-1974012021-1169049827=:13715-- --===============1184730027== 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 --===============1184730027==-- From 16ng-bounces@ietf.org Wed Jan 17 11:43:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Dsv-0001YR-Ru; Wed, 17 Jan 2007 11:43:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Dsv-0001YG-24 for 16ng@ietf.org; Wed, 17 Jan 2007 11:43:37 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Dst-0004JP-Fa for 16ng@ietf.org; Wed, 17 Jan 2007 11:43: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 l0HGhXka018966; Wed, 17 Jan 2007 17:43:34 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l0HGhXUQ012113; Wed, 17 Jan 2007 17:43:33 +0100 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 17:43:33 +0100 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] Re: multicast and IPv6 over ETHCS Date: Wed, 17 Jan 2007 17:43:33 +0100 Message-ID: <4BB931F00625F54DA8B8563E5A5CA25A013471AB@MCHP7I6A.ww002.siemens.net> In-Reply-To: <45AE471D.9090205@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc6UDJ8uQB33+dvTPi2K4IBCyUFZgABDK1A From: "Riegel, Maximilian" To: "Alexandru Petrescu" X-OriginalArrivalTime: 17 Jan 2007 16:43:33.0703 (UTC) FILETIME=[A075ED70:01C73A56] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Alex, I do not know why RFC4541 has become INFORMATIONAL. There may be other reasons than that it addresses functions below the IP layer. But I still believe that the IETF is the right place to write specifications on how IP packets are carried over foo. And in the case of IPoETHo802.16 it is not a particular framing format but particular functions in the link layer supporting IP behavior, which we have to specify. If I am following your statement, PPP would not be in the scope of the IETF. >> Bye Max BTW: Link layer multicast is not provided by the Ethernet=20 >> Convergence Layer but by a bridge device in the system deploying the=20 >> ETH-CS for transmitting Ethernet frames over IEEE802.16. > >Thanks for this clarification. So one is tempted to call the document >"IP over bridge device in the system deploying the ETH-CS for >transmitting Ethernet frames over IEEE 802.16". A terminology issue. You can just call it 'IP over Ethernet over IEEE802.16'. The bridge device together with the ETH-CS transport is exactly what is regarded as 'Ethernet'. Bye Max -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Wednesday, January 17, 2007 4:56 PM To: Riegel, Maximilian Cc: 16ng@ietf.org; Jihoon Lee Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS Max, thanks for your comments. It seems our disagreement is larger than I thought :-) In another mail I've tried to suggest that there is value in text that doesn't specify new behaviour (ie IPv6 runs over ETHCS as usual, no new behaviour) while you think that a new behaviour should be specified (albeit link-layer). I think there are other people on the list who agree that this document should not specify link-layer behaviour. Riegel, Maximilian wrote: > Hi Alex, >=20 > Your text on the behavior of the IPv6 stack on handling multicast=20 > looks like standard IPv6 behavior. Yes, it is standard behaviour of IPv6 stack over a link-layer multicast capable link, nothing new, that's the intention. > If this is true, than your text may be added for informational=20 > purposes but do not add anything to the normative part of the=20 > specification. Well if it's standard behaviour then it can't be informational, right? It should be formulated such as to not tresspass the main documents specifying this (2464, 2461, dhcp, etc) and to _recommend_ them - I agree. > If your text is defining special IPv6 behavior, i.e. changing=20 > standard IPv6 behavior, then it is not acceptable for the IPoETH-CS=20 > solution. I agree if it were so. But no the text doesn't change standard IPv6 behaviour, far from my intention. At some point it gets a little more than standard behaviour: it requires the SS to put link-layer multicast addresses in the link-layer header, something that current RFCs don't require, but implementations do. If you need, I can change that formulation to not tresspass at all, ie to say that implementations MAY use link-layer multicast addresses in link-layer header fields. Do you want me to do that? > The IPoETH solution does not allow any change to the standard=20 > behavior of the IP stack, when sending IP packets over Ethernet, but=20 > implements IP specific extensions in the Ethernet layer to make the=20 > transmission of IP over Ethernet more 'wireless friendly'. I think this Proposed Standards document is not the place to specify link-layer behaviour. > RFC4541 is an example of such an extension to the Ethernet layer. YEs, and it's INFORMATIONAL at IETF. Do you think this IPv6-over-ETHCS document should be INFORMATIONAL? > There is a real-world reason behind: an IP host may be connected by=20 > an Ethernet cable to an IEEE802.16 bridge device. The host does not=20 > have any awareness that its IP over Ethernet packets are transferred > over an IEEE802.16 radio link. All the IP specific optimization must > take place in the Ethernet layer over IEEE802.16. Sounds reasonable to me. But how that happens shouldn't be specified here. > Bye Max BTW: Link layer multicast is not provided by the Ethernet=20 > Convergence Layer but by a bridge device in the system deploying the=20 > ETH-CS for transmitting Ethernet frames over IEEE802.16. Thanks for this clarification. So one is tempted to call the document "IP over bridge device in the system deploying the ETH-CS for transmitting Ethernet frames over IEEE 802.16". A terminology issue. I can re-formulate the multicast phrases in my text to say the the link-layer multicast goals MAY be implemented by the bridge device in the system deploying the ETH-CS for transmitting Ethernet frames over IEEE 802.16. Do you agree that I re-formulate it that way? Do you or co-authors accept to introduce my text in the draft? If yes - where? I'm not pushing to do it now - please take the time - but if you or co-authors do, and when you do, please let me know. Once I know we have agreement to include the multicast text in the draft I can modify it according to all suggestions raised on the list. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 11:50:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Dzw-0004a6-Lz; Wed, 17 Jan 2007 11:50:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Dzv-0004a1-Hq for 16ng@ietf.org; Wed, 17 Jan 2007 11:50:51 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Dzu-0005eP-5T for 16ng@ietf.org; Wed, 17 Jan 2007 11:50:51 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1169052649!7063959!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 17378 invoked from network); 17 Jan 2007 16:50:49 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-7.tower-119.messagelabs.com with SMTP; 17 Jan 2007 16:50:49 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l0HGomMu011854; Wed, 17 Jan 2007 09:50:49 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0HGojQ8004880; Wed, 17 Jan 2007 10:50:47 -0600 (CST) Message-ID: <45AE53E5.90001@motorola.com> Date: Wed, 17 Jan 2007 17:50:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gabriel montenegro Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: <20070117160348.14171.qmail@web81913.mail.mud.yahoo.com> In-Reply-To: <20070117160348.14171.qmail@web81913.mail.mud.yahoo.com> 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 gabriel montenegro wrote: > > I'd suggest less rather than more text. I agree with the intent. > If it's standard behavior (as suggested by Max), rather than > describing it again and risking getting it wrong (even > informatively), I think it's better to just refer to the proper > sources (and sections within them if need be). Yes, but currently it is not the case - it doesn't refer to at least MLDv2 RFC (but prefers to refer to an INFORMATIONAL 4541 optimization of its usage). For example MLDv2 says all MLDv2-capable nodes should join FF02::16. Will an 802.16 ETHCS node join that address or not? MUST it? RFC2460-2464 don't require that. For multicast it reads as if authors concentrated in making link-layer do multicast. For example, the IPv6 section doesn't contain the word 'multicast' - or the fundamental need for it is IPv6 running over Ethernet _only_ if that Ethernet is multicast capable. This is completely absent from the IPv6 text. But, the document contains 7 occurences of 'bridge SHALL' statements. > The whole point of ETH CS is that the data path should look very > similar to most (switched) ethernet nowadays ("point-to-point LAN" as > per section 6.5.1--Support by IEEE Std 802.3--of IEEE 802.1D-2004). I agree and share the intent. > The problem of limiting potential flooding at the link-layer is not > new and we can just point at section 2.7 of > http://www.ietf.org/internet-drafts/draft-ietf-mboned-routingarch-07.txt > for existing procedures. I agree, I think we can refer to that (although it looks as a infrastructure multicast problem, non link-local). But I'm not sure what is the potential flooding problem in this 802.16 context? Anyone noticed such problem? The only problem I'm aware of is that IPv6 prefers the link-layer to be multicast capable. > Now, if there's anything normative that needs to change, Alex, please > point that out. You mean link-layer normative? Or you mean IPv6 normative? Sorry, I'm trying to figure out. For example rfc2461 says the node MUST join a group before receiving some messages. The IP-over-ETHCS document doesn't say neither it joins neither it doesn't. If the SS MUST join, then how would it do it? 2461 is silent about how to do it and MLDv2 has certain conditions under which the join should happen. IP-over-ETHCS document is silent about all this. There are also unspecified rules for joining a link-local group, running over Ethernet, and that don't involve message exchange, and deployed today. Which of those should SS do? RFC2464 says what are the mapping rules for IPv6 multicast addresses to EThernet link-layer multicast addresses. In that document there are no 'mapping rules' for IPv6 unicast addresses, nor for IPv4uni/multicast addresses. IP-over-ETHCS document says 'mapping' only for IPv4 (referring to rfc894) and says nothing about IPv6 mapping rules, it's silent about that. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 12:04:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ECz-0002qf-M9; Wed, 17 Jan 2007 12:04:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ECy-0002qI-Ii for 16ng@ietf.org; Wed, 17 Jan 2007 12:04:20 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7ECx-0008Ob-Al for 16ng@ietf.org; Wed, 17 Jan 2007 12:04:20 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1169053458!14416468!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3326 invoked from network); 17 Jan 2007 17:04:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 17 Jan 2007 17:04:18 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0HH4HOa003634; Wed, 17 Jan 2007 10:04:18 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0HH4Er9013907; Wed, 17 Jan 2007 11:04:16 -0600 (CST) Message-ID: <45AE570D.5010803@motorola.com> Date: Wed, 17 Jan 2007 18:04:13 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Riegel, Maximilian" Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: <4BB931F00625F54DA8B8563E5A5CA25A013471AB@MCHP7I6A.ww002.siemens.net> In-Reply-To: <4BB931F00625F54DA8B8563E5A5CA25A013471AB@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: c0bedb65cce30976f0bf60a0a39edea4 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: > Alex, > > I do not know why RFC4541 has become INFORMATIONAL. I don't know either, so it is. Would you like to suggest change its status? But it looks logical for IP-over-ETHCS to refer first and foremost to MLDv2 (Proposed Standard) and only after that works refer an INFORMATIONAL usage of it. No? > There may be other reasons than that it addresses functions below the > IP layer. But I still believe that the IETF is the right place to > write specifications on how IP packets are carried over foo. Yes, IP-over-foo. I completely agree. > And in the case of IPoETHo802.16 it is not a particular framing > format but particular functions in the link layer supporting IP > behavior, which we have to specify. Excuse me, but 'particular functions in the link layer' are not to be specified at IETF. We can try to dissect what 'particular functions in the link layer' is. For example, does that function build a link-layer packet? Does that function write an IP address in an IP-or-above header? > If I am following your statement, PPP would not be in the scope of > the IETF. Right, that was solved by saying PPP is not link-layer but layer 2/3. It doesn't build headers. More recently one sees PANA (full UDP) and EAP (independent of link-layer) and ppp doesn't get much upgrade at IETF. But, why do you mention ppp here? Do you see ppp anywhere in the IP-over-ETHCS context? I'd be glad to know. And I'm asking this because ppp is used everywhere on GPRS/UMTS, and pppoe is used on some HSDPA. Using ppp changes the landscape completely and if it's the case it should be stated. >>> Bye Max BTW: Link layer multicast is not provided by the Ethernet >>> Convergence Layer but by a bridge device in the system deploying >>> the ETH-CS for transmitting Ethernet frames over IEEE802.16. >> Thanks for this clarification. So one is tempted to call the >> document "IP over bridge device in the system deploying the ETH-CS >> for transmitting Ethernet frames over IEEE 802.16". A >> terminology issue. > > You can just call it 'IP over Ethernet over IEEE802.16'. The bridge > device together with the ETH-CS transport is exactly what is regarded > as 'Ethernet'. Do you mean the SS must have this 'bridge device' built-in? If SS doesn't have the 'bridge device' built-in then maybe there's nothing to be specified for the SS. Do you mean brctl? (bridge software on linux). This is software not hardware and is present in Bluetooth, but not on the SS, only on the AP. (Bluetooth had same problem of making ptp links look as multicast-capable, see PAN profile). Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 12:07:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7EFc-0007ZX-Fi; Wed, 17 Jan 2007 12:07:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7EFa-0007ZO-T0 for 16ng@ietf.org; Wed, 17 Jan 2007 12:07:02 -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 1H7EFZ-0000Nj-Cw for 16ng@ietf.org; Wed, 17 Jan 2007 12:07:02 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0HH4Z6R011802; Wed, 17 Jan 2007 19:04:49 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 19:06:46 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 11:06:41 -0600 Received: from 10.162.253.240 ([10.162.253.240]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jan 2007 17:06:40 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Wed, 17 Jan 2007 11:08:27 -0600 Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS From: Basavaraj Patil To: ext Alexandru Petrescu , gabriel montenegro Message-ID: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc6WhqIWUJDjqZNEduNAwARJNUNiA== In-Reply-To: <45AE53E5.90001@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 17:06:41.0465 (UTC) FILETIME=[DBA19A90:01C73A59] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070117190449-2DFE4BB0-522E836A/0-0/0-1 X-Nokia-AV: Clean 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 Alex, Let me pick on just one comment that you made on this thread: On 1/17/07 10:50 AM, "ext Alexandru Petrescu" wrote: > > The only problem I'm aware of is that IPv6 prefers the link-layer to be > multicast capable. > IPv6 is designed to work on many different types of links. It was not designed to work just on mutlicast capable links as your sentence implies. -Raj > > Alex > > > _______________________________________________ > 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 Jan 17 12:09:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7EIH-0008BX-0B; Wed, 17 Jan 2007 12:09:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7EIF-0008BG-Dh for 16ng@ietf.org; Wed, 17 Jan 2007 12:09:47 -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 1H7EID-00019W-UX for 16ng@ietf.org; Wed, 17 Jan 2007 12:09:47 -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 l0HH7uig020715; Wed, 17 Jan 2007 19:08:05 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 19:09:38 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 11:09:33 -0600 Received: from 10.162.253.240 ([10.162.253.240]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jan 2007 17:09:33 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Wed, 17 Jan 2007 11:11:20 -0600 Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS From: Basavaraj Patil To: ext Alexandru Petrescu , "Riegel, Maximilian" Message-ID: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc6WoGmwBqp8KZNEduNAwARJNUNiA== In-Reply-To: <45AE570D.5010803@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 17:09:33.0961 (UTC) FILETIME=[42726790:01C73A5A] X-Nokia-AV: Clean 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 Alex, Again a comment on just one of your statements: On 1/17/07 11:04 AM, "ext Alexandru Petrescu" wrote: > And I'm asking this > because ppp is used everywhere on GPRS/UMTS, and pppoe is used on some > HSDPA. PPP or PPPoE is NOT used in GPRS/UMTS or HSDPA. PDP context != PPP or PPPoE -Raj > Alex > > > _______________________________________________ > 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 Jan 17 12:20:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ESy-0004kc-8m; Wed, 17 Jan 2007 12:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ESx-0004kU-60 for 16ng@ietf.org; Wed, 17 Jan 2007 12:20:51 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7ESv-0003bi-UN for 16ng@ietf.org; Wed, 17 Jan 2007 12:20:51 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1169054449!13306430!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 25016 invoked from network); 17 Jan 2007 17:20:49 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 17 Jan 2007 17:20:49 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0HHKmKl008603; Wed, 17 Jan 2007 10:20:49 -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 l0HHKmum019038; Wed, 17 Jan 2007 11:20:48 -0600 (CST) Message-ID: <45AE5AEF.2030206@motorola.com> Date: Wed, 17 Jan 2007 18:20:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: more on ppp clarification ... [16NG] Re: multicast and IPv6 over ETHCS References: <4BB931F00625F54DA8B8563E5A5CA25A013471AB@MCHP7I6A.ww002.siemens.net> <45AE570D.5010803@motorola.com> In-Reply-To: <45AE570D.5010803@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Petrescu wrote: >> If I am following your statement, PPP would not be in the scope of >> the IETF. > > Right, that was solved by saying PPP is not link-layer but layer 2/3. > It doesn't build headers. More recently one sees PANA (full UDP) > and EAP (independent of link-layer) and ppp doesn't get much upgrade > at IETF. Also, ppp-over-ethernet is informational. But L2TP is what goes on Standards Track, and L2TP+somePPPoE is informational while LCP+L2TP is std track. The second reason for mentioning this is that someone may think something else than GRE could be used in a 802.16 deployment - it's the case, so don't make GRE mandatory. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 12:23:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7EVn-0006ZU-3W; Wed, 17 Jan 2007 12:23:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7EVm-0006WI-BY for 16ng@ietf.org; Wed, 17 Jan 2007 12:23:46 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7EVk-0004LF-Rg for 16ng@ietf.org; Wed, 17 Jan 2007 12:23:46 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1169054623!13306617!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 28611 invoked from network); 17 Jan 2007 17:23:44 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-119.messagelabs.com with SMTP; 17 Jan 2007 17:23:44 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0HHNhLw009432; Wed, 17 Jan 2007 10:23:43 -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 l0HHNgWJ020610; Wed, 17 Jan 2007 11:23:43 -0600 (CST) Message-ID: <45AE5B9E.5090006@motorola.com> Date: Wed, 17 Jan 2007 18:23:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS 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: 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 Basavaraj Patil wrote: > Alex, > > Let me pick on just one comment that you made on this thread: > > > On 1/17/07 10:50 AM, "ext Alexandru Petrescu" > wrote: > >> The only problem I'm aware of is that IPv6 prefers the link-layer >> to be multicast capable. >> > > IPv6 is designed to work on many different types of links. It was not > designed to work just on mutlicast capable links as your sentence > implies. I meant links with link-layer headers. Reading ND it says "node MUST join" before receiving an RA. 'Join' can happen only if that link is multicast-capable. In practice IPv6 runs even over RS-232, I've tried, but no conformant ND runs on that. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 12:29:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Eb2-0002TN-HW; Wed, 17 Jan 2007 12:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Eb1-0002TI-D0 for 16ng@ietf.org; Wed, 17 Jan 2007 12:29:11 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7Eb0-0005gP-1e for 16ng@ietf.org; Wed, 17 Jan 2007 12:29:11 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1169054948!13325896!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18956 invoked from network); 17 Jan 2007 17:29:08 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 17 Jan 2007 17:29:08 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0HHT8mO010979; Wed, 17 Jan 2007 10:29:08 -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 l0HHT74r027713; Wed, 17 Jan 2007 11:29:07 -0600 (CST) Message-ID: <45AE5CE2.8060500@motorola.com> Date: Wed, 17 Jan 2007 18:29:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS 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: 8abaac9e10c826e8252866cbe6766464 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 Basavaraj Patil wrote: > Alex, > > Again a comment on just one of your statements: > > > On 1/17/07 11:04 AM, "ext Alexandru Petrescu" > wrote: > >> And I'm asking this because ppp is used everywhere on GPRS/UMTS, >> and pppoe is used on some HSDPA. > > PPP is NOT used in GPRS/UMTS or HSDPA. How do you know? I know because I've tried. It's always the pppd program and ConfigReq sent/received. Do you mean a SDO spec says that PDP context is set up? And that that SDO document doesn't say 'ppp is used'? I agree with this part. > PPPoE is NOT used in GPRS/UMTS or HSDPA. What do you call a PPP ConfigReq within a MAC header with 48bits addresses, as displayed by Ethereal? And with a pcmcia card saying hsdpa. > PDP context != PPP or PPPoE I'm sorry. PDP context is not something defined at IETF, a different beast, can't compare. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 12:44:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Epi-0001Rm-3H; Wed, 17 Jan 2007 12:44:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Epg-0001Re-2m for 16ng@ietf.org; Wed, 17 Jan 2007 12:44:20 -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 1H7Epe-0007lY-LB for 16ng@ietf.org; Wed, 17 Jan 2007 12:44:20 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0HHgLGE030159; Wed, 17 Jan 2007 19:42:38 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 19:44:12 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jan 2007 11:44:10 -0600 Received: from 10.162.253.240 ([10.162.253.240]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jan 2007 17:44:09 +0000 User-Agent: Microsoft-Entourage/11.3.2.061213 Date: Wed, 17 Jan 2007 11:45:56 -0600 Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: [16NG] Re: multicast and IPv6 over ETHCS Thread-Index: Acc6X1cLlU8EqqZSEduNAwARJNUNiA== In-Reply-To: <45AE5CE2.8060500@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jan 2007 17:44:10.0571 (UTC) FILETIME=[1833F1B0:01C73A5F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Alex, On 1/17/07 11:29 AM, "ext Alexandru Petrescu" wrote: > Basavaraj Patil wrote: >> Alex, >> >> Again a comment on just one of your statements: >> >> >> On 1/17/07 11:04 AM, "ext Alexandru Petrescu" >> wrote: >> >>> And I'm asking this because ppp is used everywhere on GPRS/UMTS, >>> and pppoe is used on some HSDPA. >> >> PPP is NOT used in GPRS/UMTS or HSDPA. > > How do you know? I know because I've tried. It's always the pppd > program and ConfigReq sent/received. The PPP that you are talking about is most likely not between your PC card (that is implementing GPRS/HSDPA) and the GGSN. You could be doing PPP over a PDP context that is established between the PC card and the GGSN. Question is, does the PPP terminate at the GGSN? Of course not knowing what kind of service you are using or details, I can only speculate. > > Do you mean a SDO spec says that PDP context is set up? And that that > SDO document doesn't say 'ppp is used'? I agree with this part. PPP is an overhead and not required to transport IP packets in GPRS. PDP contexts are the mechanism used for carrying IP packets. > >> PPPoE is NOT used in GPRS/UMTS or HSDPA. > > What do you call a PPP ConfigReq within a MAC header with 48bits > addresses, as displayed by Ethereal? And with a pcmcia card saying hsdpa. Your Ethereal may not really be have the drivers to read what is being sent by the HSDPA card... I don't know. As I said above, tell me where is PPP being terminated in the network, i.e the GPRS core? > >> PDP context != PPP or PPPoE > > I'm sorry. PDP context is not something defined at IETF, a different > beast, can't compare. And I am not asking you to do so. I was just correcting a statement about PPP usage that you made. And it appeared to be a globally applicable statement to all GPRS/UMTS/HSDPA deployments. -Raj > > Alex > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 13:05:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7F9n-0003na-Vl; Wed, 17 Jan 2007 13:05:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7F9n-0003nV-Aa for 16ng@ietf.org; Wed, 17 Jan 2007 13:05:07 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7F9l-00024t-Us for 16ng@ietf.org; Wed, 17 Jan 2007 13:05:07 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1169057104!11344662!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31685 invoked from network); 17 Jan 2007 18:05:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 17 Jan 2007 18:05:04 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0HI50s9021013; Wed, 17 Jan 2007 11:05:00 -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 l0HI4xKQ012503; Wed, 17 Jan 2007 12:04:59 -0600 (CST) Message-ID: <45AE654A.5080409@motorola.com> Date: Wed, 17 Jan 2007 19:04:58 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: ppp - I'll stop discussing (was: [16NG] Re: multicast and IPv6 over ETHCS) 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: b280b4db656c3ca28dd62e5e0b03daa8 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 Raj, thanks for the email. I will not post further on this topic, not because I don't want to reply to you, but because I've already got private indication (from Chairs and AD) that I should stop ppp discussion, there's nothing new or relevant to the IP-over-IP/ETHCS. Alex Basavaraj Patil wrote: > The PPP that you are talking about is most likely not between your PC > card (that is implementing GPRS/HSDPA) and the GGSN. I'm sorry but I don't care. It's about my IP laptop and a certain network. IETF doesn't define what's GGSN nor SGSN. I believe (not sure) no deployment has strict GGSN/SGSN separation (separation suggested by SDO and graduate textbooks). > You could be doing PPP over a PDP context that is established between > the PC card and the GGSN. Question is, does the PPP terminate at the > GGSN? Of course not knowing what kind of service you are using or > details, I can only speculate. YEs, I agree. I no longer bother to even speculate, I'm torn down by these speculations, too many traceroutes, too many pings, on every operator's different topology. I prefer to see it as a network into which I can ppp, with a certain qos. This is the typical point of view adopted by a end host. >> Do you mean a SDO spec says that PDP context is set up? And that >> that SDO document doesn't say 'ppp is used'? I agree with this >> part. > > PPP is an overhead and not required to transport IP packets in GPRS. Well that's what many people do (see 'globally' interpreted at the end of this message). Not even Compression modules are used. It works. > PDP contexts are the mechanism used for carrying IP packets. There's no IP-over-PDPcontext StdsTrack RFC, sorry. I too run IPv6-over-RS232 w/o an RFC telling me how, it works, doesn't upset anybody, and solves today's context sometimes (think really small custom stuff). SDO can do that too with its PDP contexts, unless it upsets somebody. >>> PPPoE is NOT used in GPRS/UMTS or HSDPA. >> What do you call a PPP ConfigReq within a MAC header with 48bits >> addresses, as displayed by Ethereal? And with a pcmcia card saying >> hsdpa. > > Your Ethereal may not really be have the drivers to read what is > being sent by the HSDPA card... I don't know. WEll it does have necessary drivers telling me that. It's enough for making run the IPv6 stack, no more needed. > As I said above, tell me where is PPP being terminated in the > network, i.e the GPRS core? Sorry, I don't know precisely. It terminates somewhere in the network. I could tell you all the experiments I've done to find that precise question you ask, and how they were voided by simply connecting to another operator. >>> PDP context != PPP or PPPoE >> I'm sorry. PDP context is not something defined at IETF, a >> different beast, can't compare. > > And I am not asking you to do so. I was just correcting a statement > about PPP usage that you made. And it appeared to be a globally > applicable statement to all GPRS/UMTS/HSDPA deployments. Ok, what's globally applicable. To me globally applicable is the following: google APN name and find the name of operators that will allow one to ppp into their cell networks. One will find cell operators all over the world. I've personally tried a bunch of them in Europe and the 2-3 available in US. GPRS and UMTS and HSDPA. Is this globally applicable to you? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 17 15:50:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hk5-00059a-So; Wed, 17 Jan 2007 15:50:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Hjt-00050z-Gd; Wed, 17 Jan 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H7Hjs-0004rL-Sj; Wed, 17 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id C9C8C2AD48; Wed, 17 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H7HjO-0004Hd-EE; Wed, 17 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 17 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 16ng@ietf.org Subject: [16NG] I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-06.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 : IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks Author(s) : B. Patil, et al. Filename : draft-ietf-16ng-ipv6-over-ipv6cs-06.txt Pages : 20 Date : 2007-1-17 IEEE Std 802.16 is an air interface specification. 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. The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv6 packets directly over the MAC. This document specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-06.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-over-ipv6cs-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-1-17143856.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-16ng-ipv6-over-ipv6cs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-17143856.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 Jan 17 16:19:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7IBN-0007Jy-PR; Wed, 17 Jan 2007 16:18:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7IBM-0007JO-BH for 16ng@ietf.org; Wed, 17 Jan 2007 16:18:56 -0500 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7IBK-0007qZ-2y for 16ng@ietf.org; Wed, 17 Jan 2007 16:18:56 -0500 Received: by an-out-0708.google.com with SMTP id d30so3637and for <16ng@ietf.org>; Wed, 17 Jan 2007 13:18:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=g6jImn7bRR9EkQhdq7E7aNmm6p5gfjTDlkHhfhh5V6/xu8RLkqdKv89cilkqyCHG7Fi5xSOqIh2J0+N30Vn7TCIzcV3z25TFuo7fFhkozrEgrB7SowUVdIWng/GHGo5k3VhmO7b9PLAxsDYAxr0w7ldKB7CUCMGMI8bX4nhVI+4= Received: by 10.100.152.9 with SMTP id z9mr4316and.1169068731785; Wed, 17 Jan 2007 13:18:51 -0800 (PST) Received: by 10.70.102.13 with HTTP; Wed, 17 Jan 2007 13:18:51 -0800 (PST) Message-ID: <4a8dceef0701171318g3174dfbo93e37a931a4819e2@mail.gmail.com> Date: Wed, 17 Jan 2007 16:18:51 -0500 From: "Qiang Zhang" To: "Basavaraj Patil" Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS In-Reply-To: MIME-Version: 1.0 References: <45AE5CE2.8060500@motorola.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: qiangieee@gmail.com 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="===============0487613352==" Errors-To: 16ng-bounces@ietf.org --===============0487613352== Content-Type: multipart/alternative; boundary="----=_Part_97107_5619309.1169068731663" ------=_Part_97107_5619309.1169068731663 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Is there a real case that PPP/PPPoE is overlaid on top PDP or PPP (PDSN case) or LAP? My guess is that No, i haven't seen a DIALer that does this and there is no reason to do so. There is case that PC PPP to the AT though but this terminates at the AT On 1/17/07, Basavaraj Patil wrote: > > > Alex, > > > On 1/17/07 11:29 AM, "ext Alexandru Petrescu" > wrote: > > > Basavaraj Patil wrote: > >> Alex, > >> > >> Again a comment on just one of your statements: > >> > >> > >> On 1/17/07 11:04 AM, "ext Alexandru Petrescu" > >> wrote: > >> > >>> And I'm asking this because ppp is used everywhere on GPRS/UMTS, > >>> and pppoe is used on some HSDPA. > >> > >> PPP is NOT used in GPRS/UMTS or HSDPA. > > > > How do you know? I know because I've tried. It's always the pppd > > program and ConfigReq sent/received. > > The PPP that you are talking about is most likely not between your PC card > (that is implementing GPRS/HSDPA) and the GGSN. You could be doing PPP > over > a PDP context that is established between the PC card and the GGSN. > Question > is, does the PPP terminate at the GGSN? Of course not knowing what kind of > service you are using or details, I can only speculate. > > > > > Do you mean a SDO spec says that PDP context is set up? And that that > > SDO document doesn't say 'ppp is used'? I agree with this part. > > PPP is an overhead and not required to transport IP packets in GPRS. PDP > contexts are the mechanism used for carrying IP packets. > > > > >> PPPoE is NOT used in GPRS/UMTS or HSDPA. > > > > What do you call a PPP ConfigReq within a MAC header with 48bits > > addresses, as displayed by Ethereal? And with a pcmcia card saying > hsdpa. > > Your Ethereal may not really be have the drivers to read what is being > sent > by the HSDPA card... I don't know. As I said above, tell me where is PPP > being terminated in the network, i.e the GPRS core? > > > > >> PDP context != PPP or PPPoE > > > > I'm sorry. PDP context is not something defined at IETF, a different > > beast, can't compare. > > And I am not asking you to do so. I was just correcting a statement about > PPP usage that you made. And it appeared to be a globally applicable > statement to all GPRS/UMTS/HSDPA deployments. > > -Raj > > > > > Alex > > > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > ------=_Part_97107_5619309.1169068731663 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is there a real case that PPP/PPPoE is overlaid on top PDP or PPP (PDSN case) or LAP? My guess is that No, i haven't seen a DIALer that does this and there is no reason to do so. There is case that PC PPP to the AT though but this terminates at the AT

On 1/17/07, Basavaraj Patil <basavaraj.patil@nokia.com> wrote:

Alex,


On 1/17/07 11:29 AM, "ext Alexandru Petrescu"
<alexandru.petrescu@motorola.com> wrote:

> Basavaraj Patil wrote:
>> Alex,
>>
>> Again a comment on just one of your statements:
>>
>>
>> On 1/17/07 11:04 AM, "ext Alexandru Petrescu"
>> < alexandru.petrescu@motorola.com> wrote:
>>
>>> And I'm asking this because ppp is used everywhere on GPRS/UMTS,
>>> and pppoe is used on some HSDPA.
>>
>> PPP is NOT used in GPRS/UMTS or HSDPA.
>
> How do you know?  I know because I've tried.  It's always the pppd
> program and ConfigReq sent/received.

The PPP that you are talking about is most likely not between your PC card
(that is implementing GPRS/HSDPA) and the GGSN. You could be doing PPP over
a PDP context that is established between the PC card and the GGSN. Question
is, does the PPP terminate at the GGSN? Of course not knowing what kind of
service you are using or details, I can only speculate.

>
> Do you mean a SDO spec says that PDP context is set up?  And that that
> SDO document doesn't say 'ppp is used'?  I agree with this part.

PPP is an overhead and not required to transport IP packets in GPRS. PDP
contexts are the mechanism used for carrying IP packets.

>
>> PPPoE is NOT used in GPRS/UMTS or HSDPA.
>
> What do you call a PPP ConfigReq within a MAC header with 48bits
> addresses, as displayed by Ethereal?  And with a pcmcia card saying hsdpa.

Your Ethereal may not really be have the drivers to read what is being sent
by the HSDPA card... I don't know. As I said above, tell me where is PPP
being terminated in the network, i.e the GPRS core?

>
>> PDP context != PPP or PPPoE
>
> I'm sorry.  PDP context is not something defined at IETF, a different
> beast, can't compare.

And I am not asking you to do so. I was just correcting a statement about
PPP usage that you made. And it appeared to be a globally applicable
statement to all GPRS/UMTS/HSDPA deployments.

-Raj

>
> Alex
>


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

------=_Part_97107_5619309.1169068731663-- --===============0487613352== 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 --===============0487613352==-- From 16ng-bounces@ietf.org Wed Jan 17 18:37:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KLF-0005vC-QM; Wed, 17 Jan 2007 18:37:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KLE-0005v3-1r for 16ng@ietf.org; Wed, 17 Jan 2007 18:37:16 -0500 Received: from web81905.mail.mud.yahoo.com ([68.142.207.184]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7KLC-000718-Kn for 16ng@ietf.org; Wed, 17 Jan 2007 18:37:16 -0500 Received: (qmail 35378 invoked by uid 60001); 17 Jan 2007 23:37:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=eV64B+Sume21PhgcDBtq9QOiUYx0Djs7VFp3Tkg+Ed/VfofEmKeaROpKlEpi7lTl/9AkPquq2mSyUBiWCB2aE25psbLmMVdgL3ustsyVphpserMPl23eKinA/5BNAFBDYymfuW9pIFGNLIc7YpWwT66AxeUHxIyUyyeQ/XMxE0U= ; Message-ID: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81905.mail.mud.yahoo.com via HTTP; Wed, 17 Jan 2007 15:37:14 PST Date: Wed, 17 Jan 2007 15:37:14 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS To: Alexandru Petrescu , Basavaraj Patil MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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="===============1512538933==" Errors-To: 16ng-bounces@ietf.org --===============1512538933== Content-Type: multipart/alternative; boundary="0-1984287572-1169077034=:35341" --0-1984287572-1169077034=:35341 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Alex,=0A=0AThe statement below is not true:=0A=0A I meant links with link= -layer headers.=0A=0A Reading ND it says "node MUST join" before receivin= g an RA. 'Join' can=0A happen only if that link is multicast-capable.=0A= =0A802.15.4 (a link with link-layer header) has no multicast capability =0A= (only broadcast) at the link layer. Yet IPv6 can work fine. Of course,=0Aif= one wants to optimize, one can do several things (e.g., controlled=0Aflood= ing, sending along a spanning tree, etc), but neither is this=0Arequired no= r does the link layer have any concept of multicast.=0A=0AWouldn't it be en= ough to simply say that multicast address mapping=0Ais done per http://tool= s.ietf.org/html/rfc2464?=0A=0AShould be obvious, but perhaps this is worth = noting? =0A=0ABecause this is so, regular IP-level join protocols work fine= =0A(e.g., MLD), no need to say more. You also mention elsewhere that a link= -level=0A"join" for multicast is necessary. This is not so. Notice that if= a=0Alink layer simply floods all multicast packets (essentially using =0A= broadcast), things work fine. The IP layer itself will do the filtering.=0A= The link-layer can do filtering to avoid flooding mcast as if it were=0Abca= st, but it's just an optimization.=0A =0ANow, 802.1D does propose such a li= nk-layer optimization (IGRP/GARP), =0Abut probably cuz this requires suppor= t at=0Athe clients (or perhaps for other reasons as well), this is not actu= ally=0Adeployed, and yet things work fine over ethernet. Instead, the =0Aop= timization to avoid flooding is possible because IPv4 and=0AIPv6 procedures= are followed for joins (IGMP, MLD) independently of link-layer.=0ATypicall= y, snooping of those sets state at the link-layer to achieve the=0Adesired = (not required) optimization.=0A=0A-gabriel=0A=0A----- Original Message ----= =0AFrom: Alexandru Petrescu =0A=0A=0A=0A= =0A=0A=0A=0A=0A --0-1984287572-1169077034=:35341 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Alex,

The statement below is not true:

=    I meant links with link-layer headers.

   Rea= ding ND it says "node MUST join" before receiving an RA.  'Join' = can
   happen only if that link is multicast-capable.

8= 02.15.4 (a link with link-layer header) has no multicast capability
(on= ly broadcast) at the link layer. Yet IPv6 can work fine. Of course,
if o= ne wants to optimize, one can do several things (e.g., controlled
floodi= ng, sending along a spanning tree, etc), but neither is this
required no= r does the link layer have any concept of multicast.

Wouldn't it be = enough to simply say that multicast address mapping
is done per http://tools.ietf.org/html/rfc= 2464?

Should be obvious, but perhaps this is worth noting= ?

Because this is so, regular IP-level join protocols work fine
= (e.g., MLD), no need to say more. You also mention elsewhere that a link-le= vel
"join" for multicast is necessary. This is not so.  Notice that= if a
link layer simply floods all multicast packets (essentially  = using
broadcast), things work fine. The IP layer itself will do the fil= tering.
The link-layer can do filtering to avoid flooding mcast as if it= were
bcast, but it's just an optimization.

Now, 802.1D does pro= pose such a link-layer optimization (IGRP/GARP),
but probably cuz this = requires support at
the clients (or perhaps for other reasons as well), = this is not actually
deployed, and yet things work fine over ethernet. I= nstead, the
optimization to avoid flooding is possible because IPv4 and=
IPv6 procedures are followed for joins (IGMP, MLD) independently of link-layer.=
Typically, snooping of those sets state at the link-layer to achieve th= e
desired (not required) optimization.

-gabriel

--= --- Original Message ----
From: Alexandru Petrescu <alexandru.petresc= u@motorola.com>





--0-1984287572-1169077034=:35341-- --===============1512538933== 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 --===============1512538933==-- From 16ng-bounces@ietf.org Wed Jan 17 19:06:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KnD-0005N8-I9; Wed, 17 Jan 2007 19:06:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7KnC-0005My-9i for 16ng@ietf.org; Wed, 17 Jan 2007 19:06:10 -0500 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7KnA-0002CK-Sy for 16ng@ietf.org; Wed, 17 Jan 2007 19:06:10 -0500 Received: by wr-out-0506.google.com with SMTP id i22so33702wra for <16ng@ietf.org>; Wed, 17 Jan 2007 16:06:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ZiBFs2SPodQlVbkBzwr2bid/BkNkS38r2hr66zAz4QcpQe/CSFCXhU80+OGdpzInhq9aP0X7P8L6xDOlClPifxQLwc5IRVR4IZ+KJH5ERErX7Yvl40oi+4R9kGNizKEjOCU+Fkly2uh63mWIVG5Jtr72ufP81KOByiX9bxv6kkw= Received: by 10.90.90.3 with SMTP id n3mr223187agb.1169078765739; Wed, 17 Jan 2007 16:06:05 -0800 (PST) Received: by 10.65.225.19 with HTTP; Wed, 17 Jan 2007 16:06:05 -0800 (PST) Message-ID: Date: Thu, 18 Jan 2007 09:06:05 +0900 From: "Jihoon Lee" To: "gabriel montenegro" , "Alexandru Petrescu" Subject: [16NG] Re: multicast and IPv6 over ETHCS In-Reply-To: MIME-Version: 1.0 References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> X-Google-Sender-Auth: 4cd336aaa3cd3f92 X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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="===============1202443247==" Errors-To: 16ng-bounces@ietf.org --===============1202443247== Content-Type: multipart/alternative; boundary="----=_Part_77027_10137075.1169078765623" ------=_Part_77027_10137075.1169078765623 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Gabriel, > Notice that if a link layer simply floods > all multicast packets (essentially using > broadcast), things work fine. Let's focus on the main issue. As I know, we started to discuss this problem, because of the lack of flooding function (surely including multicast) between MSs (uplink) in 802.16 MAC layer. So, we're trying to discuss this problem regarding IPv6overETHCS. Best regards, Jihoon 2007/1/18, gabriel montenegro : > > Alex, > > The statement below is not true: > > I meant links with link-layer headers. > > Reading ND it says "node MUST join" before receiving an RA. 'Join' can > > happen only if that link is multicast-capable. > > 802.15.4 (a link with link-layer header) has no multicast capability > (only broadcast) at the link layer. Yet IPv6 can work fine. Of course, > if one wants to optimize, one can do several things ( e.g., controlled > flooding, sending along a spanning tree, etc), but neither is this > required nor does the link layer have any concept of multicast. > > Wouldn't it be enough to simply say that multicast address mapping > is done per http://tools.ietf.org/html/rfc2464? > > Should be obvious, but perhaps this is worth noting? > > Because this is so, regular IP-level join protocols work fine > (e.g., MLD), no need to say more. You also mention elsewhere that a > link-level > "join" for multicast is necessary. This is not so. Notice that if a > link layer simply floods all multicast packets (essentially using > broadcast), things work fine. The IP layer itself will do the filtering. > The link-layer can do filtering to avoid flooding mcast as if it were > bcast, but it's just an optimization. > > Now, 802.1D does propose such a link-layer optimization (IGRP/GARP), > but probably cuz this requires support at > the clients (or perhaps for other reasons as well), this is not actually > deployed, and yet things work fine over ethernet. Instead, the > optimization to avoid flooding is possible because IPv4 and > IPv6 procedures are followed for joins (IGMP, MLD) independently of > link-layer. > Typically, snooping of those sets state at the link-layer to achieve the > desired (not required) optimization. > > -gabriel > > ----- Original Message ---- > From: Alexandru Petrescu < alexandru.petrescu@motorola.com> > > > > > > > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > > > ------=_Part_77027_10137075.1169078765623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Gabriel,
 
> Notice that if a link layer simply floods
> all multicast packets (essentially  using
> broadcast), things work fine.
 
Let's focus on the main issue. As I know, we started to discuss this problem, because of the lack of flooding function (surely including multicast) between MSs (uplink) in 802.16 MAC layer. So, we're trying to discuss this problem regarding IPv6overETHCS.
 
Best regards,
Jihoon

 
2007/1/18, gabriel montenegro <gabriel_montenegro_2000@yahoo.com >:
Alex,

The statement below is not true:

   I meant links with link-layer headers.

   Reading ND it says "node MUST join" before receiving an RA.  'Join' can
   happen only if that link is multicast-capable.

802.15.4 (a link with link-layer header) has no multicast capability
(only broadcast) at the link layer. Yet IPv6 can work fine. Of course,
if one wants to optimize, one can do several things ( e.g., controlled
flooding, sending along a spanning tree, etc), but neither is this
required nor does the link layer have any concept of multicast.

Wouldn't it be enough to simply say that multicast address mapping
is done per http://tools.ietf.org/html/rfc2464?

Should be obvious, but perhaps this is worth noting?

Because this is so, regular IP-level join protocols work fine
(e.g., MLD), no need to say more. You also mention elsewhere that a link-level
"join" for multicast is necessary. This is not so.  Notice that if a
link layer simply floods all multicast packets (essentially  using
broadcast), things work fine. The IP layer itself will do the filtering.
The link-layer can do filtering to avoid flooding mcast as if it were
bcast, but it's just an optimization.

Now, 802.1D does propose such a link-layer optimization (IGRP/GARP),
but probably cuz this requires support at
the clients (or perhaps for other reasons as well), this is not actually
deployed, and yet things work fine over ethernet. Instead, the
optimization to avoid flooding is possible because IPv4 and
IPv6 procedures are followed for joins (IGMP, MLD) independently of link-layer.
Typically, snooping of those sets state at the link-layer to achieve the
desired (not required) optimization.

-gabriel

----- Original Message ----
From: Alexandru Petrescu < alexandru.petrescu@motorola.com>




 

 

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



------=_Part_77027_10137075.1169078765623-- --===============1202443247== 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 --===============1202443247==-- From 16ng-bounces@ietf.org Thu Jan 18 03:02:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7SE5-0007Hq-FU; Thu, 18 Jan 2007 03:02:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7SE3-0007Hh-LN for 16ng@ietf.org; Thu, 18 Jan 2007 03:02:23 -0500 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7SE1-0006C3-Rr for 16ng@ietf.org; Thu, 18 Jan 2007 03:02:23 -0500 Received: (qmail 10205 invoked by uid 60001); 18 Jan 2007 08:02:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=r9p4k/68Zy1YDWxuZv9LFYImdI6pNgjShszf3zSMSLaub3eNUvlS82HSN/0I3L929n4G4X09KBHb3XCw2I83IxT6SWwsVgM62DIMK1CBS1ELp2mRYfcx/ba1W+RMyUPXvekRDNzM2YUPoJaKY0Rj8Q876ZLz03NaVxQAXTgJnV8= ; Message-ID: <20070118080221.10203.qmail@web81913.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81913.mail.mud.yahoo.com via HTTP; Thu, 18 Jan 2007 00:02:21 PST Date: Thu, 18 Jan 2007 00:02:21 -0800 (PST) From: gabriel montenegro To: Jari Arkko , Basavaraj Patil MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: Mark Townsley , 16ng@ietf.org Subject: [16NG] Request for publication as proposed standard: draft-ietf-16ng-ipv6-over-ipv6cs-06.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: , Content-Type: multipart/mixed; boundary="===============1495530351==" Errors-To: 16ng-bounces@ietf.org --===============1495530351== Content-Type: multipart/alternative; boundary="0-1856296869-1169107341=:8389" --0-1856296869-1169107341=:8389 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Jari,=0A=0AOn behalf of the 16ng WG, please find below the request to publi= sh=0Adraft-ietf-16ng-ipv6-over-ipv6cs-06.txt as a proposed standard.=0A=0At= hanks,=0A=0A-16ng co-chairs (gab and daniel)=0A----------------------------= ----------------------------=0ADocument writeup for =0Ahttp://www.ietf.org/= internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-06.txt=0A=0ATarget: Propos= ed Standard=0A=0ADocument shepherd questions and writeup format (21 Novembe= r 2006)=0A=0A (1.a) Who is the Document Shepherd for this document? Has= the=0A Document Shepherd personally reviewed this version of the= =0A document and, in particular, does he or she believe this=0A = version is ready for forwarding to the IESG for publication?=0A=0A = Gabriel Montenegro, the shepherding co-chair, has read this=0A = version and thinks it is ready to advance.=0A=0A (1.b) Has the = document had adequate review both from key WG members=0A and from = key non-WG members? Does the Document Shepherd have=0A any concer= ns about the depth or breadth of the reviews that=0A have been per= formed?=0A=0A There has been considerable review on this draft f= rom WG members,=0A an AD and the WG's technical advisors. It has= also been the subject=0A of discussion in face-to-face meetings= at regular IETF=0A sessions as well as an interim meeting last = September.=0A Also very important is the review done at the WiMa= x forum,=0A where this document is now being referred to from th= eir=0A specifications. =0A=0A (1.c) Does the Document Shepher= d have concerns that the document=0A needs more review from a part= icular or broader perspective,=0A e.g., security, operational comp= lexity, someone familiar with=0A AAA, internationalization or XML?= =0A=0A I believe there is sufficient review. This document has = =0A undergone two WG LC periods, an initial 2-week period in=0A = October and a shorter 1-week period which ended on Jan 5.=0A=0A = (1.d) Does the Document Shepherd have any specific concerns or=0A = issues with this document that the Responsible Area Director=0A = and/or the IESG should be aware of? For example, perhaps he=0A o= r she is uncomfortable with certain parts of the document, or=0A h= as concerns whether there really is a need for it. In any=0A even= t, if the WG has discussed those issues and has indicated=0A that = it still wishes to advance the document, detail those=0A concerns = here.=0A=0A None.=0A=0A (1.e) How solid is the WG consensus b= ehind this document? Does it=0A represent the strong concurrence = of a few individuals, with=0A others being silent, or does the WG = as a whole understand and=0A agree with it?=0A=0A There= is strong consensus behind the approach. There was =0A consider= able discussion during both WG LC period. In particular,=0A this= version clarifies some points discussed during the last=0A WG L= C related to multicast support, router discovery and some=0A add= itional information about the 802.16 procedures.=0A=0A (1.f) Has anyone = threatened an appeal or otherwise indicated extreme=0A discontent?= If so, please summarise the areas of conflict in=0A separate ema= il messages to the Responsible Area Director. (It=0A should be in= a separate email because this questionnaire is=0A entered into th= e ID Tracker.)=0A=0A No.=0A=0A (1.g) Has the Document Shepher= d personally verified that the=0A document satisfies all ID nits? = (See=0A http://www.ietf.org/ID-Checklist.html and=0A htt= p://tools.ietf.org/tools/idnits/). Boilerplate checks are=0A not = enough; this check needs to be thorough. Has the document=0A met = all formal review criteria it needs to, such as the MIB=0A Doctor,= media type and URI type reviews?=0A=0A No issues found.=0A=0A = (1.h) Has the document split its references into normative and=0A = informative? Are there normative references to documents that=0A = are not ready for advancement or are otherwise in an unclear=0A = state? If such normative references exist, what is the=0A strateg= y for their completion? Are there normative references=0A that ar= e downward references, as described in [RFC3967]? If=0A so, list = these downward references to support the Area=0A Director in the L= ast Call procedure for them [RFC3967].=0A=0A No issues here.=0A= =0A (1.i) Has the Document Shepherd verified that the document IANA=0A = consideration section exists and is consistent with the body=0A = of the document? If the document specifies protocol=0A exte= nsions, are reservations requested in appropriate IANA=0A registri= es? Are the IANA registries clearly identified? If=0A the docume= nt creates a new registry, does it define the=0A proposed initial = contents of the registry and an allocation=0A procedure for future= registrations? Does it suggested a=0A reasonable name for the ne= w registry? See=0A [I-D.narten-iana-considerations-rfc2434bis]. = If the document=0A describes an Expert Review process has Shepherd= conferred with=0A the Responsible Area Director so that the IESG = can appoint the=0A needed Expert during the IESG Evaluation?=0A=0A= IANA section does not require any actions.=0A=0A (1.j) Has t= he Document Shepherd verified that sections of the=0A document tha= t are written in a formal language, such as XML=0A code, BNF rules= , MIB definitions, etc., validate correctly in=0A an automated che= cker?=0A=0A No such sections.=0A=0A (1.k) The IESG approval a= nnouncement includes a Document=0A Announcement Write-Up. Please = provide such a Document=0A Announcement Writeup? Recent examples = can be found in the=0A "Action" announcements for approved documen= ts. The approval=0A announcement contains the following sections:= =0A=0A Technical Summary =0A=0A This document specifies= the addressing and operation of IPv6 over=0A the IPv6 specific = part of the packet CS for hosts served by a=0A network that util= izes the IEEE Std 802.16 air interface. It=0A recommends the ass= ignment of a unique prefix (or prefixes) to each=0A host and all= ows the host to use multiple identifiers within that=0A prefix, = including support for randomly generated identifiers.=0A=0A=0A Wor= king Group Summary=0A=0A There was much initial debate about the= link model to adopt.=0A The interim made it clear that the "per= -MS" prefix was=0A preferable. Beyond that, there has been debat= e about how much=0A 802.16-specific details to include (e.g., on= network entry=0A procedure) for clarity.=0A=0A Documen= t Quality=0A=0A There are no currently known implementations of = this document.=0A However, the per-MS prefix model has been depl= oyed in 3GPP, so =0A at least that part is known to work, and th= is was a major point=0A in deciding in its favor. The WiMax foru= m sees this document as one=0A of its pilars, so it is expected = that it will see significant =0A deployment within the next year= s.=0A=0A Personnel=0A Who is the Document Shepherd for= this document? Who is the=0A Responsible Area Director?=0A=0A= Shepherd: Gabriel Montenegro=0A AD: Jari Ar= kko=0A=0A=0A=0A --0-1856296869-1169107341=:8389 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Jari,

On behalf of the 16ng WG, please find belo= w the request to publish
draft-ietf-16ng-ipv6-over-ipv6cs-06.txt as a pr= oposed standard.

thanks,

-16ng co-chairs (gab and daniel)
= --------------------------------------------------------
Document writeu= p for
http://www.ietf.org/internet= -drafts/draft-ietf-16ng-ipv6-over-ipv6cs-06.txt

Target: P= roposed Standard

Document shepherd questions and writeup format (21 = November 2006)

   (1.a)  Who is the Document Shepherd= for this document?  Has the
      &n= bsp;   Document Shepherd personally reviewed this version of the
          document and= , in particular, does he or she believe this
    &nb= sp;     version is ready for forwarding to the IESG for= publication?

         =    Gabriel Montenegro, the shepherding co-chair, has read this            version= and thinks it is ready to advance.

   (1.b)  Has the= document had adequate review both from key WG members
   = ;       and from key non-WG members?  Do= es the Document Shepherd have
       =    any concerns about the depth or breadth of the reviews that          have been performed= ?

           = There has been considerable review on this draft from WG members,
  &nb= sp;         an AD and the WG's tech= nical advisors. It has also been the subject
    &nb= sp;       of discussion in face-to-face meeti= ngs at regular IETF
        &nbs= p;   sessions as well as an interim meeting last September.
&n= bsp;           Also very = important is the review done at the WiMax forum,
    = ;        where this document is now bein= g referred to from their
        = ;    specifications.

   (1.c)  Does t= he Document Shepherd have concerns that the document
   &= nbsp;      needs more review from a particular or = broader perspective,
          e.g= ., security, operational complexity, someone familiar with
  &= nbsp;       AAA, internationalization or XML?=

            = I believe there is sufficient review. This document has
  &nb= sp;         undergone two WG LC per= iods, an initial 2-week period in
      &n= bsp;     October and a shorter 1-week period which ende= d on Jan 5.

   (1.d)  Does the Document Shepherd have= any specific concerns or
       &nbs= p;  issues with this document that the Responsible Area Director
&n= bsp;         and/or the IESG should= be aware of?  For example, perhaps he
          or she is unc= omfortable with certain parts of the document, or
   &nbs= p;      has concerns whether there really is a nee= d for it.  In any
        &= nbsp; event, if the WG has discussed those issues and has indicated
&nbs= p;         that it still wishes to = advance the document, detail those
      &= nbsp;   concerns here.

      = ;      None.

   (1.e)  How s= olid is the WG consensus behind this document?  Does it
  = ;        represent the strong concurrenc= e of a few individuals, with
       &= nbsp;  others being silent, or does the WG as a whole understand and
          agree with i= t?

           = ; There is strong consensus behind the approach. There was
  =           considerable discuss= ion during both WG LC period. In particular,
    &nb= sp;       this version clarifies some points = discussed during the last
       &nbs= p;    WG LC related to multicast support, router discovery a= nd some
          &nbs= p; additional information about the 802.16 procedures.

   = (1.f)  Has anyone threatened an appeal or otherwise indicated extreme<= br>          discontent? = If so, please summarise the areas of conflict in
          separate emai= l messages to the Responsible Area Director.  (It
   = ;       should be in a separate email because= this questionnaire is
        &= nbsp; entered into the ID Tracker.)

     &n= bsp;      No.

   (1.g)  Has = the Document Shepherd personally verified that the
   &nb= sp;      document satisfies all ID nits?  (Se= e
          http://www.ietf.= org/ID-Checklist.html and
     = ;     http://tools.ietf.org/tools/idnits/).  Boilerplat= e checks are
          not e= nough; this check needs to be thorough.  Has the document
 &nb= sp;        met all formal review criteri= a it needs to, such as the MIB
       = ;   Doctor, media type and URI type reviews?

  &= nbsp;         No issues found.
<= br>   (1.h)  Has the document split its references into norm= ative and
          informa= tive?  Are there normative references to documents that
  = ;        are not ready for advancement o= r are otherwise in an unclear
       =    state?  If such normative references exist, what is the          strategy for their completion?  Are there normative references
   &nbs= p;      that are downward references, as described= in [RFC3967]?  If
        =   so, list these downward references to support the Area
 &nbs= p;        Director in the Last Call proc= edure for them [RFC3967].

       =      No issues here.

   (1.i)  Ha= s the Document Shepherd verified that the document IANA
  &nbs= p;       consideration section exists and is = consistent with the body
        = ;  of the document?  If the document specifies protocol
 =          extensions, are reservatio= ns requested in appropriate IANA
          registries?=   Are the IANA registries clearly identified?  If
  =         the document creates a new regis= try, does it define the
        =   proposed initial contents of the registry and an allocation
 = ;         procedure for future regi= strations?  Does it suggested a
      = ;    reasonable name for the new registry?  See
&nbs= p;         [I-D.narten-iana-conside= rations-rfc2434bis].  If the document
     = ;     describes an Expert Review process has Shepherd c= onferred with
          the= Responsible Area Director so that the IESG can appoint the
          needed Exper= t during the IESG Evaluation?

      &n= bsp;     IANA section does not require any actions.
=
   (1.j)  Has the Document Shepherd verified that sectio= ns of the
          documen= t that are written in a formal language, such as XML
   &= nbsp;      code, BNF rules, MIB definitions, etc.,= validate correctly in
        &= nbsp; an automated checker?

      &nbs= p;     No such sections.

   (1.k) = ; The IESG approval announcement includes a Document
   &= nbsp;      Announcement Write-Up.  Please pro= vide such a Document
        &nb= sp; Announcement Writeup?  Recent examples can be found in the
 &= nbsp;        "Action" announcements for = approved documents.  The approval
     &nb= sp;    announcement contains the following sections:

=           Technical Summary
            Th= is document specifies the addressing and operation of IPv6 over
 &n= bsp;          the IPv6 specifi= c part of the packet CS for hosts served by a
    &n= bsp;       network that utilizes the IEEE Std= 802.16 air interface. It
       &nbs= p;    recommends the assignment of a unique prefix (or prefi= xes) to each
          = ;  host and allows the host to use multiple identifiers within that
  = ;          prefix, including s= upport for randomly generated identifiers.


   &nb= sp;      Working Group Summary

  =           There was much initi= al debate about the link model to adopt.
     &= nbsp;      The interim made it clear that the "per= -MS" prefix was
         &n= bsp;  preferable. Beyond that, there has been debate about how much            802.16-= specific details to include (e.g., on network entry
   &n= bsp;        procedure) for clarity.
<= br>          Document Quality

          = ;  There are no currently known implementations of this document.
&= nbsp;           However, = the per-MS prefix model has been deployed in 3GPP, so
   = ;         at least that part is kno= wn to work, and this was a major point
     &nb= sp;      in deciding in its favor. The WiMax forum= sees this document as one
       &nb= sp;    of its pilars, so it is expected that it will see sig= nificant
          &n= bsp; deployment within the next years.

     = ;     Personnel
      =        Who is the Document Shepherd for this document?  Who is the
       &n= bsp;     Responsible Area Director?

  =             &nb= sp; Shepherd: Gabriel Montenegro
      &nb= sp;          AD: Jari Arkko

--0-1856296869-1169107341=:8389-- --===============1495530351== 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 --===============1495530351==-- From 16ng-bounces@ietf.org Thu Jan 18 06:23:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VMB-0003o0-9N; Thu, 18 Jan 2007 06:22:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VM9-0003nH-Q4 for 16ng@ietf.org; Thu, 18 Jan 2007 06:22:57 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7VM8-0000w3-EQ for 16ng@ietf.org; Thu, 18 Jan 2007 06:22:57 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1169119375!9655240!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 3882 invoked from network); 18 Jan 2007 11:22:55 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-10.tower-119.messagelabs.com with SMTP; 18 Jan 2007 11:22:55 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l0IBMsCr029069; Thu, 18 Jan 2007 04:22:54 -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 l0IBMqdE027304; Thu, 18 Jan 2007 05:22:53 -0600 (CST) Message-ID: <45AF588B.6000706@motorola.com> Date: Thu, 18 Jan 2007 12:22:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: gabriel montenegro Subject: Re: [16NG] Re: multicast and IPv6 over ETHCS References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> In-Reply-To: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 gabriel montenegro wrote: > Alex, > > The statement below is not true: > > I meant links with link-layer headers. > > Reading ND it says "node MUST join" before receiving an RA. 'Join' > can happen only if that link is multicast-capable. > > 802.15.4 (a link with link-layer header) has no multicast capability > (only broadcast) at the link layer. Yet IPv6 can work fine. Gabriel, on one hand I completely agree that IPv6 can work in practice on a wide variety of links. On another hand - ND - may be different. Its section 6.3.3 Interface Initialization says: > The host joins the all-nodes multicast address on all multicast- > capable interfaces. If 802.15.4 interface is attached to a router the same rfc2461 uses the stronger MUST, section 6.2.2 rfc2461 Becoming an Advertising Interface: > A router MUST join the all-routers multicast address on an > advertising interface. Routers respond to Router Solicitations sent > to the all-routers address and verify the consistency of Router > Advertisements sent by neighboring routers. So depending on how that reads the 'join' word, and how one interprets IPv6 _can_ run on a specific link (does IPv6 include ND?) one can make different conclusions. > Of course, if one wants to optimize, one can do several things (e.g., > controlled flooding, sending along a spanning tree, etc), but > neither is this required nor does the link layer have any concept of > multicast. > > Wouldn't it be enough to simply say that multicast address mapping is > done per http://tools.ietf.org/html/rfc2464? Yes RFC2464. And as per RFC4291 (IPv6 Addressing Arch) and as per RFC3810 (MLDv2) and as per RFC4489 (method for link-scope IPv6 multicast addresses). The four RFCs contain different IPv6 link-local multicast addresses that an implementation should do. These specs are disjoint (for example only MLDv2 requires joining ff02::16 and only 4291 describes the solicited-node mapping). Ie it's not sufficient to refer to only one spec. Out of these 4 essential RFCs for IPv6 link-local multicast currently the draft cites only 2464. I think if we want to be in alignment with how IPv6 specs we should also think the IPv6 Scoped Address Architecture RFC4007, which defines the scopes for link-local multicast. Ie IP-over-ETHCS should specify the extent of the link-local scope and zone. Currently IPv6-over-ETHCS doesn't talk about this. And we should also probably think anycast. Several anycast aspects are mandatory for IPv6. Off of the top of my head I can think of the reserved subnet anycast address and the Home-Agents anycast address as of RFC2526. Currently IPv6-over-ETHCS doesn't talk about this. > Should be obvious, but perhaps this is worth noting? All the RFCs above are Standards Track. I see lots of value of at least referring to them. I also see value in shortly describing what their recommendations are and how or why IPv6-over-ETHCS should follow them or tresspass them. I do not recommend being silent about those RFCs. > Because this is so, regular IP-level join protocols work fine (e.g., > MLD), no need to say more. You also mention elsewhere that a > link-level "join" for multicast is necessary. This is not so. 2461 says a host joins and a router MUST join. This apparent discrepancy between your oppinion and mine is probably to be solved by suggesting that the 'join' action can happen by either sending a MLD REPORT or by setting up a local filtering rule or by sending a link-layer multicast-intent or multicast-dest message. Do you agree with this interpretation? Do you agree this is complete interpretation of that 'join' word and no other way can happen a 'join'? > Notice that if a link layer simply floods all multicast packets > (essentially using broadcast), things work fine. The IP layer itself > will do the filtering. Yes, but in that case we must specify that the IP layer must receive all packets addressed to the 'flooding' address, which is a link-layer multicast address. I can explain why we need to put this on paper. Usually flooding means send to link-layer broadcast address ff:ff:ff:ff:ff:ff. But that broadcast address is for IPv4 only, not for IPv6. IPv6 implementations don't know about that ff:ff:ff:ff:ff:ff link-layer address. So I agree flooding can happen, but we need to be specific on how it happens: is it to 12-fs or to 33:33:0:0:0:1? This question is particularly relevant in a draft covering both IPv4 and IPv6. > The link-layer can do filtering to avoid flooding mcast as if it were > bcast, but it's just an optimization. I agree link-layer can do filtering to avoid flooding mcast, and that's an optimization. So we may write it as a MAY. I called this 'local filtering rules' in my text. > Now, 802.1D does propose such a link-layer optimization (IGRP/GARP), > but probably cuz this requires support at the clients (or perhaps for > other reasons as well), this is not actually deployed, and yet things > work fine over ethernet. Instead, the optimization to avoid flooding > is possible because IPv4 and IPv6 procedures are followed for joins > (IGMP, MLD) independently of link-layer. Typically, snooping of those > sets state at the link-layer to achieve the desired (not required) > optimization. Ok. Makes sense in a certain perspective. I agree making 'snooping' a recommendation to make work link-layer multicast and I think I'll want to look into 802.1q and spanning tree protocol to see whether it's worth mentioning too. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 18 06:25:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VOE-00054E-Bc; Thu, 18 Jan 2007 06:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7VOC-000547-VA for 16ng@ietf.org; Thu, 18 Jan 2007 06:25:04 -0500 Received: from mail125.messagelabs.com ([85.158.136.35]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7VOB-0001D3-IE for 16ng@ietf.org; Thu, 18 Jan 2007 06:25:04 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-14.tower-125.messagelabs.com!1169119501!15023502!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 10481 invoked from network); 18 Jan 2007 11:25:02 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-14.tower-125.messagelabs.com with SMTP; 18 Jan 2007 11:25:02 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0IBP1Us002817; Thu, 18 Jan 2007 04:25:01 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0IBOx8P003638; Thu, 18 Jan 2007 05:25:00 -0600 (CST) Message-ID: <45AF590A.2000005@motorola.com> Date: Thu, 18 Jan 2007 12:24:58 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> 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: de4f315c9369b71d7dd5909b42224370 Cc: 16ng@ietf.org Subject: [16NG] Re: flloding multicast and IPv6 over ETHCS 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 Jihoon Lee wrote: > Gabriel, > >> Notice that if a link layer simply floods all multicast packets >> (essentially using broadcast), things work fine. > > Let's focus on the main issue. As I know, we started to discuss this > problem, because of the lack of flooding function (surely including > multicast) between MSs (uplink) in 802.16 MAC layer. So, we're trying > to discuss this problem regarding IPv6overETHCS. I think for IPv6, 'flooding' means sending to the link-layer multicast address 33:33::1. Do you agree? Do you think there's another link-layer multicast address that does this flooding? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 18 10:16:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Z0B-0001vC-9u; Thu, 18 Jan 2007 10:16:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7Z09-0001v7-Cb for 16ng@ietf.org; Thu, 18 Jan 2007 10:16:29 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7Z05-00072q-B6 for 16ng@ietf.org; Thu, 18 Jan 2007 10:16:29 -0500 Received: by nz-out-0506.google.com with SMTP id z6so179043nzd for <16ng@ietf.org>; Thu, 18 Jan 2007 07:16:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=XRtc7jfWOVtsHCav7o5n2NS7Rd7acV8cmaJ5SI1ly7Yu7cViMrb+EI5C1mpQVQKgUX6m3m3Ggu1Av/1KkuhjJPinn2h/JQ+JH5MwdRvPMpGDR9GTD+bDp50RmX6YYMIagn57GpOKq7SUD659Ctmyp0zhUn2/1AifzAkZGUiL8Rs= Received: by 10.65.112.5 with SMTP id p5mr1047666qbm.1169133384879; Thu, 18 Jan 2007 07:16:24 -0800 (PST) Received: by 10.65.225.19 with HTTP; Thu, 18 Jan 2007 07:16:24 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 00:16:24 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45AF590A.2000005@motorola.com> MIME-Version: 1.0 References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> <45AF590A.2000005@motorola.com> X-Google-Sender-Auth: 0c4814f51717601f X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: 16ng@ietf.org Subject: [16NG] Re: flloding multicast and IPv6 over ETHCS 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="===============0845976580==" Errors-To: 16ng-bounces@ietf.org --===============0845976580== Content-Type: multipart/alternative; boundary="----=_Part_83685_1079822.1169133384621" ------=_Part_83685_1079822.1169133384621 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, My comments inline. Best regards, Jihoon 2007/1/18, Alexandru Petrescu : > > Jihoon Lee wrote: > > Gabriel, > > > >> Notice that if a link layer simply floods all multicast packets > >> (essentially using broadcast), things work fine. > > > > Let's focus on the main issue. As I know, we started to discuss this > > problem, because of the lack of flooding function (surely including > > multicast) between MSs (uplink) in 802.16 MAC layer. So, we're trying > > to discuss this problem regarding IPv6overETHCS. > > I think for IPv6, 'flooding' means sending to the link-layer multicast > address 33:33::1. Do you agree? Yes, I do. > Do you think there's another link-layer multicast address that does this > flooding? No, I don't > Alex > > ------=_Part_83685_1079822.1169133384621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 
Hi Alex,
 
My comments inline.
 
Best regards,
Jihoon
 
2007/1/18, Alexandru Petrescu <alexandru.petrescu@motorola.com >:
Jihoon Lee wrote:
> Gabriel,
>
>> Notice that if a link layer simply floods all multicast packets
>> (essentially  using broadcast), things work fine.
>
> Let's focus on the main issue. As I know, we started to discuss this
> problem, because of the lack of flooding function (surely including
> multicast) between MSs (uplink) in 802.16 MAC layer. So, we're trying
> to discuss this problem regarding IPv6overETHCS.

I think for IPv6, 'flooding' means sending to the link-layer multicast
address 33:33::1.  Do you agree?  
 
Yes, I do.  
 
Do you think there's another link-layer multicast address that does this flooding?
 
No, I don't
 
Alex


------=_Part_83685_1079822.1169133384621-- --===============0845976580== 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 --===============0845976580==-- From 16ng-bounces@ietf.org Thu Jan 18 11:31:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aAY-00018d-Ny; Thu, 18 Jan 2007 11:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7aAX-00018Y-Gj for 16ng@ietf.org; Thu, 18 Jan 2007 11:31:17 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7aAU-0003S9-6L for 16ng@ietf.org; Thu, 18 Jan 2007 11:31:17 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1169137873!19455845!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 27984 invoked from network); 18 Jan 2007 16:31:13 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-13.tower-119.messagelabs.com with SMTP; 18 Jan 2007 16:31:13 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l0IGVCuk016056; Thu, 18 Jan 2007 09:31:13 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0IGV9iN026337; Thu, 18 Jan 2007 10:31:10 -0600 (CST) Message-ID: <45AFA0CD.8080103@motorola.com> Date: Thu, 18 Jan 2007 17:31:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> <45AF590A.2000005@motorola.com> 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 Subject: [16NG] Re: flloding multicast and IPv6 over ETHCS 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 Jihoon, Jihoon Lee wrote: > > Hi Alex, > > My comments inline. > > Best regards, Jihoon > > 2007/1/18, Alexandru Petrescu >: > > Jihoon Lee wrote: >> Gabriel, >> >>> Notice that if a link layer simply floods all multicast packets >>> (essentially using broadcast), things work fine. >> >> Let's focus on the main issue. As I know, we started to discuss >> this problem, because of the lack of flooding function (surely >> including multicast) between MSs (uplink) in 802.16 MAC layer. So, >> we're trying to discuss this problem regarding IPv6overETHCS. > > I think for IPv6, 'flooding' means sending to the link-layer > multicast address 33:33::1. Do you agree? > > > Yes, I do. > > > Do you think there's another link-layer multicast address that does > this flooding? > > > No, I don't I think thus we can define *IPv6 flooding* as being IPv6 packets sent over ETHCS (or over the bridge 'device' in the system deploying the ETHCS for transmitting Ethernet frames over IEEE802.16), and addressed to the link-layer address 33:33:0:0:0:1. More specifically, we can define it as being packets addressed to any link-layer address prefixed by 33:33 (see the post-scriptum why). I think we have that definition ok. I think we need to identify what are the means to avoid flooding. Otherwise, you seem to say we need to discuss the problem of lack of flooding function in 802.16. What do you mean? Alex PS: many other link-layer link-local addresses are candidates of being flooded. There may be questions about whether 33:33:0:0:0:2 (not 1) can be target of an IPv6 multicast link-local flood. The way to build a link-layer multicast address from an IPv6 multicast address is specified in rfc2464 sec 7. If the IPv6 link-local multicast address is ff02::1 then the link-layer multicast address is 33:33:0:0:0:1. RFC4291 (addr arch) says that there can be several IPv6 multicast addresses interface-local or link-local: ff01::1 and ff02::1 (all-nodes); and ff01::2 and ff02::2 (all-routers). Thus one is tempted to think packets sent 33:33:0:0:0:2 (not 1) - all-routers - is a potential target for flooding too. Correspondingly, if we use MLDv2, then floods can happen to 33:33::16 (:16 !) too, flooding all MLDv2-capable nodes. Floods could happen to 33:33:ff:xx:xx:xx too, the solicited-node address. Floods could happen to 33:33::1:1 too (flood all NTP servers, relevant if IEEE 802.16 decides to use NTP in the future, instead of current TIME). Floods could happen to 33:33::1:2 (all-dhcp-relays-servers) and to 33:33::1:3 (all-dhcp-servers), too. http://www.iana.org/assignments/ipv6-multicast-addresses lists all multicast addresses out of which one could derive 33:33 multicast addresses potential targets for flooding. One could find some orthodox protocols such as DVMRP, OSPF or other less orthodox names such as ST, UPnP or Mobile-Agents. This would reduce our definition of flooding as being addressed to 33:33::1 link-layer address to wider definition of flooding being packets addressed to _any_ link-layer address prefixed by 33:33. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 18 16:01:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eO5-0005Qv-07; Thu, 18 Jan 2007 16:01:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7eMY-0003Do-SV for 16ng@ietf.org; Thu, 18 Jan 2007 15:59:58 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7eH5-0006rN-2k for 16ng@ietf.org; Thu, 18 Jan 2007 15:54:42 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-2.tower-128.messagelabs.com!1169153657!922042!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10924 invoked from network); 18 Jan 2007 20:54:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-128.messagelabs.com with SMTP; 18 Jan 2007 20:54:18 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0IKsHga012462; Thu, 18 Jan 2007 13:54:17 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0IKsFnk022300; Thu, 18 Jan 2007 14:54:16 -0600 (CST) Message-ID: <45AFDE76.7070809@motorola.com> Date: Thu, 18 Jan 2007 21:54:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A54ED7.9020203@motorola.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> 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: 52f7a77164458f8c7b36b66787c853da Cc: 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation (was: and IPv6 over ETHCS) 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 Jihoon Lee wrote: > Assumption: IPv6 ND messages cannot be transmitted to other MSs served > by the same BS without any additional supporting function. > > 1) 802.16 BS support a local multicast function. (How? keep this open. > Where? Inside BS. maybe a function implemented over ETHCS.) This > supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering > them to a bridge or an AR. > 2) There is a bridge between BSs and ARs. Firstly, the bridge relays > (multicasts) IPv6 ND messages except for the source MS. > Then, it delivers to AR. (How? keep this open. Where? bridge and AR in > case of utilizing VLAN ). > 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND > messages to other MSs except for the source MS. (How? keep this > open. Where? AR). > 4) ... Jihoon, let me try to focus on the above text and motivate why I said it would go in an Appendix. I am against the assumption in step 3 that only GRE tunnel can be used for a 802.16 deployment. Other tunnels can do the trick too - L2TPv3 RFC4719 is designed exactly to transport Ethernet over IP. IEEE802.16 spec doesn't require GRE (search doesn't hit word 'GRE'). That's why I think step 3 should be preceded by a big MAY. The structuring of steps you present above makes sense to me, in that functionalities are left open with How - keep open. From your above text I also understand that only BS and AR behaviours are enhanced. I think you don't think SS or MS should do anything special to run a special IPv6 over ETHCS. What do you think? I am personally interested only on what happens on the SS, I can contribute to that. So I could look for an enhancement for IPv6-over-ETHCS on SS. For example, we could require IPv6 stack on SS to (1) do MLD REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then (3) transmit an unsolicited 802.16 MCA-RSP message (not MLD REPORT) to BS. The steps 1 and 2 are existing art, rfc2461 and rfc2464. The step 3 is art in 802.16MAC. The sequence of the three steps is novelty for IPv6-over-ETHCS document. What do you think? We could alternatively require the IPv6 stack on SS to (1) do MLD REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then don't transmit the unsolicited MCA-RSP to BS but set up a uplink classifier rule in ETHCS. Subsequent to that, any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 stack. We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU that doesn't have such a uplink classifier rule within ETHCS. This should be achieved according to IEEE spec, not enhancement. It could be done by having the output of that uplink classifier rule to go to a CID that is void or nil or non-existent. In this way we could be ok with the IEEESpec (not modify it, not tresspass it). I think in all cases we don't want the IPv6 stack on SS to receive multicast packets for which it hasn't joined, because this augments the risk of bad flooding effects. What do you think about GRE/L2TP? And about SS IPv6 multicast enhancements? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 18 16:42:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7f1X-00072w-KV; Thu, 18 Jan 2007 16:42:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7f1W-00071d-84 for 16ng@ietf.org; Thu, 18 Jan 2007 16:42:18 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7f1T-0006vf-Jt for 16ng@ietf.org; Thu, 18 Jan 2007 16:42:18 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l0ILgB6t010463; Thu, 18 Jan 2007 22:42:11 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id l0ILgB9m030368; Thu, 18 Jan 2007 22:42:11 +0100 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 22:42:10 +0100 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] Re: stepped multicast operation (was: and IPv6 over ETHCS) Date: Thu, 18 Jan 2007 22:42:09 +0100 Message-ID: <4BB931F00625F54DA8B8563E5A5CA25A013471CB@MCHP7I6A.ww002.siemens.net> In-Reply-To: <45AFDE76.7070809@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [16NG] Re: stepped multicast operation (was: and IPv6 over ETHCS) Thread-Index: Acc7RBANZBNS0Hp9TDGE0RiLMCjBEQABHc+Q From: "Riegel, Maximilian" To: "Alexandru Petrescu" , "Jihoon Lee" X-OriginalArrivalTime: 18 Jan 2007 21:42:10.0938 (UTC) FILETIME=[8260C5A0:01C73B49] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Usage of GRE is a WiMAX specific implementation choice of connecting BSs with the bridge and this GRE tunnels should not appear anymore in future revisions of the IPoETH draft. The specification can well be written without mentioning 'GRE'. There are many other solutions possible for connecting BSs with a bridge and the draft should be not specific to one particular implementation. Bye Max -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: Thursday, January 18, 2007 9:54 PM To: Jihoon Lee Cc: 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation (was: and IPv6 over ETHCS) Jihoon Lee wrote: > Assumption: IPv6 ND messages cannot be transmitted to other MSs served > by the same BS without any additional supporting function. > =20 > 1) 802.16 BS support a local multicast function. (How? keep this open. > Where? Inside BS. maybe a function implemented over ETHCS.) This=20 > supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering=20 > them to a bridge or an AR. > 2) There is a bridge between BSs and ARs. Firstly, the bridge relays=20 > (multicasts) IPv6 ND messages except for the source MS.=20 > Then, it delivers to AR. (How? keep this open. Where? bridge and AR in > case of utilizing VLAN ). > 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND=20 > messages to other MSs except for the source MS. (How? keep this=20 > open. Where? AR). > 4) ... Jihoon, let me try to focus on the above text and motivate why I said it would go in an Appendix. I am against the assumption in step 3 that only GRE tunnel can be used for a 802.16 deployment. Other tunnels can do the trick too - L2TPv3 RFC4719 is designed exactly to transport Ethernet over IP. IEEE802.16 spec doesn't require GRE (search doesn't hit word 'GRE'). That's why I think step 3 should be preceded by a big MAY. The structuring of steps you present above makes sense to me, in that functionalities are left open with How - keep open. From your above text I also understand that only BS and AR behaviours are enhanced. I think you don't think SS or MS should do anything special to run a special IPv6 over ETHCS. What do you think? I am personally interested only on what happens on the SS, I can contribute to that. So I could look for an enhancement for IPv6-over-ETHCS on SS. For example, we could require IPv6 stack on SS to (1) do MLD REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then (3) transmit an unsolicited 802.16 MCA-RSP message (not MLD REPORT) to BS. The steps 1 and 2 are existing art, rfc2461 and rfc2464. The step 3 is art in 802.16MAC. The sequence of the three steps is novelty for IPv6-over-ETHCS document. What do you think? We could alternatively require the IPv6 stack on SS to (1) do MLD REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then don't transmit the unsolicited MCA-RSP to BS but set up a uplink classifier rule in ETHCS. Subsequent to that, any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 stack. We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU that doesn't have such a uplink classifier rule within ETHCS. This should be achieved according to IEEE spec, not enhancement. It could be done by having the output of that uplink classifier rule to go to a CID that is void or nil or non-existent. In this way we could be ok with the IEEESpec (not modify it, not tresspass it). I think in all cases we don't want the IPv6 stack on SS to receive multicast packets for which it hasn't joined, because this augments the risk of bad flooding effects. What do you think about GRE/L2TP? And about SS IPv6 multicast enhancements? Alex _______________________________________________ 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 Thu Jan 18 18:29:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7ggf-0003Vh-Lk; Thu, 18 Jan 2007 18:28:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7gge-0003Vb-E0 for 16ng@ietf.org; Thu, 18 Jan 2007 18:28:52 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7ggd-0006Tb-S8 for 16ng@ietf.org; Thu, 18 Jan 2007 18:28:52 -0500 Received: by nz-out-0506.google.com with SMTP id z6so296586nzd for <16ng@ietf.org>; Thu, 18 Jan 2007 15:28:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=X3EBKW+l1DnrW/hnvC42oQrLaXfioNlGEygFGMDfxFieqrsDAqVyy+GUw3UCg/oef+7gEr4z2cU8oN4rkDxgFot2L+Lr3HzpNouWDBEw0suYURRicoFrIT3ujaVCD/z7h73IzNekoOzTctmM/iZW/cjLoJdub0F/H9oXKtEYb7w= Received: by 10.64.204.19 with SMTP id b19mr1894685qbg.1169162931391; Thu, 18 Jan 2007 15:28:51 -0800 (PST) Received: by 10.65.225.19 with HTTP; Thu, 18 Jan 2007 15:28:49 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 08:28:49 +0900 From: "Jihoon Lee" To: "Riegel, Maximilian" Subject: Re: [16NG] Re: stepped multicast operation (was: and IPv6 over ETHCS) In-Reply-To: <4BB931F00625F54DA8B8563E5A5CA25A013471CB@MCHP7I6A.ww002.siemens.net> MIME-Version: 1.0 References: <45AFDE76.7070809@motorola.com> <4BB931F00625F54DA8B8563E5A5CA25A013471CB@MCHP7I6A.ww002.siemens.net> X-Google-Sender-Auth: ae73cb3288b9ef22 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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="===============1987044952==" Errors-To: 16ng-bounces@ietf.org --===============1987044952== Content-Type: multipart/alternative; boundary="----=_Part_89221_9367177.1169162929609" ------=_Part_89221_9367177.1169162929609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Max, Yes, you're right. I'm not gonna use that word. Thanks, Jihoon 2007/1/19, Riegel, Maximilian : > > Usage of GRE is a WiMAX specific implementation choice of connecting BSs > with the bridge and this GRE tunnels should not appear anymore in future > revisions of the IPoETH draft. The specification can well be written > without mentioning 'GRE'. > > There are many other solutions possible for connecting BSs with a bridge > and the draft should be not specific to one particular implementation. > > Bye > Max > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Thursday, January 18, 2007 9:54 PM > To: Jihoon Lee > Cc: 16ng@ietf.org > Subject: [16NG] Re: stepped multicast operation (was: and IPv6 over > ETHCS) > > Jihoon Lee wrote: > > Assumption: IPv6 ND messages cannot be transmitted to other MSs served > > > by the same BS without any additional supporting function. > > > > 1) 802.16 BS support a local multicast function. (How? keep this open. > > > Where? Inside BS. maybe a function implemented over ETHCS.) This > > supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering > > them to a bridge or an AR. > > 2) There is a bridge between BSs and ARs. Firstly, the bridge relays > > (multicasts) IPv6 ND messages except for the source MS. > > Then, it delivers to AR. (How? keep this open. Where? bridge and AR in > > > case of utilizing VLAN ). > > 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND > > messages to other MSs except for the source MS. (How? keep this > > open. Where? AR). > > 4) ... > > Jihoon, let me try to focus on the above text and motivate why I said it > would go in an Appendix. > > I am against the assumption in step 3 that only GRE tunnel can be used > for a 802.16 deployment. Other tunnels can do the trick too - L2TPv3 > RFC4719 is designed exactly to transport Ethernet over IP. IEEE802.16 > spec doesn't require GRE (search doesn't hit word 'GRE'). That's > why I think step 3 should be preceded by a big MAY. > > The structuring of steps you present above makes sense to me, in that > functionalities are left open with How - keep open. > > From your above text I also understand that only BS and AR behaviours > are enhanced. I think you don't think SS or MS should do anything > special to run a special IPv6 over ETHCS. What do you think? > > I am personally interested only on what happens on the SS, I can > contribute to that. > > So I could look for an enhancement for IPv6-over-ETHCS on SS. > > For example, we could require IPv6 stack on SS to (1) do MLD REPORT for > IPv6 link-local address ff02::1, (2) map to 33:33::1, and then (3) > transmit an unsolicited 802.16 MCA-RSP message (not MLD REPORT) to BS. > The steps 1 and 2 are existing art, rfc2461 and rfc2464. The step 3 is > art in 802.16MAC. The sequence of the three steps is novelty for > IPv6-over-ETHCS document. What do you think? > > We could alternatively require the IPv6 stack on SS to (1) do MLD REPORT > for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then don't > transmit the unsolicited MCA-RSP to BS but set up a uplink classifier > rule in ETHCS. Subsequent to that, any PDU received by ETHCS that has > dst 33:33::1 goes to the IPv6 stack. We would require the SS's ETHCS to > not put to SS's IPv6 stack a PDU that doesn't have such a uplink > classifier rule within ETHCS. This should be achieved according to IEEE > spec, not enhancement. It could be done by having the output of that > uplink classifier rule to go to a CID that is void or nil or > non-existent. In this way we could be ok with the IEEESpec (not modify > it, not tresspass it). > > I think in all cases we don't want the IPv6 stack on SS to receive > multicast packets for which it hasn't joined, because this augments the > risk of bad flooding effects. > > What do you think about GRE/L2TP? And about SS IPv6 multicast > enhancements? > > Alex > > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng > ------=_Part_89221_9367177.1169162929609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Max,
Yes, you're right. I'm not gonna use that word.
 
Thanks,
Jihoon

 
2007/1/19, Riegel, Maximilian <maximilian.riegel@siemens.com>:
Usage of GRE is a WiMAX specific implementation choice of connecting BSs
with the bridge and this GRE tunnels should not appear anymore in future
revisions of the IPoETH draft. The specification can well be written
without mentioning 'GRE'.

There are many other solutions possible for connecting BSs with a bridge
and the draft should be not specific to one particular implementation.

Bye
Max

-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]
Sent: Thursday, January 18, 2007 9:54 PM
To: Jihoon Lee
Cc: 16ng@ietf.org
Subject: [16NG] Re: stepped multicast operation (was: and IPv6 over
ETHCS)

Jihoon Lee wrote:
> Assumption: IPv6 ND messages cannot be transmitted to other MSs served

> by the same BS without any additional supporting function.
>
> 1) 802.16 BS support a local multicast function. (How? keep this open.

> Where? Inside BS. maybe a function implemented over ETHCS.) This
> supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering
> them to a bridge or an AR.
> 2) There is a bridge between BSs and ARs. Firstly, the bridge relays
> (multicasts) IPv6 ND messages except for the source MS.
> Then, it delivers to AR. (How? keep this open. Where? bridge and AR in

> case of utilizing VLAN ).
> 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND
> messages to other MSs except for the source MS. (How? keep this
> open. Where? AR).
> 4) ...

Jihoon, let me try to focus on the above text and motivate why I said it
would go in an Appendix.

I am against the assumption in step 3 that only GRE tunnel can be used
for a 802.16 deployment. Other tunnels can do the trick too - L2TPv3
RFC4719 is designed exactly to transport Ethernet over IP. IEEE802.16
spec doesn't require GRE (search doesn't hit word 'GRE'). That's
why I think step 3 should be preceded by a big MAY.

The structuring of steps you present above makes sense to me, in that
functionalities are left open with How - keep open.

From your above text I also understand that only BS and AR behaviours
are enhanced. I think you don't think SS or MS should do anything
special to run a special IPv6 over ETHCS. What do you think?

I am personally interested only on what happens on the SS, I can
contribute to that.

So I could look for an enhancement for IPv6-over-ETHCS on SS.

For example, we could require IPv6 stack on SS to (1) do MLD REPORT for
IPv6 link-local address ff02::1, (2) map to 33:33::1, and then (3)
transmit an unsolicited 802.16 MCA-RSP message (not MLD REPORT) to BS.
The steps 1 and 2 are existing art, rfc2461 and rfc2464. The step 3 is
art in 802.16MAC. The sequence of the three steps is novelty for
IPv6-over-ETHCS document. What do you think?

We could alternatively require the IPv6 stack on SS to (1) do MLD REPORT
for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then don't
transmit the unsolicited MCA-RSP to BS but set up a uplink classifier
rule in ETHCS. Subsequent to that, any PDU received by ETHCS that has
dst 33:33::1 goes to the IPv6 stack. We would require the SS's ETHCS to
not put to SS's IPv6 stack a PDU that doesn't have such a uplink
classifier rule within ETHCS. This should be achieved according to IEEE
spec, not enhancement. It could be done by having the output of that
uplink classifier rule to go to a CID that is void or nil or
non-existent. In this way we could be ok with the IEEESpec (not modify
it, not tresspass it).

I think in all cases we don't want the IPv6 stack on SS to receive
multicast packets for which it hasn't joined, because this augments the
risk of bad flooding effects.

What do you think about GRE/L2TP? And about SS IPv6 multicast
enhancements?

Alex


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

------=_Part_89221_9367177.1169162929609-- --===============1987044952== 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 --===============1987044952==-- From 16ng-bounces@ietf.org Thu Jan 18 19:43:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7hqw-0006LQ-EL; Thu, 18 Jan 2007 19:43:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7hqv-0006LL-56 for 16ng@ietf.org; Thu, 18 Jan 2007 19:43:33 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7hqr-0002HZ-Jt for 16ng@ietf.org; Thu, 18 Jan 2007 19:43:33 -0500 Received: by nz-out-0506.google.com with SMTP id z6so309517nzd for <16ng@ietf.org>; Thu, 18 Jan 2007 16:43:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gG+qRw6awz9oLbfuJ0Fh36hUWQjJ6LAU16T07zixooqfXYj4KTh8lYH4jiQ1NGAtc9VaW3FLit9lFez6mjFiTMReEWazhybugpBzM9JQTgDiJEaxhL6y3W9EdXZCl+D282VZ5lij5UyLL7yMj8qkkfcYtfdDBhun5NspqA3f3tU= Received: by 10.65.23.3 with SMTP id a3mr1973422qbj.1169167408846; Thu, 18 Jan 2007 16:43:28 -0800 (PST) Received: by 10.65.225.19 with HTTP; Thu, 18 Jan 2007 16:43:28 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 09:43:28 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45AFA0CD.8080103@motorola.com> MIME-Version: 1.0 References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> <45AF590A.2000005@motorola.com> <45AFA0CD.8080103@motorola.com> X-Google-Sender-Auth: 379e3a1add0bbce3 X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: 16ng@ietf.org Subject: [16NG] Re: flloding multicast and IPv6 over ETHCS 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="===============1543323971==" Errors-To: 16ng-bounces@ietf.org --===============1543323971== Content-Type: multipart/alternative; boundary="----=_Part_89637_28951636.1169167408795" ------=_Part_89637_28951636.1169167408795 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, > More specifically, we can define it as being packets addressed to any > link-layer address prefixed by 33:33 (see the post-scriptum why). Sure. I agree. To support IPv6 transparently over ETHCS over 802.16, multicasting (or broadcasting) packets in both directions of which MAC addresses are 33:33:x:x:x:x is sufficient. > I think we need to identify what are the means to avoid flooding. I'm sorry, I don't know what you're referring to. Anyway, I presume that you mean that flooding (i.e., broadcast) is inefficient in terms of bandwidth usage comparing to multicast. Am I correct? As Gabriel said before, it's about efficiency. IMHO, supporting either multicast or broadcast (just flood 33:33:x:x:x:x packets) should be fine. > Otherwise, you seem to say we need to discuss the problem of lack of > flooding function in 802.16. What do you mean? I just pointed out there was no uplink broadcast as well as multicast in 802.16 PMP(point-to-multipoint) mode. Best regards, Brandon 2007/1/19, Alexandru Petrescu : > > Hi Jihoon, > > Jihoon Lee wrote: > > > > Hi Alex, > > > > My comments inline. > > > > Best regards, Jihoon > > > > 2007/1/18, Alexandru Petrescu > >: > > > > Jihoon Lee wrote: > >> Gabriel, > >> > >>> Notice that if a link layer simply floods all multicast packets > >>> (essentially using broadcast), things work fine. > >> > >> Let's focus on the main issue. As I know, we started to discuss > >> this problem, because of the lack of flooding function (surely > >> including multicast) between MSs (uplink) in 802.16 MAC layer. So, > >> we're trying to discuss this problem regarding IPv6overETHCS. > > > > I think for IPv6, 'flooding' means sending to the link-layer > > multicast address 33:33::1. Do you agree? > > > > > > Yes, I do. > > > > > > Do you think there's another link-layer multicast address that does > > this flooding? > > > > > > No, I don't > > I think thus we can define *IPv6 flooding* as being IPv6 packets sent > over ETHCS (or over the bridge 'device' in the system deploying the > ETHCS for transmitting Ethernet frames over IEEE802.16), and addressed > to the link-layer address 33:33:0:0:0:1. > > More specifically, we can define it as being packets addressed to any > link-layer address prefixed by 33:33 (see the post-scriptum why). I think we have that definition ok. I think we need to identify what > are the means to avoid flooding. > > Otherwise, you seem to say we need to discuss the problem of lack of > flooding function in 802.16. What do you mean? > > Alex > > PS: many other link-layer link-local addresses are candidates of being > flooded. > > There may be questions about whether 33:33:0:0:0:2 (not 1) can be target > of an IPv6 multicast link-local flood. > > The way to build a link-layer multicast address from an IPv6 multicast > address is specified in rfc2464 sec 7. If the IPv6 link-local multicast > address is ff02::1 then the link-layer multicast address is > 33:33:0:0:0:1. RFC4291 (addr arch) says that there can be several IPv6 > multicast addresses interface-local or link-local: ff01::1 and ff02::1 > (all-nodes); and ff01::2 and ff02::2 (all-routers). > > Thus one is tempted to think packets sent 33:33:0:0:0:2 (not 1) - > all-routers - is a potential target for flooding too. > > Correspondingly, if we use MLDv2, then floods can happen to 33:33::16 > (:16 !) too, flooding all MLDv2-capable nodes. > > Floods could happen to 33:33:ff:xx:xx:xx too, the solicited-node address. > > Floods could happen to 33:33::1:1 too (flood all NTP servers, relevant > if IEEE 802.16 decides to use NTP in the future, instead of current TIME). > > Floods could happen to 33:33::1:2 (all-dhcp-relays-servers) and to > 33:33::1:3 (all-dhcp-servers), too. > > http://www.iana.org/assignments/ipv6-multicast-addresses lists all > multicast addresses out of which one could derive 33:33 multicast > addresses potential targets for flooding. One could find some orthodox > protocols such as DVMRP, OSPF or other less orthodox names such as ST, > UPnP or Mobile-Agents. > > This would reduce our definition of flooding as being addressed to > 33:33::1 link-layer address to wider definition of flooding being > packets addressed to _any_ link-layer address prefixed by 33:33. > > ------=_Part_89637_28951636.1169167408795 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
> More specifically, we can define it as being packets addressed to any
> link-layer address prefixed by 33:33 (see the post-scriptum why).
 
Sure. I agree. To support IPv6 transparently over ETHCS over 802.16, multicasting (or broadcasting) packets in both directions of which MAC addresses are 33:33:x:x:x:x is sufficient.
 
> I think we need to identify what are the means to avoid flooding.
 
I'm sorry, I don't know what you're referring to. Anyway, I presume that you mean that flooding (i.e., broadcast) is inefficient in terms of bandwidth usage comparing to multicast. Am I correct? 
 
As Gabriel said before, it's about efficiency. IMHO, supporting either multicast or broadcast (just flood 33:33:x:x:x:x packets)  should be fine.
 

> Otherwise, you seem to say we need to discuss the problem of lack of
> flooding function in 802.16.  What do you mean?
 
I just pointed out there was no uplink broadcast as well as multicast in 802.16 PMP(point-to-multipoint) mode.
 
Best regards,
Brandon
 
2007/1/19, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Hi Jihoon,

Jihoon Lee wrote:
>
> Hi Alex,
>
> My comments inline.
>
> Best regards, Jihoon
>
> 2007/1/18, Alexandru Petrescu <alexandru.petrescu@motorola.com
> <mailto: alexandru.petrescu@motorola.com> >:
>
> Jihoon Lee wrote:
>> Gabriel,
>>
>>> Notice that if a link layer simply floods all multicast packets
>>> (essentially  using broadcast), things work fine.
>>
>> Let's focus on the main issue. As I know, we started to discuss
>> this problem, because of the lack of flooding function (surely
>> including multicast) between MSs (uplink) in 802.16 MAC layer. So,
>> we're trying to discuss this problem regarding IPv6overETHCS.
>
> I think for IPv6, 'flooding' means sending to the link-layer
> multicast address 33:33::1.  Do you agree?
>
>
> Yes, I do.
>
>
> Do you think there's another link-layer multicast address that does
> this flooding?
>
>
> No, I don't

I think thus we can define *IPv6 flooding* as being IPv6 packets sent
over ETHCS (or over the bridge 'device' in the system deploying the
ETHCS for transmitting Ethernet frames over IEEE802.16), and addressed
to the link-layer address 33:33:0:0:0:1.

More specifically, we can define it as being packets addressed to any
link-layer address prefixed by 33:33 (see the post-scriptum why).
I think we have that definition ok.  I think we need to identify what
are the means to avoid flooding.

Otherwise, you seem to say we need to discuss the problem of lack of
flooding function in 802.16.  What do you mean?

Alex

PS: many other link-layer link-local addresses are candidates of being
flooded.

There may be questions about whether 33:33:0:0:0:2 (not 1) can be target
of an IPv6 multicast link-local flood.

The way to build a link-layer multicast address from an IPv6 multicast
address is specified in rfc2464 sec 7.  If the IPv6 link-local multicast
address is ff02::1 then the link-layer multicast address is
33:33:0:0:0:1.  RFC4291 (addr arch) says that there can be several IPv6
multicast addresses interface-local or link-local: ff01::1 and ff02::1
(all-nodes); and ff01::2 and ff02::2 (all-routers).

Thus one is tempted to think packets sent 33:33:0:0:0:2 (not 1) -
all-routers -  is a potential target for flooding too.

Correspondingly, if we use MLDv2, then floods can happen to 33:33::16
(:16 !) too, flooding all MLDv2-capable nodes.

Floods could happen to 33:33:ff:xx:xx:xx too, the solicited-node address.

Floods could happen to 33:33::1:1 too (flood all NTP servers, relevant
if IEEE 802.16 decides to use NTP in the future, instead of current TIME).

Floods could happen to 33:33::1:2 (all-dhcp-relays-servers) and to
33:33::1:3 (all-dhcp-servers), too.

http://www.iana.org/assignments/ipv6-multicast-addresses lists all
multicast addresses out of which one could derive 33:33 multicast
addresses potential targets for flooding.  One could find some orthodox
protocols such as DVMRP, OSPF or other less orthodox names such as ST,
UPnP or Mobile-Agents.

This would reduce our definition of flooding as being addressed to
33:33::1 link-layer address to wider definition of flooding being
packets addressed to _any_ link-layer address prefixed by 33:33.


------=_Part_89637_28951636.1169167408795-- --===============1543323971== 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 --===============1543323971==-- From 16ng-bounces@ietf.org Thu Jan 18 21:14:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jGd-0003ho-Uz; Thu, 18 Jan 2007 21:14:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7jGc-0003du-HZ for 16ng@ietf.org; Thu, 18 Jan 2007 21:14:10 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7jGc-0006xI-0M for 16ng@ietf.org; Thu, 18 Jan 2007 21:14:10 -0500 Received: by nz-out-0506.google.com with SMTP id z6so325747nzd for <16ng@ietf.org>; Thu, 18 Jan 2007 18:14:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=KyL+S5QucLYyEAx6v4UslLsMHU8Hv/4K6yh+1ZSZUtnuL+evj8a1l9yFLhTPvkB3/17EfsfWI8in6tUns0ezpMSNuVD41dy8L6YMXio+Oz1QD44yvK/tWZWMULidMDDiiGCXDRLK9Xv+v0VXdHmNkHpcKIOsNJedSAY3WhLw6hU= Received: by 10.64.91.15 with SMTP id o15mr2058699qbb.1169172849564; Thu, 18 Jan 2007 18:14:09 -0800 (PST) Received: by 10.65.225.19 with HTTP; Thu, 18 Jan 2007 18:14:09 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2007 11:14:09 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45AFDE76.7070809@motorola.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> <45AFDE76.7070809@motorola.com> X-Google-Sender-Auth: 8f5835d209e1f451 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation (was: and IPv6 over ETHCS) 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="===============1032885725==" Errors-To: 16ng-bounces@ietf.org --===============1032885725== Content-Type: multipart/alternative; boundary="----=_Part_90085_11289270.1169172849496" ------=_Part_90085_11289270.1169172849496 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, Please see inline comments. Jihoon 2007/1/19, Alexandru Petrescu : > Jihoon Lee wrote: > > Assumption: IPv6 ND messages cannot be transmitted to other MSs served > > by the same BS without any additional supporting function. > > > > 1) 802.16 BS support a local multicast function. (How? keep this open. > > Where? Inside BS. maybe a function implemented over ETHCS.) This > > supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering > > them to a bridge or an AR. > > 2) There is a bridge between BSs and ARs. Firstly, the bridge relays > > (multicasts) IPv6 ND messages except for the source MS. > > Then, it delivers to AR. (How? keep this open. Where? bridge and AR in > > case of utilizing VLAN ). > > 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND > > messages to other MSs except for the source MS. (How? keep this > > open. Where? AR). > > 4) ... > > Jihoon, let me try to focus on the above text and motivate why I said it > would go in an Appendix. > > I am against the assumption in step 3 that only GRE tunnel can be used > for a 802.16 deployment. Other tunnels can do the trick too - L2TPv3 > RFC4719 is designed exactly to transport Ethernet over IP. IEEE802.16 > spec doesn't require GRE (search doesn't hit word 'GRE'). That's > why I think step 3 should be preceded by a big MAY. Yes, you're right. In addition, we should not specify it, as Max said. > The structuring of steps you present above makes sense to me, in that > functionalities are left open with How - keep open. > > From your above text I also understand that only BS and AR behaviours > are enhanced. I think you don't think SS or MS should do anything > special to run a special IPv6 over ETHCS. What do you think? Yes, I presume that we may not need any special add-on function on SS to address this multicast problem. But, I assume that there may be something in BS or AR or between them. BTW, definately there must be IPv6 stack, ETHCS layer, and 802.16 MAC/PHY on SS, which are supporing RFCs required. Firstly, let's consider all possible ways. > I am personally interested only on what happens on the SS, I can > contribute to that. > > So I could look for an enhancement for IPv6-over-ETHCS on SS. For example, we could require IPv6 stack on SS to (1) do MLD REPORT for > IPv6 link-local address ff02::1, (2) map to 33:33::1, and then (3) > transmit an unsolicited 802.16 MCA-RSP message (not MLD REPORT) to BS. > The steps 1 and 2 are existing art, rfc2461 and rfc2464. The step 3 is > art in 802.16MAC. The sequence of the three steps is novelty for > IPv6-over-ETHCS document. What do you think? I think you can mention (1) and (2) for SS. However, (3) is impossible. At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is a kind of ack, which has only Transaction Id (which can distinguish each 802.16 MAC message transaction) and Confirmation Code (return code such as success/failure). And MCA-REQ shall be initiated by a BS. Therefore, using MCA-REQ/RSP is not appropriate. (For your information, 802.16 MBS creates 802.16 (DL) multicast connection using DSA-REQ/RSP/ACK messages) In addition, we'd better not mention any 802.16 message explicitly. (BTW, I think there is no 802.16 message which may do this....hmm) We could alternatively require the IPv6 stack on SS to (1) do MLD REPORT > for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then don't > transmit the unsolicited MCA-RSP to BS but set up a uplink classifier > rule in ETHCS. Subsequent to that, any PDU received by ETHCS that has > dst 33:33::1 goes to the IPv6 stack. We would require the SS's ETHCS to > not put to SS's IPv6 stack a PDU that doesn't have such a uplink > classifier rule within ETHCS. This should be achieved according to IEEE > spec, not enhancement. It could be done by having the output of that > uplink classifier rule to go to a CID that is void or nil or > non-existent. In this way we could be ok with the IEEESpec (not modify > it, not tresspass it). As I see, this scenario is more plausible. But I don't fully understand your intention. (1) and (2) are ok. > any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 stack. This is the BS side, right? > We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU that doesn't have such a uplink classifier rule within ETHCS. I don't understand this sentence. Could you make this clear? Note that there is no 802.16 classifier in rx side regardless of BS or MS. I think in all cases we don't want the IPv6 stack on SS to receive > multicast packets for which it hasn't joined, because this augments the > risk of bad flooding effects. Yes. It's desirable. What do you think about GRE/L2TP? And about SS IPv6 multicast enhancements? > Alex > > ------=_Part_90085_11289270.1169172849496 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
Please see inline comments.
 
Jihoon

 
2007/1/19, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Jihoon Lee wrote:
> Assumption: IPv6 ND messages cannot be transmitted to other MSs served
> by the same BS without any additional supporting function.
>
> 1) 802.16 BS support a local multicast function. (How? keep this open.
> Where? Inside BS. maybe a function implemented over ETHCS.) This
> supposes IEEE 802.16 BS relays the IPv6 ND messages before delivering
> them to a bridge or an AR.
> 2) There is a bridge between BSs and ARs. Firstly, the bridge relays
> (multicasts) IPv6 ND messages except for the source MS.
> Then, it delivers to AR. (How? keep this open. Where? bridge and AR in
> case of utilizing VLAN ).
> 3) There is GRE tunnel between a MS and an AR. The AR relays IPv6 ND
> messages to other MSs except for the source MS. (How? keep this
> open. Where? AR).
> 4) ...

Jihoon, let me try to focus on the above text and motivate why I said it
would go in an Appendix.

I am against the assumption in step 3 that only GRE tunnel can be used
for a 802.16 deployment. Other tunnels can do the trick too - L2TPv3
RFC4719 is designed exactly to transport Ethernet over IP. IEEE802.16
spec doesn't require GRE (search doesn't hit word 'GRE'). That's
why I think step 3 should be preceded by a big MAY.
 
Yes, you're right. In addition, we should not specify it, as Max said.
 

 
The structuring of steps you present above makes sense to me, in that
functionalities are left open with How - keep open.

From your above text I also understand that only BS and AR behaviours
are enhanced. I think you don't think SS or MS should do anything
special to run a special IPv6 over ETHCS. What do you think?
 
Yes, I presume that we may not need any special add-on function on SS to address this multicast problem. But, I assume that there may be something in BS or AR or between them. BTW, definately there must be IPv6 stack, ETHCS layer, and 802.16 MAC/PHY on SS, which are supporing RFCs required.
 
Firstly, let's consider all possible ways.
 

 
I am personally interested only on what happens on the SS, I can
contribute to that.

So I could look for an enhancement for IPv6-over-ETHCS on SS.
For example, we could require IPv6 stack on SS to (1) do MLD REPORT for
IPv6 link-local address ff02::1, (2) map to 33:33::1, and then (3)
transmit an unsolicited 802.16 MCA-RSP message (not MLD REPORT) to BS.
The steps 1 and 2 are existing art, rfc2461 and rfc2464. The step 3 is
art in 802.16MAC. The sequence of the three steps is novelty for
IPv6-over-ETHCS document. What do you think?
 
I think you can mention (1) and (2) for SS. However, (3) is impossible.
 
At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is a kind of ack, which has only Transaction Id (which can distinguish each 802.16 MAC message transaction) and Confirmation Code (return code such as success/failure). And MCA-REQ shall be initiated by a BS. Therefore, using MCA-REQ/RSP is not appropriate.
(For your information, 802.16 MBS creates 802.16 (DL) multicast connection using DSA-REQ/RSP/ACK messages)
 
In addition, we'd better not mention any 802.16 message explicitly. (BTW, I think there is no 802.16 message which may do this....hmm)
 

We could alternatively require the IPv6 stack on SS to (1) do MLD REPORT
for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then don't
transmit the unsolicited MCA-RSP to BS but set up a uplink classifier
rule in ETHCS. Subsequent to that, any PDU received by ETHCS that has
dst 33:33::1 goes to the IPv6 stack. We would require the SS's ETHCS to
not put to SS's IPv6 stack a PDU that doesn't have such a uplink
classifier rule within ETHCS. This should be achieved according to IEEE
spec, not enhancement. It could be done by having the output of that
uplink classifier rule to go to a CID that is void or nil or
non-existent. In this way we could be ok with the IEEESpec (not modify
it, not tresspass it).
 
As I see, this scenario is more plausible. But I don't fully understand your intention.
(1) and (2) are ok.
> any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 stack.
This is the BS side, right?
> We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU that doesn't have such a uplink classifier rule within ETHCS.
I don't understand this sentence. Could you make this clear?
 
Note that there is no 802.16 classifier in rx side regardless of BS or MS.
 

I think in all cases we don't want the IPv6 stack on SS to receive
multicast packets for which it hasn't joined, because this augments the
risk of bad flooding effects.
 
Yes. It's desirable.

What do you think about GRE/L2TP? And about SS IPv6 multicast enhancements?
Alex


------=_Part_90085_11289270.1169172849496-- --===============1032885725== 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 --===============1032885725==-- From 16ng-bounces@ietf.org Fri Jan 19 06:16:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7rip-0006eb-T5; Fri, 19 Jan 2007 06:15:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7rio-0006cx-CN for 16ng@ietf.org; Fri, 19 Jan 2007 06:15:50 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7rim-0002AA-TA for 16ng@ietf.org; Fri, 19 Jan 2007 06:15:50 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-10.tower-153.messagelabs.com!1169205347!127218!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23503 invoked from network); 19 Jan 2007 11:15:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-153.messagelabs.com with SMTP; 19 Jan 2007 11:15:47 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0JBFk3L013448; Fri, 19 Jan 2007 04:15:46 -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 l0JBFjVJ025417; Fri, 19 Jan 2007 05:15:46 -0600 (CST) Message-ID: <45B0A860.2070303@motorola.com> Date: Fri, 19 Jan 2007 12:15:44 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A67293.6030504@motorola.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> <45AFDE76.7070809@motorola.com> 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: 2beba50d0fcdeee5f091c59f204d4365 Cc: 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation 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 Jihoon Lee wrote: > Yes, I presume that we may not need any special add-on function on SS > to address this multicast problem. But, I assume that there may be > something in BS or AR or between them. BTW, definately there must be > IPv6 stack, ETHCS layer, and 802.16 MAC/PHY on SS, which are > supporing RFCs required. > > Firstly, let's consider all possible ways. I think it is important to identify whether anything special is needed on SS. I mean anything other than rfc2461, rfc2464 and MLDv2 and the other RFCs. >> For example, we could require IPv6 stack on SS to (1) do MLD REPORT >> for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then >> (3) transmit an unsolicited 802.16 MCA-RSP message (not MLD >> REPORT) to BS. The steps 1 and 2 are existing art, rfc2461 and >> rfc2464. The step 3 is art in 802.16MAC. The sequence of the three >> steps is novelty for IPv6-over-ETHCS document. What do you think? >> > > I think you can mention (1) and (2) for SS. However, (3) is > impossible. > > At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is > a kind of ack, which has only Transaction Id (which can distinguish > each 802.16 MAC message transaction) and Confirmation Code (return > code such as success/failure). And MCA-REQ shall be initiated by a > BS. Therefore, using MCA-REQ/RSP is not appropriate. Ok, thanks, I understand MCA-RSP is not specified to be sent unsolicited but as a response. In this case, we can specify that BS before sending a RA it sends a MCA-REQ to poll who are the SS's interested in receiving that RA, and thus SS can send the MCA-RSP as it is designed. Remark that the router (entity who sends the RA - BS or AR) MUST join the all-routers address (rfc2461), with a MLD or with a local filter (popular interpretation). So subsequent to sending that MLD REPORT, or setting up filtering rule, it can send the MCA-REQ. So we can trigger the sending of MCA-REQ either by sending the RA, or by MLD JOIN for all-routers, etc. What do you think about this? Is this violating anything in 802.16. What method would you prefer? > (For your information, 802.16 MBS creates 802.16 (DL) multicast > connection using DSA-REQ/RSP/ACK messages) As I understand it DSA-REQ/RSP/ACK are for allocating service flows with a certain QoS, bandwidth request, (table 113 ieee-2004). This DSA-REQ is for a multicast CID, ok. I understand DSA-REQ/RSP/ACK are not specifically designed to indicate intention of belonging to a mc group - which is what I'm looking for, the equivalent of MLD REPORT. What do you think? Should I look elsewhere in the spec? > In addition, we'd better not mention any 802.16 message explicitly. > (BTW, I think there is no 802.16 message which may do this....hmm) I think that if we can use the 802.16 message in the way it is intended to, and if we can get comment from 802.16 expert, then we may be fine. It may also be that it's not fine at all, by expert oppinion. >> We could alternatively require the IPv6 stack on SS to (1) do MLD >> REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1, >> and then don't transmit the unsolicited MCA-RSP to BS but set up a >> uplink classifier rule in ETHCS. Subsequent to that, any PDU >> received by ETHCS that has dst 33:33::1 goes to the IPv6 stack. We >> would require the SS's ETHCS to not put to SS's IPv6 stack a PDU >> that doesn't have such a uplink classifier rule within ETHCS. This >> should be achieved according to IEEE spec, not enhancement. It >> could be done by having the output of that uplink classifier rule >> to go to a CID that is void or nil or non-existent. In this way we >> could be ok with the IEEESpec (not modify it, not tresspass it). > > > As I see, this scenario is more plausible. But I don't fully > understand your intention. (1) and (2) are ok. >> any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 >> stack. > > This is the BS side, right? I meant SS. >> We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU >> that doesn't have such a uplink classifier rule within ETHCS. > > I don't understand this sentence. Could you make this clear? Yes, the goal is for SS. SS's ETHCS shouldn't deliver ('put') a PDU it receives from BS's ETHCS, that is addressed to 33:33, to the IPv6 stack, if SS's doesn't have a 'reconstitution' classifier rule for it. So one would basically require that only if there is a reconstitution rule in SS's ETHCS for the 33:33 dst and a normal CID, should the ETHCS deliver the packet to the IPv6 stack of the SS. (I should have said maybe 'reconstitution' instead of 'uplink classifier'. Figure 7, 8 ieee-2004. Basically SS has only uplink classifiers, BS has only downlink classifiers, when they send packets; and they have 'reconstitution' when they receive packets). > Note that there is no 802.16 classifier in rx side regardless of BS > or MS. I agree, I should have said 'reconstitution' then? Can the 'reconstitution' part of SS, the one that undoes PHS, have such a classifier rule? If it does not then one really has to prevent unwanted 33:33-addressed messages to reach the SS. Apparently the only way left is to do it at BS, send the 33:33-addressed packets only to those SS's that are interested. What do you think? > I think in all cases we don't want the IPv6 stack on SS to receive > multicast packets for which it hasn't joined, because this augments > the risk of bad flooding effects. > > > Yes. It's desirable. I agree it is desirable. To me it is at least desirable, and more, it is a MUST. I think we could have been more in agreement if we defined in detail what the flooding problem is. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 19 06:34:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7s0U-0008Nz-Dp; Fri, 19 Jan 2007 06:34:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7s0T-0008Mg-Jb for 16ng@ietf.org; Fri, 19 Jan 2007 06:34:05 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7s0R-0005iN-8B for 16ng@ietf.org; Fri, 19 Jan 2007 06:34:05 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1169206441!1241410!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 18924 invoked from network); 19 Jan 2007 11:34:02 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-128.messagelabs.com with SMTP; 19 Jan 2007 11:34:02 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0JBY1h2018189; Fri, 19 Jan 2007 04:34: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 l0JBY0Lq002302; Fri, 19 Jan 2007 05:34:01 -0600 (CST) Message-ID: <45B0ACA7.4000109@motorola.com> Date: Fri, 19 Jan 2007 12:33:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> <45AF590A.2000005@motorola.com> <45AFA0CD.8080103@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 16ng@ietf.org Subject: [16NG] Re: flloding problem 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 Jihoon Lee wrote: > Hi Alex, > >> More specifically, we can define it as being packets addressed to >> any link-layer address prefixed by 33:33 (see the post-scriptum >> why). > > Sure. I agree. To support IPv6 transparently over ETHCS over 802.16, > multicasting (or broadcasting) packets in both directions of which > MAC addresses are 33:33:x:x:x:x is sufficient. Let's focus on the flooding problem, not solution. >> I think we need to identify what are the means to avoid flooding. > > I'm sorry, I don't know what you're referring to. Anyway, I presume > that you mean that flooding (i.e., broadcast) is inefficient in terms > of bandwidth usage comparing to multicast. Am I correct? Ok, flooding is not broadcast. Up to now we agreed flooding is sending to 33:33-prefixed packets. Broadcast is sending to ff:ff:ff:ff:ff:ff address. It's completely different. > As Gabriel said before, it's about efficiency. IMHO, supporting > either multicast or broadcast (just flood 33:33:x:x:x:x packets) > should be fine. Ok, I must say I disagree. I completely respect Chair indications with respect to administrative, but I think that oppinion was expressed as a technical oppinion, not as Chair, so anyone can disagree with it. It is a very strong goal, and much more than qualifying as 'efficient or less efficient', to not deliver the IPv6 multicast packet to a stack that hasn't indicated willingness to participate into that multicast group. Or, to deliver a multicast packet only to a stack that has expressed interest in it. This is a requirement, as I see it. What do you think? I can mention a scenario where this flooding can become a tsunami: if one doesn't use link-layer filtering rules, or MLD, then an attacker can send a packet to a 33:33 address and falsely put 33:33 in its src address. At which point everybody will respond to everybody, and more everybody to everybody, etc. A broadcasted NS is but an example. Oftentimes this behaviour that I called 'tsunami' people call actually 'flooding'. So our flooding problem would be so too. What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33', and about the necessity to not deliver a multicast IPv6 packet to an IPv6 stack that hasn't expressed interest in it? Is this necessary in your view? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 19 11:55:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7x18-0001dJ-KY; Fri, 19 Jan 2007 11:55:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7x17-0001cY-45 for 16ng@ietf.org; Fri, 19 Jan 2007 11:55:05 -0500 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7x11-0002Xc-Dl for 16ng@ietf.org; Fri, 19 Jan 2007 11:55:05 -0500 Received: by nz-out-0506.google.com with SMTP id z6so492086nzd for <16ng@ietf.org>; Fri, 19 Jan 2007 08:54:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Z4Bqztbf0Kyr2YPutIagRaoyd+M/qTZDogxdGujjGzseBMBMJzMcngluUnKBfX9LTe2xD8zcDBPrW4ICOTZWgrQQrCG7zGGUtKjoNqai3j0n3ywyAFUrzv0XRgV9Nm1BefLkrt38ig7kBOidxnYOBlPZ8ak0MHVMIb6XE1Kcywc= Received: by 10.65.216.19 with SMTP id t19mr3262357qbq.1169225698000; Fri, 19 Jan 2007 08:54:58 -0800 (PST) Received: by 10.65.222.2 with HTTP; Fri, 19 Jan 2007 08:54:57 -0800 (PST) Message-ID: Date: Sat, 20 Jan 2007 01:54:57 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45B0A860.2070303@motorola.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> <45AFDE76.7070809@motorola.com> <45B0A860.2070303@motorola.com> X-Google-Sender-Auth: 561c4d29b1997c2f X-Spam-Score: 0.3 (/) X-Scan-Signature: 9cc83ac38bbbabacbf00f656311dd8d8 Cc: 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation 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="===============1562972980==" Errors-To: 16ng-bounces@ietf.org --===============1562972980== Content-Type: multipart/alternative; boundary="----=_Part_109122_9946835.1169225697906" ------=_Part_109122_9946835.1169225697906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, >I think it is important to identify whether anything special is needed >on SS. I mean anything other than rfc2461, rfc2464 and MLDv2 and the >other RFCs. Ok. I understood your intention. > Ok, thanks, I understand MCA-RSP is not specified to be sent unsolicited > but as a response. > In this case, we can specify that BS before sending a RA it sends a > MCA-REQ to poll who are the SS's interested in receiving that RA, and > thus SS can send the MCA-RSP as it is designed. > Remark that the router (entity who sends the RA - BS or AR) MUST join > the all-routers address (rfc2461), with a MLD or with a local filter > (popular interpretation). So subsequent to sending that MLD REPORT, or > setting up filtering rule, it can send the MCA-REQ. So we can trigger > the sending of MCA-REQ either by sending the RA, or by MLD JOIN for > all-routers, etc. > What do you think about this? Is this violating anything in 802.16. > What method would you prefer? Right now, I'm not sure about the usage of 802.16 MCA messages. Actually I thought the MCA differently. You may need to ask an 16 expert the usage of MCA. > As I understand it DSA-REQ/RSP/ACK are for allocating service flows with > a certain QoS, bandwidth request, (table 113 ieee-2004). This DSA-REQ > is for a multicast CID, ok. I understand DSA-REQ/RSP/ACK are not > specifically designed to indicate intention of belonging to a mc group - > which is what I'm looking for, the equivalent of MLD REPORT. > What do you think? Should I look elsewhere in the spec? Here is another feasible way. I believe this is similar to what you're trying to do: DSA performs 802.16 connection setup as well as the service flow creation. If there is no connection (actually CID) on SS, the SS cannot receive it at 802.16 link layer. When BS creates multicast connection between itself and MSs, DSA transaction is required for each MS. Therefore, BS can manage its multicast group which is associated with 802.16 multicast CID. In other words, MS may join by initiating DSA with appropriate multicast CID. Because, in theory, DSA can be initiated by either BS or MS. Consequently, the multicast can be delivered to intended users only in 802.16 link-layer. BTW, basically 802.16 doesn't know any upper layer messages such as IGMP/MLD-REPORT. So, there may be some issues, i.e., who will trigger a multicast connection setup, and which is better, BS-initiated or MS-initiated. The MBS will be discussed in WiMAX Forum at the end of this month. Then, we may refer to details in DL multicast. > Yes, the goal is for SS. SS's ETHCS shouldn't deliver ('put') a PDU it > receives from BS's ETHCS, that is addressed to 33:33, to the IPv6 stack, > if SS's doesn't have a 'reconstitution' classifier rule for it. > > So one would basically require that only if there is a reconstitution > rule in SS's ETHCS for the 33:33 dst and a normal CID, should the ETHCS > deliver the packet to the IPv6 stack of the SS. > > (I should have said maybe 'reconstitution' instead of 'uplink > classifier'. Figure 7, 8 ieee-2004. Basically SS has only uplink > classifiers, BS has only downlink classifiers, when they send packets; > and they have 'reconstitution' when they receive packets). > Ok. 'reconstitution' is fine to me. > Can the 'reconstitution' part of SS, the one that undoes PHS, have such a > classifier rule? > > If it does not then one really has to prevent unwanted 33:33-addressed > messages to reach the SS. Apparently the only way left is to do it at > BS, send the 33:33-addressed packets only to those SS's that are > interested. What do you think? I think you cannot define any classification rule in 'reconstitution' part of SS, since the 'reconstitution' part is defined in 802.16. Why don't you do that on top of 802.16? BTW, how about the scenario I mentioned above? I think it could also prevent unwanted/not-joined 33:33-addressed messages to reach the SS. Best regards, Jihoon 2007/1/19, Alexandru Petrescu : > > Jihoon Lee wrote: > > Yes, I presume that we may not need any special add-on function on SS > > to address this multicast problem. But, I assume that there may be > > something in BS or AR or between them. BTW, definately there must be > > IPv6 stack, ETHCS layer, and 802.16 MAC/PHY on SS, which are > > supporing RFCs required. > > > > Firstly, let's consider all possible ways. > > I think it is important to identify whether anything special is needed > on SS. I mean anything other than rfc2461, rfc2464 and MLDv2 and the > other RFCs. > > >> For example, we could require IPv6 stack on SS to (1) do MLD REPORT > >> for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then > >> (3) transmit an unsolicited 802.16 MCA-RSP message (not MLD > >> REPORT) to BS. The steps 1 and 2 are existing art, rfc2461 and > >> rfc2464. The step 3 is art in 802.16MAC. The sequence of the three > >> steps is novelty for IPv6-over-ETHCS document. What do you think? > >> > > > > I think you can mention (1) and (2) for SS. However, (3) is > > impossible. > > > > At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is > > a kind of ack, which has only Transaction Id (which can distinguish > > each 802.16 MAC message transaction) and Confirmation Code (return > > code such as success/failure). And MCA-REQ shall be initiated by a > > BS. Therefore, using MCA-REQ/RSP is not appropriate. > > Ok, thanks, I understand MCA-RSP is not specified to be sent unsolicited > but as a response. > > In this case, we can specify that BS before sending a RA it sends a > MCA-REQ to poll who are the SS's interested in receiving that RA, and > thus SS can send the MCA-RSP as it is designed. > > Remark that the router (entity who sends the RA - BS or AR) MUST join > the all-routers address (rfc2461), with a MLD or with a local filter > (popular interpretation). So subsequent to sending that MLD REPORT, or > setting up filtering rule, it can send the MCA-REQ. So we can trigger > the sending of MCA-REQ either by sending the RA, or by MLD JOIN for > all-routers, etc. > > What do you think about this? Is this violating anything in 802.16. > What method would you prefer? > > > (For your information, 802.16 MBS creates 802.16 (DL) multicast > > connection using DSA-REQ/RSP/ACK messages) > > As I understand it DSA-REQ/RSP/ACK are for allocating service flows with > a certain QoS, bandwidth request, (table 113 ieee-2004). This DSA-REQ > is for a multicast CID, ok. I understand DSA-REQ/RSP/ACK are not > specifically designed to indicate intention of belonging to a mc group - > which is what I'm looking for, the equivalent of MLD REPORT. > > What do you think? Should I look elsewhere in the spec? > > > In addition, we'd better not mention any 802.16 message explicitly. > > (BTW, I think there is no 802.16 message which may do this....hmm) > > I think that if we can use the 802.16 message in the way it is intended > to, and if we can get comment from 802.16 expert, then we may be fine. > It may also be that it's not fine at all, by expert oppinion. > > >> We could alternatively require the IPv6 stack on SS to (1) do MLD > >> REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1, > >> and then don't transmit the unsolicited MCA-RSP to BS but set up a > >> uplink classifier rule in ETHCS. Subsequent to that, any PDU > >> received by ETHCS that has dst 33:33::1 goes to the IPv6 stack. We > >> would require the SS's ETHCS to not put to SS's IPv6 stack a PDU > >> that doesn't have such a uplink classifier rule within ETHCS. This > >> should be achieved according to IEEE spec, not enhancement. It > >> could be done by having the output of that uplink classifier rule > >> to go to a CID that is void or nil or non-existent. In this way we > >> could be ok with the IEEESpec (not modify it, not tresspass it). > > > > > > As I see, this scenario is more plausible. But I don't fully > > understand your intention. (1) and (2) are ok. > >> any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6 > >> stack. > > > > This is the BS side, right? > > I meant SS. > > >> We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU > >> that doesn't have such a uplink classifier rule within ETHCS. > > > > I don't understand this sentence. Could you make this clear? > > Yes, the goal is for SS. SS's ETHCS shouldn't deliver ('put') a PDU it > receives from BS's ETHCS, that is addressed to 33:33, to the IPv6 stack, > if SS's doesn't have a 'reconstitution' classifier rule for it. > > So one would basically require that only if there is a reconstitution > rule in SS's ETHCS for the 33:33 dst and a normal CID, should the ETHCS > deliver the packet to the IPv6 stack of the SS. > > (I should have said maybe 'reconstitution' instead of 'uplink > classifier'. Figure 7, 8 ieee-2004. Basically SS has only uplink > classifiers, BS has only downlink classifiers, when they send packets; > and they have 'reconstitution' when they receive packets). > > > Note that there is no 802.16 classifier in rx side regardless of BS > > or MS. > > I agree, I should have said 'reconstitution' then? Can the > 'reconstitution' part of SS, the one that undoes PHS, have such a > classifier rule? > > If it does not then one really has to prevent unwanted 33:33-addressed > messages to reach the SS. Apparently the only way left is to do it at > BS, send the 33:33-addressed packets only to those SS's that are > interested. What do you think? > > > I think in all cases we don't want the IPv6 stack on SS to receive > > multicast packets for which it hasn't joined, because this augments > > the risk of bad flooding effects. > > > > > > Yes. It's desirable. > > I agree it is desirable. To me it is at least desirable, and more, it > is a MUST. I think we could have been more in agreement if we defined > in detail what the flooding problem is. > > Alex > > ------=_Part_109122_9946835.1169225697906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
>I think it is important to identify whether anything special is needed
>on SS.  I mean anything other than rfc2461, rfc2464 and MLDv2 and the
>other RFCs.
 
Ok. I understood your intention.
 
> Ok, thanks, I understand MCA-RSP is not specified to be sent unsolicited
> but as a response.
> In this case, we can specify that BS before sending a RA it sends a
> MCA-REQ to poll who are the SS's interested in receiving that RA, and
> thus SS can send the MCA-RSP as it is designed.
> Remark that the router (entity who sends the RA - BS or AR) MUST join
> the all-routers address (rfc2461), with a MLD or with a local filter
> (popular interpretation).  So subsequent to sending that MLD REPORT, or
> setting up filtering rule, it can send the MCA-REQ.  So we can trigger
> the sending of MCA-REQ either by sending the RA, or by MLD JOIN for
> all-routers, etc.
> What do you think about this?  Is this violating anything in 802.16.
> What method would you prefer?
 
Right now, I'm not sure about the usage of 802.16 MCA messages. Actually I thought the MCA differently. You may need to ask an 16 expert the usage of MCA.
 
> As I understand it DSA-REQ/RSP/ACK are for allocating service flows with
> a certain QoS, bandwidth request, (table 113 ieee-2004).  This DSA-REQ
> is for a multicast CID, ok.  I understand DSA-REQ/RSP/ACK are not
> specifically designed to indicate intention of belonging to a mc group -
> which is what I'm looking for, the equivalent of MLD REPORT.
> What do you think?  Should I look elsewhere in the spec?
 
Here is another feasible way. I believe this is similar to what you're trying to do:
 
DSA performs 802.16 connection setup as well as the service flow creation. If there is no connection (actually CID) on SS, the SS cannot receive it at 802.16 link layer. When BS creates multicast connection between itself and MSs, DSA transaction is required for each MS. Therefore, BS can manage its multicast group which is associated with 802.16 multicast CID. In other words, MS may join by initiating DSA with appropriate multicast CID. Because, in theory, DSA can be initiated by either BS or MS. Consequently, the multicast can be delivered to intended users only in 802.16 link-layer.
 
BTW, basically 802.16 doesn't know any upper layer messages such as IGMP/MLD-REPORT. So, there may be some issues, i.e., who will trigger a multicast connection setup, and which is better, BS-initiated or MS-initiated.
 
The MBS will be discussed in WiMAX Forum at the end of this month. Then, we may refer to details in DL multicast.

 
> Yes, the goal is for SS.  SS's ETHCS shouldn't deliver ('put') a PDU it
> receives from BS's ETHCS, that is addressed to 33:33, to the IPv6 stack,
> if SS's doesn't have a 'reconstitution' classifier rule for it.
>
> So one would basically require that only if there is a reconstitution
> rule in SS's ETHCS for the 33:33 dst and a normal CID, should the ETHCS
> deliver the packet to the IPv6 stack of the SS.
>
> (I should have said maybe 'reconstitution' instead of 'uplink
> classifier'. Figure 7, 8 ieee-2004.  Basically SS has only uplink
> classifiers, BS has only downlink classifiers, when they send packets;
> and they have 'reconstitution' when they receive packets).
>
 
Ok. 'reconstitution' is fine to me.
 
> Can the 'reconstitution' part  of SS, the one that undoes PHS, have such a
> classifier rule?
>
> If it does not then one really has to prevent unwanted 33:33-addressed
> messages to reach the SS.  Apparently the only way left is to do it at
> BS, send the 33:33-addressed packets only to those SS's that are
> interested.  What do you think?

I think you cannot define any classification rule in 'reconstitution' part of SS, since the 'reconstitution' part is defined in 802.16. Why don't you do that on top of 802.16?
 
BTW, how about the scenario I mentioned above?  I think it could also prevent unwanted/not-joined 33:33-addressed messages to reach the SS.
 
Best regards,
Jihoon

 
2007/1/19, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Jihoon Lee wrote:
> Yes, I presume that we may not need any special add-on function on SS
>  to address this multicast problem. But, I assume that there may be
> something in BS or AR or between them. BTW, definately there must be
> IPv6 stack, ETHCS layer, and 802.16 MAC/PHY on SS, which are
> supporing RFCs required.
>
> Firstly, let's consider all possible ways.

I think it is important to identify whether anything special is needed
on SS.  I mean anything other than rfc2461, rfc2464 and MLDv2 and the
other RFCs.

>> For example, we could require IPv6 stack on SS to (1) do MLD REPORT
>>  for IPv6 link-local address ff02::1, (2) map to 33:33::1, and then
>>  (3) transmit an unsolicited 802.16 MCA-RSP message (not MLD
>> REPORT) to BS. The steps 1 and 2 are existing art, rfc2461 and
>> rfc2464. The step 3 is art in 802.16MAC. The sequence of the three
>> steps is novelty for IPv6-over-ETHCS document. What do you think?
>>
>
> I think you can mention (1) and (2) for SS. However, (3) is
> impossible.
>
> At first, MCA-RSP cannot be sent by an unsolicited manner. MCA-RSP is
>  a kind of ack, which has only Transaction Id (which can distinguish
> each 802.16 MAC message transaction) and Confirmation Code (return
> code such as success/failure). And MCA-REQ shall be initiated by a
> BS. Therefore, using MCA-REQ/RSP is not appropriate.

Ok, thanks, I understand MCA-RSP is not specified to be sent unsolicited
but as a response.

In this case, we can specify that BS before sending a RA it sends a
MCA-REQ to poll who are the SS's interested in receiving that RA, and
thus SS can send the MCA-RSP as it is designed.

Remark that the router (entity who sends the RA - BS or AR) MUST join
the all-routers address (rfc2461), with a MLD or with a local filter
(popular interpretation).  So subsequent to sending that MLD REPORT, or
setting up filtering rule, it can send the MCA-REQ.  So we can trigger
the sending of MCA-REQ either by sending the RA, or by MLD JOIN for
all-routers, etc.

What do you think about this?  Is this violating anything in 802.16.
What method would you prefer?

> (For your information, 802.16 MBS creates 802.16 (DL) multicast
> connection using DSA-REQ/RSP/ACK messages)

As I understand it DSA-REQ/RSP/ACK are for allocating service flows with
a certain QoS, bandwidth request, (table 113 ieee-2004).  This DSA-REQ
is for a multicast CID, ok.  I understand DSA-REQ/RSP/ACK are not
specifically designed to indicate intention of belonging to a mc group -
which is what I'm looking for, the equivalent of MLD REPORT.

What do you think?  Should I look elsewhere in the spec?

> In addition, we'd better not mention any 802.16 message explicitly.
> (BTW, I think there is no 802.16 message which may do this....hmm)

I think that if we can use the 802.16 message in the way it is intended
to, and if we can get comment from 802.16 expert, then we may be fine.
It may also be that it's not fine at all, by expert oppinion.

>> We could alternatively require the IPv6 stack on SS to (1) do MLD
>> REPORT for IPv6 link-local address ff02::1, (2) map to 33:33::1,
>> and then don't transmit the unsolicited MCA-RSP to BS but set up a
>> uplink classifier rule in ETHCS. Subsequent to that, any PDU
>> received by ETHCS that has dst 33:33::1 goes to the IPv6 stack. We
>> would require the SS's ETHCS to not put to SS's IPv6 stack a PDU
>> that doesn't have such a uplink classifier rule within ETHCS. This
>> should be achieved according to IEEE spec, not enhancement. It
>> could be done by having the output of that uplink classifier rule
>> to go to a CID that is void or nil or non-existent. In this way we
>> could be ok with the IEEESpec (not modify it, not tresspass it).
>
>
> As I see, this scenario is more plausible. But I don't fully
> understand your intention. (1) and (2) are ok.
>> any PDU received by ETHCS that has dst 33:33::1 goes to the IPv6
>> stack.
>
> This is the BS side, right?

I meant SS.

>> We would require the SS's ETHCS to not put to SS's IPv6 stack a PDU
>>  that doesn't have such a uplink classifier rule within ETHCS.
>
> I don't understand this sentence. Could you make this clear?

Yes, the goal is for SS.  SS's ETHCS shouldn't deliver ('put') a PDU it
receives from BS's ETHCS, that is addressed to 33:33, to the IPv6 stack,
if SS's doesn't have a 'reconstitution' classifier rule for it.

So one would basically require that only if there is a reconstitution
rule in SS's ETHCS for the 33:33 dst and a normal CID, should the ETHCS
deliver the packet to the IPv6 stack of the SS.

(I should have said maybe 'reconstitution' instead of 'uplink
classifier'. Figure 7, 8 ieee-2004.  Basically SS has only uplink
classifiers, BS has only downlink classifiers, when they send packets;
and they have 'reconstitution' when they receive packets).

> Note that there is no 802.16 classifier in rx side regardless of BS
> or MS.

I agree, I should have said 'reconstitution' then?  Can the
'reconstitution' part  of SS, the one that undoes PHS, have such a
classifier rule?

If it does not then one really has to prevent unwanted 33:33-addressed
messages to reach the SS.  Apparently the only way left is to do it at
BS, send the 33:33-addressed packets only to those SS's that are
interested.  What do you think?

> I think in all cases we don't want the IPv6 stack on SS to receive
> multicast packets for which it hasn't joined, because this augments
> the risk of bad flooding effects.
>
>
> Yes. It's desirable.

I agree it is desirable.  To me it is at least desirable, and more, it
is a MUST.  I think we could have been more in agreement if we defined
in detail what the flooding problem is.

Alex


------=_Part_109122_9946835.1169225697906-- --===============1562972980== 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 --===============1562972980==-- From 16ng-bounces@ietf.org Fri Jan 19 12:56:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xyF-00019a-90; Fri, 19 Jan 2007 12:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7xyD-00015m-Pa for 16ng@ietf.org; Fri, 19 Jan 2007 12:56:09 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H7xyC-0004ja-E4 for 16ng@ietf.org; Fri, 19 Jan 2007 12:56:09 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1169229367!7200574!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9031 invoked from network); 19 Jan 2007 17:56:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 19 Jan 2007 17:56:07 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0JHu3j0013684; Fri, 19 Jan 2007 10:56:03 -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 l0JHu2co010927; Fri, 19 Jan 2007 11:56:02 -0600 (CST) Message-ID: <45B10631.6050809@motorola.com> Date: Fri, 19 Jan 2007 18:56:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jihoon Lee References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45A76EC4.7070304@motorola.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> <45AFDE76.7070809@motorola.com> <45B0A860.2070303@motorola.com> 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: b2809b6f39decc6de467dcf252f42af1 Cc: David Johnston , 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation and two questions to David Johnston 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 Jihoon Lee wrote: >> Ok, thanks, I understand MCA-RSP is not specified to be sent >> unsolicited but as a response. In this case, we can specify that BS >> before sending a RA it sends a MCA-REQ to poll who are the SS's >> interested in receiving that RA, and thus SS can send the MCA-RSP >> as it is designed. Remark that the router (entity who sends the RA >> - BS or AR) MUST join the all-routers address (rfc2461), with a MLD >> or with a local filter (popular interpretation). So subsequent to >> sending that MLD REPORT, or setting up filtering rule, it can send >> the MCA-REQ. So we can trigger the sending of MCA-REQ either by >> sending the RA, or by MLD JOIN for all-routers, etc. What do you >> think about this? Is this violating anything in 802.16. What >> method would you prefer? > > Right now, I'm not sure about the usage of 802.16 MCA messages. > Actually I thought the MCA differently. You may need to ask an 16 > expert the usage of MCA. David, do you think an IPv6 stack on the BS can ask the 802.16MAC to send a MCA-REQ to SS to ask it whether it's interested in receiving packets addressed to 33:33:0:0:0:1? >> As I understand it DSA-REQ/RSP/ACK are for allocating service flows >> with a certain QoS, bandwidth request, (table 113 ieee-2004). >> This DSA-REQ is for a multicast CID, ok. I understand >> DSA-REQ/RSP/ACK are not specifically designed to indicate intention >> of belonging to a mc group - which is what I'm looking for, the >> equivalent of MLD REPORT. What do you think? Should I look >> elsewhere in the spec? > > Here is another feasible way. I believe this is similar to what > you're trying to do: > > DSA performs 802.16 connection setup as well as the service flow > creation. If there is no connection (actually CID) on SS, the SS > cannot receive it at 802.16 link layer. When BS creates multicast > connection between itself and MSs, DSA transaction is required for > each MS. Therefore, BS can manage its multicast group which is > associated with 802.16 multicast CID. In other words, MS may join by > initiating DSA with appropriate multicast CID. Because, in theory, > DSA can be initiated by either BS or MS. Consequently, the multicast > can be delivered to intended users only in 802.16 link-layer. [At which point there would be a need to be able to convert IPv6 link-local multicast addresses to multicast CIDs, right? Like ff02::1 to 16bit. Or do you think 802.16MAC converts the 33:33::1 to a multicast CID?] I understand. So the SS uses DSA messages to indicate interest in a multicast-CID reception, and the BS keeps track of interests. It makes sense to me. The packets addressed to a multicast group will arrive to SS on that multicast CID. But I think we still need to say that it is the SS who triggers that DSA exchange, ie SS's IPv6 stack. Do you agree? It can happen in of the following alternative 2 ways: (1) IPv6 stack generates a MLD REPORT and puts it to ETHCS Driver. ETHCS Driver interprets it, drops it, and sends the corresponding DSA-REQ; (2) IPv6 stack calls a function in ETHCS Driver giving it parameter 33:33::1 and ETHCS Driver generates the DSA-REQ. I think this should work. > BTW, basically 802.16 doesn't know any upper layer messages such as > IGMP/MLD-REPORT. Unless it 'snoops' them? > So, there may be some issues, i.e., who will trigger a multicast > connection setup, and which is better, BS-initiated or MS-initiated. Most IPv6 stacks currently call some function to join a certain group. Some generate MLD REPORTS, some others just call a driver's function. This can be matched into DSA-REQ/RSP. All IPv6 router stacks must join all-routers group, so the BS (_if_ it sends RAs) should join. This matches the model of BS sending MCA-REQ and SS sending MCA-RSP. > The MBS will be discussed in WiMAX Forum at the end of this month. > Then, we may refer to details in DL multicast. Sorry, I don't know what's MBS. I think we have freedom to propose something that makes sense for multicast IPv6 over ETHCS, here. If there's agreement in the group and gets drafted then maybe MBS and WiMax will be interested to know what the draft says. >> If it does not then one really has to prevent unwanted >> 33:33-addressed messages to reach the SS. Apparently the only way >> left is to do it at BS, send the 33:33-addressed packets only to >> those SS's that are interested. What do you think? > > I think you cannot define any classification rule in 'reconstitution' > part of SS, since the 'reconstitution' part is defined in 802.16. David, is it possible for IPv6 stack to add classification rule to the 'reconstitution' part of a SS, ie classifiers in SS that apply to packets SS receives from BS, not 'uplink' classifiers that apply to packets SS sends to BS. > Why don't you do that on top of 802.16? I was thinking we may save code. But then _where_ exactly on top of 802.16? Can I say add 'filtering rule' in the ETHCS layer of SS? Or can I say add 'filtering rule' in the Bridging function of the ETHCS layer of SS? But please, no link-local multicast filtering rule in the IPv6 stack. > BTW, how about the scenario I mentioned above? I think it could also > prevent unwanted/not-joined 33:33-addressed messages to reach the > SS. I think it makes sense. I think DSA-REQ/RSP can be used by SS to set up a multicast CID, based on my rough reading of the IEEE-2004 document. I think it will open a connection on which the RA will be sent, for example. I think we need to identify what triggers the sending of the DSA-REQ. I've suggested above. I think if we have agreement on that maybe we can write 4 short paragraphs and then re-ask in the Working Group and the IEEE experts. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 19 13:15:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yH3-0003hh-6K; Fri, 19 Jan 2007 13:15:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7yH2-0003hb-Kv for 16ng@ietf.org; Fri, 19 Jan 2007 13:15:36 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7yGz-00019c-KH for 16ng@ietf.org; Fri, 19 Jan 2007 13:15:36 -0500 Received: by nz-out-0506.google.com with SMTP id z6so509528nzd for <16ng@ietf.org>; Fri, 19 Jan 2007 10:15:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=L1XU01M+eThLTSGaBz9zNvd2aubytU+O/rF15mEaYJ+e9cWxnuHkNQtU0M8Xo36VWAfGfV3M21WB3wNPhbptsoCAChecclj5vSp1CHMC50gHOn27Bb/gRjH23CUMzzCv0NwQP5zhkOTfWeEjF4OU8TdE0bc5gXroWbRvNg/9bsQ= Received: by 10.65.177.6 with SMTP id e6mr3404866qbp.1169230533061; Fri, 19 Jan 2007 10:15:33 -0800 (PST) Received: by 10.65.222.2 with HTTP; Fri, 19 Jan 2007 10:15:32 -0800 (PST) Message-ID: Date: Sat, 20 Jan 2007 03:15:32 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45B0ACA7.4000109@motorola.com> MIME-Version: 1.0 References: <20070117233714.35376.qmail@web81905.mail.mud.yahoo.com> <45AF590A.2000005@motorola.com> <45AFA0CD.8080103@motorola.com> <45B0ACA7.4000109@motorola.com> X-Google-Sender-Auth: b626ae0de6990fc8 X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: 16ng@ietf.org Subject: [16NG] Re: flloding problem 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="===============0219446657==" Errors-To: 16ng-bounces@ietf.org --===============0219446657== Content-Type: multipart/alternative; boundary="----=_Part_109883_14843236.1169230532889" ------=_Part_109883_14843236.1169230532889 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, > What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33', > and about the necessity to not deliver a multicast IPv6 packet to an > IPv6 stack that hasn't expressed interest in it? Is this necessary in > your view? I thought it over. Ok, I think we don't have to allow flooding (though you think the flooding MUST NOT be allowed). >From now on, Iet's focus on the multicast which avoids flooding. Thanks, Jihoon 2007/1/19, Alexandru Petrescu : > > Jihoon Lee wrote: > > Hi Alex, > > > >> More specifically, we can define it as being packets addressed to > >> any link-layer address prefixed by 33:33 (see the post-scriptum > >> why). > > > > Sure. I agree. To support IPv6 transparently over ETHCS over 802.16, > > multicasting (or broadcasting) packets in both directions of which > > MAC addresses are 33:33:x:x:x:x is sufficient. > > Let's focus on the flooding problem, not solution. > >> I think we need to identify what are the means to avoid flooding. > > > > I'm sorry, I don't know what you're referring to. Anyway, I presume > > that you mean that flooding (i.e., broadcast) is inefficient in terms > > of bandwidth usage comparing to multicast. Am I correct? > > Ok, flooding is not broadcast. > > Up to now we agreed flooding is sending to 33:33-prefixed packets. > Broadcast is sending to ff:ff:ff:ff:ff:ff address. It's completely > different. > > > As Gabriel said before, it's about efficiency. IMHO, supporting > > either multicast or broadcast (just flood 33:33:x:x:x:x packets) > > should be fine. > > Ok, I must say I disagree. I completely respect Chair indications with > respect to administrative, but I think that oppinion was expressed as a > technical oppinion, not as Chair, so anyone can disagree with it. > > It is a very strong goal, and much more than qualifying as 'efficient or > less efficient', to not deliver the IPv6 multicast packet to a stack > that hasn't indicated willingness to participate into that multicast > group. Or, to deliver a multicast packet only to a stack that has > expressed interest in it. This is a requirement, as I see it. What do > you think? > > I can mention a scenario where this flooding can become a tsunami: if > one doesn't use link-layer filtering rules, or MLD, then an attacker can > send a packet to a 33:33 address and falsely put 33:33 in its src > address. At which point everybody will respond to everybody, and more > everybody to everybody, etc. A broadcasted NS is but an example. > > Oftentimes this behaviour that I called 'tsunami' people call actually > 'flooding'. So our flooding problem would be so too. > > What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33', > and about the necessity to not deliver a multicast IPv6 packet to an > IPv6 stack that hasn't expressed interest in it? Is this necessary in > your view? > > Alex > ------=_Part_109883_14843236.1169230532889 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
> What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33',
> and about the necessity to not deliver a multicast IPv6 packet to an
> IPv6 stack that hasn't expressed interest in it?  Is this necessary in
> your view?
 
I thought it over. Ok, I think we don't have to allow flooding (though you think the flooding MUST NOT be allowed).
 
From now on, Iet's focus on the multicast which avoids flooding.
 
Thanks,
Jihoon
 
2007/1/19, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Jihoon Lee wrote:
> Hi Alex,
>
>> More specifically, we can define it as being packets addressed to
>> any link-layer address prefixed by 33:33 (see the post-scriptum
>> why).
>
> Sure. I agree. To support IPv6 transparently over ETHCS over 802.16,
> multicasting (or broadcasting) packets in both directions of which
> MAC addresses are 33:33:x:x:x:x is sufficient.

Let's focus on the flooding problem, not solution.
 
>> I think we need to identify what are the means to avoid flooding.
>
> I'm sorry, I don't know what you're referring to. Anyway, I presume
> that you mean that flooding (i.e., broadcast) is inefficient in terms
>  of bandwidth usage comparing to multicast. Am I correct?

Ok, flooding is not broadcast.

Up to now we agreed flooding is sending to 33:33-prefixed packets.
Broadcast is sending to ff:ff:ff:ff:ff:ff address.  It's completely
different.

> As Gabriel said before, it's about efficiency. IMHO, supporting
> either multicast or broadcast (just flood 33:33:x:x:x:x packets)
> should be fine.

Ok, I must say I disagree.  I completely respect Chair indications with
respect to administrative, but I think that oppinion was expressed as a
technical oppinion, not as Chair, so anyone can disagree with it.

It is a very strong goal, and much more than qualifying as 'efficient or
less efficient', to not deliver the IPv6 multicast packet to a stack
that hasn't indicated willingness to participate into that multicast
group.  Or, to deliver a multicast packet only to a stack that has
expressed interest in it.  This is a requirement, as I see it.  What do
you think?

I can mention a scenario where this flooding can become a tsunami: if
one doesn't use link-layer filtering rules, or MLD, then an attacker can
send a packet to a 33:33 address and falsely put 33:33 in its src
address.  At which point everybody will respond to everybody, and more
everybody to everybody, etc.  A broadcasted NS is but an example.

Oftentimes this behaviour that I called 'tsunami' people call actually
'flooding'.  So our flooding problem would be so too.

What do you think about 'IPv6 flooding' not being ff:ff.. but '33:33',
and about the necessity to not deliver a multicast IPv6 packet to an
IPv6 stack that hasn't expressed interest in it?  Is this necessary in
your view?

Alex

------=_Part_109883_14843236.1169230532889-- --===============0219446657== 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 --===============0219446657==-- From 16ng-bounces@ietf.org Fri Jan 19 14:19:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zGK-00044F-JB; Fri, 19 Jan 2007 14:18:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zGJ-00043c-II for 16ng@ietf.org; Fri, 19 Jan 2007 14:18:55 -0500 Received: from nz-out-0506.google.com ([64.233.162.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7zGD-0007Yr-Te for 16ng@ietf.org; Fri, 19 Jan 2007 14:18:55 -0500 Received: by nz-out-0506.google.com with SMTP id z6so523196nzd for <16ng@ietf.org>; Fri, 19 Jan 2007 11:18:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=sq8Clmqi9aPdAl2atEypBs8fAXjZcqZahau54OPalgRnd7amLxhVOR9mhv1ePJZarEuzRXfluChYopErmfUblzpp06NQhOHog5vtPj557XdqiNkzeaT1hXdqgjQH/7X8GpEUCM/xGVGWFn4FqbvAjMfUBqnVqU+O0AhVhP3FBuM= Received: by 10.64.91.15 with SMTP id o15mr3524811qbb.1169234329346; Fri, 19 Jan 2007 11:18:49 -0800 (PST) Received: by 10.65.222.2 with HTTP; Fri, 19 Jan 2007 11:18:49 -0800 (PST) Message-ID: Date: Sat, 20 Jan 2007 04:18:49 +0900 From: "Jihoon Lee" To: "Alexandru Petrescu" In-Reply-To: <45B10631.6050809@motorola.com> MIME-Version: 1.0 References: <20070110194054.28319.qmail@web81914.mail.mud.yahoo.com> <45AB7268.7020609@motorola.com> <45ACD265.2080601@motorola.com> <45AFDE76.7070809@motorola.com> <45B0A860.2070303@motorola.com> <45B10631.6050809@motorola.com> X-Google-Sender-Auth: d39de5625169ba18 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: David Johnston , 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation and two questions to David Johnston 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="===============1222940866==" Errors-To: 16ng-bounces@ietf.org --===============1222940866== Content-Type: multipart/alternative; boundary="----=_Part_110412_2447189.1169234329304" ------=_Part_110412_2447189.1169234329304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Alex, Comments inline. Best regards, Brandon 2007/1/20, Alexandru Petrescu : > > Jihoon Lee wrote: > >> Ok, thanks, I understand MCA-RSP is not specified to be sent > >> unsolicited but as a response. In this case, we can specify that BS > >> before sending a RA it sends a MCA-REQ to poll who are the SS's > >> interested in receiving that RA, and thus SS can send the MCA-RSP > >> as it is designed. Remark that the router (entity who sends the RA > >> - BS or AR) MUST join the all-routers address (rfc2461), with a MLD > >> or with a local filter (popular interpretation). So subsequent to > >> sending that MLD REPORT, or setting up filtering rule, it can send > >> the MCA-REQ. So we can trigger the sending of MCA-REQ either by > >> sending the RA, or by MLD JOIN for all-routers, etc. What do you > >> think about this? Is this violating anything in 802.16. What > >> method would you prefer? > > > > Right now, I'm not sure about the usage of 802.16 MCA messages. > > Actually I thought the MCA differently. You may need to ask an 16 > > expert the usage of MCA. > > David, do you think an IPv6 stack on the BS can ask the 802.16MAC to > send a MCA-REQ to SS to ask it whether it's interested in receiving > packets addressed to 33:33:0:0:0:1? > > >> As I understand it DSA-REQ/RSP/ACK are for allocating service flows > >> with a certain QoS, bandwidth request, (table 113 ieee-2004). > >> This DSA-REQ is for a multicast CID, ok. I understand > >> DSA-REQ/RSP/ACK are not specifically designed to indicate intention > >> of belonging to a mc group - which is what I'm looking for, the > >> equivalent of MLD REPORT. What do you think? Should I look > >> elsewhere in the spec? > > > > Here is another feasible way. I believe this is similar to what > > you're trying to do: > > > > DSA performs 802.16 connection setup as well as the service flow > > creation. If there is no connection (actually CID) on SS, the SS > > cannot receive it at 802.16 link layer. When BS creates multicast > > connection between itself and MSs, DSA transaction is required for > > each MS. Therefore, BS can manage its multicast group which is > > associated with 802.16 multicast CID. In other words, MS may join by > > initiating DSA with appropriate multicast CID. Because, in theory, > > DSA can be initiated by either BS or MS. Consequently, the multicast > > can be delivered to intended users only in 802.16 link-layer. > > [At which point there would be a need to be able to convert IPv6 > link-local multicast addresses to multicast CIDs, right? Like ff02::1 > to 16bit. Or do you think 802.16MAC converts the 33:33::1 to a > multicast CID?] Here I assumed the former, converting IPv6 link-local multicast addresses to multicast CIDs. I understand. So the SS uses DSA messages to indicate interest in a > multicast-CID reception, and the BS keeps track of interests. It makes > sense to me. The packets addressed to a multicast group will arrive to > SS on that multicast CID. > > But I think we still need to say that it is the SS who triggers that DSA > exchange, ie SS's IPv6 stack. Do you agree? > It can happen in of the following alternative 2 ways: (1) IPv6 stack > generates a MLD REPORT and puts it to ETHCS Driver. ETHCS Driver > interprets it, drops it, and sends the corresponding DSA-REQ; (2) IPv6 > stack calls a function in ETHCS Driver giving it parameter 33:33::1 and > ETHCS Driver generates the DSA-REQ. > > I think this should work. Yes, it works. But, BS-trigger is still possible. (1) IPv6 stack generates a MLD REPORT and puts it to ETHCS Driver. ETHCS Driver pass it to 802.16 MAC, and it can be transmitted using uplink transport connection (unicast to BS). (2) MLD REPORT will be delivered from BS's 802.16 MAC to ETHCS. ETHCS can trigger BS-initiated DSA if the snooping has equipped. I cannot say which one is better. In the 802.16 point of view, BS-initiated DSA procedure is desirable, because we can assume that it has been authorized. In addition, naturally it protect from any malicious request. On the other hand, I agree that MS-initiated DSA is natural since MS initiates MLD-REPORT. Let me think. > BTW, basically 802.16 doesn't know any upper layer messages such as > > IGMP/MLD-REPORT. > > Unless it 'snoops' them? just standard 802.16 without any snooping. > So, there may be some issues, i.e., who will trigger a multicast > > connection setup, and which is better, BS-initiated or MS-initiated. > > Most IPv6 stacks currently call some function to join a certain group. > Some generate MLD REPORTS, some others just call a driver's function. > This can be matched into DSA-REQ/RSP. > > All IPv6 router stacks must join all-routers group, so the BS (_if_ it > sends RAs) should join. This matches the model of BS sending MCA-REQ > and SS sending MCA-RSP. > > > The MBS will be discussed in WiMAX Forum at the end of this month. > > Then, we may refer to details in DL multicast. > > Sorry, I don't know what's MBS. > > I think we have freedom to propose something that makes sense for > multicast IPv6 over ETHCS, here. If there's agreement in the group and > gets drafted then maybe MBS and WiMax will be interested to know what > the draft says. MBS is multicast and broadcast service, which defined in 802.16. However, it's described so general in 802.16. The word, "refer", which I used, is inappropriate. The point was there'll be similar discussion to what we're doing. >> If it does not then one really has to prevent unwanted > >> 33:33-addressed messages to reach the SS. Apparently the only way > >> left is to do it at BS, send the 33:33-addressed packets only to > >> those SS's that are interested. What do you think? > > > > I think you cannot define any classification rule in 'reconstitution' > > part of SS, since the 'reconstitution' part is defined in 802.16. > > David, is it possible for IPv6 stack to add classification rule to the > 'reconstitution' part of a SS, ie classifiers in SS that apply to > packets SS receives from BS, not 'uplink' classifiers that apply to > packets SS sends to BS. > > > Why don't you do that on top of 802.16? > > I was thinking we may save code. > > But then _where_ exactly on top of 802.16? Can I say add 'filtering > rule' in the ETHCS layer of SS? Or can I say add 'filtering rule' in > the Bridging function of the ETHCS layer of SS? But please, no > link-local multicast filtering rule in the IPv6 stack. I meant ETHCS. BTW, the bridging function also exists in SS ? > BTW, how about the scenario I mentioned above? I think it could also > > prevent unwanted/not-joined 33:33-addressed messages to reach the > > SS. > > I think it makes sense. I think DSA-REQ/RSP can be used by SS to set up > a multicast CID, based on my rough reading of the IEEE-2004 document. I > think it will open a connection on which the RA will be sent, for example. > > I think we need to identify what triggers the sending of the DSA-REQ. > I've suggested above. I think if we have agreement on that maybe we can write 4 short > paragraphs and then re-ask in the Working Group and the IEEE experts. > > Alex ------=_Part_110412_2447189.1169234329304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Alex,
 
Comments inline.
 
Best regards,
Brandon

 
2007/1/20, Alexandru Petrescu <alexandru.petrescu@motorola.com>:
Jihoon Lee wrote:
>> Ok, thanks, I understand MCA-RSP is not specified to be sent
>> unsolicited but as a response. In this case, we can specify that BS
>>  before sending a RA it sends a MCA-REQ to poll who are the SS's
>> interested in receiving that RA, and thus SS can send the MCA-RSP
>> as it is designed. Remark that the router (entity who sends the RA
>> - BS or AR) MUST join the all-routers address (rfc2461), with a MLD
>>  or with a local filter (popular interpretation).  So subsequent to
>>  sending that MLD REPORT, or setting up filtering rule, it can send
>>  the MCA-REQ.  So we can trigger the sending of MCA-REQ either by
>> sending the RA, or by MLD JOIN for all-routers, etc. What do you
>> think about this?  Is this violating anything in 802.16 . What
>> method would you prefer?
>
> Right now, I'm not sure about the usage of 802.16 MCA messages.
> Actually I thought the MCA differently. You may need to ask an 16
> expert the usage of MCA.

David, do you think an IPv6 stack on the BS can ask the 802.16MAC to
send a MCA-REQ to SS to ask it whether it's interested in receiving
packets addressed to 33:33:0:0:0:1?

>> As I understand it DSA-REQ/RSP/ACK are for allocating service flows
>>  with a certain QoS, bandwidth request, (table 113 ieee-2004).
>> This DSA-REQ is for a multicast CID, ok.  I understand
>> DSA-REQ/RSP/ACK are not specifically designed to indicate intention
>> of belonging to a mc group - which is what I'm looking for, the
>> equivalent of MLD REPORT. What do you think?  Should I look
>> elsewhere in the spec?
>
> Here is another feasible way. I believe this is similar to what
> you're trying to do:
>
> DSA performs 802.16 connection setup as well as the service flow
> creation. If there is no connection (actually CID) on SS, the SS
> cannot receive it at 802.16 link layer. When BS creates multicast
> connection between itself and MSs, DSA transaction is required for
> each MS. Therefore, BS can manage its multicast group which is
> associated with 802.16 multicast CID. In other words, MS may join by
> initiating DSA with appropriate multicast CID. Because, in theory,
> DSA can be initiated by either BS or MS. Consequently, the multicast
> can be delivered to intended users only in 802.16 link-layer.

[At which point there  would be a need to be able to convert IPv6
link-local multicast addresses to multicast CIDs, right?  Like ff02::1
to 16bit.  Or do you think 802.16MAC converts the 33:33::1 to a
multicast CID?]
 
Here I assumed the former, converting IPv6 link-local multicast addresses to multicast CIDs.
 

I understand.  So the SS uses DSA messages to indicate interest in a
multicast-CID reception, and the BS keeps track of interests.  It makes
sense to me.  The packets addressed to a multicast group will arrive to
SS on that multicast CID.

But I think we still need to say that it is the SS who triggers that DSA
exchange, ie SS's IPv6 stack.  Do you agree?
It can happen in of the following alternative 2 ways: (1) IPv6 stack
generates a MLD REPORT and puts it to ETHCS Driver.  ETHCS Driver
interprets it, drops it, and sends the corresponding DSA-REQ; (2) IPv6
stack calls a function in ETHCS Driver giving it parameter 33:33::1 and
ETHCS Driver generates the DSA-REQ.

I think this should work.
 
Yes, it works. But, BS-trigger is still possible. 
(1) IPv6 stack generates a MLD REPORT and puts it to ETHCS Driver. ETHCS Driver pass  it to 802.16 MAC, and it can be transmitted using uplink transport connection (unicast to BS).
(2) MLD REPORT will be delivered from BS's 802.16 MAC to ETHCS. ETHCS can trigger BS-initiated DSA if the snooping has equipped.
 
I cannot say which one is better. In the 802.16 point of view, BS-initiated DSA procedure is desirable, because we can assume that it has been authorized. In addition, naturally it protect from any malicious request.
On the other hand, I agree that MS-initiated DSA is natural since MS initiates MLD-REPORT.
 
Let me think.
 

> BTW, basically 802.16 doesn't know any upper layer messages such as
> IGMP/MLD-REPORT.

Unless it 'snoops' them?
just standard 802.16 without any snooping.

> So, there may be some issues, i.e., who will trigger a multicast
> connection setup, and which is better, BS-initiated or MS-initiated.

Most IPv6 stacks currently call some function to join a certain group.
Some generate MLD REPORTS, some others just call a driver's function.
This can be matched into DSA-REQ/RSP.

All IPv6 router stacks must join all-routers group, so the BS (_if_ it
sends RAs) should join.  This matches the model of BS sending MCA-REQ
and SS sending MCA-RSP.

> The MBS will be discussed in WiMAX Forum at the end of this month.
> Then, we may refer to details in DL multicast.

Sorry, I don't know what's MBS.

I think we have freedom to propose something that makes sense for
multicast IPv6 over ETHCS, here.  If there's agreement in the group and
gets drafted then maybe MBS and WiMax will be interested to know what
the draft says.
 
MBS is multicast and broadcast service, which defined in 802.16. However, it's described so general in 802.16. The word, "refer", which I used, is inappropriate. The point was there'll be similar discussion to what we're doing.

>> If it does not then one really has to prevent unwanted
>> 33:33-addressed messages to reach the SS.  Apparently the only way
>> left is to do it at BS, send the 33:33-addressed packets only to
>> those SS's that are interested.  What do you think?
>
> I think you cannot define any classification rule in 'reconstitution'
>  part of SS, since the 'reconstitution' part is defined in 802.16.

David, is it possible for IPv6 stack to add classification rule to the
'reconstitution' part of a SS, ie classifiers in SS that apply to
packets SS receives from BS, not 'uplink' classifiers that apply to
packets SS sends to BS.

> Why don't you do that on top of 802.16?

I was thinking we may save code.

But then _where_ exactly on top of 802.16?  Can I say add 'filtering
rule' in the ETHCS layer of SS?  Or can I say add 'filtering rule' in
the Bridging function of the ETHCS layer of SS?  But please, no
link-local multicast filtering rule in the IPv6 stack.
 
I meant ETHCS. BTW, the bridging function also exists in SS ?

> BTW, how about the scenario I mentioned above?  I think it could also
>  prevent unwanted/not-joined 33:33-addressed messages to reach the
> SS.

I think it makes sense.  I think DSA-REQ/RSP can be used by SS to set up
a multicast CID, based on my rough reading of the IEEE-2004 document.  I
think it will open a connection on which the RA will be sent, for example.

I think we need to identify what triggers the sending of the DSA-REQ.
I've suggested above.
 
 

I think if we have agreement on that maybe we can write 4 short
paragraphs and then re-ask in the Working Group and the IEEE experts.

Alex
 
 

 
------=_Part_110412_2447189.1169234329304-- --===============1222940866== 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 --===============1222940866==-- From 16ng-bounces@ietf.org Sun Jan 21 12:36:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8gcM-0008O6-BQ; Sun, 21 Jan 2007 12:36:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8gcK-0008Kw-PO for 16ng@ietf.org; Sun, 21 Jan 2007 12:36:32 -0500 Received: from ca2-msx-c01.nw.net ([206.15.67.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8gcI-0004nS-TU for 16ng@ietf.org; Sun, 21 Jan 2007 12:36:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 21 Jan 2007 09:38:21 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: stepped multicast operation and two questions to David Johnston Thread-Index: Acc7/vCTcPrVfMWiTEyivRIZMD+PfQBgEP+w From: "David Johnston" To: "Jihoon Lee" , "Alexandru Petrescu" X-Spam-Score: 0.1 (/) X-Scan-Signature: 772a6990a160cebc49b9e3d175956d12 Cc: 16ng@ietf.org Subject: [16NG] RE: stepped multicast operation and two questions to David Johnston 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="===============1146861903==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============1146861903== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73D82.F2607AC5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73D82.F2607AC5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Replies inline... =20 ________________________________ From: brandon.jihoon@gmail.com [mailto:brandon.jihoon@gmail.com] On Behalf Of Jihoon Lee Sent: Friday, January 19, 2007 11:19 AM To: Alexandru Petrescu Cc: 16ng@ietf.org; David Johnston Subject: Re: stepped multicast operation and two questions to David Johnston =20 Hi Alex, =20 Comments inline. =20 Best regards, Brandon =20 2007/1/20, Alexandru Petrescu :=20 Jihoon Lee wrote: >> Ok, thanks, I understand MCA-RSP is not specified to be sent >> unsolicited but as a response. In this case, we can specify that BS=20 >> before sending a RA it sends a MCA-REQ to poll who are the SS's >> interested in receiving that RA, and thus SS can send the MCA-RSP >> as it is designed. Remark that the router (entity who sends the RA=20 >> - BS or AR) MUST join the all-routers address (rfc2461), with a MLD >> or with a local filter (popular interpretation). So subsequent to >> sending that MLD REPORT, or setting up filtering rule, it can send=20 >> the MCA-REQ. So we can trigger the sending of MCA-REQ either by >> sending the RA, or by MLD JOIN for all-routers, etc. What do you >> think about this? Is this violating anything in 802.16 . What >> method would you prefer? > > Right now, I'm not sure about the usage of 802.16 MCA messages. > Actually I thought the MCA differently. You may need to ask an 16 > expert the usage of MCA.=20 David, do you think an IPv6 stack on the BS can ask the 802.16MAC to send a MCA-REQ to SS to ask it whether it's interested in receiving packets addressed to 33:33:0:0:0:1? =20 No. In the case of an IP Packet CS, the IPv6 stack can send a packet to 33:33:0:0:0:1 down into the IP Packet CS of 802.16 and expect the packet to be correctly dealt with. What happens next is up to the CS. It *might* cause the CS to perform an MCS-REQ in an implementation, but I doubt it. =20 The IP Packet CS has the responsibility to set up connections that it can use to deal with the packets it needs to send and receive to correctly provide the CS MAC service. There are no hard and fast rules about what those connections are. The CS may set up multiple connections with different QoS parameter and perform classification to assign packets to connections. =20 If the IP Packet CS thinks it can use a multicast group to better implement the MAC service, then it can set one up. However the MAC CPS multicast service is downlink only, so some thought on the part of the implementer would be required to know to make this work right. I don't personally think this has been addressed in any literature I have read and I don't myself see how it can work well. The correct use of unicast connections is much more obvious. In the case of the Ethernet Packet CS, ARP happens as per Ethernet and the Ethernet Packet CS, similarly to the IP Packet CS, could use multicast group to implement the correct delivery of 802 addressed packets (that may be uni, broad or multicast). But again it sounds like more trouble than it is worth to get right. >> As I understand it DSA-REQ/RSP/ACK are for allocating service flows=20 >> with a certain QoS, bandwidth request, (table 113 ieee-2004). >> This DSA-REQ is for a multicast CID, ok. I understand >> DSA-REQ/RSP/ACK are not specifically designed to indicate intention=20 >> of belonging to a mc group - which is what I'm looking for, the >> equivalent of MLD REPORT. What do you think? Should I look >> elsewhere in the spec? > > Here is another feasible way. I believe this is similar to what=20 > you're trying to do: > > DSA performs 802.16 connection setup as well as the service flow > creation. If there is no connection (actually CID) on SS, the SS > cannot receive it at 802.16 link layer. When BS creates multicast > connection between itself and MSs, DSA transaction is required for > each MS. Therefore, BS can manage its multicast group which is > associated with 802.16 multicast CID. In other words, MS may join by=20 > initiating DSA with appropriate multicast CID. Because, in theory, > DSA can be initiated by either BS or MS. Consequently, the multicast > can be delivered to intended users only in 802.16 link-layer.=20 [At which point there would be a need to be able to convert IPv6 link-local multicast addresses to multicast CIDs, right? Like ff02::1 to 16bit. Or do you think 802.16MAC converts the 33:33::1 to a multicast CID?]=20 =20 DJ - This is the normal CS classification scheme. I.E. assigning outgoing traffic to CID based on packet contents. But can this work asymmetrically? The uplink has no multicast CIDs because of the limitations of the laws of physics. Hence my preference for the Ethernet CS and GPCS(when it comes). =20 Here I assumed the former, converting IPv6 link-local multicast addresses to multicast CIDs. =20 =20 I understand. So the SS uses DSA messages to indicate interest in a multicast-CID reception, and the BS keeps track of interests. It makes=20 sense to me. The packets addressed to a multicast group will arrive to SS on that multicast CID. =09 But I think we still need to say that it is the SS who triggers that DSA exchange, ie SS's IPv6 stack. Do you agree?=20 It can happen in of the following alternative 2 ways: (1) IPv6 stack generates a MLD REPORT and puts it to ETHCS Driver. ETHCS Driver=20 interprets it, drops it, and sends the corresponding DSA-REQ; (2) IPv6 stack calls a function in ETHCS Driver giving it parameter 33:33::1 and ETHCS Driver generates the DSA-REQ. =09 I think this should work.=20 =20 Yes, it works. But, BS-trigger is still possible.=20 (1) IPv6 stack generates a MLD REPORT and puts it to ETHCS Driver. ETHCS Driver pass it to 802.16 MAC, and it can be transmitted using uplink transport connection (unicast to BS). (2) MLD REPORT will be delivered from BS's 802.16 MAC to ETHCS. ETHCS can trigger BS-initiated DSA if the snooping has equipped.=20 =20 I cannot say which one is better. In the 802.16 point of view, BS-initiated DSA procedure is desirable, because we can assume that it has been authorized. In addition, naturally it protect from any malicious request.=20 On the other hand, I agree that MS-initiated DSA is natural since MS initiates MLD-REPORT. =20 Let me think. =20 =20 > BTW, basically 802.16 doesn't know any upper layer messages such as > IGMP/MLD-REPORT. =09 Unless it 'snoops' them? just standard 802.16 without any snooping. =20 > So, there may be some issues, i.e., who will trigger a multicast > connection setup, and which is better, BS-initiated or MS-initiated.=20 =09 Most IPv6 stacks currently call some function to join a certain group. Some generate MLD REPORTS, some others just call a driver's function. This can be matched into DSA-REQ/RSP. =09 All IPv6 router stacks must join all-routers group, so the BS (_if_ it=20 sends RAs) should join. This matches the model of BS sending MCA-REQ and SS sending MCA-RSP. =09 > The MBS will be discussed in WiMAX Forum at the end of this month. > Then, we may refer to details in DL multicast.=20 =09 Sorry, I don't know what's MBS. =09 I think we have freedom to propose something that makes sense for multicast IPv6 over ETHCS, here. If there's agreement in the group and gets drafted then maybe MBS and WiMax will be interested to know what=20 the draft says. =20 MBS is multicast and broadcast service, which defined in 802.16. However, it's described so general in 802.16. The word, "refer", which I used, is inappropriate. The point was there'll be similar discussion to what we're doing.=20 =20 >> If it does not then one really has to prevent unwanted >> 33:33-addressed messages to reach the SS. Apparently the only way=20 >> left is to do it at BS, send the 33:33-addressed packets only to >> those SS's that are interested. What do you think? > > I think you cannot define any classification rule in 'reconstitution'=20 > part of SS, since the 'reconstitution' part is defined in 802.16. =09 David, is it possible for IPv6 stack to add classification rule to the 'reconstitution' part of a SS, ie classifiers in SS that apply to=20 packets SS receives from BS, not 'uplink' classifiers that apply to packets SS sends to BS. =09 =09 I assume you mean for PHS? Reconstitution of PHS compressed packets does not need to refer to the classification rules. It just needs to uncompress what was compressed and this is a handle-turning algorithm. =20 An SS can know the classification rules applied to a DL connection by remembering them from the connection setup. But why? What can it do beyond sending the packets up to the IP stack/bridge? Traffic filtering can happen but I don't think it is the job of 802.16 to define that. It's more of an implementation thing. =09 > Why don't you do that on top of 802.16? =09 I was thinking we may save code. =09 But then _where_ exactly on top of 802.16? Can I say add 'filtering rule' in the ETHCS layer of SS? Or can I say add 'filtering rule' in the Bridging function of the ETHCS layer of SS? But please, no link-local multicast filtering rule in the IPv6 stack.=20 =20 I meant ETHCS. BTW, the bridging function also exists in SS ? =20 Bridging might exist. In the 802 world, you shouldn't need to know and things will work right. 802.1AB exists if you feel the need to probe. =20 > BTW, how about the scenario I mentioned above? I think it could also > prevent unwanted/not-joined 33:33-addressed messages to reach the=20 > SS. =09 I think it makes sense. I think DSA-REQ/RSP can be used by SS to set up a multicast CID, based on my rough reading of the IEEE-2004 document. I think it will open a connection on which the RA will be sent, for example.=20 =09 I think we need to identify what triggers the sending of the DSA-REQ. I've suggested above. =20 =20 =20 I think if we have agreement on that maybe we can write 4 short paragraphs and then re-ask in the Working Group and the IEEE experts.=20 =09 =09 Yes. Feel free. I can do my liaisonly duty and pass them on. =09 Alex =20 =20 =20 ------_=_NextPart_001_01C73D82.F2607AC5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Replies = inline…

 

From: brandon.jihoon@gmail.com [mailto:brandon.jihoon@gmail.com] On Behalf Of Jihoon Lee
Sent: Friday, January 19, = 2007 11:19 AM
To: Alexandru = Petrescu
Cc: 16ng@ietf.org; David = Johnston
Subject: Re: stepped = multicast operation and two questions to David = Johnston

 

Hi Alex,

 

Comments inline.

 

Best regards,

Brandon
 

2007/1/20, Alexandru Petrescu <alexandru.petrescu@motoro= la.com>:

Jihoon Lee wrote:
>> Ok, thanks, I understand MCA-RSP is not specified to be = sent
>> unsolicited but as a response. In this case, we can specify = that BS
>>  before sending a RA it sends a MCA-REQ to poll who = are the SS's
>> interested in receiving that RA, and thus SS can send the = MCA-RSP
>> as it is designed. Remark that the router (entity who sends the = RA
>> - BS or AR) MUST join the all-routers address (rfc2461), with a = MLD
>>  or with a local filter (popular interpretation).  So subsequent to
>>  sending that MLD REPORT, or setting up filtering = rule, it can send
>>  the MCA-REQ.  So we can trigger the = sending of MCA-REQ either by
>> sending the RA, or by MLD JOIN for all-routers, etc. What do = you
>> think about this?  Is this violating anything in = 802.16 . What
>> method would you prefer?
>
> Right now, I'm not sure about the usage of 802.16 MCA messages.
> Actually I thought the MCA differently. You may need to ask an = 16
> expert the usage of MCA.

David, do you think an IPv6 stack on the BS can ask the 802.16MAC to
send a MCA-REQ to SS to ask it whether it's interested in receiving
packets addressed to 33:33:0:0:0:1?

 

No. In the case of an IP Packet CS, = the IPv6 stack can send a packet to 33:33:0:0:0:1 down into the IP Packet CS = of 802.16 and expect the packet to be correctly dealt with. What happens = next is up to the CS. It *might* = cause the CS to perform an MCS-REQ in an implementation, but I doubt = it.

 

The IP Packet CS has the = responsibility to set up connections that it can use to deal with the packets it needs to = send and receive to correctly provide the CS MAC service. There are no hard = and fast rules about what those connections are. The CS may set up multiple = connections with different QoS parameter and perform classification to assign = packets to connections.

 

If the IP Packet CS thinks it can = use a multicast group to better implement the MAC service, then it can set one = up. However the MAC CPS multicast service is downlink only, so some thought = on the part of the implementer would be required to know to make this work = right. I don’t personally think this has been addressed in any literature I = have read and I don’t myself see how it can work well. The correct use = of unicast connections is much more obvious.


In the case of the = Ethernet Packet CS, ARP happens as per Ethernet and the Ethernet Packet CS, similarly to = the IP Packet CS, could use multicast group to implement the correct delivery = of 802 addressed packets (that may be uni, broad or multicast). But again it = sounds like more trouble than it is worth to get = right.


>> As I understand it DSA-REQ/RSP/ACK are for allocating service = flows
>>  with a certain QoS, bandwidth request, (table 113 ieee-2004).
>> This DSA-REQ is for a multicast CID, ok.  I = understand
>> DSA-REQ/RSP/ACK are not specifically designed to indicate = intention
>> of belonging to a mc group - which is what I'm looking for, = the
>> equivalent of MLD REPORT. What do you think?  Should = I look
>> elsewhere in the spec?
>
> Here is another feasible way. I believe this is similar to what =
> you're trying to do:
>
> DSA performs 802.16 connection setup as well as the service = flow
> creation. If there is no connection (actually CID) on SS, the = SS
> cannot receive it at 802.16 link layer. When BS creates = multicast
> connection between itself and MSs, DSA transaction is required = for
> each MS. Therefore, BS can manage its multicast group which is
> associated with 802.16 multicast CID. In other words, MS may join = by
> initiating DSA with appropriate multicast CID. Because, in = theory,
> DSA can be initiated by either BS or MS. Consequently, the = multicast
> can be delivered to intended users only in 802.16 link-layer.

[At which point there  would be a need to be able to convert = IPv6
link-local multicast addresses to multicast CIDs, right?  Like ff02::1
to 16bit.  Or do you think 802.16MAC converts the 33:33::1 to = a
multicast CID?]

 

=

DJ – This is the normal CS classification scheme. I.E. assigning outgoing traffic to CID based on = packet contents. But can this work asymmetrically? The uplink has no multicast = CIDs because of the limitations of the laws of physics. Hence my preference = for the Ethernet CS and GPCS(when it comes).

 

Here I assumed the former, converting IPv6 link-local multicast addresses to multicast CIDs.

 

 

I understand.  So the SS uses DSA messages to indicate interest in a
multicast-CID reception, and the BS keeps track of = interests.  It makes
sense to me.  The packets addressed to a multicast group will = arrive to
SS on that multicast CID.

But I think we still need to say that it is the SS who triggers that = DSA
exchange, ie SS's IPv6 stack.  Do you agree? =

It can happen in of the following alternative 2 ways: (1) IPv6 = stack
generates a MLD REPORT and puts it to ETHCS Driver.  ETHCS = Driver
interprets it, drops it, and sends the corresponding DSA-REQ; (2) = IPv6
stack calls a function in ETHCS Driver giving it parameter 33:33::1 = and
ETHCS Driver generates the DSA-REQ.

I think this should work.

 

Yes, it works. But, BS-trigger is still = possible. 

(1) IPv6 stack generates a MLD REPORT and puts it to ETHCS = Driver. ETHCS Driver pass  it to 802.16 MAC, and it can be transmitted = using uplink transport connection (unicast to = BS).

(2) MLD REPORT will be delivered from BS's 802.16 MAC to ETHCS. = ETHCS can trigger BS-initiated DSA if the snooping has equipped. =

 

I cannot say which one is better. In the 802.16 point of view, BS-initiated DSA procedure is desirable, because we can = assume that it has been authorized. In addition, naturally it protect from = any malicious request.

On the other hand, I agree that MS-initiated DSA is natural = since MS initiates MLD-REPORT.

 

Let me think.

 

 

> BTW, basically 802.16 doesn't know any upper layer messages = such as
> IGMP/MLD-REPORT.

Unless it 'snoops' them?

just standard 802.16 without any = snooping.

 

> So, there may be some issues, i.e., who will trigger a = multicast
> connection setup, and which is better, BS-initiated or = MS-initiated.

Most IPv6 stacks currently call some function to join a certain = group.
Some generate MLD REPORTS, some others just call a driver's = function.
This can be matched into DSA-REQ/RSP.

All IPv6 router stacks must join all-routers group, so the BS (_if_ it =
sends RAs) should join.  This matches the model of BS sending = MCA-REQ
and SS sending MCA-RSP.

> The MBS will be discussed in WiMAX Forum at the end of this = month.
> Then, we may refer to details in DL multicast.

Sorry, I don't know what's MBS.

I think we have freedom to propose something that makes sense for
multicast IPv6 over ETHCS, here.  If there's agreement in the = group and
gets drafted then maybe MBS and WiMax will be interested to know what =
the draft says.

 

MBS is multicast and broadcast service, which defined in 802.16. However, it's described so general in 802.16. The word, = "refer", which I used, is inappropriate. The point was there'll be similar discussion to what we're doing.

 

>> If it does not then one really has to prevent = unwanted
>> 33:33-addressed messages to reach the SS.  Apparently = the only way
>> left is to do it at BS, send the 33:33-addressed packets only = to
>> those SS's that are interested.  What do you = think?
>
> I think you cannot define any classification rule in = 'reconstitution'
>  part of SS, since the 'reconstitution' part is defined = in 802.16.

David, is it possible for IPv6 stack to add classification rule to = the
'reconstitution' part of a SS, ie classifiers in SS that apply to
packets SS receives from BS, not 'uplink' classifiers that apply to
packets SS sends to BS.

I assume you mean for PHS? = Reconstitution of PHS compressed packets does not need to refer to the classification = rules. It just needs to uncompress what was compressed and this is a = handle-turning algorithm.

 

An SS can know the classification = rules applied to a DL connection by remembering them from the connection = setup. But why? What can it do beyond sending the packets up to the IP = stack/bridge? Traffic filtering can happen but I don’t think it is the job of 802.16 to = define that. It’s more of an implementation = thing.


> Why don't you do that on top of 802.16?

I was thinking we may save code.

But then _where_ exactly on top of 802.16?  Can I say add = 'filtering
rule' in the ETHCS layer of SS?  Or can I say add 'filtering = rule' in
the Bridging function of the ETHCS layer of SS?  But please, = no
link-local multicast filtering rule in the IPv6 stack. =

 

I meant ETHCS. BTW, the bridging function also exists in = SS ?

 

=

Bridging might exist. In the 802 = world, you shouldn’t need to know and things will work right. 802.1AB = exists if you feel the need to probe.

 

> BTW, how about the scenario I mentioned above?  I = think it could also
>  prevent unwanted/not-joined 33:33-addressed messages to = reach the
> SS.

I think it makes sense.  I think DSA-REQ/RSP can be used by SS = to set up
a multicast CID, based on my rough reading of the IEEE-2004 document.  I
think it will open a connection on which the RA will be sent, for = example.

I think we need to identify what triggers the sending of the = DSA-REQ.
I've suggested above.

 

 

 

I think if we have agreement on that maybe we can write 4 = short
paragraphs and then re-ask in the Working Group and the IEEE experts. =

Yes. Feel free. I can do my = liaisonly duty and pass them on.


Alex

 

 


 

------_=_NextPart_001_01C73D82.F2607AC5-- --===============1146861903== 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 --===============1146861903==-- From 16ng-bounces@ietf.org Mon Jan 22 13:08:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93aR-0002G9-EJ; Mon, 22 Jan 2007 13:08:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H93aQ-0002G3-EW for 16ng@ietf.org; Mon, 22 Jan 2007 13:08:06 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H93aP-0003je-90 for 16ng@ietf.org; Mon, 22 Jan 2007 13:08:06 -0500 Received: by an-out-0708.google.com with SMTP id d30so449709and for <16ng@ietf.org>; Mon, 22 Jan 2007 10:08:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=k9UngThrEYfGWC9OPeye1AuoesxfQPoJAwhgWH9JfT2rFoONrdHYvaGBH6onx/Opw7xdO+9C0aLVqhTclgxZ5XEkSYvXtD5lbmET0bC2ycKcxMWQA6AkUzplga5V0cDiBI1cZwdvs3rajYX6b+urJ+0s9XMT2bKa1V999TC6bFA= Received: by 10.100.48.7 with SMTP id v7mr692815anv.1169489284977; Mon, 22 Jan 2007 10:08:04 -0800 (PST) Received: by 10.100.151.4 with HTTP; Mon, 22 Jan 2007 10:08:04 -0800 (PST) Message-ID: Date: Tue, 23 Jan 2007 03:08:04 +0900 From: "Daniel Park" To: 16ng@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [16NG] A new secretary of the 16ng working group 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 Jihoon Lee who is a new secretary of the 16ng working group. We've escaped from the note taker...:-) -- 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 Tue Jan 23 14:04:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Qwm-0006Er-LB; Tue, 23 Jan 2007 14:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Qwl-0006EH-2y for 16ng@ietf.org; Tue, 23 Jan 2007 14:04:43 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Qwi-0002UM-Gg for 16ng@ietf.org; Tue, 23 Jan 2007 14:04:43 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B8A1219876D; Tue, 23 Jan 2007 21:04:38 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6B32C19876C; Tue, 23 Jan 2007 21:04:38 +0200 (EET) Message-ID: <45B65C47.9020802@piuha.net> Date: Tue, 23 Jan 2007 21:04:39 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Basavaraj Patil 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: 21c69d3cfc2dd19218717dbe1d974352 Cc: 16ng@ietf.org Subject: [16NG] review of the new revision (ipv6 over ipcs) 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 Basavaraj, all I reviewed the new version of this spec, and I'm generally quite happy with it. I found three small remaining issues which are listed below: > +-----+ CID1 +-----+ +-----------+ > | MS1 |----------/| BS1 |----------| AR |-----[Internet ] > +-----+ / +-----+ +-----------+ > . / ____________ > . CIDn / ()__________() > +-----+ / L2 Tunnel > | MSn |-----/ > +-----+ > > > Figure 5: The IPv6 AR is separate from the BS, which acts as a bridge > The part about the BS acting as a bridge seems surprising. Is this really the case? A standard bridge function? > This > section presents a model for the last mile link, i.e. the link to > which MSs attach themselves. I would remove this sentence. You need to explain how the link looks like from an IP perspective. And I think you are doing that. Whether there is a distributed or integrated BS/AR at the other end is really not a key issue. > IEEE > 802.16 also defines a secondary management connection that can be > used for host configuration. However support for secondary > management connections is not mandatory. A transport connection has > the advantage of it being used for host configuration as well as for > user data. Are you specifying something about the use of the management connections? If not, take it out. > Each MS belongs to > a different link. No two MSs belong to the same link. Duplication. Remove the first sentence. Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 23 15:19:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9S72-0008Ji-FI; Tue, 23 Jan 2007 15:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9S70-0008Jc-Fl for 16ng@ietf.org; Tue, 23 Jan 2007 15:19:22 -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 1H9S6y-0001D6-Vy for 16ng@ietf.org; Tue, 23 Jan 2007 15:19:22 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0NKGOPB006471; Tue, 23 Jan 2007 22:16:52 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 22:19:40 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jan 2007 14:19:38 -0600 Received: from 10.162.253.241 ([10.162.253.241]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Jan 2007 20:19:38 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 23 Jan 2007 14:21:02 -0600 From: Basavaraj Patil To: ext Jari Arkko Message-ID: Thread-Topic: review of the new revision (ipv6 over ipcs) Thread-Index: Acc/LABUPwgEjKsfEduYWwARJNUNiA== In-Reply-To: <45B65C47.9020802@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jan 2007 20:19:38.0599 (UTC) FILETIME=[CE9E8F70:01C73F2B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 16ng@ietf.org Subject: [16NG] Re: review of the new revision (ipv6 over ipcs) 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, Responses inline: On 1/23/07 1:04 PM, "ext Jari Arkko" wrote: > Basavaraj, all > > I reviewed the new version of this spec, and > I'm generally quite happy with it. I found three > small remaining issues which are listed below: >> +-----+ CID1 +-----+ +-----------+ >> | MS1 |----------/| BS1 |----------| AR |-----[Internet >> >> ] >> +-----+ / +-----+ +-----------+ >> . / ____________ >> . CIDn / ()__________() >> +-----+ / L2 Tunnel >> | MSn |-----/ >> +-----+ >> >> >> Figure 5: The IPv6 AR is separate from the BS, which acts as a bridge >> > The part about the BS acting as a bridge seems surprising. > Is this really the case? A standard bridge function? I did'nt mean bridge from the "standard bridge function" definition. I will delete it from the document. Basically the BS is an L1/L2 entity, but I do not believe I will not to elaborate on that. > >> This >> section presents a model for the last mile link, i.e. the link to >> which MSs attach themselves. > I would remove this sentence. You need to explain > how the link looks like from an IP perspective. > And I think you are doing that. Whether there > is a distributed or integrated BS/AR at the other > end is really not a key issue. Okay. Will work on this text as suggested. > >> IEEE >> 802.16 also defines a secondary management connection that can be >> used for host configuration. However support for secondary >> management connections is not mandatory. A transport connection has >> the advantage of it being used for host configuration as well as for >> user data. > Are you specifying something about the use of the > management connections? If not, take it out. > Not really specifying anything w.r.t the management connection. This came up during discussion with Alex Petrescu and I added it just for the sake of completeness. Within the scope of this I-D, the management connection has no relevance. I can take it out. >> Each MS belongs to >> a different link. No two MSs belong to the same link. > Duplication. Remove the first sentence. > Okay. Editorial fix. Will submit a revised version with these changes. -Raj > Jari > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 23 21:22:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9XmA-0004Ni-JX; Tue, 23 Jan 2007 21:22:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Xm9-0004Na-EE for 16ng@ietf.org; Tue, 23 Jan 2007 21:22:13 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9Xm8-00062L-8H for 16ng@ietf.org; Tue, 23 Jan 2007 21:22:13 -0500 Received: by an-out-0708.google.com with SMTP id d30so15393and for <16ng@ietf.org>; Tue, 23 Jan 2007 18:22:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=B9zX+5ZdCQpX4qTAE8XFN4j5oBK1tJH824yKvCJWXNJaXtmKewSKrmuLpopT7TDnlaVyb9KIHm0L1Jza93NLw7biG/GPRae2J7eNlAdGsvYmnE95iivrlOMkIXbtDScH/mby+uVk2njtV9Wz2/cwmYLiJnENTVSEWM8FhV+Y4Uo= Received: by 10.100.132.16 with SMTP id f16mr568and.1169605331864; Tue, 23 Jan 2007 18:22:11 -0800 (PST) Received: by 10.100.13.14 with HTTP; Tue, 23 Jan 2007 18:22:11 -0800 (PST) Message-ID: Date: Wed, 24 Jan 2007 11:22:11 +0900 From: "Daniel Park" To: 16ng@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [16NG] Call for agenda item 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 Dear all, Our session has been scheduled in Prague. The length of session is 2 hours. Thus, I am soliciting agenda items. For those who are thinking about 16ng agenda items in Prague meeting on March. Please let chairs know them including required items below: Due is 24th of March. o Required Items: [1] Title of presentation: [2] Speaker: [3] Associated I-D or document: [4] Slot length: [5] Abstract (in brief) -- 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 Wed Jan 24 13:49:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nBt-0003Yp-VE; Wed, 24 Jan 2007 13:49:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nBs-0003YC-90 for 16ng@ietf.org; Wed, 24 Jan 2007 13:49:48 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9nBp-0004qs-NA for 16ng@ietf.org; Wed, 24 Jan 2007 13:49:48 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1169664584!556707!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16081 invoked from network); 24 Jan 2007 18:49:44 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 24 Jan 2007 18:49:44 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0OIneHw028373; Wed, 24 Jan 2007 11:49:40 -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 l0OInd2Y015139; Wed, 24 Jan 2007 12:49:39 -0600 (CST) Message-ID: <45B7AA42.7010004@motorola.com> Date: Wed, 24 Jan 2007 19:49:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) 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: 7e439b86d3292ef5adf93b694a43a576 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 Raj, Jari, thanks for having this exchange public on the mailing list. I will precede this mail with a high-level unease I have about advancement of this draft towards a Standards Track RFC. This can be solved by several ways, eg change its name into 'Goals for ...' or maybe change status, or other way one may think of. The draft is definitely well written, complete in its own and self-contained, a piece of text worth the effort to submit to IESG. Usually a a Standards Track RFC gives clear directions about what should be implemented. This document doesn't: there's no new message format, no new message exchange, no new issues with other implementation, 'MUST' occurs only two times and it's for lifetimes in RA - no new lifetime in RA suggested, 'SHOULD' appears once to say MTU should be what 2460 recommends (which is good), 'MAY' never appears. It doesn't offer a implementer anything special that should be done about running an existing IPv6 stack over a new kind of link (802.16 IPv6CS in this case, allow me the term IPv6CS). Section 2 Introduction describes what the IEEE standard describes. It also describes what WiMax thinks the architecture should be. Section 3 Terminology describes a new term 'ASN' which is a WiMax term. Sections 4 and 5 are architectural descriptions, from IEEE documents. One very important part in Section 4, giving indication to which specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS or IPv6CS?) is left implementation-dependent (who implements that? how?) - is there an RA-overIPv6CS enhancement that says use ETHCS vs use IPv6CS. Section 6 'IPv6 link' makes recommendation about how to configure things, but nothing to implement. Section 6.2 'IPv6 link establishment' which is the 802.16 network-entry procedure. What should the IPv6 stack implementer write? Section 6.3 'MTU' says MTU should be what it should be. This is a good goal, but what to implementer means? Section 7 "IPv6 Prefix Assignment" recommends each mobile to be on a different prefix. This is (1) different than any other IPv6-over-foo documents (and there are other point-to-point links out there not recommending this) and (2) a configuration management issue, nothing to be implemented. Section 8 "Router Discovery" is standard behaviour nothing new, nothing to implement. Section 9 "IPv6 addressing for hosts" - nothing new. I could think of SeND issues with the MS having the same link-local address on all its 802.16 connections (subnets) but that's all. These are the reasons I have that uneases. That said, let me address the point where I was cited, see below. Basavaraj Patil wrote: > Hi Jari, > > Responses inline: > > > On 1/23/07 1:04 PM, "ext Jari Arkko" wrote: > >> Basavaraj, all >> >> I reviewed the new version of this spec, and I'm generally quite >> happy with it. I found three small remaining issues which are >> listed below: >>> +-----+ CID1 +-----+ +-----------+ | MS1 >>> |----------/| BS1 |----------| AR |-----[Internet >>> > >> > ] >>> +-----+ / +-----+ +-----------+ . / >>> ____________ . CIDn / ()__________() +-----+ / L2 >>> Tunnel | MSn |-----/ +-----+ >>> >>> >>> Figure 5: The IPv6 AR is separate from the BS, which acts as a >>> bridge >>> >> The part about the BS acting as a bridge seems surprising. Is this >> really the case? A standard bridge function? > > I did'nt mean bridge from the "standard bridge function" definition. > I will delete it from the document. Basically the BS is an L1/L2 > entity, but I do not believe I will not to elaborate on that. > >>> This section presents a model for the last mile link, i.e. the >>> link to which MSs attach themselves. >> I would remove this sentence. You need to explain how the link >> looks like from an IP perspective. And I think you are doing that. >> Whether there is a distributed or integrated BS/AR at the other >> end is really not a key issue. > > Okay. Will work on this text as suggested. > >>> IEEE 802.16 also defines a secondary management connection that >>> can be used for host configuration. However support for >>> secondary management connections is not mandatory. A transport >>> connection has the advantage of it being used for host >>> configuration as well as for user data. >> Are you specifying something about the use of the management >> connections? If not, take it out. >> > > Not really specifying anything w.r.t the management connection. This > came up during discussion with Alex Petrescu and I added it just for > the sake of completeness. Within the scope of this I-D, the > management connection has no relevance. I can take it out. Yes, the issue is that 802.16 recommends the RS/RA to happen on a Secondary Management Connection (instead of on a Transport Connection). Clarifications on the list suggested that probably nobody uses a SMC. But that doesn't mean that the IEEE spec isn't saying so. So one could write in the draft that "contrary to the IEEE Spec, this draft recommends the use of a normal transport connection for an RS/RA". I would suggest that actually. But there may be other oppinions as well. Another thing that was mentioned in the list, and it was agreed by me and Tim, is that there may be an issue with the indication of how to auto-configure an address: statelessly or statefully. This indicator comes from an RA in an IP-only world but in 802.16 it comes from a link-layer message too. This is an obvious risk for interoperability: what if the BS says stateless but AR says stateful. In this line of thought some may remark (from my experience in other WGs) that people should be capable to configure their networks ok, and these clarifications shouldn't be specified. But here we talk things to be done at MAC layer vs at Network layer, and maybe it's not the same people doing it. So I would suggest to at least clarify that IPv6-over-IPv6CS recommends to ignore that link-layer indicator. But there may be other oppinions on this topic too. Finally, even with all these clarifying remarks I'm making in the inner body of the mail, I think there is still nothing new to be implemented - which is good in a good sense, less work :-) Alex > >>> Each MS belongs to a different link. No two MSs belong to the >>> same link. >> Duplication. Remove the first sentence. >> > > Okay. Editorial fix. > > Will submit a revised version with these changes. > > -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 Wed Jan 24 14:05:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nRH-0003KJ-B2; Wed, 24 Jan 2007 14:05:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nRF-0003Hk-GH for 16ng@ietf.org; Wed, 24 Jan 2007 14:05:41 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H9nRC-0000Gu-Vo for 16ng@ietf.org; Wed, 24 Jan 2007 14:05:41 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-153.messagelabs.com!1169665535!434666!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 13789 invoked from network); 24 Jan 2007 19:05:35 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-7.tower-153.messagelabs.com with SMTP; 24 Jan 2007 19:05:35 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l0OJD2dv002507; Wed, 24 Jan 2007 12:13:03 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0OJ5OF7024114; Wed, 24 Jan 2007 13:05:28 -0600 (CST) Message-ID: <45B7ADF3.1030309@motorola.com> Date: Wed, 24 Jan 2007 20:05:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: David Johnston References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: 16ng@ietf.org Subject: [16NG] Re: stepped multicast operation and two questions to David Johnston 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 David, thanks the mail. Let me reply quickly to some of the text. I've planned more detailed answer, but I'm figuring to let the first things first and then I'll see. David Johnston wrote: > >> Jihoon Lee wrote: >>>> Ok, thanks, I understand MCA-RSP is not specified to be sent >>>> unsolicited but as a response. In this case, we can specify >>>> that BS before sending a RA it sends a MCA-REQ to poll who are >>>> the SS's interested in receiving that RA, and thus SS can send >>>> the MCA-RSP as it is designed. Remark that the router (entity >>>> who sends the RA - BS or AR) MUST join the all-routers address >>>> (rfc2461), with a MLD or with a local filter (popular >>>> interpretation). So subsequent to sending that MLD REPORT, or >>>> setting up filtering rule, it can send the MCA-REQ. So we can >>>> trigger the sending of MCA-REQ either by sending the RA, or by >>>> MLD JOIN for all-routers, etc. What do you think about this? >>>> Is this violating anything in 802.16 . What method would you >>>> prefer? >>> >>> Right now, I'm not sure about the usage of 802.16 MCA messages. >>> Actually I thought the MCA differently. You may need to ask an 16 >>> expert the usage of MCA. >> >> David, do you think an IPv6 stack on the BS can ask the 802.16MAC >> to send a MCA-REQ to SS to ask it whether it's interested in >> receiving packets addressed to 33:33:0:0:0:1? > > No. In the case of an IP Packet CS, the IPv6 stack can send a packet > to 33:33:0:0:0:1 down into the IP Packet CS of 802.16 and expect the > packet to be correctly dealt with. What happens next is up to the > CS. It **might** cause the CS to perform an MCS-REQ in an > implementation, but I doubt it. I think then it would make sense form draft to recommend BS to send that MCa-REQ before sending the RA. In this way BS learns who are the SSs interested to receive the RA. If it doesn't break anything. That's what I'm trying to figure out, whether use of MCA-REQ at BS prior to send RA breaks anything. > The IP Packet CS has the responsibility to set up connections that it > can use to deal with the packets it needs to send and receive to > correctly provide the CS MAC service. There are no hard and fast > rules about what those connections are. The CS may set up multiple > connections with different QoS parameter and perform classification > to assign packets to connections. Yes, setting up connections would be done with DSA messages, but I think MCS-REQ/RSP is only to find out who's listening, polling. > If the IP Packet CS thinks it can use a multicast group to better > implement the MAC service, then it can set one up. This would be great. If the BS can deliver RAs only to SSs that are interested in receiving it it would be absolutely great. > However the MAC CPS multicast service is downlink only, so some > thought on the part of the implementer would be required to know to > make this work right. I think that if we can figure out a unitary downlink behaviour then we can see the uplink behaviour. You see, I wouldn't care if a IP-multicasted packet from SS1 to SS2 (group made of only IP SS1 and IP SS2) goes through a MAC-layer downlink multicast group at BS, even if it reaches BS. The essential is that the IP-multicasted packet from SS1 to SS2 doesn't go to SSn which hasn't declared interest in that IP multicast group. > I don’t personally think this has been addressed in any literature I > have read and I don’t myself see how it can work well. The correct > use of unicast connections is much more obvious. > > In the case of the Ethernet Packet CS, ARP happens as per Ethernet > and the Ethernet Packet CS, similarly to the IP Packet CS, could use > multicast group to implement the correct delivery of 802 addressed > packets (that may be uni, broad or multicast). But again it sounds > like more trouble than it is worth to get right. There's a difference between ARP and ND in that ND requires the use of link-layer multicast while ARP less so. I'm not sure whether some _operation_ should be specified, or only some _goals_ should be specified and leave much on Ethernet MAC designers. >>>> As I understand it DSA-REQ/RSP/ACK are for allocating service >>>> flows with a certain QoS, bandwidth request, (table 113 >>>> ieee-2004). This DSA-REQ is for a multicast CID, ok. I >>>> understand DSA-REQ/RSP/ACK are not specifically designed to >>>> indicate intention of belonging to a mc group - which is what >>>> I'm looking for, the equivalent of MLD REPORT. What do you >>>> think? Should I look elsewhere in the spec? >>> >>> Here is another feasible way. I believe this is similar to what >>> you're trying to do: >>> >>> DSA performs 802.16 connection setup as well as the service flow >>> creation. If there is no connection (actually CID) on SS, the SS >>> cannot receive it at 802.16 link layer. When BS creates multicast >>> connection between itself and MSs, DSA transaction is required >>> for each MS. Therefore, BS can manage its multicast group which >>> is associated with 802.16 multicast CID. In other words, MS may >>> join by initiating DSA with appropriate multicast CID. Because, >>> in theory, DSA can be initiated by either BS or MS. Consequently, >>> the multicast can be delivered to intended users only in 802.16 >>> link-layer. >> >> [At which point there would be a need to be able to convert IPv6 >> link-local multicast addresses to multicast CIDs, right? Like >> ff02::1 to 16bit. Or do you think 802.16MAC converts the 33:33::1 >> to a multicast CID?] >> > > DJ – This is the normal CS classification scheme. I.E. assigning > outgoing traffic to CID based on packet contents. But can this work > asymmetrically? The uplink has no multicast CIDs because of the > limitations of the laws of physics. Hence my preference for the > Ethernet CS and GPCS(when it comes). I like what nature imposes and especially how to design around it. It may be that a set of uplink unicast connections can be managed as downlink multicast... and force BS to see all groups packets, and that would be still fine provided that not all SSs see traffic they're not interested in. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 24 15:15:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oWy-0006TD-Px; Wed, 24 Jan 2007 15:15:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9oWx-0006T5-Jk for 16ng@ietf.org; Wed, 24 Jan 2007 15:15:39 -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 1H9oWv-0008GJ-OI for 16ng@ietf.org; Wed, 24 Jan 2007 15:15:39 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0OKDSVt029370; Wed, 24 Jan 2007 22:13:50 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 22:15:19 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jan 2007 14:15:43 -0600 Received: from 172.19.244.91 ([172.19.244.91]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 24 Jan 2007 20:15:44 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 24 Jan 2007 14:17:04 -0600 Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) From: Basavaraj Patil To: ext Alexandru Petrescu Message-ID: Thread-Topic: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) Thread-Index: Acc/9Jzi20ANwavnEduETwARJNUNiA== In-Reply-To: <45B7AA42.7010004@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Jan 2007 20:15:43.0863 (UTC) FILETIME=[6D1E7070:01C73FF4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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 Alex, Why don't you try and implement the I-D first? All I see from you is non-constructive comments. I think the chairs, ADs and the IESG will form their own opinion about the track for this I-D. And since when is it required that a standards track RFC MUST specify "n" number of MUSTS and SHOULDS and MAYS. Other comments inline: On 1/24/07 12:49 PM, "ext Alexandru Petrescu" wrote: > Raj, Jari, thanks for having this exchange public on the mailing list. > > I will precede this mail with a high-level unease I have about > advancement of this draft towards a Standards Track RFC. This can be > solved by several ways, eg change its name into 'Goals for ...' or maybe > change status, or other way one may think of. The draft is definitely > well written, complete in its own and self-contained, a piece of text > worth the effort to submit to IESG. > > Usually a a Standards Track RFC gives clear directions about what should > be implemented. This document doesn't: there's no new message format, > no new message exchange, no new issues with other implementation, 'MUST' > occurs only two times and it's for lifetimes in RA - no new lifetime in > RA suggested, 'SHOULD' appears once to say MTU should be what 2460 > recommends (which is good), 'MAY' never appears. It doesn't offer a > implementer anything special that should be done about running an > existing IPv6 stack over a new kind of link (802.16 IPv6CS in this case, > allow me the term IPv6CS). There is nothing special needed for an implementer other than what is stated in the I-D. > > Section 2 Introduction describes what the IEEE standard describes. It > also describes what WiMax thinks the architecture should be. > > Section 3 Terminology describes a new term 'ASN' which is a WiMax term. > > Sections 4 and 5 are architectural descriptions, from IEEE documents. So whats your point above other than the fact that you have read the document and noted the section numbers and their content? > > One very important part in Section 4, giving indication to which > specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS or > IPv6CS?) is left implementation-dependent (who implements that? how?) - > is there an RA-overIPv6CS enhancement that says use ETHCS vs use IPv6CS. As I said IPv6 can be run over 802.3 (which runs on the EthCS) or directly over the IPv6 CS. The choice depends on the host. The clarification that has been put in is the fact that the network will need to support both. And that is sufficient. > > Section 6 'IPv6 link' makes recommendation about how to configure > things, but nothing to implement. > > Section 6.2 'IPv6 link establishment' which is the 802.16 network-entry > procedure. What should the IPv6 stack implementer write? Nothing. > > Section 6.3 'MTU' says MTU should be what it should be. This is a good > goal, but what to implementer means? I do not see anything in this section that would not be understandable by an IPv6 implementer. > > Section 7 "IPv6 Prefix Assignment" recommends each mobile to be on a > different prefix. This is (1) different than any other IPv6-over-foo > documents (and there are other point-to-point links out there not > recommending this) and (2) a configuration management issue, nothing to > be implemented. > > Section 8 "Router Discovery" is standard behaviour nothing new, nothing > to implement. > > Section 9 "IPv6 addressing for hosts" - nothing new. I could think of > SeND issues with the MS having the same link-local address on all its > 802.16 connections (subnets) but that's all. > > These are the reasons I have that uneases. That said, let me address > the point where I was cited, see below. Point about your uneasiness noted. Can we move on? -Raj > > Basavaraj Patil wrote: >> Hi Jari, >> >> Responses inline: >> >> >> On 1/23/07 1:04 PM, "ext Jari Arkko" wrote: >> >>> Basavaraj, all >>> >>> I reviewed the new version of this spec, and I'm generally quite >>> happy with it. I found three small remaining issues which are >>> listed below: >>>> +-----+ CID1 +-----+ +-----------+ | MS1 >>>> |----------/| BS1 |----------| AR |-----[Internet >>>> >> >> >> >> ] >>>> +-----+ / +-----+ +-----------+ . / >>>> ____________ . CIDn / ()__________() +-----+ / L2 >>>> Tunnel | MSn |-----/ +-----+ >>>> >>>> >>>> Figure 5: The IPv6 AR is separate from the BS, which acts as a >>>> bridge >>>> >>> The part about the BS acting as a bridge seems surprising. Is this >>> really the case? A standard bridge function? >> >> I did'nt mean bridge from the "standard bridge function" definition. >> I will delete it from the document. Basically the BS is an L1/L2 >> entity, but I do not believe I will not to elaborate on that. >> >>>> This section presents a model for the last mile link, i.e. the >>>> link to which MSs attach themselves. >>> I would remove this sentence. You need to explain how the link >>> looks like from an IP perspective. And I think you are doing that. >>> Whether there is a distributed or integrated BS/AR at the other >>> end is really not a key issue. >> >> Okay. Will work on this text as suggested. >> >>>> IEEE 802.16 also defines a secondary management connection that >>>> can be used for host configuration. However support for >>>> secondary management connections is not mandatory. A transport >>>> connection has the advantage of it being used for host >>>> configuration as well as for user data. >>> Are you specifying something about the use of the management >>> connections? If not, take it out. >>> >> >> Not really specifying anything w.r.t the management connection. This >> came up during discussion with Alex Petrescu and I added it just for >> the sake of completeness. Within the scope of this I-D, the >> management connection has no relevance. I can take it out. > > Yes, the issue is that 802.16 recommends the RS/RA to happen on a > Secondary Management Connection (instead of on a Transport Connection). > Clarifications on the list suggested that probably nobody uses a SMC. > But that doesn't mean that the IEEE spec isn't saying so. > > So one could write in the draft that "contrary to the IEEE Spec, this > draft recommends the use of a normal transport connection for an RS/RA". > I would suggest that actually. But there may be other oppinions as well. > > Another thing that was mentioned in the list, and it was agreed by me > and Tim, is that there may be an issue with the indication of how to > auto-configure an address: statelessly or statefully. This indicator > comes from an RA in an IP-only world but in 802.16 it comes from a > link-layer message too. This is an obvious risk for interoperability: > what if the BS says stateless but AR says stateful. In this line of > thought some may remark (from my experience in other WGs) that people > should be capable to configure their networks ok, and these > clarifications shouldn't be specified. But here we talk things to be > done at MAC layer vs at Network layer, and maybe it's not the same > people doing it. > > So I would suggest to at least clarify that IPv6-over-IPv6CS recommends > to ignore that link-layer indicator. But there may be other oppinions > on this topic too. > > Finally, even with all these clarifying remarks I'm making in the inner > body of the mail, I think there is still nothing new to be implemented - > which is good in a good sense, less work :-) > > Alex > > >> >>>> Each MS belongs to a different link. No two MSs belong to the >>>> same link. >>> Duplication. Remove the first sentence. >>> >> >> Okay. Editorial fix. >> >> Will submit a revised version with these changes. >> >> -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 Wed Jan 24 15:50:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9p4N-0006yc-PA; Wed, 24 Jan 2007 15:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9p4F-0006tt-2p; Wed, 24 Jan 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 1H9p4E-00021e-Ix; Wed, 24 Jan 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 75A793296B; Wed, 24 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H9p4E-0008Va-Ax; Wed, 24 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 24 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: 16ng@ietf.org Subject: [16NG] I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-07.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 : IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks Author(s) : B. Patil, et al. Filename : draft-ietf-16ng-ipv6-over-ipv6cs-07.txt Pages : 20 Date : 2007-1-24 IEEE Std 802.16 is an air interface specification. 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. The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv6 packets directly over the MAC. This document specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-07.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-over-ipv6cs-07.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-over-ipv6cs-07.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-1-24132422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-16ng-ipv6-over-ipv6cs-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-24132422.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 Thu Jan 25 02:52:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zOt-0001vh-HK; Thu, 25 Jan 2007 02:52:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9zOr-0001vV-JK for 16ng@ietf.org; Thu, 25 Jan 2007 02:52:01 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9zOq-0002V2-9w for 16ng@ietf.org; Thu, 25 Jan 2007 02:52:01 -0500 Received: by ug-out-1314.google.com with SMTP id 72so344447ugd for <16ng@ietf.org>; Wed, 24 Jan 2007 23:51:59 -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=eduwDtb2g0wVD1ruFSDw5Fojrgv3/ED59sesgRRbbjbT3iSDS3Il3LIYgPGHtqo1LnWYfkWOt9efCTjaZtZcvL2Xpl2QR4kPiXv0bHMWMi1SomRRSkmqFTdJA/cTuXEx3hY9FKstUERu8unc4+A5AuHJ0SsZ5q0yu15VbYHIzAQ= Received: by 10.82.182.8 with SMTP id e8mr757193buf.1169711519160; Wed, 24 Jan 2007 23:51:59 -0800 (PST) Received: by 10.48.217.12 with HTTP; Wed, 24 Jan 2007 23:51:59 -0800 (PST) Message-ID: <92e919fb0701242351x4d1e4b4al5f080c5e0503a376@mail.gmail.com> Date: Thu, 25 Jan 2007 16:51:59 +0900 From: "JinHyeock Choi" To: "Alexandru Petrescu" Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) In-Reply-To: <45B7AA42.7010004@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B7AA42.7010004@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Alex Kindly find my in-line comments. > >>> IEEE 802.16 also defines a secondary management connection that > >>> can be used for host configuration. However support for > >>> secondary management connections is not mandatory. A transport > >>> connection has the advantage of it being used for host > >>> configuration as well as for user data. > >> Are you specifying something about the use of the management > >> connections? If not, take it out. > >> > > > > Not really specifying anything w.r.t the management connection. This > > came up during discussion with Alex Petrescu and I added it just for > > the sake of completeness. Within the scope of this I-D, the > > management connection has no relevance. I can take it out. > > Yes, the issue is that 802.16 recommends the RS/RA to happen on a > Secondary Management Connection (instead of on a Transport Connection). > Clarifications on the list suggested that probably nobody uses a SMC. > But that doesn't mean that the IEEE spec isn't saying so. As of my knowledge, 802.16 doesn't mandate which connection to use for RS/RA. Actually in the beginning of IPv6 over 802.16 IP CS work, we gave much thought on which connection to use for Neighbor Discovery messages such as RS/ RA or NS/ NA. (because those messages can carry multicast destination address and unspecified source address, special features are required for the connection.) Unfortunately 802.16 spec is not perfectly clear about this. While there are a few vague statements which may be interpreted to recommend the Secondary Management Connection, upon discussing with 802.16 & WiMAX people, we found out that neither the statements were written with that intention nor the actual 802.16 SS and BS were implemented that way. Transport Connection (especially Initial Service Flow for WiMAX case) is universally agreed as long as our experience & knowledge goes. If there is something missing or wrong, kindly let me know. 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 Jan 25 11:24:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Oj-0000Sg-F3; Thu, 25 Jan 2007 11:24:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Oi-0000SW-Bh for 16ng@ietf.org; Thu, 25 Jan 2007 11:24:24 -0500 Received: from web60324.mail.yahoo.com ([209.73.178.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA7Oh-0000lf-Kf for 16ng@ietf.org; Thu, 25 Jan 2007 11:24:24 -0500 Received: (qmail 74392 invoked by uid 60001); 25 Jan 2007 16:24:23 -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=6oq+Xm7s8G0iMC3H4wFnc6ur3Oqr+UZRFVYY434Hc/aeSu9TDK+trcf4QMJJZvgfOBO8xrW89me5YepUuZJG7/P2Ibl4ElZjEbRkFsyxW5Nwue3Cz/IW9VpXkSe/cxEmSw1+9uDHo2CvWuCzUROYkfIDkxnDUuhqc3FvQJS/O4o=; X-YMail-OSG: t69.HmsVM1mMrOT5mHyUM1.iw5UvKWSuJgBFOrQXHQMUssVW3razhWjN146B.4P6_qynwXBe69P2pTbyFeLhOzcl6Ox7EZwnMaM20RSVNLJry2jkcwmpFdC8MOkNwg_L9PdrdaBMubWRrBG.AtGc5irOJl6SSl53k3VtzKezPbQdpZ6ANFnhjnPLsMSd.w-- Received: from [12.129.211.52] by web60324.mail.yahoo.com via HTTP; Thu, 25 Jan 2007 08:24:23 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Thu, 25 Jan 2007 08:24:23 -0800 (PST) From: Behcet Sarikaya Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) To: Alexandru Petrescu MIME-Version: 1.0 Message-ID: <276426.73990.qm@web60324.mail.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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="===============0378356019==" Errors-To: 16ng-bounces@ietf.org --===============0378356019== Content-Type: multipart/alternative; boundary="0-547485204-1169742263=:73990" --0-547485204-1169742263=:73990 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,=0A Section 7 mandating unique per-MN prefixes is the main contrib= ution of this document. 3GPP and 3GPP2 also have PtP links and they too man= dated the same. Apart from that, a few clarifications like Jin-Hyeock and R= aj mentioned are important for the implementors.=0A Having said that, I ju= st checked the 3GPP document, RFC 3314, it was published as informational. = Maybe you have a point there :)=0A=0ARegards,=0A=0ABehcet=0A=0A=0A----- Ori= ginal Message ----=0AFrom: Alexandru Petrescu =0ATo: Basavaraj Patil =0ACc: 16ng@ietf.org= =0ASent: Wednesday, January 24, 2007 12:49:38 PM=0ASubject: Re: some though= ts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 ov= er ipcs))=0A=0A=0ARaj, Jari, thanks for having this exchange public on the = mailing list.=0A=0AI will precede this mail with a high-level unease I have= about=0Aadvancement of this draft towards a Standards Track RFC. This can= be=0Asolved by several ways, eg change its name into 'Goals for ...' or ma= ybe=0Achange status, or other way one may think of. The draft is definitel= y=0Awell written, complete in its own and self-contained, a piece of text= =0Aworth the effort to submit to IESG.=0A=0AUsually a a Standards Track RFC= gives clear directions about what should=0Abe implemented. This document = doesn't: there's no new message format,=0Ano new message exchange, no new i= ssues with other implementation, 'MUST'=0Aoccurs only two times and it's fo= r lifetimes in RA - no new lifetime in=0ARA suggested, 'SHOULD' appears onc= e to say MTU should be what 2460=0Arecommends (which is good), 'MAY' never = appears. It doesn't offer a=0Aimplementer anything special that should be = done about running an=0Aexisting IPv6 stack over a new kind of link (802.16= IPv6CS in this case,=0Aallow me the term IPv6CS).=0A=0ASection 2 Introduct= ion describes what the IEEE standard describes. It=0Aalso describes what W= iMax thinks the architecture should be.=0A=0ASection 3 Terminology describe= s a new term 'ASN' which is a WiMax term.=0A=0ASections 4 and 5 are archite= ctural descriptions, from IEEE documents.=0A=0AOne very important part in S= ection 4, giving indication to which=0Aspecific part to use when putting IP= v6 packets on 802.16 MAC (ETHCS or=0AIPv6CS?) is left implementation-depend= ent (who implements that? how?) -=0Ais there an RA-overIPv6CS enhancement = that says use ETHCS vs use IPv6CS.=0A=0ASection 6 'IPv6 link' makes recomme= ndation about how to configure=0Athings, but nothing to implement.=0A=0ASec= tion 6.2 'IPv6 link establishment' which is the 802.16 network-entry=0Aproc= edure. What should the IPv6 stack implementer write?=0A=0ASection 6.3 'MTU= ' says MTU should be what it should be. This is a good=0Agoal, but what to= implementer means?=0A=0ASection 7 "IPv6 Prefix Assignment" recommends each= mobile to be on a=0Adifferent prefix. This is (1) different than any othe= r IPv6-over-foo=0Adocuments (and there are other point-to-point links out t= here not=0Arecommending this) and (2) a configuration management issue, not= hing to=0Abe implemented.=0A=0ASection 8 "Router Discovery" is standard beh= aviour nothing new, nothing=0Ato implement.=0A=0ASection 9 "IPv6 addressing= for hosts" - nothing new. I could think of=0ASeND issues with the MS havi= ng the same link-local address on all its=0A802.16 connections (subnets) bu= t that's all.=0A=0AThese are the reasons I have that uneases. That said, l= et me address=0Athe point where I was cited, see below.=0A=0ABasavaraj Pati= l wrote:=0A> Hi Jari,=0A> =0A> Responses inline:=0A> =0A> =0A> On 1/23/07 1= :04 PM, "ext Jari Arkko" wrote:=0A> =0A>> Basavaraj,= all=0A>> =0A>> I reviewed the new version of this spec, and I'm generally = quite =0A>> happy with it. I found three small remaining issues which are = =0A>> listed below:=0A>>> +-----+ CID1 +-----+ +-----------+ = | MS1 =0A>>> |----------/| BS1 |----------| AR |-----[Internet=0A>>>= =0A> >>=0A> ]=0A>>> +-----+ / +-----+ +-----------+ . = / =0A>>> ____________ . CIDn / ()__________() +-----+ = / L2=0A>>> Tunnel | MSn |-----/ +-----+=0A>>> =0A>>> =0A>>> Figure 5:= The IPv6 AR is separate from the BS, which acts as a =0A>>> bridge=0A>>> = =0A>> The part about the BS acting as a bridge seems surprising. Is this=0A= >> really the case? A standard bridge function?=0A> =0A> I did'nt mean bri= dge from the "standard bridge function" definition.=0A> I will delete it f= rom the document. Basically the BS is an L1/L2 =0A> entity, but I do not be= lieve I will not to elaborate on that.=0A> =0A>>> This section presents a m= odel for the last mile link, i.e. the =0A>>> link to which MSs attach thems= elves.=0A>> I would remove this sentence. You need to explain how the link = =0A>> looks like from an IP perspective. And I think you are doing that.=0A= >> Whether there is a distributed or integrated BS/AR at the other=0A>> en= d is really not a key issue.=0A> =0A> Okay. Will work on this text as sugge= sted.=0A> =0A>>> IEEE 802.16 also defines a secondary management connection= that =0A>>> can be used for host configuration. However support for =0A>>= > secondary management connections is not mandatory. A transport =0A>>> co= nnection has the advantage of it being used for host =0A>>> configuration a= s well as for user data.=0A>> Are you specifying something about the use of= the management =0A>> connections? If not, take it out.=0A>> =0A> =0A> Not = really specifying anything w.r.t the management connection. This=0A> came = up during discussion with Alex Petrescu and I added it just for=0A> the sa= ke of completeness. Within the scope of this I-D, the =0A> management conne= ction has no relevance. I can take it out.=0A=0AYes, the issue is that 802.= 16 recommends the RS/RA to happen on a=0ASecondary Management Connection (i= nstead of on a Transport Connection).=0A Clarifications on the list sugges= ted that probably nobody uses a SMC.=0ABut that doesn't mean that the IEEE = spec isn't saying so.=0A=0ASo one could write in the draft that "contrary = to the IEEE Spec, this=0Adraft recommends the use of a normal transport con= nection for an RS/RA".=0AI would suggest that actually. But there may be o= ther oppinions as well.=0A=0AAnother thing that was mentioned in the list, = and it was agreed by me=0Aand Tim, is that there may be an issue with the i= ndication of how to=0Aauto-configure an address: statelessly or statefully.= This indicator=0Acomes from an RA in an IP-only world but in 802.16 it co= mes from a=0Alink-layer message too. This is an obvious risk for interoper= ability:=0Awhat if the BS says stateless but AR says stateful. In this lin= e of=0Athought some may remark (from my experience in other WGs) that peopl= e=0Ashould be capable to configure their networks ok, and these=0Aclarifica= tions shouldn't be specified. But here we talk things to be=0Adone at MAC = layer vs at Network layer, and maybe it's not the same=0Apeople doing it.= =0A=0ASo I would suggest to at least clarify that IPv6-over-IPv6CS recommen= ds=0Ato ignore that link-layer indicator. But there may be other oppinions= =0Aon this topic too.=0A=0AFinally, even with all these clarifying remarks = I'm making in the inner=0Abody of the mail, I think there is still nothing = new to be implemented -=0Awhich is good in a good sense, less work :-)=0A= =0AAlex=0A=0A=0A> =0A>>> Each MS belongs to a different link. No two MSs b= elong to the =0A>>> same link.=0A>> Duplication. Remove the first sentence.= =0A>> =0A> =0A> Okay. Editorial fix.=0A> =0A> Will submit a revised version= with these changes.=0A> =0A> -Raj=0A> =0A>> Jari=0A>> =0A> =0A> =0A> _____= __________________________________________ 16NG mailing list =0A> 16NG@ietf= .org https://www1.ietf.org/mailman/listinfo/16ng=0A> =0A=0A=0A_____________= __________________________________=0A16NG mailing list=0A16NG@ietf.org=0Aht= tps://www1.ietf.org/mailman/listinfo/16ng --0-547485204-1169742263=:73990 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alex,
=0A
  Section 7 manda= ting unique per-MN prefixes is the main contribution of this document. 3GPP= and 3GPP2 also have PtP links and they too mandated the same. Apart from t= hat, a few clarifications like Jin-Hyeock and Raj mentioned are important f= or the implementors.
=0A
  Having said that, I just chec= ked the 3GPP document, RFC 3314, it was published as informational. Maybe y= ou have a point there :)
=0A
 
=0A
Regards= ,
=0A
 
=0A
Behcet

=0A
----- Original Message ----
From: Alexandru Petrescu <alexandru.pe= trescu@motorola.com>
To: Basavaraj Patil <basavaraj.patil@nokia.co= m>
Cc: 16ng@ietf.org
Sent: Wednesday, January 24, 2007 12:49:38 PM=
Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review = of the new revision (ipv6 over ipcs))

=0A
Raj, Jari, thanks for = having this exchange public on the mailing list.

I will precede this= mail with a high-level unease I have about
advancement of this draft to= wards a Standards Track RFC.  This can be
solved by several wa= ys, eg change its name into 'Goals for ...' or maybe
change status, or o= ther way one may think of.  The draft is definitely
well writt= en, complete in its own and self-contained, a piece of text
worth the ef= fort to submit to IESG.

Usually a a Standards Track RFC gives clear = directions about what should
be implemented.  This document do= esn't: there's no new message format,
no new message exchange, no new is= sues with other implementation, 'MUST'
occurs only two times and it's fo= r lifetimes in RA - no new lifetime in
RA suggested, 'SHOULD' appears on= ce to say MTU should be what 2460
recommends (which is good), 'MAY' neve= r appears.  It doesn't offer a
implementer anything special that should be done about running an
existing IPv6 sta= ck over a new kind of link (802.16 IPv6CS in this case,
allow me the ter= m IPv6CS).

Section 2 Introduction describes what the IEEE standard d= escribes.  It
also describes what WiMax thinks the architectur= e should be.

Section 3 Terminology describes a new term 'ASN' which = is a WiMax term.

Sections 4 and 5 are architectural descriptions, fr= om IEEE documents.

One very important part in Section 4, giving indi= cation to which
specific part to use when putting IPv6 packets on 802.16= MAC (ETHCS or
IPv6CS?) is left implementation-dependent (who implements= that?  how?) -
is there an RA-overIPv6CS enhancement that say= s use ETHCS vs use IPv6CS.

Section 6 'IPv6 link' makes recommendatio= n about how to configure
things, but nothing to implement.

Sectio= n 6.2 'IPv6 link establishment' which is the 802.16 network-entry
procedure.  What should the IPv6 stack implemen= ter write?

Section 6.3 'MTU' says MTU should be what it should be.&n= bsp; This is a good
goal, but what to implementer means?

Sec= tion 7 "IPv6 Prefix Assignment" recommends each mobile to be on a
differ= ent prefix.  This is (1) different than any other IPv6-over-foodocuments (and there are other point-to-point links out there not
reco= mmending this) and (2) a configuration management issue, nothing to
be i= mplemented.

Section 8 "Router Discovery" is standard behaviour nothi= ng new, nothing
to implement.

Section 9 "IPv6 addressing for host= s" - nothing new.  I could think of
SeND issues with the MS ha= ving the same link-local address on all its
802.16 connections (subnets)= but that's all.

These are the reasons I have that uneases. &nb= sp;That said, let me address
the point where I was cited, see below.
=
Basavaraj Patil wrote:
> Hi Jari,
>
> Responses inline:
> <= BR>>
> On 1/23/07 1:04 PM, "ext Jari Arkko" <jari.arkko@piuha.= net> wrote:
>
>> Basavaraj, all
>>
>>= I reviewed the new version of this spec, and I'm generally quite
>&= gt; happy with it. I found three small remaining issues which are
>&= gt; listed below:
>>> +-----+   CID1   = ; +-----+          += -----------+ | MS1
>>> |----------/| BS1 |----------| &nb= sp;   AR    |-----[Internet
>>> <= BR>> <http://tools.ietf.org/html/draft-i= etf-16ng-ipv6-over-ipv6cs-06#ref-Internet>>>
> &nbs= p;]
>>> +-----+        = / +-----+          +------= -----+ .           /
= >>> ____________ .     CIDn /   = ;     ()__________() +-----+   &nbs= p;  / L2
>>>  Tunnel | MSn |-----/ +-----+<= BR>>>>
>>>
>>> Figure 5: The IPv6 AR is = separate from the BS, which acts as a
>>> bridge
>>&g= t;
>> The part about the BS acting as a bridge seems surprising. = Is this
>>  really the case? A standard bridge function?=
>
> I did'nt mean bridge from the "standard bridge function" = definition.
>  I will delete it from the document. Basicall= y the BS is an L1/L2
> entity, but I do not believe I will not to el= aborate on that.
>
>>> This section presents a model for= the last mile link, i.e. the
>>> link to which MSs attach themselves.<= BR>>> I would remove this sentence. You need to explain how the link =
>> looks like from an IP perspective. And I think you are doing t= hat.
>>  Whether there is a distributed or integrated BS= /AR at the other
>> end is really not a key issue.
>
>= ; Okay. Will work on this text as suggested.
>
>>> IEEE = 802.16 also defines a secondary management connection that
>>>= can be used for host configuration.  However support for
>= ;>> secondary management connections is not mandatory.  A t= ransport
>>> connection has the advantage of it being used for= host
>>> configuration as well as for user data.
>> = Are you specifying something about the use of the management
>> c= onnections? If not, take it out.
>>
>
> Not really s= pecifying anything w.r.t the management connection. This
>  came up = during discussion with Alex Petrescu and I added it just for
> &= nbsp;the sake of completeness. Within the scope of this I-D, the
> m= anagement connection has no relevance. I can take it out.

Yes, the i= ssue is that 802.16 recommends the RS/RA to happen on a
Secondary Manage= ment Connection (instead of on a Transport Connection).
  Clar= ifications on the list suggested that probably nobody uses a SMC.
But th= at doesn't mean that the IEEE spec isn't saying so.

So one could&nbs= p; write in the draft that "contrary to the IEEE Spec, this
draft r= ecommends the use of a normal transport connection for an RS/RA".
I woul= d suggest that actually.  But there may be other oppinions as wel= l.

Another thing that was mentioned in the list, and it was agreed b= y me
and Tim, is that there may be an issue with the indication of how to
auto-configure an address: statelessly or statefully.  Thi= s indicator
comes from an RA in an IP-only world but in 802.16 it comes = from a
link-layer message too.  This is an obvious risk for in= teroperability:
what if the BS says stateless but AR says stateful. = ; In this line of
thought some may remark (from my experience in ot= her WGs) that people
should be capable to configure their networks ok, a= nd these
clarifications shouldn't be specified.  But here we t= alk things to be
done at MAC layer vs at Network layer, and maybe it's n= ot the same
people doing it.

So I would suggest to at least clari= fy that IPv6-over-IPv6CS recommends
to ignore that link-layer indicator.=   But there may be other oppinions
on this topic too.

F= inally, even with all these clarifying remarks I'm making in the inner
b= ody of the mail, I think there is still nothing new to be implemented -
= which is good in a good sense, less work :-)

Alex


>
>>>= ; Each MS belongs to a different link.  No two MSs belong to the =
>>> same link.
>> Duplication. Remove the first sente= nce.
>>
>
> Okay. Editorial fix.
>
> Wi= ll submit a revised version with these changes.
>
> -Raj
&g= t;
>> Jari
>>
>
>
> _______________= ________________________________ 16NG mailing list
> 16NG@ietf.org <= A href=3D"https://www1.ietf.org/mailman/listinfo/16ng" target=3D_blank>http= s://www1.ietf.org/mailman/listinfo/16ng
>


___________= ____________________________________
16NG mailing list
16NG@ietf.org<= BR>= https://www1.ietf.org/mailman/listinfo/16ng
=0A
--0-547485204-1169742263=:73990-- --===============0378356019== 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 --===============0378356019==-- From 16ng-bounces@ietf.org Thu Jan 25 12:01:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7yj-0006gR-OA; Thu, 25 Jan 2007 12:01:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7yi-0006gL-D3 for 16ng@ietf.org; Thu, 25 Jan 2007 12:01:36 -0500 Received: from web60319.mail.yahoo.com ([209.73.178.127]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA7yg-0007ZE-KT for 16ng@ietf.org; Thu, 25 Jan 2007 12:01:36 -0500 Received: (qmail 56953 invoked by uid 60001); 25 Jan 2007 17:01:34 -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=h3HXkLerlIJP9KdkTbxfq7uXA9tIs72S5jTHdA2CJDl1MJmR9LC9+CmpexTFsoiV9ePJOolOsPYBRJH2pKx+bSnPs9/Cv6nr82XS6HbIcQVHcesL2gEJ14gkJaPNCFxFpcna0yOFMxrxPBui+91jm47XMQP2xxnJSkuV54RYy6A=; X-YMail-OSG: dyA.bGgVM1n_I2RBvkaR0e1VYHf64OVQNQd8VDm.TDHLq7GeGlI3h66yzPDoDU7KJoESH7_8yKAabEG6UsJLDqAVqKxEF_ZFgJL5.9uPP9yGODSwO9ofAiqDUAm8p9j2MYUFfeuB8YQ_rSd_0QDerDf5.OYkkbFfhUtPdnrAqAv2iHf06IIKsNUcM4diew-- Received: from [12.129.211.52] by web60319.mail.yahoo.com via HTTP; Thu, 25 Jan 2007 09:01:34 PST X-Mailer: YahooMailRC/368.3 YahooMailWebService/0.6.132.7 Date: Thu, 25 Jan 2007 09:01:33 -0800 (PST) From: Behcet Sarikaya Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) To: Alexandru Petrescu MIME-Version: 1.0 Message-ID: <146825.56111.qm@web60319.mail.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 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="===============2022928343==" Errors-To: 16ng-bounces@ietf.org --===============2022928343== Content-Type: multipart/alternative; boundary="0-1772694472-1169744493=:56111" --0-1772694472-1169744493=:56111 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable One additional comment:=0AAn informational standard has a totally different= aim/focus than this document: an informational standard may define an arch= itecture which IETF normally does not or an informational standard may be a= team report on evaluating various choices and recommending the selected on= e. =0A=0AEven if this document is not published as standards track RFC, the= re will be inter operability testing of the mobiles and the network and som= e test cases are going to be derived from this document.=0A=0ALet's do it t= he right way: I favor publication as standards track RFC.=0A=0ARegards,=0A= =0ABehcet=0A=0A=0A----- Original Message ----=0AFrom: Alexandru Petrescu =0ATo: Basavaraj Patil =0ACc: 16ng@ietf.org=0ASent: Wednesday, January 24, 2007 12:49:38 PM= =0ASubject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review o= f the new revision (ipv6 over ipcs))=0A=0A=0ARaj, Jari, thanks for having t= his exchange public on the mailing list.=0A=0AI will precede this mail with= a high-level unease I have about=0Aadvancement of this draft towards a Sta= ndards Track RFC. This can be=0Asolved by several ways, eg change its name= into 'Goals for ...' or maybe=0Achange status, or other way one may think = of. The draft is definitely=0Awell written, complete in its own and self-c= ontained, a piece of text=0Aworth the effort to submit to IESG.=0A=0AUsuall= y a a Standards Track RFC gives clear directions about what should=0Abe imp= lemented. This document doesn't: there's no new message format,=0Ano new m= essage exchange, no new issues with other implementation, 'MUST'=0Aoccurs o= nly two times and it's for lifetimes in RA - no new lifetime in=0ARA sugges= ted, 'SHOULD' appears once to say MTU should be what 2460=0Arecommends (whi= ch is good), 'MAY' never appears. It doesn't offer a=0Aimplementer anythin= g special that should be done about running an=0Aexisting IPv6 stack over a= new kind of link (802.16 IPv6CS in this case,=0Aallow me the term IPv6CS).= =0A=0ASection 2 Introduction describes what the IEEE standard describes. I= t=0Aalso describes what WiMax thinks the architecture should be.=0A=0ASecti= on 3 Terminology describes a new term 'ASN' which is a WiMax term.=0A=0ASec= tions 4 and 5 are architectural descriptions, from IEEE documents.=0A=0AOne= very important part in Section 4, giving indication to which=0Aspecific pa= rt to use when putting IPv6 packets on 802.16 MAC (ETHCS or=0AIPv6CS?) is l= eft implementation-dependent (who implements that? how?) -=0Ais there an R= A-overIPv6CS enhancement that says use ETHCS vs use IPv6CS.=0A=0ASection 6 = 'IPv6 link' makes recommendation about how to configure=0Athings, but nothi= ng to implement.=0A=0ASection 6.2 'IPv6 link establishment' which is the 80= 2.16 network-entry=0Aprocedure. What should the IPv6 stack implementer wri= te?=0A=0ASection 6.3 'MTU' says MTU should be what it should be. This is a= good=0Agoal, but what to implementer means?=0A=0ASection 7 "IPv6 Prefix As= signment" recommends each mobile to be on a=0Adifferent prefix. This is (1= ) different than any other IPv6-over-foo=0Adocuments (and there are other p= oint-to-point links out there not=0Arecommending this) and (2) a configurat= ion management issue, nothing to=0Abe implemented.=0A=0ASection 8 "Router D= iscovery" is standard behaviour nothing new, nothing=0Ato implement.=0A=0AS= ection 9 "IPv6 addressing for hosts" - nothing new. I could think of=0ASeN= D issues with the MS having the same link-local address on all its=0A802.16= connections (subnets) but that's all.=0A=0AThese are the reasons I have th= at uneases. That said, let me address=0Athe point where I was cited, see b= elow.=0A=0ABasavaraj Patil wrote:=0A> Hi Jari,=0A> =0A> Responses inline:= =0A> =0A> =0A> On 1/23/07 1:04 PM, "ext Jari Arkko" = wrote:=0A> =0A>> Basavaraj, all=0A>> =0A>> I reviewed the new version of th= is spec, and I'm generally quite =0A>> happy with it. I found three small r= emaining issues which are =0A>> listed below:=0A>>> +-----+ CID1 +----= -+ +-----------+ | MS1 =0A>>> |----------/| BS1 |----------| A= R |-----[Internet=0A>>> =0A> >>=0A> ]=0A>>> +-----+ / +-----+= +-----------+ . / =0A>>> ____________ . CIDn / = ()__________() +-----+ / L2=0A>>> Tunnel | MSn |-----/ +-----+=0A>= >> =0A>>> =0A>>> Figure 5: The IPv6 AR is separate from the BS, which acts = as a =0A>>> bridge=0A>>> =0A>> The part about the BS acting as a bridge see= ms surprising. Is this=0A>> really the case? A standard bridge function?= =0A> =0A> I did'nt mean bridge from the "standard bridge function" definiti= on.=0A> I will delete it from the document. Basically the BS is an L1/L2 = =0A> entity, but I do not believe I will not to elaborate on that.=0A> =0A>= >> This section presents a model for the last mile link, i.e. the =0A>>> li= nk to which MSs attach themselves.=0A>> I would remove this sentence. You n= eed to explain how the link =0A>> looks like from an IP perspective. And I = think you are doing that.=0A>> Whether there is a distributed or integrate= d BS/AR at the other=0A>> end is really not a key issue.=0A> =0A> Okay. Wil= l work on this text as suggested.=0A> =0A>>> IEEE 802.16 also defines a sec= ondary management connection that =0A>>> can be used for host configuration= . However support for =0A>>> secondary management connections is not manda= tory. A transport =0A>>> connection has the advantage of it being used for= host =0A>>> configuration as well as for user data.=0A>> Are you specifyin= g something about the use of the management =0A>> connections? If not, take= it out.=0A>> =0A> =0A> Not really specifying anything w.r.t the management= connection. This=0A> came up during discussion with Alex Petrescu and I a= dded it just for=0A> the sake of completeness. Within the scope of this I-= D, the =0A> management connection has no relevance. I can take it out.=0A= =0AYes, the issue is that 802.16 recommends the RS/RA to happen on a=0ASeco= ndary Management Connection (instead of on a Transport Connection).=0A Cla= rifications on the list suggested that probably nobody uses a SMC.=0ABut th= at doesn't mean that the IEEE spec isn't saying so.=0A=0ASo one could writ= e in the draft that "contrary to the IEEE Spec, this=0Adraft recommends the= use of a normal transport connection for an RS/RA".=0AI would suggest that= actually. But there may be other oppinions as well.=0A=0AAnother thing th= at was mentioned in the list, and it was agreed by me=0Aand Tim, is that th= ere may be an issue with the indication of how to=0Aauto-configure an addre= ss: statelessly or statefully. This indicator=0Acomes from an RA in an IP-= only world but in 802.16 it comes from a=0Alink-layer message too. This is= an obvious risk for interoperability:=0Awhat if the BS says stateless but = AR says stateful. In this line of=0Athought some may remark (from my exper= ience in other WGs) that people=0Ashould be capable to configure their netw= orks ok, and these=0Aclarifications shouldn't be specified. But here we ta= lk things to be=0Adone at MAC layer vs at Network layer, and maybe it's not= the same=0Apeople doing it.=0A=0ASo I would suggest to at least clarify th= at IPv6-over-IPv6CS recommends=0Ato ignore that link-layer indicator. But = there may be other oppinions=0Aon this topic too.=0A=0AFinally, even with a= ll these clarifying remarks I'm making in the inner=0Abody of the mail, I t= hink there is still nothing new to be implemented -=0Awhich is good in a go= od sense, less work :-)=0A=0AAlex=0A=0A=0A> =0A>>> Each MS belongs to a dif= ferent link. No two MSs belong to the =0A>>> same link.=0A>> Duplication. = Remove the first sentence.=0A>> =0A> =0A> Okay. Editorial fix.=0A> =0A> Wil= l submit a revised version with these changes.=0A> =0A> -Raj=0A> =0A>> Jari= =0A>> =0A> =0A> =0A> _______________________________________________ 16NG m= ailing list =0A> 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng= =0A> =0A=0A=0A_______________________________________________=0A16NG mailin= g list=0A16NG@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/16ng --0-1772694472-1169744493=:56111 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
One additional comment:
=0A
An info= rmational standard has a totally different aim/focus than this document: an= informational standard may define an architecture which IETF normally does= not or an informational standard may be a team report on evaluating variou= s choices and recommending the selected one.
=0A
 =0A
Even if this document is not published as standards track RFC= , there will be inter operability testing of the mobiles and the network an= d some test cases are going to be derived from this document.
=0A
 
=0A
Let's do it the right way: I favor publicatio= n as standards track RFC.
=0A
 
=0A
Regard= s,
=0A
 
=0A
Behcet

=0A
----- Original Message ----
From: Alexandru Petrescu <alexandru.p= etrescu@motorola.com>
To: Basavaraj Patil <basavaraj.patil@nokia.c= om>
Cc: 16ng@ietf.org
Sent: Wednesday, January 24, 2007 12:49:38 P= M
Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review= of the new revision (ipv6 over ipcs))

=0A
Raj, Jari, thanks for= having this exchange public on the mailing list.

I will precede thi= s mail with a high-level unease I have about
advancement of this draft t= owards a Standards Track RFC.  This can be
solved by several w= ays, eg change its name into 'Goals for ...' or maybe
change status, or = other way one may think of.  The draft is definitely
well writ= ten, complete in its own and self-contained, a piece of text
worth the e= ffort to submit to IESG.

Usually a a Standards Track RFC gives clear= directions about what should
be implemented.  This document d= oesn't: there's no new message format,
no new message exchange, no new i= ssues with other implementation, 'MUST'
occurs only two times and it's f= or lifetimes in RA - no new lifetime in
RA suggested, 'SHOULD' appears o= nce to say MTU should be what 2460
recommends (which is good), 'MAY' nev= er appears.  It doesn't offer a
implementer anything special that should be done about running an
existing IPv6 sta= ck over a new kind of link (802.16 IPv6CS in this case,
allow me the ter= m IPv6CS).

Section 2 Introduction describes what the IEEE standard d= escribes.  It
also describes what WiMax thinks the architectur= e should be.

Section 3 Terminology describes a new term 'ASN' which = is a WiMax term.

Sections 4 and 5 are architectural descriptions, fr= om IEEE documents.

One very important part in Section 4, giving indi= cation to which
specific part to use when putting IPv6 packets on 802.16= MAC (ETHCS or
IPv6CS?) is left implementation-dependent (who implements= that?  how?) -
is there an RA-overIPv6CS enhancement that say= s use ETHCS vs use IPv6CS.

Section 6 'IPv6 link' makes recommendatio= n about how to configure
things, but nothing to implement.

Sectio= n 6.2 'IPv6 link establishment' which is the 802.16 network-entry
procedure.  What should the IPv6 stack implemen= ter write?

Section 6.3 'MTU' says MTU should be what it should be.&n= bsp; This is a good
goal, but what to implementer means?

Sec= tion 7 "IPv6 Prefix Assignment" recommends each mobile to be on a
differ= ent prefix.  This is (1) different than any other IPv6-over-foodocuments (and there are other point-to-point links out there not
reco= mmending this) and (2) a configuration management issue, nothing to
be i= mplemented.

Section 8 "Router Discovery" is standard behaviour nothi= ng new, nothing
to implement.

Section 9 "IPv6 addressing for host= s" - nothing new.  I could think of
SeND issues with the MS ha= ving the same link-local address on all its
802.16 connections (subnets)= but that's all.

These are the reasons I have that uneases. &nb= sp;That said, let me address
the point where I was cited, see below.
=
Basavaraj Patil wrote:
> Hi Jari,
>
> Responses inline:
> <= BR>>
> On 1/23/07 1:04 PM, "ext Jari Arkko" <jari.arkko@piuha.= net> wrote:
>
>> Basavaraj, all
>>
>>= I reviewed the new version of this spec, and I'm generally quite
>&= gt; happy with it. I found three small remaining issues which are
>&= gt; listed below:
>>> +-----+   CID1   = ; +-----+          += -----------+ | MS1
>>> |----------/| BS1 |----------| &nb= sp;   AR    |-----[Internet
>>> <= BR>> <http://tools.ietf.org/html/draft-i= etf-16ng-ipv6-over-ipv6cs-06#ref-Internet>>>
> &nbs= p;]
>>> +-----+        = / +-----+          +------= -----+ .           /
= >>> ____________ .     CIDn /   = ;     ()__________() +-----+   &nbs= p;  / L2
>>>  Tunnel | MSn |-----/ +-----+<= BR>>>>
>>>
>>> Figure 5: The IPv6 AR is = separate from the BS, which acts as a
>>> bridge
>>&g= t;
>> The part about the BS acting as a bridge seems surprising. = Is this
>>  really the case? A standard bridge function?=
>
> I did'nt mean bridge from the "standard bridge function" = definition.
>  I will delete it from the document. Basicall= y the BS is an L1/L2
> entity, but I do not believe I will not to el= aborate on that.
>
>>> This section presents a model for= the last mile link, i.e. the
>>> link to which MSs attach themselves.<= BR>>> I would remove this sentence. You need to explain how the link =
>> looks like from an IP perspective. And I think you are doing t= hat.
>>  Whether there is a distributed or integrated BS= /AR at the other
>> end is really not a key issue.
>
>= ; Okay. Will work on this text as suggested.
>
>>> IEEE = 802.16 also defines a secondary management connection that
>>>= can be used for host configuration.  However support for
>= ;>> secondary management connections is not mandatory.  A t= ransport
>>> connection has the advantage of it being used for= host
>>> configuration as well as for user data.
>> = Are you specifying something about the use of the management
>> c= onnections? If not, take it out.
>>
>
> Not really s= pecifying anything w.r.t the management connection. This
>  came up = during discussion with Alex Petrescu and I added it just for
> &= nbsp;the sake of completeness. Within the scope of this I-D, the
> m= anagement connection has no relevance. I can take it out.

Yes, the i= ssue is that 802.16 recommends the RS/RA to happen on a
Secondary Manage= ment Connection (instead of on a Transport Connection).
  Clar= ifications on the list suggested that probably nobody uses a SMC.
But th= at doesn't mean that the IEEE spec isn't saying so.

So one could&nbs= p; write in the draft that "contrary to the IEEE Spec, this
draft r= ecommends the use of a normal transport connection for an RS/RA".
I woul= d suggest that actually.  But there may be other oppinions as wel= l.

Another thing that was mentioned in the list, and it was agreed b= y me
and Tim, is that there may be an issue with the indication of how to
auto-configure an address: statelessly or statefully.  Thi= s indicator
comes from an RA in an IP-only world but in 802.16 it comes = from a
link-layer message too.  This is an obvious risk for in= teroperability:
what if the BS says stateless but AR says stateful. = ; In this line of
thought some may remark (from my experience in ot= her WGs) that people
should be capable to configure their networks ok, a= nd these
clarifications shouldn't be specified.  But here we t= alk things to be
done at MAC layer vs at Network layer, and maybe it's n= ot the same
people doing it.

So I would suggest to at least clari= fy that IPv6-over-IPv6CS recommends
to ignore that link-layer indicator.=   But there may be other oppinions
on this topic too.

F= inally, even with all these clarifying remarks I'm making in the inner
b= ody of the mail, I think there is still nothing new to be implemented -
= which is good in a good sense, less work :-)

Alex


>
>>>= ; Each MS belongs to a different link.  No two MSs belong to the =
>>> same link.
>> Duplication. Remove the first sente= nce.
>>
>
> Okay. Editorial fix.
>
> Wi= ll submit a revised version with these changes.
>
> -Raj
&g= t;
>> Jari
>>
>
>
> _______________= ________________________________ 16NG mailing list
> 16NG@ietf.org <= A href=3D"https://www1.ietf.org/mailman/listinfo/16ng" target=3D_blank>http= s://www1.ietf.org/mailman/listinfo/16ng
>


___________= ____________________________________
16NG mailing list
16NG@ietf.org<= BR>= https://www1.ietf.org/mailman/listinfo/16ng
=0A
--0-1772694472-1169744493=:56111-- --===============2022928343== 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 --===============2022928343==-- From 16ng-bounces@ietf.org Thu Jan 25 12:39:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8ZS-0005N5-BE; Thu, 25 Jan 2007 12:39:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8ZQ-0005N0-Vq for 16ng@ietf.org; Thu, 25 Jan 2007 12:39:32 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA8ZP-0006QS-LO for 16ng@ietf.org; Thu, 25 Jan 2007 12:39:32 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1169746770!1274375!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 12912 invoked from network); 25 Jan 2007 17:39:30 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-15.tower-128.messagelabs.com with SMTP; 25 Jan 2007 17:39:30 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l0PHdU3G028544; Thu, 25 Jan 2007 10:39:30 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0PHdSTZ025706; Thu, 25 Jan 2007 11:39:29 -0600 (CST) Message-ID: <45B8EB50.4070400@motorola.com> Date: Thu, 25 Jan 2007 18:39:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Behcet Sarikaya Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) References: <146825.56111.qm@web60319.mail.yahoo.com> In-Reply-To: <146825.56111.qm@web60319.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Behcet Sarikaya wrote: > One additional comment: An informational standard has a totally > different aim/focus than this document: an informational standard may > define an architecture which IETF normally does not or an > informational standard may be a team report on evaluating various > choices and recommending the selected one. How about EXPERIMENTAL status? > Even if this document is not published as standards track RFC, there > will be inter operability testing of the mobiles and the network and > some test cases are going to be derived from this document. Thanks, that is good to know. > Let's do it the right way: I favor publication as standards track > RFC. Could you please clarify whether you're an author of this document or not, just for the record. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 25 13:27:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9JW-0001WU-7A; Thu, 25 Jan 2007 13:27:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9JU-0001WO-PU for 16ng@ietf.org; Thu, 25 Jan 2007 13:27:08 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA9JT-0007Lb-AH for 16ng@ietf.org; Thu, 25 Jan 2007 13:27:08 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1169749624!577051!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 3280 invoked from network); 25 Jan 2007 18:27:04 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-153.messagelabs.com with SMTP; 25 Jan 2007 18:27:04 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l0PIR4EB020318 for <16ng@ietf.org>; Thu, 25 Jan 2007 11:27:04 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l0PIR39P024481 for <16ng@ietf.org>; Thu, 25 Jan 2007 12:27:04 -0600 (CST) Message-ID: <45B8F676.10801@motorola.com> Date: Thu, 25 Jan 2007 19:27:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: 16ng@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Subject: [16NG] An interpretation of draft-iab-multilink-subnet-issues-02.txt in 16ng context 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 Trying to find out under what conditions this draft recommends the use of a prefix-per-mobile, and see how it applies to 802.16 IPv6CS ptp links. I've purportedly choosen paragraphs that IMHO are relevant to IPv6-over-IPv6CS. If there are others, please point me to them. > Some examples of protocols today that are known to embed some > assumption about the relationship between TTL and subnet prefix are: > > > o Neighbor Discovery (ND) [RFC2461] uses messages with Hop Limit 255 > checked on receipt, to resolve the link-layer address of any IP > address in the subnet. Ok, ND checks Hop Limit to be 255. No prefix-per-mobile recommendation yet. > Some other examples of protocols today that are known to use a TTL 1 > or 255, but do not appear to explicitly have any assumption about > the relationship to subnet prefixes (other than the well-known > link-local prefix) include: > > o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop Limit > of 1. > > o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit of 1. > > Ok, MLD uses hop limit 1. It's different than ND but not an issue, because different protocols (MLD doesn't talk to ND). > It is unknown whether any implementations of such protocols exist > that add such assumptions about the relationship to subnet prefixes > for other reasons. I agree. > The well-known examples of protocols using link-scoped multicast or > broadcast generally fall into one of the following groups: [...] For > example, ND uses link-scoped multicast to resolve the link-layer > address of an IP address in the same subnet prefix, and to do > duplicate address detection (see section 2.4 below) within the > subnet. Nit to draft-iab comments, not relevant in this context, it's in the fe80 prefix, which is not a subnet prefix. [If BSD and/or linux implement fe80 as a subnet prefix then it's a problem, not mine.] > 4. Recommendations: > > It is RECOMMENDED that one of the following two models be used: > > o Multiaccess link model: In this model, there can be multiple nodes > on the same link, including zero or more routers. Data packets sent > to the IPv4 link-local broadcast address (255.255.255.255) or to a > link-local multicast address can be received by all other interested > nodes on the link. Two nodes on the link are able to communicate > without any IPv4 TTL or IPv6 Hop Limit decrement. There can be any > number of layer 2 devices (bridges, switches, access points, > whatever) in the middle of the link. > > o Point-to-point link model: In this model, there are exactly two > nodes on the same link. Data packets sent to the IPv4 link-local > broadcast address or to a link-local multicast address can be > received by the other node on the link. The two nodes are able to > communicate without any IPv4 TTL or IPv6 Hop Limit decrement. There > can be any number of layer 2 devices (bridges, switches, access > points, whatever) in the middle of the link. Ok, we're point-to-point case (for IPv6-overIPv6CS). Text above doesn't cite prefix-per-link. > Loop prevention: If physical loops cannot exist within the subnet, > then removing the TTL/Hop Limit decrement is not an issue. Otherwise, > implementers SHOULD either retain the decrement but use a separate > prefix per link, or else use some form of bridging protocol instead > (e.g., [BRIDGE] or [RBRIDGE]). Physical loops can not exist within the ptp link, so no recommendation to use prefix per link. Do you think there can be physical loops? How? > One of the reasons sometimes cited for wanting a multilink subnet > model (rather than a multi-access link model), is to minimize the > ARP/ND traffic between end-nodes. This is primarily a concern in > IPv4 where ARP results in a broadcast that would be seen by all > nodes, not just the node with the IPv4 address being resolved. Even > if this is a significant concern, the use of a multilink subnet > model is not necessary. The point-to-point link model is one way to > avoid this issue entirely. Ok, this is IPv6 ptp, so use the point-to-point link model. > In the multi-access link model, IPv6 ND traffic can be reduced by > using well-known multicast learning techniques (e.g., [RFC4541] at a > layer 2 intermediate device (bridge, switch, access point, > whatever). > Ok, this is about IPv6-over-IPv6CS, the rfc4541 is for IPv6-over-ETHCS. Besides, if IPv6-over-IPv6CS is about the SS too the above paragraph omits talk about the end node. > Limiting broadcast (including all-hosts multicast): If there is no > efficiency requirement to prevent broadcast from going to other > on-link hosts, then flooding it within the subnet is not an issue. > Otherwise, implementers SHOULD either use a separate prefix per link, > or else flood broadcast other than ARP within the subnet (ARP is > covered below in section 4.3). There is an efficiency requirement, flooding is an issue. So either use prefix-per-link, or flood broadcast other than ARP within subnet. I take that 'other' to be IPv6 multicast. > Limiting the scope of other multicast (including IPv6 Neighbor > Discovery): If there is no efficiency requirement to prevent > multicast from going to other on-link hosts, then flooding multicast > within the subnet is not an issue. Otherwise, implementers SHOULD > either use a separate prefix per link, or else use IGMP/MLD snooping > [RFC4541] instead. Yes, there is an efficiency goal - I think it is a goal in wireless deployments to not wake up SSs under BS that haven't expressed interest in receiving a certain multicast group. So, instead of using prefix-per-link, and instead of using MLD snooping, I think it is possible to use MLD. It is something that I've tried several times to suggest to IPv6-over-IPv6CS to structure the ptp link into something multicast-capable; I gave my thoughts how that would be possible, but I got rejected. So one may need to decide between having multicast-capable ptp links or using prefix-per-mobile with its address waste consequences. It's a take, thanks, Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 25 13:57:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9mh-0004Re-BQ; Thu, 25 Jan 2007 13:57:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9mg-0004RZ-SQ for 16ng@ietf.org; Thu, 25 Jan 2007 13:57:18 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA9mf-0002zh-D7 for 16ng@ietf.org; Thu, 25 Jan 2007 13:57:18 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1169751436!928769!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 24005 invoked from network); 25 Jan 2007 18:57:16 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-11.tower-128.messagelabs.com with SMTP; 25 Jan 2007 18:57:16 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0PIvB6v002749; Thu, 25 Jan 2007 11:57:11 -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 l0PIv9aO002792; Thu, 25 Jan 2007 12:57:10 -0600 (CST) Message-ID: <45B8FD84.9020609@motorola.com> Date: Thu, 25 Jan 2007 19:57:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) 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: a1852b4f554b02e7e4548cc7928acc1f 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 Basavaraj Patil wrote: > Alex, > > Why don't you try and implement the I-D first? All I see from you is > non-constructive comments. I think the chairs, ADs and the IESG will > form their own opinion about the track for this I-D. And since when > is it required that a standards track RFC MUST specify "n" number of > MUSTS and SHOULDS and MAYS. Raj, I gave one opinion and I respect opinion of WG members and decision by WG Chairs and AD. About non-constructive comments: I gave several constructive comments several times (entry procedure enhanced, RA bit, etc), including my support to advance this document to delivery to IESG. What you seem to react to is its status (your remark on n MUSTs). If you wish we can discuss its status. > Other comments inline: > > On 1/24/07 12:49 PM, "ext Alexandru Petrescu" > wrote: > >> Raj, Jari, thanks for having this exchange public on the mailing >> list. >> >> I will precede this mail with a high-level unease I have about >> advancement of this draft towards a Standards Track RFC. This can >> be solved by several ways, eg change its name into 'Goals for ...' >> or maybe change status, or other way one may think of. The draft >> is definitely well written, complete in its own and self-contained, >> a piece of text worth the effort to submit to IESG. >> >> Usually a a Standards Track RFC gives clear directions about what >> should be implemented. This document doesn't: there's no new >> message format, no new message exchange, no new issues with other >> implementation, 'MUST' occurs only two times and it's for lifetimes >> in RA - no new lifetime in RA suggested, 'SHOULD' appears once to >> say MTU should be what 2460 recommends (which is good), 'MAY' never >> appears. It doesn't offer a implementer anything special that >> should be done about running an existing IPv6 stack over a new kind >> of link (802.16 IPv6CS in this case, allow me the term IPv6CS). > > There is nothing special needed for an implementer other than what is > stated in the I-D. > >> Section 2 Introduction describes what the IEEE standard describes. >> It also describes what WiMax thinks the architecture should be. >> >> Section 3 Terminology describes a new term 'ASN' which is a WiMax >> term. >> >> Sections 4 and 5 are architectural descriptions, from IEEE >> documents. > > So whats your point above other than the fact that you have read the > document and noted the section numbers and their content? YEs, one point is to show I've read it. Often I'm asked to read, so I've tried to avoid this recommendation. The second point is that there's nothing to be implemented in these sections. >> One very important part in Section 4, giving indication to which >> specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS >> or IPv6CS?) is left implementation-dependent (who implements that? >> how?) - is there an RA-overIPv6CS enhancement that says use ETHCS >> vs use IPv6CS. > > As I said IPv6 can be run over 802.3 (which runs on the EthCS) or > directly over the IPv6 CS. The choice depends on the host. The > clarification that has been put in is the fact that the network will > need to support both. And that is sufficient. How does the network 'support' both? How does the network switch between the two modes? That is left implementation-dependent. Or this implementation should follow this spec. Constructive comment: the spec could specify a means in an ICMPv6 message enhancement to change between the modes. I suggest one bit only. >> Section 6 'IPv6 link' makes recommendation about how to configure >> things, but nothing to implement. >> >> Section 6.2 'IPv6 link establishment' which is the 802.16 >> network-entry procedure. What should the IPv6 stack implementer >> write? > > Nothing. Ok, so nothing to write about the network entry procedure. Maybe something to configure then. Constructive comment: I suggest IPv6CS to offer configuration parameters to the IPv6 stack, such that the IPv6 stack can enable/disable the use of some features. For example, PANA does auth at IP level, so the IP stack could request disabling of the PKM MAC-layer auth features and message exchanges. This can happen as an extension to the BSD Socket interface. >> Section 6.3 'MTU' says MTU should be what it should be. This is a >> good goal, but what to implementer means? > > I do not see anything in this section that would not be > understandable by an IPv6 implementer. YEs, it is, understandable, complete description, agreed in the WG. The comment is that an IPv6 stack implementer doesn't have to do anything special about MTU to run on IPv6CS. This is good - less work. >> Section 7 "IPv6 Prefix Assignment" recommends each mobile to be on >> a different prefix. This is (1) different than any other >> IPv6-over-foo documents (and there are other point-to-point links >> out there not recommending this) and (2) a configuration management >> issue, nothing to be implemented. >> >> Section 8 "Router Discovery" is standard behaviour nothing new, >> nothing to implement. >> >> Section 9 "IPv6 addressing for hosts" - nothing new. I could think >> of SeND issues with the MS having the same link-local address on >> all its 802.16 connections (subnets) but that's all. >> >> These are the reasons I have that uneases. That said, let me >> address the point where I was cited, see below. > > Point about your uneasiness noted. Can we move on? YEs, thanks about noting my point. Let's move on. Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 25 13:58:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9nM-0004YU-Tv; Thu, 25 Jan 2007 13:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA9nL-0004YO-O4 for 16ng@ietf.org; Thu, 25 Jan 2007 13:57:59 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HA9nK-00033C-CX for 16ng@ietf.org; Thu, 25 Jan 2007 13:57:59 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1169751477!1278771!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11259 invoked from network); 25 Jan 2007 18:57:57 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 25 Jan 2007 18:57:57 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0PIvuIf011284; Thu, 25 Jan 2007 11:57:56 -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 l0PIvslj003205; Thu, 25 Jan 2007 12:57:55 -0600 (CST) Message-ID: <45B8FDB2.3060301@motorola.com> Date: Thu, 25 Jan 2007 19:57:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: JinHyeock Choi References: <45B7AA42.7010004@motorola.com> <92e919fb0701242351x4d1e4b4al5f080c5e0503a376@mail.gmail.com> In-Reply-To: <92e919fb0701242351x4d1e4b4al5f080c5e0503a376@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 16ng@ietf.org Subject: [16NG] Re: some thoughts on IPv6-over-IPv6CS 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 JinHyeock, thanks for your reply. Just one comment, I will not insist on this. JinHyeock Choi wrote: > Dear Alex > > Kindly find my in-line comments. > >>>>> IEEE 802.16 also defines a secondary management connection >>>>> that can be used for host configuration. However support for >>>>> secondary management connections is not mandatory. A >>>>> transport connection has the advantage of it being used for >>>>> host configuration as well as for user data. >>>> Are you specifying something about the use of the management >>>> connections? If not, take it out. >>>> >>> >>> Not really specifying anything w.r.t the management connection. >>> This came up during discussion with Alex Petrescu and I added it >>> just for the sake of completeness. Within the scope of this I-D, >>> the management connection has no relevance. I can take it out. >> >> Yes, the issue is that 802.16 recommends the RS/RA to happen on a >> Secondary Management Connection (instead of on a Transport >> Connection). Clarifications on the list suggested that probably >> nobody uses a SMC. But that doesn't mean that the IEEE spec isn't >> saying so. > > As of my knowledge, 802.16 doesn't mandate which connection to use > for RS/RA. Well I thought that mentioning of sl address autoconf happening on the SMC, check citation below. > Actually in the beginning of IPv6 over 802.16 IP CS work, we gave > much thought on which connection to use for Neighbor Discovery > messages such as RS/ RA or NS/ NA. (because those messages can carry > multicast destination address and unspecified source address, special > features are required for the connection.) What came out of the discussion? > Unfortunately 802.16 spec is not perfectly clear about this. While > there are a few vague statements which may be interpreted to > recommend the Secondary Management Connection, upon discussing with > 802.16 & WiMAX people, we found out that neither the statements were > written with that intention nor the actual 802.16 SS and BS were > implemented that way. Transport Connection (especially Initial > Service Flow for WiMAX case) is universally agreed as long as our > experience & knowledge goes. If there is something missing or wrong, > kindly let me know. Look. Let's ignore WiMax for a very short moment. All we're left with is the 802.16-2005 spec: > IPv6 Stateless Address Autoconfiguration [IETF RFC 2462] based on the > value of a TLV tuple in REG-RSP. Establishment of IP connectivity > shall be performed on the SS’s Secondary Management Connection (see > Table 110). First issue is the use of SMC for RS/RA. The second item is the value in REG-RSP. That value is equivalent to the M-bit in RA. Both issues can be solved directly and solely in the IETF draft, until the IEEE spec is updated. I agree discussion and clarification happened, at least on the list, but its results should be documented. I agree that IEEE 802.16 may be fed back and modified suggestions. I would like that to happen. If that happens then some coherency is gained. Remark we can't put deadlines on IEEE document advancement, so maybe just hold on for a while. Alex > > 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 Jan 25 14:52:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAe6-00015t-4o; Thu, 25 Jan 2007 14:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAAe5-00015j-Gi for 16ng@ietf.org; Thu, 25 Jan 2007 14:52:29 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAAe4-0000uG-73 for 16ng@ietf.org; Thu, 25 Jan 2007 14:52:29 -0500 Received: by ug-out-1314.google.com with SMTP id 72so489907ugd for <16ng@ietf.org>; Thu, 25 Jan 2007 11:52:25 -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=qo4YRIUwAAW9mmG+AnR37Enqi/fl4+S7lP8/Ipm5x3Fid9lZpyAFT11PNLUWSBzXdxoyrvZG4s1PgTzVUTJdE3JA7RD1KyteEV3FBhKb5crCnm3u4v3TBf0C/vzXY8xAq5AUiYIbdEwsXy3iKvXSwzttCVxSv+gYw9evETwiuYI= Received: by 10.82.183.19 with SMTP id g19mr1461992buf.1169754744986; Thu, 25 Jan 2007 11:52:24 -0800 (PST) Received: by 10.49.92.12 with HTTP; Thu, 25 Jan 2007 11:52:24 -0800 (PST) Message-ID: <10e14db20701251152x34a23c39s3172790d1f5a6812@mail.gmail.com> Date: Fri, 26 Jan 2007 01:22:24 +0530 From: "Syam Madanapalli" To: "Alexandru Petrescu" Subject: Re: some thoughts on IPv6-over-IPv6CS (was: [16NG] Re: review of the new revision (ipv6 over ipcs)) In-Reply-To: <45B8FD84.9020609@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B8FD84.9020609@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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, One quick comment inline. [cut] > >> One very important part in Section 4, giving indication to which > >> specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS > >> or IPv6CS?) is left implementation-dependent (who implements that? > >> how?) - is there an RA-overIPv6CS enhancement that says use ETHCS > >> vs use IPv6CS. > > > > As I said IPv6 can be run over 802.3 (which runs on the EthCS) or > > directly over the IPv6 CS. The choice depends on the host. The > > clarification that has been put in is the fact that the network will > > need to support both. And that is sufficient. > > How does the network 'support' both? How does the network switch > between the two modes? That is left implementation-dependent. Or this > implementation should follow this spec. Network supporting both Eth CS and IP Cs is like having two different mechanisms for accessing the network. It is like a router supporting two different PHY interfaces. An IP CS only MS cannot interwork with Eth CS only BS and vice versa.. An MS that has support for both Eth CS and IP CS, and wants switch, it has to do the vertical handoff. > > Constructive comment: the spec could specify a means in an ICMPv6 > message enhancement to change between the modes. I suggest one bit only. > I do not see any need for this. Thanks, Syam _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Thu Jan 25 20:33:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAFy0-0005iN-Tq; Thu, 25 Jan 2007 20:33:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAFxy-0005iH-S3 for 16ng@ietf.org; Thu, 25 Jan 2007 20:33:22 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAFxx-00016o-H3 for 16ng@ietf.org; Thu, 25 Jan 2007 20:33:22 -0500 Received: by nf-out-0910.google.com with SMTP id l36so1027211nfa for <16ng@ietf.org>; Thu, 25 Jan 2007 17:33:20 -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=qRzvZDh2cAtOV7Na/YpiGgiBD0szCeCKZ+uVhDT4hmqNIOtutuuVoJRFZmiC6e7S0nQ5Oh1XleWU9MF6+p0UTwsZJFBwjMePjqbYcEvASbvs/vROPNgNQe9Yb0e4GQbN8ipLfiVom/Fcnud+qKjRcNtAknLfRNq+dpTCbg0M9GM= Received: by 10.48.217.11 with SMTP id p11mr4988394nfg.1169775200544; Thu, 25 Jan 2007 17:33:20 -0800 (PST) Received: by 10.48.217.12 with HTTP; Thu, 25 Jan 2007 17:33:20 -0800 (PST) Message-ID: <92e919fb0701251733j799b47a9gcb1bc8bfefaed16b@mail.gmail.com> Date: Fri, 26 Jan 2007 10:33:20 +0900 From: "JinHyeock Choi" To: "Alexandru Petrescu" In-Reply-To: <45B8FDB2.3060301@motorola.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45B7AA42.7010004@motorola.com> <92e919fb0701242351x4d1e4b4al5f080c5e0503a376@mail.gmail.com> <45B8FDB2.3060301@motorola.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 16ng@ietf.org Subject: [16NG] Re: some thoughts on IPv6-over-IPv6CS 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 thanks for your prompt reply. > Just one comment, I will not insist on this. glad to hear that. :-) > JinHyeock Choi wrote: > > Dear Alex > > > > Kindly find my in-line comments. > > > >>>>> IEEE 802.16 also defines a secondary management connection > >>>>> that can be used for host configuration. However support for > >>>>> secondary management connections is not mandatory. A > >>>>> transport connection has the advantage of it being used for > >>>>> host configuration as well as for user data. > >>>> Are you specifying something about the use of the management > >>>> connections? If not, take it out. > >>>> > >>> > >>> Not really specifying anything w.r.t the management connection. > >>> This came up during discussion with Alex Petrescu and I added it > >>> just for the sake of completeness. Within the scope of this I-D, > >>> the management connection has no relevance. I can take it out. > >> > >> Yes, the issue is that 802.16 recommends the RS/RA to happen on a > >> Secondary Management Connection (instead of on a Transport > >> Connection). Clarifications on the list suggested that probably > >> nobody uses a SMC. But that doesn't mean that the IEEE spec isn't > >> saying so. > > > > As of my knowledge, 802.16 doesn't mandate which connection to use > > for RS/RA. > > Well I thought that mentioning of sl address autoconf happening on the > SMC, check citation below. > > > Actually in the beginning of IPv6 over 802.16 IP CS work, we gave > > much thought on which connection to use for Neighbor Discovery > > messages such as RS/ RA or NS/ NA. (because those messages can carry > > multicast destination address and unspecified source address, > > special features are required for the connection.) > > What came out of the discussion? > > > Unfortunately 802.16 spec is not perfectly clear about this. While > > there are a few vague statements which may be interpreted to > > recommend the Secondary Management Connection, upon discussing with > > 802.16 & WiMAX people, we found out that neither the statements were > > written with that intention nor the actual 802.16 SS and BS were > > implemented that way. Transport Connection (especially Initial > > Service Flow for WiMAX case) is universally agreed as long as our > > experience & knowledge goes. If there is something missing or wrong, > > kindly let me know. > > Look. Let's ignore WiMax for a very short moment. All we're left with > is the 802.16-2005 spec: > > > IPv6 Stateless Address Autoconfiguration [IETF RFC 2462] based on the > > value of a TLV tuple in REG-RSP. Establishment of IP connectivity > > shall be performed on the SS's Secondary Management Connection (see > > Table 110). > > First issue is the use of SMC for RS/RA. > > The second item is the value in REG-RSP. That value is equivalent to > the M-bit in RA. > > Both issues can be solved directly and solely in the IETF draft, until > the IEEE spec is updated. > > I agree discussion and clarification happened, at least on the list, but > its results should be documented. I agree that IEEE 802.16 may be fed > back and modified suggestions. I would like that to happen. If that > happens then some coherency is gained. > > Remark we can't put deadlines on IEEE document advancement, so maybe > just hold on for a while. The above citation may give the impression that SMC is for RS/ RA but doesn't clearly mandate it. I don't think it's productive for us to further debate how to interpret the expression. However, both issues can bring forth some confusion and I guess maybe we'd better give feedback to 802.16 to right them. Best Regards JinHyeock _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Fri Jan 26 11:06:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATb2-0005z6-4i; Fri, 26 Jan 2007 11:06:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATb0-0005ys-MK for 16ng@ietf.org; Fri, 26 Jan 2007 11:06:34 -0500 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATay-0003vz-Dd for 16ng@ietf.org; Fri, 26 Jan 2007 11:06:34 -0500 Received: by an-out-0708.google.com with SMTP id d30so394191and for <16ng@ietf.org>; Fri, 26 Jan 2007 08:06:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hu+RzNuhPYy2xEg2KkmRnFYQH7WUDTVyVYjHM0F8q6t4CfOylOLXy1lLgTqQaAGPCG8E8zOS3JJpkMfZPlHQ2ik83J80Rp+Xq/qKv5h6MtW1nymIXjCvc69c2VCQ4ODJkKkH6S4v+7ityMn4Om+LZbSv59ZTS+GvEgUdOE3iTH0= Received: by 10.114.157.1 with SMTP id f1mr118216wae.1169827591690; Fri, 26 Jan 2007 08:06:31 -0800 (PST) Received: by 10.115.94.12 with HTTP; Fri, 26 Jan 2007 08:06:31 -0800 (PST) Message-ID: Date: Sat, 27 Jan 2007 01:06:31 +0900 From: "Daniel Park" To: 16ng@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [16NG] FW:Internet-Drafts Submission Cutoff Dates for the 68th IETF Meeting in Prague, Czech Republic 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 FYI, ------------------------------------------------------------------------------- There are two (2) Internet-Draft cutoff dates for the 68th IETF Meeting in Prague, Czech Republic: February 26th: Cutoff Date for Initial (i.e., version -00) Internet-Draft Submissions All initial Internet-Drafts (version -00) must be submitted by Monday, February 26th at 9:00 AM ET. As always, all initial submissions with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. The Secretariat would appreciate receiving WG Chair approval by Monday, February 19th at 9:00 AM ET. March 5th: Cutoff Date for Revised (i.e., version -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (version -01 and higher) must be submitted by Monday, March 5th at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced until on or after Monday, March 19th at 9:00 AM ET, when Internet-Draft posting resumes. Please do not wait until the last minute to submit. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 68th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_68.html. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce -- 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 Jan 26 11:08:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATd1-0000Cx-Fj; Fri, 26 Jan 2007 11:08:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATcz-0000Cj-KG for 16ng@ietf.org; Fri, 26 Jan 2007 11:08:37 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATcy-0004Jx-Bl for 16ng@ietf.org; Fri, 26 Jan 2007 11:08:37 -0500 Received: by an-out-0708.google.com with SMTP id d30so394650and for <16ng@ietf.org>; Fri, 26 Jan 2007 08:08:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=GQyekLJKi1qeSUhGHPJQ/cnT3rDsSi2HNEJBrl3v5hxgKwbvx/rdmcRzgBImXa4A3YqDC0ce38zCwRad33+eyflxi5M/V1014bftPs8bTRlJy+gIrqDZulRH9uu0pwLPDbZ6K5Oo9jJtvBT0vBBk1GIfWbB67O6TbSNbSSJACTE= Received: by 10.114.185.8 with SMTP id i8mr120148waf.1169827715558; Fri, 26 Jan 2007 08:08:35 -0800 (PST) Received: by 10.115.94.12 with HTTP; Fri, 26 Jan 2007 08:08:35 -0800 (PST) Message-ID: Date: Sat, 27 Jan 2007 01:08:35 +0900 From: "Daniel Park" To: 16ng@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [16NG] FW:I-D ACTION:draft-iab-link-encaps-08.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 FYI, =============================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Architecture Board Working Group of the IETF. Title : Multiple Encapsulation Methods Considered Harmful Author(s) : B. Aboba Filename : draft-iab-link-encaps-08.txt Pages : 26 Date : 2007-1-25 This document describes architectural and operational issues that arise from link layer protocols supporting multiple Internet Protocol encapsulation methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-link-encaps-08.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-iab-link-encaps-08.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-iab-link-encaps-08.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. -------------------------------------------------------------------------------- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -- 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 Jan 26 11:09:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATdr-0000To-Qe; Fri, 26 Jan 2007 11:09:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATdq-0000TF-Cj for 16ng@ietf.org; Fri, 26 Jan 2007 11:09:30 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HATdp-0004Vb-4D for 16ng@ietf.org; Fri, 26 Jan 2007 11:09:30 -0500 Received: by an-out-0708.google.com with SMTP id d30so394839and for <16ng@ietf.org>; Fri, 26 Jan 2007 08:09:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=MVXno2JhnK+kB895/upK2SOaGoGmQDM+G6LFzEe+E+qqMOlM8nc9TOjaBU1w7fUhxIqQqFwN4X4nYrf0AIV8NnGnCPx6QLU7G0ZT3Md1Q3UESglex4jb/Jhsl0fkzmjQrCMxZ7rnLiISLUhfmVh818DrSNKfbFsuDLz/vpW2KBs= Received: by 10.114.110.1 with SMTP id i1mr30308wac.1169827768437; Fri, 26 Jan 2007 08:09:28 -0800 (PST) Received: by 10.115.94.12 with HTTP; Fri, 26 Jan 2007 08:09:28 -0800 (PST) Message-ID: Date: Sat, 27 Jan 2007 01:09:28 +0900 From: "Daniel Park" To: 16ng@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [16NG] FW:I-D ACTION:draft-iab-multilink-subnet-issues-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 FYI, ========================================= A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Architecture Board Working Group of the IETF. Title : Multilink Subnet Issues Author(s) : D. Thaler Filename : draft-iab-multilink-subnet-issues-03.txt Pages : 0 Date : 2007-1-25 There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iab-multilink-subnet-issues-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-iab-multilink-subnet-issues-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-iab-multilink-subnet-issues-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. -------------------------------------------------------------------------------- _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -- 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 Jan 29 04:23:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSjH-0002Le-5F; Mon, 29 Jan 2007 04:23:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBSjF-0002Hx-UC for 16ng@ietf.org; Mon, 29 Jan 2007 04:23:09 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBSjD-0006GA-5T for 16ng@ietf.org; Mon, 29 Jan 2007 04:23:09 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C428D198772; Mon, 29 Jan 2007 11:23:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 78C51198630; Mon, 29 Jan 2007 11:23:03 +0200 (EET) Message-ID: <45BDBCF8.4030106@piuha.net> Date: Mon, 29 Jan 2007 11:23:04 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandru Petrescu References: <45B7AA42.7010004@motorola.com> In-Reply-To: <45B7AA42.7010004@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: bf422c85703d3d847fb014987125ac48 Cc: 16ng@ietf.org Subject: [16NG] Re: some thoughts on IPv6-over-IPv6CS 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, Let me start by saying that I actually did share a little bit of your unease given that the document has a lot of focus on the configuration and network architecture issues. However, I believe its a feature, not a bug when most of the spec contains statements like "XXX is performed as per RFC NNNN." There is indeed very little new to implement here, because you run IPv6 as it has already been defined, and you run L2 as it has already been defined. That's great! Particularly when a lot of different changes and other ways of running IPv6 over this link have been suggested in the past. Given this background, I think it is also important for the specification to talk about the configuration/architecture issues, because those were the determining factor when we decided that we do not actually need all these new enhancements to run IPv6. Jari Alexandru Petrescu kirjoitti: > Raj, Jari, thanks for having this exchange public on the mailing list. > > I will precede this mail with a high-level unease I have about > advancement of this draft towards a Standards Track RFC. This can be > solved by several ways, eg change its name into 'Goals for ...' or maybe > change status, or other way one may think of. The draft is definitely > well written, complete in its own and self-contained, a piece of text > worth the effort to submit to IESG. > > Usually a a Standards Track RFC gives clear directions about what should > be implemented. This document doesn't: there's no new message format, > no new message exchange, no new issues with other implementation, 'MUST' > occurs only two times and it's for lifetimes in RA - no new lifetime in > RA suggested, 'SHOULD' appears once to say MTU should be what 2460 > recommends (which is good), 'MAY' never appears. It doesn't offer a > implementer anything special that should be done about running an > existing IPv6 stack over a new kind of link (802.16 IPv6CS in this case, > allow me the term IPv6CS). > > Section 2 Introduction describes what the IEEE standard describes. It > also describes what WiMax thinks the architecture should be. > > Section 3 Terminology describes a new term 'ASN' which is a WiMax term. > > Sections 4 and 5 are architectural descriptions, from IEEE documents. > > One very important part in Section 4, giving indication to which > specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS or > IPv6CS?) is left implementation-dependent (who implements that? how?) - > is there an RA-overIPv6CS enhancement that says use ETHCS vs use IPv6CS. > > Section 6 'IPv6 link' makes recommendation about how to configure > things, but nothing to implement. > > Section 6.2 'IPv6 link establishment' which is the 802.16 network-entry > procedure. What should the IPv6 stack implementer write? > > Section 6.3 'MTU' says MTU should be what it should be. This is a good > goal, but what to implementer means? > > Section 7 "IPv6 Prefix Assignment" recommends each mobile to be on a > different prefix. This is (1) different than any other IPv6-over-foo > documents (and there are other point-to-point links out there not > recommending this) and (2) a configuration management issue, nothing to > be implemented. > > Section 8 "Router Discovery" is standard behaviour nothing new, nothing > to implement. > > Section 9 "IPv6 addressing for hosts" - nothing new. I could think of > SeND issues with the MS having the same link-local address on all its > 802.16 connections (subnets) but that's all. > > These are the reasons I have that uneases. That said, let me address > the point where I was cited, see below. > > Basavaraj Patil wrote: >> Hi Jari, >> >> Responses inline: >> >> >> On 1/23/07 1:04 PM, "ext Jari Arkko" wrote: >> >>> Basavaraj, all >>> >>> I reviewed the new version of this spec, and I'm generally quite >>> happy with it. I found three small remaining issues which are listed >>> below: >>>> +-----+ CID1 +-----+ +-----------+ | MS1 >>>> |----------/| BS1 |----------| AR |-----[Internet >>>> >> >> >> >> ] >>>> +-----+ / +-----+ +-----------+ . / >>>> ____________ . CIDn / ()__________() +-----+ / L2 >>>> Tunnel | MSn |-----/ +-----+ >>>> >>>> >>>> Figure 5: The IPv6 AR is separate from the BS, which acts as a bridge >>>> >>> The part about the BS acting as a bridge seems surprising. Is this >>> really the case? A standard bridge function? >> >> I did'nt mean bridge from the "standard bridge function" definition. >> I will delete it from the document. Basically the BS is an L1/L2 >> entity, but I do not believe I will not to elaborate on that. >> >>>> This section presents a model for the last mile link, i.e. the link >>>> to which MSs attach themselves. >>> I would remove this sentence. You need to explain how the link looks >>> like from an IP perspective. And I think you are doing that. >>> Whether there is a distributed or integrated BS/AR at the other >>> end is really not a key issue. >> >> Okay. Will work on this text as suggested. >> >>>> IEEE 802.16 also defines a secondary management connection that can >>>> be used for host configuration. However support for secondary >>>> management connections is not mandatory. A transport connection >>>> has the advantage of it being used for host configuration as well >>>> as for user data. >>> Are you specifying something about the use of the management >>> connections? If not, take it out. >>> >> >> Not really specifying anything w.r.t the management connection. This >> came up during discussion with Alex Petrescu and I added it just for >> the sake of completeness. Within the scope of this I-D, the >> management connection has no relevance. I can take it out. > > Yes, the issue is that 802.16 recommends the RS/RA to happen on a > Secondary Management Connection (instead of on a Transport Connection). > Clarifications on the list suggested that probably nobody uses a SMC. > But that doesn't mean that the IEEE spec isn't saying so. > > So one could write in the draft that "contrary to the IEEE Spec, this > draft recommends the use of a normal transport connection for an RS/RA". > I would suggest that actually. But there may be other oppinions as well. > > Another thing that was mentioned in the list, and it was agreed by me > and Tim, is that there may be an issue with the indication of how to > auto-configure an address: statelessly or statefully. This indicator > comes from an RA in an IP-only world but in 802.16 it comes from a > link-layer message too. This is an obvious risk for interoperability: > what if the BS says stateless but AR says stateful. In this line of > thought some may remark (from my experience in other WGs) that people > should be capable to configure their networks ok, and these > clarifications shouldn't be specified. But here we talk things to be > done at MAC layer vs at Network layer, and maybe it's not the same > people doing it. > > So I would suggest to at least clarify that IPv6-over-IPv6CS recommends > to ignore that link-layer indicator. But there may be other oppinions > on this topic too. > > Finally, even with all these clarifying remarks I'm making in the inner > body of the mail, I think there is still nothing new to be implemented - > which is good in a good sense, less work :-) > > Alex > > >> >>>> Each MS belongs to a different link. No two MSs belong to the same >>>> link. >>> Duplication. Remove the first sentence. >>> >> >> Okay. Editorial fix. >> >> Will submit a revised version with these changes. >> >> -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 Jan 29 05:23:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTfe-00008a-PS; Mon, 29 Jan 2007 05:23:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBTfc-000084-Jm for 16ng@ietf.org; Mon, 29 Jan 2007 05:23:28 -0500 Received: from web81906.mail.mud.yahoo.com ([68.142.207.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBTfY-0007cP-2K for 16ng@ietf.org; Mon, 29 Jan 2007 05:23:28 -0500 Received: (qmail 63365 invoked by uid 60001); 29 Jan 2007 10:23:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=OLYLZoaUaGKNdLgIcx7Hv1vDZ/gXx/OAGn5EV+EOPh6Y+jDunVs6WPb6A0b0muhnFozcCH1I9exvBspCKOaNpXJqj3garBkUzjEv7GD72DDT9lIp8AfiyWIEYDGPYDStg+ksEvzo3rJSQS/WDR7VTu/XhXWG298yQV40EXdTEbY= ; Message-ID: <20070129102323.63363.qmail@web81906.mail.mud.yahoo.com> Received: from [24.16.90.95] by web81906.mail.mud.yahoo.com via HTTP; Mon, 29 Jan 2007 02:23:23 PST Date: Mon, 29 Jan 2007 02:23:23 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 To: Junghoon Jee , Daniel Park , 16ng@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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="===============0751164022==" Errors-To: 16ng-bounces@ietf.org --===============0751164022== Content-Type: multipart/alternative; boundary="0-1954328249-1170066203=:57741" --0-1954328249-1170066203=:57741 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Any idea when the new version will be available?=0A=0Athanks,=0A=0A-gabriel= =0A=0A----- Original Message ----=0AFrom: Junghoon Jee = =0ATo: Daniel Park ; 16ng@ietf.org=0ASent: Tuesda= y, December 26, 2006 11:12:20 PM=0ASubject: [16NG] RE: WG Decision: WGLC : = draft-ietf-16ng-ps-goals-00=0A=0ADaniel,=0ASorry for the delay.=0AThe updat= ed PS I-D will be available soon along with the related=0Adiscussion if nec= essary.=0A=0AJunghoon =0A=0A> -----Original Message-----=0A> From: Daniel P= ark [mailto:soohong.park@samsung.com] =0A> Sent: Wednesday, December 27, 20= 06 1:58 PM=0A> To: 16ng@ietf.org=0A> Cc: ???=0A> Subject: WG Decision: WGLC= : draft-ietf-16ng-ps-goals-00=0A> =0A> =0A> Folks, =0A> =0A> The WGLC expi= red long time ago, but WG does not think it is =0A> passed successfully. In= order words, the authors need more =0A> works on the revision to increase = the quality of this =0A> document. Once updating it including two experts r= eview (DJ =0A> and Phil) as well as a new set of terms. We will solicit one= =0A> more short WGLC to be ready for the IESG at that time. =0A> =0A> Jung= hoon, please update it as soon as possible, then submit =0A> it to the IETF= secretariate. =0A> =0A> Thanks, =0A> =0A> Daniel (Soohong Daniel Park)=0A>= Mobile Convergence Laboratory, SAMSUNG Electronics.=0A> =0A> ----- Origina= l Message -----=0A> From: "Soohong Daniel Park" =0A> To= : <16ng@eeca16.sogang.ac.kr>=0A> Sent: Tuesday, October 17, 2006 9:19 AM=0A= > Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00=0A> =0A> =0A> > Folks,= =0A> > =0A> > This is a two week WGLC on draft-ietf-16ng-ps-goals-00.=0A> >= =0A> > Please review the I-D and submit your comments to the authors or=0A= to=0A> > the list directly. The WGLC will exipre on October 31 =0A> (Pacifi= c Time).=0A> > =0A> > o I-D: =0A> http://www.ietf.org/internet-drafts/draft= -ietf-16ng-ps-goals-00.txt=0A> > =0A> > o Intended publication: Information= al RFC=0A> > =0A> > =0A> > -- =0A> > =0A> > =0A> > Daniel (Soohong Daniel P= ark)=0A> > Mobile Convergence Laboratory, SAMSUNG Electronics.=0A> > ______= _________________________________________=0A> > 16ng mailing list=0A> > 16n= g@eeca16.sogang.ac.kr=0A> > http://eeca16.sogang.ac.kr/mailman/listinfo/16n= g=0A> > =0A> >=0A=0A=0A_______________________________________________=0A16= NG mailing list=0A16NG@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/16= ng=0A=0A=0A=0A=0A --0-1954328249-1170066203=:57741 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Any idea when the new version will be available?
<= br>thanks,

-gabriel

----- Original Message ----
Fr= om: Junghoon Jee <jhjee@etri.re.kr>
To: Daniel Park <soohong.pa= rk@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 b= e available soon along with the related
discussion if necessary.

= Junghoon

> -----Original Message-----
> From: Daniel Park = [mailto:soohong.park@samsung.com]
> Sent: Wednesday, December 27, 20= 06 1:58 PM
> To: 16ng@ietf.org
> Cc: ???
> Subject: WG Decision: WGLC : dra= ft-ietf-16ng-ps-goals-00
>
>
> Folks,
>
>= The WGLC expired long time ago, but WG does not think it is
> passe= d 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.
>
&= gt; Thanks,
>
> Daniel (Soohong Daniel Park)
> Mobile C= onvergence Laboratory, SAMSUNG Electronics.
>
> ----- Original= Message -----
> From: "Soohong Daniel Park" <soohongp@gmail.com&g= t;
> To: <16ng@eeca16.sogang.ac.kr>
> Sent: Tuesday, Octo= ber 17, 2006 9:19 AM
> Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00
>=
>
> > Folks,
> >
> > This is a two wee= k WGLC on draft-ietf-16ng-ps-goals-00.
> >
> > Please re= view the I-D and submit your comments to the authors or
to
> > = the list directly. The WGLC will exipre on October 31
> (Pacific Tim= e).
> >
> > o I-D:
> http:= //www.ietf.org/internet-drafts/draft-ietf-16ng-ps-goals-00.txt
> = >
> > o Intended publication: Informational RFC
> > <= br>> >
> > --
> >
> >
> > Dan= iel (Soohong Daniel Park)
> > Mobile Convergence Laboratory, SAMSU= NG Electronics.
> > ______________________________________________= _
> > 16ng mailing list
> > 16ng@eeca16.sogang.ac.kr
&= gt; > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> >
>= ; >


_______________________________________________
16NG m= ailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng<= /a>

--0-1954328249-1170066203=:57741-- --===============0751164022== 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 --===============0751164022==-- From 16ng-bounces@ietf.org Mon Jan 29 06:16:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUV3-0006N3-6t; Mon, 29 Jan 2007 06:16:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBUV2-0006Mr-43 for 16ng@ietf.org; Mon, 29 Jan 2007 06:16:36 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBUV0-0008Aw-Ef for 16ng@ietf.org; Mon, 29 Jan 2007 06:16:36 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1170069393!12068510!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 26046 invoked from network); 29 Jan 2007 11:16:33 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-6.tower-128.messagelabs.com with SMTP; 29 Jan 2007 11:16:33 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l0TBGWIP026213; Mon, 29 Jan 2007 05:16:32 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l0TBGUru027481; Mon, 29 Jan 2007 05:16:31 -0600 (CST) Message-ID: <45BDD78C.9000703@motorola.com> Date: Mon, 29 Jan 2007 12:16:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko References: <45B7AA42.7010004@motorola.com> <45BDBCF8.4030106@piuha.net> In-Reply-To: <45BDBCF8.4030106@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: 16ng@ietf.org Subject: [16NG] Re: some thoughts on IPv6-over-IPv6CS 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 is indeed a needed feature to have statements "XXX is performed as per RFC NNNN". There is value in that and it establishes a basis for communication. That is needed. The Charter puts the document on Standards Track. I hope that direction is taken with an eye on the fact that not all IETF's IPv6-over-foo documents are Standards Track (optionally see rfc4392 and rfc3572). IMHO an IPv6-over-foo document to be on Standards Track would be good to have at least one _new_ recommendation, something like "IID is derived from a non-48bit id, in this way". Other example would be conversion from multicast address to multicast CID, or conversion of IPv6 Traffic Class to a 802.16 Service Class, or something similar. Or an IPv6-oriented network-entry procedure (not a link-layer network entry procedure). Or maybe a IANA action. But please take this as just some thoughts on the document, not necessarily as a disagreement. Again the document looks good, it is needed and I can live with it ok. It is possible that later work can enhance the basic features in this document. Alex Jari Arkko wrote: > Alex, > > Let me start by saying that I actually did share a little bit of your > unease given that the document has a lot of focus on the > configuration and network architecture issues. However, I believe its > a feature, not a bug when most of the spec contains statements like > "XXX is performed as per RFC NNNN." There is indeed very little new > to implement here, because you run IPv6 as it has already been > defined, and you run L2 as it has already been defined. That's great! > Particularly when a lot of different changes and other ways of > running IPv6 over this link have been suggested in the past. Given > this background, I think it is also important for the specification > to talk about the configuration/architecture issues, because those > were the determining factor when we decided that we do not actually > need all these new enhancements to run IPv6. A few examples: rfc4392 IP over InfiniBand, an Informational RFC describes some architecture. rfc3572, IPv6 over MAPOS, Informational, does describe new things to be implemented, when deriving the IID from the HDLC address. RFC3831 IPv6 over Fibre Channel, Stds Track, has at least one new thing that needs to be implemented in an IPv6 stack: derive IID from Nx_Port_Name. rfc3146m IPv6 over IEEE1394, StdsTrack, proposes at least new IANA allocations and SLLAO/TLLAO encodings. Alex > > Jari > > Alexandru Petrescu kirjoitti: >> Raj, Jari, thanks for having this exchange public on the mailing >> list. >> >> I will precede this mail with a high-level unease I have about >> advancement of this draft towards a Standards Track RFC. This can >> be solved by several ways, eg change its name into 'Goals for ...' >> or maybe change status, or other way one may think of. The draft >> is definitely well written, complete in its own and self-contained, >> a piece of text worth the effort to submit to IESG. >> >> >> >> Usually a a Standards Track RFC gives clear directions about what >> should be implemented. This document doesn't: there's no new >> message format, no new message exchange, no new issues with other >> implementation, 'MUST' occurs only two times and it's for lifetimes >> in RA - no new lifetime in RA suggested, 'SHOULD' appears once to >> say MTU should be what 2460 recommends (which is good), 'MAY' never >> appears. It doesn't offer a implementer anything special that >> should be done about running an existing IPv6 stack over a new kind >> of link (802.16 IPv6CS in this case, allow me the term IPv6CS). >> >> Section 2 Introduction describes what the IEEE standard describes. >> It also describes what WiMax thinks the architecture should be. >> >> Section 3 Terminology describes a new term 'ASN' which is a WiMax >> term. >> >> Sections 4 and 5 are architectural descriptions, from IEEE >> documents. >> >> One very important part in Section 4, giving indication to which >> specific part to use when putting IPv6 packets on 802.16 MAC (ETHCS >> or IPv6CS?) is left implementation-dependent (who implements that? >> how?) - is there an RA-overIPv6CS enhancement that says use ETHCS >> vs use IPv6CS. >> >> Section 6 'IPv6 link' makes recommendation about how to configure >> things, but nothing to implement. >> >> Section 6.2 'IPv6 link establishment' which is the 802.16 >> network-entry procedure. What should the IPv6 stack implementer >> write? >> >> Section 6.3 'MTU' says MTU should be what it should be. This is a >> good goal, but what to implementer means? >> >> Section 7 "IPv6 Prefix Assignment" recommends each mobile to be on >> a different prefix. This is (1) different than any other >> IPv6-over-foo documents (and there are other point-to-point links >> out there not recommending this) and (2) a configuration management >> issue, nothing to be implemented. >> >> Section 8 "Router Discovery" is standard behaviour nothing new, >> nothing to implement. >> >> Section 9 "IPv6 addressing for hosts" - nothing new. I could think >> of SeND issues with the MS having the same link-local address on >> all its 802.16 connections (subnets) but that's all. >> >> These are the reasons I have that uneases. That said, let me >> address the point where I was cited, see below. >> >> Basavaraj Patil wrote: >>> Hi Jari, >>> >>> Responses inline: >>> >>> >>> On 1/23/07 1:04 PM, "ext Jari Arkko" >>> wrote: >>> >>>> Basavaraj, all >>>> >>>> I reviewed the new version of this spec, and I'm generally >>>> quite happy with it. I found three small remaining issues which >>>> are listed below: >>>>> +-----+ CID1 +-----+ +-----------+ | MS1 >>>>> |----------/| BS1 |----------| AR |-----[Internet >>>>> >>> >> >>> >>> >>> >>> >>> >>> >>> >>> ] >>>>> +-----+ / +-----+ +-----------+ . / >>>>> ____________ . CIDn / ()__________() +-----+ / L2 >>>>> Tunnel | MSn |-----/ +-----+ >>>>> >>>>> >>>>> Figure 5: The IPv6 AR is separate from the BS, which acts as >>>>> a bridge >>>>> >>>> The part about the BS acting as a bridge seems surprising. Is >>>> this really the case? A standard bridge function? >>> I did'nt mean bridge from the "standard bridge function" >>> definition. I will delete it from the document. Basically the BS >>> is an L1/L2 entity, but I do not believe I will not to elaborate >>> on that. >>> >>>>> This section presents a model for the last mile link, i.e. >>>>> the link to which MSs attach themselves. >>>> I would remove this sentence. You need to explain how the link >>>> looks like from an IP perspective. And I think you are doing >>>> that. Whether there is a distributed or integrated BS/AR at the >>>> other end is really not a key issue. >>> Okay. Will work on this text as suggested. >>> >>>>> IEEE 802.16 also defines a secondary management connection >>>>> that can be used for host configuration. However support for >>>>> secondary management connections is not mandatory. A >>>>> transport connection has the advantage of it being used for >>>>> host configuration as well as for user data. >>>> Are you specifying something about the use of the management >>>> connections? If not, take it out. >>>> >>> Not really specifying anything w.r.t the management connection. >>> This came up during discussion with Alex Petrescu and I added it >>> just for the sake of completeness. Within the scope of this I-D, >>> the management connection has no relevance. I can take it out. >> Yes, the issue is that 802.16 recommends the RS/RA to happen on a >> Secondary Management Connection (instead of on a Transport >> Connection). Clarifications on the list suggested that probably >> nobody uses a SMC. But that doesn't mean that the IEEE spec isn't >> saying so. >> >> So one could write in the draft that "contrary to the IEEE Spec, >> this draft recommends the use of a normal transport connection for >> an RS/RA". I would suggest that actually. But there may be other >> oppinions as well. >> >> Another thing that was mentioned in the list, and it was agreed by >> me and Tim, is that there may be an issue with the indication of >> how to auto-configure an address: statelessly or statefully. This >> indicator comes from an RA in an IP-only world but in 802.16 it >> comes from a link-layer message too. This is an obvious risk for >> interoperability: what if the BS says stateless but AR says >> stateful. In this line of thought some may remark (from my >> experience in other WGs) that people should be capable to configure >> their networks ok, and these clarifications shouldn't be >> specified. But here we talk things to be done at MAC layer vs at >> Network layer, and maybe it's not the same people doing it. >> >> So I would suggest to at least clarify that IPv6-over-IPv6CS >> recommends to ignore that link-layer indicator. But there may be >> other oppinions on this topic too. >> >> Finally, even with all these clarifying remarks I'm making in the >> inner body of the mail, I think there is still nothing new to be >> implemented - which is good in a good sense, less work :-) >> >> Alex >> >> >>>>> Each MS belongs to a different link. No two MSs belong to >>>>> the same link. >>>> Duplication. Remove the first sentence. >>>> >>> Okay. Editorial fix. >>> >>> Will submit a revised version with these changes. >>> >>> -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 Jan 29 08:56:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWzJ-0001rk-Bs; Mon, 29 Jan 2007 08:56:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWzH-0001rc-7e for 16ng@ietf.org; Mon, 29 Jan 2007 08:55:59 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBWzE-0006RN-Nn for 16ng@ietf.org; Mon, 29 Jan 2007 08:55:59 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 48915198775; Mon, 29 Jan 2007 15:55:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 02C5D198630; Mon, 29 Jan 2007 15:55:52 +0200 (EET) Message-ID: <45BDFCE9.2050804@piuha.net> Date: Mon, 29 Jan 2007 15:55:53 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Syam Madanapalli 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: 4b800b1eab964a31702fa68f1ff0e955 Cc: 16ng@ietf.org Subject: [16NG] AD review of draft-ietf-16ng-ipv6-link-model 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, I have reviewed this document again. Please see a few comments below: > 3.1. Shared IPv6 Prefix Link Model This section should start with a definition of the model. > 3.1.4.5. Changes to Host Implementation > > This link model requires no other implementation changes except that > the hosts are required to perform duplicate address detection for all > addresses even if the host is reusing the interface identifier. Is this a remnant from an earlier revision? If you employ MLD snooping as opposed to looking at NAs, it would appear that the above is not true. > 802.16 [1] [2] is a connection oriented access technology for the > last mile without bi-directional native multicast support. 802.16 has > only downlink multicast support and there is no mechanisms defined > for mobile stations to be able to send multicast packets that can be > mapped to downlink multicast connection. This could be a problem for > IP protocols (e.g. ARP, IPv6 ND) that traditionally assume the > availability of multicast at the link layer. This statement may need to be revised according to DJ's recent comments on the list. > 3. If neither PPP nor VLAN is used, the set of 802.16 connections > can be viewed as a virtual point-to-point link for the purpose of > neighbor discovery and address configuration. For IPv6 CS, this > may be used to implement the point-to-point link. The key issue is not what you do with ND, but rather what the scope of the link local multicast is; that determines what happens to RAs, NAs, etc. > When the p2p link model is used, the BS acts as a bridge. For each > MS, the BS bridges the unique prefix or set of prefixes assigned by > the AR to the link between itself and the MS. This means, in > particular, that the per MS prefix or set of prefixes are routed on > both sides (wireless and wired) of the BS, and that the BS needs to > participate in all 802 standard bridging protocols. The expression "routed on both sides" may not be appropriate here. The BS is not a router. Question: why is it that the BS needs to participate in all bridging protocols? From the perspective of the MS it shouldn't even see the existence of a tunnel behind the BS. > One way to construct an Ethernet like link is to implement bridging > [13] between BSs and AR like switched Ethernet. In the Figure 4, > bridging performs link aggregation between BSs and AR. Bridging also > supports multicast packet filtering. Another way to implement this > model is by using VLAN function [11]. I do not understand how VLANs relate to this. Please explain or remove. > In this model, an IPv6 prefix is shared by multiple MSs on top of > IEEE 802.16 point-to-multipoint links. Also this model supports > multiple access routers and multiple hosts behind an MS as shown in > Figure 4. Yes, but a question: should this be taken as a claim that the other models do not support multiple hosts? The document does not say anything about this. > conjunction with IP convergence sublyaer with IPv6 classifiers. Typo. Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 29 08:57:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX12-0002LA-2F; Mon, 29 Jan 2007 08:57:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBX10-0002L4-5D for 16ng@ietf.org; Mon, 29 Jan 2007 08:57:46 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBX0z-0006il-EV for 16ng@ietf.org; Mon, 29 Jan 2007 08:57:46 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9A276198775; Mon, 29 Jan 2007 15:57:44 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3D62B198630; Mon, 29 Jan 2007 15:57:44 +0200 (EET) Message-ID: <45BDFD58.8060202@piuha.net> Date: Mon, 29 Jan 2007 15:57:44 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Basavaraj Patil , 16ng@ietf.org 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: 8b6657e60309a1317174c9db2ae5f227 Cc: Pekka Savola Subject: [16NG] FW: 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 all, I asked Pekka Savola to review this specification, which he did -- thank you! You will find his comments below. Please send any responses or text updates with respect to his points to the list. Jari (Sorry for the duplicates, I forgot to copy the list when sending this.) ----- The editorial clarity could have been somewhat better. It is not obvious whether the scenarios where "MS" is a fixed station and/or a router has been adequately considered or whether this is an editorial issue. 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? There seem to be some technical problems (e.g., GRE tunnel multiplexing, different MTU recommendation) with Appendices and an issue of clarity why the appendices are there to begin with. It is not clear if traffic classification is adequately specified (or is it specified elsewhere?) and some miscellaneous issues. substantial ----------- ==> looking at the other "IPv6 over foo" documents, this document doesn't specify or mention the following: - link-local address generation (exactly as described in RFC2464, I suppose?) - unicast and multicast address mapping Maybe these don't require much text but an explicit note might be a good thing to have. ... The packet CS defines a set of classifiers that are used to determine how to handle the packet. The IP classifiers that are used at the MAC operate on the fields of the IP header and the transport protocol and these include the IP Traffic class, Next header field, Masked IP source and destination addresses and, Protocol source and destination port ranges. ==> this is probably defined better in 802.16, but not all traffic may have a traffic class (v4 has DSCP which is similar), you don't define what is "masked {dst,src} address" (just some kind of prefix part of an address?), and there may not necessarily be any port ranges involved (non-TCP/UDP protocols). Is more precise specification of this required to create interoperable implementations? Is it a problem if different hosts make different classifications for the same kind of traffic? Hence the point-to-point link model for IPv6 operation over the IP specific part of the Packet CS in 802.16 is recommended. A unique IPv6 prefix(es) per link (MS) is also recommended. ==> you don't discuss what will happen if these recommendations are not followed, in fact, the whole document assumes they are adhered to. Either this should be discussed or the recommendations should be made stronger (requirements). 6.3. Maximum transmission unit in 802.16 [...] The Max value of the IPv6 MTU for 802.16 is 2038 bytes and the minimum value of 1280 bytes. The default MTU for IPv6 over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 octets. RFC2461 defines an MTU option that an AR can advertise to an MN. If an AR advertises an MTU via the RA MTU option, the MN should use the MTU from the RA. ==> Should the last sentence use uppercase keywords? ==> 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. 8.1. Router Solicitation [...] Movement detection at the IP layer of an MS in many cases is based on receiving periodic router advertisements. ==> yet, in 8.3 you make the period much longer, to be counted in hours. That's not useful for movement detection, text above should probably be adjusted. 8.3. Router lifetime and periodic router advertisements ==> it is not clear if the implications of the design decision to raise the default advertisement intervals has been adequately understood. Will this mean that every single instance of protocols which use too low intervals will need to be modified? How do you deal with periodic MLD reports, for example? 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? The granularity of the GRE tunnel should be on a per MS basis or on a per service flow basis (an MS can have multiple service flows, each of which are identified uniquely by a service flow ID). ==> So, it's possible to have multiple GRE tunnels between AR and BS. Yet, I do not see how different GRE tunnels are multiplexed/demultiplexed. GRE header does not support this AFAICS -- you'd need to use different source/destination IP address pairs, or encode different flows as different 'Protocol type' values (16 bits), but the latter would require modifications to GRE processing code at both endpoints of the tunnel. Therefore I'm not sure if this approach is workable. Appendix D. Maximum transmission unit in WiMAX The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. Hence the IPv6 path MTU can be 1500 octets. However because of the overhead of the GRE tunnel used to transport IPv6 packets between the BS and AR and the 6 byte MAC header over the air interface, using a value of 1500 would result in fragmentation of packets. It is recommended that the default MTU for IPv6 be set to 1400 octets for the MS in WiMAX networks. Note that the 1522 octet specification is a WiMAX forum specification and not the size of the SDU that can be transmitted over 802.16, which has a higher limit. ==> This brings up multiple problems: 1) main body said SHOULD use 1500 bytes, yet this recommends 1400. 2) there is no statement in the document how to treat the appendices, i.e., why thet even exist in this document especially if they contain contradicting material. 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. editorial --------- Abstract IEEE Std 802.16 is an air interface specification. 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. The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv6 packets directly over the MAC. This document specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated identifiers. ==> s/the assignment of/assigning/ ? ==> abstract is a bit on the lengthy side. Maybe shorten a bit from the beginning, e.g. leaving ATM CS and some more generic sublayer discussions out of the abstract? 2. Introduction ==> the introduction mentions "mobile station/host", yet I think there is no restriction that the endpoint be a) mobile (could be a fixed wireless link as well), and b) a host (could be a router as well). Maybe some further clarification here is needed to make it clear that fixed/router scenarios are also to be addressed by this specification. ==> it might be helpful to have a diagram in section 2, as there are at least four functional components (AR, BS, link, MS) and at least AR hasn't been spelled out. This also seems to include some assumptions about connecting a host to a router (above). 4.1. IPv6 encapsulation over the IP CS of the MAC The IPv6 payload when carried over the IP specific part of the Packet CS is encapsulated by the 6 byte 802.16 MAC header. [...] ==> "encapsulated by" seems a bit strange.. also, later you use "encapsulated .. in". The IPv6 node requirements RFC RFC4294 [RFC4294] specifies [...] ==> s/ RFC RFC4294// _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 29 14:49:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcUT-0008RS-Go; Mon, 29 Jan 2007 14:48:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBcUS-0008RF-GH for 16ng@ietf.org; Mon, 29 Jan 2007 14:48:32 -0500 Received: from [64.25.87.235] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBcUP-00044M-Go for 16ng@ietf.org; Mon, 29 Jan 2007 14:48:32 -0500 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 5.0.1) with ESMTPSA id 1800370 for 16ng@ietf.org; Mon, 29 Jan 2007 14:48:25 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45B65399.4000707@piuha.net> References: <45B65399.4000707@piuha.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6055E634-B45E-4E11-93E2-133B549D0CF3@thingmagic.com> Content-Transfer-Encoding: 7bit From: Margaret Wasserman Date: Mon, 29 Jan 2007 14:48:23 -0500 To: 16ng@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d424907374faffed8e9e11e94f671eb2 Subject: [16NG] Review of draft-ietf-16ng-ipv6-over-ipv6cs-07.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 [I sent to the wrong e-mail address the first time. I apologize for any duplicates.] Hi All, I have a fairly large number of comments and questions on draft-ietf-16ng-ipv6-over-ipv6cs-07.txt. I have included them all below, hopefully with enough document context that you can tell what I am commenting about. Substantive issues are preceded by "SUBS:" and editorial issues are preceded by "EDIT:". IMO, this document needs some work, especially in the areas of organization and clarity, before it will be ready for publication. In some cases, I was not able to understand the document well-enough to determine what it is specifying. Thanks, Margaret --- EDIT: This document would, IMO, benefit greatly from the inclusion of RFC 2119 language to make it clear what is actually being specified. There are a fairly large number of places where loose language is used to talk about existing IPv6 functionality, and it is not always clear whether that information is being included for reference purposes, or if this document is intending to change (or at least loosen the requirements) for those parts of IPv6. Abstract IEEE Std 802.16 is an air interface specification. 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. EDIT: s/which the upper layers interface to/to which the upper layers interface. The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv6 packets directly over the MAC. This document specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. SUBS: There seems to be some confusion here about whether the IEEE has defined an IP-specific CS (presumably for both IPv4 and IPv6) or an IPv6-specific CS. Which is correct? SUBS: Why is this document defining an IPv6 encapsulation and not both an IPv4 and an IPv6 encapsulation? If they are defined separately, where will you describe how a dual stack will work over the convergence sublayer(s)? It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated identifiers. ED: s/identifiers/interface identifiers. Appendix A. WiMAX network architecture and IPv6 support . . . . . 15 Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 16 Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 17 Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 17 SUBS: What is the purpose of including this WiMAX-specific information in the document? I realize that the WiMAX architecture is expected to make use of this mechanism, but I don't understand why we would want to put this WiMAX information here, where it is unnecessary and may become obsolete over time. 2. Introduction SUBS: Is there a short description we can borrow from the IEEE regarding what 802.16 is and what it intends to accomplish? It seems like this document would greatly benefit from a summary of 802.16 up front that can be referred to later. IPv6 packets can be carried over the IEEE Std 802.16 specified air interface via either: SUBS: The document should be independent of the abstract, so you may want to repeat some of the abstract information here, rather than just jumping in. Also, shouldn't you define what IEEE Std 802.16 is and include a reference here, rather than in the next paragraph? EDIT: I think that "either" is only used when there are exactly two choices, so s/either:/: 1. the IP specific part of the Packet CS or, 2. the 802.3 specific part of the Packet CS or, 3. the 802.1Q specific part of the Packet CS. SUBS: You have not yet defined the acronym CS. Also, all of these technologies need references. The 802.16 [802.16] specification includes the Phy and MAC details. EDIT: You should define the abbreviations Phy and MAC before using them. The convergence sublayers are a part of the MAC. This document specifies IPv6 from the perspective of the transmission of IPv6 over the IP specific part of the packet convergence sublayer. The mobile EDIT: Paragraph break? station/host is attached to an access router via a base station (BS). The host and the BS are connected via the IEEE Std 802.16 air interface at the link and physical layers. The IPv6 link from the MS terminates at an access router which may be a part of the BS or an entity beyond the BS. The base station is a layer 2 entity (from the perspective of the IPv6 link between the MS and AR) and relays the IPv6 packets between the AR and the host via a point-to-point connection over the air interface. EDIT: If the text below is retained, it should be a separate paragraph. The WiMAX (Worldwide Interoperability for Microwave Access) forum [WMF] has defined a network architecture in which the air interface is based on the IEEE 802.16 standard. The addressing and operation of IPv6 described in this document is applicable to the WiMAX network as well. The various aspects of IPv6 over 802.16 as applicable to WiMAX are captured in the appendix sections of this document. SUBS: Why is this needed in the document? Are we defining IPv6 over the IEEE 802.16 IP CS exclusively for WiMAX? If not, I think we should avoid any indication that this specification is somehow WiMAX-specific. 3. Terminology The terminology in this document is based on the definitions in [PSDOC], in addition to the ones specified in this section. Access Service Network (ASN) - The ASN is defined as a complete set of network functions needed to provide radio access to a WiMAX subscriber. The ASN is the access network to which the MS attaches. The IPv6 access router is an entity within the ASN. The term ASN is specific to the WiMAX network architecture. SUBS: Same question on whether this document is WiMAX-specific. Also, it is not clear to me that this term is actually needed to understand or implement this specification. 4. IEEE 802.16 convergence sublayer support for IPv6 The figure below shows the options for IPv6 transport over the packet CS of 802.16: ----------------- ----------------- | IPv6 | | IPv6 | ---------------- |---------------| |----------- | | IPv6 | | Ethernet | | 802.1Q | |--------------| |---------------| |----------- | | IP Specific | | 802.3 specific| |802.1Q specific| |part of Pkt CS| |part of Pkt CS | |part of Pkt CS | |..............| |...............| |...............| | MAC | | MAC | | MAC | |--------------| |---------------| |---------------| | PHY | | PHY | | PHY | ---------------- ----------------- ----------------- (1) IPv6 over (2) IPv6 over (3) IPv6 over IP Specific part 802.3/Ethernet 802.1Q of Packet CS Figure 2: IPv6 over IP, 802.3 and 802.1Q specific parts of the Packet CS EDIT: Include an informative pointer to the I6ng WG document that defines IP(v4 & v6) over the Ethernet CS? The scope of this document is limited to IPv6 operation over the IP specific part of the Packet CS only. It should be noted that immediately after ranging (802.16 air interface procedure), the MS and BS exchange their capability negotiation via REG-REQ and REG- RSP. SUBS: Need more explanation in order to understand what this means. Also, expand acronyms/abbreviations. These management frames negotiate parameters such as the Convergence Sublayer support. By default, Packet, IPv4 and 802.3/Ethernet are supported. IPv6 via the Packet CS is supported by the MS and the BS only when the bit specifying such support is indicated in the parameter "Classification/PHS options and SDU encapsulation support" (Refer to [802.16]). SUBS: It is not clear what this means. Which entities negotiate IPv6 support using what mechanisms? Additionally during the establishment of the transport connection for transporting IPv6 packets, the DSA-REQ and DSA-RSP messages between the BS and MS indicate via the CS- Specification TLV the CS that the connection being setup shall use. When the IPv6 packet is encapsulated by the 802.16 six byte MAC header there is no specific indication in the MAC header itself about the payload type. The processing of the packet is based entirely on the classifiers. SUBS: Does this indicate that IPv4 and IPv6 would need to run over separate 802.16 connections? Or that they would run over a single connection? Transmission of IPv6 as explained above is possible via multiple methods, i.e, via the IP specific part of the packet CS or via Ethernet or 802.1Q interfaces. The choice of which method to use is implementation specific. In order to ensure interoperability the BS should at least support both the IP specific part of the packet CS and the Ethernet specific part of the packet CS for IPv6 transport. SUBS: I think we need something stronger than a lowercase should here. In order to assure interoperability, this specification must make it clear what each side is required to implement in order to be compliant with this spec. Hosts which may implement one or the other method for transmission would be assured of the ability to establish a transport connection that would enable the transport of IPv6 packets. Inability to negotiate a common convergence sublayer for the transport connection between the MS and BS will result in failure to setup the transport connection and thereby render the host unable to send and receive IPv6 packets. In the case of a host which implements more than one method of transporting IPv6 packets, the choice of which method to use (i.e IPv6 over the IP specific part of the packet CS or IPv6 over 802.3 or, IPv6 over 802.1Q) is implementation specific. SUBS: How does the MS tell which modes are supported by the BS? Or vice versa? 4.1. IPv6 encapsulation over the IP CS of the MAC The IPv6 payload when carried over the IP specific part of the Packet CS is encapsulated by the 6 byte 802.16 MAC header. Header suppression can also be applied to the IP packet. The format of the IPv6 packet with and without header suppression is shown in the figure below: ---------/ /----------- | MAC SDU | --------/ /------------ || || \/ --------------------------------------------------------- | PHSI=0 | IPv6 Packet (including Header) | --------------------------------------------------------- (i) IPv6 packet without header suppression SUBS: What is PHSI? Is this part of the 6-byte MAC header? Or something separate? --------------------------------------------------------- | PHSI=1 | (Header suppressed IPv6 packet) | --------------------------------------------------------- (ii) IPv6 packet with header suppression SUBS: What type of header suppression is used in this case? Please add a pointer to the relevant specification. For transmission of IPv6 packets via the IP specific part of the Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC directly. The IPv6 layer delivers the IPv6 packet to the Packet CS of the 802.16. The packet CS defines a set of classifiers that are used to determine how to handle the packet. The IP classifiers that are used at the MAC operate on the fields of the IP header and the transport protocol and these include the IP Traffic class, Next SUBS: Why include the traffic class and not the entire IPv6 Flow Label field? header field, Masked IP source and destination addresses and, SUBS: Will the classifier walk any chained IPv6 headers and use the next header field that corresponds to the upper layer protocol? Or the next header field in the main IPv6 header? SUBS: How/why are the source and dest addresses masked? Protocol source and destination port ranges. Using the classifiers, SUBS: What does the classifier use for source/dest ports if the packet is encrypted? the MAC maps an upper layer packet to a specific service flow and transport connection to be used. The MAC encapsulates the IPv6 packet in the 6 byte MAC header and transmits it. 5. Generic network architecture using the 802.16 air interface EDIT: It would be helpful to move all of the information in this section to the introduction. When an AR and a BS are collocated, the collection of Transport Connections to an MS is defined as a single link. When an AR and a BS are separated, it is recommended that a tunnel is established between the AR and a BS whose granuality is no greater than 'per MS' or 'per service flow' ( An MS can have multiple service flows which are identified by a service flow ID). Then the tunnel(s) for an MS, in combination with the MS's Transport connections, forms a single point-to-point link. EDIT: You have not previous defined "service flow", as far as I know. SUBS: If this is only recommended, what are the other options and how would IPv6 be supported over them? From the rest of the discussion, it appears that this is required, not recommended. The collection of service flows (tunnels) to an MS is defined as a single link. Each link has only an MS and an AR. Each MS belongs to a different link. A different prefix should be assigned to each unique link. This link is fully consistent with a standard IP link, without exception and conforms with the definition of a point-to- point link in RFC2461 [RFC2461]. Hence the point-to-point link model for IPv6 operation over the IP specific part of the Packet CS in 802.16 is recommended. A unique IPv6 prefix(es) per link (MS) is also recommended. SUBS: Should we make it clear that this prefix should be no longer than a /64, in order to provide full support for the features of IPv6? 6.2. IPv6 link establishment in 802.16 In order to enable the sending and receiving of IPv6 packets between the MS and the AR, the link between the MS and the AR via the BS needs to be established. This section illustrates the link establishment procedure. [...] 5. The MS can request the establishment of a service flow for IPv6 packets over the IP specific part of the Packet CS. The service flow can also be triggered by the network as a result of pre- provisioning. The service flow establishes a link between the MS and the AR over which IPv6 packets can be sent and received. SUBS: When you say "the MS can request" or "the service flow can also be triggered", which is the mandatory mode that both ends must support? 6. The AR sends a router advertisement to the MS. Alternatively or in addition, the MS can also send a router solicitation. SUBS: The AR and MS should send router advertisements and solicitations as specified in the Neighbor Discovery specification. If it is not your intent to change that, I would put a pointer here instead of the wording that is currently included. The above flow does not show the actual 802.16 messages that are used for ranging, capability exchange or service flow establishment. Details of these are in [802.16]. 6.3. Maximum transmission unit in 802.16 The 802.16 MAC PDU (Protocol Data Unit) is composed by a 6 byte header followed by an optional payload and an optional CRC covering the header and the payload. The length of the PDU is indicated by the Len parameter in the Generic MAC HDR. The Len parameter has a size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6 payload can be a max value of 2038 bytes ( Total PDU size minus (MAC Header + CRC)). The Max value of the IPv6 MTU for 802.16 is 2038 bytes and the minimum value of 1280 bytes. The default MTU for IPv6 over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 octets. SUBS: It is unclear what you are specifying here. We don't get to declare a default value for the 802.16 MTU. One of two things seems to be true here, and I don't have enough information to know which one: the MTU of 802.16 networks is 2038 bytes, or the MTU for 802.16 network is configurable between 1280 and 2038 bytes. Either way, IPv6 should be aware of the actual MTU in use on a give link and PMTUD should function accordingly. RFC2461 defines an MTU option that an AR can advertise to an MN. If an AR advertises an MTU via the RA MTU option, the MN should use the MTU from the RA. SUBS: Even if it is greater than 2038 or less than 1280 bytes? 7. IPv6 prefix assignment The MS and the AR are connected via a point-to-point connection at the IPv6 layer. Hence each MS can be considered to be on a separate subnet. A CPE (Customer Premise Equipment) type of device which serves multiple IPv6 hosts, may be the end point of the connection. Hence one or more /64 prefixes should be assigned to a link. The prefixes are advertised with the on-link (L-bit) flag set as specified in RFC2461 [RFC2461]. The size and number of the prefixes is a configuration issue. Also, prefix delegation may be used to provide additional prefixes for a router connected over 802.16. The other properties of the prefixes are also dealt via configuration. SUBS: As above, we should strongly recommend prefixes no shorter than a /64 in order for all IPv6 features to function properly. 8.3. Router lifetime and periodic router advertisements The router lifetime should be set to a large value, preferably in hours. This document over-rides the specification for the value of the router lifetime in RFC2461 [RFC2461]. The AdvDefaultLifetime in the router advertisement MUST be either zero or between MaxRtrAdvInterval and 43200 seconds. The default value is 2 * MaxRtrAdvInterval. 802.16 hosts have the capability to transition to an idle mode in which case the radio link between the BS and MS is torn down. Paging is required in case the network needs to deliver packets to the MS. In order to avoid waking a mobile which is in idle mode and consuming resources on the air interface, the interval between periodic router advertisements should be set quite high. The MaxRtrAdvInterval value specified in this document over-rides the recommendation in RFC2461 [RFC2461]. The MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 21600 seconds. The default value for MaxRtrAdvInterval is 10800 seconds. SUBS: I would like to see some exploration of what the impact of these changes would be on IPv6 operations. Are there other mechanisms that are used in 802.16 for black-hole detection and/or detecting when a network connection has been lost? 9.1. Interface Identifier The MS has a 48-bit MAC address as specified in 802.16 [802.16]. This MAC address can be used if EUI-64 based interface identifier is needed for autoconfiguration RFC4291 [RFC4291]. As in other links that support IPv6, EUI-64 based interface identifiers are not mandatory and other mechanisms, such as random interface identifiers RFC3041 [RFC3041] may also be used. SUBS: Would the translation from 802.16's 48-bit MAC address to an EUI-64 identifier be the same as for an Ethernet address? EDIT: IPv6 addressers are based on Modified EUI-64 identifiers, not on EUI-64s in their original form. 9.2. Duplicate address detection DAD is performed as per RFC2461 [RFC2461] and, RFC2462 [RFC2462]. EDIT: Here and elsewhere, it would be more useful to name these documents and include the RFC number in the citation, rather than simply repeating the RFC number. 9.3. Stateless address autoconfiguration If the A-bit in the prefix information option (PIO) is set, the MS performs stateless address autoconfiguration as per RFC 2461, 2462. The AR is the default router that advertises a unique prefix (or prefixes) that is used by the MS to configure an address. 9.4. Stateful address autoconfiguration The Stateful Address Autoconfiguration is invoked if the M-flag is set in the Router Advertisement. Obtaining the IPv6 address through stateful address autoconfiguration method is specified in RFC3315 [RFC3315]. SUBS: In both of the previous two sections, is this any different from standard IPv6? If so, spell out what is changed. If not, why include these sections? 10. IANA Considerations This draft does not require any actions from IANA. 11. Security Considerations This document does not introduce any new vulnerabilities to IPv6 specifications or operation. The security of the 802.16 air interface is the subject of [802.16]. In addition, the security issues of the network architecture spanning beyond the 802.16 base stations is the subject of the documents defining such architectures, such as WiMAX Network Architecture [WiMAXArch]. SUBS: I am not sure that this is correct. I am not clear on how 802.16 packet classification is consistent with encrypted upper-layer headers. Also, the changes to the Router Solicitation/Advertisement timers may have some security-related implications, particularly WRT to how long it may take end-nodes to detect changes to network attachment. Appendix E. Stateless address autoconfiguration The MS can perform stateless address autoconfiguration as per RFC2461, 2462 if the A-bit in the prefix information option (PIO) is set. The AR is the default router that advertises a unique /64 prefix (or prefixes) that is used by the MS to configure an address. EDIT: Why is this in an appendix? How does this differ from section 9.3? 3.2. Informative References [802.16] "IEEE Std 802.16e: IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", October 2005. SUBS: The IEEE 802.16 document should be a normative reference for this specification, not an informative one. EDIT: Since this is now available for free download, a URL would be helpful. [RFC3315] Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, . EDIT: There is no reference to RFC 3315 in the document. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 29 18:01:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfVS-0008Ei-CA; Mon, 29 Jan 2007 18:01:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBfVQ-0008Eb-RP for 16ng@ietf.org; Mon, 29 Jan 2007 18:01:44 -0500 Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBfVP-0002EL-8K for 16ng@ietf.org; Mon, 29 Jan 2007 18:01:44 -0500 Received: from [87.103.79.231] (231.79.103.87.rev.vodafone.pt [87.103.79.231]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l0TN1aX5025309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <16ng@ietf.org>; Mon, 29 Jan 2007 23:01:38 GMT Message-ID: <45BE7CD6.8070707@dei.uc.pt> Date: Mon, 29 Jan 2007 23:01:42 +0000 From: Bruno Miguel Sousa User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: 16ng@ietf.org Subject: [16NG] Review draft-ietf-v6ops-802-16-deployment-scenarios-02 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: 1.1 (+) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 v6ops group. I've reviewed the IPv6 Deployment Scenarios in 802.16(e) Networks version 02. Where are my comments: [General] I think the document introduces different issues related with IPv6 in the IEEE 802.16 networks and presents the on going work to overcome the same. And quite interesting scenarios. Nevertheless I think the document needs improvements. 1) If talking about deployment scenarios, does make sense to refer the WiMAX Network reference model, at least in the appendix. As done by the IPv6 over Packet CS in 802.16 specification. 2) The differences from IPv4 don't seem to explicit in the text. When in the abstract is defended such goal for the document. [Specific] S1) Section 2.2.1 " Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as well as fixed communication. " In my opinion I would not make the comparison with the 802.11. Furthermore on the previous section (section 2.2) there is already a mention to the cellular system. I suggest the following text: The IEEE 802.16 BS can provide mobility functions and fixed communications. " There is alwayes ... " Minor typo, always S2) Section 2.2.1.1 " The BS does not need to support IPv6. " I think this sentence might not be aligned to the scope and with other sections of the document. If the BS does not support IPv6, at least it should support IPv6 classifiers (as presented on the section 2.2.1.3). My suggestion is to remove this and consequent sentences and introduce the following: The BS should support IPv6 classifiers as specified in [IEEE 802.16]. S3) Section 2.2.1.3 " In a subnet, there are always two underlying links: " I suggest to use : In a IPv6 subnet, there are... Just for clarification. S4) Section 2.2.1.3 " BS generates the flow based on the classification. It also decides where to send the packet or just forward the packet to the ACR, since IEEE 802.16 connection always ends at BS while IPv6 connection terminates at the AR. " To these sentences I want to remark the following: 1) If the document as implicit the service flows created by the BS, then this should be more explicit. For instance the document refers the mesh mode of the standard but states that only focuses the PMP mode (section 2.2). So I suggest to add to section 2.2 the following text: The [IEEE802.16] supports MS initiated service flows and BS initiated service flows. The document only focuses the BS initiated service flows. 2) The term ACR is not defined in the document (and sorry) I don't know what does it mean. Do you intend to say AR?! S5) Section 2.2.1.3 " However PHS (Packet Header Compression) " If you are referring the 802.16 PHS, shouldn't you state Payload Header Suppression. I suggest a rephrasing: When PHS (Payload Header Suppression) is deployed it mitigates this overhead through the compression of packet headers. S6) Section 2.2.1.4 " Therefore, no routing protocols are needed on the MS. " Just for clarification. This sentence also applies when the MS has a network behind it? The default routes are enough in such cases? S7) Section 2.2.1.5 " Also, IEEE 802.16g which is ... " I would add an informative reference regarding 802.16g. It is missing! " convergence sublayers [I-D.iab-link-encaps], the mobile access scenarios need solutions about how roaming will work when forced to move from one CS to another. " Just for clarification. I would add an example of the CS roaming (e.g. from IPv4 CS to Ethernet CS). S8) Section 2.2.2.1 The text in this section refers that MS, AR, and ER should support IPv6. The S2 applies also here. And the Ethernet Bridge should also support IPv6 to build the authoritative address cache (as referenced in section 2.2.2.3). " The bridge builds its authoritative address cache by parsing the IPv6 Neighbor Discovery messages used during address configuration (DAD). " I think in this section there should be a reference to the required IPv6 support by the Ethernet Bridge. S9) Section 2.4 " The QoS has different semantics with IP QoS " I suggest to change this sentence: The 802.16 supported QoS has different semantics from IP QoS. S10) Section 2.6 I think this section does not fulfill the intended purpose. It does not refer how to make IPv6 Network Management. And besides this, I think there should be a reference to the 802.16f the amendment that includes the management information base for IEEE 802.16 networks. For the moment, this is my input to the document. Kindly, Bruno Sousa _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Mon Jan 29 19:04:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgTf-0003J6-Er; Mon, 29 Jan 2007 19:03:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBgTd-0003J1-U2 for 16ng@ietf.org; Mon, 29 Jan 2007 19:03:57 -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 1HBgTY-0001vf-Jl for 16ng@ietf.org; Mon, 29 Jan 2007 19:03:57 -0500 Received: from etriabcb8a0047 ([129.254.112.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 09:08:26 +0900 From: "Jee, Junghoon" To: "'gabriel montenegro'" , "'Daniel Park'" , <16ng@ietf.org> References: <20070129102323.63363.qmail@web81906.mail.mud.yahoo.com> Subject: RE: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 Date: Tue, 30 Jan 2007 09:03:51 +0900 Message-ID: <002501c74402$1fd67440$4270fe81@etriabcb8a0047> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070129102323.63363.qmail@web81906.mail.mud.yahoo.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AcdDkClDBBmmnh1mQdaRVl1oAqaYFwAcNv4A X-OriginalArrivalTime: 30 Jan 2007 00:08:26.0658 (UTC) FILETIME=[C3A8A020:01C74402] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d9aaf4f837d0910b987cb9188300fdd 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="===============1541162715==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============1541162715== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C7444D.8FBE1C40" This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C7444D.8FBE1C40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Gabriel, The PS update reflecting the DJ and Phil's 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's day. I hope this works for the WG's 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 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 > -----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" > 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_0026_01C7444D.8FBE1C40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Gabriel,

The = PS update reflecting the DJ and Phil’s 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’s day.

I = hope this works for the WG’s 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_0026_01C7444D.8FBE1C40-- --===============1541162715== 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 --===============1541162715==-- From 16ng-bounces@ietf.org Mon Jan 29 20:50:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBi8w-0007zn-4k; Mon, 29 Jan 2007 20:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBi8v-0007zi-9n for 16ng@ietf.org; Mon, 29 Jan 2007 20:50:41 -0500 Received: from web81908.mail.mud.yahoo.com ([68.142.207.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HBi8t-0005qD-KW for 16ng@ietf.org; Mon, 29 Jan 2007 20:50:41 -0500 Received: (qmail 91199 invoked by uid 60001); 30 Jan 2007 01:50:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=Ob7y5qo51Me0vSrHO7HstWwh5ngckIUdBSk5UJ8MY6ahyK6Ump4sYPOpGEwr3Y8BFsyXxfC4JqsVDKi+rfFsaB/gTizUeScPPC32utaptWc324GvguMo1gWB1fmmFGC5fFQg0yen0wKit2HDinRLGdKQi+Ztm3TcSGnQCcyprAw= ; Message-ID: <20070130015037.91197.qmail@web81908.mail.mud.yahoo.com> Received: from [131.107.0.103] by web81908.mail.mud.yahoo.com via HTTP; Mon, 29 Jan 2007 17:50:37 PST Date: Mon, 29 Jan 2007 17:50:37 -0800 (PST) From: gabriel montenegro Subject: Re: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 To: "Jee, Junghoon" , Daniel Park , 16ng@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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="===============0053888374==" Errors-To: 16ng-bounces@ietf.org --===============0053888374== Content-Type: multipart/alternative; boundary="0-713366911-1170121837=:90164" --0-713366911-1170121837=:90164 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable I guess that's before Feb 18 or so? Cool, thanks.=0A=0Asay hay boke-mahn he= pah du say oh.=0A=0A-gabriel=0A=0A----- Original Message ----=0AFrom: "Jee= , Junghoon" =0ATo: gabriel montenegro ; Daniel Park ; 16ng@ietf.org=0AS= ent: Monday, January 29, 2007 4:03:51 PM=0ASubject: RE: [16NG] RE: WG Decis= ion: WGLC : draft-ietf-16ng-ps-goals-00=0A=0A=0A=0A=0A =0A =0A=0A =0A=0A = =0A=0A =0A=0A=0A= =0A=0A=0A=0A=0A=0A=0AHello Gabriel,=0A =0A=0AThe PS update=0Areflecting the= DJ and Phil=A2s comments have been undertaken and still ongoing.=0A =0A=0A= The main=0Areason of the unexpected delay was that proposed comments are mo= re than=0Aeditorial and requires structural and major enhancement from the = current=0Aversion.=0A =0A=0AI expect that=0Anew version should be available= before the lunar new year=A2s day.=0A =0A=0AI hope this=0Aworks for the WG= =A2s agenda.=0A =0A=0A =0A =0A=0ABest Regards,=0A =0A=0AJunghoon=0A =0A=0A= =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AFrom:=0Agabriel montenegro [mailto:g= abriel_montenegro_2000@yahoo.com] =0A=0ASent: Monday, January 29, 2007=0A 7= :23 PM=0A=0ATo: Junghoon Jee; Daniel Park;=0A16ng@ietf.org=0A=0ASubject: Re= : [16NG] RE: WG=0ADecision: WGLC : draft-ietf-16ng-ps-goals-00=0A =0A=0A=0A= =0A=0A =0A =0A=0A=0A=0A=0A=0AAny idea when the new=0Aversion will be avail= able?=0A=0A=0A=0Athanks,=0A=0A=0A=0A-gabriel=0A =0A=0A=0A=0A----- Original= =0AMessage ----=0A=0AFrom: Junghoon Jee < jhjee@etri.re.kr >=0A=0ATo: Danie= l Park ; 16ng@ietf.org=0A=0ASent: Tuesday, Decemb= er 26, 2006=0A 11:12:20 PM=0A=0ASubject: [16NG] RE: WG Decision: WGLC : dra= ft-ietf-16ng-ps-goals-00=0A =0A=0A=0A=0ADaniel,=0A=0ASorry for the delay.= =0A=0AThe updated PS I-D will be available soon along with the related=0A= =0Adiscussion if necessary.=0A=0A=0A=0AJunghoon =0A=0A=0A=0A> -----Original= Message-----=0A=0A> From: Daniel Park [mailto:soohong.park@samsung.com] = =0A=0A> Sent: Wednesday, December 27, 2006=0A 1:58 PM=0A=0A> To: 16ng@ietf.= org=0A=0A> Cc: ???=0A=0A> Subject: WG Decision: WGLC : draft-ietf-16ng-ps-g= oals-00=0A=0A> =0A=0A> =0A=0A> Folks, =0A=0A> =0A=0A> The WGLC expired long= time ago, but WG does not think it is =0A=0A> passed successfully. In orde= r words, the authors need more =0A=0A> works on the revision to increase th= e quality of this =0A=0A> document. Once updating it including two experts = review (DJ =0A=0A> and Phil) as well as a new set of terms. We will solicit= one =0A=0A> more short WGLC to be ready for the IESG at that time. =0A=0A>= =0A=0A> Junghoon, please update it as soon as possible, then submit =0A=0A= > it to the IETF secretariate. =0A=0A> =0A=0A> Thanks, =0A=0A> =0A=0A> Dani= el (Soohong Daniel Park)=0A=0A> Mobile Convergence Laboratory, SAMSUNG Elec= tronics.=0A=0A> =0A=0A> ----- Original Message -----=0A=0A> From: "Soohong = Daniel Park" =0A=0A> To: <16ng@eeca16.sogang.ac.kr>=0A= =0A> Sent: Tuesday, October 17, 2006=0A 9:19 AM=0A=0A> Subject: [16ng] WGLC= : draft-ietf-16ng-ps-goals-00=0A=0A> =0A=0A> =0A=0A> > Folks,=0A=0A> > =0A= =0A> > This is a two week WGLC on draft-ietf-16ng-ps-goals-00.=0A=0A> > =0A= =0A> > Please review the I-D and submit your comments to the authors or=0A= =0Ato=0A=0A> > the list directly. The WGLC will exipre on October 31 =0A=0A= > (Pacific Time).=0A=0A> > =0A=0A> > o I-D: =0A=0A> http://www.ietf.org/int= ernet-drafts/draft-ietf-16ng-ps-goals-00.txt=0A=0A> > =0A=0A> > o Intended = publication: Informational RFC=0A=0A> > =0A=0A> > =0A=0A> > -- =0A=0A> > = =0A=0A> > =0A=0A> > Daniel (Soohong Daniel Park)=0A=0A> > Mobile Convergenc= e Laboratory,=0ASAMSUNG Electronics.=0A=0A> > _____________________________= __________________=0A=0A> > 16ng mailing list=0A=0A> > 16ng@eeca16.sogang.a= c.kr=0A=0A> > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng=0A=0A> > =0A= =0A> >=0A=0A=0A=0A=0A=0A_______________________________________________=0A= =0A16NG mailing list=0A=0A16NG@ietf.org=0A=0Ahttps://www1.ietf.org/mailman/= listinfo/16ng=0A =0A=0A=0A=0A=0A=0A=0A=0A =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A --0-713366911-1170121837=:90164 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: quoted-printable
I guess that's before Feb 18 or so? Cool, thanks.
=
say hay boke-mahn he pah du say oh.
-gabriel

----- Original Message ----
From: "J= ee, Junghoon" <jhjee@etri.re.kr>
To: gabriel montenegro <gabrie= l_montenegro_2000@yahoo.com>; Daniel Park <soohong.park@samsung.com&g= t;; 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

=0A= =0A=0A =0A =0A=0A =0A=0A =0A=0A =0A=0A=0A=0A=0A=0A
=0A=0A

Hello Gabriel,

=0A=0A

The PS updat= e=0Areflecting the DJ and Phil=A1=AFs comments have been undertaken and still ongoi= ng.

=0A=0A

The main=0Areason of the unexpected del= ay was that proposed comments are more than=0Aeditorial and requires struct= ural and major enhancement from the current=0Aversion.

= =0A=0A

I expect that=0Anew version should be available before the lu= nar new year=A1=AFs day.

=0A=0A

I hope this=0Aworks for t= he WG=A1= =AFs agenda.

=0A=0A

 

=0A= =0A

Best Regards,

=0A=0A

<= font color=3D"navy" face=3D"=B1=BC=B8=B2" size=3D"2">Junghoon<= /font>

=0A=0A

 

=0A=0A
=0A=0A
=0A=0A
= =0A=0A
=0A=0A

From:=0Agabriel montenegro [mailto:gabriel_montenegro_2000@yahoo.com]
= =0ASent: Monday, January 2= 9, 2007=0A 7:23 PM
=0ATo: Junghoon Jee; Daniel Park;=0A16ng@ietf.org
=0ASubject: Re: [16NG] RE: WG=0ADecision: WGLC : dra= ft-ietf-16ng-ps-goals-00

=0A= =0A
=0A=0A

 

=0A=0A
=0A=0A
=0A=0A

Any idea when the new=0Aversion w= ill be available?
=0A
=0Athanks,
=0A
=0A-gabriel<= /p> =0A=0A

=0A=0A

= ----- Original=0AMessage ----
=0AFrom: Junghoon Jee < = jhjee@etri.re.kr >
=0ATo: Daniel Park <soohong.park@samsung.com>= ;; 16ng@ietf.org
=0ASent: Tuesday, December 26, 2006=0A 11:12:20 PM
= =0ASubject: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00

=0A=0A
=0A=0A

Daniel= ,
=0ASorry for the delay.
=0AThe updated PS I-D will be available soo= n along with the related
=0Adiscussion if necessary.
=0A
=0AJungho= on
=0A
=0A> -----Original Message-----
=0A> From: Daniel Pa= rk [mailto:soohong.park@samsung.com]
=0A> Sent: Wednesday, December = 27, 2006=0A 1:58 PM
=0A> To: 16ng@ietf.org
=0A> Cc: ???
=0A&= gt; Subject: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00
=0A> =0A>
=0A> Folks,
=0A>
=0A> The WGLC expired long t= ime ago, but WG does not think it is
=0A> passed successfully. In or= der words, the authors need more
=0A> works on the revision to incre= ase the quality of this
=0A> document. Once updating it including tw= o experts review (DJ
=0A> and Phil) as well as a new set of terms. W= e will solicit one
=0A> more short WGLC to be ready for the IESG at = that time.
=0A>
=0A> Junghoon, please update it as soon as po= ssible, then submit
=0A> it to the IETF secretariate.
=0A> =0A> Thanks,
=0A>
=0A> Daniel (Soohong Daniel Park)
= =0A> Mobile Convergence Laboratory, SAMSUNG Electronics.
=0A>
= =0A> ----- Original Message -----
=0A> From: "Soohong Daniel Park"= <soohongp@gmail.com>
=0A> To: <16ng@eeca16.sogang.ac.kr>=
=0A> Sent: Tuesday, October 17, 2006=0A 9:19 AM
=0A> Subject: = [16ng] WGLC : draft-ietf-16ng-ps-goals-00
=0A>
=0A>
=0A>= ; > Folks,
=0A> >
=0A> > This is a two week WGLC on d= raft-ietf-16ng-ps-goals-00.
=0A> >
=0A> > Please review = the I-D and submit your comments to the authors or
=0Ato
=0A> >= the list directly. The WGLC will exipre on October 31
=0A> (Pacific= Time).
=0A> >
=0A> > o I-D:
=0A> http://www.ietf.org/internet-drafts/draft-ietf-16n= g-ps-goals-00.txt
=0A> >
=0A> > o Intended publicati= on: Informational RFC
=0A> >
=0A> >
=0A> > -- =
=0A> >
=0A> >
=0A> > Daniel (Soohong Daniel P= ark)
=0A> > Mobile Convergence Laboratory,=0ASAMSUNG Electronics.<= br>=0A> > _______________________________________________
=0A> = > 16ng mailing list
=0A> > 16ng@eeca16.sogang.ac.kr
=0A> = > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng<= /a>
=0A> >
=0A> >
=0A
=0A
=0A__________________= _____________________________
=0A16NG mailing list
=0A16NG@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo/16ng=

=0A=0A
=0A=0A
=0A=0A

 

=0A=0A
=0A=0A
=0A=0A=
=0A=0A

--0-713366911-1170121837=:90164-- --===============0053888374== 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 --===============0053888374==-- From 16ng-bounces@ietf.org Mon Jan 29 21:22:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBidN-0004R0-9T; Mon, 29 Jan 2007 21:22:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBidM-0004Qv-JE for 16ng@ietf.org; Mon, 29 Jan 2007 21:22:08 -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 1HBidK-0005ZG-Bw for 16ng@ietf.org; Mon, 29 Jan 2007 21:22:08 -0500 Received: from etriabcb8a0047 ([129.254.112.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 11:26:41 +0900 From: "Jee, Junghoon" To: "'gabriel montenegro'" , "'Daniel Park'" , <16ng@ietf.org> References: <20070130015037.91197.qmail@web81908.mail.mud.yahoo.com> Subject: RE: [16NG] RE: WG Decision: WGLC : draft-ietf-16ng-ps-goals-00 Date: Tue, 30 Jan 2007 11:22:06 +0900 Message-ID: <004401c74415$6fb2cfa0$4270fe81@etriabcb8a0047> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070130015037.91197.qmail@web81908.mail.mud.yahoo.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AcdEEa/s92ojWJqGQ7ONAruiskVGKwAAy2SA X-OriginalArrivalTime: 30 Jan 2007 02:26:41.0265 (UTC) FILETIME=[13A13610:01C74416] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4824b9ef1b1988f2983d420e78cedc0a 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="===============1536000894==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============1536000894== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01C74460.DF9A77A0" This is a multi-part message in MIME format. ------=_NextPart_000_0045_01C74460.DF9A77A0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable =20 =20 _____ =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. Junghoon>> That's right, Thankyou. say hay boke-mahn he pah du say oh. =20 Junghoon>> What a sweet greeting! Happy new year you too!! -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_0045_01C74460.DF9A77A0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable

 =

 =

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.

Junghoon>> That’s = right, Thankyou.


say hay boke-mahn he pah = du say oh.

 

Junghoon>> What a sweet greeting! Happy new year = you too!!



-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_0045_01C74460.DF9A77A0-- --===============1536000894== 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 --===============1536000894==-- From 16ng-bounces@ietf.org Tue Jan 30 00:36:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlfS-0000n4-LS; Tue, 30 Jan 2007 00:36:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlfS-0000mz-6z for 16ng@ietf.org; Tue, 30 Jan 2007 00:36:30 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBlfP-0007M1-RB for 16ng@ietf.org; Tue, 30 Jan 2007 00:36:30 -0500 Received: by nz-out-0506.google.com with SMTP id z6so1692016nzd for <16ng@ietf.org>; Mon, 29 Jan 2007 21:36:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lKjNTi0ntrDN77qkB/7qrsUyYnJNt/DrwU81ukWZ44za/scJLgQeXEez0opQjJYQcoaqhvZ91fWtHbCGIE4LB56D9GRNCl+guJZigBSYVZYQ+ykZzAloTrBqKLKsiRxmMionoe2M3v50L5AM2CmRfJkP/L6hkLE9jlFzAFEN1vI= Received: by 10.65.219.11 with SMTP id w11mr11295552qbq.1170135387083; Mon, 29 Jan 2007 21:36:27 -0800 (PST) Received: from ?129.254.112.125? ( [129.254.112.125]) by mx.google.com with ESMTP id a29sm10297649qbd.2007.01.29.21.36.24; Mon, 29 Jan 2007 21:36:25 -0800 (PST) Message-ID: <45BED94D.5010201@gmail.com> Date: Tue, 30 Jan 2007 14:36:13 +0900 From: Myung-Ki Shin Organization: ETRI User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruno Miguel Sousa Subject: Re: [16NG] Review draft-ietf-v6ops-802-16-deployment-scenarios-02 References: <45BE7CD6.8070707@dei.uc.pt> In-Reply-To: <45BE7CD6.8070707@dei.uc.pt> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: v6ops@ops.ietf.org, 16ng@ietf.org X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: myungki.shin@gmail.com 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 Bruno, I agree on most of your comments. I'm preparing revision now. Thanks. See inline. Bruno Miguel Sousa wrote: > Dear v6ops group. > > I've reviewed the IPv6 Deployment Scenarios in 802.16(e) Networks version > 02. Where are my comments: > > [General] > I think the document introduces different issues related with IPv6 in the > IEEE 802.16 networks and presents the on going work to overcome the same. > And quite interesting scenarios. > Nevertheless I think the document needs improvements. > 1) If talking about deployment scenarios, does make sense to refer the > WiMAX Network reference model, at least in the appendix. As done by the > IPv6 over Packet CS in 802.16 specification. Actually, this draft covers the typical scenarios based on IPv6 link models for 802.16, draft-ietf-16ng-ipv6-link-model-analysis. Authors believe that we don't need to add any specific scenarios for WiMAX or WiBro in appendix or elsewhere. We just refer to draft-ietf-16ng-ipv6-link-model-analysis or 802.16 specification. And, all the suggestions below are valid. > > [Specific] > > S1) > Section 2.2.1 > " > Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as > well as fixed communication. > " > In my opinion I would not make the comparison with the 802.11. Furthermore > on the previous section (section 2.2) there is already a mention to the > cellular system. I suggest the following text: > The IEEE 802.16 BS can provide mobility functions and fixed > communications. Ok. > " > There is alwayes ... > " > Minor typo, always Correct. > > S2) > Section 2.2.1.1 > " > The BS does not need to support IPv6. > " > I think this sentence might not be aligned to the scope and with other > sections of the document. > If the BS does not support IPv6, at least it should support IPv6 > classifiers (as presented on the section 2.2.1.3). > My suggestion is to remove this and consequent sentences and introduce the > following: > The BS should support IPv6 classifiers as specified in [IEEE 802.16]. Agreed. > > S3) > Section 2.2.1.3 > " > In a subnet, there are always two underlying links: > " > I suggest to use : > In a IPv6 subnet, there are... > > Just for clarification. Yes. > > > S4) > Section 2.2.1.3 > " > BS generates the flow based on > the classification. It also decides where to send the packet or just > forward the packet to the ACR, since IEEE 802.16 connection always > ends at BS while IPv6 connection terminates at the AR. > " > To these sentences I want to remark the following: > 1) If the document as implicit the service flows created by the BS, then > this should be more explicit. For instance the document refers the mesh > mode of the standard but states that only focuses the PMP mode (section > 2.2). So I suggest to add to section 2.2 the following text: > The [IEEE802.16] supports MS initiated service flows and BS initiated > service flows. The document only focuses the BS initiated service flows. I think it is better to remove the paragraph in sec 2.2.1.3 to avoid confusion. > 2) The term ACR is not defined in the document (and sorry) I don't know > what does it mean. Do you intend to say AR?! AR is correct. > S5) > Section 2.2.1.3 > " > However PHS (Packet Header Compression) > " > If you are referring the 802.16 PHS, shouldn't you state Payload Header > Suppression. I suggest a rephrasing: > When PHS (Payload Header Suppression) is deployed it mitigates this > overhead through the compression of packet headers. > It seems to be fine with me. > > S6) > Section 2.2.1.4 > " > Therefore, no routing protocols are needed on the MS. > " > Just for clarification. This sentence also applies when the MS has a > network behind it? The default routes are enough in such cases? That's good point. In sec 2.2.1.4, we should consider the case - the MS has a network behind it, too. We'll rephrase it and add this case. > > S7) > Section 2.2.1.5 > " > Also, IEEE 802.16g which is ... > " > I would add an informative reference regarding 802.16g. It is missing! I'll add it. > > " > convergence sublayers [I-D.iab-link-encaps], the mobile access > scenarios need solutions about how roaming will work when forced to > move from one CS to another. > " > Just for clarification. I would add an example of the CS roaming (e.g. from > IPv4 CS to Ethernet CS). Ok. e.g., IPv6 CS to Ethernet CS > > S8) > Section 2.2.2.1 > The text in this section refers that MS, AR, and ER should support IPv6. > The S2 applies also here. > And the Ethernet Bridge should also support IPv6 to build the authoritative > address cache (as referenced in section 2.2.2.3). > " > The bridge builds its authoritative address cache by parsing the IPv6 > Neighbor Discovery messages used during address configuration (DAD). > " > I think in this section there should be a reference to the required IPv6 > support by the Ethernet Bridge. Right, I'll update it. > S9) > Section 2.4 > " > The QoS has different semantics with IP QoS > " > I suggest to change this sentence: > The 802.16 supported QoS has different semantics from IP QoS. Ok. > > S10) > Section 2.6 > I think this section does not fulfill the intended purpose. It does not > refer how to make IPv6 Network Management. > And besides this, I think there should be a reference to the 802.16f the > amendment that includes the management information base for IEEE 802.16 > networks. Ok, I'll try to rephase it and add the reference. Thanks for your valuable comments. Myung-Ki, _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 30 02:27:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnOt-0003TX-Vc; Tue, 30 Jan 2007 02:27:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnOs-0003TM-TF for 16ng@ietf.org; Tue, 30 Jan 2007 02:27:30 -0500 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBnOr-00008N-8P for 16ng@ietf.org; Tue, 30 Jan 2007 02:27:30 -0500 Received: from [87.103.54.227] (227.54.103.87.rev.vodafone.pt [87.103.54.227]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l0U7NSIG006117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jan 2007 07:23:30 GMT Message-ID: <45BEF272.6030207@dei.uc.pt> Date: Tue, 30 Jan 2007 07:23:30 +0000 From: Bruno Miguel Sousa User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: myungki.shin@gmail.com Subject: Re: [16NG] Review draft-ietf-v6ops-802-16-deployment-scenarios-02 References: <45BE7CD6.8070707@dei.uc.pt> <45BED94D.5010201@gmail.com> In-Reply-To: <45BED94D.5010201@gmail.com> 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: 1.1 (+) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: v6ops@ops.ietf.org, 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 Myung-Ki Thanks for taking account my comments. Yesterday I forgot to mention the title of the document. "IPv6 Deployment Scenarios in 802.16(e) Networks" In my opinion I would remove the (e) version. Since the document specifies the fixed and mobile 802.16 access networks. Just put: "IPv6 Deployment Scenarios in 802.16 Networks". Kindly, Bruno Sousa Myung-Ki Shin wrote: > Hi Bruno, > > I agree on most of your comments. > I'm preparing revision now. Thanks. > > See inline. > > Bruno Miguel Sousa wrote: >> Dear v6ops group. >> >> I've reviewed the IPv6 Deployment Scenarios in 802.16(e) Networks >> version >> 02. Where are my comments: >> >> [General] >> I think the document introduces different issues related with IPv6 in >> the >> IEEE 802.16 networks and presents the on going work to overcome the >> same. >> And quite interesting scenarios. >> Nevertheless I think the document needs improvements. >> 1) If talking about deployment scenarios, does make sense to refer the >> WiMAX Network reference model, at least in the appendix. As done by the >> IPv6 over Packet CS in 802.16 specification. > > Actually, this draft covers the typical scenarios based on IPv6 link > models for 802.16, draft-ietf-16ng-ipv6-link-model-analysis. > Authors believe that we don't need to add any specific scenarios for > WiMAX or WiBro in appendix or elsewhere. We just refer to > draft-ietf-16ng-ipv6-link-model-analysis or 802.16 specification. > > And, all the suggestions below are valid. >> >> [Specific] >> >> S1) >> Section 2.2.1 >> " >> Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as >> well as fixed communication. >> " >> In my opinion I would not make the comparison with the 802.11. >> Furthermore >> on the previous section (section 2.2) there is already a mention to the >> cellular system. I suggest the following text: >> The IEEE 802.16 BS can provide mobility functions and fixed >> communications. > > Ok. > >> " >> There is alwayes ... >> " >> Minor typo, always > > Correct. > >> >> S2) >> Section 2.2.1.1 >> " >> The BS does not need to support IPv6. >> " >> I think this sentence might not be aligned to the scope and with other >> sections of the document. >> If the BS does not support IPv6, at least it should support IPv6 >> classifiers (as presented on the section 2.2.1.3). >> My suggestion is to remove this and consequent sentences and >> introduce the >> following: >> The BS should support IPv6 classifiers as specified in [IEEE 802.16]. > > Agreed. > >> >> S3) >> Section 2.2.1.3 >> " >> In a subnet, there are always two underlying links: >> " >> I suggest to use : >> In a IPv6 subnet, there are... >> >> Just for clarification. > > Yes. >> >> >> S4) >> Section 2.2.1.3 >> " >> BS generates the flow based on >> the classification. It also decides where to send the packet or just >> forward the packet to the ACR, since IEEE 802.16 connection always >> ends at BS while IPv6 connection terminates at the AR. >> " >> To these sentences I want to remark the following: >> 1) If the document as implicit the service flows created by the BS, then >> this should be more explicit. For instance the document refers the mesh >> mode of the standard but states that only focuses the PMP mode (section >> 2.2). So I suggest to add to section 2.2 the following text: >> The [IEEE802.16] supports MS initiated service flows and BS initiated >> service flows. The document only focuses the BS initiated service flows. > > I think it is better to remove the paragraph in sec 2.2.1.3 to avoid > confusion. > >> 2) The term ACR is not defined in the document (and sorry) I don't know >> what does it mean. Do you intend to say AR?! > > AR is correct. > >> S5) >> Section 2.2.1.3 >> " >> However PHS (Packet Header Compression) >> " >> If you are referring the 802.16 PHS, shouldn't you state Payload Header >> Suppression. I suggest a rephrasing: >> When PHS (Payload Header Suppression) is deployed it mitigates this >> overhead through the compression of packet headers. >> > > It seems to be fine with me. > >> >> S6) >> Section 2.2.1.4 >> " >> Therefore, no routing protocols are needed on the MS. >> " >> Just for clarification. This sentence also applies when the MS has a >> network behind it? The default routes are enough in such cases? > > That's good point. > > In sec 2.2.1.4, we should consider the case - the MS has a > network behind it, too. We'll rephrase it and add this case. > >> >> S7) >> Section 2.2.1.5 >> " >> Also, IEEE 802.16g which is ... >> " >> I would add an informative reference regarding 802.16g. It is missing! > > I'll add it. > >> >> " >> convergence sublayers [I-D.iab-link-encaps], the mobile access >> scenarios need solutions about how roaming will work when forced to >> move from one CS to another. >> " >> Just for clarification. I would add an example of the CS roaming >> (e.g. from >> IPv4 CS to Ethernet CS). > > Ok. e.g., IPv6 CS to Ethernet CS > >> >> S8) >> Section 2.2.2.1 >> The text in this section refers that MS, AR, and ER should support IPv6. >> The S2 applies also here. >> And the Ethernet Bridge should also support IPv6 to build the >> authoritative >> address cache (as referenced in section 2.2.2.3). >> " >> The bridge builds its authoritative address cache by parsing the IPv6 >> Neighbor Discovery messages used during address configuration (DAD). >> " >> I think in this section there should be a reference to the required IPv6 >> support by the Ethernet Bridge. > > Right, I'll update it. > >> S9) >> Section 2.4 >> " >> The QoS has different semantics with IP QoS >> " >> I suggest to change this sentence: >> The 802.16 supported QoS has different semantics from IP QoS. > > Ok. > >> >> S10) >> Section 2.6 >> I think this section does not fulfill the intended purpose. It does not >> refer how to make IPv6 Network Management. >> And besides this, I think there should be a reference to the 802.16f >> the >> amendment that includes the management information base for IEEE 802.16 >> networks. > > Ok, I'll try to rephase it and add the reference. > > Thanks for your valuable comments. > Myung-Ki, > _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Tue Jan 30 02:54:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnoV-0006u2-Rn; Tue, 30 Jan 2007 02:53:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBnoU-0006tx-5X for 16ng@ietf.org; Tue, 30 Jan 2007 02:53:58 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBnoR-0000XM-Mj for 16ng@ietf.org; Tue, 30 Jan 2007 02:53:58 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCO00DTZ8HNT3@szxga04-in.huawei.com> for 16ng@ietf.org; Tue, 30 Jan 2007 15:51:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCO0012Y8HLF8@szxga04-in.huawei.com> for 16ng@ietf.org; Tue, 30 Jan 2007 15:51:23 +0800 (CST) Received: from z49950 ([10.121.32.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCO00HQW8HHZQ@szxml04-in.huawei.com> for 16ng@ietf.org; Tue, 30 Jan 2007 15:51:21 +0800 (CST) Date: Tue, 30 Jan 2007 15:51:17 +0800 From: "John.zhao" To: "'Riegel, Maximilian'" Message-id: <004a01c74443$6cd207f0$6520790a@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdEQ2xWVR4qvH0PQ2WzdkPSro1SKQ== X-Spam-Score: 0.2 (/) X-Scan-Signature: 92abeebc7b3c56bc274d8238a52368c9 Cc: 16ng@ietf.org Subject: [16NG] review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00 X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com 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="===============0164610254==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============0164610254== Content-type: multipart/alternative; boundary="Boundary_(ID_QYUdKZhtlRya0bhnfK7mFA)" This is a multi-part message in MIME format. --Boundary_(ID_QYUdKZhtlRya0bhnfK7mFA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Max, In section 7.3, there is a sentence that 'The unicast IPv4 addresses can be learned by examining the source address of packets or DHCP Response message.' But why this operation is needed? And if we will need the layer-3 operation in this place? Best Rgds, Thanks, John.zhao --Boundary_(ID_QYUdKZhtlRya0bhnfK7mFA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Max,

 

         In section 7.3, there is a sentence that ‘The unicast IPv4 addresses can be learned by examining the source address of packets or DHCP Response message.’ But why this operation is needed? And if we will need the layer-3 operation in this place?

         Best Rgds,

Thanks,

 

 

 

 

 

         John.zhao

--Boundary_(ID_QYUdKZhtlRya0bhnfK7mFA)-- --===============0164610254== 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 --===============0164610254==-- From 16ng-bounces@ietf.org Tue Jan 30 13:56:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy9I-0008LY-5G; Tue, 30 Jan 2007 13:56:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBy9G-0008LD-Kq for 16ng@ietf.org; Tue, 30 Jan 2007 13:56:06 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBy8s-0001us-DX for 16ng@ietf.org; Tue, 30 Jan 2007 13:56:06 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id l0UItYh6008059; Tue, 30 Jan 2007 19:55:34 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id l0UItY20002415; Tue, 30 Jan 2007 19:55:34 +0100 Received: from MCHP7I6A.ww002.siemens.net ([139.25.131.137]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 19:55:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 19:55:33 +0100 Message-ID: <4BB931F00625F54DA8B8563E5A5CA25A01347208@MCHP7I6A.ww002.siemens.net> In-Reply-To: <004a01c74443$6cd207f0$6520790a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00 Thread-Index: AcdEQ2xWVR4qvH0PQ2WzdkPSro1SKQAW1m7Q From: "Riegel, Maximilian" To: X-OriginalArrivalTime: 30 Jan 2007 18:55:33.0875 (UTC) FILETIME=[389F0430:01C744A0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 089da5e32269fece1072c9ff54523f20 Cc: 16ng@ietf.org Subject: [16NG] RE: review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00 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="===============2099657250==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============2099657250== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C744A0.3840163F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C744A0.3840163F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi John.zhao, =20 ProxyARP must know about the IP addresses being used by the SS/MSs. The information can be retrieved by intercepting the DHCP message exchange or just looking at the source IP addresses of upstream packets. =20 With this information Proxy ARP can respond to ARP messages instead of broadcasting the message to all the SS/MSs. =20 Bye Max ________________________________ From: John.zhao [mailto:john.zhao@huawei.com]=20 Sent: Tuesday, January 30, 2007 8:51 AM To: Riegel, Maximilian Cc: 16ng@ietf.org Subject: review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00 Hi Max, =20 In section 7.3, there is a sentence that 'The unicast IPv4 addresses can be learned by examining the source address of packets or DHCP Response message.' But why this operation is needed? And if we will need the layer-3 operation in this place? Best Rgds, Thanks, =20 =20 =20 =20 =20 John.zhao ------_=_NextPart_001_01C744A0.3840163F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi John.zhao,
 
ProxyARP must know about the IP addresses being = used by the=20 SS/MSs. The information can be retrieved by intercepting the DHCP = message=20 exchange or just looking at the source IP addresses of upstream=20 packets.
 
With this information Proxy ARP can respond to = ARP messages=20 instead of broadcasting the message to all the = SS/MSs.
 
Bye
Max

From: John.zhao = [mailto:john.zhao@huawei.com]=20
Sent: Tuesday, January 30, 2007 8:51 AM
To: Riegel, = Maximilian
Cc: 16ng@ietf.org
Subject: review of=20 draft-ietf-16ng-ip-over-ethernet-over-802.16-00

Hi=20 Max,

 

        =20 In section 7.3, there is a sentence that ‘The unicast=20 IPv4 addresses can be learned by examining the source address of packets = or DHCP=20 Response message.’ But why this = operation is needed?=20 And if we will need the layer-3 operation in this=20 place?

        =20 Best Rgds,

Thanks,

 

 

 

 

 

        =20 John.zhao

------_=_NextPart_001_01C744A0.3840163F-- --===============2099657250== 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 --===============2099657250==-- From 16ng-bounces@ietf.org Tue Jan 30 19:56:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3mB-0001sE-1x; Tue, 30 Jan 2007 19:56:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC3m9-0001s8-FE for 16ng@ietf.org; Tue, 30 Jan 2007 19:56:37 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC3m6-0004Ps-G1 for 16ng@ietf.org; Tue, 30 Jan 2007 19:56:37 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCP00CFAJX4EM@szxga02-in.huawei.com> for 16ng@ietf.org; Wed, 31 Jan 2007 08:55:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JCP004QOJX1F2@szxga02-in.huawei.com> for 16ng@ietf.org; Wed, 31 Jan 2007 08:55:52 +0800 (CST) Received: from z49950 ([10.121.32.101]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCP00320JWYGH@szxml04-in.huawei.com> for 16ng@ietf.org; Wed, 31 Jan 2007 08:55:49 +0800 (CST) Date: Wed, 31 Jan 2007 08:55:42 +0800 From: "John.zhao" In-reply-to: <4BB931F00625F54DA8B8563E5A5CA25A01347208@MCHP7I6A.ww002.siemens.net> To: "'Riegel, Maximilian'" Message-id: <002d01c744d2$8b87eb30$6520790a@china.huawei.com> Organization: Huawei Technologies Co., LTD. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcdEQ2xWVR4qvH0PQ2WzdkPSro1SKQAW1m7QAAyuBBA= X-Spam-Score: 0.2 (/) X-Scan-Signature: c307e466c5fb8dd2974e846d3b474c9f Cc: 16ng@ietf.org Subject: [16NG] RE: review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00 X-BeenThere: 16ng@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: john.zhao@huawei.com 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="===============1175985619==" Errors-To: 16ng-bounces@ietf.org This is a multi-part message in MIME format. --===============1175985619== Content-type: multipart/alternative; boundary="Boundary_(ID_Ih7YXEkPrzb58YQdrC2iFQ)" This is a multi-part message in MIME format. --Boundary_(ID_Ih7YXEkPrzb58YQdrC2iFQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hello Max =20 Thanks. From your explain, you mentioned two method can be used = to know about the IP addresses:=20 1) Intercepting the DHCP message exchange; =20 2)Just looking at the source IP addresses of upstream packets. To the method 1) , it will need DHCP stack to do that.=20 As to the method 2) ,if that means we have to monitor the source IP = address of every packets. Otherwise , we can make sure when the MS/SS change = it=A1=AFs address.=20 Right? =20 Best Rgds, Thanks, =20 _____ =20 =B7=A2=BC=FE=C8=CB: Riegel, Maximilian = [mailto:maximilian.riegel@siemens.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA1=D4=C231=C8=D5 2:56 =CA=D5=BC=FE=C8=CB: john.zhao@huawei.com =B3=AD=CB=CD: 16ng@ietf.org =D6=F7=CC=E2: RE: review of = draft-ietf-16ng-ip-over-ethernet-over-802.16-00 =20 Hi John.zhao, =20 ProxyARP must know about the IP addresses being used by the SS/MSs. The information can be retrieved by intercepting the DHCP message exchange = or just looking at the source IP addresses of upstream packets. =20 With this information Proxy ARP can respond to ARP messages instead of broadcasting the message to all the SS/MSs. =20 Bye Max =20 _____ =20 From: John.zhao [mailto:john.zhao@huawei.com]=20 Sent: Tuesday, January 30, 2007 8:51 AM To: Riegel, Maximilian Cc: 16ng@ietf.org Subject: review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00 Hi Max, =20 In section 7.3, there is a sentence that =A1=AEThe unicast IPv4 addresses can be learned by examining the source address of packets or = DHCP Response message.=A1=AF But why this operation is needed? And if we will = need the layer-3 operation in this place? Best Rgds, Thanks, =20 =20 =20 =20 =20 John.zhao --Boundary_(ID_Ih7YXEkPrzb58YQdrC2iFQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

H= ello Max

<= o:p> 

&= nbsp;        Thanks. From your explain, you mentioned two method can be used to know = about the IP addresses:

1) Intercepting the DHCP message exchange;  

2)Just looking at the source IP addresses = of upstream packets.

&= nbsp;        To the method 1) , it will need DHCP stack to do that. =

As to the method 2) ,if that means we have to monitor = the source IP address of every packets. Otherwise , we can make sure when = the MS/SS change it=A1=AFs address.

Right?

         =

Best Rgds,

T= hanks,

<= o:p> 

=B7=A2= =BC=FE=C8=CB: Riegel, Maximilian [mailto:maximilian.riegel@siemens.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2007=C4=EA1=D4=C231=C8=D5 = 2:56
=CA=D5=BC=FE=C8=CB: john.zhao@huawei.com
=B3=AD=CB=CD: 16ng@ietf.org
=D6=F7=CC=E2: RE: review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00

 

Hi John.zhao,

 

ProxyARP must know about the IP = addresses being used by the SS/MSs. The information can be retrieved by = intercepting the DHCP message exchange or just looking at the source IP addresses of = upstream packets.

 

With this information Proxy ARP = can respond to ARP messages instead of broadcasting the message to all the = SS/MSs.

 

Bye

Max

 

From: John.zhao [mailto:john.zhao@huawei.com]
Sent: Tuesday, January = 30, 2007 8:51 AM
To: Riegel, = Maximilian
Cc: 16ng@ietf.org
Subject: review of draft-ietf-16ng-ip-over-ethernet-over-802.16-00

Hi = Max,

 =

     = ;    In section 7.3, there is a sentence that =A1=AEThe = unicast IPv4 addresses can be learned by examining the source address of packets or DHCP Response = message.=A1=AF But why this operation is needed? And if we will need the layer-3 = operation in this place?

     = ;    Best Rgds,

Thanks,

 

 

 

 

 

     = ;    John.zhao

--Boundary_(ID_Ih7YXEkPrzb58YQdrC2iFQ)-- --===============1175985619== 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 --===============1175985619==-- From 16ng-bounces@ietf.org Wed Jan 31 08:30:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFX7-0000oZ-PX; Wed, 31 Jan 2007 08:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFX6-0000jf-8g for 16ng@ietf.org; Wed, 31 Jan 2007 08:29:52 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFX3-0005wQ-QZ for 16ng@ietf.org; Wed, 31 Jan 2007 08:29:52 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3BBB71986AF; Wed, 31 Jan 2007 15:29:49 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F26671986AD; Wed, 31 Jan 2007 15:29:48 +0200 (EET) Message-ID: <45C099CD.8010506@piuha.net> Date: Wed, 31 Jan 2007 15:29:49 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Basavaraj Patil , Pekka Savola Subject: Re: [16NG] FW: Review of the ipv6-over-ipv6cs draft References: <45BDFD58.8060202@piuha.net> In-Reply-To: <45BDFD58.8060202@piuha.net> 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: 10d3e4e3c32e363f129e380e644649be 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, Some thoughts on the substantive points raised by Pekka's review: > 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? > I believe there are generic issues such as port scanning that may be best handled elsewhere. This document should be free to address the specific IP layer issues, however. (Not commenting on what the solution is, however, or the lack of a solution for some of these things. But all-nodes address in the recommended link scope does not appear to be a problem.) > There seem to be some technical problems (e.g., GRE tunnel multiplexing, > different MTU recommendation) with Appendices and an issue of > clarity why the appendices are there to begin with. > I am getting the sense that removing the Wimax-specific discussion is the right thing. In addition, your comments regarding GRE multiplexing should be taken into account in the Wimax work. Basavaraj works in Wimax Forum, I'm sure he can bring that issue up there. > It is not clear if traffic classification is adequately specified (or is > it specified elsewhere?) and some miscellaneous issues. > Specified elsewhere. This needs to be made clearer. > substantial > ----------- > > ==> looking at the other "IPv6 over foo" documents, this document doesn't > specify or mention the following: > - link-local address generation (exactly as described in RFC2464, I > suppose?) > - unicast and multicast address mapping > > Maybe these don't require much text but an explicit note might be a good > thing to have. > Yes. > Hence the point-to-point link model > for IPv6 operation over the IP specific part of the Packet CS in > 802.16 is recommended. A unique IPv6 prefix(es) per link (MS) is > also recommended. > > ==> you don't discuss what will happen if these recommendations are not > followed, in fact, the whole document assumes they are adhered to. Either > this should be discussed or the recommendations should be made stronger > (requirements). > They should be requirements. > 6.3. Maximum transmission unit in 802.16 > > [...] The Max value of the IPv6 MTU for 802.16 is 2038 > bytes and the minimum value of 1280 bytes. The default MTU for IPv6 > over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 > octets. RFC2461 defines an MTU option that an AR can advertise to an > MN. If an AR advertises an MTU via the RA MTU option, the MN should > use the MTU from the RA. > > ==> Should the last sentence use uppercase keywords? > ==> 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. > This should be made clear in the text -- perhaps with appropriate warning label that discourages such usage. (If Wimax Forum wants to do that due to the MTU of the backend tunnels, it would be their conscious choice.) Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 08:30:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFXT-0000wR-4s; Wed, 31 Jan 2007 08:30:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCFXR-0000wI-TG for 16ng@ietf.org; Wed, 31 Jan 2007 08:30:13 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCFXO-000649-UV for 16ng@ietf.org; Wed, 31 Jan 2007 08:30:13 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2736D1986AF; Wed, 31 Jan 2007 15:30:10 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C2B031986AD; Wed, 31 Jan 2007 15:30:09 +0200 (EET) Message-ID: <45C099E1.2020002@piuha.net> Date: Wed, 31 Jan 2007 15:30:09 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Margaret Wasserman , Basavaraj Patil Subject: Re: [16NG] Review of draft-ietf-16ng-ipv6-over-ipv6cs-07.txt References: <45B65399.4000707@piuha.net> <6055E634-B45E-4E11-93E2-133B549D0CF3@thingmagic.com> In-Reply-To: <6055E634-B45E-4E11-93E2-133B549D0CF3@thingmagic.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: 343d06d914165ffd9d590a64755216ca 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 Margaret, Basavaraj, First, thank you Margaret for your review! I talked to the chairs and Basavaraj, and they will revise the document according to your and Pekka's comments. Please find some observations inline wrt to the biggest substantial comments. > > EDIT: This document would, IMO, benefit greatly from the inclusion of > RFC 2119 language to make it clear what is actually being specified. > There are a fairly large number of places where loose language is used > to talk about existing IPv6 functionality, and it is not always clear > whether that information is being included for reference purposes, or > if this document is intending to change (or at least loosen the > requirements) for those parts of IPv6. Yes, the same feedback has been received from different reviewers. The draft needs to make clear what its requirements are. > > The packet CS is used for transport for all packet-based > protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) > and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS > enables transport of IPv6 packets directly over the MAC. This > document specifies the addressing and operation of IPv6 over the IPv6 > specific part of the packet CS for hosts served by a network that > utilizes the IEEE Std 802.16 air interface. > > SUBS: There seems to be some confusion here about whether the IEEE > has defined an IP-specific CS (presumably for both IPv4 and IPv6) or > an IPv6-specific CS. Which is correct? > > SUBS: Why is this document defining an IPv6 encapsulation and not > both an IPv4 and an IPv6 encapsulation? If they are defined > separately, where will you describe how a dual stack will work over > the convergence sublayer(s)? > This document is separate from the IPv4 part mainly to allow the issues to be worked on separately (and because in terms of timing, the IPv6 part is urgent). But I agree that the document should talk about dual stack. This is also required by the WG's charter. > Appendix A. WiMAX network architecture and IPv6 support . . . . . 15 > Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 16 > Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 17 > Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 17 > > SUBS: What is the purpose of including this WiMAX-specific > information in > the document? I am also getting now the sense that these parts have brought more confusion than clarity. It would be better to keep the main body of the document and deal with the Wimax aspects in Wimax documents -- using the capabilities defined in this document of course. For instance, the document allows routers to advertise a non-default MTU, which Wimax could use. > > The scope of this document is limited to IPv6 operation over the IP > specific part of the Packet CS only. It should be noted that > immediately after ranging (802.16 air interface procedure), the MS > and BS exchange their capability negotiation via REG-REQ and REG-RSP. > > SUBS: Need more explanation in order to understand what this means. > Also, > expand acronyms/abbreviations. Yes. The wording could also be changed to ensure that people understand REG-REQ is not a part of this spec, it exists in 802.16. For instance, "As specified in [...], ...". In any case, the text is there only to explain how the capability negotiation of CSes happens. > > Additionally during the establishment of the > transport connection for transporting IPv6 packets, the DSA-REQ and > DSA-RSP messages between the BS and MS indicate via the CS- > Specification TLV the CS that the connection being setup shall use. > When the IPv6 packet is encapsulated by the 802.16 six byte MAC > header there is no specific indication in the MAC header itself about > the payload type. The processing of the packet is based entirely on > the classifiers. > > SUBS: Does this indicate that IPv4 and IPv6 would need to run over > separate > 802.16 connections? Or that they would run over a single connection? Separate, I believe, but this needs to spelled out. > Transmission of IPv6 as explained above is possible via multiple > methods, i.e, via the IP specific part of the packet CS or via > Ethernet or 802.1Q interfaces. The choice of which method to use is > implementation specific. In order to ensure interoperability the BS > should at least support both the IP specific part of the packet CS > and the Ethernet specific part of the packet CS for IPv6 transport. > > SUBS: I think we need something stronger than a lowercase should here. > In order to assure interoperability, this specification must make it > clear what each side is required to implement in order to be compliant > with > this spec. Right. > > For transmission of IPv6 packets via the IP specific part of the > Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC > directly. The IPv6 layer delivers the IPv6 packet to the Packet CS > of the 802.16. The packet CS defines a set of classifiers that are > used to determine how to handle the packet. The IP classifiers that > are used at the MAC operate on the fields of the IP header and the > transport protocol and these include the IP Traffic class, Next > > SUBS: Why include the traffic class and not the entire IPv6 Flow Label > field? The 802.16 specification determines how the classifers work. We cannot change that (but we are setting up a review with IEEE that would detect differences, if any.) > > header field, Masked IP source and destination addresses and, > > SUBS: Will the classifier walk any chained IPv6 headers and use the next > header field that corresponds to the upper layer protocol? Or the next > header field in the main IPv6 header? > > SUBS: How/why are the source and dest addresses masked? > > Protocol source and destination port ranges. Using the classifiers, > > SUBS: What does the classifier use for source/dest ports if the packet > is encrypted? These are good questions, but I believe they should be subject for the relevant IEEE specifications. The document should make it clear that it does not claim to provide normative rules for the classification process. > > When an AR and a BS are collocated, the collection of Transport > Connections to an MS is defined as a single link. When an AR and a > BS are separated, it is recommended that a tunnel is established > between the AR and a BS whose granuality is no greater than 'per MS' > or 'per service flow' ( An MS can have multiple service flows which > are identified by a service flow ID). Then the tunnel(s) for an MS, > in combination with the MS's Transport connections, forms a single > point-to-point link. > > SUBS: If this is only recommended, what are the other options and how > would IPv6 be supported over them? From the rest of the discussion, it > appears that this is required, not recommended. > Indeed. This should be changed to a normative requirement. > The collection of service flows (tunnels) to an MS is defined as a > single link. Each link has only an MS and an AR. Each MS belongs to > a different link. A different prefix should be assigned to each > unique link. This link is fully consistent with a standard IP link, > without exception and conforms with the definition of a point-to- > point link in RFC2461 [RFC2461]. Hence the point-to-point link model > for IPv6 operation over the IP specific part of the Packet CS in > 802.16 is recommended. A unique IPv6 prefix(es) per link (MS) is > also recommended. > > SUBS: Should we make it clear that this prefix should be no longer than > a /64, in order to provide full support for the features of IPv6? Yes. > > 6. The AR sends a router advertisement to the MS. Alternatively or > in addition, the MS can also send a router solicitation. > > SUBS: The AR and MS should send router advertisements and solicitations > as specified in the Neighbor Discovery specification. If it is not your > intent to change that, I would put a pointer here instead of the wording > that is currently included. Right. > > The 802.16 MAC PDU (Protocol Data Unit) is composed by a 6 byte > header followed by an optional payload and an optional CRC covering > the header and the payload. The length of the PDU is indicated by > the Len parameter in the Generic MAC HDR. The Len parameter has a > size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6 > payload can be a max value of 2038 bytes ( Total PDU size minus (MAC > Header + CRC)). The Max value of the IPv6 MTU for 802.16 is 2038 > bytes and the minimum value of 1280 bytes. The default MTU for IPv6 > over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 > octets. > > SUBS: It is unclear what you are specifying here. We don't get to > declare a default value for the 802.16 MTU. One of two things seems to > be true here, and I don't have enough information to know which one: > the MTU of 802.16 networks is 2038 bytes, or the MTU for 802.16 network > is configurable between 1280 and 2038 bytes. > The latter was the intent, I believe. Text should change. > RFC2461 defines an MTU option that an AR can advertise to an > MN. If an AR advertises an MTU via the RA MTU option, the MN should > use the MTU from the RA. > > SUBS: Even if it is greater than 2038 or less than 1280 bytes? > No -- should be noted. > > 8.3. Router lifetime and periodic router advertisements > > The router lifetime should be set to a large value, preferably in > hours. This document over-rides the specification for the value of > the router lifetime in RFC2461 [RFC2461]. The AdvDefaultLifetime in > the router advertisement MUST be either zero or between > MaxRtrAdvInterval and 43200 seconds. The default value is 2 * > MaxRtrAdvInterval. > > 802.16 hosts have the capability to transition to an idle mode in > which case the radio link between the BS and MS is torn down. Paging > is required in case the network needs to deliver packets to the MS. > In order to avoid waking a mobile which is in idle mode and consuming > resources on the air interface, the interval between periodic router > advertisements should be set quite high. The MaxRtrAdvInterval value > specified in this document over-rides the recommendation in RFC2461 > [RFC2461]. The MaxRtrAdvInterval MUST be no less than 4 seconds and > no greater than 21600 seconds. The default value for > MaxRtrAdvInterval is 10800 seconds. > > SUBS: I would like to see some exploration of what the impact of these > changes would be on IPv6 operations. Are there other mechanisms that > are used in 802.16 for black-hole detection and/or detecting when a > network connection has been lost? There may be L2 mechanisms, but I'm not sure if that guarantees reachability all the way to the router. > > 9.3. Stateless address autoconfiguration > > If the A-bit in the prefix information option (PIO) is set, the MS > performs stateless address autoconfiguration as per RFC 2461, 2462. > The AR is the default router that advertises a unique prefix (or > prefixes) that is used by the MS to configure an address. > > 9.4. Stateful address autoconfiguration > > The Stateful Address Autoconfiguration is invoked if the M-flag is > set in the Router Advertisement. Obtaining the IPv6 address through > stateful address autoconfiguration method is specified in RFC3315 > [RFC3315]. > > SUBS: In both of the previous two sections, is this any different from > standard IPv6? If so, spell out what is changed. If not, why include > these sections? Previous proposals included mechanisms that changed the way address autoconfiguration worked, for instance. I think it is useful to state that ND operates as specified in IPv6. But it may be that these sections have too many words. > > This document does not introduce any new vulnerabilities to IPv6 > specifications or operation. The security of the 802.16 air > interface is the subject of [802.16]. In addition, the security > issues of the network architecture spanning beyond the 802.16 base > stations is the subject of the documents defining such architectures, > such as WiMAX Network Architecture [WiMAXArch]. > > SUBS: I am not sure that this is correct. I am not clear on how 802.16 > packet classification is consistent with encrypted upper-layer headers. I do not think this is any different on packet classification on firewalls, for instance. The information that is available is used, not more... --Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 09:05:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG5l-0001wv-8m; Wed, 31 Jan 2007 09:05:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCG5j-0001wp-Ii for 16ng@ietf.org; Wed, 31 Jan 2007 09:05:39 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCG5i-0000lc-5c for 16ng@ietf.org; Wed, 31 Jan 2007 09:05:39 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1170252336!1032120!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 22467 invoked from network); 31 Jan 2007 14:05:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 31 Jan 2007 14:05:36 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0VE5TJO010496; Wed, 31 Jan 2007 07:05:29 -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 l0VE5SxO023179; Wed, 31 Jan 2007 08:05:28 -0600 (CST) Message-ID: <45C0A227.1040303@motorola.com> Date: Wed, 31 Jan 2007 15:05:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: traffic classification (was: [16NG] FW: Review of the ipv6-over-ipv6cs draft) References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> In-Reply-To: <45C099CD.8010506@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Jari Arkko wrote: > Hi, > > Some thoughts on the substantive points raised by Pekka's review: [...] >> It is not clear if traffic classification is adequately specified >> (or is it specified elsewhere?) and some miscellaneous issues. >> > > Specified elsewhere. This needs to be made clearer. I think it _may_ be relevant here. IPv6 has a Traffic Class field with defined values (see rfc2474 for 6bit DSCP, and rfc2597 for AF Assured Forwarding values). 802.16 has Service Class service flow encodings (11.13.4 in 802.16-1004). The mapping between the two should be specified here I believe. Basically one would need to define mappings between DSCPs and 802.16 Service Flow encodings. Remark the mapping is not straightforward because DSCP uses 6bit while service field is on 4bit. But not all values from 6bit need to be encoded either. I think 802.16 spec doesn't define these mappings. Although they do define filter in the CS that interprets the IPv6 Traffic Class field. I think we need advice from QoS community on this. Alex > >> substantial ----------- >> >> ==> looking at the other "IPv6 over foo" documents, this document >> doesn't specify or mention the following: - link-local address >> generation (exactly as described in RFC2464, I suppose?) - unicast >> and multicast address mapping >> >> Maybe these don't require much text but an explicit note might be a >> good thing to have. >> > > Yes. > >> Hence the point-to-point link model for IPv6 operation over the IP >> specific part of the Packet CS in 802.16 is recommended. A unique >> IPv6 prefix(es) per link (MS) is also recommended. >> >> ==> you don't discuss what will happen if these recommendations are >> not followed, in fact, the whole document assumes they are adhered >> to. Either this should be discussed or the recommendations should >> be made stronger (requirements). >> > > They should be requirements. > >> 6.3. Maximum transmission unit in 802.16 >> >> [...] The Max value of the IPv6 MTU for 802.16 is 2038 bytes and >> the minimum value of 1280 bytes. The default MTU for IPv6 over >> 802.16 SHOULD be the same as specified in RFC2460 which is 1500 >> octets. RFC2461 defines an MTU option that an AR can advertise to >> an MN. If an AR advertises an MTU via the RA MTU option, the MN >> should use the MTU from the RA. >> >> ==> Should the last sentence use uppercase keywords? ==> 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. >> > > This should be made clear in the text -- perhaps with appropriate > warning label that discourages such usage. (If Wimax Forum wants to > do that due to the MTU of the backend tunnels, it would be their > conscious choice.) > > 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 Wed Jan 31 09:12:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGCZ-0005fl-QC; Wed, 31 Jan 2007 09:12:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGCY-0005fd-Or for 16ng@ietf.org; Wed, 31 Jan 2007 09:12:42 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCGCT-0002Si-PY for 16ng@ietf.org; Wed, 31 Jan 2007 09:12:42 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1170252756!4348019!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 7641 invoked from network); 31 Jan 2007 14:12:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 31 Jan 2007 14:12:36 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0VECaTW013209; Wed, 31 Jan 2007 07:12:36 -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 l0VECYCp014309; Wed, 31 Jan 2007 08:12:35 -0600 (CST) Message-ID: <45C0A3D2.50401@motorola.com> Date: Wed, 31 Jan 2007 15:12:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jari Arkko Subject: Re: traffic class (was: [16NG] Review of draft-ietf-16ng-ipv6-over-ipv6cs-07.txt) References: <45B65399.4000707@piuha.net> <6055E634-B45E-4E11-93E2-133B549D0CF3@thingmagic.com> <45C099E1.2020002@piuha.net> In-Reply-To: <45C099E1.2020002@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: > Margaret, Basavaraj, > > First, thank you Margaret for your review! I talked to the chairs and > Basavaraj, and they will revise the document according to your and > Pekka's comments. > > Please find some observations inline wrt to the biggest substantial > comments. [...] >> For transmission of IPv6 packets via the IP specific part of the >> Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC >> directly. The IPv6 layer delivers the IPv6 packet to the Packet CS >> of the 802.16. The packet CS defines a set of classifiers that are >> used to determine how to handle the packet. The IP classifiers >> that are used at the MAC operate on the fields of the IP header and >> the transport protocol and these include the IP Traffic class, Next >> >> >> >> SUBS: Why include the traffic class and not the entire IPv6 Flow >> Label field? > > The 802.16 specification determines how the classifers work. We > cannot change that (but we are setting up a review with IEEE that > would detect differences, if any.) I _think_ the 802.16 classifiers just list what are the fields in the IPv6 header that they understand. I _think_ the 802.16 CS classifiers don't know how to map the contained values, eg DSCP AF11 '001010' (rfc2597) into a 802.16 service field. I _think_ this mapping isn't specified in 802.16 spec. I think it should be specified here. I could formulate that as a question: how does the 802.16 MAC implementation map the DSCP AF11 into a service flow, what is the mapping? Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 09:16:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGGc-0008K0-Jy; Wed, 31 Jan 2007 09:16:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCGGa-0008Hv-KK for 16ng@ietf.org; Wed, 31 Jan 2007 09:16:52 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCGGZ-0003ql-7W for 16ng@ietf.org; Wed, 31 Jan 2007 09:16:52 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2C78D1986AF; Wed, 31 Jan 2007 16:16:50 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DEEE31986AE; Wed, 31 Jan 2007 16:16:49 +0200 (EET) Message-ID: <45C0A4D1.9010602@piuha.net> Date: Wed, 31 Jan 2007 16:16:49 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Alexandru Petrescu References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> In-Reply-To: <45C0A227.1040303@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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 16ng@ietf.org, Pekka Savola Subject: [16NG] Re: traffic classification 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 think it _may_ be relevant here. IPv6 has a Traffic Class field with > defined values (see rfc2474 for 6bit DSCP, and rfc2597 for AF Assured > Forwarding values). 802.16 has Service Class service flow encodings > (11.13.4 in 802.16-1004). The mapping between the two should be > specified here I believe. > > Basically one would need to define mappings between DSCPs and 802.16 > Service Flow encodings. Remark the mapping is not straightforward > because DSCP uses 6bit while service field is on 4bit. But not all > values from 6bit need to be encoded either. > > I think 802.16 spec doesn't define these mappings. Although they do > define filter in the CS that interprets the IPv6 Traffic Class field. Anyone who understands in detail what 802.16 classification does, feel free to jump in here... DJ? My assumption was that 802.16 defines a classification mechanism that can look at certain fields from IP packets and determine what service flow should be used, including all parameters used in the service flow. If this is not the case then you are right. Jari _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 10:37:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHWc-0001td-DG; Wed, 31 Jan 2007 10:37:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHWb-0001sf-7a for 16ng@ietf.org; Wed, 31 Jan 2007 10:37:29 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HCHWW-0007kx-OX for 16ng@ietf.org; Wed, 31 Jan 2007 10:37:29 -0500 Received: by nf-out-0910.google.com with SMTP id l36so582788nfa for <16ng@ietf.org>; Wed, 31 Jan 2007 07:37:23 -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=Vn/1/jsvw9srh8UlokDblcoxpJw9cI2WvdhuCqDfmO4CG8KDp1J3ZfWDYnUhW+jaYB6RDTlCDkJfL+U7VQqZMtuejoSOp/K0EcW91BKsstmvDitZ+i5tToJJl3kCJpvgiDc5gZfH0w+aYU2pGHMeNDw7obEANcx+PW8PLzvJOOg= Received: by 10.49.29.3 with SMTP id g3mr2684450nfj.1170257842208; Wed, 31 Jan 2007 07:37:22 -0800 (PST) Received: by 10.48.217.6 with HTTP; Wed, 31 Jan 2007 07:37:21 -0800 (PST) Message-ID: <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> Date: Thu, 1 Feb 2007 00:37:21 +0900 From: "JinHyeock Choi" To: "Jari Arkko" Subject: Re: [16NG] Re: traffic classification In-Reply-To: <45C0A4D1.9010602@piuha.net> 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> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 > > I think it _may_ be relevant here. IPv6 has a Traffic Class field with > > defined values (see rfc2474 for 6bit DSCP, and rfc2597 for AF Assured > > Forwarding values). 802.16 has Service Class service flow encodings > > (11.13.4 in 802.16-1004). The mapping between the two should be > > specified here I believe. > > > > Basically one would need to define mappings between DSCPs and 802.16 > > Service Flow encodings. Remark the mapping is not straightforward > > because DSCP uses 6bit while service field is on 4bit. But not all > > values from 6bit need to be encoded either. > > > > I think 802.16 spec doesn't define these mappings. Although they do > > define filter in the CS that interprets the IPv6 Traffic Class field. > > Anyone who understands in detail what 802.16 classification > does, feel free to jump in here... DJ? > > My assumption was that 802.16 defines a classification mechanism > that can look at certain fields from IP packets and determine what > service flow should be used, including all parameters used in the > service flow. If this is not the case then you are right. Classification is the process by which a MAC SDU (IPv6 packet in our case) is mapped onto a particular transport connection for transmission between MAC peers (BS and MS in our case). The mapping process associates an IPv6 packet with a transport connection and its CID (Connection Identifier). Classifiers are matching criteria applied to each packet and consist of some protocol-specific packet matching criteria such as destination IP address. If a packet matches the specified packet matching criteria (i.e. classifier(s)), it is then delivered to the SAP for delivery on the connection defined by the CID (Connection Identifier). You may find more detail in 5.2.2 of 802.16. I also put a figure in http://www.diffeo.com/16ng/fig.gif 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 Wed Jan 31 11:14:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI6O-0006XC-9a; Wed, 31 Jan 2007 11:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCI6N-0006Tj-6W for 16ng@ietf.org; Wed, 31 Jan 2007 11:14:27 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCI6L-0007yw-RJ for 16ng@ietf.org; Wed, 31 Jan 2007 11:14:27 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1170260064!1980506!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 25796 invoked from network); 31 Jan 2007 16:14:24 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-128.messagelabs.com with SMTP; 31 Jan 2007 16:14:24 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l0VGEK0B008582; Wed, 31 Jan 2007 09:14:20 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0VGEG5k007987; Wed, 31 Jan 2007 10:14:17 -0600 (CST) Message-ID: <45C0C057.5040402@motorola.com> Date: Wed, 31 Jan 2007 17:14:15 +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> In-Reply-To: <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@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: 244a2fd369eaf00ce6820a760a3de2e8 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: >>> I think it _may_ be relevant here. IPv6 has a Traffic Class >>> field with defined values (see rfc2474 for 6bit DSCP, and rfc2597 >>> for AF Assured Forwarding values). 802.16 has Service Class >>> service flow encodings (11.13.4 in 802.16-1004). The mapping >>> between the two should be specified here I believe. >>> >>> Basically one would need to define mappings between DSCPs and >>> 802.16 Service Flow encodings. Remark the mapping is not >>> straightforward because DSCP uses 6bit while service field is on >>> 4bit. But not all values from 6bit need to be encoded either. >>> >>> I think 802.16 spec doesn't define these mappings. Although they >>> do define filter in the CS that interprets the IPv6 Traffic Class >>> field. >> >> Anyone who understands in detail what 802.16 classification does, >> feel free to jump in here... DJ? >> >> My assumption was that 802.16 defines a classification mechanism >> that can look at certain fields from IP packets and determine what >> service flow should be used, including all parameters used in the >> service flow. If this is not the case then you are right. > > Classification is the process by which a MAC SDU (IPv6 packet in our > case) is mapped onto a particular transport connection for > transmission between MAC peers (BS and MS in our case). The mapping > process associates an IPv6 packet with a transport connection and its > CID (Connection Identifier). > > Classifiers are matching criteria applied to each packet and consist > of some protocol-specific packet matching criteria such as > destination IP address. If a packet matches the specified packet > matching criteria (i.e. classifier(s)), it is then delivered to the > SAP for delivery on the connection defined by the CID (Connection > Identifier). > > You may find more detail in 5.2.2 of 802.16. I also put a figure in > > http://www.diffeo.com/16ng/fig.gif > > Thanks for your kind consideration. 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? 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. Thanks, Alex _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 11:41:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCIWa-0003rA-Gu; Wed, 31 Jan 2007 11:41:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHyb-0000Em-Fz for 16ng@ietf.org; Wed, 31 Jan 2007 11:06:25 -0500 Received: from webmail.ee.ncu.edu.tw ([140.115.70.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHyS-0004av-3F for 16ng@ietf.org; Wed, 31 Jan 2007 11:06:25 -0500 Received: from ee.ncu.edu.tw (localhost [127.0.0.1]) by webmail.ee.ncu.edu.tw (8.13.4/8.13.1) with ESMTP id l0VGLCER036303; Thu, 1 Feb 2007 00:21:13 +0800 (CST) (envelope-from ywchen@ee.ncu.edu.tw) From: "yw_chen" To: "JinHyeock Choi" , "Jari Arkko" Subject: Re: [16NG] Re: traffic classification Date: Thu, 1 Feb 2007 00:21:12 +0800 Message-Id: <20070131161106.M971@ee.ncu.edu.tw> In-Reply-To: <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> References: <45BDFD58.8060202@piuha.net> <45C099CD.8010506@piuha.net> <45C0A227.1040303@motorola.com> <45C0A4D1.9010602@piuha.net> <92e919fb0701310737m45cbb6f8ud1dab68aa75f380d@mail.gmail.com> X-Mailer: Open WebMail 2.51 20050228 X-OriginatingIP: 220.139.159.79 (ywchen) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-Mailman-Approved-At: Wed, 31 Jan 2007 11:41:29 -0500 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 All, I am Yen-Wen Chen from Dept. of Communication Engineering, National Central University, Taiwan. As I know that the classifier in 802.16 is applied to match the network layer traffic (e.g. IP packets or IPv6 packets) into MAC flows of 802.16. Each MAC flow has a connection ID (CID) and is associated with a specific forwarding class (e.g. UGS, rtPS, nrtPS, ertPS, or best effort) and QoS-related parameters (e.g. delay time, loss rate, etc.). The mapping rules does not specify in the spec. and is decided in accordance with different applications. Packets with different IP Headers may be mapped to the same CID if those packets are with the same treatment in the link layer of 802.16. Yen-Wen On Thu, 1 Feb 2007 00:37:21 +0900, JinHyeock Choi wrote > > > I think it _may_ be relevant here. IPv6 has a Traffic Class field with > > > defined values (see rfc2474 for 6bit DSCP, and rfc2597 for AF Assured > > > Forwarding values). 802.16 has Service Class service flow encodings > > > (11.13.4 in 802.16-1004). The mapping between the two should be > > > specified here I believe. > > > > > > Basically one would need to define mappings between DSCPs and 802.16 > > > Service Flow encodings. Remark the mapping is not straightforward > > > because DSCP uses 6bit while service field is on 4bit. But not all > > > values from 6bit need to be encoded either. > > > > > > I think 802.16 spec doesn't define these mappings. Although they do > > > define filter in the CS that interprets the IPv6 Traffic Class field. > > > > Anyone who understands in detail what 802.16 classification > > does, feel free to jump in here... DJ? > > > > My assumption was that 802.16 defines a classification mechanism > > that can look at certain fields from IP packets and determine what > > service flow should be used, including all parameters used in the > > service flow. If this is not the case then you are right. > > Classification is the process by which a MAC SDU (IPv6 packet in our > case) is mapped onto a particular transport connection for > transmission between MAC peers (BS and MS in our case). The mapping > process associates an IPv6 packet with a transport connection and its > CID (Connection Identifier). > > Classifiers are matching criteria applied to each packet and consist > of some protocol-specific packet matching criteria such as > destination IP address. If a packet matches the specified packet > matching criteria > (i.e. classifier(s)), it is then delivered to the SAP for delivery > on the connection defined by the CID (Connection Identifier). > > You may find more detail in 5.2.2 of 802.16. I also put a figure in > > http://www.diffeo.com/16ng/fig.gif > > Thanks for your kind consideration. > > Best Regards > > JinHyeock > > _______________________________________________ > 16NG mailing list > 16NG@ietf.org > https://www1.ietf.org/mailman/listinfo/16ng -- Open WebMail Project (http://openwebmail.org) _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 12:25:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJCk-0006We-QT; Wed, 31 Jan 2007 12:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCJCi-0006TJ-1D for 16ng@ietf.org; Wed, 31 Jan 2007 12:25:04 -0500 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCJAv-00059F-55 for 16ng@ietf.org; Wed, 31 Jan 2007 12:23:15 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-5.tower-153.messagelabs.com!1170264191!370254!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 14484 invoked from network); 31 Jan 2007 17:23:11 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-153.messagelabs.com with SMTP; 31 Jan 2007 17:23:11 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l0VHN2IX027487; Wed, 31 Jan 2007 10:23:02 -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 l0VHN10w027981; Wed, 31 Jan 2007 11:23:01 -0600 (CST) Message-ID: <45C0D074.5080000@motorola.com> Date: Wed, 31 Jan 2007 18:23:00 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: yw_chen 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> <20070131161106.M971@ee.ncu.edu.tw> In-Reply-To: <20070131161106.M971@ee.ncu.edu.tw> Content-Type: text/plain; charset=Big5 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 Hi yw_chen, yw_chen wrote: > Dear All, > > I am Yen-Wen Chen from Dept. of Communication Engineering, National > Central University, Taiwan. As I know that the classifier in 802.16 > is applied to match the network layer traffic (e.g. IP packets or > IPv6 packets) into MAC flows of 802.16. Each MAC flow has a > connection ID (CID) and is associated with a specific forwarding > class (e.g. UGS, rtPS, nrtPS, ertPS, or best effort) and QoS-related > parameters (e.g. delay time, loss rate, etc.). The mapping rules does > not specify in the spec. and is decided in accordance with different > applications. I believe when 802.16 spec says 'in accordance with different applications' it means IP is one of those applications. I think both the 802.16MAC implementation _and_ the IPv6 stack should respect the same - unwritten - mapping rules. Otherwise my IPv6 stack on a vendor's 802.16MAC won't work on another vendor's. > Packets with different IP Headers may be mapped to the same CID if > those packets are with the same treatment in the link layer of > 802.16. I'm fine with that. But does IPv6 DSCP AF11 '001010' (rfc2597) map into 'UGS' or into 'Best Effort' forwarding class (802.16)? Which one do you like more? Which one is implemented? Alex PS: 802.16 terms: UGS - Unsolicited Grant Service rtPS - real-time Polling Services nrtPS - non-real-time Polling Services ertPS - ?? _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 16:54:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNP9-0005f7-9a; Wed, 31 Jan 2007 16:54:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNP7-0005f1-Rr for 16ng@ietf.org; Wed, 31 Jan 2007 16:54:09 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNP4-0003jH-1L for 16ng@ietf.org; Wed, 31 Jan 2007 16:54:09 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0VLp2Jc014967; Wed, 31 Jan 2007 23:51:11 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 23:53:41 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 15:53:38 -0600 Received: from 10.162.252.192 ([10.162.252.192]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 31 Jan 2007 21:53:38 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 31 Jan 2007 15:54:13 -0600 Subject: Re: [16NG] Review of draft-ietf-16ng-ipv6-over-ipv6cs-07.txt From: Basavaraj Patil To: Margaret Wasserman , <16ng@ietf.org> Message-ID: Thread-Topic: [16NG] Review of draft-ietf-16ng-ipv6-over-ipv6cs-07.txt Thread-Index: AcdFglghlnRrJrF1EduEiQARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 31 Jan 2007 21:53:38.0850 (UTC) FILETIME=[43C69020:01C74582] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9404aa2ccc871248c2288463bebdd6b9 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 Hi Margaret, Thanks for the review. My responses to your comments are prefixed with Raj> below: -Raj -------------------------- Hi All, I have a fairly large number of comments and questions on draft-ietf-16ng-ipv6-over-ipv6cs-07.txt. I have included them all below, hopefully with enough document context that you can tell what I am commenting about. Substantive issues are preceded by "SUBS:" and editorial issues are preceded by "EDIT:". IMO, this document needs some work, especially in the areas of organization and clarity, before it will be ready for publication. In some cases, I was not able to understand the document well-enough to determine what it is specifying. Thanks, Margaret --- EDIT: This document would, IMO, benefit greatly from the inclusion of RFC 2119 language to make it clear what is actually being specified. There are a fairly large number of places where loose language is used to talk about existing IPv6 functionality, and it is not always clear whether that information is being included for reference purposes, or if this document is intending to change (or at least loosen the requirements) for those parts of IPv6. Raj> Okay. Abstract IEEE Std 802.16 is an air interface specification. 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. EDIT: s/which the upper layers interface to/to which the upper layers interface. Raj> Agree. The packet CS is used for transport for all packet-based protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS enables transport of IPv6 packets directly over the MAC. This document specifies the addressing and operation of IPv6 over the IPv6 specific part of the packet CS for hosts served by a network that utilizes the IEEE Std 802.16 air interface. SUBS: There seems to be some confusion here about whether the IEEE has defined an IP-specific CS (presumably for both IPv4 and IPv6) or an IPv6-specific CS. Which is correct? Raj> IEEE 802.16 specifies two main convergence sublayers, ATM and Packet. The Packet CS supports IPv4, IPv6, 802.3 and 802.1Q. A set of classification rules are used to process upper layer packets and map them to a transport connection that is established for either IPv4, IPv6, 802.3 or 802.1Q . So to answer your question, there is not a specific IPv6 CS. Rather the packet CS using the classification rules that determine a packet is an IPv6 packet map it to a service flow and a transport connection that is established for carrying the IPv6 packet. The same packet CS with classification rules for IPv4 deal with IPv4 packets. I can add some text in the I-D to make this clear. But I believe that this is clear by virtue of referencing the 802.16 specification. SUBS: Why is this document defining an IPv6 encapsulation and not both an IPv4 and an IPv6 encapsulation? If they are defined separately, where will you describe how a dual stack will work over the convergence sublayer(s)? Raj> Because there is a separate I-D and WG goal to define the same for IPv4 as well. I dont know if the I-D has been posted yet, but I have seen a preliminary version of it. Operation of dual-stack over the packet CS and more specifically the IP specific part of the packet CS (i.e exclusing operation of dual stack over 802.3) is not in the scope of this I-D. This may be done in a separate document by the WG depending on the types of issues identified. At this time, I do not see any serious concerns about operating a dual-stack over the IP specific part of the packet CS. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated identifiers. ED: s/identifiers/interface identifiers. Raj> Okay. Appendix A. WiMAX network architecture and IPv6 support . . . . . 15 Appendix B. IPv6 link in WiMAX . . . . . . . . . . . . . . . . . 16 Appendix C. IPv6 link establishment in WiMAX . . . . . . . . . . 17 Appendix D. Maximum transmission unit in WiMAX . . . . . . . . . 17 SUBS: What is the purpose of including this WiMAX-specific information in the document? I realize that the WiMAX architecture is expected to make use of this mechanism, but I don't understand why we would want to put this WiMAX information here, where it is unnecessary and may become obsolete over time. Raj> The WiMAX specific part is in an appendix. The 802.16 air-interface is being adopted and deployed as WiMAX networks today. Hence from an applicability perspective it gives information about how the operation of IPv6 over 802.16 is utilized. IMO, this is useful information and given that it is in an appendix, it is only informative and does no harm. I am not sure I understand your concern about it being obsoleted. This is technology that is being built and deployed now and will exist for several years. I agree that as with everything else there will be evolution, but so will RFCs that are revised. 2. Introduction SUBS: Is there a short description we can borrow from the IEEE regarding what 802.16 is and what it intends to accomplish? It seems like this document would greatly benefit from a summary of 802.16 up front that can be referred to later. Raj> My intention was to avoid having to get into the details of 802.16 beyond the fact that it is an air-interface specification. The reference to the IEEE specification IMO is sufficient. But I have no problems in adding a paragraph with a brief explanation of 802.16. The problem is that everyone will have an opinion about what 802.16 intends to accomplish. All I can say about it is the fact that it is just another radio technology. IPv6 packets can be carried over the IEEE Std 802.16 specified air interface via either: SUBS: The document should be independent of the abstract, so you may want to repeat some of the abstract information here, rather than just jumping in. Also, shouldn't you define what IEEE Std 802.16 is and include a reference here, rather than in the next paragraph? Raj> Okay. I can do that. EDIT: I think that "either" is only used when there are exactly two choices, so s/either:/: 1. the IP specific part of the Packet CS or, 2. the 802.3 specific part of the Packet CS or, 3. the 802.1Q specific part of the Packet CS. Raj> Agreed. SUBS: You have not yet defined the acronym CS. Also, all of these technologies need references. Raj> It is in the abstract itself. "IEEE has specified several service specific convergence sublayers (CS)..." When you say technologies, I am not sure what you mean. Basically the technology being referenced here is 802.16. The terminology of CS, SF (service flow), CID etc. are all part of 802.16 and the terminology is intended to be included in the next rev of the problem-specification (PSDOC). The terminology that will be included in the PSDOC is in the email: http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html The 802.16 [802.16] specification includes the Phy and MAC details. EDIT: You should define the abbreviations Phy and MAC before using them. Raj> Okay. The convergence sublayers are a part of the MAC. This document specifies IPv6 from the perspective of the transmission of IPv6 over the IP specific part of the packet convergence sublayer. The mobile EDIT: Paragraph break? Raj> Yes. station/host is attached to an access router via a base station (BS). The host and the BS are connected via the IEEE Std 802.16 air interface at the link and physical layers. The IPv6 link from the MS terminates at an access router which may be a part of the BS or an entity beyond the BS. The base station is a layer 2 entity (from the perspective of the IPv6 link between the MS and AR) and relays the IPv6 packets between the AR and the host via a point-to-point connection over the air interface. EDIT: If the text below is retained, it should be a separate paragraph. Raj> Okay. The WiMAX (Worldwide Interoperability for Microwave Access) forum [WMF] has defined a network architecture in which the air interface is based on the IEEE 802.16 standard. The addressing and operation of IPv6 described in this document is applicable to the WiMAX network as well. The various aspects of IPv6 over 802.16 as applicable to WiMAX are captured in the appendix sections of this document. SUBS: Why is this needed in the document? Are we defining IPv6 over the IEEE 802.16 IP CS exclusively for WiMAX? If not, I think we should avoid any indication that this specification is somehow WiMAX-specific. Raj> The specification is intended to be generic. It is also a fact that this specification will be the basis for IPv6 operation in WiMAX networks and the networking group in WiMAX forum is referencing this specification. Mentioning the above fact IMO does no harm. But if you think this is a serious concern, I can simply mention this in the Appendix. 3. Terminology The terminology in this document is based on the definitions in [PSDOC], in addition to the ones specified in this section. Access Service Network (ASN) - The ASN is defined as a complete set of network functions needed to provide radio access to a WiMAX subscriber. The ASN is the access network to which the MS attaches. The IPv6 access router is an entity within the ASN. The term ASN is specific to the WiMAX network architecture. SUBS: Same question on whether this document is WiMAX-specific. Also, it is not clear to me that this term is actually needed to understand or implement this specification. Raj> I agree that the term ASN can be moved to the appendix since it is applicable only in that context. Will remove it from the main body of the text. 4. IEEE 802.16 convergence sublayer support for IPv6 The figure below shows the options for IPv6 transport over the packet CS of 802.16: ----------------- ----------------- | IPv6 | | IPv6 | ---------------- |---------------| |----------- | | IPv6 | | Ethernet | | 802.1Q | |--------------| |---------------| |----------- | | IP Specific | | 802.3 specific| |802.1Q specific| |part of Pkt CS| |part of Pkt CS | |part of Pkt CS | |..............| |...............| |...............| | MAC | | MAC | | MAC | |--------------| |---------------| |---------------| | PHY | | PHY | | PHY | ---------------- ----------------- ----------------- (1) IPv6 over (2) IPv6 over (3) IPv6 over IP Specific part 802.3/Ethernet 802.1Q of Packet CS Figure 2: IPv6 over IP, 802.3 and 802.1Q specific parts of the Packet CS EDIT: Include an informative pointer to the I6ng WG document that defines IP(v4 & v6) over the Ethernet CS? Raj> Okay. The scope of this document is limited to IPv6 operation over the IP specific part of the Packet CS only. It should be noted that immediately after ranging (802.16 air interface procedure), the MS and BS exchange their capability negotiation via REG-REQ and REG- RSP. SUBS: Need more explanation in order to understand what this means. Also, expand acronyms/abbreviations. Raj> I can add additional text to explain this. But the explanation of ranging and capability exchange via 802.16 MAC messages (REG-REQ/REG-RSP) are in the 802.16 spec. I can mention the reference here again. Let me propose some additional text and see if it clarifies the above paragraph further to a reader who may not have an understanding of .16. However an implementer will need to know a certain extent 802.16 details and hence the reference to 802.16 should be normative as you have suggested as well. These management frames negotiate parameters such as the Convergence Sublayer support. By default, Packet, IPv4 and 802.3/Ethernet are supported. IPv6 via the Packet CS is supported by the MS and the BS only when the bit specifying such support is indicated in the parameter "Classification/PHS options and SDU encapsulation support" (Refer to [802.16]). SUBS: It is not clear what this means. Which entities negotiate IPv6 support using what mechanisms? Raj> Hmmm... Let me see if I can do a better job of explaining this paragraph. Will provide new text for this. Basically what I am trying to say is that 802.16 MAC messages exchanged between the host and the BS (base-station) negotiate capability and the existence of support for IPv6. Additionally during the establishment of the transport connection for transporting IPv6 packets, the DSA-REQ and DSA-RSP messages between the BS and MS indicate via the CS- Specification TLV the CS that the connection being setup shall use. When the IPv6 packet is encapsulated by the 802.16 six byte MAC header there is no specific indication in the MAC header itself about the payload type. The processing of the packet is based entirely on the classifiers. SUBS: Does this indicate that IPv4 and IPv6 would need to run over separate 802.16 connections? Or that they would run over a single connection? Raj> IPv4 and IPv6 when run over the IP specific part of the packet CS are run over separate transport connections over the air-interface. They cannot be run over a single connection. Transmission of IPv6 as explained above is possible via multiple methods, i.e, via the IP specific part of the packet CS or via Ethernet or 802.1Q interfaces. The choice of which method to use is implementation specific. In order to ensure interoperability the BS should at least support both the IP specific part of the packet CS and the Ethernet specific part of the packet CS for IPv6 transport. SUBS: I think we need something stronger than a lowercase should here. In order to assure interoperability, this specification must make it clear what each side is required to implement in order to be compliant with this spec. Raj> Okay. Hosts which may implement one or the other method for transmission would be assured of the ability to establish a transport connection that would enable the transport of IPv6 packets. Inability to negotiate a common convergence sublayer for the transport connection between the MS and BS will result in failure to setup the transport connection and thereby render the host unable to send and receive IPv6 packets. In the case of a host which implements more than one method of transporting IPv6 packets, the choice of which method to use (i.e IPv6 over the IP specific part of the packet CS or IPv6 over 802.3 or, IPv6 over 802.1Q) is implementation specific. SUBS: How does the MS tell which modes are supported by the BS? Or vice versa? Raj> Via the capability negotiation in the MAC messages and the parameters exchanged in the request to establish a transport connection. The MS indicates what it is capable of supporting and the BS provides an indication in the response which mode to use. You may also want to refer to the email below for further details: http://www1.ietf.org/mail-archive/web/16ng/current/msg00021.html 4.1. IPv6 encapsulation over the IP CS of the MAC The IPv6 payload when carried over the IP specific part of the Packet CS is encapsulated by the 6 byte 802.16 MAC header. Header suppression can also be applied to the IP packet. The format of the IPv6 packet with and without header suppression is shown in the figure below: ---------/ /----------- | MAC SDU | --------/ /------------ || || \/ --------------------------------------------------------- | PHSI=0 | IPv6 Packet (including Header) | --------------------------------------------------------- (i) IPv6 packet without header suppression SUBS: What is PHSI? Is this part of the 6-byte MAC header? Or something separate? Raj> It is part of the MAC header. I will clarify the term PHSI. PHSI = Payload Header Suppression Index --------------------------------------------------------- | PHSI=1 | (Header suppressed IPv6 packet) | --------------------------------------------------------- (ii) IPv6 packet with header suppression SUBS: What type of header suppression is used in this case? Please add a pointer to the relevant specification. Raj> This is explained in section 5.2.3 of the 802.16 specification. I will add the appropriate reference. For transmission of IPv6 packets via the IP specific part of the Packet CS of 802.16, the IPv6 layer interfaces with the 802.16 MAC directly. The IPv6 layer delivers the IPv6 packet to the Packet CS of the 802.16. The packet CS defines a set of classifiers that are used to determine how to handle the packet. The IP classifiers that are used at the MAC operate on the fields of the IP header and the transport protocol and these include the IP Traffic class, Next SUBS: Why include the traffic class and not the entire IPv6 Flow Label field? Raj> Because the flow label is not a parameter used in the classification as specified by 802.16 today. header field, Masked IP source and destination addresses and, SUBS: Will the classifier walk any chained IPv6 headers and use the next header field that corresponds to the upper layer protocol? Or the next header field in the main IPv6 header? Raj> No. To quote 802.16 : "For IPv6 (IETF RFC 2460), this refers to next header entry in the last header of the IP header chain." I can clarify in the I-D. SUBS: How/why are the source and dest addresses masked? Raj> I am not sure I understand what you mean. Applying a mask to obtain a range is straightforward. And the reason for applying the mask is to use the filters (classification rules) to apply for multiple adresses or address ranges. Protocol source and destination port ranges. Using the classifiers, SUBS: What does the classifier use for source/dest ports if the packet is encrypted? Raj> In the case of encrypted packets, the SRC/Dest ports do not apply. As the 802.16 spec says :"If this parameter is omitted, the protocol source port is irrelevant. This parameter is irrelevant for protocols without port numbers." And the same for destination ports. So in the case of an encrypted packet, the rule does not apply. the MAC maps an upper layer packet to a specific service flow and transport connection to be used. The MAC encapsulates the IPv6 packet in the 6 byte MAC header and transmits it. 5. Generic network architecture using the 802.16 air interface EDIT: It would be helpful to move all of the information in this section to the introduction. Raj> But that would cause clutter and less readable IMO. When an AR and a BS are collocated, the collection of Transport Connections to an MS is defined as a single link. When an AR and a BS are separated, it is recommended that a tunnel is established between the AR and a BS whose granuality is no greater than 'per MS' or 'per service flow' ( An MS can have multiple service flows which are identified by a service flow ID). Then the tunnel(s) for an MS, in combination with the MS's Transport connections, forms a single point-to-point link. EDIT: You have not previous defined "service flow", as far as I know. Raj> Good catch. I will clarify. SUBS: If this is only recommended, what are the other options and how would IPv6 be supported over them? From the rest of the discussion, it appears that this is required, not recommended. Raj> Well... IPv6 can also be transported over Ethernet. If IPv6 is to be transported over the IP specific part of the packet CS, then this I-D specifies the mechanism. I can make such a statement in the I-D. The collection of service flows (tunnels) to an MS is defined as a single link. Each link has only an MS and an AR. Each MS belongs to a different link. A different prefix should be assigned to each unique link. This link is fully consistent with a standard IP link, without exception and conforms with the definition of a point-to- point link in RFC2461 [RFC2461]. Hence the point-to-point link model for IPv6 operation over the IP specific part of the Packet CS in 802.16 is recommended. A unique IPv6 prefix(es) per link (MS) is also recommended. SUBS: Should we make it clear that this prefix should be no longer than a /64, in order to provide full support for the features of IPv6? Raj> I am okay with making such a recommendation. I am just wondering if there may be a need to assign a /128 prefix in some cases as a way to limit the capability of the host. 6.2. IPv6 link establishment in 802.16 In order to enable the sending and receiving of IPv6 packets between the MS and the AR, the link between the MS and the AR via the BS needs to be established. This section illustrates the link establishment procedure. [...] 5. The MS can request the establishment of a service flow for IPv6 packets over the IP specific part of the Packet CS. The service flow can also be triggered by the network as a result of pre- provisioning. The service flow establishes a link between the MS and the AR over which IPv6 packets can be sent and received. SUBS: When you say "the MS can request" or "the service flow can also be triggered", which is the mandatory mode that both ends must support? Raj> The default option is the triggering of the service flow on completion of access authentication. Will clarify. 6. The AR sends a router advertisement to the MS. Alternatively or in addition, the MS can also send a router solicitation. SUBS: The AR and MS should send router advertisements and solicitations as specified in the Neighbor Discovery specification. If it is not your intent to change that, I would put a pointer here instead of the wording that is currently included. Raj> Okay. The above flow does not show the actual 802.16 messages that are used for ranging, capability exchange or service flow establishment. Details of these are in [802.16]. 6.3. Maximum transmission unit in 802.16 The 802.16 MAC PDU (Protocol Data Unit) is composed by a 6 byte header followed by an optional payload and an optional CRC covering the header and the payload. The length of the PDU is indicated by the Len parameter in the Generic MAC HDR. The Len parameter has a size of 11 bits. Hence the total PDU size is 2048 bytes. The IPv6 payload can be a max value of 2038 bytes ( Total PDU size minus (MAC Header + CRC)). The Max value of the IPv6 MTU for 802.16 is 2038 bytes and the minimum value of 1280 bytes. The default MTU for IPv6 over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 octets. SUBS: It is unclear what you are specifying here. We don't get to declare a default value for the 802.16 MTU. One of two things seems to be true here, and I don't have enough information to know which one: the MTU of 802.16 networks is 2038 bytes, or the MTU for 802.16 network is configurable between 1280 and 2038 bytes. Either way, IPv6 should be aware of the actual MTU in use on a give link and PMTUD should function accordingly. Raj> PMTUD is applicable when implemented on the host. The MTU recommendation is for the case when the host does not do PMTUD or does not obtain the information in the RA. The above section is basically explaining the MTU of the .16 link but recommending the use of 1500 octets as the default. RFC2461 defines an MTU option that an AR can advertise to an MN. If an AR advertises an MTU via the RA MTU option, the MN should use the MTU from the RA. SUBS: Even if it is greater than 2038 or less than 1280 bytes? Raj> Well... I would expect the AR to advertise a value that is between 1280 and 2038. It would be configured for the specific link. Maybe I can add the extra sentence to say that this value should be between 1280 and 2038. 7. IPv6 prefix assignment The MS and the AR are connected via a point-to-point connection at the IPv6 layer. Hence each MS can be considered to be on a separate subnet. A CPE (Customer Premise Equipment) type of device which serves multiple IPv6 hosts, may be the end point of the connection. Hence one or more /64 prefixes should be assigned to a link. The prefixes are advertised with the on-link (L-bit) flag set as specified in RFC2461 [RFC2461]. The size and number of the prefixes is a configuration issue. Also, prefix delegation may be used to provide additional prefixes for a router connected over 802.16. The other properties of the prefixes are also dealt via configuration. SUBS: As above, we should strongly recommend prefixes no shorter than a /64 in order for all IPv6 features to function properly. Raj> Are you suggesting that the AR should not advertise a /48 prefix? 8.3. Router lifetime and periodic router advertisements The router lifetime should be set to a large value, preferably in hours. This document over-rides the specification for the value of the router lifetime in RFC2461 [RFC2461]. The AdvDefaultLifetime in the router advertisement MUST be either zero or between MaxRtrAdvInterval and 43200 seconds. The default value is 2 * MaxRtrAdvInterval. 802.16 hosts have the capability to transition to an idle mode in which case the radio link between the BS and MS is torn down. Paging is required in case the network needs to deliver packets to the MS. In order to avoid waking a mobile which is in idle mode and consuming resources on the air interface, the interval between periodic router advertisements should be set quite high. The MaxRtrAdvInterval value specified in this document over-rides the recommendation in RFC2461 [RFC2461]. The MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 21600 seconds. The default value for MaxRtrAdvInterval is 10800 seconds. SUBS: I would like to see some exploration of what the impact of these changes would be on IPv6 operations. Are there other mechanisms that are used in 802.16 for black-hole detection and/or detecting when a network connection has been lost? Raj> The fact is that IETF has not specified behavior for hosts that can transition to Idle mode. A host which is connected at the IP layer and in idle mode does not have any radio bearer or connection as such to the AR. There is state in the host and the AR which allows the establishment of the connection when needed via paging mechanisms. So when you say network connection being lost, this happens only if the host does not see any of the .16 radio signaling at all. And in such a case there do exist mechanisms for the link layer to trigger network connection loss. A host in idle mode which has no lower layer connections to the AR but is still able to see the .16 radio signals is considered to be connected. I do not believe there are significant impacts to IPv6 operations with these changes (AFAIK). 9.1. Interface Identifier The MS has a 48-bit MAC address as specified in 802.16 [802.16]. This MAC address can be used if EUI-64 based interface identifier is needed for autoconfiguration RFC4291 [RFC4291]. As in other links that support IPv6, EUI-64 based interface identifiers are not mandatory and other mechanisms, such as random interface identifiers RFC3041 [RFC3041] may also be used. SUBS: Would the translation from 802.16's 48-bit MAC address to an EUI-64 identifier be the same as for an Ethernet address? Raj> Yes. EDIT: IPv6 addressers are based on Modified EUI-64 identifiers, not on EUI-64s in their original form. Raj> Okay. 9.2. Duplicate address detection DAD is performed as per RFC2461 [RFC2461] and, RFC2462 [RFC2462]. EDIT: Here and elsewhere, it would be more useful to name these documents and include the RFC number in the citation, rather than simply repeating the RFC number. Raj> Okay. 9.3. Stateless address autoconfiguration If the A-bit in the prefix information option (PIO) is set, the MS performs stateless address autoconfiguration as per RFC 2461, 2462. The AR is the default router that advertises a unique prefix (or prefixes) that is used by the MS to configure an address. 9.4. Stateful address autoconfiguration The Stateful Address Autoconfiguration is invoked if the M-flag is set in the Router Advertisement. Obtaining the IPv6 address through stateful address autoconfiguration method is specified in RFC3315 [RFC3315]. SUBS: In both of the previous two sections, is this any different from standard IPv6? If so, spell out what is changed. If not, why include these sections? Raj> Okay... Will clarify what is specific to this I-D and 802.16 10. IANA Considerations This draft does not require any actions from IANA. 11. Security Considerations This document does not introduce any new vulnerabilities to IPv6 specifications or operation. The security of the 802.16 air interface is the subject of [802.16]. In addition, the security issues of the network architecture spanning beyond the 802.16 base stations is the subject of the documents defining such architectures, such as WiMAX Network Architecture [WiMAXArch]. SUBS: I am not sure that this is correct. I am not clear on how 802.16 packet classification is consistent with encrypted upper-layer headers. Also, the changes to the Router Solicitation/Advertisement timers may have some security-related implications, particularly WRT to how long it may take end-nodes to detect changes to network attachment. Raj> As I said, the host is capable of detecting network attachment quite well at the link layer. Classification rules are specified such that if a packet does not meet the criteria, they are dropped. In the case of encrypted packets, the classification rules may exclude the use of the upper layer parameters. It is flexible. Changes to the RA interval IMO at least does not have a security impact. Appendix E. Stateless address autoconfiguration The MS can perform stateless address autoconfiguration as per RFC2461, 2462 if the A-bit in the prefix information option (PIO) is set. The AR is the default router that advertises a unique /64 prefix (or prefixes) that is used by the MS to configure an address. EDIT: Why is this in an appendix? How does this differ from section 9.3? Raj> Will delete. 3.2. Informative References [802.16] "IEEE Std 802.16e: IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", October 2005. SUBS: The IEEE 802.16 document should be a normative reference for this specification, not an informative one. Raj> Agree. Will correct. EDIT: Since this is now available for free download, a URL would be helpful. Raj> Okay [RFC3315] Droms, Ed., R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003, . EDIT: There is no reference to RFC 3315 in the document. Raj> Sec 9.4 of the I-D has a reference to 3315. _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng From 16ng-bounces@ietf.org Wed Jan 31 22:47:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSug-0003ZK-JQ; Wed, 31 Jan 2007 22:47:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCSuf-0003ZC-Be for 16ng@ietf.org; Wed, 31 Jan 2007 22:47:05 -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 1HCSuc-0002Nk-C0 for 16ng@ietf.org; Wed, 31 Jan 2007 22:47:05 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l113i7Va018505; Thu, 1 Feb 2007 05:44:11 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 05:46:44 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 21:46:41 -0600 Received: from 10.162.253.188 ([10.162.253.188]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Feb 2007 03:46:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 31 Jan 2007 21:49:00 -0600 From: Basavaraj Patil To: ext Jari Arkko , <16ng@ietf.org> Message-ID: Thread-Topic: Review of the ipv6-over-ipv6cs draft Thread-Index: AcdFs+grJnQRZLGnEduqwwARJNUNiA== In-Reply-To: <45BDFD58.8060202@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 03:46:41.0703 (UTC) FILETIME=[95BD6B70:01C745B3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6437e26f1586b9f35812ea5ebeedf4ad Cc: Pekka Savola 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, Thanks for the review. Comments inline: > >The editorial clarity could have been somewhat better. > >It is not obvious whether the scenarios where "MS" is a fixed station >and/or a router has been adequately considered or whether this is an >editorial issue. The term SS as has been defined and proposed for inclusion in the problem statement I-D (Ref: PSDOC in the I-D) is: o Subscriber Station (SS): An end-user equipment that provides connectivity to the 802.16 networks. It can be either fixed/nomadic or mobile equipment. In mobile environment, SS represents the Mobile Subscriber Station (MS) introduced in IEEE 802.16e specification. The email on the terminology is at: http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html In the case the MS is a CPE type of device serving hosts attached to it, then the behavior of the CPE in this I-D is the same as an MS/SS. > >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. 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? Pinging the all-nodes multicast address is an interesting issue. Doing so for example on the AR would result in flooding the access network and causing congestion on the air-interface if you have a large number of hosts attached to the network. Hence an AR may explicitly prevent such pinging. > >There seem to be some technical problems (e.g., GRE tunnel multiplexing, >different MTU recommendation) with Appendices and an issue of >clarity why the appendices are there to begin with. The MTU recommendation in the apendix is specific to WiMAX because of a profile that has been adopted which is a subset of the 802.16 specification. I dont understand the GRE tunnel multiplexing issue that you mention. Note that the appendix is informational only in the context of this document. The reason why it is useful is because of the fact that 802.16 deployments today is primarily as WiMAX. Hence the appendix shows the applicability of the spec to a specific realization of a .16 network. > >It is not clear if traffic classification is adequately specified (or is >it specified elsewhere?) and some miscellaneous issues. Classification rules are specified in the 802.16 specification. > >substantial >----------- > >==> looking at the other "IPv6 over foo" documents, this document doesn't >specify or mention the following: > - link-local address generation (exactly as described in RFC2464, I >suppose?) Yes. > - unicast and multicast address mapping > >Maybe these don't require much text but an explicit note might be a good >thing to have. Okay. I can add a sentence in the text. But since there is no variation from the IPv6 specifications for such addresses, I do not know if it helps in adding such a statement. > >... > >The packet CS defines a set of classifiers that are > used to determine how to handle the packet. The IP classifiers that > are used at the MAC operate on the fields of the IP header and the > transport protocol and these include the IP Traffic class, Next > header field, Masked IP source and destination addresses and, > Protocol source and destination port ranges. > >==> this is probably defined better in 802.16, but not all traffic may have >a traffic class (v4 has DSCP which is similar), you don't define what is >"masked {dst,src} address" (just some kind of prefix part of an address?), >and there may not necessarily be any port ranges involved (non-TCP/UDP >protocols). > >Is more precise specification of this required to create interoperable >implementations? Is it a problem if different hosts make different >classifications for the same kind of traffic? The classification rules operate on a set of fields defined in 802.16. Absence of such fields (for example ports in non TCP/UDP protocols) in a packet are essentially ignored. To quote 802.16 for the case of port numbers: " If this parameter is omitted the protocol destination port is irrelevant. This parameter is irrelevant for protocols without port numbers. " Masked src/dest address classification rule is simply a means of specifying address ranges via a mask. I can try and clarify this section better and add a reference to the 802.16 spec for further details on the classification rules. > > Hence the point-to-point link model > for IPv6 operation over the IP specific part of the Packet CS in > 802.16 is recommended. A unique IPv6 prefix(es) per link (MS) is > also recommended. > >==> you don't discuss what will happen if these recommendations are not >followed, in fact, the whole document assumes they are adhered to. Either >this should be discussed or the recommendations should be made stronger >(requirements). Okay... I can make it a requirement. > >6.3. Maximum transmission unit in 802.16 > >[...] The Max value of the IPv6 MTU for 802.16 is 2038 > bytes and the minimum value of 1280 bytes. The default MTU for IPv6 > over 802.16 SHOULD be the same as specified in RFC2460 which is 1500 > octets. RFC2461 defines an MTU option that an AR can advertise to an > MN. If an AR advertises an MTU via the RA MTU option, the MN should > use the MTU from the RA. > >==> Should the last sentence use uppercase keywords? Yes. >==> 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? > >8.1. Router Solicitation > [...] Movement detection at the IP layer of an MS > in many cases is based on receiving periodic router advertisements. > >==> yet, in 8.3 you make the period much longer, to be counted in hours. >That's not useful for movement detection, text above should probably be >adjusted. But if you see the sentence following the above in sec 8.1, I do state that link-layer triggers can be used to send router solicitations instead and not rely on periodic RAs. So the sentence when read by itself is in conflict with Sec 8.3 but not when read with the following sentences in Sec 8.1. > >8.3. Router lifetime and periodic router advertisements > >==> it is not clear if the implications of the design decision to raise the >default advertisement intervals has been adequately understood. Will this >mean that every single instance of protocols which use too low intervals >will need to be modified? What specific protocols would you be concerned in this case? I know MIP6 for example uses a lower interval for RAs for movement detection. But as I said, movement detection in the case of 802.16 can be dealt with at the link layer and triggers to indicate such movement to the IP layer. > How do you deal with periodic MLD reports, for >example? So what would break if periodic MLD reports are not sent. >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? In case a packet for the MS arrives at the AR, paging is used wake up and establish the link and deliver the packet to the host. > > The > granularity of the GRE tunnel should be on a per MS basis or on a per > service flow basis (an MS can have multiple service flows, each of > which are identified uniquely by a service flow ID). > >==> So, it's possible to have multiple GRE tunnels between AR and BS. Yet, >I do not see how different GRE tunnels are multiplexed/demultiplexed. GRE >header does not support this AFAICS -- you'd need to use different >source/destination IP address pairs, or encode different flows as different >'Protocol type' values (16 bits), but the latter would require >modifications >to GRE processing code at both endpoints of the tunnel. Therefore I'm not >sure if this approach is workable. Let me send a separate explanation for this. > >Appendix D. Maximum transmission unit in WiMAX > > The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets. > Hence the IPv6 path MTU can be 1500 octets. However because of the > overhead of the GRE tunnel used to transport IPv6 packets between the > BS and AR and the 6 byte MAC header over the air interface, using a > value of 1500 would result in fragmentation of packets. It is > recommended that the default MTU for IPv6 be set to 1400 octets for > the MS in WiMAX networks. Note that the 1522 octet specification is > a WiMAX forum specification and not the size of the SDU that can be > transmitted over 802.16, which has a higher limit. > >==> This brings up multiple problems: > > 1) main body said SHOULD use 1500 bytes, yet this recommends 1400. This recommendation is WiMAX specific and is in the appendix. The recommendation in the main body is applicable to 802.16 in general. > 2) there is no statement in the document how to treat the appendices, >i.e., >why thet even exist in this document especially if they contain >contradicting material. Well... The appendix is informational only. It exists to demonstrate a realization of a network based on 802.16 air interface. I can add explicit clarification to this effect. > 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. > > >editorial >--------- > >Abstract > > IEEE Std 802.16 is an air interface specification. 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. The packet CS is used for transport for all packet-based > protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet) > and, IEEE Std 802.1Q (VLAN). The IP specific part of the Packet CS > enables transport of IPv6 packets directly over the MAC. This > document specifies the addressing and operation of IPv6 over the IPv6 > specific part of the packet CS for hosts served by a network that > utilizes the IEEE Std 802.16 air interface. It recommends the > assignment of a unique prefix (or prefixes) to each host and allows > the host to use multiple identifiers within that prefix, including > support for randomly generated identifiers. > >==> s/the assignment of/assigning/ ? >==> abstract is a bit on the lengthy side. Maybe shorten a bit from the >beginning, e.g. leaving ATM CS and some more generic sublayer discussions >out of the abstract? > Okay... Will attempt. >2. Introduction > >==> the introduction mentions "mobile station/host", yet I think there >is no >restriction that the endpoint be a) mobile (could be a fixed wireless link >as well), and b) a host (could be a router as well). Maybe some further >clarification here is needed to make it clear that fixed/router scenarios >are also to be addressed by this specification. Okay. I can add further text to the definition of MS/SS to include such hosts. > >==> it might be helpful to have a diagram in section 2, as there are at >least four functional components (AR, BS, link, MS) and at least AR hasn't >been spelled out. This also seems to include some assumptions about >connecting a host to a router (above). Will consider if it would help. > >4.1. IPv6 encapsulation over the IP CS of the MAC > > The IPv6 payload when carried over the IP specific part of the Packet > CS is encapsulated by the 6 byte 802.16 MAC header. [...] > >==> "encapsulated by" seems a bit strange.. also, later you use >"encapsulated .. in". I dont know if it is a problem. But I can rephrase. Do you have a better term? > > The IPv6 node requirements RFC RFC4294 [RFC4294] specifies [...] > >==> s/ RFC RFC4294// Yes. -Raj _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng