Subject: RE: [16ng] Submission of draft-riegel-16ng-ip-over-eth-over-80216 -00.txt

From: Rina Nathaniel <[email-masked]>
Date: Tue, 20 Jun 2006 13:44:36 +0300

Max,

In IEEE, 802.16k WG is working on bridging see the links below.
This WG will write an amendment to IEEE 802.1D-2004 (MAC Bridges) that
explain bridging with 802.16.
http://ieee802.org/16/pubs/80216k.html
http://grouper.ieee.org/groups/802/16/docs/06/S80216-06_001.pdf

Rina Nathaniel, 
CTO group

-----Original Message-----
From: Riegel, Maximilian [mailto:[email-masked]]
Sent: Tuesday, June 20, 2006 11:33 AM
To: Syam Madanapalli
Cc: [email-masked]
Subject: RE: [16ng] Submission of
draft-riegel-16ng-ip-over-eth-over-80216-00.txt

Syam,

According to the scope and name of the working group (16ng) my intention
was to keep the draft agnostic to a particular access network
architecture and to focus on the generic 802.16 protocol architecture.
If you replace 'BS' in the specification part of the I-D by the WiMAX
term 'ASN', you will get an imagination, how the specification fits into
the WiMAX network architecture. As WiMAX knows about a couple of
different models for the functional split between BS and ASN-GW
(including no split at all) the bridging function may be implemented in
either place depending on the particular ASN profile and the type and
granularity of the GRE tunnels between BS and ASN-GW.

Assuming that the SS is some kind of CPE with an integrated Ethernet
bridge (switch) for connecting hosts behind the SS, the bridge at the BS
side does not get knowledge about a particular MAC address attached to
the bridge in the SS prior to the first packet coming upstream. Only in
the special case of a 'single host' terminal, the bridge can learn the
MAC address out of the establishment of the MAC connection.

Bye
Max

-----Original Message-----
From: Syam Madanapalli [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 5:01 AM
To: Riegel, Maximilian
Cc: [email-masked]
Subject: Re: [16ng] Submission of
draft-riegel-16ng-ip-over-eth-over-80216-00.txt

Hello Max,

A couple of questions:

1. It is not clear how this draft fits into the WiMAX Network model.
e.g. In WiMAX all the packets travel to ASN GW before being delivered
to destination i.e. the MAC transport connection is extended all the way
to ASN GW. So I am wondering how this bridging functionality fits into
this kind of architecture.

2. Why cannot the bridge learn the MAC addresses from the establishment
of
802.16 MAC connections?

Thank you,
Syam

On 6/19/06, Riegel, Maximilian <[email-masked]> wrote:
> Dear Editor,
>
> I would like to submit the individual I-D
> draft-riegel-16ng-ip-over-eth-over-80216-00.txt aimed for discussion
in
> the 16ng BOF/WG.
>
>        Transmission of IP Packets over Ethernet over IEEE802.16
>            draft-riegel-16ng-ip-over-eth-over-80216-00.txt
>
> Abstract
>
>   This document describes the special behavior of the Ethernet
>   emulation on top of IEEE802.16 to efficiently support the
>   transmission of IPv4 as well as IPv6 packets over IEEE802.16 radio
>   links.
>   Due to resource constraints of radio transmission systems and the
>   limitations of the IEEE802.16 MAC layer for the emulation of
>   Ethernet, the transmission of IP over an emulated LAN on top of
>   IEEE802.16 may considerably benefit by adding IP specific support
>   functions within the Ethernet emulation on top of IEEE802.16.
>
>
>
> Please fetch the full document by
>
http://www.max.franken.de/ids/draft-riegel-16ng-ip-over-eth-over-80216-0
> 0.txt
>
> Kind regards
> Max
>
>
> _______________________________________________
> 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

 
****************************************************************************
************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses(192).
****************************************************************************
************

 
****************************************************************************
********
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses(43).
****************************************************************************
********

 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************