On Fri, Jun 12, 2015 at 8:53 PM, Michel Veillette < [email protected]> wrote:
> *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(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. > > > I like your proposal to allow support for numbered objects. 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. > > > I think reserving module ID zero is OK for that > *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. > I think CoMI should support "replaceable" numbering schemes, which should be identified in the server capabilities somehow. I prefer if the server used 1 numbering scheme, not 1 per node. I proposed a conformance "package" in a now expired draft called YANG Conformance. A conformance profile can include multiple modules, and specify the required revisions and features as well. The point is that an arbitrarily large set of modules can be reduced to a single identifier. The profile could be extended to support ad-hoc numbering of all the objects in the package. This works best for lots of the similar devices which all implement the same set of modules, so there are a small number of packages to manage. The server would advertise its 1 (or more) package IDs. There is no need to use the 20 bit module ID at all if the server supports only 1 conformance package. 10 bits might be tight for numbering all the protocol accessible objects in the YANG modules in each package. I think 12 bits would be needed. This would also allow YANG modules to be numbered without a centralized authority. A CoMI package could even define the "standard" aliases, if that was supported. Do you think something like this would be useful for CoMI? Andy > > 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 > > > > [image: cid:[email protected]] > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > 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]; [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] > <[email protected]>] > *Sent:* vendredi 12 juin 2015 09:58 > *To:* Alexander Pelov; Pascal Thubert (pthubert) > *Cc:* Andy Bierman; [email protected]; [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 (3 bytes; 1 byte for the “/”, 2 bytes > for “gB”) > > > > CBOR approach: > > REQ: GET 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 (9 bytes; 1 byte for the “/”, 8 > bytes for “gB,C,D,E”) > > > > CBOR approach: > > REQ: GET 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) > > > > > > [image: cid:[email protected]] > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > www.trilliantinc.com > > > > > > *From:* Alexander Pelov [mailto:[email protected] > <[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]> > 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] <[email protected]>] *On > Behalf Of *Andy Bierman > *Sent:* vendredi 5 juin 2015 20:55 > *To:* Michel Veillette > *Cc:* [email protected]; Alexander Pelov; [email protected] > *Subject:* Re: [6tisch] Reserve space for aliases > > > > > > > > On Fri, Jun 5, 2015 at 11:41 AM, Michel Veillette < > [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] > > www.trilliantinc.com > > > > > > *From:* Alexander Pelov [mailto:[email protected]] > *Sent:* 5 juin 2015 12:03 > *To:* Michel Veillette > *Cc:* Andy Bierman; [email protected]; [email protected] > *Subject:* Re: Reserve space for aliases > > > > Hi Michel, > > > > > > Le 5 juin 2015 à 17:17, Michel Veillette < > [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] > > www.trilliantinc.com > > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
