Subject: [manet] Recharter Discussion

From: Justin Dean <[email-masked]>
Date: Fri, 22 Apr 2016 11:07:00 -0400

I'll start things off by floating the draft re-charter which was presented
in Prague.

The purpose of the MANET working group is to standardize IP routing
protocol functionality suitable for wireless routing application
within both static and dynamic topologies with increased dynamics due
to node motion or other factors.

Approaches are intended to be relatively lightweight in nature,
suitable for multiple hardware and wireless environments, and address
scenarios where MANETs are deployed at the edges of an IP
infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed
and mobile routers) should also be supported by MANET specifications
and management features.

The MANET WG is responsible for the maintenance of OLSRv2, AODVv2,
DLEP and NHPD. Of particular interest: border behavior between MANET
networks and fixed IP network infrastructures, enhance AODVv2 gateway
functionality; security enhancements, encryption security extensions
for RFC5444.

The MANET WG will standardize a multicast MANET protocol framework
based on previous work and lessons learned for scoped forwarding
within MANET networks.  As part of this framework the WG will produce
a well defined MANET multicast forwarding information base.

The WG will produce an informational draft outlining challenges and
best practices for deploying and managing MANET networks.

The MANET WG will interact with the PIM working group on issues
relating to the multicast work.  The WG will also pay attention to
other IETF and IRTF work that is addressing topics related to MANET
environments.

In summary, the WG will develop the following drafts:

MANET Management Document (Informational)
MANET Maintenance
 - RFC5444 Security extension (Standards)
 - Enhanced AODVv2 gateway extension (Standards)
MANET Multicast
 - Multicast FIB (Standards)

This will likely be considered too broad to pass.  We will likely need
to cut some and focus the work.  For me personally I know I have the
time and backing to work on the Multicast piece.

Justin

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Apr 2016 15:45:30 +0000

Multicast is the obvious top item. Lots of possible approaches, time to discuss.

Gateways for AODVv2 at Standard is obviously not possible since AODVv2 is going to be Experimental at most.

Management we did of course have an NHDP/OLSRv2 draft killed by AD. Which since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky.

I would have to make an IPR declaration to say some of what I might have to say about encryption. Not today.

Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is experimental. That would need implementation tests to advance to PS. Anyone interested in that (I’m not saying I can)?

More broadly on OLSRv2 there are various things that could be done, but what is really needed is people with a real application. Any that exist were frightened away from this group.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Justin Dean
Sent: 22 April 2016 16:07
To: [email-masked]
Subject: [manet] Recharter Discussion

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

I'll start things off by floating the draft re-charter which was presented in Prague.

The purpose of the MANET working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion or other factors.

Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures (e.g., a mixture of fixed and mobile routers) should also be supported by MANET specifications and management features.

The MANET WG is responsible for the maintenance of OLSRv2, AODVv2, DLEP and NHPD. Of particular interest: border behavior between MANET networks and fixed IP network infrastructures, enhance AODVv2 gateway functionality; security enhancements, encryption security extensions for RFC5444.

The MANET WG will standardize a multicast MANET protocol framework based on previous work and lessons learned for scoped forwarding within MANET networks.  As part of this framework the WG will produce a well defined MANET multicast forwarding information base.

The WG will produce an informational draft outlining challenges and best practices for deploying and managing MANET networks.

The MANET WG will interact with the PIM working group on issues relating to the multicast work.  The WG will also pay attention to other IETF and IRTF work that is addressing topics related to MANET environments.

MANET Maintenance

MANET Multicast

This will likely be considered too broad to pass.  We will likely need to cut some and focus the work.  For me personally I know I have the time and backing to work on the Multicast piece.

Justin
********************************************************************
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.
********************************************************************

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 22 Apr 2016 11:50:40 -0400

Hello WG,

Do we need to hold an interim meeting (via WebEX) to discuss? I'd like to
get opinions on the list about that. We'll need a couple of weeks to
schedule, but we can do that.

One other point inline:

On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Management we did of course have an NHDP/OLSRv2 draft killed by AD. Which
> since NHDP/OLSRv2 us all we have (SMF excepted) that was a bit tricky.
>
>
>

Understood. But please remember - there's only about a 5-week gap now
before the charter needs to be complete in order for the WG to meet in
Berlin.

Regards,
Stan

>
>
> Missing from the list is any work on OLSRv2 (or NHDP). MT-OLSRv2 is
> experimental. That would need implementation tests to advance to PS. Anyone
> interested in that (I’m not saying I can)?
>
>
>
> More broadly on OLSRv2 there are various things that could be done, but
> what is really needed is people with a real application. Any that exist
> were frightened away from this group.
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Justin Dean
> *Sent:* 22 April 2016 16:07
> *To:* [email-masked]
> *Subject:* [manet] Recharter Discussion
>
>
>
>
>
> **** WARNING ****
>
> *This message originates from outside our organisation, either from an
> external partner or the internet.*
>
> * Consider carefully whether you should click on any links, open any
> attachments or reply. For information regarding **Red Flags** that you
> can look out for in emails you receive, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> **** **WARNING ******
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 25 Apr 2016 12:51:42 +0000

Chairs and WG

I just needed to touch base with the appropriate person here.

I can confirm that I’m aware of (am an inventor on) a patent application that is related to the area of encryption in an ad hoc network. At this point we’re only discussing whether we should work in this area, so issues of its use do not come up now.

(Do you need the number? I don’t have it to hand this second; however given that I’m not called Smith it’s quite easy to find - but see below.)

Having said that, I can now say that a requirement that some people I know have is that of concealing identity and topology/routing information. Which ad hoc routing protocols tend to freely distribute. That’s easy if you just use a shared secret key. That’s also fairly easy if everyone knows who everyone else is, and has symmetric or public keys for everyone else. But neither are ideal solutions (especially the latter that has serious overheads).

The combination of requirement and difficulty makes it a possible subject for the WG, if there’s enough support. But I do not expect anything security related, and especially crypto related, to be plain sailing. We would be strongly advised to get specialised input.

Beyond that of course there is encryption of traffic. An easier problem (at least unicast) in that it’s a standard IP problem. Key management is the issue. There are things related to the IBS draft that can help there, but no doubt others. (In fact I know of another using an alternative to that form of IBS.)

In short, we have some interest here. Do others?

As I noted above, I said patent application not hard to find. But it’s not the only one I’m a co-inventor in. (Though there aren’t many, about three). Another one might also be an area of WG interest, but one topic per email.

Christopher

From: Stan Ratliff [mailto:[email-masked]]
Sent: 22 April 2016 16:51
To: Dearlove, Christopher (UK)
Cc: Justin Dean; [email-masked]
Subject: Re: [manet] Recharter Discussion

*** WARNING ***

Do we need to hold an interim meeting (via WebEX) to discuss? I'd like to get opinions on the list about that. We'll need a couple of weeks to schedule, but we can do that.

One other point inline:

On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Multicast is the obvious top item. Lots of possible approaches, time to discuss.

Understood. But please remember - there's only about a 5-week gap now before the charter needs to be complete in order for the WG to meet in Berlin.

Regards,
Stan

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Justin Dean
Sent: 22 April 2016 16:07
To: [email-masked]<mailto:[email-masked]>
Subject: [manet] Recharter Discussion

*** WARNING ***

MANET Maintenance

MANET Multicast

Justin

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 26 Apr 2016 20:55:24 +0200

Hi,

I believe that an virtual interim is premature: a teleconference is, mechanically, less inclusive than are mailing list discussions (time-zones, other commitments, requirement of synchronicity of participation, etc.).

Furthermore....

Until such time that a strawman charter is proposed, updated to reflect the reality of the group as stipulated by the AD and by Mr. Dean, as well as additional charter items emerging on the list,  and with relatively broad and deep support for the included items by the working group, having an interim - virtual or otherwise - is not constructive.

In other words, it should be established on the list that there are meaningful things to do, and there's a meaningful critical mass of people to be doing those things, before a (virtual) interim is called. Brainstorming on a teleconference is rarely a constructive way to spend time.

Best,

Thomas

Sent from my iPad

