Subject: [16NG] (2nd) WG LC on draft-ietf-16ng-ip-over-ethernet-over-802.16-05.txt

From: gabriel montenegro <[email-masked]>
Date: Wed, 12 Mar 2008 11:29:06 -0700 (PDT)

Folks,

Per yesterday's meeting, we're initiating a short 2nd working group last call on:

    Transmission of IP over Ethernet over IEEE 802.16 Networks
    http://tools.ietf.org/html/draft-ietf-16ng-ip-over-ethernet-over-802.16-05

This WG LC will run until Friday March 21, 2008.

thanks,

-gabriel (16ng co-chair)

_______________________________________________
16NG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/16ng

---

From: "Sangjin Jeong" <[email-masked]>
Date: Tue, 18 Mar 2008 13:18:01 +0900

Hello Gabriel,

Thanks for initiating the WGLC on the IP over EthCS document.
However, it seems that there is a problem on the URL below.
When I clicked the URL, IPv4 CS document was opened.

Regards,
Sangjin

----- Original Message ----- 
From: gabriel montenegro 
To: [email-masked] 
Sent: Thursday, March 13, 2008 3:29 AM
Subject: [16NG] (2nd) WG LC ondraft-ietf-16ng-ip-over-ethernet-over-802.16-05.txt

Folks,

thanks,

-gabriel (16ng co-chair)

--------------------------------------------------------------------------------

---

From: "Riegel, Maximilian (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 18 Mar 2008 10:42:11 +0100

Hi Sangjin,
 
The links works for me. Actually the IPoETHo802.16 document is popping
up.
 
Bye
Max

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Sangjin Jeong
Sent: Tuesday, March 18, 2008 5:18 AM
To: gabriel montenegro
Cc: [email-masked]
Subject: Re: [16NG] (2nd) WG
LCondraft-ietf-16ng-ip-over-ethernet-over-802.16-05.txt

Hello Gabriel,

Regards,
Sangjin
 
----- Original Message ----- 
From: gabriel montenegro <mailto:[email-masked]>  
To: [email-masked] 
Sent: Thursday, March 13, 2008 3:29 AM
Subject: [16NG] (2nd) WG LC
ondraft-ietf-16ng-ip-over-ethernet-over-802.16-05.txt

Folks,

Per yesterday's meeting, we're initiating a short 2nd working group last
call on:

http://tools.ietf.org/html/draft-ietf-16ng-ip-over-ethernet-over-802.16-
05
<http://tools.ietf.org/html/draft-ietf-16ng-ip-over-ethernet-over-802.16
-05> 

thanks,

-gabriel (16ng co-chair)

________________________________

---

From: Burcak Beser <[email-masked]>
Date: Fri, 21 Mar 2008 18:59:39 -0700

Even though the draft is chartered to have "define IPv4 operation including the transmission of IPv4 over IEEE 802.16 links" the draft focuses on a very specific 802.16 transport for a specific kind of devices; namely OFDMA and portable devices. Today, the biggest 802.16 deployment does not use OFDMA and does not have any portable devices. This hidden scope can be observed through many places.

Moreover, the draft touches on issues such as "the reduced transmission efficiency of multicast CIDs for small multicast groups", "additional security threats of broadcast channels" without any explanation. As far as my understanding goes these assertments are not correct and should explained further or at least be discussed within this group. Even the figure 1 omits the broadcast and multicast CID's. It is important to note that broadcast channels are critical for functioning of 802.16 transport.

The draft further develops the concept of  "Network Bridge" which is a non-standard network entity which is not a bridge. This entity is a means of extending individual SS connections to a logical/physical port. I still do not understand why this non-bridging network-bridge has to be 802.1D compliant. At the same time the introduction of non-bridging network-bridge surrounded by normative 'shall's prevent anyone to implement multicast properly as the 802.16 transport intended. It is curious that all normative 'shall's are used for building this non-bridging network-bridge and all  other functionality is hinted using normative 'should's. One normative 'must' is on a sentence that I could not decipher where it should be applied.

The draft alludes "due to the reduced transmission efficiency of multicast CIDs for small multicast groups" which I could not understand. If there are two SS' that are within the same multicast group I can set a multicast CID that will be received by them only. Which would have the right connection parameters that this would be at more efficient than double unicast case. The draft talks about devices powering up and wasting battery power. I do not understand how it is the case that these packets are not received by  MS' if the packets are multi-unicast at the AR?

The statement ""While this behavior is desirable for multicast and broadcast traffic, it is harmful for link layer broadcast control messages aimed for a single SS, like an ARP Request.  All other SSs are wasting scarce battery power for receiving, decoding and discarding the message." needs further explanation. I would like to understand if I move the ARP and DHCP behaviour as specified to BS, and prevent all other broadcast messages to reach to MS' what is the difference. With an equivalent functionality I do not see any functional difference between enabling multicast/broadcast services but better efficiency once the multicast is being used.

As for the specific issues:

(section 4.3) "the succeeding EAP authentication phase" this is not true for [802.16 ]

(section 4.3) "While MAC addresses are assigned to all the SSs as well as the BS, the forwarding of packets over the air is performed only on base of the CID value." As far as I can see this implies that the SS processes/forwards the packets based on CID not MAC address which I believe is not the case.

(section 4.3) "Not relying on the MAC addresses in the payload for reception of a radio frame allows for the transport of arbitrary source and destination MAC addresses in Ethernet frames between a SS   and its BS." Does this sentence imply that two attached hosts communicating between them will have spillover of communion to BS?

(section 4.3) "Due to the managed assignment of the service flows and associated CID values to individual SSs, the BS is able to bundle all connections belonging to a particular SS into a single link on the network side..." this is only true if broadcast/multicast connections are not used otherwise this statement is not correct.

(section 5.2) "Current IEEE 802.16 [802.16][802.16e] does not define broadcast and multicast of IP packets." 802.16 defines broadcast and multicast of  IPv4oEth packets on downstream and is unicast on upstream. The proper terminology must be used.

(section 5.2) "Hence IP broadcast and multicast packets SHOULD be replicated and then carried   via unicast transport connections as IEEE 802.16 access link. " if the previous sentence is correct why this is a normative 'should'?

(section 5.3.1) "In the Public Access scenario, direct communication between nodes is restricted because of security and accounting issues. " The word 'restricted' mmust be clarified. Restricted means different things to different people.

(section 5.3.1) "The AR MAY perform security filtering, ..." does this imply that BS cannot do security filtering, policing and accounting. If the answer is yes than we do not need to use normative language here.

(section 5.3.2) "The enterprise LAN scenario assumes trust relationship between all hosts and thus enables hosts to directly communicate with each other without detouring." I certainly do not agree with the case that two enterprises will trust each other just because they connectto the same BS.

(section 6) "Network-side bridge is based on [802.1D]" what is the functionalitythat is taken from [802.1D]?

(section 6.1) "lower side port " undefined term.

(section 6.1.1)  "all packets originated from a SS SHOULD be delivered to an AR." how about the packets originated from hosts behind the SS?

(section 6.1.2) "IP unicast packets from either SSs or AR SHALL be forwarded by [802.1D] based bridging. " to me this requirement wis over "all packets originated from a SS SHOULD be delivered to an AR" requirement of section 6.1.1.

(section 6.2.) IPv4CS will not carry VLAN packets. So the complete section "Segmenting the Ethernet into VLAN" should be deleted.

(section 6.3) "All multicast and multicast control messages SHOULD be processed in the network-side bridge according to [RFC4605]. " why this is a 'should'? this must be a normative 'must'.

(section 6.3.1.) "Usually, bridges replicate the IP multicast packets and forward them into all of its available ports with the exception of the incoming port, like IP broadcast packets.  As a result, the IP mlticast packets would be transmitted even to SSs which do not participate in the corresponding multicast group. " I would like to state that this is a problem of the system defined. The use of filters for mapping traffic to CID prevents unwanted packets to be transmitted to SS'. he senetence should be deleted.

(section 6.3.1) 'simple tree topology' must be defined.

(section 6.3.2) "The typical bridge floods the IP broadcast packets out of all connected ports except the port on which the packet was received" this is not correct, the sentence should be deleted.

(section 6.4.1) "The network-side bridge SHOULD filter broadcast ARP Requests and  SHOULD respond to all the ARP Requests from lower side port with the access router's Ethernet MAC address so that all IPv4 packets from SSs are forwarded to the access router." I am sure that standard routers will have a lot of fun, receiving packets within the same subnet. I do not understannd the reasoning.

(section 6.4.2)  "The network-side bridge SHOULD maintain an ARP Cache large enough to accommodate ARP entries for all its serving SSs." Since this is a should what happens if it is not large enough and a MAC address needs to be dropped?

(section 6.4.2) "Otherwise, the network-side bridge MAY flood the ARP Requests." doe sthis mean that the bridge now has to multiply the packet as many as SS' and flood the metwork with many of the same packet, and send it to the AR as well.

(section 7) "The Redirect message SHOULD be suppressed." why this is a 'should', it must be a normative 'must'.

