Subject: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

From: <[email-masked]>
Date: Thu, 5 Sep 2013 11:13:22 +0100

Another issue:
There is no negotiation between the MA and Controller - the Controller simply sends the Instruction to the MA, with the details of the Measurement Tasks to perform.
In general we expect that the measurement system understands the capabilities of its MAs (probably there are only one or a few classes of MA), so negotiation about the MA's capabilities would have little benefit. It would also add complexity to the MA, Controller and Control Protocol.

It is possible that the MA can't perform the requested Measurement Task. So the Control Protocol needs to allow the MA to reply with an error code. It has also been suggested that the Controller should be able to ask the MA to send a list of all the Measurement Methods that it is capable of, in case 'something goes wrong' and the Controller forgets what the MA can do. Comment: this idea hasn't had much discussion yet, but appears in the Information Model i-d

Thoughts?
Thanks
phil

---

From: Paul Aitken <[email-masked]>
Date: Thu, 05 Sep 2013 12:15:49 +0100

Phil,

A controller can't forget what an MA can do unless / untll it first 
knows... so presumably there's a discovery phase where a (new) 
controller becomes aware of which MAs are within its control, and what 
the capabilities of each MA are. This has to be a dynamic process so new 
MAs can appear (and disappear) at any time. Whether the controller 
discovers MAs, or the MAs announce themselves to the controller depends 
on the protocol, firewalls, etc.

See http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8

After this there are a couple of failure scenarios:

* Immediate: the controller requests an MA perform a test; the MA knows 
it's not capable of performing that test (eg due to a conflict or lack 
of resources). The MA can immediately indicate an error code to the 
controller. The controller could request a different test or choose a 
different MA.

* Future: the controller requests an MA perform a test in the future 
(eg, at midnight), or a repeating test (eg, hourly). The MA accepts the 
test, indicating OK to the controller. Later the MA later discovers that 
it's not capable of performing the test. Depending on the control 
protocol, there may or may not be a connection between the MA and the 
controller. So the MA may have to indicate an error to the collector - 
especially if it wants to report partial results for an incomplete 
repeating test.

If the MA indicates the error to the collector, does the collector need 
to tell the controller that the test didn't happen, or only partially 
happened? Aamer and I supposed so, which is why we added the controller 
/ collector feedback loop. OTOH, if the controller doesn't need to know 
that the test(s) didn't happen, then why do we need error codes at all? 
The controller tells an MA to perform the test, and either it does or 
doesn't... it doesn't make sense, right?

P.

> Another issue:
>
> There is no negotiation between the MA and Controller - the Controller 
> simply sends the Instruction to the MA, with the details of the 
> Measurement Tasks to perform.
>
> In general we expect that the measurement system understands the 
> capabilities of its MAs (probably there are only one or a few classes 
> of MA), so negotiation about the MA's capabilities would have little 
> benefit. It would also add complexity to the MA, Controller and 
> Control Protocol.
>
> It is possible that the MA can't perform the requested Measurement 
> Task. So the Control Protocol needs to allow the MA to reply with an 
> error code. It has also been suggested that the Controller should be 
> able to ask the MA to send a list of all the Measurement Methods that 
> it is capable of, in case 'something goes wrong' and the Controller 
> forgets what the MA can do. Comment: this idea hasn't had much 
> discussion yet, but appears in the Information Model i-d
>
> Thoughts?
>
> Thanks
>
> phil
>
>
>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Sep 2013 13:56:30 +0200

Hi, Phil, all,

Some points on this inline...

On 5 Sep 2013, at 12:13 , <[email-masked]> wrote:

> In general we expect that the measurement system understands the capabilities of its MAs (probably there are only one or a few classes of MA), so negotiation about the MA’s capabilities would have little benefit. It would also add complexity to the MA, Controller and Control Protocol.

First, there's a separation between negotiation and capabilities advertisement. The former allows MAs and Controllers to iteratively agree on what the MA can and will do with respect to a given Task; the latter provides a method for the MA to tell the Controller what it might be willing to do at some point in the future. 

Negotiation, as I see it, is significantly more complicated that advertisement; in the latter case, a Controller can simply select to use the subset of MAs -- the negotiation algorithm is local to the Controller in this case, and doesn't touch the protocol at all.

I'm somewhat skeptical that a system relying on static capabilities -- i.e. with neither negotiation nor capabilities advertisement -- will ever be deployable and manageable. It presumes that all MAs are the same, and that their capabilities never change over their lifetimes; that the set of basic capabilities presumed to be supported by all/most MAs will never change; it also presumes that no MA can support any additional measurement services beyond the base profile, which makes it difficult for different MA vendors to differentiate their implementations.

I know that _discovery_ of MAs is explicitly out of scope to allow integration with (access network technology bound) device management protocols, but it seems we really need some way to bind what an MA can do to its identification.

> It is possible that the MA can’t perform the requested Measurement Task. So the Control Protocol needs to allow the MA to reply with an error code.

This is more useful in use cases where the controller cares about the results from a specific MA. In an environment with thousands of MAs with varying connectivity, requiring a back channel for errors (and/or requiring the Controller to actually _do_ something about this error) seems like a lot of overhead for zero actionable insight. 

> It has also been suggested that the Controller should be able to ask the MA to send a list of all the Measurement Methods that it is capable of, in case ‘something goes wrong’ and the Controller forgets what the MA can do.

This would be a nice way to implement capability advertisement without linking it to discovery, actually. Downside is you end up with something that looks like negotiation on association: discover - associate - capability query - capability advertisement response - now we can measure something.

Cheers,

Brian

---

From: "Guangqing Deng" <[email-masked]>
Date: Thu, 5 Sep 2013 20:08:30 +0800

Hi, all, I think the requirements of negotiation protocols between MA and controller do exit and will continuously be proposed, since more such protocols mean more
convenience for performing measurements. However, more protocols also mean that MAs have to apply more resources (like CPU and bandwidth) on measurements,
which is OK for fixed MAs like desktops, laptops, and other such kinds of MAs. But mobile MAs (such as smart phones) may be sensitive about that (namely the 
complexity of protocols). So maybe it is necessary to divide these requirements into two kinds: basic and extended ones. The basic ones are suitable for both 
mobile and fixed MAs, and the extended ones are only for those other than mobile MAs. In a word, the protocol complexity should be deliberately controlled.

Guangqing Deng
cnnic 

From: Brian Trammell
Date: 2013-09-05 19:56
To: [email-masked]
CC: lmap
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller
Hi, Phil, all,

Cheers,

Brian

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 13:30:42 +0100

> Negotiation, as I see it, is significantly more complicated that
> advertisement;
Agree.

> I'm somewhat skeptical that a system relying on static capabilities --
> i.e. with neither negotiation nor capabilities advertisement -- will
> ever be deployable and manageable.

My assumption (which I should have stated!):
the measurement system needs to know the capabilities of its MAs. it will do this as part of deployment and bootstrapping. If the measurement system updates the MA's capabilities, eg with some new Measurement Methods, then the measurement system (& Controller) should know about it.

The WG is supposed to think about the bootstrapping process but doesn't define a detailed bootstrap protocol (I think the latter is out of scope, on the basis that's it depends on the access/device type, eg use TR-069 for BBF devices etc). 
I think so far we (or at least I) have been quite vague about what this means. We could do with some more detailed work, perhaps it would reveal that some useful things don't depend on the access/device type, so could be good for lmap wg to define?

> -----Original Message-----
> From: Brian Trammell [mailto:[email-masked]]
> Sent: 05 September 2013 12:57
> To: Eardley,PL,Philip,TUB8 R
> Cc: [email-masked]
> > There is no negotiation between the MA and Controller - the
> Controller simply sends the Instruction to the MA, with the details of
> the Measurement Tasks to perform.
> benefit. It would also add complexity to the MA, Controller and Control
> Protocol.
> 
> First, there's a separation between negotiation and capabilities
> advertisement. The former allows MAs and Controllers to iteratively
> agree on what the MA can and will do with respect to a given Task; the
> latter provides a method for the MA to tell the Controller what it
> might be willing to do at some point in the future.
> 
> Negotiation, as I see it, is significantly more complicated that
> advertisement; in the latter case, a Controller can simply select to
> use the subset of MAs -- the negotiation algorithm is local to the
> Controller in this case, and doesn't touch the protocol at all.
> 
> I'm somewhat skeptical that a system relying on static capabilities --
> i.e. with neither negotiation nor capabilities advertisement -- will
> ever be deployable and manageable. It presumes that all MAs are the
> same, and that their capabilities never change over their lifetimes;
> that the set of basic capabilities presumed to be supported by all/most
> MAs will never change; it also presumes that no MA can support any
> additional measurement services beyond the base profile, which makes it
> difficult for different MA vendors to differentiate their
> implementations.
> 
> I know that _discovery_ of MAs is explicitly out of scope to allow
> integration with (access network technology bound) device management
> protocols, but it seems we really need some way to bind what an MA can
> do to its identification.
> 
> error code.
> This is more useful in use cases where the controller cares about the
> results from a specific MA. In an environment with thousands of MAs
> with varying connectivity, requiring a back channel for errors (and/or
> requiring the Controller to actually _do_ something about this error)
> seems like a lot of overhead for zero actionable insight.
> 
> > It has also been suggested that the Controller should be able to ask
> the MA to send a list of all the Measurement Methods that it is capable
> of, in case 'something goes wrong' and the Controller forgets what the
> MA can do.
> 
> This would be a nice way to implement capability advertisement without
> linking it to discovery, actually. Downside is you end up with
> something that looks like negotiation on association: discover -
> associate - capability query - capability advertisement response - now
> we can measure something.
> 
> Cheers,
> 
> Brian

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 13:55:44 +0100

