Subject: [pim] manet: IP multicast comments

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jul 2014 03:00:19 -0700

Having not followed Manet for a couple of years, and sat in yesterdays
meeting, where there was a question about multicast,  some questions and
comments:

(1) It sounded to me as if every MANET solution support IP multicast
flooding, but thats pretty much it ? What for example would
be the solution for flooding when you use eg: OSPF with Manet
extensions ? SMF ?

(2) There seemed to be some interest in working on BTF (Metter Than
Flooding) IP multicast protocols (a), but also (b) some concerns about
work overload that this might result in for manet.

(2a) Is there any write down of use cases in Manet that require
such BTF IP multicast services with manet ? If yes, please provide
pointers, if not, i'd suggest that is the first thing to write down.

I got the understanding that eg: the evolution from SA (situation
awareness == very low bitrate) as the prime use case to also
voice/video group communication is such a typical use case for BTF 
multicast, but without it being written down and prioritized, it is
IMHO premature to proceed on protocol work.

And there is a lot more than just prioritization of work to get
from the use cases details. For example, since 2000, we do have
in the IETF two IP multicast service models. The traditional
group-join one, we now call ASM (Any Source Multicast), and
SSM, where the application has to know the source IP address,
and includes it in IGMP membership reports. SSM simplifies
BTF solutions drastical. It also increases security (not
attacks by unwanted sources). So the use case analysis needs to
vet whether SSM is an appropriate service or not for the use
case.

(2b) The routing ADs seem to be running around trying to do
load-balancing of work across WGs, so it might be feasible to
proceed with eg: protocol work for manet compatible IP multicast
in the IP Multicast WG (currently called PIM). From what i
could glean from Alias statements yesterday in PIM WG, they
where primarily thinking of bringing MPLS multicast over to the
Multicast WG, but i think one may want to consider Manet
multicast as well. Nevertheless, see (2a), use-cases should
IMHO be really owned by Manet-WG itself.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jul 2014 03:59:51 -0700

Thanks, Henning,

I understand the partial-mesh properties of manet L2 subnets,
when i said flooding i was asking across a Manet L2 domain.

Also: what kernel ?

On Wed, Jul 23, 2014 at 12:36:50PM +0200, Henning Rogge wrote:
> On Wed, Jul 23, 2014 at 12:00 PM, Toerless Eckert <[email-masked]> wrote:
> I think one main difference with MANET is that you have a
> non-transitive network... just because that you can hear someone on
> interface X does not mean all your neighbors on interface X can hear
> this station.
> 
> This means that multicast packets coming in through an interface
> typically have to be retransmitted through the same interface again.
> 
> I don't even know if there is any kind of kernel support for this kind
> of forwarding.
> 
> Henning Rogge

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jul 2014 05:00:33 -0700

On Wed, Jul 23, 2014 at 11:13:59AM +0000, Dearlove, Christopher (UK) wrote:
> They can't always be retransmitted through the same interface, you may need to use other interface(s) to reach the intended destinations.
> 
> When flooding (as SMF) you would naturally flood through all interfaces.

Well, "natural" flooding outside of MANET wold not send back to the
receiving interface. In Manet this seems to be necessary if the radio does
not do that for you.

> If building a tree you need to ensure the tree has bidirectional branches.

Well, i thought unidirectional link adjacencies are potentially important to
support. Likewise asymmetric links.

Cheers
    Toerless

> -- 
> Christopher Dearlove
> Senior Principal Engineer, Information Assurance Group
> Communications, Networks and Image Analysis Capability
> BAE Systems Advanced Technology Centre
> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Tel: +44 1245 242194 |  Fax: +44 1245 242124
> [email-masked] | http://www.baesystems.com
> 
> BAE Systems (Operations) Limited
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
> Registered in England & Wales No: 1996687
> 
> 
> -----Original Message-----
> From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
> Sent: 23 July 2014 11:37
> To: Toerless Eckert
> Cc: MANET IETF; [email-masked]
> Subject: Re: [manet] manet: IP multicast comments
> 
> ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
> Consider carefully whether you should click on any links, open any attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
> --------------------------------------------------------
> 
> > flooding, but thats pretty much it ? What for example would be the 
> > solution for flooding when you use eg: OSPF with Manet extensions ? 
> > SMF ?
> 
> I think one main difference with MANET is that you have a non-transitive network... just because that you can hear someone on interface X does not mean all your neighbors on interface X can hear this station.
> 
> This means that multicast packets coming in through an interface typically have to be retransmitted through the same interface again.
> 
> I don't even know if there is any kind of kernel support for this kind of forwarding.
> 
> Henning Rogge
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
> 
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
> 

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jul 2014 05:28:26 -0700

On Wed, Jul 23, 2014 at 01:54:03PM +0200, Abdussalam Baryun wrote:
> The multicast routings in MANET is very different than PIM and MPLS.

Can you remember if that reasoning was ever brought before PIM WG ?

> They  have very very different use cases.

Adio/Video conferencing ? Sensoric (telemtry) data flooding ?
I'd be surprised if the use cases turn out to be justifying difference
in architecture. If at all, its the mobility.

> So I support that the WG works on manet
> multicast protocols after finishing unicast protocols. As we can now start
> working on a proactive multicast protocol as we finished OLSRv2. Reactive
> multicast should not be started/adopted until we do our AODVv2.

Any specific reasons to go first with a proactive protocol ?

Btw: It would really be good as i said in anothrer mail to evaluate
the applicability of SSM to the use cases because that allows for the
most simple proactive tree building.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jul 2014 05:38:13 -0700

On Wed, Jul 23, 2014 at 12:35:02PM +0000, Dearlove, Christopher (UK) wrote:
> It depends on whether one views multicast as something special to be done after unicast, or something different. In the former case, as we have a unicast proactive protocol but not a reactive protocol, doing proactive multicast first makes sense. In the latter case, not necessarily. Though there may be an argument that the proactive network is ready - and the unicast routing protocol has information to exploit.

Thats an engineerings "reuse of code" argument.

I was more thinking of use-case requirements. Reactive protocols tend to
have problems delivering first packets reliably unless you go through
additional hoops. Proactive protocols have problems avoiding unnecessary
state and therefore have possible negative scaling impacts to the applications.

Toerless

> From: manet [mailto:[email-masked]] On Behalf Of Toerless Eckert
> Sent: 23 July 2014 13:28
> To: Abdussalam Baryun
> Cc: [email-masked]; [email-masked]
> > > proceed with eg: protocol work for manet compatible IP multicast in 
> > > the IP Multicast WG (currently called PIM). From what i could glean 
> > > from Alias statements yesterday in PIM WG, they where primarily 
> > > thinking of bringing MPLS multicast over to the Multicast WG, but i 
> > > think one may want to consider Manet multicast as well. 
> > > Nevertheless, see (2a), use-cases should IMHO be really owned by 
> > > Manet-WG itself.
> > >
> I'd be surprised if the use cases turn out to be justifying difference in architecture. If at all, its the mobility.
> 
> > So I support that the WG works on manet multicast protocols after 
> > finishing unicast protocols. As we can now start working on a 
> > proactive multicast protocol as we finished OLSRv2. Reactive multicast 
> > should not be started/adopted until we do our AODVv2.
> 
> Btw: It would really be good as i said in anothrer mail to evaluate the applicability of SSM to the use cases because that allows for the most simple proactive tree building.
> 
> Cheers
>     Toerless
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jul 2014 06:10:56 -0700

On Wed, Jul 23, 2014 at 12:56:51PM +0000, Dearlove, Christopher (UK) wrote:
> I think that was more than a reuse of code argument, and if that's all you think it was, you've missed the point that it's about what networks might already exist.

