[Forces-protocol] Summary of path
"Weiming Wang" <wmwang@mail.hzic.edu.cn> Mon, 01 November 2004 17:19 UTC
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 MAA05558 for <forces-protocol-web-archive@ietf.org>; Mon, 1 Nov 2004 12:19:29 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COg4m-0004md-U2 for forces-protocol-web-archive@ietf.org; Mon, 01 Nov 2004 12:34:58 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COfUw-0003mS-9g; Mon, 01 Nov 2004 11:57:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COFwe-0006IW-48 for forces-protocol@megatron.ietf.org; Sun, 31 Oct 2004 08:40:33 -0500
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 IAA26860 for <forces-protocol@ietf.org>; Sun, 31 Oct 2004 08:40:28 -0500 (EST)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1COGAr-0004qQ-UF; Sun, 31 Oct 2004 08:55:42 -0500
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 58110.683627790; Sun, 31 Oct 2004 22:00:04 +0800 (CST)
Received: from wwm1 (unverified [219.82.183.181]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000096247@mail.gsu.cn>; Sun, 31 Oct 2004 21:34:23 +0800
Message-ID: <005f01c4bf4f$7c9f1ae0$020aa8c0@wwm1>
From: Weiming Wang <wmwang@mail.hzic.edu.cn>
To: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, avri@psg.com, forces-protocol@ietf.org, hadi@znyx.com, Wang Weiming <wmwang@mail.hzic.edu.cn>
References: <468F3FDA28AA87429AD807992E22D07E02579243@orsmsx408>
Date: Sun, 31 Oct 2004 21:42:21 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
X-Mailman-Approved-At: Mon, 01 Nov 2004 11:57:36 -0500
Cc: ram.gopal@nokia.com, "Steven Blake (petri-meat)" <slblake@petri-meat.com>, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Putzolu, David" <david.putzolu@intel.com>, "Yang, Lily L" <lily.l.yang@intel.com>, "Joel M. Halpern" <jhalpern@megisto.com>, Zsolt Haraszti <zsolt@modularnet.com>, Alan DeKok <alan.dekok@idt.com>, Ellen M Deleganes <ellen.m.deleganes@intel.com>, Robert Haas <rha@zurich.ibm.com>
Subject: [Forces-protocol] Summary of path
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 225414c974e0d6437992164e91287a51
Hi all, Below is some of the summary on the current debate on the 'path' , its usage with the individual advantages: 1. Seems agreed that a 'path' is a list of IDs and Indices (rathan than only one 32 bit index as some might have thought). Therefore, the conclusion is a path will be represented by a TLV like format. 2. Seems agreed that the 'path' is composed of two pieces as: path := AttributeID <Index>+ (Jamal suggest to use some flags and count to more precisely represent it. Because this belongs to the issue of refinement, just is skipped currently here) Where, AttributeID is an ID used to uniquely recognize different attributes in an LFB, and will be defined during LFB definitions in the XML document (therefore it's called a static ID by Jamal). Note that in a Query Message, path is also used to query entities other than attributes, including capabilities, and even events, the AttributeID here also has a extensive meaning for IDs that represent all entities operated, such as Capability ID, and Even Event ID( Weiming). An Index is used to index an entry of a table, a array, and a structured data type. Because the data types can be recursively compounded, there is a need for multiple level of indexing, which is represented as a list of indexes. 3. Two debated schemes to use the 'path' idea as below: D1: To use a uniform 'path' field in the Operation TLV in protocol to retrieve all data (use query as example), as: OpTLV(value) := path <data> Where, the 'path' is a TLV like format that includes AttributeID and Indexes, and the two pieces are all MUST, even for attributes that are atomic, or tables with few entires. D2: To separate the 'path' into two pieces explicitly in the protocol definition as: OpTLV(value) := AttributeID <Index(es)> <data> The difference of D2 from D1 is, the AttributeID is MUST, while the <Index(es)> is OPTIONAL in D2. This means protocol users are allowed not to use Index to retieve data from FE, but they definitely have to use AttributeID for it. Because the <Index(es)> part is optional, it can be conceptually included in the followed data field, which means the protocol will not explicitly define how the Indexes are formated, leavine the model to do this just like other attribute data. Advantages for D1: 1) Can supply a direct and straight forward means for data retieving without ambiguity. (Jamal, pls add more) Advantages for D2: 1) Be more flexible to all kinds of attributes, where Index is not necessarily needed, e.g., attributes of atomic data type, of table or array with few entries inside, especially for those attributes which do not originally have indexes, like capabilities, events. ( I reviewed all of our discussions on the 'path' again (especially Zsolt/Steve's Proposal for ForCES Data Encoding), just have a feeling that to use Index in some cases, we really have a tradeoff for the complex Index management. It seems Index will have to be assigned by CE, but capabilites and events that originally exist in FE makes the assignment a total extra work for CE to do). 2) Be clear in the architecture for LFB management. I think of the architecture as below: LFB class / \ LFB Instance ... / \ Attribue ID ... ---- Above is the protocol layer cared ----- / \ Path to entry (Optional) .. ---- Below is the model layer cared ----- / Entry I see the artchitecture for D1 as: LFB class / \ LFB Instance ... / \ Path to entry ... ---- Above is the protocol layer cared ----- / Entry ---- Below is the model layer cared ----- Best Regards, Weiming Here are today's meeting minutes that I took.... Meeting Notes 1. PATH - Weiming wants to split path in 2 pieces, path/attribute id and data (one is static, other depends on the data) Attribute ID may be Table ID. Weiming to post email with text describing the two schemes - include Model team in email (Advantages, disadvantages) 2. MultiLFB Addressing - 3 schemes, Robert to present at the IETF (TLV of multiple LFB instances, MIID, changing LFB class/instance TLV again) Jamal - tradeoff between compute and bandwidth 3. Packet Subscribe - 2 schemes - configure attribute of sink/source LFBs using Config, or special operation Packet Subscribe Resolution - use a Config msg to configure the attribute of some LFBS (Source/Sink like LFBs) Do we need to define the Source/Sink LFBs - we need to define the functionality, these LFBs would probably be defined by the model team Do we need anything special for the packet mirroring - this is part of the LFB attributes 4. Jamal/Robert/Hormuzd had more discussion later on about Jamal's comments on 6.1, 6.2. One resolution was to change the name of operation "SHOW" to "ADVERTISE". Jamal will send out an email to summarize the other topic regarding Events being addressed to LFBs rather than CE, FEs. Let me know if there are any comments, Thanks all for attending, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol
- [Forces-protocol] Meeting Notes for today Khosravi, Hormuzd M
- [Forces-protocol] Summary of path Weiming Wang