I don't think lmap should define a dynamic MA discovery protocol

On your "Future" bullet - << Later the MA later discovers that it's not capable of performing the test>>
I was assuming that the MA understands what Measurement Methods it can do, so it should know at the time when it gets the Instruction whether it can do the test or not. So I'm not that worried about the MA later realising it can't.

My assumption here - the operator of the measurement system checks in the lab what Methods can run on which of its types of MAs - it allows some margin for error - it definitely doesn't try and operate Methods which will run ok sometimes and not at other times (when the device containing the MA is "busy").

If the Result isn't collected or is suspected of being wrong for some reason, then it's marked when the Results are reported. I agree in some circumstances the measurement system may want to tell the Controller (the feedback loop out of scope of lmap to define)

Thanks
Phil

From: Paul Aitken [mailto:[email-masked]]
Sent: 05 September 2013 12:16
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

Phil,

A controller can't forget what an MA can do unless / untll it first knows... so presumably there's a discovery phase where a (new) controller becomes aware of which MAs are within its control, and what the capabilities of each MA are. This has to be a dynamic process so new MAs can appear (and disappear) at any time. Whether the controller discovers MAs, or the MAs announce themselves to the controller depends on the protocol, firewalls, etc.

* Immediate: the controller requests an MA perform a test; the MA knows it's not capable of performing that test (eg due to a conflict or lack of resources). The MA can immediately indicate an error code to the controller. The controller could request a different test or choose a different MA.

* Future: the controller requests an MA perform a test in the future (eg, at midnight), or a repeating test (eg, hourly). The MA accepts the test, indicating OK to the controller. Later the MA later discovers that it's not capable of performing the test. Depending on the control protocol, there may or may not be a connection between the MA and the controller. So the MA may have to indicate an error to the collector - especially if it wants to report partial results for an incomplete repeating test.

If the MA indicates the error to the collector, does the collector need to tell the controller that the test didn't happen, or only partially happened? Aamer and I supposed so, which is why we added the controller / collector feedback loop. OTOH, if the controller doesn't need to know that the test(s) didn't happen, then why do we need error codes at all? The controller tells an MA to perform the test, and either it does or doesn't... it doesn't make sense, right?

P.

Another issue:

Thoughts?
Thanks
phil

lmap mailing list

[email-masked]<mailto:[email-masked]>

---

From: Rolf Winter <[email-masked]>
Date: Thu, 05 Sep 2013 14:56:07 +0200

Hi,

if the MA is e.g. my home gateway, I can potentially upgrade its 
firmware anytime I want (something I can do right now with my HGW at 
home) which could add or remove capabilities. What if you have a market 
where the regulator allows a customer to use a HGW of his/her liking 
which does not guarantee a standard set of capabilities. What if your 
HGW allows a user to enable/disable measurement features. Then during 
the lifetime of the MA, capabilities can change after bootstrapping. If 
this is important information for an LMAP controller, I am not entirely 
sure you want to outsource it to a third party protocol. Advertising 
capabilities seems not a very heavyweight and complex operation to me. 
Even in error reports you could advertise the currently supported 
capabilities and not just have a code that says "no can do". Both seem 
useful, i.e. error on a non-supported measurement request and a 
structured way of querying that information. The latter would then be 
part of the bootstrapping process I guess.

Best,

Rolf

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 5 Sep 2013 13:14:07 +0000

Short and sweet -

-          I don't think we can't guarantee that a MA initiating a test (could be a customer MA or other) knows the capabilities of the desired target MA via a controller only scheduling those types of tests.

o   Therefore In my mind - some peer to peer capability negotiation is required.

This is really what drives a MA to do a "capabilities" / "compatibility" check on incoming tests.
                Which immediately drives the codification (standard test naming) to enable an efficient .  .. can you do test 17alpha.5 with X, Y, Z attributes...

Example -  I want to test jumbo frames, maybe the MA doesn't do those... (asking the group to think about Gig on purpose to make sure we're future proofing here)

Regards,
Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 05, 2013 7:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

Thanks
Phil

Cc: [email-masked]<mailto:[email-masked]>

Phil,

P.
Another issue:

Thoughts?
Thanks
phil

lmap mailing list

---

From: Paul Aitken <[email-masked]>
Date: Thu, 05 Sep 2013 14:33:00 +0100

Phil,

> I don't think lmap should define a dynamic MA discovery protocol

If I buy a new router or STB, or if I install an app on my mobile 
device, how is the controller to know that new MAs are available in the 
network?

If the mobile device moves to a different network, how is the controller 
to know? The device might even move from one controller to another.

> On your "Future" bullet -- << Later the MA later discovers that it's 
> not capable of performing the test>>
>
> I was assuming that the MA understands what Measurement Methods it can 
> do, so it should know at the time when it gets the Instruction whether 
> it can do the test or not. So I'm not that worried about the MA later 
> realising it can't.
>

This is not so easily dismissed, since there are many reasons that the 
MA may be able to accept the test at request time, but quite unable to 
run it at a later test time. eg, the MA may be resource bound, offline, 
or not be able to obtain resources from a test peer - none of which it 
knows at request time unless the test is immediate.

> My assumption here -- the operator of the measurement system checks in 
> the lab what Methods can run on which of its types of MAs -- it allows 
> some margin for error -- it definitely doesn't try and operate Methods 
> which will run ok sometimes and not at other times (when the device 
> containing the MA is "busy").
>

When my ISP asks my mobile device to perform some hourly test, how do 
they know it has enough battery to last? How can they know whether the 
device will be connected each hour? How can they predict the CPU and 
memory status at test time?

> If the Result isn't collected or is suspected of being wrong for some 
> reason, then it's marked when the Results are reported. I agree in 
> some circumstances the measurement system may want to tell the 
> Controller (the feedback loop out of scope of lmap to define)
>

Good.

P.

> Thanks
>
> Phil
>
> *From:*Paul Aitken [mailto:[email-masked]]
> *Sent:* 05 September 2013 12:16
> *To:* Eardley,PL,Philip,TUB8 R
> *Cc:* [email-masked]
> *Subject:* Re: [lmap] LMAP Framework issue #3 No negotiation between 
> MA and Controller
>
> Phil,
>
> the capabilities of each MA are. This has to be a dynamic process so 
> new MAs can appear (and disappear) at any time. Whether the controller 
> discovers MAs, or the MAs announce themselves to the controller 
> depends on the protocol, firewalls, etc.
>
> * Immediate: the controller requests an MA perform a test; the MA 
> knows it's not capable of performing that test (eg due to a conflict 
> or lack of resources). The MA can immediately indicate an error code 
> to the controller. The controller could request a different test or 
> choose a different MA.
>
> (eg, at midnight), or a repeating test (eg, hourly). The MA accepts 
> the test, indicating OK to the controller. Later the MA later 
> discovers that it's not capable of performing the test. Depending on 
> the control protocol, there may or may not be a connection between the 
> MA and the controller. So the MA may have to indicate an error to the 
> collector - especially if it wants to report partial results for an 
> incomplete repeating test.
>
> If the MA indicates the error to the collector, does the collector 
> need to tell the controller that the test didn't happen, or only 
> partially happened? Aamer and I supposed so, which is why we added the 
> controller / collector feedback loop. OTOH, if the controller doesn't 
> need to know that the test(s) didn't happen, then why do we need error 
> codes at all? The controller tells an MA to perform the test, and 
> either it does or doesn't... it doesn't make sense, right?
>
> P.
>
>     Another issue:
>
>     Controller simply sends the Instruction to the MA, with the
>     details of the Measurement Tasks to perform.
>
>     capabilities of its MAs (probably there are only one or a few
>     classes of MA), so negotiation about the MA's capabilities would
>     have little benefit. It would also add complexity to the MA,
>     Controller and Control Protocol.
>
>     Task. So the Control Protocol needs to allow the MA to reply with
>     an error code. It has also been suggested that the Controller
>     should be able to ask the MA to send a list of all the Measurement
>     Methods that it is capable of, in case 'something goes wrong' and
>     the Controller forgets what the MA can do. Comment: this idea
>     hasn't had much discussion yet, but appears in the Information
>     Model i-d
>
>     Thoughts?
>
>     Thanks
>
>     phil
>
>
>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Sep 2013 15:57:05 +0200

On 5 Sep 2013, at 14:30 , <[email-masked]> wrote:

> the measurement system needs to know the capabilities of its MAs.

I'd add the following assumption: the capabilities of the MAs are (1) heterogeneous and (2) dynamic.

> it will do this as part of deployment and bootstrapping. If the measurement system updates the MA's capabilities, eg with some new Measurement Methods, then the measurement system (& Controller) should know about it.
> 

Agree; this makes sense. My question: how much information can we easily transfer about the MA via TR-069 etc.?

> I think so far we (or at least I) have been quite vague about what this means. We could do with some more detailed work, perhaps it would reveal that some useful things don't depend on the access/d…