> On 22 Apr 2016, at 17:50, Stan Ratliff <[email-masked]> wrote:
> 
> Hello WG, 
> 
>> On Fri, Apr 22, 2016 at 11:45 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:
>> T:  +44 (0)1245 242194  |  E: [email-masked]
>> 
>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>> If you feel the email is suspicious, please follow this process.
>> 
>> *** WARNING ***

---

From: Justin Dean <[email-masked]>
Date: Tue, 26 Apr 2016 16:21:52 -0400

Thomas I understand your concerns but we have mostly gone over this before
in previous meetings.  The AD will not allow us to meet at the next IETF
meeting if we do not have a new charter and new work items.  To your point
it's imparative that the discussion continues on list about the charter.
With that in mind here is a suggested edit of the previously floated
charter, with comments in () with JWD tags.

The MANET WG is responsible for the maintenance of OLSRv2, AODVv2 (JWD
TBD), DLEP and NHPD. Of particular interest: security enhancements,
and encryption security extensions for RFC5444. (JWD we may want to
break this out of the WG and make a new MANET Sec working group to
grab the attention of those interested in security and get their
participation.)

MANET Management Document (Informational)
MANET Maintenance
 - RFC5444 Security extension (Standards) (JWD possibly move this to
new working group)
MANET Multicast
 - Multicast FIB (Standards)

On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <[email-masked]>
wrote:

> Hi,
>
> I believe that an virtual interim is premature: a teleconference is,
> mechanically, less inclusive than are mailing list discussions (time-zones,
> other commitments, requirement of synchronicity of participation, etc.).
>
> Furthermore....
>
> Until such time that a strawman charter is proposed, *updated to reflect
> the reality of the group* as stipulated by the AD and by Mr. Dean, as
> well as additional charter items emerging on the list,  and *with
> relatively broad and deep support* for the included items by the working
> group, having an interim - virtual or otherwise - is not constructive.
>
> In other words, it should be established on the list that there are *meaningful
> things to do*, and there's a *meaningful critical mass of people to be
> doing those things*, before a (virtual) interim is called. Brainstorming
> on a teleconference is rarely a constructive way to spend time.
>
> Best,
>
> Thomas
>
> Sent from my iPad
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 26 Apr 2016 23:00:51 +0200

> On 26 avr. 2016, at 22:21, Justin Dean <[email-masked]> wrote:
> 
> Thomas I understand your concerns but we have mostly gone over this before in previous meetings.

The IETF conducts is business on mailing lists.

My recollection is that the strawman charter was presented once in a WG meeting, then the chairs did not animate any charter discussion for several IETFs, on the list (nor was the charter discussed in subsequent meetings) - until this present "urgency" was declared (by the chairs) to the WG.

> The AD will not allow us to meet at the next IETF meeting if we do not have a new charter and new work items. 

That does not negate my point, however, which was that:

>> it should be established on the list that there are meaningful things to do, and there's a meaningful critical mass of people to be doing those things, before a (virtual) interim is called. Brainstorming on a teleconference is rarely a constructive way to spend time

Thomas

> To your point it's imparative that the discussion continues on list about the charter.  With that in mind here is a suggested edit of the previously floated charter, with comments in () with JWD tags.
> 
> The MANET WG is responsible for the maintenance of OLSRv2, AODVv2 (JWD TBD), DLEP and NHPD. Of particular interest: security enhancements, and encryption security extensions for RFC5444. (JWD we may want to break this out of the WG and make a new MANET Sec working group to grab the attention of those interested in security and get their participation.)
> 
>  - RFC5444 Security extension (Standards) (JWD possibly move this to new working group)
> MANET Multicast
>> On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <[email-masked]> wrote:
>> Hi,
>>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 27 Apr 2016 09:56:53 +0000

The key points as I see it are:
- We shouldn’t wait for telecon, and can’t rely on telecon and cut out list.
- We are very short of contributors. Many who have contributed have dropped away. And those who have been main creators of WG RFCs (looking at statistics, Clausen and Dearlove in particular, but also others - but not a lot of others, especially after the first batch of Experimental RFCs) may or may not be contributing.
- But even more importantly we need real people (preferably companies with products) using our protocols with real problems. DLEP I think has some real adaptors, though I think most are waiting for an RFC. OLSRv2 is short on companies advertising they are using it - I wish some would (I’m told they exist, but couldn’t name any). AODVv2 (which may or may not be in scope) appears not to have even up to date experimental code (please correct if wrong).
- Hence although we may have some great ideas, it’s not yet clear people want them and we can deliver - DLEP maintenance being I think closest to contradicting that, at least publicly.

