[Forces-protocol] RE: Summary of path

"Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com> Mon, 01 November 2004 19:23 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19858 for <forces-protocol-web-archive@ietf.org>; Mon, 1 Nov 2004 14:23:28 -0500 (EST)
Received: from megatron.ietf.org ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COi14-0000Rx-Dt for forces-protocol-web-archive@ietf.org; Mon, 01 Nov 2004 14:38:58 -0500
Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhZe-0003em-VS; Mon, 01 Nov 2004 14:10:38 -0500
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COhKB-0003aY-Jz for forces-protocol@megatron.ietf.org; Mon, 01 Nov 2004 13:54:39 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17545 for <forces-protocol@ietf.org>; Mon, 1 Nov 2004 13:54:36 -0500 (EST)
Received: from fmr05.intel.com ([] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhZ5-0008ER-AC for forces-protocol@ietf.org; Mon, 01 Nov 2004 14:10:06 -0500
Received: from petasus.jf.intel.com (petasus.jf.intel.com []) 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 iA1Ivq5t000411; Mon, 1 Nov 2004 18:57:52 GMT
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com []) 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 iA1Iv5bC004161; Mon, 1 Nov 2004 18:57:16 GMT
Received: from orsmsx332.amr.corp.intel.com ([]) by orsmsxvs040.jf.intel.com (SAVSMTP with SMTP id M2004110110532508260 ; Mon, 01 Nov 2004 10:53:25 -0800
Received: from orsmsx408.amr.corp.intel.com ([]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Nov 2004 10:53:25 -0800
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
Date: Mon, 1 Nov 2004 10:53:23 -0800
Message-ID: <468F3FDA28AA87429AD807992E22D07E031B9F43@orsmsx408>
Thread-Topic: Summary of path
Thread-Index: AcS/Tuy8WUv5wDrdR8Sg/c4VmVX1YAA9QgAQ
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
To: "Weiming Wang" <wmwang@mail.hzic.edu.cn>, <avri@psg.com>, <forces-protocol@ietf.org>, <hadi@znyx.com>
X-OriginalArrivalTime: 01 Nov 2004 18:53:25.0866 (UTC) FILETIME=[119764A0:01C4C044]
X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Content-Transfer-Encoding: quoted-printable
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>, "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>, Robert Haas <rha@zurich.ibm.com>
Subject: [Forces-protocol] RE: 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.0 (/)
X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c
Content-Transfer-Encoding: quoted-printable


Pls submit this as an issue to the ForCES mailing list. See Jamal's
emails for examples.


-----Original Message-----
From: Weiming Wang [mailto:wmwang@mail.hzic.edu.cn] 
Sent: Sunday, October 31, 2004 5:42 AM
To: Khosravi, Hormuzd M; avri@psg.com; forces-protocol@ietf.org;
hadi@znyx.com; Wang Weiming
Cc: Putzolu, David; Joel M. Halpern; forces-protocol@ietf.org; Steven
Blake (petri-meat); Alan DeKok; Deleganes, Ellen M; Yang, Lily L; Zsolt
Haraszti; Robert Haas; ram.gopal@nokia.com; donglg@mail.hzic.edu.cn
Subject: Summary of path

Hi all,

Below is some of the summary on the current debate on the 'path' , its
with the individual advantages:

1. Seems agreed that  a 'path' is a list of IDs and Indices (rathan than
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
Because this belongs to the issue of  refinement,  just is skipped
    AttributeID is an ID used to uniquely recognize different attributes
in an
LFB, and will be defined during LFB definitions in the XML document
it's called a static ID by Jamal). Note that in a Query Message, path is
used to query entities other than attributes,  including capabilities,
and even
events, the AttributeID here also has a extensive meaning for IDs that
all entities operated, such as Capability ID, and Even Event ID(
    An Index is used to index an entry of  a table, a array, and a
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

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
all data (use query as example), as:

                OpTLV(value) := path <data>

Where, the 'path' is a TLV like format that includes AttributeID and
and the two pieces are all MUST, even for attributes that are atomic, or
with few entires.

D2: To separate the 'path' into two pieces explicitly in the protocol

                OpTLV(value) := AttributeID <Index(es)> <data>

The difference of D2 from D1 is, the AttributeID is MUST, while the
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
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

Advantages for D1:

1) Can supply a direct and straight forward means for data retieving
 (Jamal, pls add more)

Advantages for D2:
1) Be more flexible to all kinds of attributes, where Index is not
needed, e.g., attributes of  atomic data type, of table or array with
entries inside, especially for those attributes which do not originally
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
as below:

                                            LFB class
                                           /      \
                                    LFB Instance  ...
                                    /    \
                   Attribue ID   ...            ---- Above is the
protocol layer
cared -----
                         /        \
Path to entry (Optional) ..             ---- Below is the model layer
cared -----

I see the artchitecture for D1 as:

                                        LFB class
                                       /      \
                                LFB Instance  ...
                                /        \
               Path to  entry   ...        ---- Above is the protocol
cared -----
                     Entry                     ---- Below is the model
cared -----

Best Regards,

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

Let me know if there are any comments,

Thanks all for attending,

Forces-protocol mailing list

Forces-protocol mailing list