Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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.
==========================================