Well, i read: If one views multicast as something special to be done after unicast,
and unicast is proactive, then doing proactive multicast first makes sense. You
didn't say whether this meant specs or deployment ;-)

Be that as it may: In non-manet networks, we always only had proactive unicast,
but that didn't stop us to do reactive and proactive multicast protocols, so i am
not sure what deploymnet or spec benefits i could have with that reasoning - unless
of course the multicast protocol is directly an extension of the unicast protocol.
That was the line of thinking up until 1994 when folks figured it doesn't make a
lot of sense trying to counterfit multicast into every IGP.

> But on your points, if there's already a proactive unicast protocol, you've already committed to much of the state. I also wouldn't call it unnecessary state, if it were unnecessary it wouldn't be collected. It's more a necessary evil to achieve your other objectives.

I as just talking about multicast state, not unicast state. Outside of
Manet, there are not a lot of folks interested in reactive unicast routing.

Cheers
    toerless

> From: Toerless Eckert [mailto:[email-masked]] 
> Sent: 23 July 2014 13:38
> To: Dearlove, Christopher (UK)
> Cc: Abdussalam Baryun; [email-masked]; [email-masked]
> I was more thinking of use-case requirements. Reactive protocols tend to have problems delivering first packets reliably unless you go through additional hoops. Proactive protocols have problems avoiding unnecessary state and therefore have possible negative scaling impacts to the applications.
> 
> Toerless
> 
> > --
> > Christopher Dearlove
> > Senior Principal Engineer, Information Assurance Group Communications, 
> > Networks and Image Analysis Capability BAE Systems Advanced Technology 
> > Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace 
> > Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales 
> > No: 1996687
> > 
> > 
> > > > in the IP Multicast WG (currently called PIM). From what i could 
> > > > glean from Alias statements yesterday in PIM WG, they where 
> > > > primarily thinking of bringing MPLS multicast over to the 
> > > > Multicast WG, but i think one may want to consider Manet multicast as well.
> > > proactive multicast protocol as we finished OLSRv2. Reactive

---

From: Rick Taylor <[email-masked]>
Date: Wed, 23 Jul 2014 12:56:22 +0000

Toerless, et.al.,

I think you might be talking yourself into writing an informational draft on 'MANET considerations for multicast in reference to the existing state of the art'.

I think we are all agreeing that PIM has done some very good work that those of us in MANET are not aware of, but, as others have pointed out, the MANET group believe there are specific considerations for multicast in MANETs.

I think analysis in this area is very necessary, before we start reinventing each other's work.  Then it's just up to the AD's whether this happens in MANET or PIM.

Regards,
Rick Taylor
________________________________________
From: manet [[email-masked]] on behalf of Toerless Eckert [[email-masked]]
Sent: 23 July 2014 13:38
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] manet: IP multicast comments

Toerless

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jul 2014 12:36:50 +0200

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jul 2014 13:02:44 +0200

> Also: what kernel ?

let me rephrase this to "Operation system support"...

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Jul 2014 11:13:59 +0000

When flooding (as SMF) you would naturally flood through all interfaces. If building a tree you need to ensure the tree has bidirectional branches.

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 23 July 2014 11:37
To: Toerless Eckert
Cc: MANET IETF; [email-masked]
Subject: Re: [manet] manet: IP multicast comments

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jul 2014 13:54:03 +0200

> IMHO be really owned by Manet-WG itself.
The multicast routings in MANET is very different than PIM and MPLS. They
have very very different use cases. So I support that the WG works on manet
multicast protocols after finishing unicast protocols. As we can now start
working on a proactive multicast protocol as we finished OLSRv2. Reactive
multicast should not be started/adopted until we do our AODVv2.

AB

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Jul 2014 12:27:05 +0000

Radios tend to behave the way physics demands, and we can't stop then doing inconvenient things. Though if we are clever we can use what they do to advantage.

Every MANET protocol in the WG does not supported unidirectional links. That applies to NHDP, OLSRv2, SMF, AODVv2. Making a protocol work with unidirectional links is not straightforward, given that the sender doesn't know if it's a 1-directional link, or a 0-directional link. Blind flooding is the obvious exception that can take advantage of unidirectional links.

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: 23 July 2014 13:01
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; MANET IETF; [email-masked]
Subject: Re: [manet] manet: IP multicast comments

> When flooding (as SMF) you would naturally flood through all interfaces.

Well, "natural" flooding outside of MANET wold not send back to the receiving interface. In Manet this seems to be necessary if the radio does not do that for you.

> If building a tree you need to ensure the tree has bidirectional branches.

Well, i thought unidirectional link adjacencies are potentially important to support. Likewise asymmetric links.

Cheers
    Toerless

> > Having not followed Manet for a couple of years, and sat in 
> > yesterdays meeting, where there was a question about multicast,  
> > some questions and
> > comments:
> >

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Jul 2014 12:35:02 +0000

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Toerless Eckert
Sent: 23 July 2014 13:28
To: Abdussalam Baryun
Cc: [email-masked]; [email-masked]
Subject: Re: [manet] manet: IP multicast comments

Cheers
    Toerless

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 23 Jul 2014 12:56:51 +0000

I think that was more than a reuse of code argument, and if that's all you think it was, you've missed the point that it's about what networks might already exist. But on your points, if there's already a proactive unicast protocol, you've already committed to much of the state. I also wouldn't call it unnecessary state, if it were unnecessary it wouldn't be collected. It's more a necessary evil to achieve your other objectives.

-----Original Message-----
From: Toerless Eckert [mailto:[email-masked]] 
Sent: 23 July 2014 13:38
To: Dearlove, Christopher (UK)
Cc: Abdussalam Baryun; [email-masked]; [email-masked]
Subject: Re: [manet] manet: IP multicast comments

Toerless

---

From: Joseph Macker <[email-masked]>
Date: Wed, 23 Jul 2014 10:57:31 -0400

Toerless:

Thanks for your comments. Sorry rewinding the thread a bit for some
historical perspective in case it helps.

> be the solution for flooding when you use eg: OSPF with Manet

Many moons ago the Manet WG rechartered to make  more focused engineering
progress in the unicast areas and optimized flooding areas. Years ago there
used to be a slew of group-specific multicast discussions, work (both
reactive and proactive),  and proposals including SSM-related ones,etc. In
the last several meetings there has been some revisiting of these older
ideas with IDs ODMRP and adaptive multicast (adapts between flooding and
path-optimization as convergence/reliability allows).  Both of the newer
IDs build off of progress made in other areas.

Related to your other above question there have been successful live
experiments with OSPF-Manet variants and SMF.  Where SMF shared the
optimized control plane info of OSPF-Manet, not saying this it the right
thing to use in many deployments but its been demonstrated.  Nonetheless,
SMF is intended to be a limited application case design.

> work overload that this might result in for manet.

I am perhaps less worried about workload but some have raised concerns
about technical engineering maturity.  I believe progress has been in some
areas here over the years and there is room for this but if pursued it has
to be scoped.

> vet whether SSM is an appropriate service or not for the use

Definitely good points before the "now old" rechartering these tradeoffs
were discussed alot within the manet community..  There was also an
"explicit group" multicast proposal as well as SSM discussions.  At that
time lots of manet people were also working with PIM solutions at least for
gatewaying,etc.

I think MANET includes a rich set of application needs and multicast is
very important. Pub/sub data services, streaming services, control,
discovery are potential examples.

We do need to discuss the models, but also the convergence/reliability
issues tend to dominate the manet /mesh specific tradeoff and design space
as well as the potentially the need for support mechanisms (e.g., dup
detection). So the specific design challenges are an important part of any
design here.

> IMHO be really owned by Manet-WG itself.

Personally I have worked alot with variants of PIM in the past.  Especially
gatewaying to/from MANET type networks.  It would be good to have more
cross discussions.

---

From: "Snyder, Brian" <[email-masked]>
Date: Wed, 23 Jul 2014 15:26:15 +0000

>This means that multicast packets coming in through an interface typically have to be retransmitted through the same interface again.

I think if satellite is to be considered a use case for MANET then that can't be taken as a constant truth.  In satellite we aren't necessarily trying to build MESH networks (in fact that is much less common) but we are still interested in MANET to help us pass link state and we still have a lot of mobility (in terms of modems moving between beams / satellites while mobile).  So from a multicast requirement, we need there to be the notion on the hub side that all downstream (the broadcast outroute)  multicast is only ever sent once, regardless of how many actual DLEP peers are established in this direction.  If end devices use igmp, pim, etc to get upstream devices to forward said multicast - great - the radio doesn't have to know or care since it's a broadcast - if anyone wants it at all, everyone else has the opportunity to see it for free.

In trying to unwrap the implementation I am familiar with from the standard (thanks to many conversations on this list), I believe this may be possible in theory now. I was thinking one could setup one 'virtual' DLEP peer that registers for all multicast and broadcast mac address towards my radio.  That way my radio can then see all multicast to forward it, regardless of actual individual clients being subscribed or not. (or even *in network*).    Is this understanding correct?

thanks,
brian

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jul 2014 17:38:41 +0200

On Wed, Jul 23, 2014 at 5:26 PM, Snyder, Brian <[email-masked]> wrote:
> I think if satellite is to be considered a use case for MANET then that can't be taken as a constant truth.

Its a constant truth for MANET protocol design because its a common
thing in MANET deployments.

Satcom is already a special case (because there is a "special" node,
the hub), but even there the Satcom hub might be forced to retransmit
every multicast received over the satcom link because otherwise the
rest of the clients would not hear multicast from other clients.

>  In satellite we aren't necessarily trying to build MESH networks (in fact that is much less common) but we are still interested in MANET to help us pass link state and we still have a lot of mobility (in terms of modems moving between beams / satellites while mobile).  So from a multicast requirement, we need there to be the notion on the hub side that all downstream (the broadcast outroute)  multicast is only ever sent once, regardless of how many actual DLEP peers are established in this direction.  If end devices use igmp, pim, etc to get upstream devices to forward said multicast - great - the radio doesn't have to know or care since it's a broadcast - if anyone wants it at all, everyone else has the opportunity to see it for free.

> In trying to unwrap the implementation I am familiar with from the standard (thanks to many conversations on this list), I believe this may be possible in theory now. I was thinking one could setup…

I think the idea with multicast and DLEP is that the radio will either
statically announce multicast MACs/IPs or eavesdrop on IGMP (ICMPv6)
messages and handle them internally. The routing agent then can use
them to fill the local arp table.

Your local radio might filter multicast traffic not meant for your
local router, but I think thats an implementation detail not set in
the draft.

Henning Rogge

---

From: "Snyder, Brian" <[email-masked]>
Date: Wed, 23 Jul 2014 17:16:38 +0000

>Its a constant truth for MANET protocol design because its a common thing in MANET deployments.

>Satcom is already a special case (because there is a "special" node, the hub), but even there the Satcom hub might be forced to retransmit every multicast received over the satcom link because otherwise the rest of the clients would not hear multicast from other clients.

Whilst that is true... it is very common in satellite products (at least in my experience) that the radio will hairpin inroute multicast traffic if it is so configured to do so.  However, inroute multicast is quite rare of a use case in actuality.  Outroute multicast is very common as the broadcast nature of the medium blends beautifully to this use case.  In fact many customers solely buy sat for multicast overlay. (However, that's not the MANET use case). 

What I was very concerned with was routers thinking each peer is its own interface and replicating a downstream packet X times.  That can't be allowed to happen - but again, it's likely this is just a function of the equipment I've been exposed too (or my own misunderstandings) and not actually expected by the design.

>I think the idea with multicast and DLEP is that the radio will either statically announce multicast MACs/IPs or eavesdrop on IGMP (ICMPv6) messages and handle them internally. The routing agent then can use them to fill the local arp table.

>Your local radio might filter multicast traffic not meant for your local router, but I think thats an implementation detail not set in the draft.

Fair enough. Is there anything against the "rules" if one managed multicast membership completely outside the notion of DLEP?  There is still a physical interface (in our case a VLAN trunk port), and I would be happy to have that interface decide weather or not to forward multicast with no too little concern about modem status....  there is some persistent multicast I want to send regardless of DLEP's opinion of spokes being in or out of network. (There is station keeping multicast that must flow even if there are 0 'in-network' spokes).

thanks for the discussion,
brian

Henning Rogge

---

From: Shawn Jury <[email-masked]>
Date: Wed, 23 Jul 2014 13:48:45 -0400

Brian,

> What I was very concerned with was routers thinking each peer is its own interface and replicating a downstream packet X times.  That can't be allowed to happen - but again, it's likely this is jus…

From the draft point of view, DLEP supports multicast as a destination so metrics can be applied.  This allows other functionality like rate-limiting/shaping for a multicast group(s), but these are outside the scope of the DLEP draft.  DLEP doesn't replicate multicast packets (again, outside the scope), it assumes the router will take care of that.  Even with the implementation you played with, that was the case.  As I offered before off-list (and Stan has too), I'd be happy to help you better understand how the implementation works, but it not something to discuss on the IETF alias as it is a Cisco specific implementation.

This isn't the first time I've heard this mis-interpretation of the DLEP spec, wrt how we treat DLEP destinations.  DLEP destinations are used to associate metrics about the RF quality.  DLEP destinations can be physical (as in a router on the remote side) or logical (ie multicast group).  There is no point-to-point connection made between these devices.  Even if the router implementation makes use of virtual interfaces, the underlying radio protocol is assumed (and must be treated) to be broadcast.  I would argue that if you have an implementation that doesn't treat the RF as broadcast and makes point-to-point links instead, it is not following the DLEP spec correctly.  This is the only way I could see multicast packets being replicated by a router.  Please help me to understand if there is a different view on this.

> Fair enough. Is there anything against the "rules" if one managed multicast membership completely outside the notion of DLEP?  There is still a physical interface (in our case a VLAN trunk port), a…

Nothing states you have to use DLEP to manage multicast.  DLEP has the capability so that you can help reduce the amount of traffic sent (as mentioned above) for those radios that might have a different mechanism for sending multicast.  The ROUTER controls what multicast groups are being sent to the radio/modem.  If the ROUTER believes that a group has joined on the interface, it will send the packet out the interface (purposely left generic as there are many ways the ROUTER could learn about a group).

Shawn

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 23 Jul 2014 17:59:35 +0000

> This isn't the first time I've heard this mis-interpretation of the DLEP spec, wrt how we treat DLEP destinations.  DLEP destinations are used to associate metrics about the RF quality.  DLEP desti…

Ditto what Shawn said - Multicast packet replication is required if you're using a technique like RFC 5578 (for example), but that's got *everything* to do with the PPPoE underpinnings, and *nothing* to do with the link variability. DLEP treats a multicast group as another logical destination in the network, so that metrics for the logical destination (group) can be reported by the modem, and so that (potentially) a router can make a request via Link Characteristics Request for data rate, or latency. The "Destination Up" DLEP signal can flow in either direction (e.g. Modem-to-Router, or Router-to-Modem) so that either DLEP participant can identify the existence of a new destination (e.g. a new multicast group). There's nothing in the DLEP spec referencing multicast replication, because it's not necessary. 

Regards,
Stan