RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

["Riegel, Maximilian" <[e-mail]>]

It seems the architectural issues are more implementation issues than
issues with the architecture.

First, there are a couple of possible implementation of the link between
BS and Bridge, and GRE and VLAN are mentioned because the WiMAX Forum
has chosen GRE for the mobile WiMAX architecture and VLANs look more
familiar to the Ethernet people. GRE works fine as shown in the WiMAX
Forum specifications and is able to carry any packet size as IP is able
to fragment and reassemble packets exceeding the MTU of the underlying
transport. VLAN has restrictions on the supported packet size - even
1500 byte ETH packets may fail.

Second, the protocol being used for establishing and releasing the links
between BS and Bridge depends on the implementation. For the GRE
solution, the WiMAX Forum has defined a well defined protocol called
'Data Path Function' and for VLAN a standardized solution like GVRP may
be deployed. It may be appropriate to mention the control protocols
together with the implementation examples.

Third, encapsulation and decapsulation of Ethernet packets going over
the link between BS and Bridge are functions of the particular tunneling
protocol deployed for the implementation. Again an implementation issue
with no relevance for the architecture.

Forth, the requirements on the functions performed by the AR should be
more elaborate. We will be put more specific information into this
section.

The architecture is showing a single bridge behind the BSs. It would be
possible to split the single bridge into a number of smaller bridges,
each directly connected to a BS. Such a distributed implementation would
be much less efficient in filtering packets to prevent unnecessary
forwarding and flooding and would be more vulnerable for security
threats. Therefore the centralized form was chosen for this
specification.
 
Thanks for providing feedback on the I-D.

Bye
Max

-----Original Message-----
From: ext Burcak Beser [mailto:[e-mail]] 
Sent: Friday, September 07, 2007 6:26 AM
To: Daniel Park; [e-mail]
Subject: RE: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

[Architectural Issues]

First of all, I have to admit that the Draft is very hard to read, and
could be improved a lot by a careful re-write.

Let me try to summarize what I understood:

The Host devices are connected to a bridge SS which is through 802.16
links (Service Flows) connected to BS. BS assumes that each SS is
connected to a port and though an undefined mechanism connects these
ports to "the Bridge" that does not bridge; which in turn aggregates
these links to one Access Router or aggregates other BS to the Access
Router.

Each time a new SS connects the BS creates a new port and opens a new
undefined link that connects this port to the Bridge. Each time an SS
disconnects from the BS, the undefined link is destroyed between the BS.

First, the link between the BS and the Bridge is left as an exercise.
The examples given as the undefined link are: VLANs or GRE tunnels. The
original "-0" draft was using the GRE tunnels and now this interface is
left undefined. Since the GRE tunnel method has many issues which were
described in detail on the -0 feedback e-mail dated 1/8/2007 with
subject line "Request for clarification on
draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt", so I do not
understand why it is given even as an example. One example with GRE
tunnels is the fact that they restrict the maximum packet size to less
than 1500 bytes for IP packets. There are other problems with VLANs as
well but since these are given as example I will not go in detail with
these problems.

The second issue is that there needs to be an defined protocol between
the BS and the Bridge which enables the BS to create and destroy the
undefined links. This protocol is not just undefined but is not even
mentioned within the Draft.

The third issue with the undefined link is the fact that no matter which
transport method is being used the Bridge will be encapsulating the
packets that are being forwarded to BS and decapsulating from the
packets that are coming from the BS. For GRE this means that the Bridge
will be putting the MAC packets into L3 tunnel. Since the undefined
mechanism is undefined I am not so sure.

The Fourth issue is even though the Draft is skimpy on the BS to the
Bridge connectivity, it is not shy on putting vague restrictions on the
Access Router that the Bridge is connected. One example is the statement
"The AR SHOULD perform security filtering, policing and accounting of
all traffic from hosts, e.g. like a NAS (Network Access Server)."

I have many other issues on the architectural side but these are the
major ones.

I have a simple question: Why there is a need to separate the BS and the
Bridge? The merging of the BS and the Bridge will free you from the
interface that is undefined now, will make a lot of sense from the
architectural view since there is no reason given for the separation. If
one wants to divide a BS as air interface module and bridging module,
they can still do it but this draft does not need to define that detail.

Moreover, the merging of the BS and the Bridge will enable the focus to
be given to SS and BS. Personally I find unnecessary to put restrictions
on the Access Routers and put network restrictions that should be
provider decisions.

Kind Regards,
-burcak

> -----Original Message-----
> From: Daniel Park [mailto:[e-mail]]
> Sent: Thursday, August 16, 2007 3:50 PM
> To: [e-mail]
> Subject: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02
>
> Folks,
>
> This is a WGLC on draft-ietf-16ng-ip-over-ethernet-over-802.16-02
> "Transmission of IP over Ethernet over IEEE 802.16 Networks".
>
> o Intended publication: Proposed Standard RFC
>
> The latest version can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ip-over-et
> hernet-over-80
> 2.16-02.txt
>
> Due to vacation period, it will expire on September 7 2007.
>
> -------------------------------------------------------
> Daniel Park & Gabriel Montenegro
> Chairs, 16NG Working Group
>
>
>
> _______________________________________________
> 16NG mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/16ng
>
>



_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng