Subject: [Forces-protocol] Share experiences

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 5 Mar 2004 22:16:57 +0800

Hi, 

We (GRMP team) agree that to share the implementation experiences would be helpful for the merge posibility accessment and also be of great benifits to form a robust protocol. Actully GRMP team has successfully established a test platform for GRMP messages feasibility and related performance test. The test platform and some of the test result have been shown in the ForCES meeting in Seoul. I also hope other candidate protocol teams can be generous enough to show some of the experiments results in a more detailed mode as well as giving some experiences, which is obviusly of great help for us to finally get a robust protocol. I'm sure some candidate teams have done this quite well.
 
Apart from the detailed results we have presented to IETF meeting, we also have some  experiences with GRMP during the implementation and protocol design as below:

1.  To devide the messges into "FE management  messages", "LFB management messages", "Datapath management messages" is very reasonable and has made the messaging system very clear and easy to use. This can be seen from the testbed CE management window.

2.  GRMP has basically used TLV to express entities. Moreover, a "list" data structure has been defined, which has been proven quite efficient to describe a bunch of the same entities, such as a list of attributes in the protocol PDU. 

3. It's really useful to define a broadcast mechanism in the protocol. We have already defined FE ID=0xffff as a broadcast FE ID in GRMP original version. In our experiments,  we have used them to setup the same LFB attributes in all FEs. Our experience is just that we enjoy using it, though we now only use point to point TCP to acomplish such a broadcast in the transport layer. From the experiments we also noticed that an LFB ID based broadcast ( as first proposed by Netlink2 ) will also be useful. We are sure this FE and LFB broadcast mechanism should be even more efficient when we use other transport means like direct Ethernet, backplane, and UDP. 

4. GRMP defines transaction identifiers in the way that trans. IDs originally produced by CE and by FE are different and are easy to be recognized by its first bit (0= CE generated, 1=FE generated). When we code the CE, we have found it has simplified the coding quite a lot, for we do not need to remember where the message is originated anymore. Moreover, such definition does not need any payment. 

5. We are quite sure that the protocol managed objects like FE attributes  should include those defined by the protocol itself (like DoS protection policy, CE failover policy,etc) as well as defined by FE models, and even should be open to be defined by vendors. This means it is impossible only to rely on FE model to define every thing owing to the FE model personality. The extreme example is FE model can not define attributes related to CE operations. As a result, the "object class" idea in GRMP should be useful. This can also be seen from the CE window in our testbed, where FE attributes are clearly devided into "GRMP class" "FE model class" and Vendor classs" . 

6. Dynamic capability change as an event report to CE has already been included GRMP earliest version. We believe it is of great use. Moreover, GRMP has defined a FE DoS attack alert event report, which is obviously useful.

7.  A  mechanism to syncronize the versions of the being used ForCES protocol and the FE model between CE and FE shoud be supplied by the protocol, because CE and FE are quite possibly been supplied by different vendors at different time. GRMP has supplied this.

8. As required by ForCES requiements and framework, the scheme to support network management tools like SNMP should be clearly presented in the protocol. GRMP has provided the scheme by defining a set of Managed Object (MO) management messages. Although we have not deployed the test for this, we believe it should be fully considered, for CEs and FEs actually are in one NE. 

Yours,
Weiming

P.S.: To prevent an unexpected alignment, I have put the above txt in a attached pdf file. 

----- Original Message ----- 
From: "Khosravi, Hormuzd M" <[email-masked]>
To: <[email-masked]>
Cc:  
Sent: Friday, February 27, 2004 11:40 AM
Subject: RE: ForCES Protocol Analysis Design Team Administrivia

Hi Jamal

I have some comments on your document based on our implementation
experiences.

I agree that TLV encoding is the most optimal encoding for the protocol.
We have used both OID/BER and XML encodings in our previous implementation and
they were very in efficient and reduced the throughput almost 10 fold in one case.
Also, having a Fixed length common header and variable length payload
consisting of TLVs is most efficient way to encapsulating/decapsulating messages.

We also have the CE allocating FEIDs or PIDs as you refer to them. This
works well and is a scalable approach to add new elements into the NE.

We have not played with dynamic capability addition, however this seems
to be one of the directions of the Model team and I am open to this. However,
we must definitely support the more common case of static capabilities.

We are also fine with application or ForCES protocol level multicasting
in addition to unicasting. We do this using FEIDs just as you use PIDs.

Support for layer 2 interconnects or IP independence as you call it is
also something which has to be addressed. I think all protocols support this,
however there have been different approaches taken to support this.

One of the other useful learning experiences that we have had is
separation of data and control on separate channels. There are many good reasons to
do this, we have already explained some in the past so I wont repeat.

Another thing which we think is very important from interoperability
point of view is to mandate a minimum no. of transport(s) and have others as
optional. Keep the protocol simple by taking advantage of underlying transports or
interconnects is another useful design principle.

Anyways I need to start packing for Korea, but I think this is a good start.
Lets keep the momentum going....to get to an interop in San Diego :)

Regards
Hormuzd