[16NG] question about RFC4840
"Wei Gengyu" <weigengyu@vip.sina.com> Tue, 17 April 2007 06:28 UTC
Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1HdhB9-0007jk-Oo; Tue, 17 Apr 2007 02:28:39 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1HdhB8-0007je-5M
for 16ng-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 02:28:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HdhB7-0007jW-Q5
for 16ng@ietf.org; Tue, 17 Apr 2007 02:28:37 -0400
Received: from smtp.vip.sina.com ([202.108.3.172])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdhB3-0001TM-O1
for 16ng@ietf.org; Tue, 17 Apr 2007 02:28:37 -0400
Received: from DELLWEI (unknown [211.160.21.17])
by smtp.vip.sina.com (SINAMAIL) with ESMTP id 3670544A4CF
for <16ng@ietf.org>; Tue, 17 Apr 2007 14:28:23 +0800 (CST)
Message-ID: <000c01c780b9$934e3630$d936fea9@DELLWEI>
From: "Wei Gengyu" <weigengyu@vip.sina.com>
To: <16ng@ietf.org>
Date: Tue, 17 Apr 2007 14:28:12 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 0.4 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Subject: [16NG] question about RFC4840
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0715536783=="
Errors-To: 16ng-bounces@ietf.org
Hi! all, I have a prolem of rfc4840. In section 2.2 multicast/broadcast: In wireless media where data rates to specific destinations are negotiated and may vary over a wide range, it may be more efficient to send multiple frames via link-layer unicast than to send a single multicast/broadcast frame. For example, in [IEEE-802.11.2003] multicast/broadcast traffic from the client station (STA) to the Access Point (AP) is sent via link-layer unicast. It is because it usually is physical "unicast" from the STA to the AP. It is the point to point link. As there is no words about the link from AP to STA, the following recommendation seems to be problematic. Recommendation: Where support for link-layer multicast/broadcast is problematic, limit the propagation of link-scope multicast and broadcast traffic by assignment of separate prefixes to hosts. In some circumstances, it may be more efficient to distribute multicast/broadcast traffic as multiple link-layer unicast frames. In many circumstances, it is less efficient to distribute multicast/broadcast traffic from AP to STA in multiple unicast frames. I want to know what are the circumstances that the author wrote. Regards, Gengyu
_______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] question about RFC4840 Wei Gengyu