Re: [STDS-802-16] Issues for the usage of the Secondary managemen t connection
Peretz,
Subject of the discussion [in my perception] was: do we need new MAC level
arrangements to specify how "L3 multicast" traffic is
delivered to the terminal.
I don't see why L3 multicast traffic cannot be delivered over regular
multicast MAC connection.
It is different from IP messages used to configure MAC/PHY at the terminal
[for which purpose Secondary Management
connection was invented]. So if MIP host functionality is collocated with
the terminal, we can simply do nothing [in MAC spec].
Secondary question [not related to the discussion directly] that I raised
was: where does IP multicast traffic of "management" nature
come from? It is highly undesirable at the air interface. Ronny pointed to
MIP advertisements as an example. This example is valid
if MIP host functionality is collocated with the terminal (option A) and my
reaction was that there is another solution which does
not include delivery of multicast traffic over the air (option B: MIP Proxy
at BS). Generally speaking, partitioning of functions
supporting network level mobility [e.g. location of MIB host functionality]
is not in scope of 16e, so it should be another discussion.
For that another discussion, reference to legacy terminals is a valid
motivation for option A, but I don't find it sufficient for "option A only".
For me integration with 3GPP networks is not a primary application for
802.16e. Fortunately existing MAC tools provide for aceptable solution
for both A and B.
Vladimir
> -----Original Message-----
> From: Peretz Feder [mailto:pfeder@lucent.com]
> Sent: Tuesday, November 02, 2004 8:21 AM
> To: Vladimir Yanover
> Cc: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] Issues for the usage of the
> Secondary managemen t connection
>
>
> Vladimir:
>
> Although your idea of Mobile IP client proxy at the BS is a
> good one, it ignores
> the legacy terminals (i.e. CDMA) that do support MIP
> clients. If we were to
> interoperate across technologies (as we attempt in 802.21)
> most likely MIP proxy
> can't be assumed in every BS. In cdma2000 where BW is even
> more limited, we
> implemented MIP clients and advertisement is done only upon
> network entry.
> Thereafter advertisements are minimized and solicitations are
> sent when prior
> challenge is stale. You may argue that in 802.16
> advertisements are required to
> detect movement, but this is where 802.21 should help with a
> quicker movement
> detection through L2 or L2.5 mechanisms.
>
> Bottom line, for inter-technology handover, MIP at the
> terminal should be
> assumed.
>
> Peretz Feder
>
>
> This mail passed through mail.alvarion.com
>
> **************************************************************
**********************
> This footnote confirms that this email message has been scanned by
> PineApp Mail-SeCure for the presence of malicious code,
> vandals & computer viruses.
> **************************************************************
**********************
>
This mail was sent via mail.alvarion.com
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************