From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, Carsten Bormann
 <cabo@tzi.org>
Thread-Topic: [Roll] [Bier] Source-Routed Multicast
Thread-Index: AQHP+Jc6eJPa1iU6+EqbNCABEErj65xRRsVA
Date: Wed, 5 Nov 2014 02:10:47 +0000
Deferred-Delivery: Wed, 5 Nov 2014 02:10:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A3F9F5@xmb-rcd-x01.cisco.com>
References: <m0tx2f6ec7.fsf@tzi.org>
 <C1655E2B-C081-409A-B90D-8288F26394B2@cisco.com>
In-Reply-To: <C1655E2B-C081-409A-B90D-8288F26394B2@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/wzdHaU_rMRT2A6qbw41yO2vqp9Q
Cc: "Andrzej.Duda@imag.fr" <Andrzej.Duda@imag.fr>,
 "bier@ietf.org" <bier@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [Roll] [Bier] Source-Routed Multicast
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>

State  in BIER (one bitmap per child) is so limited and controlled that a c=
onstrained node that cannot do storing may be able to still do BIER. For su=
ch devices, we could propose a new mode of operation for RPL that is BIER o=
nly, for both unicast and multicast traffic.

If the preferred parent tree is acceptable for downward traffic, the DAOs w=
ould percolate up by ORing the bitmaps of the children and passing that to =
the preferred parent. Decision to forward down to a child (or of a child to=
 process an incoming message) would be a simple AND of the bitmap in the pa=
cket and that of the child, regardless of unicast or multicast.

Cheers,

Pascal


> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of IJsbrand Wijnands
> (iwijnand)
> Sent: mardi 4 novembre 2014 14:28
> To: Carsten Bormann
> Cc: Andrzej.Duda@imag.fr; roll@ietf.org; bier@ietf.org; 6lo@ietf.org
> Subject: Re: [Roll] [Bier] Source-Routed Multicast
>=20
> Hi Carsten,
>=20
> The ROLL case looks very interesting.
>=20
> Just one clarification, BIER is not Source-Routed multicast. i.e. we don'=
t include
> a list of hops that the packet needs to follow, we only include final des=
tination in
> the form of Bit Positions, and each router along the path does a lookup o=
n the
> Bit Position to determine where the packet is to be sent.
>=20
> Thx,
>=20
> Ice.
>=20
> On 03 Nov 2014, at 15:42, Carsten Bormann <cabo@tzi.org> wrote:
>=20
> > In Hawaii, there will be a BOF about a multicast forwarding control
> > scheme where a router on the way prefixes a multicast packet with a
> > special header that tells downtree routers where to forward the
> > multicast - Bit Index Explicit Replication, or BIER.
> >
> > While BIER appears to be very focused on a carrier or datacenter
> > perspective (see draft-kumar-bier-use-cases and the other
> > draft-*-bier-*), there are applications in constrained node networks
> > that would benefit from source-routed multicast.
> >
> > Several proposals on how to do source-routed multicast in constrained
> > node networks are getting ready for consumption.
> >
> > With its current focus, I don't think the BIER BOF itself is the right
> > place to have a technical discussion about this.
> > There is no ROLL meeting in Hawaii.
> > The 6lo agenda is almost full.
> > Should we do this in a side meeting?  (If we do this before Tuesday,
> > we can at least report in 6lo - if we do it on Sunday, we might even
> > have an opinion to air during the BIER BOF.)
> >
> > Gr=FC=DFe, Carsten
> >
> > _______________________________________________
> > BIER mailing list
> > BIER@ietf.org
> > https://www.ietf.org/mailman/listinfo/bier
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll