1 / 8

Discussion on Path

Discussion on Path. Weiming Wang <wmwang@mail.hzic.edu.cn> IETF 61th Meeting, Washington, Nov.7-12, 2004. Data Structure for LFB Attributes (1). AttrID2. AttrIDx. AttrID1. …. Value=v1. i. f1 | f2 | …. Value=vf1. j. g1 | g2 | …. Value=vg1. LFB. Value=vg2.

angela-gillespie
Download Presentation

Discussion on Path

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. Discussion on Path Weiming Wang <wmwang@mail.hzic.edu.cn> IETF 61th Meeting, Washington, Nov.7-12, 2004

  2. Data Structure for LFB Attributes (1) AttrID2 AttrIDx AttrID1 … Value=v1 i f1 | f2 | …. Value=vf1 j g1 | g2 | …. Value=vg1 LFB Value=vg2

  3. Data Structure for LFB Attributes (2) (LFB attributes here include attributes, events, capabilities) An LFB contains attributes identified by Attribute IDs LFB Attributes = { AttrID1, AttrID2, … } Attribute IDs are defined by XML (Static) An Attribute may be composed of no or several fields (compound), e.g.(in the figure), AttrID1={}, AttrID2={f1, f2, … }, Where, AttrID1 has no field (actually means only one field therefore do not need to ID it, while AttrID2 has fields f1, f2… Every field has a fieldID, which is also defined by XML(static)

  4. Data Structure for LFB Attributes (3) • An attribute may be atomic or a table, e.g. (in the figure), • Atomic: AttrID1 • Table: AttrID2[i] where ‘i’ is called index or subscript for a table (dynamic) • A field can be recursive in the data structure, e.g.(in the figure), • f2 in AttrID2 above may be another table with compound subfields as: f2[j]={g1, g2, …} where, j is index for the table, g1, g2 … are subfields (static). • Terminal fields (not recursive anymore) then have values, e.g. (as in the figure), • AttrID1=v1 • AttrID2[i=1].f1=vf1 • AttrID2[i=1].f2[j=1].g1=vg1, AttrID2[i=1].f2[j=1].g2=vg2

  5. Data Structure for LFB Attributes (4) • Summary • Attribute ID and Field ID plays important roles for Data structure of LFB attributes • Field ID and index(subscript) are two totally different notions

  6. Path – Index based • Use index i, j e.g., • Get i=10 in table of AttrID2 • Path = AttrID2[i=10] • Get j=20 in table f2 of table AttrID2 • Path = AttrID2[I=10]. f2[j=20] • Comments • Simple in expression and fast for searching • Should use Attribute ID and field ID (f2) as well as index i,j. • Not valid for items that do not have index, like atomic item, and events, capabilities that do not originally have index • Not always necessary for small size tables

  7. Path- field ID based • Use field IDs only, e.g., • Get value of AttrID1 • Path = AttrID1 • Get items of AttrID2 which meet the conditions as f1= vf1 and g1=vg1 • Path = {AttrID1.f1= = vf1} && {AttrID1.f1.g1 = = vg1} • Comments • Do not need to manage index • Fit for attributes with atomic or small size table data types, and for capabilities and events that do not originally have index. • Is content based searching, lower the efficiency for large scale tables

  8. Path • Conclusion • Index based and field ID (content) based addressing are all necessary • The Attribute ID part is always needed for both ways, therefore can be pulled out, as • Path := AttributeID <Index or Field Ids>+ • Suggestion • The followed <Index or field Ids> part be included in the Data field rather than in the PL layer for the protocol to define the complex structure like [I=10]. f2[j=20] {AttrID1.f1= = vf1} && {AttrID1.f1.g1 = = vg1} The End

More Related