This is a document that captures thoughts discussed starting at the SD IETF and thereafter in many many emails involving the model team. It is only meant as a guidance, the Protocol design team may decide to rearrange things as long as the requirements discussed are met. PL level PDU : = MAINHDR+ LFBselect := LFBCLASSID LFBInstance + OPER:= ]*>+ - MAINHDR defines msg type, Target FE/CE ID etc. the MAINHDR also defines the content. As an example the content of a "config" message would be different from an "association" message. - LFBCLASSID is a 32 bit unique identifier per LFB class defined at class creation time. - LFBInstance is a 32 bit unique instance identifier of an LFB class - OPERATION is one of {ADD,DEL,GET, ??} path-data identifies the exact element targeted. It may have zero or more data values associated. In summary the described approach has the following characteristic: - there can be one or more LFB Class + InstanceId combo targeted in a message (batch) - There can one or more operation on an addressed LFB classid+instanceid combo(batch) - There can be one or more path targets per operation (batch) - paths may have zero or more data values associated (flexibility and operation specific) It should be noted that the above is optimized for the case of a a single classid+instance targeting. To target multiple instances within the same class, multiple LFBselect are needed. To illustrate, -------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x1234 | | | +-- T = ADD | | | | | +-- // one or more path targets | | // with their data here to be added | | | +-- T = DEL | . | | . +-- // one or more path targets to be deleted | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x145 | | | | // at row index 7, replace foo1 | + -- T= ADD | | | | | | | // Block del operation on row 1-4 of table X | + -- T= DEL | | | | // at row index 70, get the value of foo2 | + -- T= GET | | +--- T = LFBselect | +-- LFBCLASSID = 0x145 | +-- LFBInstance = 0x14 . . . Main Hdr: -------- As shown above the layout begins with the main header identifies the the msg type such as "config". The main header identifies the source and target FEid/CEid. LFBselect --------- A TLV. The value contains the LFB class being selected, the instanceid within the LFB class being targetted and and one or operational TLVs defining various operations executed on the LFB instance. Operation --------- A TLV. The T defines the type of operation eg ADD. The value contains one or more path-data. path-data ---------- The layout is still under discussion and so is left out from this text. Each accessible attribute within an LFB is expected to have a 32 bit identifier. The path-data will have a map derived from the static class attribute IDs as well as those derived from variable content such table indices (derived at runtime). Below is an illustration of a complex example and how the different attributes could be accessed. Assume LFB Class A. It contains two Arrays, B, and C (assigned identifiers 1 and 2) A also contains a structure of type Stoo with a human name F. F is assigned ID 3. A also contains two attributes, D and E assigned identifiers 4 and 5. Array B is an array, indexed as a table, whose contents are int32s. Array C is an array, indexed as a table, whose contents are a structure named Star. Stoo type structures contain elements X and Y, each characters, assigned identifiers 1 and 2. Star contains An element N (a sting), assigned identifier 1, and an array Arr, assigned identifier 2, indexed as a table, containing int32s. To reference entities within an LFB instance of Class A, selectors are as follows: 1, meaning the full array B 3, meaning the full structure named F. 2, 7 meaning the full structure in the seventh entry of the array C. 4 means the attribute D 2, 8, 2, 9 meaning the 9th number in the array in the structure in the eigth slot of the array C. Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct type definition. Since the model team has asserted that class definitions can only change (version) in ways that leave existing references intact and usable it means backward compatibility is supported. Other Issues that came up -------------------------- 1) Scope of Ts. It is expected that most of the Ts would be global. There may be however desire to have localy scoped Ts depending on the LFB class 2) Can the same Ts be repeated multiple times within a hierachy? Yes. 3) Need to agree on content addressing $Log: msg-discuss.txt,v $ Revision 1.6 2004/10/12 14:34:40 hadi updated the instance and classid to be in the same TLV Revision 1.5 2004/10/06 15:10:37 hadi More discussions with Joel - I think we have reached a compromise Removed any references to how paths are achieved; leave that to the Doc from Steve and Zsolt (for now at least) Revision 1.4 2004/08/28 18:11:25 hadi reached semi-convergence with Joel Revision 1.3 2004/08/27 01:06:34 hadi Adding Joels views on the OPER approach Revision 1.2 2004/08/12 12:47:21 hadi updated diagram per Zsolts comments Revision 1.1 2004/08/12 11:34:25 hadi Initial revision