[16NG] Comments on IPv4CS subnet model and ARP

Behcet Sarikaya <behcetsarikaya@yahoo.com> Mon, 18 June 2007 16:19 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Jwx-0004hU-Nu; Mon, 18 Jun 2007 12:19:31 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43) id 1I0Jwx-0004hP-5a for 16ng-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 12:19:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Jww-0004hH-SI for 16ng@ietf.org; Mon, 18 Jun 2007 12:19:30 -0400
Received: from web84102.mail.mud.yahoo.com ([68.142.206.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0Jww-0006cB-FX for 16ng@ietf.org; Mon, 18 Jun 2007 12:19:30 -0400
Received: (qmail 85925 invoked by uid 60001); 18 Jun 2007 15:54:09 -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=RuHLWtzS/kjqIBy4+WzMBh3sn3lqdVHLB9TUmyQy3MAme3ufZ4+9aCIThDdmFkjlGly+QxtTutVgAjSmcBVLOG5ADKOapnTcbSEZTSENqnh2y74y1TK4YoEpE2PsjyWs88bOgjyBdQUJjmRPsBKpzzARkiGe7+xS37438Tylmxs=;
X-YMail-OSG: naMv2SAVM1mw6m9ktdGxiPSWLuKhuX49tLzHtpGo7aFwZm5ySznUenRbNNoJ3enKVJ5KMrtkSw--
Received: from [206.16.17.212] by web84102.mail.mud.yahoo.com via HTTP; Mon, 18 Jun 2007 08:54:09 PDT
X-Mailer: YahooMailRC/651.23.1 YahooMailWebService/0.7.41.14
Date: Mon, 18 Jun 2007 08:54:09 -0700 (PDT)
From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
Subject: [16NG] Comments on IPv4CS subnet model and ARP
To: Samita Chakrabarti <samita.chakrabarti@azairenet.com>
MIME-Version: 1.0
Message-ID: <183536.85214.qm@web84102.mail.mud.yahoo.com>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: "16ng@ietf.org" <16ng@ietf.org>
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Behcet Sarikaya <sarikaya@ieee.org>
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0702673777=="
Errors-To: 16ng-bounces@ietf.org

Hi Samita,
  Please see inline.
Please include behcetsarikaya@yahoo.com in your reply.

Regards,

Behcet

Please see in-line.
[SC>] 
I am forwarding these comments originally from Sangeun Kim at KT to 16ng list.

[SC>] Thanks.
========================================

6.  Subnet Model and IPv4 Address Assignment

The Subnet Model recommended for IPv4 over IEEE 802.16 using IP CS is
based on point-to-point link between MS and AR, hence each MS will be
on different IP subnet.

Proposed Changes: The Subnet Model recommended for IPv4 over IEEE
802.16 using IP CS is based on point-to-point link between MS and AR.

[SC>] Fine by me.

[behcet] What is the difference between the two? Why change the original text?


7.  Address Resolution Protocol

The IEEE 802.16 frame header does not contain the source and
destination MAC addresses, instead it uses the Connection Identifier
(CID) for the delivery of MAC frames.  This makes classical Address
Resolution Protocol (ARP) [3] trivial and unnecessary. > Also, IEEE
802.16 IPCS cannot classify the ARP packets as ARP runs directly over
 Ethernet and does not contain IP header.  Thus ARP packets are not
transmitted over IEEE 802.16 air interface when using IPCS.

Proposed Changes: The IEEE 802.16 frame header does not contain the
source and destination MAC addresses, instead it uses the Connection
Identifier (CID) for the delivery of MAC frames.  This makes classical
Address Resolution Protocol (ARP) [3] trivial and unnecessary. Also,
IEEE 802.16 IPCS cannot classify the ARP packets as ARP runs directly
over Ethernet and does not contain IP header. Thus ARP packets are not
  transmitted over IEEE 802.16 air interface when using IPCS. However
MS requires to proxy ARP function compatible with legacy IP host.

[SC>] Let's discuss the last sentence. MS requires to proxy ARP function compatible with legacy IP host: What is the expected configuration of the scenario in this case? The legacy IP host will not be on the same Wimax IPCS
link; thus our assumption was that they would be on different subnets.
Please clarify.


Regards,
-Samita



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