Subject: Re: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00

From: Max Riegel <[email-masked]>
Date: Wed, 01 Nov 2006 21:56:46 +0100

At 2006-10-25 05:30, wenson wrote:
>Hi,Max:
>Thanks for your reply. Andyway,I have some questions about your daft, i.e,
>draft-riegel-16ng-ip-over-eth-over-80216-01.txt
>In section 3.5, it wrote:
> >>Without implementation of the special multicast and broadcast
> >>channels in IEEE802.16 all multicast and broadcast packets have to be
> >>transferred over unicast connections to each SS causing radio
> >>resources redundantly be used for transmission of the same information.
>  So my question is:
>Does it mean that upon receiving multicast packet, BS will forward packet 
>over unicast connection?
>Is there any approach to implement special multicast and broadcast 
>channels to reduce radio resources overhead until now?

The bridge behind the BS is processing the multicast packets by multiplying 
them over unicast connections. The BS is just forwarding the connections 
over the air without special care for multicast addresses.
Making use of MBS connections for sending multicast packets may reduce the 
waste of radio resources but  forces all subscriber stations to wake up for 
processing the frames. This may cause waste of power in the subscriber 
stations which is much more critical in a wireless broadband access system 
than waste of radio resources.

>In section 3.4, it wrote:
> >>Downlink connections can be shared among multiple SSs, enabling
> >>multicast channels with multiple SSs receiving the same information
> >>from the BS.  Multicast is not enabled in the uplink but must be
> >>realized by an entity on top the IEEE802.16 MAC sending packets
> >>received on a unicast uplink downstream on a multicast channel.
>why is Multicast not enabled in the uplink but realized by an entity on 
>top the IEEE802.16 MAC?
>what is the difference between downlink connection and uplink connection?

Multicast in the uplink is not available in 802.16.

>In section 4.1.1, it wrote:
> >>When performing Standard Learned Bridging, the SS or BS shall learn
> >>all source MAC addresses originating from a port up to MAXMSIP
> >>individual learned addresses.  The accumulation of all learned MAC to
> >>port associations constitutes the Learned Bridge Table.
>Since data link connections between each of the SS and the BS are built 
>and identified
>as one 16 bit connection Identifier, why should BS support ARP and use MAC 
>in IPv4 packet processing?
>Since introducing ARP mechanism, why not realize native MBS function? what 
>do you think of it?

Thanks for pointing to this text. It is a little bit ambiguous and should 
read "When performing Standard Learnde Bridging the bridge at the SS or the 
bridge behind the BS shall learn..."
802.16 provides a point-to-point connection between these two bridges. The 
reason why not to use MBS on this connection was given above.

Bye
Max

>
>Wenson
>----- Original Message -----
>From: Riegel, Maximilian
>To: wenson
>Cc: Qin Alice ; [email-masked] ; Soohong Daniel Park
>Sent: Tuesday, October 24, 2006 7:15 PM
>Subject: RE: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00
>
>Wenson,
>
>You may find answers to your questions in the just released I-D
>draft-riegel-16ng-ip-over-eth-over-80216-01.txt
>
>The Ethernet link model for IEEE802.16 does not make use of the native MBS 
>function in IEEE802.16 for broadcast and all hosts multicast, as MBS is 
>less efficient than unicast and special processing in the bridge.
>
>Direkt host-to-host communication is only enabled as a configurable option 
>in VLAN scenario between members of a particular VLAN. Otherwise all 
>communication is passing through the AR to allow for interception and 
>accounting by the AR.
>
>Broadcast and Multicast is realized in the bridge behind BS over unicast 
>connections to the MSs with special filtering taking place to prevent from 
>wasting transmission and power resources.
>
>Bye
>Max
>
>
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of wenson
>Sent: Tuesday, October 24, 2006 6:02 AM
>To: Soohong Daniel Park
>Cc: Qin Alice; [email-masked]
>Subject: Re: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00
>
>Hi Daniel:
>
>As far as I concern, the link models can be categorized based on three 
>network topology  modes ,i.e., point to point, point to multiple points 
>and multiple points and multipoints. Different topology mode can be 
>deployed in different scenario.
>
> >>>In section 3.3.4.2, it said:
>
> >>>in case of bridging, direct inter-MSs communication may not be not 
> allowed due to restrictions from the service providers.
>
>So my questions is
>
>1.If MSs are served by the same service providers and located below the 
>same BS(i.e., connect to the same BS), Do they communicate with each other?
>
>
>
>2. In Ether like link model, there are several BS attached the same ether 
>Switch device and also there are several MS attached the same BS, how does 
>BS process multicast packet from AR beyond ether Switch and forward the 
>processed packet to each MS who is located below BS?
>
>***maybe multicast capability is limited not between MS and AR but between 
>BS and AR, what do you think of it?
>
>
>
>3. As Above said, how Ether switch or bridge work to support multicast 
>capability?
>
>
>----- Original Message -----
>From: "Soohong Daniel Park" <[email-masked]>
>To: <[email-masked]>
>Sent: Thursday, October 12, 2006 5:20 PM
>Subject: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00
>
> > Folks,
> >
> > This is a two week WGLC on draft-ietf-16ng-ipv6-link-model-analysis-00.
> >
> > Please review the I-D and submit your comments to the authors or to
> > the list directly. The WGLC will exipre on October 26 (Pacific Time).
> >
> > o I-D: 
> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-00.txt
> >
> > o Intended publication: Informational RFC
> >
> > --
> >
> >
> > Daniel (Soohong Daniel Park)
> > Mobile Convergence Laboratory, SAMSUNG Electronics.
> > _______________________________________________
> > 16ng mailing list
> > [email-masked]
> > http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> >

_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng