Yes! With the intent that the alias may be in fact that of the peer. For instance if the server is a constrained node, the (fat) client would have an additional index to that table that is the deviceID or the groupID of the server. The server would indicate in the handshake that it is not capable to handle someone else's aliases. It could indicate its aliases in the first responses and from then on the client would use the server's aliases.
Cheers, Pascal From: Michel Veillette [mailto:[email protected]] Sent: samedi 13 juin 2015 08:55 To: Pascal Thubert (pthubert) Cc: Alexander Pelov; Andy Bierman; [email protected]; [email protected] Subject: RE: [6tisch] Reserve space for aliases Hi Pascal If I understand correctly your proposal * the range 1 to 3 is used to alias a data nodes based on a mapping table containing (module name or ID, YANG ID, alias ID). If this is the case, a single ID might be sufficient since it will allow aliasing of up to 1000 data nodes. * If I understand correctly, the range 4 to 60 is used to alias complete modules based on a mapping table containing (module name or ID, alias ID). Is it correct? [cid:[email protected]] 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: Pascal Thubert (pthubert) [mailto:[email protected]] Sent: 13 juin 2015 06:17 To: Michel Veillette Cc: Alexander Pelov; Andy Bierman; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [6tisch] Reserve space for aliases Hello Michel: Got you! Thanks for all ! For the last point I was in fact suggesting that we could also alias module IDs as opposed to leaves in the model. How many modules in one sensor? If that's less than 63 then they can all be aliased. Concatenation of all ideas give: 0 for short forms 1...3 for aliasing full data node IDs long forms 4..60 for aliasing module IDs meaning that the short form must be provided 61...63 reserved for experimentation Client and server would negotiate if the alias is take from server alias space or client alias space depending on which is constrained, default being server. This negotiation would work even if the module I'd is not yet allocated since it could be negotiated by name into a reserved alias 61..63. Makes sense? Pascal Le 12 juin 2015 à 23:53, Michel Veillette <[email protected]<mailto:[email protected]>> a écrit : Hi Alexander About "Yes, I suppose you should always start with aliases, but that doesn't sound like a strong constraint to me" If I take the following example: GET example.com/mg?select<http://example.com/mg?select>(1, 2, 2049, 3) Data node ID 1 and 2 can be associated with module ID 0 (aliases) but data node ID 2049 and 3 are associated with module ID 1. I don't understand how aliases can be added at the end of this list without been processed as short form. Please confirm my understanding. Hi Andy About "The data is hierarchical and the parser is required to maintain the current module scope. It should be possible to omit the module identifier for nested data, except for nodes that start a new module scope. Is this what you have in mind?" Yes I'm proposing to use the same model as JSON with a long form consisting of a 20 bits module ID/10 bits YANG ID and the short form consisting of a 10 bits YANG ID. About "I am not convinced that aliases are worth all the effort because most (95%?) of the IDs in the payload will only need 10 bits." Agree In most cases, the message size compression will same just a couple of bytes. As mentioned by Alexander, we can simply reserve a range for aliases (e.g. module ID 0) but defer the resolution to a different draft. Hi Pascal About "I understand that any sensor vendor will want to have its own module IDs, correct?" Correct, with 20 bits, we can allocate 1 000 000 module ID. This can be done one by one or by small bundle of module IDs (e.g. 4, 8, 16 IDs). About "I have missed the trick of 63 module IDs that are optimally encoded" When using the long form (20 bits module ID, 10 bits YANG ID), data node ID small enough to fit on 16 bits are encoded using CBOR in 3 bytes. Since the YAND ID takes 10 bits, we have 6 bits left for the module ID (64 IDs minus ID 0 reserved for the short form). Module ID greater than 63 require the use of the 5 bytes CBOR encoding. About "If so: maybe we should alias the module IDs so that the 63 IDs that benefit from the optimal CBOR compression should be the aliases of any of the thousands of IDs that will soon exist in the registries." A possible solution is to reserve module ID 0, 1, 2 and 3 for aliases which will leave 60 "more optimal" module IDs. The specific use of the reserved module IDs can be addressed in one of multiple subsequence drafts. What is important for now is the establishment of a consensus around the core concepts discussed: * registered 20 bits module ID * 10 bits assigned YANG ID * long form / short form data node ID * select encoded in CBOR <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: Pascal Thubert (pthubert) [mailto:[email protected]] Sent: 12 juin 2015 21:11 To: Michel Veillette; Alexander Pelov Cc: Andy Bierman; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [6tisch] Reserve space for aliases Hello Michel: I'm not so worried for 6TiSCH's ID than for the IDs used to collect data from sensors. Because that is the operation that will happen all the time an suck batteries. I understand that any sensor vendor will want to have its own module IDs, correct? And soon enough that vendor will come with variants of his products, and will want more module IDs, is that right? If I'm correct, this pleads for aliases; but maybe not as we thought them. I have missed the trick of 63 module IDs that are optimally encoded, but I trust you on that - I figure that it is because it takes 2 bits to encoded the coap option? If so: maybe we should alias the module IDs so that the 63 IDs that benefit from the optimal cbor compression should be the aliases of any of the thousands of IDs that will soon exist in the registries. Also note that device makers will want the vendor specific range that they use to play with before something is registered. Aliases could also be a way to play with module IDs that have not yet been registered to IANA. I'm not sure the above makes sense since it is based on a partial understanding of your work so far... Pascal From: Michel Veillette [mailto:[email protected]] Sent: vendredi 12 juin 2015 09:58 To: Alexander Pelov; Pascal Thubert (pthubert) Cc: Andy Bierman; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [6tisch] Reserve space for aliases 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]<mailto:[email protected]>; [email protected]<mailto:[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]] 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
