Hi Michel, You’re right. As I mentioned in my previous mails, I’m pretty happy with the compression of IDs we’ve achieved until now, so aliases are not as a pressing issue.
The thing is, if they can be implemented at (almost) zero cost, then some of the use-cases become quite interesting. You actually provide a very good case with the select option. I’ve not thought if it will present some other difficulties, but I actually think it facilitates the use of aliases (and I mention this only because it will help me also understand the semantics of your proposal of the select option). If I take the example you provide: > REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4] ) The parameters 2,3,4 are actually relative to the module ID of the first one. So, if I try to generalize this (please correct me if I’m wrong), I would imagine something like: > REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4, > 4097,2,3,4] ) To resolve to getting module ID=1, relative node IDs=1,2,3 and 4, and module ID=2 and relative node IDs =1,2,3 and 4. This means, that specifying a GET example.com/mg?select(1) should resolve to module ID=0 and relative node ID=1. This requires absolutely no additional processing from the node. So, this leaves us back to the initial idea of the aliases. All short node IDs are relative to a module ID (so that the long form ID can be interpreted). Module ID=0 is reserved, and can be used for aliasing if the device wishes to support it. Does this break some of the things along the way? Best, Alex > Le 12 juin 2015 à 18:57, Michel Veillette <[email protected]> > a écrit : > > Hi Alexander, hi Pascal > > I want to emphases the following points > > · The use of the select query parameter encoded in CBOR support of 63 > modules with optimized message size instead of only 3 for the base64 URI. > If the 6TiSCH module ID is allocated within these 63 IDs, there will be no > message size optimization provided by the aliases mechanism. > This make the introduction of aliases less urgent. > > · The message size of the select query parameter encoded in CBOR > should be equal or smaller compared to the base64 URI. > However, the select query parameter encoded in CBOR support a wider range of > values without size penalty (16 bits instead of 12, 32 bits instead of 30) > Furthermore, CoMI devices won’t have to support two type of encoding > depending if IDs are part of the command vs. payload. > > For example: > > Assuming module ID 2 > Assuming data node ID 1, 2, 3, 4 (long form 2049, 2050, 2051) > Assuming “,” separator to select multiple data nodes > > Base64 approach: > REQ: GET example.com/mg/gB <http://example.com/mg/gB> (3 bytes; 1 > byte for the “/”, 2 bytes for “gB”) > > CBOR approach: > REQ: GET example.com/mg?select <http://example.com/mg?select>(2049) > (4 bytes; one byte for the CoAP option, 3 for 2049 encoded using CBOR) > > Base64 approach: > REQ: GET example.com/mg/gB,C,D,E <http://example.com/mg/gB,C,D,E> (9 > bytes; 1 byte for the “/”, 8 bytes for “gB,C,D,E”) > > CBOR approach: > REQ: GET example.com/mg?select <http://example.com/mg?select>( [2049,2,3,4] ) > (8 bytes; 1 byte for the CoAP option, 1 for the CBOR array, 3+1+1+1 > bytes for the IDs) > > > <image001.jpg> > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] <mailto:[email protected]> > www.trilliantinc.com <http://www.trilliantinc.com/> > > > From: Alexander Pelov [mailto:[email protected]] > Sent: 11 juin 2015 17:06 > To: Pascal Thubert (pthubert) > Cc: Andy Bierman; Michel Veillette; [email protected]; [email protected] > Subject: Re: [6tisch] Reserve space for aliases > > Hi Pascal, > > Le 10 juin 2015 à 15:25, Pascal Thubert (pthubert) <[email protected] > <mailto:[email protected]>> a écrit : > > Dear all: > > This looks like the problem of local namespaces, which is the reason why > MPLS switches labels. > The user may access a limited set of resources from a number of servers, and > servers are read by many users. > You cannot ensure that you have a single alias space that satisfies them all. > > Great analogy! And yes, sadly you cannot satisfy them all, at least not with > all devices. > > > > So ,what if the user had its own set of aliases and the server also had its > own set of aliases? > > The aliases could be mapped in a table like a uSAP and a pSAP are mapped > across layers. Broadly: > - First time a user requests a resource in a server, it comes with a tuple > (userid, useralias, fullname) > - The server responds with (serverid, serveralias, userid, user alias). > > Actually, I think that this could be worked out in CoMI also. Instead of > fullname you could provide the YANG id (module ID + data node ID) and do the > mapping. User alias would be the special aliased YANG id. User ID, however, > could be a little bit more tricky - how do we ensure that it is consistent? > Use the IP address of the client could be doable, but we’ll have to include > the UDP port just in case someone runs two clients on the same machine. > > > > > After that, if the server is a constrained device then the user talks to the > server with (serverid, serveralias) and the user maintains a switching table > for the resource it uses on various servers. > If the user is the constrained device and the server is not, the user could > talk with (userid, useralias) and the server maintains a switching table. > > For large servers, the server may allocate aliases dynamically based on what > it is being asked. We’d then need to talk about alias update or revocation, > probably in terms of session and lifetime. > > Does that look usable? > > You are pointing out an interesting question. I would think (but maybe I’m > mistaken), that the client should have the leading role in figuring out > what’s happening. The idea is the following: > > The client checks if the server supports aliasing, with the possible options: > S1) no aliasing > S2) static/server-defined aliasing > S3) dynamic/single alias mapping > S3.1) mapping already defined > S3.2) no mapping defined > S4) dynamic/per client alias mapping > > Then, the client can take action, depending on its own capabilities and the > response of the server. E.g. a unconstrained client could obtain the alias > mapping if it is static (or if there is a single alias mapping in place) and > cache it locally. So, there will be the following correspondence : > > Given: > C1) constrained client > C2) unconstrained client > > We have: > C1 + S1) no aliasing, nothing to do > C1 + S2) and C1 + S3.1) if the alias mapping is known, use it. otherwise, > ignore > C1 + S3.2) and C1 + S4) define alias mapping > > C2 + S1) no aliasing, nothing to do > C2 + S2) and C2 + S3.1) if the alias mapping is known, use it. otherwise, > learn it > C2 + S3.2) and C2 + S4) define alias mapping > > I would say that the analogy you made with MPLS corresponds quite a lot to > the C2+S4 case. Personally, I would be most interested into having one client > configure one alias mapping to all servers in the network (e.g. the managing > entity), which will profit most from saving several bytes on each message > exchange. Everyone else could use the standard IDs, which we’ve already > managed to shrink significantly. > > Indeed, with structured module ID + data node ID (20 bits + 10 bits), YANG > URI compression, and long form/short form, we’ll have quite a lot of gain. > Reserving module ID = 1 for aliases and maybe writing a short draft on how > the aliasing is implemented seems feasible, where we can cover the exact > mechanism of alias definition, and client/server interaction. > > Alexander > > > Pascal > > From: 6tisch [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Andy Bierman > Sent: vendredi 5 juin 2015 20:55 > To: Michel Veillette > Cc: [email protected] <mailto:[email protected]>; Alexander Pelov; [email protected] > <mailto:[email protected]> > Subject: Re: [6tisch] Reserve space for aliases > > > > On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette > <[email protected] > <mailto:[email protected]>> wrote: > Hi Alexander > > I have some concerns about allowing CoMI client(s) the control of the list of > aliases. > This approach work fine for the first CoMI application (e.g. 6TiSCH) but what > do we do with the subsequent CoMI application? > > One possible solution is that each CoMI client send a list of (alias, data > node ID) to the CoMI server. In this case, the CoMI client might receive an > error if one or multiple of these aliases are already reserved. > > A second possible solution is that each CoMI client send a list of (data node > ID) and get a list of (alias, data node ID) from the CoMI server. In this > case, CoMI clients will have to deal with a mix population of aliases. > > The proposed solution need to scale to a multi-vendors, multiple applications > environment. > With this is mind, do you have any alternative solutions to propose? > > > > Does this approach allow each client to have a different set of aliases, > so the server has to maintain a configured mapping for each client? > This seems like a lot of overhead and NV-storage requirements > on the server. > > Changing the schema identifiers based on which client is > sending the request seems like a complicated design change > from RESTCONF, NETCONF, or SNMP, where there is only > 1 schema tree which is not dependent on the client identity. > > > Andy > > > > > <image001.jpg> > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] <mailto:[email protected]> > www.trilliantinc.com <http://www.trilliantinc.com/> > > > From: Alexander Pelov [mailto:[email protected] > <mailto:[email protected]>] > Sent: 5 juin 2015 12:03 > To: Michel Veillette > Cc: Andy Bierman; [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > Subject: Re: Reserve space for aliases > > Hi Michel, > > > Le 5 juin 2015 à 17:17, Michel Veillette <[email protected] > <mailto:[email protected]>> a écrit : > > Hi Alexander > > In your presentation at 6TiSCH, you propose the following data node ID > structure. > > • 32 bits YANG ID > – 20 bits for module ID (assigned by IETF) > – 10 bits for data node ID (generated deterministically) > > Based on this structure, we can reserve module ID zero for aliases. > > > I was just summarizing what was discussed on the discussion in CoMI. > Actually, it is 30 bits YANG ID, but that’s for purposes to be consistent > with the YANG hash and I don’t mind keeping it 30 bits. > > > > If we want to minimize both the network an node resources require by this > alias mechanism, we can map an entire module to this space. > This can be implemented by a single integer resource (e.g. leaf > alliassedModule { type uint32 } ) > This approach require 4 bytes per CoMI server accessed. > > > It is possible to map an entire module to the alias space and this is up to > the operator. However, if you load two modules which redefine the same alias > you will loose the benefit from it. Maybe it would be interesting to be able > to specify that you want the aliases from THIS specific module to be used. > > If the /mg/0 alias is reserved for managing the aliases, this could be simply > saying: > POST /mg/0 > { > "source_uri" : "/mg/BAA" > } > > where /mg/BAA is the YANG id of the module (20 bits module ID + 10 bits set > to 0). This way, the server will know: OK, get the alias mapping from the > YANG scheme of module with ID = B (as defined by the IETF). > > Or, you can dynamically configure the mapping: > POST /mg/0 > { > YANG_id : alias, > YANG_id : alias, > YANG_id : alias > } > > > If we want a more complex but more flexible aliases mechanism, your proposed > map of (allias, YANG ID) seem the solution. > However, we have to consider that this structure can be as large as 1250 > bytes per CoMI server accessed if limited to 256 aliases. > > This is assuming you need a separate mapping for each server. I would suppose > that in a network you’ll have a single alias mapping (maybe two?) - after > all, you’re trying to optimize the management of your devices (servers). So, > typically you’d map all 6tisch devices with aliases 1-10 (channel, slot, > etc.) and use that on them, and on all other you’d access the full ID. > > Best, > Alexander > > > > <image001.jpg> > Michel Veillette > System Architecture Director > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] <mailto:[email protected]> > www.trilliantinc.com <http://www.trilliantinc.com/>
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