(section 9.1.1) "Alternatively, the DHCP Relay Agent Information Option (option-82)   [RFC3046] MAY be used to avoid DHCP broadcast replies." As far as I remember the option 82 does not prevent the broadcasting of  broadcast offer messages.

(section 9.1.2) "SSs MUST use Address Resolution Protocol (ARP) [RFC0826] for finding an Ethernet MAC address of destination." after all normative 'should's why this is a 'must'? it should be anormative 'should'.

(section 9.2) "In this document, encapsulation of IPv6 packets into Ethernet frames and mapping rules for IPv6 address to Ethernet address (i.e.  MAC address) MUST follow [RFC2464]." This is a normative requirement for this document. why? the sentence should be deleted.

(section 9.3) As far as I can see this document states there is no MTU limitation. I understand the historical value but if this is a solved problem there is no need for discussion. The section 9.3 must be deleted.

(section 9.3)  "Therefore, IEEE 802.16 frame SHOULD support for carrying 1518 bytes payload that includes 18 bytes Ethernet header and 1500 bytes IP packet." first this is a requirement for 802.16 which is not the right place. Secod no matter what the SDU size is 802.16 transport can communicate any size PDUs. I am not sure where this SDU/PDU mixup started but the same issue exists in other drafts as well.

(section 9.3) "Therefore, the network operator should consider the size of stacked VLAN tags when implementing VLAN and setting the MTU of the link." the sentence must be deleted.

(appendix A) "While similar in nature to a bridging function, there is no appropriate forwarding model available." The whole Cable Access community begs to differ. The model exists and used by millions of not hundereds of million systems.

(appendix A) "[802.1D] cannot take advantage of the multicast CIDs because it relies on unicast connections or bidirectional broadcast connections" unitl now [802.1D] did not stop us from building a non-bridging network-bridge why worry about 802.1D now?

(appendix A) "Furthermore, it should keep in mind that multicast CIDs are only efficient for a large number of subscribed SSs in a cell" this is true even for the large number of 2 SS'. The sentence must be deleted.

(appendix A) "Due to  incompatibility with advanced radio layer algorithms based on feedback information from the receiver side, multicast connections require much more radio resource for transferring the same information as a unicast connections" I really would like to see one example of this. I what is meant is ARQ schemes, there are many applications that will rather drop the packet than get it late. This is a choice but there is no reason for disabling multicast CIDs completely.

Below was my feedback to 1st WGLC which is not addressed at all:

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.

-burcak

---

From: "Riegel, Maximilian (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 25 Mar 2008 20:43:07 +0100

Thanks Burcak for the comments. Please let me first answer the more
general comments before coming back with detailed responses to the
specific issues after consultation with my co-authors.

>-----Original Message-----From: [email-masked] [mailto:16ng-
>[email-masked]] On Behalf Of ext Burcak Beser Sent: Saturday, March
>22, 2008 3:00 AM To: gabriel montenegro; [email-masked] Subject: Re:
>[16NG] (2nd) WG LCon draft-ietf-16ng-ip-over-ethernet-over-802.16-
>05.txt
>
>Even though the draft is chartered to have "define IPv4 operation
>including the transmission of IPv4 over IEEE 802.16 links" the draft
>focuses on a very specific 802.16 transport for a specific kind of
>devices; namely OFDMA and portable devices. Today, the biggest 802.16
>deployment does not use OFDMA and does not have any portable devices.
>This hidden scope can be observed through many places.

The I-D is chartered for IPv4oETH as well as IPv6oETH operation over
802.16.
The I-D does not address specific solutions for legacy 802.16, which was
fixed-only.
It provides a single solution for fixed_to_full mobile operation, which
is the scope of 802.16 for 5 years now.

>Moreover, the draft touches on issues such as "the reduced
>transmission efficiency of multicast CIDs for small multicast groups",
>"additional security threats of broadcast channels" without any
>explanation. As far as my understanding goes these assertments are not
>correct and should explained further or at least be discussed within
>this group. Even the figure 1 omits the broadcast and multicast CID's.
>It is important to note that broadcast channels are critical for
>functioning of 802.16 transport.

Broadcast channels are an essential part of 802.16 MAC operation, but
they are only optional means for transport of payload over 802.16.
Currently there is standardization ongoing to make multicast transport
CIDs usable for multicast and broadcast services, and there are issues
with the 802.16 multicast channels for ETH over 802.16, which are
explained in the I-D. There was even more information available in draft
-02 about the 'reduced efficiency of multicast channels', but we agreed
that radio specifics do not belong into an IETF document. Please go back
to the -02 revision, when you like to learn more about the lower
efficiency.

