[08:24:53] --- mrichardson has joined
[11:21:43] --- mrichardson has left: Disconnected
[12:03:11] --- SharonChisholm has joined
[12:03:37] <SharonChisholm> ---------------------------------------------
[12:04:30] --- mrichardson has joined
[12:05:49] <SharonChisholm> Jamal is presenting ...
[12:06:07] <SharonChisholm> forCES overview
[12:06:26] <mrichardson> I appreciate scribing.
[12:06:34] <mrichardson> since I have to be in another room.
[12:06:56] <SharonChisholm> <Ok ... I'll see what I can do, but I havn't read the drafts>
[12:07:38] <SharonChisholm> TML - connects stuff
[12:07:46] <SharonChisholm> Resolves underlying transport issues
[12:08:14] <SharonChisholm> several proposals for TMLs ...
[12:08:23] <SharonChisholm> 1) TIPC: L2/L1
[12:08:36] <SharonChisholm> 2) runs over tcp
[12:08:42] <SharonChisholm> 3) ?
[12:08:58] <SharonChisholm> PL-PL Logical Interface <picture>
[12:09:32] <SharonChisholm> PL termination typically at the LFB
[12:10:24] <SharonChisholm> Core LFBs
[12:10:40] <SharonChisholm> - needed for termination of messages addressed to FE or CE
[12:11:13] <SharonChisholm> - Three LFBs at the moment
[12:11:45] <SharonChisholm> (FE Object LFB, FE Protocol Object LFB, CE Object LFB)
[12:11:53] <SharonChisholm> L F B
[12:12:14] <SharonChisholm> FE Protocol Object LFB
[12:12:41] <SharonChisholm> responsible for protocol events that can be subscribes to, protocol capabilities, protocol attributes
[12:14:09] <SharonChisholm> FE Object LFB
[12:14:18] <SharonChisholm> responsible for FE Events management ... other things
[12:14:26] <SharonChisholm> CE Object LFB
[12:14:40] <SharonChisholm> responsible for CE event management
[12:15:20] <SharonChisholm> Protocol Grammar
[12:15:44] <SharonChisholm> LC LEvel PDU := PLHdr<LFBSelect>+
[12:16:06] <SharonChisholm> < that should read PL level>
[12:16:38] <SharonChisholm> LFBSelect :=LFBClassID LFBInstance <OPER>+
[12:16:59] <SharonChisholm> PLHdr defines message type and CE/FE Ids, etc
[12:17:16] <SharonChisholm> LFBClassId is an identifier
[12:17:26] <SharonChisholm> LFBInstance created at run time
[12:17:42] <SharonChisholm> Operation add, del, get, advertise, cancel, etc
[12:18:02] <SharonChisholm> path-data resource you apply operation on
[12:18:26] <SharonChisholm> nested TLVs <picture>
[12:19:41] <SharonChisholm> fits nicely into BNF and XML
[12:20:04] <SharonChisholm> Header -> LFBSelect->Operation->Path-data
[12:20:51] <SharonChisholm> batching: multiple operations
[12:21:13] <SharonChisholm> PL Message Types
[12:21:29] <SharonChisholm> - Association, Configuration, Query
[12:22:16] <SharonChisholm> PL Message Types
[12:22:34] <SharonChisholm> - event notification, packet redirection, heartbeat
[12:23:06] <SharonChisholm> Example
[12:24:11] <SharonChisholm> path data
[12:24:28] <SharonChisholm> - a path is a map to targeted element/entity
[12:24:54] <SharonChisholm> -- path is a series of 32 bit identifiers
[12:25:18] <SharonChisholm> -- elements targeted maybe capability, attribute, or event (under discussion)
[12:25:28] <SharonChisholm> - carries associated data where neeed
[12:25:49] <SharonChisholm> Simple Example: Attributes for NOP LFB
[12:28:46] <SharonChisholm> <still on the simple example>
[12:29:54] <SharonChisholm> Table operations under discussion ... to access multiple rows
[12:30:33] <SharonChisholm> complex example: attributes for NOOOP LFB
[12:33:03] <SharonChisholm> Open Issues: Show Stoppers
[12:33:12] <SharonChisholm> Consensus Path
[12:33:24] <SharonChisholm> Packaging/transporting of path referenced data
[12:34:06] <SharonChisholm> Open Issues: Resolvable
[12:34:13] <SharonChisholm> - operations on block data and content
[12:34:25] <SharonChisholm> - multicasting to LFB instances
[12:34:40] <SharonChisholm> - whether to split LFBSelector into two hierachies
[12:34:48] <SharonChisholm> - all messages terminate at LFB
[12:35:33] <SharonChisholm> ------------------------------------------------------------------------------------------
[12:35:56] <SharonChisholm> (S)
[12:36:01] <SharonChisholm> ---------------------------------------------------------------------------------------------------------------
[12:36:12] <SharonChisholm> Discussion on Path
[12:36:40] <SharonChisholm> robert channeling Weiming
[12:36:53] <SharonChisholm> data structures for LFB Attributes (1)
[12:37:32] <SharonChisholm> <picture>
[12:37:58] <SharonChisholm> Data Structures for LFB Attributes (2)
[12:38:21] <SharonChisholm> (LFB attributes here include attributes ....
[12:38:38] <SharonChisholm> an attribute may be atomic or a table
[12:38:42] <SharonChisholm> can be recursive
[12:38:52] <SharonChisholm> terminal fields contain values
[12:39:41] <SharonChisholm> Joel - he is explicit about what fields you are using as the index
[12:39:49] <SharonChisholm> A - yup
[12:40:53] <SharonChisholm> joel - seem to be a couple reasons .... trying to colapse the content addressing and subscripting .... I think that part of the reason ... some tables might not have a regular subscript ... that is a detail
[12:41:15] <SharonChisholm> joel - if you are going to allow subscripting ... you should be clear what you are using ... ip address, name, etc
[12:41:59] <SharonChisholm> joel - I think he wants to see things separately
[12:42:09] <SharonChisholm> summary
[12:42:27] <SharonChisholm> - attribute id and field id plays important roles for data structures of LFB attributes
[12:42:43] <SharonChisholm> - field id and index (subscript) are two totally different notions
[12:42:56] <SharonChisholm> joel - do you know why ... everything i do has them the same
[12:43:04] <SharonChisholm> path - index based
[12:43:22] <SharonChisholm> - use index i, j
[12:44:16] <SharonChisholm> path - field id based
[12:44:22] <SharonChisholm> - use field IDs only
[12:45:17] <SharonChisholm> path
[12:45:20] <SharonChisholm> - conclusion
[12:45:26] <SharonChisholm> - need both
[12:45:47] <SharonChisholm> - path = attributeid <index or field id>+
[12:46:30] <SharonChisholm> suggestion
[12:47:05] <SharonChisholm> - <index or field ids> part to be included in the data field rather than in the PL layer for the protocol to define the complex stricutres
[12:47:13] <SharonChisholm> <discussion>
[12:48:29] <SharonChisholm> <end o preso>
[12:48:37] <SharonChisholm> jamal - need some closure
[12:49:07] <SharonChisholm> robert - i don't see a difference between what i presented and what you presented
[12:49:20] <SharonChisholm> jamal - w sees a differences
[12:49:33] <SharonChisholm> chair - i have trouble seeing the difference too
[12:49:59] <SharonChisholm> <someone in the front said something without the mike)
[12:50:02] <SharonChisholm> -------------------------------------------
[12:50:14] <SharonChisholm> Robert is doing a second presentation
[12:50:28] <SharonChisholm> Merged: m1=PL-level mcast ID
[12:51:21] <SharonChisholm> <picture>
[12:51:39] <SharonChisholm> created a multi-cast group
[12:52:21] <SharonChisholm> merge approach 'cause the same identifier m1 goes into the LFB level multicast
[12:52:39] <SharonChisholm> second approach split: m1=PL-level mcast ID
[12:52:54] <SharonChisholm> il = virtual LFB instance ID
[12:53:59] <SharonChisholm> xcast: x,y=list of LFB instance IDs
[12:54:22] <SharonChisholm> q - instances must be in same class?
[12:54:29] <SharonChisholm> robert - i don't think so
[12:54:38] <SharonChisholm> <quiet question>
[12:54:58] <SharonChisholm> robert - we are investigating 'send this message to all LFBs of this type'
[12:55:09] <SharonChisholm> comparison of approaches
[12:55:25] <SharonChisholm> merged mcast, split mcast, xcast list
[12:56:53] <SharonChisholm> q - how to resolve <something>
[12:57:18] <SharonChisholm> robert - you need to know whenever you create a group that the id you will send this message to covers at least those that are interested
[12:59:07] <SharonChisholm> LFB for class; LFB for instance
[12:59:59] <SharonChisholm> comments? questions?
[13:00:01] <SharonChisholm> -------------------------------
[13:00:18] <SharonChisholm> (O)
[13:00:23] <SharonChisholm> --------------------
[13:00:25] <SharonChisholm> -------------
[13:00:34] <SharonChisholm> IP TML preso by Alex
[13:01:02] <SharonChisholm> Joel - i have a question ... when I look at the TML I was expecting something completly different
[13:01:39] <SharonChisholm> jamal - probably need to define API between things
[13:02:06] <SharonChisholm> joel - if it a protocol, we need to define the messages and how messages at one level relates to those at another level.
[13:02:21] <SharonChisholm> joel - i couldn't find that in either document. In fact, that is where I would start.
[13:03:13] <SharonChisholm> Forces-IPTML Design
[13:03:36] <SharonChisholm> forCES Framework
[13:05:46] <SharonChisholm> <gotta go (C) >
[13:05:53] --- SharonChisholm has left
[13:23:09] --- avri has joined
[13:24:30] --- oak has joined
[13:45:51] --- avri has left
[13:53:50] --- oak has left: Disconnected
[14:21:18] --- mrichardson has left