Well, the basic things you're trying to measure -- the underlying ideal goals of the measurement activity, as opposed to the algorithms and techniques, should be universal across access technologies; additional access-technique-specific parameters can certainly also be advertised as capabilities.

Cheers,

Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 5 Sep 2013 13:57:44 +0000

Not sure which email in this thread to start from, so I just cleaned out all other text...

Advertisement:
This is a really simple thing to do, and any good control protocol with a well-designed data model should be perfectly capable of this. It is not part of bootstrap.
For example, if TR-069 were being used as the control protocol (and, yes, I'm talking about Control and not bootstrap), there would be an xml parameter that lists capabilities, as well as xml  parameters that match up to the enabling/disabling/execution of these capabilities, and setting of specific parameters associated with these capabilities. Via this exemplary TR-069 interface, the Controller can request the MA tell the Controller (1) the entire data model structure (every single xml parameter) and (2) the current values of these xml parameters (e.g., the current value of a capability list xml parameter). It's not necessary to get this info every time. Important changes can be "evented", so the Controller is informed either that changes have occurred, and even what changes have occurred. 

IMO, lmap should not recommend a protocol that isn't capable of such incredibly basic functionality.

Negotiation:
I don't know that I would call it a negotiation as much as the MA having proper ways to tell the Controller "No". Again, using TR-069 as an example, if the Controller tells the MA to set xml parameters that the MA doesn't have in its TR-069 data model, then the MA can say "No, I don't have those parameters." If the Controller tells the MA to set xml parameters that have been locked so they cannot be written to, then the MA tells the Controller "No, those are locked". If there is some temporary reason the MA can't comply, then the MA needs to tell the Controller "No, not right now". 

Similarly, if a test were scheduled to be run by the Controller, and the MA doesn't run it for some reason, there should be an xml parameter that gives the reason why the test wasn't run (a status or result parameter). The allowed values defined for this parameter need to provide the necessary level of information to the Controller. When the Controller reads the value of that parameter, it gets the info it needs.

Since I know that TR-069 can easily do advertisement and negotiation with a well-designed data model (and, yes, in TR-069 this level of communication is done through data model parameters and their values and not through specific/different RPCs  or RPC error messages), I'm not understanding why there's debate about whether or not these should be criteria in Control protocol selection and requirements when doing that protocol's data model design. IMO, of course they're required.
Barbara

---

From: <[email-masked]>
Date: Thu, 5 Sep 2013 15:04:21 +0100

Couple of comments inline
thanks
phil

From: Paul Aitken [mailto:[email-masked]]
Sent: 05 September 2013 14:33
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

Phil,

If I buy a new router or STB, or if I install an app on my mobile device, how is the controller to know that new MAs are available in the network?

If the mobile device moves to a different network, how is the controller to know? The device might even move from one controller to another.

[phil] yes, something needs to handle this. I'm suggesting this is access/device type specific - eg BBF protocol for a broadband forum device, eg an app you download to your mobile etc. so not an lmap feature.

This is not so easily dismissed, since there are many reasons that the MA may be able to accept the test at request time, but quite unable to run it at a later test time. eg, the MA may be resource bound, offline, or not be able to obtain resources from a test peer - none of which it knows at request time unless the test is immediate.

[phil] I think it's a bad idea to try and cope with the MA sometimes lacking CPU etc resources to run a test. The test should be designed and checked in the lab such that the MA can run it except under the most unusual case (then maybe the MA sends an error, maybe it does nothing). If the MA is offline, then I guess it can't send an error msg. where appropriate the Measurement Method will define the initial part to check whether the Peer has enough resources to run the test - this is handled similarly to the case where the MA detects that there's user traffic so shouldn't run the test. I guess resources could include battery life. I think probably the Method should define what to do - for example delay the test and re-try.

My view is that the MA should act autonomously - it gets instructed what test to run and when, then it gets on with it. Negotiation back and forth would add a lot to the complexity and personally I don't see much gain - this is supposed to be something simple to do.

When my ISP asks my mobile device to perform some hourly test, how do they know it has enough battery to last? How can they know whether the device will be connected each hour? How can they predict the CPU and memory status at test time?

Good.

P.

Thanks
Phil

Phil,

P.

Another issue:

Thoughts?
Thanks
phil

lmap mailing list

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 5 Sep 2013 14:04:39 +0000

I concur there needs to be a discovery method, maybe two methods, one for the home network, and one for the larger Internet.

Either way a standard "how do you find X" needs to be there for Agents...
When a Agent doesn't have a clear registry advertising is required.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Thursday, September 05, 2013 8:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

Advertisement:

Negotiation:

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 5 Sep 2013 14:26:44 +0000

> transfer about the MA via TR-069 etc.?

Note: TR-069 can be used both for bootstrap as well as Control. I have every intention of making sure that a TR-069 data model gets defined based on the lmap information model, and extended to include elements specifically defined in BBF (e.g., if there are access PHY-specific tests -- for every access PHY people would like to see included in the data model, since TR-069 itself only depends on IP connectivity).

I would probably limit metadata about an MA (bootstrap xml parameter data model) to just be the elements needed to get the MA installed, running, and communicating with a Controller.

However, the "communicating with a Controller" metadata would be optional to have or use. In many cases, the MA will come pre-configured with the Controller information. Discovery is accomplished by the MA "calling home" to the configured Controller.

For example: 3rd party has MA software available for user to download and install on a PC. User downloads, agrees to terms and conditions, installs, and runs the MA. Therefore, the user is the bootstrapper. The MA comes pre-configured with that 3rd party's Controller info, so when the user runs it, the MA "calls home" and is discovered. In this case, the Controller info is internal to the MA (not exposed metadata).

There is also the case where the user is asked to help configure the MA (again, the user is the bootstrapper). In this case, the Controller info is, effectively, exposed metadata. 

And there is the case where the service provider puts a MA on a provided home router. The service provider may choose to expose the Controller configuration metadata to the bootstrap protocol, or have that info pre-configured in the MA.

I would recommend that whether or not the Controller metadata is exposed to the bootstrap mechanism, or pre-configured, it must be settable by the Controller.

Therefore, Controller info needs to be included in the information model.

Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 5 Sep 2013 14:53:20 +0000

> I concur there needs to be a discovery method, maybe two methods, one for
> the home network, and one for the larger Internet.
> 

Hmm. This seems to be expanding the concept of "discovery" beyond what I saw in previous posts.
I thought the "discovery" discussion was in the context of a Controller "discovering" the MAs that it can control, and an MA "discovering" who its Controller was supposed to be. As I mentioned in my last email, I think that these are best and most easily handled through either bootstrap (which could be via user or protocol and is out of scope) or pre-configuration. It would be possible to design more robust and incredibly complex discovery mechanisms (and then the robust and complex security needed to prevent abuse of such mechanisms), but I'm really not seeing good justification for something more complex at this time.

I'm only focusing on the case where the Controller is somewhere in the Internet and not in the home network.

I've sort of concluded that the best place to deal with internal-to-the-home-network mechanisms in IETF is homenet and not lmap. 
Barbara

---

From: "Sharam Hakimi" <[email-masked]>
Date: Thu, 5 Sep 2013 15:08:14 -0400

It seems that there are major questions on USE cases. Whether it is
Discovery/Registration, Bootstrapped or self contained, finding MA
capabilities, Test is MA initiated or Controller initiated, to who and
how to report the results, what test authorization or CAC accomplishes,
would be best to agree on a set of use cases and then apply the details.

Sharam

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, September 05, 2013 10:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA
and Controller

thanks

phil

From: Paul Aitken [mailto:[email-masked]] 
Sent: 05 September 2013 14:33
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA
and Controller

Phil,

[phil] yes, something needs to handle this. I'm suggesting this is
access/device type specific - eg BBF protocol for a broadband forum
device, eg an app you download to your mobile etc. so not an lmap
feature. 

On your "Future" bullet - << Later the MA later discovers that it's not
capable of performing the test>>

[phil] I think it's a bad idea to try and cope with the MA sometimes
lacking CPU etc resources to run a test. The test should be designed and
checked in the lab such that the MA can run it except under the most
unusual case (then maybe the MA sends an error, maybe it does nothing).
If the MA is offline, then I guess it can't send an error msg. where
appropriate the Measurement Method will define the initial part to check
whether the Peer has enough resources to run the test - this is handled
similarly to the case where the MA detects that there's user traffic so
shouldn't run the test. I guess resources could include battery life. I
think probably the Method should define what to do - for example delay
the test and re-try.

My view is that the MA should act autonomously - it gets instructed what
test to run and when, then it gets on with it. Negotiation back and
forth would add a lot to the complexity and personally I don't see much
gain - this is supposed to be something simple to do.

My assumption here - the operator of the measurement system checks in
the lab what Methods can run on which of its types of MAs - it allows
some margin for error - it definitely doesn't try and operate Methods
which will run ok sometimes and not at other times (when the device
containing the MA is "busy").

If the Result isn't collected or is suspected of being wrong for some
reason, then it's marked when the Results are reported. I agree in some
circumstances the measurement system may want to tell the Controller
(the feedback loop out of scope of lmap to define)

Good.

P.

Thanks

Phil

From: Paul Aitken [mailto:[email-masked]] 
Sent: 05 September 2013 12:16
To: Eardley,PL,Philip,TUB8 R
Cc: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA
and Controller

Phil,

See
http://tools.ietf.org/html/draft-akhter-lmap-framework-00#section-3.8

P.

	Another issue:

	In general we expect that the measurement system understands the
capabilities of its MAs (probably there are only one or a few classes of
MA), so negotiation about the MA's capabilities would have little
benefit. It would also add complexity to the MA, Controller and Control
Protocol. 

	It is possible that the MA can't perform the requested
Measurement Task. So the Control Protocol needs to allow the MA to reply
with an error code. It has also been suggested that the Controller
should be able to ask the MA to send a list of all the Measurement
Methods that it is capable of, in case 'something goes wrong' and the
Controller forgets what the MA can do. Comment: this idea hasn't had
much discussion yet, but appears in the Information Model i-d

	Thoughts? 

	Thanks

	phil

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 06 Sep 2013 09:05:39 +0200

So, let me expand on Barbara's list and tweak it a bit.

I think we need to following functionalities:

- A mechanism for MA discovery i.e. to find out which MA's are out 
there. I think this is part of the Bootstrap or configuration phase.

- A mechanism for MA capabilities advertisement. i.e. assuming that the 
Controller knows what are the MAs out there, a mechanism to find out 
which are the capabilties of each MA i.e. what tests it supports.

- A mechanism to find out if the instructions that the controller have 
sent to the MA have been executed succesfully and if not, what is the 
reason they were not.

I think the framework and the information model shoudl cover all these.
I think the WG should prioritize which items to focus on at the begining.

Makes sense?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Sep 2013 10:02:02 +0200

On Fri, Sep 06, 2013 at 09:05:39AM +0200, marcelo bagnulo braun wrote:
> - A mechanism for MA capabilities advertisement. i.e. assuming that
> the Controller knows what are the MAs out there, a mechanism to find
> out which are the capabilties of each MA i.e. what tests it
> supports.
> 
> - A mechanism to find out if the instructions that the controller
> have sent to the MA have been executed succesfully and if not, what
> is the reason they were not.
> 

I am not sure about a generic discovery mechanism. The general
framework assumes that the bootstrapping mechanism provides MA with
sufficient information that they can contact they initial controller.
How that is done is bootstrap mechanism specific.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 06 Sep 2013 14:42:17 +0200

> How that is done is bootstrap mechanism specific.

Right, and that is one discovery mechanism, isn't it?

Regards, marcelo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Sep 2013 15:42:56 +0200

> Right, and that is one discovery mechanism, isn't it?

No, not for me. There will be several different boot strapping
mechanisms. Some of them may involve a specific LMAP discovery phase,
others already have a suitable discovery phase and yet others may not
need a discovery phase. Hence, the general framework and information
model should be silent about this.

/js

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 6 Sep 2013 09:36:47 -0400

I would call that Registration. I guess it is Discovery depending who's point of view one looks at it. If it from the point of view of the MA, it is Discovery and if it is from the point of view of the Controller, it is registration.

For the case of an MA where it is behind a NAT, it would have to be Registration because discovery from a Controller would not be possible.

Sharam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Friday, September 06, 2013 8:42 AM
To: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

Regards, marcelo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Sep 2013 15:55:18 +0200

Sharam,

the MA, once bootstrapped, registers with the controller. I think this
is all well described. My point was that any discovery of MAs is part
of a bootstrapping mechanism, not part of the LMAP framework itsef.

/js

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Fri, 6 Sep 2013 15:05:40 +0000

I don't think Discovery the right term (we may be over extending it's definition)...

