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" <nv33134@yahoo.com>
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

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<META NAME="Template" CONTENT="C:\Arquivos de programas\Microsoft Office\Office\html.dot">
</HEAD>
<BODY LINK="#0000ff" VLINK="#800080">

<P ALIGN="CENTER"><A HREF="mailto:atualidade2004@yahoo.com.br?subject=DesejoReceberInfoGratuitaProximosLancamentos"><FONT FACE="Bookman Old Style" SIZE=2>InfoGratuitaProximosLancamentos</FONT></A><FONT FACE="Bookman Old Style" SIZE=2> - </FONT><A HREF="mailto:atualidade2004@yahoo.com.br?subject=LinkToFreeAutomaticTranslator"><FONT FACE="Bookman Old Style" SIZE=2>LinkToFreeAutomaticTranslator</FONT></A><FONT FACE="Bookman Old Style" SIZE=2> (Castellano, English, Fran&ccedil;ais, Deutsche, Portugu&ecirc;s, etc.) <!-- Please, follow the links:
http://www.hotmail.com
http://www.spamcop.net
mailto:edu-discuss-admin@ietf.org?subject=Unsubscribe 
mailto:nv3331344@hotmail.com?subject=Subscribe 
mailto:abernardico@yahoo.com?subject=Remove
andrediniz@nonaarte.com.br
andredogon@simbolo.com.br
mailto:andredogon@simbolo.coml.sys.intranet?subject=Subscribir
braulinojr@bol.com.br
mailto:camera3@mail.telepac.pt?subject=IAgree
mailto:carlospi@adinet.com.uy?subject=Adquirir
DADEAN1@aol.com
df01a8c0@xdata1.com.uy
mailto:efigge@arnet.com.ar?subject=Unsubscribe
elrey@123.com
emancipacordoba@hotmail.com
mailto:FabianF@exo.com.ar?subject=MyOpinion
jaabril@mail.comcast.net -->
</FONT><B><FONT FACE="Bookman Old Style" SIZE=5><P>Brasil 2004: reportagem desenha mapa atualizado da "esquerda cat&oacute;lica" </P>
</B></FONT><FONT FACE="Bookman Old Style"><P>* A "esquerda cat&oacute;lica", sua influ&ecirc;ncia vis&iacute;vel na esfera sociopol&iacute;tica, e seu poder subterr&acirc;neo atrav&eacute;s de redes capilares e "vasos comunicantes" no Brasil de hoje, &eacute; apresentada num livro-reportagem in&eacute;dito de 56 p&aacute;ginas, de f&aacute;cil leitura e ampla documenta&ccedil;&atilde;o.</P>
<P>* "Pastoral da Terra e MST incendeiam o Pa&iacute;s" &eacute; ao mesmo tempo um mapa atualizado e um instrumento informativo indispens&aacute;vel para quem deseja conhecer os poss&iacute;veis rumos sociopol&iacute;ticos do Brasil de amanh&atilde;. </P>
<P>* O autor, o advogado e pesquisador Gregorio Vivanco Lopes, com mais de 30 anos de especializa&ccedil;&atilde;o no tema das comunidades eclesiais de base e da teologia da liberta&ccedil;&atilde;o, mostra a real dimens&atilde;o da Pastoral da Terra e do MST, duas pontas de um mesmo e gigantesco iceberg que a m&iacute;dia nem sempre revela e que a opini&atilde;o p&uacute;blica ignora.</P>
<P>* A for&ccedil;a e o tal&atilde;o de Aquiles da "esquerda cat&oacute;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.</P>
<P>* O autor do livreto "Pastoral da Terra e MST incendeiam o Pa&iacute;s" exerce o leg&iacute;timo direito de informar, e favorece tamb&eacute;m o direito de cada brasileiro de ser informado, condi&ccedil;&otilde;es ambas indispens&aacute;veis para uma aut&ecirc;ntica democracia.</P>
<P>* Solicite gratuitamente, por e-mail, o &Iacute;ndice e a Introdu&ccedil;&atilde;o contendo um resumo da reportagem e a capa da edi&ccedil;&atilde;o impressa:</P>
</FONT><P><A HREF="mailto:atualidade2004@yahoo.com.br?subject=IntroCapaGratuitas"><FONT FACE="Bookman Old Style">IntroCapaGratuitas</FONT></A></P>
<FONT FACE="Bookman Old Style"><P>* Envie seu voto eletr&ocirc;nico e, se poss&iacute;vel, sua valiosa opini&atilde;o a respeito do tema abordado, e receber&aacute; informa&ccedil;&atilde;o gratuita sobre pr&oacute;ximos lan&ccedil;amentos:</P>
<P>- </FONT><A HREF="mailto:atualidade2004@yahoo.com.br?subject=Lopes:Concordo"><FONT FACE="Bookman Old Style">Lopes:Concordo</FONT></A></P>
<FONT FACE="Bookman Old Style"><P>- </FONT><A HREF="mailto:atualidade2004@yahoo.com.br?subject=Lopes:EmTermos"><FONT FACE="Bookman Old Style">Lopes:EmTermos</FONT></A></P>
<FONT FACE="Bookman Old Style"><P>- </FONT><A HREF="mailto:atualidade2004@yahoo.com.br?subject=Lopes:Discordo"><FONT FACE="Bookman Old Style">Lopes:Discordo</FONT></A></P>
<FONT FACE="Bookman Old Style"><P>* Para enviar mensagem ou tomar contato com o autor, clique em:</P>
</FONT><P><A HREF="mailto:atualidade2004@yahoo.com.br?subject=Lopes:MinhaMensagem"><FONT FACE="Bookman Old Style">Lopes:MinhaMensagem</FONT></A><FONT FACE="Bookman Old Style"> (ou ligue para 11-38223241 / 11-38281102</P>
<P>* Caso deseje adquirir a vers&atilde;o impressa (R$ 10,00 correio inclu&iacute;do), clique no link: </FONT><A HREF="mailto:atualidade2004@yahoo.com.br?subject=DesejoAdquirirLivro"><FONT FACE="Bookman Old Style">DesejoAdquirirLivro</FONT></A><FONT FACE="Bookman Old Style"> (receber&aacute; as instru&ccedil;&otilde;es do distribuidor, de exclusiva responsabilidade deste).</P>
<P>* Caso deseje receber, por e-mail, o e-Book com o texto completo da reportagem (R$ 1,99), clique no link: </P>
</FONT><P><A HREF="mailto:atualidade2004@yahoo.com.br?subject=DesejoAdquirirEBook"><FONT FACE="Bookman Old Style">DesejoAdquirirEBook</FONT></A><FONT FACE="Bookman Old Style"> </P>
<P>* Para ser retirado de nosso Address Book, por favor, clique em: </P>
</FONT><P><A HREF="mailto:atualidade2004@yahoo.com.br?subject=RetirarImediatamente"><FONT FACE="Bookman Old Style">RetirarImediatamente</FONT></A></P>
<FONT FACE="Bookman Old Style"><P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P></FONT></BODY>
</HTML>




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 <forces-archive@IETF.ORG>; 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 <B0000018036@mail.gsu.cn> for
          <FORCES@peach.ease.lsoft.com>; 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" <wmwang@MAIL.HZIC.EDU.CN>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Wang,Weiming" <wmwang@MAIL.HZIC.EDU.CN>
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" <hadi@ZNYX.COM>
>
> 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 <forces-archive@IETF.ORG>; 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 <B0000018050@mail.gsu.cn> for
          <FORCES@peach.ease.lsoft.com>; 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" <wmwang@MAIL.HZIC.EDU.CN>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Wang,Weiming" <wmwang@MAIL.HZIC.EDU.CN>
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" <wmwang@mail.hzic.edu.cn>
> 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" <hadi@ZNYX.COM>
> >
> > 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 <forces-archive@IETF.ORG>; 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 <B0000018076@mail.gsu.cn> for
          <FORCES@peach.ease.lsoft.com>; 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" <wmwang@MAIL.HZIC.EDU.CN>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Wang,Weiming" <wmwang@MAIL.HZIC.EDU.CN>
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 <forces-archive@IETF.ORG>; 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              <FORCES@PEACH.EASE.LSOFT.COM>
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: Znyx Networks
Subject: Re: updated message layout doc
Comments: To: "Wang,Weiming" <wmwang@MAIL.HZIC.EDU.CN>
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 <forces-archive@IETF.ORG>; 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 <B0000027530@mail.gsu.cn>; 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" <wmwang@MAIL.HZIC.EDU.CN>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Wang,Weiming" <wmwang@MAIL.HZIC.EDU.CN>
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" <hadi@ZNYX.COM>

> 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 <forces-archive@IETF.ORG>; 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" <hormuzd.m.khosravi@INTEL.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@INTEL.COM>
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 <forces-archive@IETF.ORG>; 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 <slblake@PETRI-MEAT.COM>
Sender: Forwarding and Control Element Separation              <FORCES@PEACH.EASE.LSOFT.COM>
From: Steven Blake <slblake@PETRI-MEAT.COM>
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>          Path that unambigously identifies a table
        <data>          data to initialize or over-write table entry,
                        or obtained from table entry
        <key-val>       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: <path>, <data>
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 <data>.
If it cannot find an unused index without violating the index or size
constraints, it fails.

4.1.2  INS_IDX

Parameters: <path>, idx, <data>
Returns:    success indicator
Insert at CE-provided index. Check if provided index is unused. If  it
is, initialize it with <data>, otherwise indicate error.

4.1.3  INS_IDX!

Parameters: <path>, idx, <data>
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
<data> (instead of reporting error).

4.1.4  DEL

Parameters: <path>, idx
Returns:    success indicator
If table[idx]  is  used,  delete  table  entry  (making  idx  unused),
otherwise report error.

4.1.5  DEL!

Parameters: <path>, idx
Returns:    success indicator
Delete table[idx] if it exists, do  nothing  otherwise  (never  report
error).

4.1.6  SET

Parameters: <path>, idx, <data>
Returns:    success indicator
If table[idx] exists, overwrite  its  content  with  provided  <data>,
report error otherwise.

4.1.7  SET!

Parameters: <path>, idx, <data>
Returns:    success indicator
If table[idx] exists, overwrite  its  content  with  provided  <data>,
create new entry with idx otherwise.

4.1.8  GET

Parameters: <path>, idx
Returns:    success indicator, <data>
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 <idx-data> 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> :   All (used) entries in the table.
N     :   N entries anywhere (used only in the INS_BLK operation)

<data>* refers to the data to initialize/set the specified table entries,
or obtained from the specified table entries.

4.2.1  INS_BLK

Parameters: <path>, <idx-data>, <data>
Returns:    success indicator, <idx-data>
TBD

4.2.2  DEL_BLK

Parameters: <path>, <idx-data>
Returns:    success indicator
Delete all entries specified by <idx-data>.  TBD: how to handle errors?

4.2.3  SET_BLK

Parameters: <path>, <idx-data>, <data>*
Returns:    success indicator
Sets all elements specified by <idx-data> with the provided <data>*.
TBD: how to handle errors?

4.2.4  GET_BLK

Parameters: <path>, <idx-data>
Returns:    success indicator, <data>*
Obtains content of all entries specified by <idx-data>.


4.3  Associative (Key-Based) Operators

In the following operators the following additional notations are used:
<key>:          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 <key-val>.
<mode>          Search modes as described in section 2 (e.g., exact match,
                all that match prefix, longest prefix match, range, etc.)
<key-val>       Data to be compared to the entry fields that are used as
                key. What is provided in <key-val> depends on the <key>
                and also on <mode>.

4.3.1  GET_IDX_BY_KEY

Parameters: <path>, <key>, <mode>, <key-data>
Returns:    success indicator, <idx>*
Returns with the index of all entries identified by <key>, <mode>  and
<key-data>.

4.3.2  DEL_BY_KEY

Parameters: <path>, <key>, <mode>, <key-data>
Returns:    success indicator
Deletes all entries identified by the <key>, <mode>, and <key-data>.

4.3.3  SET_BY_KEY

Parameters: <path>, <key>, <mode>, <key-data>, <data>*
Returns:    success indicator
Overwrites all entries identified by  <key>, <mode>,  and  <key-data>.
TBD: Some restrictions on mode will apply.

4.3.4  GET_BY_KEY

Parameters: <path>, <key>, <mode>, <key-data>
Returns:    success indicator, [<idx>*], <data>*
Returns with the content (and optionally the  index)  of  all  entries
identified by the <key>, <mode>, and <key-data>.


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