There is the horrible warning of Autoconf that went wrong in several ways, but at the end, had no one who would do the work (which is a lot of work, taking longer than you expect) to create a draft and take it all the way. And that means a small team of actual authors, plus wider input.

Incidentally the autoconf problem is still real, but was too narrow. That was considering address autoconfiguration (though the WG never actually got there). As I see it, there’s an inseparable (in terms of thinking about it, drafts may of course separate out details) issue that is of address assignment, identity assignment/management, cryptographic key management, and other forms of management (network management). And several chicken and egg problems that arise in them, especially in ad hoc networks.

From: manet [mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
Sent: 26 April 2016 22:01
To: Justin Dean
Cc: [email-masked]
Subject: Re: [manet] Recharter Discussion

*** WARNING ***

On 26 avr. 2016, at 22:21, Justin Dean <[email-masked]<mailto:[email-masked]>> wrote:
Thomas I understand your concerns but we have mostly gone over this before in previous meetings.

Thomas

MANET Maintenance

MANET Multicast

On Tue, Apr 26, 2016 at 2:55 PM, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Furthermore....

Best,

Thomas

Sent from my iPad

On 22 Apr 2016, at 17:50, Stan Ratliff <[email-masked]<mailto:[email-masked]>> wrote:
Hello WG,

One other point inline:

Regards,
Stan

*** WARNING ***

MANET Maintenance

MANET Multicast

Justin

---

From: Justin Dean <[email-masked]>
Date: Wed, 27 Apr 2016 11:44:48 -0400

On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> I agree.  We shouldn't wait for the telecon.  I'll continue to engage
everyone on this list about what people are willing to work on.

> - We are very short of contributors. Many who have contributed have
> dropped away. And those who have been main creators of WG RFCs (looking at
> statistics, Clausen and Dearlove in particular, but also others - but not a
> lot of others, especially after the first batch of Experimental RFCs) may
> or may not be contributing.
>
> We are short contributors and we may be able to get more by focusing the
group on specific issues and possibly creating new focused groups to invite
a larger/wider IETF involvement.  Security being the one coming to mind.
Your mention on the list about security stuff that you are interested in
hasn't brought a lot of discussion on this list but it very well may bring
a lot of interest from the larger ietf community.

> - But even more importantly we need real people (preferably companies with
> products) using our protocols with real problems. DLEP I think has some
> real adaptors, though I think most are waiting for an RFC. OLSRv2 is short
> on companies advertising they are using it - I wish some would (I’m told
> they exist, but couldn’t name any). AODVv2 (which may or may not be in
> scope) appears not to have even up to date experimental code (please
> correct if wrong).
>
> - Hence although we may have some great ideas, it’s not yet clear people
> want them and we can deliver - DLEP maintenance being I think closest to
> contradicting that, at least publicly.
>
Well I KNOW that here at NRL we have the real people and prototype products
relating to the multicast issue that it can happen. The key issue is making
sure there are enough people willing to contribute and engineer a solution
to an issue that needs solving.

There is the horrible warning of Autoconf that went wrong in several ways,
> but at the end, had no one who would do the work (which is a lot of work,
> taking longer than you expect) to create a draft and take it all the way.
> And that means a small team of actual authors, plus wider input.
>

>
> Incidentally the autoconf problem is still real, but was too narrow. That
> was considering address autoconfiguration (though the WG never actually got
> there). As I see it, there’s an inseparable (in terms of thinking about it,
> drafts may of course separate out details) issue that is of address
> assignment, identity assignment/management, cryptographic key management,
> and other forms of management (network management). And several chicken and
> egg problems that arise in them, especially in ad hoc networks.
>
> I think the issue with autoconf is that it was attempting to solve to
broad a problem.  There were demonstratable solutions to very specific
problems (e.g. multihop DHCP) but then there were more exotic solutions to
more complex problems like DAD in disconnected partitioning/merging
networks. If we can focus on a specific well defined problem space I think
we'll be fine.

> *From:* manet [mailto:[email-masked]] *On Behalf Of *Thomas Heide
> Clausen
> *Sent:* 26 April 2016 22:01
> *To:* Justin Dean
> *Cc:* [email-masked]
> *Subject:* Re: [manet] Recharter Discussion
>
>
>
>
>
> **** WARNING ****
>
> in previous meetings.
> My recollection is that the strawman charter was presented once in a WG
> meeting, then the chairs did not animate any charter discussion for several
> IETFs, on the list (nor was the charter discussed in subsequent meetings) -
> until this present "urgency" was declared (by the chairs) to the WG.
>
>
>
> it should be established on the list that there are *meaningful things to
> do*, and there's a *meaningful critical mass of people to be doing those
> things*, before a (virtual) interim is called. Brainstorming on a
> teleconference is rarely a constructive way to spend time
>
>
>
>
>
> Thomas
>
>
>
> To your point it's imparative that the discussion continues on list about
> the charter.  With that in mind here is a suggested edit of the previously
> floated charter, with comments in () with JWD tags.
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 27 Apr 2016 16:35:23 +0000

OK, you know there are some people at NRL. Good. But still quite a way short of what we really need in terms of buy-in. (I’m assuming the people at NRL are represented by you and/or Brian, as otherwise even they aren’t showing up.)

From: Justin Dean [mailto:[email-masked]]
Sent: 27 April 2016 16:45
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; [email-masked]
Subject: Re: [manet] Recharter Discussion

*** WARNING ***

On Wed, Apr 27, 2016 at 5:56 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
The key points as I see it are:
- We shouldn’t wait for telecon, and can’t rely on telecon and cut out list.
I agree.  We shouldn't wait for the telecon.  I'll continue to engage everyone on this list about what people are willing to work on.

- We are very short of contributors. Many who have contributed have dropped away. And those who have been main creators of WG RFCs (looking at statistics, Clausen and Dearlove in particular, but also others - but not a lot of others, especially after the first batch of Experimental RFCs) may or may not be contributing.
We are short contributors and we may be able to get more by focusing the group on specific issues and possibly creating new focused groups to invite a larger/wider IETF involvement.  Security being the one coming to mind.  Your mention on the list about security stuff that you are interested in hasn't brought a lot of discussion on this list but it very well may bring a lot of interest from the larger ietf community.

- But even more importantly we need real people (preferably companies with products) using our protocols with real problems. DLEP I think has some real adaptors, though I think most are waiting for an RFC. OLSRv2 is short on companies advertising they are using it - I wish some would (I’m told they exist, but couldn’t name any). AODVv2 (which may or may not be in scope) appears not to have even up to date experimental code (please correct if wrong).
- Hence although we may have some great ideas, it’s not yet clear people want them and we can deliver - DLEP maintenance being I think closest to contradicting that, at least publicly.
Well I KNOW that here at NRL we have the real people and prototype products relating to the multicast issue that it can happen. The key issue is making sure there are enough people willing to contribute and engineer a solution to an issue that needs solving.

Incidentally the autoconf problem is still real, but was too narrow. That was considering address autoconfiguration (though the WG never actually got there). As I see it, there’s an inseparable (in terms of thinking about it, drafts may of course separate out details) issue that is of address assignment, identity assignment/management, cryptographic key management, and other forms of management (network management). And several chicken and egg problems that arise in them, especially in ad hoc networks.
I think the issue with autoconf is that it was attempting to solve to broad a problem.  There were demonstratable solutions to very specific problems (e.g. multihop DHCP) but then there were more exotic solutions to more complex problems like DAD in disconnected partitioning/merging networks. If we can focus on a specific well defined problem space I think we'll be fine.

From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Heide Clausen
Sent: 26 April 2016 22:01
To: Justin Dean
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [manet] Recharter Discussion

*** WARNING ***

Thomas

MANET Maintenance

MANET Multicast

Furthermore....

Best,

Thomas

Sent from my iPad

One other point inline:

Regards,
Stan

*** WARNING ***

MANET Maintenance

MANET Multicast

Justin