For what's being discussed .. Audit / Registration of capabilities is more correct IMHO...

Bigger picture -- there are two distinct steps IMHO 

1) Discovery = Identification & authentication
2) Capability registration / resolution = Investigation of capabilities, or registering of capabilities.

Implementation wise (triggers and audit functions in the MA &  controller)
I used audit vs. registration of capabilities because as some else mentioned a MA has a life cycle where it's functionality could change.
To that end triggers need to be developed to
 1) Drive a MA to re-register....
 2) An Audit function needs to be placed (sub command loop)in the controller to ask the "MA" what it's capabilities are when the controller starts 	getting failed  or rejected tests... ie. A trigger event to scheduling testing to cause an audit..

 Most of this is mom and apple pie for split control schemas so it shouldn't be a big leap.

Regards,
Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
Sent: Friday, September 06, 2013 7:42 AM
To: [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

El 06/09/13 10:02, Juergen Schoenwaelder escribió:
>> out which are the capabilties of each MA i.e. what tests it supports.
>>

Regards, marcelo

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 6 Sep 2013 12:02:17 -0400

Juergen,

I think Discovery or registration is part of bootstrapping. The MA would have to be known by the controller in order to be able to download a version or the latest version of what the MA needs to run. 

I would say that the device would be registered at that point.

Sharam

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, September 06, 2013 9:55 AM
To: Sharam Hakimi
Cc: marcelo bagnulo braun; [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

Sharam,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Sep 2013 18:41:07 +0200

Sharam,

I think the model is that the device bootstraps, it then registers by
connecting to the initial controller, then the controller does what it
needs to do.  The bootstrapping phase may involve discovery of MAs
such that they can be subsequently bootstrapped but this is bootstrap
method specific and as far as I understand the charter bootstrapping
is out of scope for LMAP 1.0. Hence, from the charter perspective, our
work begins when the MA has all the needed information to initiate a
connection to the initial controller. This is my view as long as we
talk about "MA discovery".

The thread originally started from "capability discovery". Trevor's
information model draft talks about this as part of so called Status
Information:

   5.  Status Information.  Information on the general status and
       capabilities of the MA.  For example, the set of measurements
       that are supported on the device

Some further details are in section 2.6 of
draft-burbridge-lmap-information-model-00.txt. How this information is
made available to the Controller depends on the protocol being
used. One option is that this information is pushed to the Controller
while registering and MAs have to re-register when their capabilities
change. There may be many other options - but what is a reasonable
choice depends to some extend on the protocol being used for LMAP
and hence can't fully answer this question at this point in time.

Makes sense?

/js

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 6 Sep 2013 17:56:50 -0400

Juergen,
Bootstrapping might not be needed in all cases and it will be individual user defined per the model. After either coming up to the bootstrapping point or coming up to the point that the MA can communicate from an already initial setup, the MA would have to REGISTER with the controller that it has been told to use. The discussion has been around MA discovery and not MA capability discovery. I don't know how something can be bootstrapped or DISCOVERED if it has not Registered.

Thanks,
Sharam

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Friday, September 06, 2013 12:41 PM
To: Sharam Hakimi
Cc: marcelo bagnulo braun; [email-masked]
Subject: Re: [lmap] LMAP Framework issue #3 No negotiation between MA and Controller

Sharam,

Makes sense?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 7 Sep 2013 08:38:48 +0200

Sharam,

I think we are talking past each other.

/js

---

From: <[email-masked]>
Date: Thu, 12 Sep 2013 15:46:22 +0100

Barbara
I think you convinced me.
I'll work on a revised summary text
Thanks
phil

> From: STARK, BARBARA H [mailto:[email-masked]]
> Sent: 05 September 2013 14:58
> Subject: RE: [lmap] LMAP Framework issue #3 No negotiation between MA
> and Controller
> 
> This is a really simple thing to do, and any good control protocol with
> a well-designed data model should be perfectly capable of this. It is
> not part of bootstrap.
> For example, if TR-069 were being used as the control protocol (and,
> yes, I'm talking about Control and not bootstrap), there would be an
> xml parameter that lists capabilities, as well as xml  parameters that
> match up to the enabling/disabling/execution of these capabilities, and
> setting of specific parameters associated with these capabilities. Via
> this exemplary TR-069 interface, the Controller can request the MA tell
> the Controller (1) the entire data model structure (every single xml
> parameter) and (2) the current values of these xml parameters (e.g.,
> the current value of a capability list xml parameter). It's not
> necessary to get this info every time. Important changes can be
> "evented", so the Controller is informed either that changes have
> occurred, and even what changes have occurred.
> 
> I don't know that I would call it a negotiation as much as the MA
> having proper ways to tell the Controller "No". Again, using TR-069 as
> an example, if the Controller tells the MA to set xml parameters that
> the MA doesn't have in its TR-069 data model, then the MA can say "No,
> I don't have those parameters." If the Controller tells the MA to set
> xml parameters that have been locked so they cannot be written to, then
> the MA tells the Controller "No, those are locked". If there is some
> temporary reason the MA can't comply, then the MA needs to tell the
> Controller "No, not right now".
> 
> Similarly, if a test were scheduled to be run by the Controller, and
> the MA doesn't run it for some reason, there should be an xml parameter
> that gives the reason why the test wasn't run (a status or result
> parameter). The allowed values defined for this parameter need to
> provide the necessary level of information to the Controller. When the
> Controller reads the value of that parameter, it gets the info it
> needs.
> 
> Since I know that TR-069 can easily do advertisement and negotiation
> with a well-designed data model (and, yes, in TR-069 this level of
> communication is done through data model parameters and their values
> and not through specific/different RPCs  or RPC error messages), I'm
> not understanding why there's debate about whether or not these should
> be criteria in Control protocol selection and requirements when doing
> that protocol's data model design. IMO, of course they're required.
> Barbara
>