[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [16NG] Comments ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
Paolo,
Thank you for your comments.
Now we are going to update our draft. It will have lots of change.
The updated draft does not use any tunnels between bridges.
In the updated draft, MAC-Forced Forwarding [RFC4562] can be used
to send all the packets from SSs toward AR in case of public access scenario
and IGMP/MLD snooping [RFC4541] provides an efficient transmission of IP
multicast data.
Also some additional functionalities is to be presented for broadcast
filtering.
Best Regards,
Hongseok
> -----Original Message-----
> From: Narvaez, Paolo (Paolo) [mailto:paolo at alcatel-lucent.com]
> Sent: Thursday, January 11, 2007 5:16 AM
> To: Hongseok Jeon
> Cc: 16ng at ietf.org
> Subject: RE: [16NG] Comments
> ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
>
>
>
>
> Hongseok,
>
> Thanks for the reply. Please find below some additional
> comments to your response.
>
> Thanks,
> Paolo
>
> > -----Original Message-----
> > From: Hongseok Jeon [mailto:jeonhs at etri.re.kr]
> > Sent: Friday, December 22, 2006 5:31 AM
> > To: Narvaez, Paolo (Paolo)
> > Cc: 16ng at ietf.org
> > Subject: RE: [16NG] Comments
> > ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
> > >
> > > Section 5.3 -
> > >
> > >
> > > "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."
> > >
> > >
> > > 2) It does not mention what happens to packets with a MAC
> DA equal
> > > to the MAC address of a SS. These should not be forwarded.
> >
> > It depends on the scenario. In case of public access scenario, the
> > packets should be transmitted to AR and then relayed to the
> intended
> > SS by relaying function on AR. In VLAN scenario, the packets are
> > directly forwarded to the intended SS by bridge.
>
>
> For the public access case, I understand why the AR would
> want to forward a packet back to another SS based on a
> destination IP address.
> But why would the AR forward based on a MAC DA? That MAC
> address should not even have been known to the originating
> SS. In fact, the AR should drop any Ethernet frame with a
> unicast MAC DA that does not match the MAC address of one of
> its interfaces.
>
> If the public access case is supposed to prevent direct
> Ethernet connectivity between SSs, packets with a MAC DA = SS
> MAC address should be dropped. Forwarding them to the AR is a
> waste of bandwidth, since they will be dropped by the AR anyway.
>
>
>
>
> > > Section 6.1 -
> > >
> > > "Figure 3 depicts an IEEE 802.16 network deployment
> scenario without
> > > direct host-to-host communication. In the general
> public access
> > > case, direct communication between nodes is restricted
> because of
> > > security and accounting issues. In this scenario, the
> > bridge SHALL
> > > forward all packets received from any radio side port to
> > a network
> > > side port. Peer-to-peer communication is not supported by the
> > > bridge
> > > and all packets originated from a SS should be delivered
> > to an AR."
> > >
> > > 4) What is the behavior of the bridge in the public
> access scenario
> > > when the Ethernet frame arriving over the air (or from
> the AR) has
> > > one or more VLAN tags? Is the VLAN tag stripped off? Is
> it ignored?
> > > Are SSs and ARs forbidden from sending VLAN-tagged frames to the
> > > bridge?
> >
> > Public access scenario does not consider Ethernet frames
> embedded with
> > VLAN tag.
> > Ethernet frames with VLAN tag are handled in VLAN scenario
> and we will
> > provide the detail procedures in next version document.
>
> In the public access scenario how do you guarantee that the
> terminal does not send Ethernet frames with VLAN tags? How
> does the bridge react if this happens? The text should
> explain how this is prevented or should explain how the
> bridge deals with these packets.
>
>
>
> > > Section 7.2 -
> > >
> > > "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."
> > >
> > >
> > > 7) What happens if there are multiple network side ports? In that
> > > case, I think you would want to filter broadcasting to the air
> > > interfaces, but you will still want to broadcast on the remaining
> > > network ports.
> >
> > Filtering in this document focuses on multicast data, and
> broadcasting
> > data destined for sleep mode SSs. Broadcast data for
> wake-up SSs does
> > not be filtered. Hosts in network side always wake up and thus
> > broadcast data for the host does not need to be filtered.
>
> I agree. The document should make a distinction between the
> different types of ports and clarify that filtering only
> applies to the air ports.
>
>
>
> > > Section 7.6 -
> > >
> > > "The AR SHALL have packet-relay functionality. The AR
> > relays packets
> > > destined for IP broadcast address and link-local
> scoped multicast
> > > addresses to incoming interface again. When relaying,
> > AR does not
> > > decrease the value of TTL or Hop Limit."
> > >
> > > 8) Can this on-link packet-relay functionality be
> performed at the
> > > bridge instead of the AR? Since the bridge already has several
> > > IP-snooping capabilities (ARP-proxy, ND-relay) and has
> knowledge of
> > > IP addresses, it seems that it could also perform this
> function. In
> > > this case, the AR would not require any modifications and would
> > > behave like a standard AR. The bridge requires modifications
> > > anyways.
> >
> > The position of packet-relay functionality on AR is based on the
> > assumption which all traffics from SS should be transmitted
> to AR in
> > the public access scenario.
>
>
> I understand that the current draft is placing the relay
> functionality in the AR. My question is about the rationale
> behind it. It seems that this functionality could also be
> performed by the bridge. Two benefits of placing this
> functionality at the bridge is that 1) it eliminates the
> round-trip multicast traffic to and from the AR and 2) no
> modifications are required at the AR (the AR is a standard
> router). Therefore, what is the design rationale for placing
> the relay functionality in the AR?
_______________________________________________
16NG mailing list
16NG at ietf.org
https://www1.ietf.org/mailman/listinfo/16ng