Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]

[Jamal Hadi Salim <hadi at znyx.com>]

Weiming,

On Fri, 2004-11-12 at 09:37, Wang,Weiming wrote:
> I just see random index is unavoidable regardless of rules used.

I agree there will be holes in the indixes. So this somehow needs to be
managed.


> > Or maybe i should start the discussion on encoding in parallel?
> That's fine.
> 

I am travelling today, but (at the cost of probably being frowned on)
heres the document i gathered from reading Steve/Zsolt doc. It talks
about content and block operations.

cheers,
jamal

This doc builds up on what was posted by Steve/Zsolt[1] to
try to map to protocol.
It by no means imposes a decision i.e tghis is merely here
as a discussion place holder with the a desire to speed things
up.

NOTE:
-----

A small reminder on layout:

main hdr (eg type = config)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = 0x45 
     |        |
     |        |
     |        +-- LFBInstance = 0x1234
     |        |
     |        +-- T = ADD //operation
     |        |   |
     |        |   +--  // path target X
     |        |        // with data to be added
     |        |        // This is the discussion point 
     |        |
     |        +-- T = ADD //operation
     |        |   |
     |        |   +--  // path target Y
     |        |        // with data to be added
     |        |        // This is the discussion point 
     |        |
     |        |
     |        +-- T  = DEL //operation
     |        .   |
     |        .   +--  // path target Z
     |        .        // This is the discussion point 
     |            

1) There could be multiple operations on any instance
2) path-data comes after the operation.
3) there is only one path-data per operation.

A possible path-data layout. 
----------------------------

OPER_TLV : = <PATH-DATA>
PATH-DATA := flags IDcount <IDs> [BLOCK_OR_KEY_NOTATION] [DATA]

The operational TLV contains an opcode in the T part. Its V
contains the PATH-DATA.
Opcodes discussed so far:
* SET (create, modify or both depending on PATH-DATA flags}
* DEL (remove an existing entity specified by PATH-DATA }
* GET (Access a entity specified in PATH-DATA }
* EV_S (subscribe to an event defined in PATH-DATA }
* EV_U (unsubscribe to an event defined in PATH-DATA }

-> IDs := a series of 32bit IDs (whose size is given by IDcount)
defining the path.
-> flags are used to further refine the operation to be applied
on the ID_TLV.
-> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension
defined in section 4.2 and 4.3 of [1]
-> DATA : = Optional variable sized data dependent on PATH
and applied operations (eg GET will not have DATA).

Some Clarification in relation to [1]:
-------------------------------------

[1] represents a requirement gathering/place holder.
This document is into details closer to implementation.

flags
-----

Derived from netlink and BSD route sockets to meet requirements
defined in [1]:

--> F_EXCL: 
The exclusive flag.
Donot replace the config attribute(s) if already exists -
Report back error instead.

A CREATE operation with this flag is equivalent to 
INS_IDX if index is passed and equivalent to  INS if index is 
not passed in the IDs.
A DEL with this flag is equivalent to DEL! in [1]. Without
this flag the equivalency is to DEL.

--> F_REPLACE: 
Replace existing matching config attribute(s) with passed 
data.  An index must be passed. In the case of key operations, a 
KEY must be passed.
A CREATE operation with this flag is equivalent to a SET
or a INS_IDX!.

Steve/Zsolt please double check that this is matching to your
doc.

A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET!

** Other flags used for block operations mentioned in the BLOCK section.

BLOCK and KEY path selection
-----------------------------

The <all> variant described in [1] is not needed. To get access
to all of table contents, the IDs merely need to point to the table.
Therefore to access a range, the IDs field will contain the ID
leading to a table and an optional TLV will include the range
information.

- Additional flags needed:
1)F_BLOCK_ON, to indicate block selector embeded
2)F_KEY_ON, to indicate a key selector embeded
#1 and #2 are mutually exclusive.
3) F_REV_TRAVERSE, to indicate reverse progress in the access.
4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is
on.
5) F_BLOCK_MODE (1 bit); indicates count or range for second
parameter of BLOCK Notation.

In the case of block operations: 

Two modes exist. [a,b] or [a,N]
We introduce a block TLV

T = BLOCK_TLV
    start // "a"
    end // "b" or "N"

The flag F_BLOCK_ON will indicate the presence of this TLV.
F_BLOCK_MODE will indicate that "end" is an "a" or "N"
F_REV_TRAVERSE will indicate whether reverse or forward progress

In the case of the associative paths: 
the flag F_KEY_ON will indicate that we are using associative approach 
F_KEY_MODE will define the mode .

We introduce a KEY_INFO TLV.

T = BLOCK_TLV
    KEY
    KEY_DATA

The length of the TLV will help deducing the size of the KEY_DATA.

DATA:
-----
Not discussing the optional data right now; a lot of details
above need ironing out first.
DATA is complex twist when it comes with variable sized data.

$Log: path-data-oper.txt,v $
Revision 1.2  2004/10/16 14:03:25  hadi
incoporating feedback from Joel et al

Revision 1.1  2004/10/14 13:12:32  hadi
Initial revision

_______________________________________________
Forces-protocol mailing list
Forces-protocol at ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol