[16NG] Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

I have to admit that at this point of time I am confused. The draft has
some details and a lot of information that I am not sure how these
interconnect.

Let me start from the beginning:

(The below described usage is the WiMAX mandatory supported transport of
packets and all the descriptions and especially normative language has
to deal with these details.)

Per WiMAX specifications (see
http://www.wimaxforum.org/technology/documents/WiMAX_End_to_End_Network_
Systems_Architecture.zip) each "connection" between SS and BS indicated
by a unique CID within a single BS domain is mapped into a GRE tunnel in
and in some other cases all CID's coming from a single SS is mapped into
a GRE tunnel identified by a "GRE key". Now, it is important to note
that the  "connections" per IEEE 802.16 specifications is left very
liberal in the means that they may be used. It is possible that there is
a single uplink "connection" which has associated multiple downlink
"connections". If there are no limitations on the CPE generated packets
it is possible that the CPE packets will be fragmented as in the case of
IPSEC tunnels, and will be fragmented again on the GRE level.

      SS_A CID1 BS GRE-key1

CPE -----|------|------------\

         |      |             \

CPE------| CID2 |  GRE-key2    \

CPE -----|------|---------------\

                |                \      GRE

.               |                /========================

.               |               /

                |              /

CID3  SS_Z CID* |   GRE-keyn  /

---------|------|------------/

The BS sends these packets through the GRE tunnel to the ASN-GW which is
a layer-3 device and designated in the draft as Access Router (AR). Per
WiMAX specifications the ASN-GW actually can be divided into two as
being serving ASN-GW which is the entity that the BS is connected
(through the draft defined bridge) which re-maps the packets (GRE
payloads) to another GRE tunnel to the anchored ASN-GW (again through
the draft defined bridge). Where the final figure looks like as below:

      CID         GRE_1        GRE_2           GRE_3          GRE_3
GRE_4

SS ---------- BS ------ Bridge ------ serving ----- arbitrary -----
Bridge -------- anchored

                       (serving)      ASN-GW         network
(anchored)         ASN-GW

We can say that for each CID there is a GRE tunnel where GRE_1 and GRE_2
are the same tunnel and GRE_3 and GRE_4 are the same tunnel further the
GRE_1/2 and GRE_3/4 are one-to-one mapped.

This brings the draft introduced "Bridge", which has different
interpretations; for the sake of taxonomy I think the bridge as having 3
layers:

i. Layer 0: This is the 802.1d-2004 defined layer where the physical
interfaces are the interfaces. It is very easy to decide where a packet
is received and which interface you can send a packet. On this level the
bridge supports a limited number of traffic:

* GRE tunnel: This is the traffic between the BS(s) and the ASN-GW(s).
All BS(s) are sending packets to serving ASN-GW(s).

* ASN Control packets: These are packets exchanged between BS and ASN-GW
for various purposes.

* Inter BS communications: This is the R8 interface of the WiMAX
specification although it is not specified it may exist.

It is important to note that any packets generated by SS or any CPE
behind it is send through the GRE tunnel which will always have the
serving ASN-GW's MAC address for destination and  BS' MAC address for
source, and all the downstream packets destined for the SS or CPE's are
send by the ASN-GW via the GRE tunnel with the source MAC address of the
serving ASN-GW and destination MAC address of the BS.

For the anchored "bridge" even though the packets look almost the same
on level-0 they are different. Since the packets are coming through an
arbitrary network it is safe to assume that multiple GRE tunnels from
different serving ASN-GW's will be connected through a single physical
router port. In which case multiple GRE tunnels will have the same
source and destination depending on the direction the packets are
traversing. Since all the GRE packets are traversing arbitrary network
it is possible that these packets being received out of sequence of some
of these packets being dropped.

ii. Layer 1: This is the GRE aware layer of the "bridge" on this level
the "bridge" knows the individual GRE flows most probably via the IP
addresses. This layer is defined for the sake of completeness only and
hopefully there will not be any need to use this layer.

On this level the bridge has as many ports/interfaces as BS's and
serving ASN-GW's. It is further assumed that the bridge loop detection
will be performed on this level.

iii. Layer 2: On this layer each "GRE key" acts as an port/interface. On
this level the "bridge" can see the GRE payload and sees the MAC address
of the source and destination for the SS or CPE packets. For the sake of
taxonomy a bridge working on this level will be referred as
"hyper-bridge" to make the distinction from the bridges that generally
work on level-0.

Since the "connection" to GRE-key mapping has two forms it is important
look these cases separately:

iii.a. Per SS GRE-key: In this scheme the BS merges all the
"connections" that are coming from a specific SS and send them using the
same GRE-key. For the reverse direction the BS upon receiving a packet
by applying the per flow classifiers as defined in 802.16 series.

This case is the simplest of two, for which each SS will have an
interface at level_2 "hyper-bridge" with symmetric operations.

iii.b. Per connection GRE-key: In this scheme the BS uses a GRE-key for
each connection in both directions. Since there are no restrictions on
how the "connection" classifiers are to be set it is not possible to
predict how they will look like. Even in this case the "hyper-bridge"
needs the information regarding the paired ingress and egress ports.
This is due to the fact that the packets may be send and received
through different GRE-keys and the bridge has no means of automatically
figuring how to pair ingress and egress GRE sub-tunnels.

To give some examples and their implication at "hyper-bridge" level: 

iii.b.I. There is a specific "connection" for one or many CPE's
(including SS) in both directions. 

The fact that the GRE sub-tunnels can be paired helps a lot, but the
fact that there are interface bundles that belong to the same broadcast
group makes the broadcast and multicast decisions very hard on the
"hyper-bridge" level.

iii.b.II. There is one upstream "connection" and a number of downstream
"connections". 

In this case the "hyper-bridge" needs to decide which connection the
"hyper-bridge" generated packets is to be sent, meaning that the ingress
port and egress ports will be different for the "hyper-bridge" in other
words the connection classifier information is to reside in the
"hyper-bridge".

iii.b.III. There are a number of upstream and downstream "connections".

This is the most general case that the "hyper-bridge" generated packets
needs to be applied to the same classifiers as the connections meaning
that the information is to reside in the "hyper-bridge" as well.

Above levels can be summed as illustrated below:

                                      Hyper-bridge

                                        Level_2

         Level_0   Level_1             _________             Level_1
Level_0

Physical | GRE_1        |   GRE_1-Key1 |        |GRE_1-Key1    | GRE_1
|

Port     |/=============|==------------|
|------------==|=============\| Physical

=========| GRE_2        |  |GRE_1-Key2 |        |GRE_1-Key2 |  | GRE_2
| Port

BS       |==============|  \-----------|        |-----------/
|==============|======== AR

or       |  ...         |  ...         |        |   ...        |  ...
|      ASN-GW

Router   | GRE_n        | GRE_n_Key_m  |        | GRE_n-Keym   | GRE_n
|

Port     |\=============|--------------|
|--------------|=============/|

Carrying |              |              ----------              |
|

Multiple |              |                                      |
|

GRE      |              ----------------------------------------
|

flows    |                               level_1 "bridge"
|

from
|--------------------------------------------------------------------|

many              Level_0 "bridge"

BS's.

Coming to normative requirements stated in the draft:

1. Section 5.3 states that: "The BS SHALL forward all the radio
connections belonging to one SS to a port of a bridge between all ports
on the radio side and the interfaces towards the network side."

I guess this means that if BS has multiple interfaces it will send all
the packets through the physical interface that is connected to "the
bridge". I have trouble to understand this requirement, is it desired
that all the packets send through the same GRE tunnel? 

2. Section 5.3 further states: "If the SS functions as a bridge then it
SHALL support a bridging between all its LAN ports and the airlink."

I am not sure why we have this as a requirement, as a principle I am
against mandating unnecessary behavior. Further, I would like to point
out that bridging is not defined. I am surprised to find that
802.1d-2004 is referenced as an informative.

3. The last paragraph/sentence of the section 5.3 states: "When
performing bridging, any packets destined for one of the addresses in
the Filtering Database SHALL be forwarded directly to that port, if
appropriate for the particular scenario, and all packets received from a
port, for which the packet's destination MAC address is also an entry
for that port in the Filtering Database, SHALL be silently discarded."

First since it is not explicitly clear where it is applicable I assume
that this behavior is applicable to both SS as a bridge and the
"bridge". What is missing is the behavior when an entry is deleted from
the Dynamic Filtering Entry. In the non-normative section the
BRIDGETIMEOUT is used without a default value or definition. There is a
non-normative shall that defines the use of BRIDGETIMEOUT that uses the
term traffic but does not describe whether this is for bi-directional
traffic or not.

It is not clear at which level this bridge operates: level_0, level_1 or
level_2? Since the usage of SS (I would like the term CPE and would like
to see CPE to include SS) implies that this is a behavior of
"hyper-bridge". 

If the behavior is for a "hyper-bridge", the issue of interfaces as
discussed in iii.b. is applicable.

4. Section 6.1 states: "In this scenario, the bridge SHALL forward all
packets received from any radio side port to a network side port."

First of all the applicability of this normative statement is not clear,
and second I am missing the difference between this statement and
statement discussed in bullet 1. Having said that, I miss the need for
this requirement.

