Re: [pcp] Side-by-side or nested protocols (was Re: PANA implementatinos to consider)

[Margaret Wasserman <[e-mail]>]

Hi Alper,

On Sep 18, 2012, at 3:30 AM, Alper Yegin wrote:
> But more interestingly, you said you are not aware of any PANA implementations in production.
> As we said before, PANA is adopted into Zigbee Smart Energy Profile 2.0
> And it passed several interop events, with 10 implementations.

Do you actually think that any nodes that implement SEP 2.0 will implement PCP?

[For those unfamiliar with Zigbee SEP 2.0, it is one of the standards (the only IP-based one, I think) proposed for use in the Smart Grid, specifically for appliances, sensors and other embedded devices to integrate with a home energy management system (EMS) and/or electric meter (Smart Meter) on the in-home side of the Smart Energy universe.  Implementations of SEP 2.0 are most often provided in ASICs, for integration into embedded devices with very limited system requirements.  These devices run on a dedicated Zigbee networks within the home, and do not generally communicate outside the home, at all.]

> Yes, it could be tricky, if we had a funky relationship between the two protocols. But in this case, it's a clean separation. PCP needs keys to run, it triggers PANA to generate the keys, PANA does its job and gives back the keys, PCP runs with the keys. This is how separate "key management" works. Natural fit.

The success case in the side-by-side approach appears to work very smoothly, it is the error cases that I am more concerned about.  Also, you haven't explained how you would deal with all of the things you list below...  If PCP has a simple request/response API with PANA, how are things like "asynchronous requests" handled in that model?  What is an "asynchronous request" in this context and when/why would it happen, BTW?  I understand that, in PANA, it is possible for network access to be renegotiated, or for Ip addresses to be reallocated.  There is no equivalent notion in PCP, though.

> But, if we embed one protocol inside the other, then you have to combine the state machines. And that combining is not a simple jump back and forth like in the above case. More specifically, within the PCP state machine, now you have to account for server-side retransmissions, server-side asynchronous requests, etc.

You keep claiming that there will be problems with "combining the state machines" of PCP and PANA in the encapsulation case that aren't there in the side-by-side case, but I'm still not sure what you mean by this.  Could you give a concrete example?

>> PCP is capable of sending unsolicited messages (both multicast and
>> unicast). So, we are good here.
> 
> You are referring to "announcements" right?
> They are one-way notifications.
> What you need is a server-initiated, multi-round-trip req/rsp exchanges -- to have a working EAP lower-layer.

How do we get this in a model that you have described as:  "PCP needs keys to run, it triggers PANA to generate the keys, PANA does its job and gives back the keys, PCP runs with the keys. "  Won't this notion (of server-initiated messages) need to be integrated into the API between PCP and PANA somehow?  When would these messages ever happen in the PCP context?

Margaret