From nv33134@yahoo.com Thu Sep 2 18:32:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18880; Thu, 2 Sep 2004 18:32:46 -0400 (EDT) Date: Thu, 2 Sep 2004 18:32:46 -0400 (EDT) Message-Id: <200409022232.SAA18880@ietf.org> Received: from [218.12.34.234] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C30Ar-0006o4-9e; Thu, 02 Sep 2004 18:35:24 -0400 From: "Brasil 2004 / Informe Exclusivo" To: MapaAtualizado2004@local.cnri.reston.va.us Subject: Mapa atualizado da "esquerda católica" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html X-Spam-Score: 28.8 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

InfoGratuitaProximosLancamentos - LinkToFreeAutomaticTranslator (Castellano, English, Français, Deutsche, Português, etc.)

Brasil 2004: reportagem desenha mapa atualizado da "esquerda católica"

* A "esquerda católica", sua influência visível na esfera sociopolítica, e seu poder subterrâneo através de redes capilares e "vasos comunicantes" no Brasil de hoje, é apresentada num livro-reportagem inédito de 56 páginas, de fácil leitura e ampla documentação.

* "Pastoral da Terra e MST incendeiam o País" é ao mesmo tempo um mapa atualizado e um instrumento informativo indispensável para quem deseja conhecer os possíveis rumos sociopolíticos do Brasil de amanhã.

* O autor, o advogado e pesquisador Gregorio Vivanco Lopes, com mais de 30 anos de especialização no tema das comunidades eclesiais de base e da teologia da libertação, mostra a real dimensão da Pastoral da Terra e do MST, duas pontas de um mesmo e gigantesco iceberg que a mídia nem sempre revela e que a opinião pública ignora.

* A força e o talão de Aquiles da "esquerda católica" descritas num informe objetivo, documentado e sereno que todo brasileiro deve ler, ainda que para discordar e debater de maneira invariavelmente respeitosa, em prol da paz social no Brasil.

* O autor do livreto "Pastoral da Terra e MST incendeiam o País" exerce o legítimo direito de informar, e favorece também o direito de cada brasileiro de ser informado, condições ambas indispensáveis para uma autêntica democracia.

* Solicite gratuitamente, por e-mail, o Índice e a Introdução contendo um resumo da reportagem e a capa da edição impressa:

IntroCapaGratuitas

* Envie seu voto eletrônico e, se possível, sua valiosa opinião a respeito do tema abordado, e receberá informação gratuita sobre próximos lançamentos:

- Lopes:Concordo

- Lopes:EmTermos

- Lopes:Discordo

* Para enviar mensagem ou tomar contato com o autor, clique em:

Lopes:MinhaMensagem (ou ligue para 11-38223241 / 11-38281102

* Caso deseje adquirir a versão impressa (R$ 10,00 correio incluído), clique no link: DesejoAdquirirLivro (receberá as instruções do distribuidor, de exclusiva responsabilidade deste).

* Caso deseje receber, por e-mail, o e-Book com o texto completo da reportagem (R$ 1,99), clique no link:

DesejoAdquirirEBook

* Para ser retirado de nosso Address Book, por favor, clique em:

RetirarImediatamente

From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 6 00:25:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15247 for ; Mon, 6 Sep 2004 00:25:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4B7Y-0006WD-SC for forces-archive@IETF.ORG; Mon, 06 Sep 2004 00:28:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00E6F502@cherry.ease.lsoft.com>; Mon, 6 Sep 2004 0:25:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34130861 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Sep 2004 00:25:29 -0400 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 6 Sep 2004 00:14:42 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 88704.804536222; Mon, 6 Sep 2004 12:24:32 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Mon, 6 Sep 2004 12:17:26 +0800 References: <1093716884.1074.140.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <001901c493c7$5da66f20$845c21d2@Necom.hzic.edu.cn> Date: Mon, 6 Sep 2004 12:09:53 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated message layout doc To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi Jamal, To respond to your ask for more detailed description of my thoughts, I compose a text in the attachement. Because it is just for discussion, I think you may not care too much about the roughness of the text. Thank you. Hi Ellen, I'm ok with the time you scheduled. Thank you. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > Attached a little document to reinject stalled discussion. > > Purpose is to help reach a quicker convergence > on the message layout as well as influence how the > model and protocol teams on moving forward. This should reduce > current confusion on both sides on how message content is > delivered and how such content is to be modeled so it can > be appropriately delivered. > It captures my thoughts that are influenced by many discussions > on the list. It also captures a divergence from that thinking > with Joel. Theres a slight different view by Weiming but because > i was lacking details i didnt capture it. > Weiming please send me an update. > > Both Joel and myself are looking forward to being beaten up (as opposed > to a thundering silence). > > cheers, > jamal > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 6 00:34:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15798 for ; Mon, 6 Sep 2004 00:34:15 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4BG1-0006eW-GU for forces-archive@IETF.ORG; Mon, 06 Sep 2004 00:37:34 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00E6F66B@cherry.ease.lsoft.com>; Mon, 6 Sep 2004 0:34:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34131348 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Sep 2004 00:34:13 -0400 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 6 Sep 2004 00:32:34 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 88704.804536222; Mon, 6 Sep 2004 12:42:21 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Mon, 6 Sep 2004 12:35:16 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <004a01c493c9$db0c1c10$845c21d2@Necom.hzic.edu.cn> Date: Mon, 6 Sep 2004 12:27:44 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated message layout doc To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Seems an attachment can not be posted, trying again. ----- Original Message ----- From: "Wang,Weiming" > Hi Jamal, > > To respond to your ask for more detailed description of my thoughts, I compose a > text in the attachement. Because it is just for discussion, I think you may not > care too much about the roughness of the text. Thank you. > > Hi Ellen, > > I'm ok with the time you scheduled. Thank you. > > Cheers, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > Attached a little document to reinject stalled discussion. > > > > Purpose is to help reach a quicker convergence > > on the message layout as well as influence how the > > model and protocol teams on moving forward. This should reduce > > current confusion on both sides on how message content is > > delivered and how such content is to be modeled so it can > > be appropriately delivered. > > It captures my thoughts that are influenced by many discussions > > on the list. It also captures a divergence from that thinking > > with Joel. Theres a slight different view by Weiming but because > > i was lacking details i didnt capture it. > > Weiming please send me an update. > > > > Both Joel and myself are looking forward to being beaten up (as opposed > > to a thundering silence). > > > > cheers, > > jamal > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 6 00:49:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16200 for ; Mon, 6 Sep 2004 00:49:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4BUq-0006ou-Rr for forces-archive@IETF.ORG; Mon, 06 Sep 2004 00:52:53 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00E6F5E3@cherry.ease.lsoft.com>; Mon, 6 Sep 2004 0:49:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 34131774 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 6 Sep 2004 00:49:33 -0400 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 6 Sep 2004 00:47:57 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 88704.804536222; Mon, 6 Sep 2004 12:57:48 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Mon, 6 Sep 2004 12:50:42 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <007901c493cc$01e346e0$845c21d2@Necom.hzic.edu.cn> Date: Mon, 6 Sep 2004 12:43:07 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated message layout doc To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Seems still not work for the attachment. I just directly put the contents below. Sorry for it. Weiming **************************************************************** Followed are some of my thoughts on the message TLV format for discussion: 1. Message Format 1) Config Message 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Msg Header(MessageType='Config') ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OpTLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OpTLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OpTLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2) Query Message MsgHeader(Type='Query') LfbTLV DataTLV ... LfbTLV DataTLV ... There is no OpTLV for Qeury Message, because the message has actually limited its operation to query. 3) Query Response Message MsgHeader(Type='Query Response') LfbTLV DataTLV ... LfbTLV DataTLV ... There is also no need for OpTLV for this message. 3) Event Notification Message MsgHeader(Type='Event Notification') LfbTLV DataTLV ... LfbTLV DataTLV ... There is also no need for OpTLV here. 2. Definition of TLVs 1). LfbTLV The LfbTLV presents the LFB(s) that are addressed by the message. The LfbTLV format is uniform and can be applied to all types of messages that need LFB addressing. We can think of an LfbTLV format like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 'LFBTLV' | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Type ID #1 | LFB Instance ID #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Type ID #N | LFB Instance ID #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We can also define a more complex LFBTLV for more complex LFB addressing, e.g., we may allow addressing a range of LFB instances, like LFB A with the instance id ranging from #1 to #10. 2). OpTLV The OpTLV is to describe operation to the LfbTLV addressed LFB(s) Note that although the OpTLV is globally defined, it may only be applied to configure message. For query, query response, and event notification messages, the operation has actually been implicitly assigned, therefore there no needs for OpTLV for them. I think of the OpTLV format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 'OpTLV' | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation | FLAGs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Operation field indicate the operation mode. For configration message, following operations are defined: 'Add' to add an attribute value to the addressed LFB(s) 'Delete' to delete an attribute value 'Modify' to modify an attribute value 'Flags' indicates operational features like inner-message 'batch','atomicity', etc (inter-message 'batch' and 'atomicity' are defined by flags in the protocol message headers). Note that for 'Modify' operation, the followed Odd 'DataTLV' assign the Data Name (ID) to be modified, while the followed Even 'DataTLV' assign the Data value to be modified (see section 3 example #3 below). 3). DataTLV DataTLV is to describe the data reqired by operation. The TLV globally has format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 'DataTLV' | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Data Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'Data ID' includes following IDs: LFB attribute type ID LFB capability type ID LFB event type ID For Config Message, the Data ID is for LFB attribute type ID. For Query and Response Message, the Data ID is for LFB attribute type and capability type IDs. For Event Notification Message, the Data ID is for LFB event type ID. (need to discuss if the Data ID should be global or only LFB specific.) The 'Data Value' describes the actual data value for the Data. In some cases it is optional, i.e., there is only Data ID there. For example, in Query Message, there may only be 'Data ID' while no 'Data Value'. In this case, it means to query all data with the 'Data ID'. E.g., if the 'Data ID' is 'RoutingTable' for an Forwarder LFB, then to use only the RoutingTable to query is actually to query all routing items in the table. If we need to query some specific items in the routing table, we then use Data Value to specify it. (I'm trying to describe how we can use the 'Data Value' to query items in the routing table based on the table 'Index' as Joel and Jamal proposed, later in Section 3 examples.) I think above are that which may appear in the the protocol specification, while the detailed 'Data value' definition will not appear in the protocol description. I think a specific "FE Data Model" is responsible to define the above 'Data Value' format for all FE LFBs in details. Following is some of my thoughts on the 'Data Value' format in the 'FE Data Model', which I think does not belong to the protocol specification. ========Below only for "FE data model"=========== In the "FE Data Model", the 'Data Value' may be composed of several field as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Field #1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ...... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Field #N ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Taking an routing table as an example, a routing table may have fields like 'Index', 'SrcIP', 'Mask', 'OutPort', etc. A more complex field can also be defined. E.g., we can define an 'IndexRange' or 'IndexEnum' to address a range of intexed items or enumerated items. I also wonder if we need to define some field to describe logical relationship between the fields, such as logica AND, OR, etc for fields. A 'Field' is described by a TLV as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = FieldID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Field Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The FieldID does not need to be global, it may only be LFB-specific. "FE Data Model" is responsible to accurately define the Field Value format and the meanings for all Data IDs of all LFBs. ========above only for "FE data model"=========== 3. Some examples Coming back to the protocol message, we take a few examples to show how a table operation can be implemented based on above model. Note that, the 'Index' can not been seen in the protocol specification it is only a field in the "FE Data Model". It also means protocol users can also choose not to use such Index for table operations, but if they choose to use it, we can also support it. 1). To add a routing rule to a routing table in a Forwarder LFB (Type=0x01, InstanceID=0x45), the routing rule has value as: Index=7, SrcIP=192.168.0.5, Mask=255.255.0.0, OutPort=3 Below is the message format for this purpose: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Msg Header(MessageType='Config') ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OpTLV('Add') ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV ( Data ID ='RoutingTable', ~ ~ Data Value= Index:7, SrcIP:192.168.0.5, ~ ~ Mask:255.255.0.0, OutPort:3) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: the items in Data Value are all represented by field TLVs defined above. 2). To delete Index=7 routing rule from above routing table +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Msg Header(MessageType='Config') ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OpTLV('Del') ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV ( Data ID ='RoutingTable', ~ ~ Data Value= Index:7 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3). To modify Index #7 routing rule in above routing table to Index=8, OutPort=5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Msg Header(MessageType='Config') ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ OpTLV('Modify') ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV ( Data ID ='RoutingTable', ~ ~ Data Value= Index:7 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV ( Data ID ='RoutingTable', ~ ~ Data Value= Index:8, OutPort:5) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4). To query a whole routing table in a Forwarder LFB (Type=0x01, InstanceID=0x45) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Msg Header(MessageType='Query') ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV ( Data ID ='RoutingTable', ~ ~ Data Value= Null ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5). Query Response to above Query message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Msg Header(MessageType='QueryResponse') ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV (Data ID ='RoutingTable', ~ ~ Data Value= Index:1,... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV (Data ID ='RoutingTable', ~ ~ Data Value= Index:2,... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV (Data ID ='RoutingTable', ~ ~ Data Value= ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ...... ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6). To query a routing rule with index=7 in a routing table in a Forwarder LFB (Type=0x01, InstanceID=0x45) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Msg Header(MessageType='Query') ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DataTLV (Data ID ='RoutingTable', ~ ~ Data Value= Index:7 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ********************* The End *************** From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 13 12:09:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13033 for ; Mon, 13 Sep 2004 12:09:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6tSs-0003Yp-Uj for forces-archive@IETF.ORG; Mon, 13 Sep 2004 12:14:03 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00E7C56B@cherry.ease.lsoft.com>; Mon, 13 Sep 2004 12:09:08 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 35277492 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Sep 2004 12:09:05 -0400 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Sep 2004 11:52:54 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004091308541539:38367 ; Mon, 13 Sep 2004 08:54:15 -0700 References: <007901c493cc$01e346e0$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/13/2004 08:54:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 09/13/2004 08:54:20 AM, Serialize complete at 09/13/2004 08:54:20 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1095090767.2156.12.camel@jzny.localdomain> Date: Mon, 13 Sep 2004 11:52:48 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: updated message layout doc Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <007901c493cc$01e346e0$845c21d2@Necom.hzic.edu.cn> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Content-Transfer-Encoding: 7bit Weiming, I was away the last week. I just went over your text briefly. While you are trying to reduce the amount of parsing involved (a noble effort), the result is you have lost clean structuring. As i am digging deeper i am more inclined to think that maybe Joels approach or a refined variant of it is the way to go. It is a little more processor intensive but will make management interface a lot more sane. Unfortunately mngmt interface is a very important tradeoff in the overall design (at some point manageability of Forces will kick in - currently people write MIBS - we should be able to use XML instead). My suggestion is to try and look at Joels delta and see if that can be cleaned up. Lets talk in tommorows design meeting (or if you can respond before the meeting then we can have a starting point). cheers, jamal On Mon, 2004-09-06 at 00:43, Wang,Weiming wrote: > Seems still not work for the attachment. I just directly put the contents below. > > Sorry for it. > Weiming > > **************************************************************** > > Followed are some of my thoughts on the message TLV format for discussion: > > 1. Message Format > > 1) Config Message > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Msg Header(MessageType='Config') ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ OpTLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ OpTLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ OpTLV ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 2) Query Message > MsgHeader(Type='Query') > LfbTLV > DataTLV > ... > LfbTLV > DataTLV > ... > > There is no OpTLV for Qeury Message, because the message has actually > limited its operation to query. > > 3) Query Response Message > MsgHeader(Type='Query Response') > LfbTLV > DataTLV > ... > LfbTLV > DataTLV > ... > There is also no need for OpTLV for this message. > > 3) Event Notification Message > MsgHeader(Type='Event Notification') > LfbTLV > DataTLV > ... > LfbTLV > DataTLV > ... > There is also no need for OpTLV here. > > 2. Definition of TLVs > > 1). LfbTLV > > The LfbTLV presents the LFB(s) that are addressed by the message. The > LfbTLV format is uniform and can be applied to all types of messages > that need LFB addressing. We can think of an LfbTLV format like: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 'LFBTLV' | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Type ID #1 | LFB Instance ID #1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Type ID #N | LFB Instance ID #N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > We can also define a more complex LFBTLV for more complex LFB addressing, > e.g., we may allow addressing a range of LFB instances, like LFB A with > the instance id ranging from #1 to #10. > > 2). OpTLV > > The OpTLV is to describe operation to the LfbTLV addressed LFB(s) > > Note that although the OpTLV is globally defined, it may only be applied > to configure message. For query, query response, and event notification > messages, the operation has actually been implicitly assigned, therefore > there no needs for OpTLV for them. > > I think of the OpTLV format as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 'OpTLV' | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operation | FLAGs | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Where, > Operation field indicate the operation mode. For configration message, > following operations are defined: > 'Add' to add an attribute value to the addressed LFB(s) > 'Delete' to delete an attribute value > 'Modify' to modify an attribute value > > 'Flags' indicates operational features like inner-message 'batch','atomicity', > etc (inter-message 'batch' and 'atomicity' are defined by flags in the > protocol message headers). > > Note that for 'Modify' operation, the followed Odd 'DataTLV' assign the > Data Name (ID) to be modified, while the followed Even 'DataTLV' assign > the Data value to be modified (see section 3 example #3 below). > > 3). DataTLV > > DataTLV is to describe the data reqired by operation. The TLV globally > has format as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = 'DataTLV' | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Data Value ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The 'Data ID' includes following IDs: > > LFB attribute type ID > LFB capability type ID > LFB event type ID > > For Config Message, the Data ID is for LFB attribute type ID. > For Query and Response Message, the Data ID is for LFB attribute type > and capability type IDs. > For Event Notification Message, the Data ID is for LFB event type ID. > > (need to discuss if the Data ID should be global or only LFB specific.) > > The 'Data Value' describes the actual data value for the Data. In some > cases it is optional, i.e., there is only Data ID there. For example, > in Query Message, there may only be 'Data ID' while no 'Data Value'. > In this case, it means to query all data with the 'Data ID'. E.g., if > the 'Data ID' is 'RoutingTable' for an Forwarder LFB, then to use only > the RoutingTable to query is actually to query all routing items in > the table. If we need to query some specific items in the routing table, > we then use Data Value to specify it. (I'm trying to describe how we can > use the 'Data Value' to query items in the routing table based on the > table 'Index' as Joel and Jamal proposed, later in Section 3 examples.) > > I think above are that which may appear in the the protocol specification, > while the detailed 'Data value' definition will not appear in the protocol > description. I think a specific "FE Data Model" is responsible to define > the above 'Data Value' format for all FE LFBs in details. > > Following is some of my thoughts on the 'Data Value' format in the > 'FE Data Model', which I think does not belong to the protocol specification. > > ========Below only for "FE data model"=========== > In the "FE Data Model", the 'Data Value' may be composed of several field as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Field #1 ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ...... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Field #N ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Taking an routing table as an example, a routing table may have fields > like 'Index', 'SrcIP', 'Mask', 'OutPort', etc. A more complex field can > also be defined. E.g., we can define an 'IndexRange' or 'IndexEnum' to > address a range of intexed items or enumerated items. I also wonder if > we need to define some field to describe logical relationship between > the fields, such as logica AND, OR, etc for fields. > > A 'Field' is described by a TLV as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = FieldID | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Field Value ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The FieldID does not need to be global, it may only be LFB-specific. > > "FE Data Model" is responsible to accurately define the Field Value > format and the meanings for all Data IDs of all LFBs. > > ========above only for "FE data model"=========== > > 3. Some examples > > Coming back to the protocol message, we take a few examples to show > how a table operation can be implemented based on above model. Note that, > the 'Index' can not been seen in the protocol specification it is only > a field in the "FE Data Model". It also means protocol users can also > choose not to use such Index for table operations, but if they choose > to use it, we can also support it. > > 1). To add a routing rule to a routing table in a Forwarder LFB > (Type=0x01, InstanceID=0x45), the routing rule has value as: Index=7, > SrcIP=192.168.0.5, Mask=255.255.0.0, OutPort=3 > > Below is the message format for this purpose: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Msg Header(MessageType='Config') ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ OpTLV('Add') ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV ( Data ID ='RoutingTable', ~ > ~ Data Value= Index:7, SrcIP:192.168.0.5, ~ > ~ Mask:255.255.0.0, OutPort:3) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note: the items in Data Value are all represented by field TLVs defined above. > > 2). To delete Index=7 routing rule from above routing table > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Msg Header(MessageType='Config') ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ OpTLV('Del') ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV ( Data ID ='RoutingTable', ~ > ~ Data Value= Index:7 ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 3). To modify Index #7 routing rule in above routing table to Index=8, OutPort=5 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Msg Header(MessageType='Config') ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ OpTLV('Modify') ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV ( Data ID ='RoutingTable', ~ > ~ Data Value= Index:7 ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV ( Data ID ='RoutingTable', ~ > ~ Data Value= Index:8, OutPort:5) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 4). To query a whole routing table in a Forwarder LFB (Type=0x01, > InstanceID=0x45) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Msg Header(MessageType='Query') ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV ( Data ID ='RoutingTable', ~ > ~ Data Value= Null ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 5). Query Response to above Query message > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Msg Header(MessageType='QueryResponse') ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV (Data ID ='RoutingTable', ~ > ~ Data Value= Index:1,... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV (Data ID ='RoutingTable', ~ > ~ Data Value= Index:2,... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV (Data ID ='RoutingTable', ~ > ~ Data Value= ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ...... ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 6). To query a routing rule with index=7 in a routing table in a > Forwarder LFB (Type=0x01, InstanceID=0x45) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Msg Header(MessageType='Query') ~ > ~ ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ LfbTLV (LFBtype=0x01, InstanceID=0x45) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ DataTLV (Data ID ='RoutingTable', ~ > ~ Data Value= Index:7 ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ********************* The End *************** From owner-forces@PEACH.EASE.LSOFT.COM Tue Sep 14 10:03:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11165 for ; Tue, 14 Sep 2004 10:03:07 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Dyd-0006xX-Td for forces-archive@IETF.ORG; Tue, 14 Sep 2004 10:08:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00E7E206@cherry.ease.lsoft.com>; Tue, 14 Sep 2004 10:03:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 35422690 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Sep 2004 10:02:58 -0400 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Sep 2004 10:00:36 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 88704.804536222; Tue, 14 Sep 2004 21:55:47 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 14 Sep 2004 21:47:03 +0800 References: <007901c493cc$01e346e0$845c21d2@Necom.hzic.edu.cn> <1095090767.2156.12.camel@jzny.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <08f501c49a60$36fa2e80$845c21d2@Necom.hzic.edu.cn> Date: Tue, 14 Sep 2004 21:39:10 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: updated message layout doc Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Jamal, Thank you for the response. Some replies inline. ----- Original Message ----- From: "Jamal Hadi Salim" > Weiming, > I was away the last week. I just went over your text briefly. > > While you are trying to reduce the amount of parsing involved > (a noble effort), the result is you have lost clean structuring. [Weiming]As I mentioned before, the effort is not just for easy parsing, but also for more clean structure and more flexibility (by use of universal LfbTLV, OpTLV and even DataTLV). I'm not very sure of clean structuring you mean here. Do you mean the individual TLVs are too complicated, or the message format is too complex? I'm trying to understand it. would be helpful if you could give a litlle more detailed thoughts here, thank you. > As i am digging deeper i am more inclined to think that maybe Joels > approach or a refined variant of it is the way to go. It is a little > more processor intensive but will make management interface a lot more > sane. Unfortunately mngmt interface is a very important tradeoff in the > overall design (at some point manageability of Forces will kick in - > currently people write MIBS - we should be able to use XML instead). > My suggestion is to try and look at Joels delta and see if that can be > cleaned up. [Weiming]I checked your summary on Joel's idea. I suppose what you summarized there is mainly about the way for table indexing. We the teams truly have quite different thoughts on if the index should be put in protocol layer or not, therefore I suppose this can be one separate from TLV topic for the call meeting to discuss, as Ellen suggested. > > Lets talk in tommorows design meeting (or if you can respond before the > meeting then we can have a starting point). [Weiming]As Ellen suggested, I also suppose the two topics: one for TLV format for messages, one for table indexing way as well as for LFB attribute representation for protocol messages. > > cheers, > jamal > Cheers, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Sep 15 00:36:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26327 for ; Wed, 15 Sep 2004 00:36:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7RcR-0001nC-W7 for forces-archive@IETF.ORG; Wed, 15 Sep 2004 00:42:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00E7F89B@cherry.ease.lsoft.com>; Wed, 15 Sep 2004 0:36:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 35524693 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Sep 2004 00:36:55 -0400 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Sep 2004 00:36:29 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i8F4dMdq012975; Wed, 15 Sep 2004 04:39:22 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i8F4d8V4023995; Wed, 15 Sep 2004 04:39:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004091421362813180 ; Tue, 14 Sep 2004 21:36:28 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Sep 2004 21:36:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] updated message layout doc Thread-Index: AcSNKxM62SXPIrJnQEaU/oJHnJm7cgNsXKsA X-OriginalArrivalTime: 15 Sep 2004 04:36:28.0753 (UTC) FILETIME=[91305410:01C49ADD] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E0257914A@orsmsx408> Date: Tue, 14 Sep 2004 21:36:16 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: updated message layout doc Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable I agree with Joel's approach regarding generic operations such as ADD, DEL which apply to all LFBs...its a clean approach, I have seen it used in a lot of other protocols and we already had this in our protocol draft as well. My 2 cents, Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Saturday, August 28, 2004 11:15 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] updated message layout doc Attached a little document to reinject stalled discussion. Purpose is to help reach a quicker convergence on the message layout as well as influence how the model and protocol teams on moving forward. This should reduce current confusion on both sides on how message content is delivered and how such content is to be modeled so it can be appropriately delivered. It captures my thoughts that are influenced by many discussions on the list. It also captures a divergence from that thinking with Joel. Theres a slight different view by Weiming but because i was lacking details i didnt capture it. Weiming please send me an update. Both Joel and myself are looking forward to being beaten up (as opposed to a thundering silence). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Sep 20 14:31:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28521 for ; Mon, 20 Sep 2004 14:31:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9T3F-00044Q-87 for forces-archive@IETF.ORG; Mon, 20 Sep 2004 14:38:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00E88A75@cherry.ease.lsoft.com>; Mon, 20 Sep 2004 14:31:45 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 36409340 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Sep 2004 14:31:43 -0400 Approved-By: slblake@PETRI-MEAT.COM Received: from 209.152.177.32 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Sep 2004 13:42:28 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1C9SBJ-0003xz-3R for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Sep 2004 13:42:29 -0400 References: <1092188616.2662.2.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-vIxJzB/UF5Fm90sk7yl0" Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - peach.ease.lsoft.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Message-ID: <1095702145.2340.15.camel@localhost.localdomain> Date: Mon, 20 Sep 2004 13:42:25 -0400 Reply-To: Steven Blake Sender: Forwarding and Control Element Separation From: Steven Blake Subject: Table model and config operators in ForCES rev. 2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1092188616.2662.2.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 --=-vIxJzB/UF5Fm90sk7yl0 Content-Type: text/plain Content-Transfer-Encoding: 7bit After some discussions between the model and protocol design teams, Zsolt Haraszti and I took the to-do to put together a proposal on how LFB tables could be modeled and managed in the protocol. The attached file is what we came up with. Please review and send comments to the list. Regards, // Steve --=-vIxJzB/UF5Fm90sk7yl0 Content-Disposition: attachment; filename=lfb_tables.txt Content-Type: text/plain; name=lfb_tables.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Tables in the ForCES Model 20-September-2004 ========================== 1 Table Definition and Indexing -------------------------------- An LFB table is a conceptual model of an ordered list of data elements (entries) of identical type, where the type can be any of the ForCES- supported data types, including atomic and compound types. Note that since compound types include arrays and structs, the entries in a table can be or can include other tables, respectively. The conceptual model of the table need not correspond closely with any implementation construct: any implementation may choose to use an array, a radix tree, a hash table, a doubly linked list, etc. Each element in the table may be uniquely identified by its associated table index, where the index is an unsigned integer that is assigned -- either by the FE or the CE, depending on operation -- when the entry is inserted into or moved within the table. The index value is not part of the table entry definition; indices are a property of every LFB table. The generic index type in ForCES is the 32-bit unsigned integer, but a table can narrow down the allowable indices by specifying an allowed index range, denoted here as min_idx and max_idx. If the index range is not specified, the default allowable range is between 0 and 2^32-1, both inclusive (min_idx=0, max_idx=2^32-1). Table entries need not be packed sequentially (this is implementation dependent), but will usually be packed densely. The order of entries in a table is not meant to represent any form of precedence of entries. For LFB tables that contain elements that are searched in the datapath in some precedence order, that precedence order must be maintained by the CE, by appropriate specification of a precedence field defined in each element. In the ForCES model the index has a permanent, immutable association to the element, i.e., it is created when the element is created and it does not change as other elements are manipulated in the table. As the index is immutable, tables do not compact, i.e., they can become sparsely populated (from the index point of view) as a result of subsequent insert and delete operations. In addition to the index range restrictions discussed above, the table may also specify the maximum number of elements, denoted here as max_size. Note that this value may be smaller than what is implied by the allowed range. The default value of max_size is max_idx-min_idx+1. If specified, max_size cannot be greater than the current max_idx-min_idx+1. The schema will allow the optional definition of default content for the table. If the default content is specified, the FE will intialize the table when the table is created (i.e., when the LFB instance is created or when a new table inside an LFB instance is created. The schema will support full and partial initialization (including sparse population). 2 Optional Associative Addressing ---------------------------------- In addition to addressing table entries by index, individual tables can define one or multiple optional search keys (in the LFB class model). A search key can be used by ForCES for associative addressing of table entries. A search key can be defined as the entire element comprising the table entry or -- if the element is of a struct type -- exactly one specific field of the struct (including a sub-structure). A particular element may define more than one field that may be used independently as an associative search key. For example, an IP prefix LFB will contain a table of prefix entry structs having the following fields: IP prefix (ip_prefix), next-hop identifier (nhid), and a set of counters (counters). The ip_prefix itself will be a struct of two 32-bit values, an IPv4 address and a prefix mask (or prefix length). A very useful search key for such an IP prefix table would be the ip_prefix. Defining the ip_prefix as a search key allows insert and delete operations using the ip_prefix as a table entry address. In addition, the nhid could also be defined as an alternative search key. A variety of associate search operators may be supported by ForCES, including: - Exact match - Prefix: - Shortest Matching Prefix - Longest Matching Prefix - All Matching Prefixes - Range: - Smallest Match in Range - Largest Match in Range - All Matches in Range The particular operators supported for a particular search key in a particular element will be specified in the appropriate LFB class definition, and may also be limited by a LFB instance (as an LFB capability). Multiple entries in a table may contain the same value for a search key under the applied search operation. An associative search may therefore return more than one matching entry. The most prevalent addressing technique is expected to be index based. In cases where a table's entries are accessed in the dataplane by associative search (e.g., IP prefix LFB), it may often be the case that it is most convenient for the CE to access the table entries via associate search as well. 3 Table Definition Information ------------------------------- The following information will be provided for all tables in the LFB/FE model: type of the table elements The following are additional optional information that _can_ be statically provided in the LFB specifications for each table: information type default value ----------- ---- ------------- hard_min_idx uint32 0 hard_max_idx uint32 2^32-1 hard_max_size uint32 2^32 search_key_enabled boolean false search_key* int32(struct field id) 0 (refers to the struct field if entries are structs) search_op* uint32 0 (a bit-mask of allowed operators) * More than one key may be defined for the same table. In addition, real-time FE-level and per-LFB-instance soft limits can be specified either in the FE LFB or in the actual LFB instance, respectively: information type default value ----------- ---- ------------- soft_min_idx uint32 hard_min_idx soft_max_idx uint32 hard_max_idx soft_max_size uint32 hard_max_size search_key_enabled* uint32 0 (a bitmap of allowed search keys specified in the LFB class definition) search_op* uint32 0 (a bitmap of allowed operators, specified) (Note that most of the above information are not reflected in the current working draft of the XML schema, but --once reasonable consensus is gained in the group-- it will be included in a revised version.) 4 Table Operations ------------------- Following is an itemized list of tentative *conceptual* table operations. How these will be mapped to what protocol operators, TLVs, etc., is not discussed here yet. First the WG needs to settle on what operations will be supported and then it can flesh out the actual operators and associated encoding. Insert operations for both FE-assigned indices and CE-assigned indices are supported. LFB instance creation is not discussed here. Table creation (in cases where the table is embedded in another table) is not discussed here. We assume that when the table is created, all the above listed associated information is initialized. In addition, if the default content is specified for the table, the initial table entries are created. Manipulating the sub-content of a given existing table entry (e.g., setting a field of a struct table entry) is not regarded as a table-specific operation, and hence we do not discuss them here in detail. Note that technically INS and DEL are the only two basic operators that are absolutely needed, all other operators are convenience operators, i.e., - they either allow the CE to be more state-less, or - improve performance by minimizing protocol load. Note that not reporting an error on an operation is not the same as ignoring an error report by the CE (consider the effect on batched requests and atomic operations). All operations require LFB ID (type+instance), and path information that identifies the table. This path information may be as simple as an attribute ID (if the table is a top-level attribue of the LFB), or it can be a sequence of IDs (path) if the table is buried under some other attribute. All range and max_size checking are applied to all insert operations. Notation: table refers to the table addressed by above path idx is the index provided to the operator (where applicable) idx' is an index generated by the operator (FE) Path that unambigously identifies a table data to initialize or over-write table entry, or obtained from table entry Data used in associative addressing in table. It can be a full table entry or a field in a struct-based table entry. 4.1 Atomic, Index-based Operations (INS, INS-IDX, DEL, SET, GET) 4.1.1 INS Parameters: , Returns: success indicator, idx' Insert with FE-originated index. Finds an unused index idx' (if available), creates new entry at idx', and intialize it with . If it cannot find an unused index without violating the index or size constraints, it fails. 4.1.2 INS_IDX Parameters: , idx, Returns: success indicator Insert at CE-provided index. Check if provided index is unused. If it is, initialize it with , otherwise indicate error. 4.1.3 INS_IDX! Parameters: , idx, Returns: success indicator This is an altered version of the previous INS_IDX in that if the index is already in use, it overwrites the entry with the provided (instead of reporting error). 4.1.4 DEL Parameters: , idx Returns: success indicator If table[idx] is used, delete table entry (making idx unused), otherwise report error. 4.1.5 DEL! Parameters: , idx Returns: success indicator Delete table[idx] if it exists, do nothing otherwise (never report error). 4.1.6 SET Parameters: , idx, Returns: success indicator If table[idx] exists, overwrite its content with provided , report error otherwise. 4.1.7 SET! Parameters: , idx, Returns: success indicator If table[idx] exists, overwrite its content with provided , create new entry with idx otherwise. 4.1.8 GET Parameters: , idx Returns: success indicator, If table[idx] exists, return with its content, indicate error otherwise. 4.2 Index-based Block/Bulk Operations These block/bulk operations are considered to save protocol overhead when simultaneously dealing with a large number of table entries. In the following will be able to capture any one of the following things: [a, b]: index range, matching all entries with idx: a<=idx<=b [a, N]: N (used) entries starting from idx=a and progressing to increasing indices, skipping unused entries [a, -N]: N (used) entries starting from idx=a and progressing to lower indices : All (used) entries in the table. N : N entries anywhere (used only in the INS_BLK operation) * refers to the data to initialize/set the specified table entries, or obtained from the specified table entries. 4.2.1 INS_BLK Parameters: , , Returns: success indicator, TBD 4.2.2 DEL_BLK Parameters: , Returns: success indicator Delete all entries specified by . TBD: how to handle errors? 4.2.3 SET_BLK Parameters: , , * Returns: success indicator Sets all elements specified by with the provided *. TBD: how to handle errors? 4.2.4 GET_BLK Parameters: , Returns: success indicator, * Obtains content of all entries specified by . 4.3 Associative (Key-Based) Operators In the following operators the following additional notations are used: : Refers to the identification of the key. Note that the same table may be addressable by more than one key. Indirectly, the key refers to the field in the table entry that will be compared to the . Search modes as described in section 2 (e.g., exact match, all that match prefix, longest prefix match, range, etc.) Data to be compared to the entry fields that are used as key. What is provided in depends on the and also on . 4.3.1 GET_IDX_BY_KEY Parameters: , , , Returns: success indicator, * Returns with the index of all entries identified by , and . 4.3.2 DEL_BY_KEY Parameters: , , , Returns: success indicator Deletes all entries identified by the , , and . 4.3.3 SET_BY_KEY Parameters: , , , , * Returns: success indicator Overwrites all entries identified by , , and . TBD: Some restrictions on mode will apply. 4.3.4 GET_BY_KEY Parameters: , , , Returns: success indicator, [*], * Returns with the content (and optionally the index) of all entries identified by the , , and . 5 Path Semantics ----------------- Paths to tables or other attribute elements are represented by a sequence of element identifiers, starting with the identifier of the associated LFB attribute. Path identifiers are unsigned 32-bit integers which are assigned to each element and sub-element of a LFB class's attributes in the class definition. As an example, imagine a class with an attribute a which is a table of structures, each of which contains another table as the third element. The path {a,b,c,d} would represent attribute a, table index b, table element c, table index d. 6 Metadata Value Binding to Table Entries ------------------------------------------ The index of a LFB table entry can be used for two purposes: one is to access the table entry via the ForCES protocol (INS, DEL, SET, GET commands), the other is to access the entry's contents in the dataplane. This latter usage is achieved by using some metadata value associated with the packet as the lookup index in the table. As an example, a CLASS_ID metadata item could be used to select a rate meter entry in a table in a Rate Meter LFB. The example above represents an implicit binding between a metadata item value and a table entry. Alternatively, the metadata binding could be defined explicitly, by specifying a field in the table element definition which is the metadata match value. The value of this field must be unique across all table entries to ensure an unambiguous mapping to incoming metadata values. Usage of either implicit or explicit metadata binding will be specified in the LFB class definition. The metadata value emitted by a LFB operation is configured by the CE. In the case of implicit metadata binding, the CE can allow the FE to determine the appropriate table entry index in the downstream LFB, and can configure that value into the upstream LFB, or the CE can determine the metadata value, and configure the upstream and downstream LFBs in any order. --=-vIxJzB/UF5Fm90sk7yl0--