Re: [STDS-802-16] The ARP broadcast problem in 802.16
Hi,
I agree with you, if define one well-known transport broadcast connection
can let the system deployment has more flexibilities, which is one of the
major benefit of 802.16, why not do it?
I have one question about the BS provides proxy ARP service for the MSS if
the Mobile IP is applied. In this case, the Home Agent will also provides
proxy ARP, I think this might cause problems.
Thank you.
Best Regards,
Chi-Chen Lee
==========================================
Industrial Technology Research Institute
Computer & Communications Research Lab.
==========================================
---------------- Original Message ----------------
> "Mike Geipel" <geipel@ieee.org> 2005/02/04 05:58:49 AM wrote:
收件人: "'Chi-Chen Lee'" <jjlee@itri.org.tw>
副本抄送: "'Dj Johnston'" <dj.johnston@intel.com>
主旨: RE: [STDS-802-16] The ARP broadcast problem in 802.16
As far as I can tell, the SMC is still in both draft specs.
(802.16-2004+corrigenda and 802.16e)
I made a NetMan contribution in Sanya in which I proposed language be
added to clarify that the BS must proxy ARP and DHCP in order to support
the SMC. It was rejected as being an "obvious" implementation
requirement. (The IEEE is good at writing standards that no one
understands...)
I made a similar (late) contribution to the Corrigenda. But they didn't
get to review any late comments.
The relevant verbiage is in 802.16maint-05/063 and 802.16g-05/02:
Option 1: Explicitly state that the following are mandatory requirements
of the Base Station to support the SMC: BS modems that are not routers
must provide proxy ARP service for all managed SSs. BS modems either
provide a DHCP service directly, or act as DHCP relay agent for all
managed SSs. BS modems must provide IP forwarding service for all
managed SSs in the downlink.
(The subscriber is NOT currently limited to just SNMP and TFTP for
management via IP.)
Option 2: Define a well-known downlink multicast CID for broadcast SMC
traffic to managed SSs.
It gets even more interesting:
The "e" spec even mentions mobile-IP as an alternative way for a
subscriber modem to get the IP address. But there isn't a way for the
subscriber to tell the basestation which method is going to be used.
This matters because the BS must now also participate in the mobile-IP
binding exchange in order to know the subscriber modem's IP address(es).
(A consequence of being the ARP proxy.)
The implication would be that tunneled (mobile-IP encapsulated) traffic
should be presented on an IP CS for CPE flows, so 802.16 IP classifiers
would still work. But that isn't stated anywhere either. Of course,
the SMC traffic would need to support the full wrapper traffic, since it
participates as the mobile agent. Details, details, details.
Again, defining a well-known multicast CID for broadcast traffic to SMC
SAPs would be a better alternative, IMHO.
--
Mike Geipel
Principal Engineer
Axxcelera Broadband Wireless
1600 East Parham Road
Richmond, VA 23228
Direct: 804-864-4125
-----Original Message-----
From: Chi-Chen Lee mailto:jjlee@ITRI.ORG.TW]
Sent: Thursday, February 03, 2005 8:32 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] The ARP broadcast problem in 802.16
Hi,
After revisiting the passed discussions of the usage of "SMC", I found
that
all of them are focused on the L3 broadcast messages. There is no
discussion about the broadcast messages such as ARP, RARP and Gratuitous
ARP. (Considering one SS seeks another SS's MAC address using ARP or the
router seeks the SS's MAC address using ARP) These messages will be
broadcasted in the subnet. According to DJ's reply, it seems that there is
still no answer to how will these kind of broadcast messages
be transmitted over the 802.16 air interface efficiently. I think the
contribution "IEEE C802.16d-03/81 (Resolving IP Broadcast Issues by Alex
Raji and Don Leimer)" has proposed a possible solution about the IP
broadcast issues, i.e. a new CID named "Transport broadcast CID". But it
did not mention the ARP broadcast issues. It seems reasonable to add a new
broadcast CID to carry those ARP/RARP/Gratuitous ARP and L3 broadcast
messages. Can anybody clarify this issue?
Thank you.
Best Regards,
Chi-Chen Lee
==========================================
Industrial Technology Research Institute
Computer & Communications Research Lab.
==========================================
---------------- Original Message ----------------
> "Johnston, Dj" <dj.johnston@INTEL.COM> 2005/01/29 01:33:48 AM
wrote:
收件人: STDS-802-16@LISTSERV.IEEE.ORG
主旨: Re: [STDS-802-16] The ARP broadcast problem in 802.16
If you could use the SMC for ARP traffic of an MSS, then yes, the
problem you describe would exist.
However the secondary management channel was removed for MSSs in the San
Antonio meeting. So text specifying an MSS must the the SMC for
something sounds inconsistent with that.
DJ
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG
[mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Chi-Chen Lee
Sent: Friday, January 28, 2005 4:07 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] The ARP broadcast problem in 802.16
Hi all,
I have a question about the ARP operation in 802.16 network. In
contribution named "BS's Proxy ARPing for Sleep & Idle Mode MSSs", it
mentioned that the ARP request message will be carried over secondary
management connection. The problem is that secondary management
connection in DL is an unicast connection, if the BS broadcasts the ARP
request message through secondary management connection, it means that
each SS will receive an duplicate ARP request message from the BS, which
is obvious not bandwidth efficient. Is there any misunderstanding of my
reading of the standard?
Thank you.
Best Regards,
Chi-Chen Lee
==========================================
Industrial Technology Research Institute Computer & Communications
Research Lab.
==========================================