110 likes | 116 Views
Changes to the ForCES Model. 7-March-2005 Presented by Joel Halpern jhalpern@megisto.com. Summary of Changes. FE Object now an LFB Added Element Identifiers For LFB Classes, LFB attributes, and structure components Add Content Keying Added Alias starting point
E N D
Changes to the ForCES Model 7-March-2005 Presented by Joel Halpern jhalpern@megisto.com
Summary of Changes • FE Object now an LFB • Added Element Identifiers • For LFB Classes, LFB attributes, and structure components • Add Content Keying • Added Alias starting point • Added variable length octet sequences
FE Schema -> LFB Class • Class ID 1, Instance ID 1 • Captures all the information that what is in the previous FE schema • Called the FE Object LFB Class • Probably still could use some additional information
Element Identifiers • For LFB Classes, added attribute LFBClassID to hold the identifier of the class. • Class IDs must be globally unique, across all libraries. Should we introduce a 16 bit library ID? • For attributes, capabilities, and structure elements, added elementID attribute • Provides identifiers for use in paths
Content Keying • An array declaration can declare one or more combinations of fields as keys. • Each key is declared with a <key> element. • Which has a keyID attribute • And one or more <keyField> elements to declare the parts of the key • Should this be called “contentKey”? • Should we wrap the multiple <key> occurences in a <keys> (or <contentKeys>) element?
Key Declaration Example <array type=“variable-size”> <typeRef>IPneighbor</typeRef> <key keyID=“1”> <keyField>IPaddress</keyField> </key> </array> Assuming that IPneighbor has IPaddress
Alias – for sharing between LFBs • An <alias> declaration declares • The name of the alias • The type of the alias • And has an elementID attribute • An Alias implicitly creates four pieces • The LFB Class and LFB instance of the target • The path to the target attribute • An element to dereference to the shared value
Issues and Topics • Configured Adjacency Description • Element Meta Information • Events • Optional Elements • Unlimited length strings
Configured Adjacency • The current definition reflects configuring • MAC or IP address of the neighbor • the port through which the neighbor is reached. • Suggestion is to replace the address with the nrighbors FE ID and port information • Since this is for the case where the neighbor is under control of the same CE
Element Meta-Information • Currently, we have capabilities • Which can carry anything at the LFB level • No easy way to express consistent capabilities • No easy way to express structure or array element capabilities • Optional elements, read / write • Should we create a protocol syntax for working with this kind of information?
Events • We have to have event reporting • We have to have a way to define what events an LFB may generate • And what information to include in the report • We need boolean variables for the CE to set which events it wants • And this has to be understandable. It is way to easy to get very complex here