[manet] DLEP and broadcast/multicast

Vikram KAUL <vkaul@research.telcordia.com> Mon, 15 August 2011 15:13 UTC

Return-Path: <vkaul@research.telcordia.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A0121F8C41 for <manet@ietfa.amsl.com>; Mon, 15 Aug 2011 08:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level:
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB9rcPaaeMA4 for <manet@ietfa.amsl.com>; Mon, 15 Aug 2011 08:13:49 -0700 (PDT)
Received: from flower.research.telcordia.com (flower.research.telcordia.com [128.96.41.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC1621F8C40 for <manet@ietf.org>; Mon, 15 Aug 2011 08:13:49 -0700 (PDT)
Received: from vkaul7-t61.research.telcordia.com (vpntnlA77.research.telcordia.com [128.96.58.77]) by flower.research.telcordia.com (8.14.2/8.14.2) with ESMTP id p7FFEY4p021982; Mon, 15 Aug 2011 11:14:34 -0400 (EDT)
Date: Mon, 15 Aug 2011 11:14:30 -0400
From: Vikram KAUL <vkaul@research.telcordia.com>
To: manet@ietf.org
Message-ID: <alpine.WNT.2.01.1108151053430.5496@vkaul7-t61>
User-Agent: Alpine 2.01 (WNT 1266 2009-07-14)
X-X-Sender: vkaul@mailee.research.telcordia.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Subject: [manet] DLEP and broadcast/multicast
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 15:13:50 -0000

Folks

  I have some questions about how DLEP handles multicast/broadcast traffic 
and the intents that the router might have to send to the modem device. 
Some of this might have been answered; but I couldn't find it in the 
archives

  The inherent nature of DLEP seems focused on neighbor relationships and 
link characteristics (MDR, CDR, Latency, etc) are focused on individual 
neighbors as identifed by the 'MAC Address Sub-TLV' which is mandatory in 
most of the messages

  My question is related to broadcast and/or multicast traffic that would 
emanate from a router. Let us presume that the underlying multicast 
protocol is SMF for ease of discussion... but it could be anything that 
forwards native multicast packets, either via flooding or after creating 
trees.

  How can one use DLEP to specify the MDR/CDR or latency requirements for 
those flows ? Is it even possible to do so ? I understand how one could do 
it for individual links to neighbors. But if I presume that multicast and 
broadcast is the predominant traffic (say 70%-80%, and I don't believe I 
am wrong about that), how can one use DLEP   "Link Characteristics Request 
Message" to specify that traffic to a particular MAC address should be 
able to get at least what is specified by the CDR Sub-TLV

  Typically (but not always) MAC addresses for multicast IP packets are set 
to  01:00:xx:yy:zz:aa for a destination multicast address of xx.yy.zz.aa. 
Could one not have that 01:00:xx:yy:zz:aa MAC Address Sub-TLV so that the 
modem could identify that traffic to that MAC Address (and hence traffic 
to that destination multicast IP address) needs to get at least that data 
rate. How the modems would achieve that is a separate question, but DLEP 
does not delve into those answers anyway

  Again, it might be that the charter for DLEP is to focus specifically on 
one-to-one relationships (and hence one-to-one specifications and 
conditions). Could the specs not be augmented to support something on 
one-to-many specifications ? Just thinking aloud.

regards..
Vikram