It is not clear at which level this bridge operates: level_0, level_1 or
level_2? The only evidence is against the level_0 is the fact that this
defined behavior completely disables R8 interface of WiMAX
specifications.

5. Section 7.2 states: "The bridge SHALL have the ability to enable or
disable any filtering functionality defined herein."

It is not clear whether this is a flow specific or not. At this point of
time my interpretation is that this is a global switch.

6. Section 7.2 further states: "If a packet is filtered it SHALL be
silently discarded."

It is not clear at which level this bridge operates: level_0, level_1 or
level_2? The context implies that this is a level_2 functionality
thereby the bridge is actually a "hyper-bridge".

One of the side-effects of being a "hyper-bridge" is the fact that
whenever a packet is dropped it, it will not be send through the GRE
tunnel, and whenever a new packet is to be send by the "hyper-bridge"
needs to insert an additional packet into the GRE tunnel with relevant
GRE-key. 

The insertion/removal of GRE packets make the case that the GRE sequence
numbers cannot be used without making the "hyper-bridge" a kind of
back-to-back GRE relay that re-sequences.

If there are no re-sequencers in the "bridge" and sequence numbers are
being used there needs to be either a dummy packet insertion or a
missing packet within the GRE tunnel. Due to the fact that the missing
sequence numbers has the impact of delaying the packets out of the
tunnel, it is assumed that the dummy packet generation method is being
suggested. For the sake of compatibility the dummy packet is to be
defined clearly.

7. Section 7.2 states that: "The bridge SHALL support filtering of all
packets received from a network side port to a destination MAC address
or Multicast IP address not existing in the ICT or expired address."

If this sentence is taken to its face value, there is no way that an
expired address to be reached by an external communication. 

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2. 

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner MAC
address, and than makes a lookup against its Identification Cache Table,
if the entry does match it sends the GRE packet to the port stated in
the ICT.

8. Section 7.2 states that: "The bridge SHALL support filtering of all
packets received from a network side port to a broadcast or all-nodes
multicast MAC address."

What this requirement does is disabling the all means of communication
from the network if the CPE MAC address has expired. When the fact that
there are no normative requirements on the "bridge" to learn is added,
it is very hard to have a predictable behavior between the "bridges"
that are within this draft.

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner MAC
address, if the inner MAC address is broadcast, removes the packet and
sends the next packet with next sequence number (if sequence numbers are
being used) to the ASN-GW thereby creating a hole in the GRE sequence.  

One question regarding the requirement is that some DHCP Offers are send
as MAC broadcast messages, and this requirement prevents these hosts to
get an IP address.

9. Section 7.2 further states: "The bridge SHALL support filtering of
all packets received from a network side port to a broadcast or
all-nodes multicast MAC address.

I am not sure why this restriction is in place. 

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner MAC
address, and if the packet is coming from a radio side level_2 interface
and the MAC address is broadcast the "hyper-bridge" deletes the packet
and sends the next packet with next sequence number (if sequence numbers
are being used) to the ASN-GW thereby creating a hole in the GRE
sequence.

10. The last paragraph/sentence on section 7.2 states that: "If
filtering is enabled the bridge SHALL permit all Address Resolution
Protocol messages to pass to the ARP Proxy Agent and all Neighbor
Discovery messages to pass to the Neighbor Discovery (ND) Relay Agent
for additional processing as specified in following section."

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". It is important to note
that the proxy ARP referred receives packets that are within GRE tunnel
and send packets through GRE tunnel.

11. The Section 7.3 states: "For IPv4 over Ethernet, ICT contains MAC
address and Port Map, which constitute a filtering entry in Filtering
Database, tunnel ID, lifetime, and one or more unicast and multicast
IPv4 addresses."

The mentioning of the tunnel ID strongly suggests a "hyper-bridge"
operation. The problem of ingress and egress tunnel-ID has no solution
offered and has to be mentioned using two tunnel ID's.

12. Section 7.4 states that: "The AR SHALL have packet-relay
functionality."

The packet-relay is not defined within this document and since document
only as informational references this is a hard to test item if not
impossible.

13. Section 8.1.1 states that: "The bridge SHALL support an ARP Proxy."

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner
packet, if the inner packet is ARP, it passes the packet to the proxy
ARP. The Proxy ARP resolves a return MAC address which is set by an
undetermined method. Than it will construct an ARP Reply packet and
through an undetermined method decides which GRE sub-tunnel (GRE-key)
will be used (see iii for issues). Next it will construct a GRE
encapsulation, the GRE sequence number has to be recalculated, and than
send it to the proper BS. 

These are some of the issues that has to be cleared before a through
reading of the draft can be carried out.

-burcak