1 / 11

Changes to the ForCES Model

Summary of changes made to the ForCES Model on March 7, 2005, including additions like FE Object as LFB, Element Identifiers, Content Keying, and more. Issues discussed include Adjacency, Meta-Information, Events, and Optional Elements.

wgray
Download Presentation

Changes to the ForCES Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Changes to the ForCES Model 7-March-2005 Presented by Joel Halpern jhalpern@megisto.com

  2. 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

  3. 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

  4. 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

  5. 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?

  6. Key Declaration Example <array type=“variable-size”> <typeRef>IPneighbor</typeRef> <key keyID=“1”> <keyField>IPaddress</keyField> </key> </array> Assuming that IPneighbor has IPaddress

  7. 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

  8. Issues and Topics • Configured Adjacency Description • Element Meta Information • Events • Optional Elements • Unlimited length strings

  9. 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

  10. 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?

  11. 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

More Related