>The draft further develops the concept of  "Network Bridge" which is a
>non-standard network entity which is not a bridge. This entity is a
>means of extending individual SS connections to a logical/physical
>port. I still do not understand why this non-bridging network-bridge
>has to be 802.1D compliant. At the same time the introduction of non-
>bridging network-bridge surrounded by normative 'shall's prevent
>anyone to implement multicast properly as the 802.16 transport
>intended. It is curious that all normative 'shall's are used for
>building this non-bridging network-bridge and all  other functionality
>is hinted using normative 'should's. One normative 'must' is on a
>sentence that I could not decipher where it should be applied.

It is the aim of the I-D to create a standard for the 'Network Bridge' -
and as for any upcoming standard the content of the specification is not
standardized yet.
The 'network bridge' has to be 802.1D compliant, because 802.1D is the
normative standard for bridging behavior of Ethernet. And if the
'Network Bridge' is compliant to 802.1D, all the widely-deployed and
well-known amendments of 802.1 for Ethernet bridging like 802.1Q,
802.1ad or 802.1ah can be applied without worrying about the consistence
of the specifications. IEEE P802.1 has spend quite some effort to ensure
that the specifications are fitting together.
All requirements to ensure IEEE 802.1 compliant bridging are declared by
'SHALL', functions providing better performance but not being necessary
to realize 802.1 compliant bridging behavior are marked by 'SHOULDs'.
Lower performance does not break network operation, but not being
compliant to IEEE 802.1 bridging may break network operation.
The I-D does not prevent the implementation of multicast services based
on multicast CIDs. Indeed the I-D does not make any use of multicast
CIDs or imposes any restriction on usage of multicast CIDs for multicast
services.

>The draft alludes "due to the reduced transmission efficiency of
>multicast CIDs for small multicast groups" which I could not
>understand. If there are two SS' that are within the same multicast
>group I can set a multicast CID that will be received by them only.
>Which would have the right connection parameters that this would be at
>more efficient than double unicast case. The draft talks about devices
>powering up and wasting battery power. I do not understand how it is
>the case that these packets are not received by  MS' if the packets
>are multi-unicast at the AR?

The issue of reduced transmission efficiency of multicast CIDs is
already covered in the previous paragraph.
There is a main distinction between using multicast channels for
services and using multicast channels for emulation of Ethernet
behavior; it is the difference between intended reception of a multicast
packet vs. not intended reception of a multicast packet. If multicast is
provided by the AR, the MS has to register for a particular multicast
channel and all the data is transferred to the MS by intention and under
control of the MS; the MS is able to deregister from the multicast
service to ensure that it is not waked up unintentionally. There is no
possibility to prevent the reception of 'meaningless' ARP messages (ARP
messages, which are looking for some other MS), when ARP is going over a
multicast channel.

>The statement ""While this behavior is desirable for multicast and
>broadcast traffic, it is harmful for link layer broadcast control
>messages aimed for a single SS, like an ARP Request.  All other SSs
>are wasting scarce battery power for receiving, decoding and
>discarding the message." needs further explanation. I would like to
>understand if I move the ARP and DHCP behaviour as specified to BS,
>and prevent all other broadcast messages to reach to MS' what is the
>difference. With an equivalent functionality I do not see any
>functional difference between enabling multicast/broadcast services
>but better efficiency once the multicast is being used.

What is unclear with the sentence? Processing of packets consumes power,
and consuming power without any reasonable result is waste of power.
Are you asking about relocating the 'Network Bridge' into the BS? Please
keep in mind that BS refers to the logical entity of 802.16, not to the
device commonly denoted basestation. Whether it is feasible to implement
the NetBridge together with one BS into a basestation depends on the
deployment. If the broadcast area is limited to one BS, it should be
fine. But when the broadcast area spans across multiple BSs, the
NetBridge should serve all the BS in the broadcast area.

> ...

We will respond to the specific issues in a separate email.

>Below was my feedback to 1st WGLC which is not addressed at all:

Did you miss our response? We have addressed all your issues in the I-D
and we have even added a whole new annex to provide more information on
the distributed bridging approach. Please find my response to your email
from Sept. 7, 2007:

-----Original Message-----
From: Riegel, Maximilian 
Sent: Friday, September 07, 2007 11:13 PM
To: 'Burcak Beser'; [email-masked]'
Cc: 'Daniel Park'
Subject: RE: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

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

>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 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.
>
>-burcak _______________________________________________ 16NG mailing
>list [email-masked] https://www.ietf.org/mailman/listinfo/16ng