2005 Message-Id: Date: Fri, 1 Jul 2005 10:40:42 +0800 From: "Wang,Weiming" Subject: Re: Redirect Message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCwgYW5kIEphbWFsLA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbT og IkpvZWwgTS4gSGFscGVybiIgIA0KPiBJIGFtIG5vdCBzdXJlIHlvdSBjb3BpZWQgSmFtYWwgb2 4g dGhlIG5vdGUuDQo+IA0KPiBJIGFtIG1pc3NpbmcgdGhlIHBvaW50LiAgRm9yIHRoZSBmaXhlZC Bj b250ZW50IChldmV5dGhpZ24gZXhjZXB0IHRoZSANCj4gbWV0YS1kYXRhKSB0aGVyZSBpcyBuby Bu ZWVkIHRvIGRlZmluZSBpdCB2aWEgYW4gZXZlbnQuDQo+IEFuZCBhcyBJIHVuZGVyc3RhbmQgdG hp bmdzLCB0aGVzZSBtZXNzYWdlcyBzaG91bGQgZ28gb3ZlciBhIGRpZmZlcmVudCANCj4gY2hhbm 5l bCB0aGFuIExGQiBldmVudHMuDQoNCkJ5IHNheWluZyB0byB0cmVhdCBpcyBhcyBhIHNwZWNpYW wg ZXZlbnQsICBJIGRvbid0IG1lYW4gd2Ugc2hvdWxkIHVzZSBhbiBldmVudCBtZXNzYWdlIGZvci Bp dHMgdHJhbnNtaXNzaW9uLCB0aGVyZWZvcmUgc2hvdWxkIG5vdCBnbyBvdmVyIGRpZmZlcmVudC Bj aGFubmVsLiBNYXliZSBJIHNob3VsZCB1c2UgYW5vdGhlciBuYW1lIGZvciB0aGlzOiBhbiBhdH Ry aWJ1dGUgZm9yIHRoZSByZWRpcmVjdCBMRkIgdGhhdCBpcyAncmVhZC1vbmx5JyAuIEkganVzdC Bu b3RpY2UgdGhhdCB3ZSBkbyBoYXZlIG5vdCB0byBjb25maWd1cmUgYW55dGhpbmcgZm9yICBhIH Jl ZGlyZWN0IExGQiBleGNlcHQgdG8gbGluayBpdHMgcG9ydHMgd2l0aCBvdGhlciBMRkJzLiAgDQ oN ClRoYW5rcywNCldlaW1pbmcNCj4gDQo+IFdlIGRvIG5lZWQgYSBkZWZpbml0aW9uIG9mIHRoZS BM RkIuICBJdCBuZWVkcyBwcm9wZXJ0aWVzIHRvIGRlY2lkZSB3aGljaCANCj4gcGFja2V0cyBzaG 91 bGQgYmUgc2VudCB1cCAoZm9yIG9uZSBkaXJlY3Rpb24pIGFuZCB3aGF0IHRvIGRvIHdpdGggcG Fj a2V0cyANCj4gZnJvbSB0aGUgQ0UgKGluIHRoZSBvdGhlciBkaXJlY3Rpb24pLg0KPiANCj4gWW 91 cnMsDQo+IEpvZWwNCj4gDQo+IEF0IDEyOjA5IFBNIDYvMzAvMjAwNSwgV2FuZyxXZWltaW5nIH dy b3RlOg0KPiA+SmFtYWwsDQo+ID4NCj4gPkhvdyBhYm91dCB0aGUgdGhvdWdodCBiZWxvdz8NCj 4g Pg0KPiA+VG8gdHJlYXQgcmVkaXJlY3QgZGF0YSBhcyBhIGtpbmQgb2YgdGhpbmdzIGxpa2Ugd2 hh dCBhbiBldmVudCBpcyBkZWZpbmVkIA0KPiA+aW4gdGhlIHJlZGlyZWN0IExGQiwgdGhvdWdoIH dl IG1heSBub3QgY2FsbCBpdCBhbiBldmVudC4gV2l0aCB0aGlzIA0KPiA+dGhvdWdodCwgbXkgb3 Bp bmlvbiBpcyB3ZSBuZWVkIHRvIGRlZmluZSB0aGUgc291cmNlIGFuZCBzaW5rIExGQiB0aGF0IG 9u bHkgDQo+ID5oYXZlIG9uZSBhdHRyaWJ1dGUgKGV2ZW50KSwgc2F5IHRoZSBldmVudCBhdHRyaW J1 dGUgIElEID0xLCB0aGVuIHRoZSBldmVudCANCj4gPmhhcyBhIGRhdGEgcGFydCwgdGhhdCBpcy Bk ZWZpbmVkIHdpdGggdGhyZWUgZmllbGRzOiB0aGUgcG9ydCBudW1iZXIgaXQgDQo+ID5jb21lcy wg dGhlIHBhY2tldCB0eXBlLCBhbmQgdGhlIGFjdHVhbCBwYWNrZXQgZGF0YS4NCj4gPg0KPiA+SW 4g dGhpcyB3YXksIHdlIGNhbiB0aGVuIGtlZXAgdGhlIHJlZGlyZWN0IG1lc3NhZ2UgaW4gdGhlIG Zv cm1hdCBhcyANCj4gPnVuaWZvcm0gUGF0aC1EYXRhLCBhbmQgdGhlIGRhdGEgcGFydCBpcyBpc2 9s YXRlZCBmcm9tICB0aGUgcHJvdG9jb2wuDQo+ID4NCj4gPlRoYW5rcywNCj4gPldlaW1pbmcNCj 4g Pg0KPiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+RnJvbTogIkpvZWwgTS4gSG Fs cGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NCj4gPlRvOiA8Rk9SQ0VTQFBFQUNILkVBU0 Uu TFNPRlQuQ09NPg0KPiA+U2VudDogVGh1cnNkYXksIEp1bmUgMzAsIDIwMDUgMTA6NTEgUE0NCj 4g PlN1YmplY3Q6IFJlZGlyZWN0IE1lc3NhZ2UNCj4gPg0KPiA+DQo+ID4gPiBCYXNlZCBvbiBkaX Nj dXNzaW9uLCBhbmQgYmFzZWQgb24gbXkgZWFybGllciBtZXNzYWdlIHRoYXQgc3BlY2lmaWMgDQ o+ ID4gcHJvdG9jb2wNCj4gPiA+IG1lc3NhZ2VzIG1heSBoYXZlIGRpZmZlcmVudCB0b3AgbGV2ZW wg VExWcywgaGVyZSBpcyBhIGRlc2NyaXB0aW9uIG9mIHRoZQ0KPiA+ID4gY29udGVudHMgb2YgYS By ZWRpcmVjdCBtZXNzYWdlLg0KPiA+ID4NCj4gPiA+IEEgcmVkaXJlY3QgbWVzc2FnZSB3aWxsIG Nv bnRhaW4gYSByZWRpcmVjdCBUTFYuDQo+ID4gPiBBIHJlZGlyZWN0IFRMViBjb25zaXN0cyBvZi B0 aHJlZSBmaXhlZCBmaWVsZHMsIGFuZCBtZXRhLWRhdGEgVExWLCBhbmQgdGhlDQo+ID4gPiBwYW Nr ZXQuDQo+ID4gPiBUaGUgZml4ZWQgZmllbGRzIGFyZQ0KPiA+ID4gbyB0aGUgTEZCIENsYXNzIE lE IG9mIHRoZSByZWRpcmVjdCBzb3VyY2Ugb3IgcmVkaXJlY3Qgc2luayBMRkIgb24gdGhlIEZFDQ o+ ID4gPiBhc3NvY2lhdGVkIHdpdGggdGhpcyBwYWNrZXQNCj4gPiA+IG8gdGhlIExGQiBJbnN0YW 5j ZSBJRCBvZiB0aGUgcmVkaXJlY3Qgc291cmNlIG9yIHJlZGlyZWN0IHNpbmsgTEZCIG9uIA0KPi A+ IHRoZSBGRQ0KPiA+ID4gYXNzb2NpYXRlZCB3aXRoIHRoaXMgcGFja2V0DQo+ID4gPiBvIGFuIG lu ZGV4IHdpdGhpbiB0aGF0IExGQiB0byBpZGVudGlmeSBjb25maWd1cmVkIHByb3BlcnRpZXMgb2 Yg dGhlIHBhY2tldC4NCj4gPiA+DQo+ID4gPiBUaGUgbWV0YS1kYXRhIFRMViBjb250YWlucyBkeW 5h bWljIGluZm9ybWF0aW9uIG5lZWRlZCBieSB0aGUgRkUgb3IgQ0UgdG8NCj4gPiA+IHByb2Nlc3 Mg dGhlIHBhY2tldC4gIFRoaXMgd2lsbCBuZWVkIHRvIGJlIHNwZWxsZWQgb3V0IGluIG1vcmUgZG V0 YWlsLiAgSXQNCj4gPiA+IG1heSBuZWVkIHRvIHVzZSBwYXRoIGVuY29kaW5nLg0KPiA+ID4NCj 4g PiA+IEZvbGxvd2luZyB0aGlzIHdpbGwgYmUgdGhlIHBhY2tldC4NCj4gPiA+DQo+ID4gPiBZb3 Vy cywNCj4gPiA+IEpvZWwNCj4gDQo= 2005 Message-Id: Date: Thu, 28 Jul 2005 17:32:32 +0200 From: Robert Haas Subject: Re: Result TLV Comments: To: "Khosravi, Hormuzd M" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hormuzd, Also, mention that the format is not necessarily one Path-data TLV and=20 one Result TLV: there could be multiple. Regards, -Robert Khosravi, Hormuzd M wrote: >Thanks for the clarification, Joel! That's completely fine with me. >So it looks like.... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D LFB select | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path-data TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path-data TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >This is more granular and makes sense to me (what I would have expected >to see in the response). Therefore I asked for the clarification below. > >Regards >Hormuzd > >-----Original Message----- >From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 >Sent: Wednesday, July 13, 2005 12:34 PM >To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM >Subject: RE: [FORCES] Result TLV > >I would expect there to be path-data at least some of the time. >Assuming abbreviated responses (which are probably the norm) then for=20 >success it might suffice to just have one Result TLV, with no path-data. >I=20 >had not thought about allowing that. >If there are errors, there must at least be the path-data (possibly >several=20 >nested path-data TLVs) that identify the target of the operation which=20 >failed, to provide context for the error code in the Result TLV. >(Remember=20 >that there can be multiple path-data in the request, so the CE needs to=20 >know which thing failed.. >If we are in the try-all-operations mode, then at least each operation=20 >which failed will need its path-data. > >And if we instead use verbose responses, then I expect the response to >have=20 >all the path-data from the request, with result TLVs for each one=20 >indicating success or failure. > >Basically, I am just putting the Result-TLV into the path-data where the > >data-raw would have gone. > >Yours, >Joel > >At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: > =20 > >>Again a reasonable and simple approach to provide the Results. >> >>To put some more context around it, is this how it would look like in a >>Config Response message? >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type =3D LFB select | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | LFB Class ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | LFB Instance ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Operations (SET-RESP) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Result TLV | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Operations (DEL-RESP) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Result TLV | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >>Pls do clarify, No path-data tlv in this format? >> >>Thanks >>Hormuzd >> >>-----Original Message----- >>From: Forwarding and Control Element Separation >>[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >>Sent: Thursday, June 30, 2005 12:04 PM >>To: FORCES@PEACH.EASE.LSOFT.COM >>Subject: [FORCES] Result TLV >> >>The following is what I suggest for handling results of operations. >> >>SET and GET Requests do not have result information (they are >> =20 >> >requests). > =20 > >>SET and GET Responses have result information. >>SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. >> >>For a GET responses, individual gets which succeed will have DATARAW >>TLVs >>added to the leaf paths to carry the requested data. For GET elements >>that >>fail, instead of the DATARAW TLV there will be a RESULT TLV. >> >>For a SET response, each DATARAW TLV in the original request will be >>replace with a RESULT TLV in the response. >>If the request was for Ack-fail, then only those items which failed >> =20 >> >will > =20 > >>appear in the response. If the request was for ack-all, then all >>elements >>of the request will appear in the response with RESULT TLVs. >> >>A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >>byte) >>value. >>The defined values are >> 0 =3D success >> 1 =3D no such object >> 2 =3D permission denied >> 3 =3D invalid value (the dataraw could not validly be stored in the >>field) >> 4 =3D invalid array creation (when the subscript in an array create >> =20 >> >is > =20 > >>not >>allowed) >> 255 =3D unspecified error (for when the FE can not decide what went >>wrong) >> >>We may need a few more values to cover other errors. >>Note that if a SET request with a structure in a DATARAW is issued, and >>some field in the structure is invalid, the FE will not attempt to >>indicate >>which field was invalid, but rather will indicate that the operation >>failed. >>Note further that if there are multiple errors in a single leaf >>path-data / >>DATARAW, the FE can select which error it chooses to return. So if a >>DATARAW for a SET of a structure attempts to write one field which is >>read >>only, and attempts to set another field to an invalid value, the FE can >>return whatever error it likes. >> >>Yours, >>Joel M. Halpern >> =20 >> > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Sat, 23 Jul 2005 22:26:56 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, absolutely. LFB design cannot be done in seclusion, the designer has to think about other LFBs in the system that will work in conjunction with each other to provide a certain functionality. As per the ForCES charter, for the first rev of the model, lfb library, we should target LFBs to provide IPv4 forwarding and QoS functionality. We had discussed this long time back at the NPF and even at an IETF meeting I remember and Steve/Zsolt had a list of about 20 LFBs that were needed for this (IPv4 forwarding, Diffserv, Packet redirection, Ports, etc). regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Just for completeness, I do have one other concern. If we make the=20 meta-data ID fixed, then the LFB designer has to figure out what id makes=20 sense for any meta-data he generates, and what ids are assigned for=20 meta-data he wants. This means that the process of defining an LFB is now=20 intertwined much more tightly with the definition of other existing or new=20 LFB definitions. Yours, Joel 2005 Message-Id: Date: Sat, 23 Jul 2005 22:05:28 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I suppose as long as we define a configurable meta-data transcoder, I can live with making the meta-data IDs fixed by the LFB definition. Just for completeness, I do have one other concern. If we make the meta-data ID fixed, then the LFB designer has to figure out what id makes sense for any meta-data he generates, and what ids are assigned for meta-data he wants. This means that the process of defining an LFB is now intertwined much more tightly with the definition of other existing or new LFB definitions. Yours, Joel At 05:33 PM 7/23/2005, Khosravi, Hormuzd M wrote: >My thinking would be the latter (below). We should strive to keep the >model, lfb library, etc relatively simple atleast for the first rev...we >can add more flexibility for the second rev as we learn more from >different usage scenarios and implementation experiences. > >regards >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Saturday, July 23, 2005 2:17 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue32] Packet Redirect > >It is certainly attractive to simply define for a given LFB what >meta-data >ID it uses / produces. >If we want to take that approach, then we are going to frequently need >to >make use of meta-data transcoders whose only function is to take >meta-data >of ID x and turn it into meta-data of ID y. >This comes up because one could easily have a classifier that uses >"port" >(say ID 12), but a tunnel processor that produces "tunnel-id" (say id >34). And the CE wants the classifier to use the tunnel ID as the port >for >its work. > >If we believe that the significant majority of the time we can get the >IDs >right, then the LFB definition can include the meta-data ID. I am >doubtful. > >Yours, >Joel > >At 04:39 PM 7/23/2005, Khosravi, Hormuzd M wrote: > >Joel, > > > >I did some thinking on this and I couldn't see how having configurable > >meta-data would make things simpler for the protocol or model. Having > >unique meta-data IDs per LFB is a much more simpler approach IMHO. I > >don't think this list will be very large and this way seems to be more > >manageable to me...its in line with our common philosophy of keeping > >things simple atleast for the 1st rev of the protocol/model. > > > >My 2 cents > >Hormuzd > > > >-----Original Message----- > >From: Forwarding and Control Element Separation > >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > >Sent: Sunday, July 17, 2005 2:25 PM > >To: FORCES@PEACH.EASE.LSOFT.COM > >Subject: Re: [FORCES] [issue32] Packet Redirect > > > >This was a topic of major discussion within the model team. > >The cases which drive it get complex. > > > >Firstly, there is the simple case of a meta-data classfiier. This > >accepts > >packets on its input, looks at their meta-data, and selects the output. > >Clearly, such an LFB must have a selectable meta-data usage, so that >you > > > >can use if after the port-id, or after the DSCP selection, or ... > > > >Then, we get into more complex situations. SUppse that we want to have > >the > >output port of an LFB selected by a piece of meta-data. We could try >to > > > >assign globally unique IDs, and define the meta-data ID that this LFB > >uses. > >At the same time we have the LPM lfb which produces an extress > >interface, > >possibly a port, and possibly some next hope identifying information. > >We > >could try to define which of those correspond with the output port > >Identifier. > >And we could ensure it was different from the input port identifier. > >But then someone defines a new LFB that sometimes wants to use next-hop > >ID > >and sometimes wants to use port-ID (maybe to cope differently with > >p-to-p > >interfaces). > >And gradually we add more LFBs, and they want different meta-data >values > >to > >match, etc. > >We would (and may eventually anyway) need to create a meta-data > >rewireter > >that by configuration copies values from certain meta-data items to > >certain > >other meta-data items. > >That will work. > > > >Or we take the approach that the identifier (not the semantics, just >the > > > >identifier) of the meta-data item used or produced by each LFB needs to > >be > >configured. > > > >This whole issue is finessed in the model. My own feeling is that >since > > > >some items will necessarily require configurable meta-data handling, it > >seems much simpler to always se configurable meta-data selection. > > > >Yours, > >Joel > > > >PS: I Steve, Zsolt, and Alan did more thinking on this than I, but >their > > > >thinking never got into the document. They probably have a better idea > >of > >what is really needed and why. > > > >At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: > > >Joel, > > > > > >I am not sure I understand why the Identifiers will be assigned by >the > > >CE? > > >Isnt this just another Type that will be defined in the Model...e.g. > > >Id=Port, metadata value=port_id > > > > > >Let me know what I am missing here, > > > > > >Thanks > > >Hormuzd > > > > > >-----Original Message----- > > > > > >This looks good to me. > > >My only quibble (minor difference) is with the description that the > > >identifier portion of the meta-data ILV is assigned by the model. We > > >have > > >not worked this out, but I think that the identifiers are probably > >going > > >to > > >end up assigned by the CE. > > >(The implication of this is that if one CE takes over for another, it > > >may > > >have to do some analysis to get the meanings for the meta-data > > >identifiers. But it should be simple to find the LFBs where the > > >meta-data > > >is created, and determine what ID is configured to be used for it. >And > > >this needs to be described somewhere in either the model or the > >protocol > > > > > >document. I think it will go in the meta-data portion of the model > > >draft.) > > > > > >Yours, > > >Joel 2005 Message-Id: Date: Sat, 23 Jul 2005 17:16:48 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed It is certainly attractive to simply define for a given LFB what meta-data ID it uses / produces. If we want to take that approach, then we are going to frequently need to make use of meta-data transcoders whose only function is to take meta-data of ID x and turn it into meta-data of ID y. This comes up because one could easily have a classifier that uses "port" (say ID 12), but a tunnel processor that produces "tunnel-id" (say id 34). And the CE wants the classifier to use the tunnel ID as the port for its work. If we believe that the significant majority of the time we can get the IDs right, then the LFB definition can include the meta-data ID. I am doubtful. Yours, Joel At 04:39 PM 7/23/2005, Khosravi, Hormuzd M wrote: >Joel, > >I did some thinking on this and I couldn't see how having configurable >meta-data would make things simpler for the protocol or model. Having >unique meta-data IDs per LFB is a much more simpler approach IMHO. I >don't think this list will be very large and this way seems to be more >manageable to me...its in line with our common philosophy of keeping >things simple atleast for the 1st rev of the protocol/model. > >My 2 cents >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Sunday, July 17, 2005 2:25 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue32] Packet Redirect > >This was a topic of major discussion within the model team. >The cases which drive it get complex. > >Firstly, there is the simple case of a meta-data classfiier. This >accepts >packets on its input, looks at their meta-data, and selects the output. >Clearly, such an LFB must have a selectable meta-data usage, so that you > >can use if after the port-id, or after the DSCP selection, or ... > >Then, we get into more complex situations. SUppse that we want to have >the >output port of an LFB selected by a piece of meta-data. We could try to > >assign globally unique IDs, and define the meta-data ID that this LFB >uses. >At the same time we have the LPM lfb which produces an extress >interface, >possibly a port, and possibly some next hope identifying information. >We >could try to define which of those correspond with the output port >Identifier. >And we could ensure it was different from the input port identifier. >But then someone defines a new LFB that sometimes wants to use next-hop >ID >and sometimes wants to use port-ID (maybe to cope differently with >p-to-p >interfaces). >And gradually we add more LFBs, and they want different meta-data values >to >match, etc. >We would (and may eventually anyway) need to create a meta-data >rewireter >that by configuration copies values from certain meta-data items to >certain >other meta-data items. >That will work. > >Or we take the approach that the identifier (not the semantics, just the > >identifier) of the meta-data item used or produced by each LFB needs to >be >configured. > >This whole issue is finessed in the model. My own feeling is that since > >some items will necessarily require configurable meta-data handling, it >seems much simpler to always se configurable meta-data selection. > >Yours, >Joel > >PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their > >thinking never got into the document. They probably have a better idea >of >what is really needed and why. > >At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: > >Joel, > > > >I am not sure I understand why the Identifiers will be assigned by the > >CE? > >Isnt this just another Type that will be defined in the Model...e.g. > >Id=Port, metadata value=port_id > > > >Let me know what I am missing here, > > > >Thanks > >Hormuzd > > > >-----Original Message----- > > > >This looks good to me. > >My only quibble (minor difference) is with the description that the > >identifier portion of the meta-data ILV is assigned by the model. We > >have > >not worked this out, but I think that the identifiers are probably >going > >to > >end up assigned by the CE. > >(The implication of this is that if one CE takes over for another, it > >may > >have to do some analysis to get the meanings for the meta-data > >identifiers. But it should be simple to find the LFBs where the > >meta-data > >is created, and determine what ID is configured to be used for it. And > >this needs to be described somewhere in either the model or the >protocol > > > >document. I think it will go in the meta-data portion of the model > >draft.) > > > >Yours, > >Joel 2005 Message-Id: Date: Sat, 23 Jul 2005 14:33:49 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My thinking would be the latter (below). We should strive to keep the model, lfb library, etc relatively simple atleast for the first rev...we can add more flexibility for the second rev as we learn more from different usage scenarios and implementation experiences. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Saturday, July 23, 2005 2:17 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue32] Packet Redirect It is certainly attractive to simply define for a given LFB what meta-data=20 ID it uses / produces. If we want to take that approach, then we are going to frequently need to=20 make use of meta-data transcoders whose only function is to take meta-data=20 of ID x and turn it into meta-data of ID y. This comes up because one could easily have a classifier that uses "port"=20 (say ID 12), but a tunnel processor that produces "tunnel-id" (say id=20 34). And the CE wants the classifier to use the tunnel ID as the port for=20 its work. If we believe that the significant majority of the time we can get the IDs=20 right, then the LFB definition can include the meta-data ID. I am doubtful. Yours, Joel At 04:39 PM 7/23/2005, Khosravi, Hormuzd M wrote: >Joel, > >I did some thinking on this and I couldn't see how having configurable >meta-data would make things simpler for the protocol or model. Having >unique meta-data IDs per LFB is a much more simpler approach IMHO. I >don't think this list will be very large and this way seems to be more >manageable to me...its in line with our common philosophy of keeping >things simple atleast for the 1st rev of the protocol/model. > >My 2 cents >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Sunday, July 17, 2005 2:25 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: Re: [FORCES] [issue32] Packet Redirect > >This was a topic of major discussion within the model team. >The cases which drive it get complex. > >Firstly, there is the simple case of a meta-data classfiier. This >accepts >packets on its input, looks at their meta-data, and selects the output. >Clearly, such an LFB must have a selectable meta-data usage, so that you > >can use if after the port-id, or after the DSCP selection, or ... > >Then, we get into more complex situations. SUppse that we want to have >the >output port of an LFB selected by a piece of meta-data. We could try to > >assign globally unique IDs, and define the meta-data ID that this LFB >uses. >At the same time we have the LPM lfb which produces an extress >interface, >possibly a port, and possibly some next hope identifying information. >We >could try to define which of those correspond with the output port >Identifier. >And we could ensure it was different from the input port identifier. >But then someone defines a new LFB that sometimes wants to use next-hop >ID >and sometimes wants to use port-ID (maybe to cope differently with >p-to-p >interfaces). >And gradually we add more LFBs, and they want different meta-data values >to >match, etc. >We would (and may eventually anyway) need to create a meta-data >rewireter >that by configuration copies values from certain meta-data items to >certain >other meta-data items. >That will work. > >Or we take the approach that the identifier (not the semantics, just the > >identifier) of the meta-data item used or produced by each LFB needs to >be >configured. > >This whole issue is finessed in the model. My own feeling is that since > >some items will necessarily require configurable meta-data handling, it >seems much simpler to always se configurable meta-data selection. > >Yours, >Joel > >PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their > >thinking never got into the document. They probably have a better idea >of >what is really needed and why. > >At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: > >Joel, > > > >I am not sure I understand why the Identifiers will be assigned by the > >CE? > >Isnt this just another Type that will be defined in the Model...e.g. > >Id=3DPort, metadata value=3Dport_id > > > >Let me know what I am missing here, > > > >Thanks > >Hormuzd > > > >-----Original Message----- > > > >This looks good to me. > >My only quibble (minor difference) is with the description that the > >identifier portion of the meta-data ILV is assigned by the model. We > >have > >not worked this out, but I think that the identifiers are probably >going > >to > >end up assigned by the CE. > >(The implication of this is that if one CE takes over for another, it > >may > >have to do some analysis to get the meanings for the meta-data > >identifiers. But it should be simple to find the LFBs where the > >meta-data > >is created, and determine what ID is configured to be used for it. And > >this needs to be described somewhere in either the model or the >protocol > > > >document. I think it will go in the meta-data portion of the model > >draft.) > > > >Yours, > >Joel 2005 Message-Id: Date: Sat, 23 Jul 2005 13:39:55 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel, I did some thinking on this and I couldn't see how having configurable meta-data would make things simpler for the protocol or model. Having unique meta-data IDs per LFB is a much more simpler approach IMHO. I don't think this list will be very large and this way seems to be more manageable to me...its in line with our common philosophy of keeping things simple atleast for the 1st rev of the protocol/model. My 2 cents Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, July 17, 2005 2:25 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue32] Packet Redirect This was a topic of major discussion within the model team. The cases which drive it get complex. Firstly, there is the simple case of a meta-data classfiier. This accepts=20 packets on its input, looks at their meta-data, and selects the output. Clearly, such an LFB must have a selectable meta-data usage, so that you can use if after the port-id, or after the DSCP selection, or ... Then, we get into more complex situations. SUppse that we want to have the=20 output port of an LFB selected by a piece of meta-data. We could try to assign globally unique IDs, and define the meta-data ID that this LFB uses. At the same time we have the LPM lfb which produces an extress interface,=20 possibly a port, and possibly some next hope identifying information. We=20 could try to define which of those correspond with the output port Identifier. And we could ensure it was different from the input port identifier. But then someone defines a new LFB that sometimes wants to use next-hop ID=20 and sometimes wants to use port-ID (maybe to cope differently with p-to-p=20 interfaces). And gradually we add more LFBs, and they want different meta-data values to=20 match, etc. We would (and may eventually anyway) need to create a meta-data rewireter=20 that by configuration copies values from certain meta-data items to certain=20 other meta-data items. That will work. Or we take the approach that the identifier (not the semantics, just the identifier) of the meta-data item used or produced by each LFB needs to be=20 configured. This whole issue is finessed in the model. My own feeling is that since some items will necessarily require configurable meta-data handling, it=20 seems much simpler to always se configurable meta-data selection. Yours, Joel PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their thinking never got into the document. They probably have a better idea of=20 what is really needed and why. At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: >Joel, > >I am not sure I understand why the Identifiers will be assigned by the >CE? >Isnt this just another Type that will be defined in the Model...e.g. >Id=3DPort, metadata value=3Dport_id > >Let me know what I am missing here, > >Thanks >Hormuzd > >-----Original Message----- > >This looks good to me. >My only quibble (minor difference) is with the description that the >identifier portion of the meta-data ILV is assigned by the model. We >have >not worked this out, but I think that the identifiers are probably going >to >end up assigned by the CE. >(The implication of this is that if one CE takes over for another, it >may >have to do some analysis to get the meanings for the meta-data >identifiers. But it should be simple to find the LFBs where the >meta-data >is created, and determine what ID is configured to be used for it. And >this needs to be described somewhere in either the model or the protocol > >document. I think it will go in the meta-data portion of the model >draft.) > >Yours, >Joel 2005 Message-Id: Date: Sat, 23 Jul 2005 13:18:11 -0700 From: "Khosravi, Hormuzd M" Subject: Re: text for issue 26 Comments: To: aaudu2000@aol.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58FC3.A79BE7D3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58FC3.A79BE7D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex =20 Good suggestion. I'll make the change to the draft. =20 Thanks Hormuzd =20 ________________________________ From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu Sent: Saturday, July 23, 2005 8:28 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] text for issue 26 =20 Hi Hormuzd, =20 Can you also tear down an association as a result of the heart-beat expiring?..bandwidth limitation?.. So may be we could use the following error codes: =20 0 - normal teardown by administrator 1 - error - loss of heart-beat 2 - error - out of bandwidth resource 3 - error - out of memory resource 4 - error - application crash .. 255 - error - other or unspecified =20 Error 2 may signal the system's reaction to DOS attack. I have also arranged them according to severity levels,..the crash being most severe. I am not sure if the=20 ordering matters much though. =20 Cheers, Alex. =20 =20 =20 -----Original Message----- From: Khosravi, Hormuzd M To: FORCES@PEACH.EASE.LSOFT.COM Sent: Sun, 17 Jul 2005 16:34:51 -0700 Subject: text for issue 26 Here is the text for 26... =20 =20 Teardown TLV =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D Teardown reason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Teardown reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - out of memory 2 - error - application crash 255 - error - other or unspecified =20 =20 Hormuzd =20 ------_=_NextPart_001_01C58FC3.A79BE7D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alex

 

Good suggestion. I’ll make = the change to the draft.

 

Thanks

Hormuzd

 

From: = Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Alex Audu
Sent: Saturday, July 23, = 2005 8:28 AM
To: = FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [FORCES] = text for issue 26

 

 Hi Hormuzd,

 

Can you also tear down an association as a result of the heart-beat expiring?..bandwidth = limitation?..

So may be we could use the following error = codes:

 

0 - normal teardown by = administrator

1 - error - loss of = heart-beat

2 - error - out of bandwidth = resource

3 - error - out of memory = resource

4 - error - application = crash

..

255 - error - other or = unspecified

 

Error 2 may signal the = system's reaction to DOS attack.  I have also arranged them

according to severity levels,..the crash = being most severe. I am not sure if the

ordering matters much = though.

 

Cheers,

Alex.

 

 

 
-----Original Message-----
From: Khosravi, Hormuzd M <hormuzd.m.khosravi@intel.com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Sun, 17 Jul 2005 16:34:51 -0700
Subject: text for issue 26

Here is the text for 26...

 

 

Teardown TLV

 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    |  Type =3D Teardown reason       |            =    Length          = |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    |            =           Teardown Reason           &= nbsp;           &n= bsp;  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

  Teardown reason (32 = bits):

       This = indicates the reason why the association is being

       = terminated. Several reason codes are defined as follows.

0 - normal teardown by = administrator

1 - error - out of memory

2 - error - application = crash

255 - error - other or = unspecified

 

 

Hormuzd

 

------_=_NextPart_001_01C58FC3.A79BE7D3-- 2005 Message-Id: Date: Sat, 23 Jul 2005 11:28:12 -0400 From: Alex Audu Subject: Re: text for issue 26 Comments: To: hormuzd.m.khosravi@intel.com Content-Type: multipart/alternative; boundary="--------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com" MIME-Version: 1.0 ----------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com Content-Type: text/plain; charset="us-ascii" Hi Hormuzd, Can you also tear down an association as a result of the heart-beat expiring?..bandwidth limitation?.. So may be we could use the following error codes: 0 - normal teardown by administrator 1 - error - loss of heart-beat 2 - error - out of bandwidth resource 3 - error - out of memory resource 4 - error - application crash .. 255 - error - other or unspecified Error 2 may signal the system's reaction to DOS attack. I have also arranged them according to severity levels,..the crash being most severe. I am not sure if the ordering matters much though. Cheers, Alex. -----Original Message----- From: Khosravi, Hormuzd M To: FORCES@PEACH.EASE.LSOFT.COM Sent: Sun, 17 Jul 2005 16:34:51 -0700 Subject: text for issue 26 Here is the text for 26... Teardown TLV +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = Teardown reason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Teardown reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - out of memory 2 - error - application crash 255 - error - other or unspecified Hormuzd ----------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com Content-Type: text/html; charset="us-ascii"
 Hi Hormuzd,
 
Can you also tear down an association as a result of the heart-beat expiring?..bandwidth limitation?..
So may be we could use the following error codes:
 
0 - normal teardown by administrator
1 - error - loss of heart-beat
2 - error - out of bandwidth resource
3 - error - out of memory resource
4 - error - application crash
..
255 - error - other or unspecified
 
Error 2 may signal the system's reaction to DOS attack.  I have also arranged them
according to severity levels,..the crash being most severe. I am not sure if the
ordering matters much though.
 
Cheers,
Alex.
 
 
 
-----Original Message-----
From: Khosravi, Hormuzd M <hormuzd.m.khosravi@intel.com>
To: FORCES@PEACH.EASE.LSOFT.COM
Sent: Sun, 17 Jul 2005 16:34:51 -0700
Subject: text for issue 26

Here is the text for 26...
 
 
Teardown TLV
 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type = Teardown reason       |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Teardown Reason                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
  Teardown reason (32 bits):
       This indicates the reason why the association is being
       terminated. Several reason codes are defined as follows.
0 - normal teardown by administrator
1 - error - out of memory
2 - error - application crash
255 - error - other or unspecified
 
 
Hormuzd
 
----------MailBlocks_8C75DB245C5CDAC_8BC_A22F_mblk-d40.sysops.aol.com-- 2005 Message-Id: Date: Fri, 22 Jul 2005 11:27:01 +0200 From: Patrick Droz Organization: IBM Research Division Subject: Agenda for ForCES WG, IETF 63 Comments: To: agenda@ietf.org Comments: cc: Alex Zinin , Bill Fenner MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020703050004000001010504" This is a cryptographically signed message in MIME format. --------------ms020703050004000001010504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Forwarding and Control Element Separation (ForCES) Agenda, IETF 63, Paris Monday, August 1st, 2005, 10:30-12:30 ================================= CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner AGENDA: 10 min - WG status & Agenda Bash - chairs 20 min Architecture of the Flexinet ForCES-based Control Point (EU project) Robert Haas 25 min - ForCES Protocol Draft Updates Robert Haas and Jamal Hadi Salim draft-forces-protocol-04.txt 25 min - ForCES Forwarding Element Model Joel Halpern draft-ietf-forces-model-04.txt 15 min - Examples of Logical Function Blocks (LFBs) Jamal Hadi Salim 15 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-khosravi-forces-tcptml-00.txt 10 min - TIPC based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-maloy-tipc-tml-00.txt (Updated July 22, 2005) --------------ms020703050004000001010504 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA3MjIw OTI3MDFaMCMGCSqGSIb3DQEJBDEWBBRCdduULjFZGzxPCHpr20xbTvVIWzBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgCLxzxKqDmczM9VYzfNc88MMKU6ggcojmqwQ xNJoT0wGodbEu0uCC6BYRWxWjzt2U+4bxxTowd4exYa/KrdhZ3b8NrLWmfZl7Xd8laQB39Cy OK5LLGi2dGEUrwXEFP+gjHXgK2FO//p63iu5PpCyAvgClTPG5GJzZkW2lFkTcp/vAAAAAAAA --------------ms020703050004000001010504-- 2005 Message-Id: Date: Thu, 21 Jul 2005 12:01:46 +0200 From: Patrick Droz Organization: IBM Research Division Subject: tentative agenda for ForCES WG, IETF 63 Comments: cc: David Putzolu , rha MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050403000404050201010203" This is a cryptographically signed message in MIME format. --------------ms050403000404050201010203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit attached is a tentative agenda for the forthcoming meeting in Paris. I personally will not make it to this meeting and Robert Haas will by chairing for me. Please let me know if you need changes to the agenda. Regards, Patrick Forwarding and Control Element Separation (ForCES) Agenda, IETF 63, Paris Monday, August 1st, 2005, 10:30-12:30 ================================= CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner AGENDA: 10 min - WG status & Agenda Bash - chairs 20 min Architecture of the Flexinet ForCES-based Control Point (EU project) Robert Haas 25 min - ForCES Protocol Draft Updates Robert Haas and Jamal Salim draft-forces-protocol-04.txt 25 min - ForCES Forwarding Element Model Joel Halpern draft-ietf-forces-model-04.txt 15 min - Examples of Logical Function Blocks (LFBs) Jamal Salim 15 min - TCP/IP based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-khosravi-forces-tcptml-00.txt 10 min - TIPC based TML (Transport Mapping Layer) for ForCES protocol Jon Maloy draft-maloy-tipc-tml-00.txt (Updated July 21, 2005) -- Dr. Robert R. Haas IBM Zurich Research Laboratory Säumerstrasse 4 CH-8803 Rüschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha --------------ms050403000404050201010203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA3MjEx MDAxNDZaMCMGCSqGSIb3DQEJBDEWBBRJi7NeeNbQ7d6GB+7I12PlwwGTajBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgBXUSx/t7z0RqQt8rfkX+VO2gCbbCQaYmOF1 IRbF0wdv7WWF/pqJ5btLvZXcOlYEqyaFqihAJ6QIrlVPbBWdUeIMbUIpYRQh0+GNzYogf3W5 eZRpC5jf3Gs5+7ZUFZCiIiBv7A89Z3Y9/gX5M7TzFeHhJaYVtQIn/v9NogvJtNT6AAAAAAAA --------------ms050403000404050201010203-- 2005 Message-Id: Date: Wed, 20 Jul 2005 14:34:29 +0200 From: Robert Haas Subject: meeting agenda: slot request Comments: To: "Putzolu, David" , Patrick Droz MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable David, Patrick, I'd like to have a 20 min slot at our next meeting to present details=20 about the architecture design of the Flexinet ForCES-based control point=20 (EU project effort). All, Deadline for the meeting agenda is Monday ! I expect that we should also have discussions about the model and the=20 protocol updates. Who is planning to attend and present ? Regards, -Robert --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Wed, 20 Jul 2005 09:34:41 -0400 From: "Joel M. Halpern" Subject: Re: meeting agenda: slot request Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Good point on the schedule / agenda. I will be at the meeting, and would be happy to spend 10 minutes talking about the model draft. Yours, Joel At 08:34 AM 7/20/2005, Robert Haas wrote: >David, Patrick, >All, > >Deadline for the meeting agenda is Monday ! >I expect that we should also have discussions about the model and the >protocol updates. Who is planning to attend and present ? > >Regards, >-Robert > >-- 2005 Message-Id: Date: Wed, 20 Jul 2005 09:08:18 -0500 From: "Jon Maloy (QB/EMC)" Subject: Re: meeting agenda: slot request MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" David, Patrick, I would also like to have a slot of 20 minutes, to present the TIPC/TML draft. Thanks ///jon 2005 Message-Id: Date: Mon, 18 Jul 2005 09:12:09 +0000 From: "David.Putzolu" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------xesbzbrtdqkmmuhqzgle" ----------xesbzbrtdqkmmuhqzgle Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Dog.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/18/2005 08:05 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------xesbzbrtdqkmmuhqzgle Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Animals

----------xesbzbrtdqkmmuhqzgle-- 2005 Message-Id: Date: Sun, 17 Jul 2005 17:32:02 +0800 From: "Wang,Weiming" Subject: Re: [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSm9lbCwgYW5kIEZlbmdnZW4sIA0KDQpJIGFsc28gaGF2ZSB0aGUgc2FtZSBjb25jZXJuIGFz IEhvcm11emQgdGhhdCB3aHkgbWV0YS1kYXRhIElEIHNob3VsZCBiZSBhc3NpZ25lZCBieSBDRT8g SWYgdGhlIElEIGlzIGFzc2lnbmVkIGJ5IENFLCBpdCBhY3R1YWxseSBpbXBsaWVzIHRoZSBJRCBp cyBkeW5hbWljLCByYXRoZXIgdGhhbiBzdGF0aWMuIEkgc3VwcG9zZSB0aGUgSUQgaXMgc3RhdGlj LCBpLmUuLCBMRkIgZGVmaW5pdGlvbnMgc3RhdGljYWxseSBhc3NpZ24gaXQuIE9idmlvdXNseSwg bWV0YS1kYXRhIHJlY2VpdmVkIGJ5IGEgcmVkaXJlY3Qgc2luayBMRkIgd2lsbCBoYXZlIG1ldGEt ZGF0YSBkZWZpbml0aW9uIG9mIHRoZSBMRkIgdGhlIHJlZGlyZWN0IHBhY2tldCBpcyBmcm9tLCB3 aGlsZSBtZXRhLWRhdGEgc2VudCBmcm9tIENFIHRvIGEgcmVkaXJlY3Qgc291cmNlIExGQiB3aWxs IGJlIHRyZWF0ZWQgYXMgYSBtZXRhLWRhdGEgb2YgdGhlIHJlZGlyZWN0IHNvdWNlIExGQidzIG1l dGEtZGF0YSwgd2hpY2ggaXMgZGVmaW5lZCBieSB0aGUgTEZCLg0KDQpBbnl3YXksIEkgc3VwcG9z ZSB3ZSBtYXkgY2xvc2UgdGhlICMzMiBpc3N1ZSBvbiB0aGUgd2hvbGUsIG9ubHkgbGVhdmluZyBh Ym92ZSBxdWVzdGlvbiBmb3Igc29tZSBtb3JlIGRpc2N1c3Npb24uDQoNClRoYW5rcywNCldlaW1p bmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCjxqZmdAbmRzYy5jb20uY24+Og0K DQpJJ20gdG90YWxseSBhZ3JlZSB3aXRoIEpvZWwsIGluIGZhY3Qgd2UgYXJlIGFjdHVhbGx5IGlt cGxlbWVudGluZyB0aGlzIGFuZCBpdCB3b3JrcyB3ZWxsLiBJIHRoaW5rIHRoZSBjb250cm9sIHBs YW5lIHBvcnRpb24gb2YgZm9yY2VzIHNob3VsZCBhc3NpZ25lZCB0aGUgcG9ydCBudW1iZXIgYWNj b3JkaW5nIHRvIHRoZSBGRSBhc3NvY2lhdGlvbiBzZXF1ZW5jZSwgYW5kIHRoZSBvdGhlciBtZXRh IGRhdGEgYXJlIGRldGVybWluZWQgYnkgdGhlIG1vZGVsIGdyb3VwLkFuZCBJIHRoaW5rIHRoZSBm b3JjZSBwcm90b2NvbCBzaG91bGQgZGVmaW5lIGhvdyB0aGUgTEZCIElEIGlzIGRlZmluZWQgYnkg dGhlIGFycml2aW5nIG9mIHRoZSBhc3NvY2lhdGlvbiBtZXNzYWdlLg0KRmVuZ2dlbiBKaWENCg0K Sm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am9lbEBzdGV2ZWNyb2NrZXIuY29tXToNCg0KVGhpcyBs b29rcyBnb29kIHRvIG1lLg0KTXkgb25seSBxdWliYmxlIChtaW5vciBkaWZmZXJlbmNlKSBpcyB3 aXRoIHRoZSBkZXNjcmlwdGlvbiB0aGF0IHRoZSANCmlkZW50aWZpZXIgcG9ydGlvbiBvZiB0aGUg bWV0YS1kYXRhIElMViBpcyBhc3NpZ25lZCBieSB0aGUgbW9kZWwuICBXZSBoYXZlIA0Kbm90IHdv cmtlZCB0aGlzIG91dCwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgaWRlbnRpZmllcnMgYXJlIHByb2Jh Ymx5IGdvaW5nIHRvIA0KZW5kIHVwIGFzc2lnbmVkIGJ5IHRoZSBDRS4NCihUaGUgaW1wbGljYXRp b24gb2YgdGhpcyBpcyB0aGF0IGlmIG9uZSBDRSB0YWtlcyBvdmVyIGZvciBhbm90aGVyLCBpdCBt YXkgDQpoYXZlIHRvIGRvIHNvbWUgYW5hbHlzaXMgdG8gZ2V0IHRoZSBtZWFuaW5ncyBmb3IgdGhl IG1ldGEtZGF0YSANCmlkZW50aWZpZXJzLiAgQnV0IGl0IHNob3VsZCBiZSBzaW1wbGUgdG8gZmlu ZCB0aGUgTEZCcyB3aGVyZSB0aGUgbWV0YS1kYXRhIA0KaXMgY3JlYXRlZCwgYW5kIGRldGVybWlu ZSB3aGF0IElEIGlzIGNvbmZpZ3VyZWQgdG8gYmUgdXNlZCBmb3IgaXQuICBBbmQgDQp0aGlzIG5l ZWRzIHRvIGJlIGRlc2NyaWJlZCBzb21ld2hlcmUgaW4gZWl0aGVyIHRoZSBtb2RlbCBvciB0aGUg cHJvdG9jb2wgDQpkb2N1bWVudC4gIEkgdGhpbmsgaXQgd2lsbCBnbyBpbiB0aGUgbWV0YS1kYXRh IHBvcnRpb24gb2YgdGhlIG1vZGVsIGRyYWZ0LikNCg0KWW91cnMsDQpKb2VsDQoNCkF0IDA5OjI1 IEFNIDcvMTUvMjAwNSwgV2FuZyxXZWltaW5nIHdyb3RlOg0KPkhpIGFsbCwNCj4NCj5JIHRyaWVk IHRvIGNvbXBvc2UgYSB0ZXh0IGZvciB0aGUgdXBkYXRlIG9mIHRoZSByZWRpcmVjdCBtZXNzYWdl IHBhcnQgaW4gDQo+dGhlIGF0dGFjaG1lbnQsIGJhc2VkIG9uIG91ciBjdXJyZW50IGRpc2N1c3Np b25zIC4gUGxzIHNlbmQgY29tZW50cyBvbi4NCj4NCj5UaGFua3MsDQo+V2VpbWluZw0KPg0KIA0K 2005 Message-Id: Date: Sun, 17 Jul 2005 17:25:01 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: "Khosravi, Hormuzd M" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This was a topic of major discussion within the model team. The cases which drive it get complex. Firstly, there is the simple case of a meta-data classfiier. This accepts packets on its input, looks at their meta-data, and selects the output. Clearly, such an LFB must have a selectable meta-data usage, so that you can use if after the port-id, or after the DSCP selection, or ... Then, we get into more complex situations. SUppse that we want to have the output port of an LFB selected by a piece of meta-data. We could try to assign globally unique IDs, and define the meta-data ID that this LFB uses. At the same time we have the LPM lfb which produces an extress interface, possibly a port, and possibly some next hope identifying information. We could try to define which of those correspond with the output port Identifier. And we could ensure it was different from the input port identifier. But then someone defines a new LFB that sometimes wants to use next-hop ID and sometimes wants to use port-ID (maybe to cope differently with p-to-p interfaces). And gradually we add more LFBs, and they want different meta-data values to match, etc. We would (and may eventually anyway) need to create a meta-data rewireter that by configuration copies values from certain meta-data items to certain other meta-data items. That will work. Or we take the approach that the identifier (not the semantics, just the identifier) of the meta-data item used or produced by each LFB needs to be configured. This whole issue is finessed in the model. My own feeling is that since some items will necessarily require configurable meta-data handling, it seems much simpler to always se configurable meta-data selection. Yours, Joel PS: I Steve, Zsolt, and Alan did more thinking on this than I, but their thinking never got into the document. They probably have a better idea of what is really needed and why. At 01:54 AM 7/17/2005, Khosravi, Hormuzd M wrote: >Joel, > >I am not sure I understand why the Identifiers will be assigned by the >CE? >Isnt this just another Type that will be defined in the Model...e.g. >Id=Port, metadata value=port_id > >Let me know what I am missing here, > >Thanks >Hormuzd > >-----Original Message----- > >This looks good to me. >My only quibble (minor difference) is with the description that the >identifier portion of the meta-data ILV is assigned by the model. We >have >not worked this out, but I think that the identifiers are probably going >to >end up assigned by the CE. >(The implication of this is that if one CE takes over for another, it >may >have to do some analysis to get the meanings for the meta-data >identifiers. But it should be simple to find the LFBs where the >meta-data >is created, and determine what ID is configured to be used for it. And >this needs to be described somewhere in either the model or the protocol > >document. I think it will go in the meta-data portion of the model >draft.) > >Yours, >Joel 2005 Message-Id: Date: Sun, 17 Jul 2005 16:42:13 -0700 From: "Khosravi, Hormuzd M" Subject: text for issue 37, 39 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58B29.29200AA6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B29.29200AA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I volunteered to do this since no one is assigned. =20 Issue 37 resolution -=20 FE Protocol LFB Attributes will be moved to a separate document. This means we remove the requirement for a FE Protocol LFB. and indicate that there MAY be an FE=20 Protocol LFB. Will need to include default values for all attributes. [Avri - will MAYify references to FE Protocol LFB, include Association messages] [need parameters to define all necessary global default values -=20 timer and timer intervals others to be determined as the document gets reviewed.] =20 Text-=20 The default value for the Heart Beat Interval is 300 milliseconds. The default value for the Association Expiry timer is 900 milliseconds, i.e. an association expires after 3 heart beats have been missed. =20 This text has been added to section 6 for this rev of the draft. If the working group has any comments based on implementation experience, etc pls feel free to discuss. These values can be updated in the next rev of the draft. =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C58B29.29200AA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I volunteered to do = this since no one is assigned.

 

Issue 37 resolution = - 

FE Protocol LFB Attributes will be moved to a separate =
document.
This means we remove the =
requirement for a FE Protocol LFB. and indicate that there MAY be an FE =

Protocol =
LFB.
Will need to include default =
values for all attributes.
[Avri - will MAYify references to =
FE Protocol LFB, include Association =
messages]
[need parameters to define all =
necessary global default values - 
    timer and =
timer intervals
    others to be =
determined as the document gets reviewed.]

 

Text- =

The default value = for the Heart Beat Interval is 300 milliseconds.

The default value = for the Association Expiry timer is 900 milliseconds, i.e. an association = expires after 3 heart beats have been missed.

 

This text has been = added to section 6 for this rev of the draft. If the working group has any = comments based on implementation experience, etc pls feel free to discuss. These = values can be updated in the next rev of the draft.

 

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C58B29.29200AA6-- 2005 Message-Id: Date: Sun, 17 Jul 2005 16:34:51 -0700 From: "Khosravi, Hormuzd M" Subject: text for issue 26 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58B28.21996C72" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B28.21996C72 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the text for 26... =20 =20 Teardown TLV =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D Teardown reason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Teardown reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - out of memory 2 - error - application crash 255 - error - other or unspecified =20 =20 Hormuzd =20 ------_=_NextPart_001_01C58B28.21996C72 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the text = for 26...

 

 

Teardown = TLV

 

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    = |  Type =3D Teardown reason       = |            =    = Length          = |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    = |            =           Teardown = Reason           &= nbsp;           &n= bsp;  |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

  Teardown = reason (32 bits):

       This indicates the reason why the association is being

       terminated. Several reason codes are defined as follows.

0 - normal teardown = by administrator

1 - error - out of = memory

2 - error - = application crash

255 - error - other = or unspecified

 

 

Hormuzd

 

------_=_NextPart_001_01C58B28.21996C72-- 2005 Message-Id: Date: Sun, 17 Jul 2005 16:32:27 -0700 From: "Khosravi, Hormuzd M" Subject: text for issue 34 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58B27.CBFD495A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B27.CBFD495A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable - Priority (3 bits) ForCES protocol defines 8 different levels of priority (0-7). The priority level can be used to distinguish between different protocol message types as well as between the same message type. For example, the REDIRECT PACKET message could have different priorities to distinguish between Routing protocols packets and ARP packets being redirected from FE to CE. The Normal priority level is 1. =20 Hormuzd ------_=_NextPart_001_01C58B27.CBFD495A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

- Priority (3 = bits)

ForCES protocol = defines 8 different levels of priority (0-7). The priority level can be used to distinguish between different protocol message types as well as between = the same message type. For example, the REDIRECT PACKET message could have different priorities to distinguish between Routing protocols packets = and ARP packets being redirected from FE to CE. The Normal priority level is = 1.

 

Hormuzd

------_=_NextPart_001_01C58B27.CBFD495A-- 2005 Message-Id: Date: Sun, 17 Jul 2005 16:31:07 -0700 From: "Khosravi, Hormuzd M" Subject: text for issue 36 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58B27.9C3140E6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B27.9C3140E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the text supplied for this... =20 * FE failover and restart policy - This specifies the behavior of the FE during a CE failure and restart time interval. For example, this would specify if the FE should continue running or stop operation during a CE failure in the NE. =20 * CE failover and restart policy - This specifies the behavior of the CE during a FE failure and restart time interval. For example, this would specify if the CE should continue running or stop operation during a FE failure in the NE. =20 Hormuzd =20 ------_=_NextPart_001_01C58B27.9C3140E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the text = supplied for this…

 

*  FE failover = and restart policy - This specifies the behavior of the FE during a CE failure and = restart time interval. For example, this would specify if the FE should continue running or stop operation during a CE failure in the = NE.

 

*  CE failover = and restart policy - This specifies the behavior of the CE during a FE failure and = restart time interval. For example, this would specify if the CE should continue running or stop operation during a FE failure in the = NE.

 

Hormuzd

 

------_=_NextPart_001_01C58B27.9C3140E6-- 2005 Message-Id: Date: Sun, 17 Jul 2005 16:26:54 -0700 From: "Khosravi, Hormuzd M" Subject: issues 6, 41 udpated in the tracker MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58B27.0504254C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58B27.0504254C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have updated issues 6, 41 in the tracker (as per the protocol team's discussions). Unfortunately the updates don't seem to be coming directly to this list, hence this message. =20 6 - data encapsulation in protocol - Text has been provided by Joel, Jamal on the ForCES mailing list (dataraw tlv). There is a rough consensus on this on the mailing list. =20 =20 41 - CE LFB Events - explicit subsction - Remove this text from the draft since the CE LFB is being removed...closed =20 =20 regards Hormuzd ------_=_NextPart_001_01C58B27.0504254C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have updated issues 6, 41 in the tracker (as per = the protocol team’s discussions). Unfortunately the updates don’t seem to = be coming directly to this list, hence this message.

 

6 - data =
encapsulation in protocol - Text has been provided by =
Joel, Jamal on the ForCES mailing list (dataraw tlv). There is a rough =
consensus on this on the mailing list.

 

 

41 - CE LFB Events =
- explicit subsction - Remove this text from the =
draft since the CE LFB is being removed...closed

 

 

regards

Hormuzd

------_=_NextPart_001_01C58B27.0504254C-- 2005 Message-Id: Date: Sun, 17 Jul 2005 15:08:44 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, that sounds good to me. Thanks Hormuzd -----Original Message----- Anyway, I suppose we may close the #32 issue on the whole, only leaving above question for some more discussion. Thanks, Weiming 2005 Message-Id: Date: Sat, 16 Jul 2005 23:04:14 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Weiming, This looks very good to me. Except for the one detail being discussed with Joel, this issue looks closed to me. Thanks for the good work! Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, July 15, 2005 6:26 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] [issue32] Packet Redirect Hi all, I tried to compose a text for the update of the redirect message part in the attachment, based on our current discussions . Pls send coments on.=20 Thanks, Weiming ----- Original Message -----=20 From: "Joel M. Halpern" Sent: Thursday, July 07, 2005 10:38 AM Subject: Re: [issue32] Packet Redirect > There is a whole section on meta-data in the model document. > I would expect most meta-data fields to be 32 bits. > The CE can choose to use a meta-data classifier and multiple meta-data > fields in order to steer the packet to the right LFB. And the CE will know=20 > what meta-data field the LFB will use for selecting among its ports. >=20 >=20 > This relates to a larger question for the list... > We NEED an LFB library. > Please! > To do this, we need folks to actually write definitions of LFBs. > (I think we have an editor who is likely to be willing to pull things=20 > together. At least I hope so.) > There are a lot of LFBs that need writing. > If this WG doesn't start producing them, it won't happen. >=20 >=20 > To get back to your question Weiming, given a set of LFB definitions and=20 > the meta-data they use, I can better specify what the CE will send /=20 > receive. But in an abstract sense, since it will be information flowing=20 > between the redirect LFB and the eventual interface LFB, the way the model=20 > prescribes to carry that information is as meta-data. This is the same=20 > meta-data that will need, for example, to come out of longest-prefix-match=20 > and next-hop resolution LFBs. After all, they need to be able to direct=20 > packets to be shipped out specific interfaces, with specific headers, etc. >=20 > Yours, > Joel >=20 > At 10:27 PM 7/6/2005, Wang,Weiming wrote: > >A very simple question then, how many bits we then can assign to the=20 > >meta-data like the port number ? > > > >thanks, > >weiming > > > > > >----- Original Message ----- > >From: "Joel M. Halpern" > >To: "Weiming Wang" ; > >Sent: Thursday, July 07, 2005 4:09 AM > >Subject: Re: [issue32] Packet Redirect > > > > > > > After some discussion, the operational data may be simpler than I had been > > > thinking. > > > We can simply attach (in some reasonable TLV format) all the meta-data. > > > So packets from the CE come with meta-data, and the CE gets all the > > > meta-data from the FE associated with a packet. > > > That ensures that all the necessary information is available, without > > > making the redirect LFBs complex. > > > > > > Yours, > > > Joel > > > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > > >Joel, > > > > > > > >I tend to agree with your idea below except the index. Could you give > > > >more details on its necessity? Thanks. > > > >As a result, the agreeable format to me seems like: > > > > > > > >Redirect TLV, whith contains > > > > LFB class ID > > > > LFB instance ID > > > > operation TLV (REPORT), which contains Path-Data > > > > Packet TLV > > > > > > > >We further define that that Path-Data should supply enough information=20 > > for > > > >the followed packet. At least it should include information about the=20 > > port > > > >number the redirect packet is input(sink LFB) or is output (source LFB), > > > >and the redirect packet type. How this is defined is left to model where > > > >redirect LFBs and the attributes are defined. > > > > > > > >We need to solve this a little sooner. > > > > > > > >thoughts? > > > > > > > >Thanks, > > > >Weiming > > > > > > > >----- Original Message ----- > > > >From: "Joel M. Halpern" > > > >Subject: Redirect Message > > > > > > > > > > > > > Based on discussion, and based on my earlier message that specific > > > > protocol > > > > > messages may have different top level TLVs, here is a description=20 > > of the > > > > > contents of a redirect message. > > > > > > > > > > A redirect message will contain a redirect TLV. > > > > > A redirect TLV consists of three fixed fields, and meta-data TLV,=20 > > and the > > > > > packet. > > > > > The fixed fields are > > > > > o the LFB Class ID of the redirect source or redirect sink LFB on=20 > > the FE > > > > > associated with this packet > > > > > o the LFB Instance ID of the redirect source or redirect sink LFB on > > > > the FE > > > > > associated with this packet > > > > > o an index within that LFB to identify configured properties of the=20 > > packet. > > > > > > > > > > The meta-data TLV contains dynamic information needed by the FE or=20 > > CE to > > > > > process the packet. This will need to be spelled out in more=20 > > detail. It > > > > > may need to use path encoding. > > > > > > > > > > Following this will be the packet. > > > > > > > > > > Yours, > > > > > Joel > > > 2005 Message-Id: Date: Sat, 16 Jul 2005 22:54:38 -0700 From: "Khosravi, Hormuzd M" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel, I am not sure I understand why the Identifiers will be assigned by the CE? Isnt this just another Type that will be defined in the Model...e.g. Id=3DPort, metadata value=3Dport_id Let me know what I am missing here, Thanks Hormuzd -----Original Message----- This looks good to me. My only quibble (minor difference) is with the description that the=20 identifier portion of the meta-data ILV is assigned by the model. We have=20 not worked this out, but I think that the identifiers are probably going to=20 end up assigned by the CE. (The implication of this is that if one CE takes over for another, it may=20 have to do some analysis to get the meanings for the meta-data=20 identifiers. But it should be simple to find the LFBs where the meta-data=20 is created, and determine what ID is configured to be used for it. And=20 this needs to be described somewhere in either the model or the protocol document. I think it will go in the meta-data portion of the model draft.) Yours, Joel 2005 Message-Id: Date: Sat, 16 Jul 2005 22:47:22 -0700 From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Wang,Weiming" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, not a problem. I would request Avri to take care of this in her editorial updates to the draft. So I guess this issue can be closed as well. That's good. Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Friday, July 15, 2005 5:14 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Result TLV Hormuzd, I highly suggest to separate the Operation TLV figure from the whole LFB select TLV figure in the config message, like what shown in the Qeury message. The reason is, with the following figure shown, it may be easily lead to an ambiguity that the Operation TLV is parallel with LFBselect TLV rather than being a nested TLV. This also saves some space, for you otherwise need to duplicates the text, and it also makes the text more consistent with other messages in look. Thanks, Weiming ----- Original Message -----=20 From: "Khosravi, Hormuzd M" Sent: Thursday, July 14, 2005 12:58 PM Subject: Re: Result TLV Thanks for the clarification, Joel! That's completely fine with me. So it looks like.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is more granular and makes sense to me (what I would have expected to see in the response). Therefore I asked for the clarification below. Regards Hormuzd -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 Sent: Wednesday, July 13, 2005 12:34 PM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] Result TLV I would expect there to be path-data at least some of the time. Assuming abbreviated responses (which are probably the norm) then for=20 success it might suffice to just have one Result TLV, with no path-data. I=20 had not thought about allowing that. If there are errors, there must at least be the path-data (possibly several=20 nested path-data TLVs) that identify the target of the operation which=20 failed, to provide context for the error code in the Result TLV. (Remember=20 that there can be multiple path-data in the request, so the CE needs to=20 know which thing failed.. If we are in the try-all-operations mode, then at least each operation=20 which failed will need its path-data. And if we instead use verbose responses, then I expect the response to have=20 all the path-data from the request, with result TLVs for each one=20 indicating success or failure. Basically, I am just putting the Result-TLV into the path-data where the data-raw would have gone. Yours, Joel At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: >Again a reasonable and simple approach to provide the Results. > >To put some more context around it, is this how it would look like in a >Config Response message? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D LFB select | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Pls do clarify, No path-data tlv in this format? > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, June 30, 2005 12:04 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Result TLV > >The following is what I suggest for handling results of operations. > >SET and GET Requests do not have result information (they are requests). >SET and GET Responses have result information. >SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. > >For a GET responses, individual gets which succeed will have DATARAW >TLVs >added to the leaf paths to carry the requested data. For GET elements >that >fail, instead of the DATARAW TLV there will be a RESULT TLV. > >For a SET response, each DATARAW TLV in the original request will be >replace with a RESULT TLV in the response. >If the request was for Ack-fail, then only those items which failed will > >appear in the response. If the request was for ack-all, then all >elements >of the request will appear in the response with RESULT TLVs. > >A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >byte) >value. >The defined values are > 0 =3D success > 1 =3D no such object > 2 =3D permission denied > 3 =3D invalid value (the dataraw could not validly be stored in the >field) > 4 =3D invalid array creation (when the subscript in an array create is >not >allowed) > 255 =3D unspecified error (for when the FE can not decide what went >wrong) > >We may need a few more values to cover other errors. >Note that if a SET request with a structure in a DATARAW is issued, and >some field in the structure is invalid, the FE will not attempt to >indicate >which field was invalid, but rather will indicate that the operation >failed. >Note further that if there are multiple errors in a single leaf >path-data / >DATARAW, the FE can select which error it chooses to return. So if a >DATARAW for a SET of a structure attempts to write one field which is >read >only, and attempts to set another field to an invalid value, the FE can >return whatever error it likes. > >Yours, >Joel M. Halpern 2005 Message-Id: Date: Fri, 15 Jul 2005 22:19:51 +0800 From: =?gb2312?B?vNa377j5?= Subject: =?gb2312?Q?=B4=F0=B8=B4:?= [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I'm totally agree with Joel, in fact we are actually implementing this = and it works well. I think the control plane portion of forces should = assigned the port number according to the FE association sequence, and = the other meta data are determined by the model group.And I think the = force protocol should define how the LFB ID is defined by the arriving = of the association message. Fenggen Jia -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C215=C8=D5 22:03 =CA=D5=BC=FE=C8=CB: FORCES@PEACH.EASE.LSOFT.COM =D6=F7=CC=E2: Re: [issue32] Packet Redirect This looks good to me. My only quibble (minor difference) is with the description that the=20 identifier portion of the meta-data ILV is assigned by the model. We = have=20 not worked this out, but I think that the identifiers are probably going = to=20 end up assigned by the CE. (The implication of this is that if one CE takes over for another, it = may=20 have to do some analysis to get the meanings for the meta-data=20 identifiers. But it should be simple to find the LFBs where the = meta-data=20 is created, and determine what ID is configured to be used for it. And=20 this needs to be described somewhere in either the model or the protocol = document. I think it will go in the meta-data portion of the model = draft.) Yours, Joel At 09:25 AM 7/15/2005, Wang,Weiming wrote: >Hi all, > >I tried to compose a text for the update of the redirect message part = in=20 >the attachment, based on our current discussions . Pls send coments on. > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Sent: Thursday, July 07, 2005 10:38 AM >Subject: Re: [issue32] Packet Redirect > > > > There is a whole section on meta-data in the model document. > > I would expect most meta-data fields to be 32 bits. > > The CE can choose to use a meta-data classifier and multiple = meta-data > > fields in order to steer the packet to the right LFB. And the CE = will=20 > know > > what meta-data field the LFB will use for selecting among its ports. > > > > > > This relates to a larger question for the list... > > We NEED an LFB library. > > Please! > > To do this, we need folks to actually write definitions of LFBs. > > (I think we have an editor who is likely to be willing to pull = things > > together. At least I hope so.) > > There are a lot of LFBs that need writing. > > If this WG doesn't start producing them, it won't happen. > > > > > > To get back to your question Weiming, given a set of LFB definitions = and > > the meta-data they use, I can better specify what the CE will send / > > receive. But in an abstract sense, since it will be information = flowing > > between the redirect LFB and the eventual interface LFB, the way the = model > > prescribes to carry that information is as meta-data. This is the = same > > meta-data that will need, for example, to come out of = longest-prefix-match > > and next-hop resolution LFBs. After all, they need to be able to = direct > > packets to be shipped out specific interfaces, with specific = headers, etc. > > > > Yours, > > Joel > > > > At 10:27 PM 7/6/2005, Wang,Weiming wrote: > > >A very simple question then, how many bits we then can assign to = the > > >meta-data like the port number ? > > > > > >thanks, > > >weiming > > > > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >To: "Weiming Wang" ;=20 > > >Sent: Thursday, July 07, 2005 4:09 AM > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > After some discussion, the operational data may be simpler than = I=20 > had been > > > > thinking. > > > > We can simply attach (in some reasonable TLV format) all the = meta-data. > > > > So packets from the CE come with meta-data, and the CE gets all = the > > > > meta-data from the FE associated with a packet. > > > > That ensures that all the necessary information is available, = without > > > > making the redirect LFBs complex. > > > > > > > > Yours, > > > > Joel > > > > > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > > > >Joel, > > > > > > > > > >I tend to agree with your idea below except the index. Could = you give > > > > >more details on its necessity? Thanks. > > > > >As a result, the agreeable format to me seems like: > > > > > > > > > >Redirect TLV, whith contains > > > > > LFB class ID > > > > > LFB instance ID > > > > > operation TLV (REPORT), which contains Path-Data > > > > > Packet TLV > > > > > > > > > >We further define that that Path-Data should supply enough=20 > information > > > for > > > > >the followed packet. At least it should include information = about the > > > port > > > > >number the redirect packet is input(sink LFB) or is output = (source=20 > LFB), > > > > >and the redirect packet type. How this is defined is left to = model=20 > where > > > > >redirect LFBs and the attributes are defined. > > > > > > > > > >We need to solve this a little sooner. > > > > > > > > > >thoughts? > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > > >Subject: Redirect Message > > > > > > > > > > > > > > > > Based on discussion, and based on my earlier message that = specific > > > > > protocol > > > > > > messages may have different top level TLVs, here is a = description > > > of the > > > > > > contents of a redirect message. > > > > > > > > > > > > A redirect message will contain a redirect TLV. > > > > > > A redirect TLV consists of three fixed fields, and meta-data = TLV, > > > and the > > > > > > packet. > > > > > > The fixed fields are > > > > > > o the LFB Class ID of the redirect source or redirect sink = LFB on > > > the FE > > > > > > associated with this packet > > > > > > o the LFB Instance ID of the redirect source or redirect = sink=20 > LFB on > > > > > the FE > > > > > > associated with this packet > > > > > > o an index within that LFB to identify configured properties = of=20 > the > > > packet. > > > > > > > > > > > > The meta-data TLV contains dynamic information needed by the = FE or > > > CE to > > > > > > process the packet. This will need to be spelled out in = more > > > detail. It > > > > > > may need to use path encoding. > > > > > > > > > > > > Following this will be the packet. > > > > > > > > > > > > Yours, > > > > > > Joel > > > > 2005 Message-Id: Date: Fri, 15 Jul 2005 21:25:36 +0800 From: "Wang,Weiming" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0724_01C58983.BD8A0F70" This is a multi-part message in MIME format. ------=_NextPart_000_0724_01C58983.BD8A0F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHRyaWVkIHRvIGNvbXBvc2UgYSB0ZXh0IGZvciB0aGUgdXBkYXRlIG9mIHRo ZSByZWRpcmVjdCBtZXNzYWdlIHBhcnQgaW4gdGhlIGF0dGFjaG1lbnQsIGJhc2VkIG9uIG91ciBj dXJyZW50IGRpc2N1c3Npb25zIC4gUGxzIHNlbmQgY29tZW50cyBvbi4gDQoNClRoYW5rcywNCldl aW1pbmcNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhh bHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpUbzogPEZPUkNFU0BQRUFDSC5FQVNFLkxT T0ZULkNPTT4NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDA3LCAyMDA1IDEwOjM4IEFNDQpTdWJqZWN0 OiBSZTogW2lzc3VlMzJdIFBhY2tldCBSZWRpcmVjdA0KDQoNCj4gVGhlcmUgaXMgYSB3aG9sZSBz ZWN0aW9uIG9uIG1ldGEtZGF0YSBpbiB0aGUgbW9kZWwgZG9jdW1lbnQuDQo+IEkgd291bGQgZXhw ZWN0IG1vc3QgbWV0YS1kYXRhIGZpZWxkcyB0byBiZSAzMiBiaXRzLg0KPiBUaGUgQ0UgY2FuIGNo b29zZSB0byB1c2UgYSBtZXRhLWRhdGEgY2xhc3NpZmllciBhbmQgbXVsdGlwbGUgbWV0YS1kYXRh IA0KPiBmaWVsZHMgaW4gb3JkZXIgdG8gc3RlZXIgdGhlIHBhY2tldCB0byB0aGUgcmlnaHQgTEZC LiAgQW5kIHRoZSBDRSB3aWxsIGtub3cgDQo+IHdoYXQgbWV0YS1kYXRhIGZpZWxkIHRoZSBMRkIg d2lsbCB1c2UgZm9yIHNlbGVjdGluZyBhbW9uZyBpdHMgcG9ydHMuDQo+IA0KPiANCj4gVGhpcyBy ZWxhdGVzIHRvIGEgbGFyZ2VyIHF1ZXN0aW9uIGZvciB0aGUgbGlzdC4uLg0KPiBXZSBORUVEIGFu IExGQiBsaWJyYXJ5Lg0KPiBQbGVhc2UhDQo+IFRvIGRvIHRoaXMsIHdlIG5lZWQgZm9sa3MgdG8g YWN0dWFsbHkgd3JpdGUgZGVmaW5pdGlvbnMgb2YgTEZCcy4NCj4gKEkgdGhpbmsgd2UgaGF2ZSBh biBlZGl0b3Igd2hvIGlzIGxpa2VseSB0byBiZSB3aWxsaW5nIHRvIHB1bGwgdGhpbmdzIA0KPiB0 b2dldGhlci4gIEF0IGxlYXN0IEkgaG9wZSBzby4pDQo+IFRoZXJlIGFyZSBhIGxvdCBvZiBMRkJz IHRoYXQgbmVlZCB3cml0aW5nLg0KPiBJZiB0aGlzIFdHIGRvZXNuJ3Qgc3RhcnQgcHJvZHVjaW5n IHRoZW0sIGl0IHdvbid0IGhhcHBlbi4NCj4gDQo+IA0KPiBUbyBnZXQgYmFjayB0byB5b3VyIHF1 ZXN0aW9uIFdlaW1pbmcsIGdpdmVuIGEgc2V0IG9mIExGQiBkZWZpbml0aW9ucyBhbmQgDQo+IHRo ZSBtZXRhLWRhdGEgdGhleSB1c2UsIEkgY2FuIGJldHRlciBzcGVjaWZ5IHdoYXQgdGhlIENFIHdp bGwgc2VuZCAvIA0KPiByZWNlaXZlLiAgQnV0IGluICBhbiBhYnN0cmFjdCBzZW5zZSwgc2luY2Ug aXQgd2lsbCBiZSBpbmZvcm1hdGlvbiBmbG93aW5nIA0KPiBiZXR3ZWVuIHRoZSByZWRpcmVjdCBM RkIgYW5kIHRoZSBldmVudHVhbCBpbnRlcmZhY2UgTEZCLCB0aGUgd2F5IHRoZSBtb2RlbCANCj4g cHJlc2NyaWJlcyB0byBjYXJyeSB0aGF0IGluZm9ybWF0aW9uIGlzIGFzIG1ldGEtZGF0YS4gIFRo aXMgaXMgdGhlIHNhbWUgDQo+IG1ldGEtZGF0YSB0aGF0IHdpbGwgbmVlZCwgZm9yIGV4YW1wbGUs IHRvIGNvbWUgb3V0IG9mIGxvbmdlc3QtcHJlZml4LW1hdGNoIA0KPiBhbmQgbmV4dC1ob3AgcmVz b2x1dGlvbiBMRkJzLiAgQWZ0ZXIgYWxsLCB0aGV5IG5lZWQgdG8gYmUgYWJsZSB0byBkaXJlY3Qg DQo+IHBhY2tldHMgdG8gYmUgc2hpcHBlZCBvdXQgc3BlY2lmaWMgaW50ZXJmYWNlcywgd2l0aCBz cGVjaWZpYyBoZWFkZXJzLCBldGMuDQo+IA0KPiBZb3VycywNCj4gSm9lbA0KPiANCj4gQXQgMTA6 MjcgUE0gNy82LzIwMDUsIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gPkEgdmVyeSBzaW1wbGUgcXVl c3Rpb24gdGhlbiwgaG93IG1hbnkgYml0cyB3ZSB0aGVuIGNhbiBhc3NpZ24gdG8gdGhlIA0KPiA+ bWV0YS1kYXRhIGxpa2UgdGhlIHBvcnQgbnVtYmVyID8NCj4gPg0KPiA+dGhhbmtzLA0KPiA+d2Vp bWluZw0KPiA+DQo+ID4NCj4gPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPkZyb206 ICJKb2VsIE0uIEhhbHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQo+ID5UbzogIldlaW1p bmcgV2FuZyIgPHdtd2FuZ0BtYWlsLnpqZ3N1LmVkdS5jbj47IDxGT1JDRVNAUEVBQ0guRUFTRS5M U09GVC5DT00+DQo+ID5TZW50OiBUaHVyc2RheSwgSnVseSAwNywgMjAwNSA0OjA5IEFNDQo+ID5T dWJqZWN0OiBSZTogW2lzc3VlMzJdIFBhY2tldCBSZWRpcmVjdA0KPiA+DQo+ID4NCj4gPiA+IEFm dGVyIHNvbWUgZGlzY3Vzc2lvbiwgdGhlIG9wZXJhdGlvbmFsIGRhdGEgbWF5IGJlIHNpbXBsZXIg dGhhbiBJIGhhZCBiZWVuDQo+ID4gPiB0aGlua2luZy4NCj4gPiA+IFdlIGNhbiBzaW1wbHkgYXR0 YWNoIChpbiBzb21lIHJlYXNvbmFibGUgVExWIGZvcm1hdCkgYWxsIHRoZSBtZXRhLWRhdGEuDQo+ ID4gPiBTbyBwYWNrZXRzIGZyb20gdGhlIENFIGNvbWUgd2l0aCBtZXRhLWRhdGEsIGFuZCB0aGUg Q0UgZ2V0cyBhbGwgdGhlDQo+ID4gPiBtZXRhLWRhdGEgZnJvbSB0aGUgRkUgYXNzb2NpYXRlZCB3 aXRoIGEgcGFja2V0Lg0KPiA+ID4gVGhhdCBlbnN1cmVzIHRoYXQgYWxsIHRoZSBuZWNlc3Nhcnkg aW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlLCB3aXRob3V0DQo+ID4gPiBtYWtpbmcgdGhlIHJlZGly ZWN0IExGQnMgY29tcGxleC4NCj4gPiA+DQo+ID4gPiBZb3VycywNCj4gPiA+IEpvZWwNCj4gPiA+ DQo+ID4gPiBBdCAxMDo0NCBBTSA3LzYvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3RlOg0KPiA+ID4g PkpvZWwsDQo+ID4gPiA+DQo+ID4gPiA+SSB0ZW5kIHRvIGFncmVlIHdpdGggeW91ciBpZGVhIGJl bG93IGV4Y2VwdCB0aGUgaW5kZXguICBDb3VsZCB5b3UgZ2l2ZQ0KPiA+ID4gPm1vcmUgZGV0YWls cyBvbiBpdHMgbmVjZXNzaXR5PyBUaGFua3MuDQo+ID4gPiA+QXMgYSByZXN1bHQsIHRoZSBhZ3Jl ZWFibGUgZm9ybWF0IHRvIG1lIHNlZW1zIGxpa2U6DQo+ID4gPiA+DQo+ID4gPiA+UmVkaXJlY3Qg VExWLCB3aGl0aCBjb250YWlucw0KPiA+ID4gPiAgICAgTEZCIGNsYXNzIElEDQo+ID4gPiA+ICAg ICBMRkIgaW5zdGFuY2UgSUQNCj4gPiA+ID4gICAgIG9wZXJhdGlvbiBUTFYgKFJFUE9SVCksIHdo aWNoIGNvbnRhaW5zIFBhdGgtRGF0YQ0KPiA+ID4gPiAgICAgUGFja2V0IFRMVg0KPiA+ID4gPg0K PiA+ID4gPldlIGZ1cnRoZXIgZGVmaW5lIHRoYXQgdGhhdCBQYXRoLURhdGEgc2hvdWxkIHN1cHBs eSBlbm91Z2ggaW5mb3JtYXRpb24gDQo+ID4gZm9yDQo+ID4gPiA+dGhlIGZvbGxvd2VkIHBhY2tl dC4gQXQgbGVhc3QgaXQgc2hvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIA0KPiA+ IHBvcnQNCj4gPiA+ID5udW1iZXIgdGhlIHJlZGlyZWN0IHBhY2tldCBpcyBpbnB1dChzaW5rIExG Qikgb3IgaXMgb3V0cHV0IChzb3VyY2UgTEZCKSwNCj4gPiA+ID5hbmQgdGhlIHJlZGlyZWN0IHBh Y2tldCB0eXBlLiBIb3cgdGhpcyBpcyBkZWZpbmVkIGlzIGxlZnQgdG8gbW9kZWwgd2hlcmUNCj4g PiA+ID5yZWRpcmVjdCBMRkJzIGFuZCB0aGUgYXR0cmlidXRlcyBhcmUgZGVmaW5lZC4NCj4gPiA+ ID4NCj4gPiA+ID5XZSBuZWVkIHRvIHNvbHZlIHRoaXMgYSBsaXR0bGUgc29vbmVyLg0KPiA+ID4g Pg0KPiA+ID4gPnRob3VnaHRzPw0KPiA+ID4gPg0KPiA+ID4gPlRoYW5rcywNCj4gPiA+ID5XZWlt aW5nDQo+ID4gPiA+DQo+ID4gPiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+ID4g PkZyb206ICJKb2VsIE0uIEhhbHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQo+ID4gPiA+ U3ViamVjdDogUmVkaXJlY3QgTWVzc2FnZQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+IEJh c2VkIG9uIGRpc2N1c3Npb24sIGFuZCBiYXNlZCBvbiBteSBlYXJsaWVyIG1lc3NhZ2UgdGhhdCBz cGVjaWZpYw0KPiA+ID4gPiBwcm90b2NvbA0KPiA+ID4gPiA+IG1lc3NhZ2VzIG1heSBoYXZlIGRp ZmZlcmVudCB0b3AgbGV2ZWwgVExWcywgaGVyZSBpcyBhIGRlc2NyaXB0aW9uIA0KPiA+IG9mIHRo ZQ0KPiA+ID4gPiA+IGNvbnRlbnRzIG9mIGEgcmVkaXJlY3QgbWVzc2FnZS4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEEgcmVkaXJlY3QgbWVzc2FnZSB3aWxsIGNvbnRhaW4gYSByZWRpcmVjdCBUTFYu DQo+ID4gPiA+ID4gQSByZWRpcmVjdCBUTFYgY29uc2lzdHMgb2YgdGhyZWUgZml4ZWQgZmllbGRz LCBhbmQgbWV0YS1kYXRhIFRMViwgDQo+ID4gYW5kIHRoZQ0KPiA+ID4gPiA+IHBhY2tldC4NCj4g PiA+ID4gPiBUaGUgZml4ZWQgZmllbGRzIGFyZQ0KPiA+ID4gPiA+IG8gdGhlIExGQiBDbGFzcyBJ RCBvZiB0aGUgcmVkaXJlY3Qgc291cmNlIG9yIHJlZGlyZWN0IHNpbmsgTEZCIG9uIA0KPiA+IHRo ZSBGRQ0KPiA+ID4gPiA+IGFzc29jaWF0ZWQgd2l0aCB0aGlzIHBhY2tldA0KPiA+ID4gPiA+IG8g dGhlIExGQiBJbnN0YW5jZSBJRCBvZiB0aGUgcmVkaXJlY3Qgc291cmNlIG9yIHJlZGlyZWN0IHNp bmsgTEZCIG9uDQo+ID4gPiA+IHRoZSBGRQ0KPiA+ID4gPiA+IGFzc29jaWF0ZWQgd2l0aCB0aGlz IHBhY2tldA0KPiA+ID4gPiA+IG8gYW4gaW5kZXggd2l0aGluIHRoYXQgTEZCIHRvIGlkZW50aWZ5 IGNvbmZpZ3VyZWQgcHJvcGVydGllcyBvZiB0aGUgDQo+ID4gcGFja2V0Lg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gVGhlIG1ldGEtZGF0YSBUTFYgY29udGFpbnMgZHluYW1pYyBpbmZvcm1hdGlvbiBu ZWVkZWQgYnkgdGhlIEZFIG9yIA0KPiA+IENFIHRvDQo+ID4gPiA+ID4gcHJvY2VzcyB0aGUgcGFj a2V0LiAgVGhpcyB3aWxsIG5lZWQgdG8gYmUgc3BlbGxlZCBvdXQgaW4gbW9yZSANCj4gPiBkZXRh aWwuICBJdA0KPiA+ID4gPiA+IG1heSBuZWVkIHRvIHVzZSBwYXRoIGVuY29kaW5nLg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gRm9sbG93aW5nIHRoaXMgd2lsbCBiZSB0aGUgcGFja2V0Lg0KPiA+ID4g PiA+DQo+ID4gPiA+ID4gWW91cnMsDQo+ID4gPiA+ID4gSm9lbA0KPiA+ID4NCg== ------=_NextPart_000_0724_01C58983.BD8A0F70 Content-Type: text/plain; name="PacketRedirectMsgUpdate.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="PacketRedirectMsgUpdate.txt" =20 Message Body: Consists of one or more TLVs, with every TLV having the following data format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D Redirect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirect Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25 =20 LFB class ID: There are only two possible LFB classes here, the 'RedirectSink' LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from = FE to CE, the LFB class should be 'RedirectSink'. If the message=20 is from CE to FE, the LFB class should be 'RedirectSource'. Instance ID: Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. Meta Data TLV: This is a TLV that specifies meta-data associated with followed=20 redirected data. The TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D META-DATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Meta Data ILV: This is an Identifier-Length-Value format that is used to=20 describe one meta data. The ILV has the format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data Value | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Where, Meta Data ID is an identifier for the meta data, which is usually defined by FE-Model[FE-MODEL]. =20 Usually there are two meta data that are necessary for CE-FE = redirect=20 operation. One is the redirected data type (e.g., IP packet, TCP = packet,=20 or UDP Packet). For an FE->CE redirect operation, redirected packet = type=20 meta data is usually a meta data specified by a Classifier LFB that filter out redirected packets from packet stream and sends the = packets to Redirect Sink LFB. For an CE->FE redirect operation, the redirected = packet=20 type meta data is usually directly generated by CE.=20 =20 Another meta data that should be associated with redirected data is=20 the port number in a redirect LFB. For a RedirectSink LFB, the port=20 number meta data tells CE from which port in the lFB the redirected=20 data come. For a RedriectSource LFB, via the meta data, CE tells FE=20 which port in the LFB the redirected data should go out.=20 =20 Redirect Data TLV: This is a TLV describing one packet of data to be directed via the redirect operation. The TLV format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D REDIRECTDATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirected Data |=20 . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = =20 Redirected Data: This field presents the whole packet that is to be redirected.=20 Obviously, the packet should be 32bits aligned. ------=_NextPart_000_0724_01C58983.BD8A0F70-- 2005 Message-Id: Date: Fri, 15 Jul 2005 20:14:03 +0800 From: "Wang,Weiming" Subject: Re: Result TLV Comments: To: "Khosravi, Hormuzd M" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SG9ybXV6ZCwNCg0KSSBoaWdobHkgc3VnZ2VzdCB0byBzZXBhcmF0ZSB0aGUgT3BlcmF0aW9uIFRM ViBmaWd1cmUgZnJvbSB0aGUgd2hvbGUgTEZCIHNlbGVjdCBUTFYgZmlndXJlIGluIHRoZSBjb25m aWcgbWVzc2FnZSwgbGlrZSB3aGF0IHNob3duIGluIHRoZSBRZXVyeSBtZXNzYWdlLiAgVGhlIHJl YXNvbiBpcywgd2l0aCB0aGUgZm9sbG93aW5nIGZpZ3VyZSBzaG93biwgaXQgbWF5IGJlIGVhc2ls eSBsZWFkIHRvIGFuIGFtYmlndWl0eSB0aGF0IHRoZSBPcGVyYXRpb24gVExWIGlzIHBhcmFsbGVs IHdpdGggTEZCc2VsZWN0IFRMViByYXRoZXIgdGhhbiBiZWluZyBhIG5lc3RlZCBUTFYuDQoNClRo aXMgYWxzbyBzYXZlcyBzb21lIHNwYWNlLCBmb3IgeW91IG90aGVyd2lzZSBuZWVkIHRvIGR1cGxp Y2F0ZXMgdGhlIHRleHQsIGFuZCBpdCBhbHNvIG1ha2VzIHRoZSB0ZXh0IG1vcmUgY29uc2lzdGVu dCB3aXRoIG90aGVyIG1lc3NhZ2VzIGluIGxvb2suDQoNClRoYW5rcywNCldlaW1pbmcNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJLaG9zcmF2aSwgSG9ybXV6ZCBNIiA8 aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbT4NClRvOiA8Rk9SQ0VTQFBFQUNILkVBU0UuTFNP RlQuQ09NPg0KU2VudDogVGh1cnNkYXksIEp1bHkgMTQsIDIwMDUgMTI6NTggUE0NClN1YmplY3Q6 IFJlOiBSZXN1bHQgVExWDQoNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiwgSm9lbCEg VGhhdCdzIGNvbXBsZXRlbHkgZmluZSB3aXRoIG1lLg0KU28gaXQgbG9va3MgbGlrZS4uLi4NCg0K ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICBUeXBlID0gTEZCIHNlbGVjdCAgICAgIHwgICAg ICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIEluc3Rh bmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAg IE9wZXJhdGlvbnMgKFNFVC1SRVNQKSAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAg ICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgIFBhdGgtZGF0 YSBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIFJlc3VsdCBUTFYgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg ICB8ICAgIE9wZXJhdGlvbnMgKERFTC1SRVNQKSAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGgg ICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgIFBh dGgtZGF0YSBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIFJlc3VsdCBUTFYg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KDQpUaGlzIGlzIG1vcmUgZ3JhbnVsYXIgYW5kIG1ha2VzIHNlbnNlIHRvIG1lICh3aGF0IEkg d291bGQgaGF2ZSBleHBlY3RlZA0KdG8gc2VlIGluIHRoZSByZXNwb25zZSkuIFRoZXJlZm9yZSBJ IGFza2VkIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBiZWxvdy4NCg0KUmVnYXJkcw0KSG9ybXV6ZA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWls dG86am9lbEBzdGV2ZWNyb2NrZXIuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMywgMjAw NSAxMjozNCBQTQ0KVG86IEtob3NyYXZpLCBIb3JtdXpkIE07IEZPUkNFU0BQRUFDSC5FQVNFLkxT T0ZULkNPTQ0KU3ViamVjdDogUkU6IFtGT1JDRVNdIFJlc3VsdCBUTFYNCg0KSSB3b3VsZCBleHBl Y3QgdGhlcmUgdG8gYmUgcGF0aC1kYXRhIGF0IGxlYXN0IHNvbWUgb2YgdGhlIHRpbWUuDQpBc3N1 bWluZyBhYmJyZXZpYXRlZCByZXNwb25zZXMgKHdoaWNoIGFyZSBwcm9iYWJseSB0aGUgbm9ybSkg dGhlbiBmb3IgDQpzdWNjZXNzIGl0IG1pZ2h0IHN1ZmZpY2UgdG8ganVzdCBoYXZlIG9uZSBSZXN1 bHQgVExWLCB3aXRoIG5vIHBhdGgtZGF0YS4NCkkgDQpoYWQgbm90IHRob3VnaHQgYWJvdXQgYWxs b3dpbmcgdGhhdC4NCklmIHRoZXJlIGFyZSBlcnJvcnMsIHRoZXJlIG11c3QgYXQgbGVhc3QgYmUg dGhlIHBhdGgtZGF0YSAocG9zc2libHkNCnNldmVyYWwgDQpuZXN0ZWQgcGF0aC1kYXRhIFRMVnMp IHRoYXQgaWRlbnRpZnkgdGhlIHRhcmdldCBvZiB0aGUgb3BlcmF0aW9uIHdoaWNoIA0KZmFpbGVk LCB0byBwcm92aWRlIGNvbnRleHQgZm9yIHRoZSBlcnJvciBjb2RlIGluIHRoZSBSZXN1bHQgVExW Lg0KKFJlbWVtYmVyIA0KdGhhdCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgcGF0aC1kYXRhIGluIHRo ZSByZXF1ZXN0LCBzbyB0aGUgQ0UgbmVlZHMgdG8gDQprbm93IHdoaWNoIHRoaW5nIGZhaWxlZC4u DQpJZiB3ZSBhcmUgaW4gdGhlIHRyeS1hbGwtb3BlcmF0aW9ucyBtb2RlLCB0aGVuIGF0IGxlYXN0 IGVhY2ggb3BlcmF0aW9uIA0Kd2hpY2ggZmFpbGVkIHdpbGwgbmVlZCBpdHMgcGF0aC1kYXRhLg0K DQpBbmQgaWYgd2UgaW5zdGVhZCB1c2UgdmVyYm9zZSByZXNwb25zZXMsIHRoZW4gSSBleHBlY3Qg dGhlIHJlc3BvbnNlIHRvDQpoYXZlIA0KYWxsIHRoZSBwYXRoLWRhdGEgZnJvbSB0aGUgcmVxdWVz dCwgd2l0aCByZXN1bHQgVExWcyBmb3IgZWFjaCBvbmUgDQppbmRpY2F0aW5nIHN1Y2Nlc3Mgb3Ig ZmFpbHVyZS4NCg0KQmFzaWNhbGx5LCBJIGFtIGp1c3QgcHV0dGluZyB0aGUgUmVzdWx0LVRMViBp bnRvIHRoZSBwYXRoLWRhdGEgd2hlcmUgdGhlDQoNCmRhdGEtcmF3IHdvdWxkIGhhdmUgZ29uZS4N Cg0KWW91cnMsDQpKb2VsDQoNCkF0IDEyOjMwIFBNIDcvMTMvMjAwNSwgS2hvc3JhdmksIEhvcm11 emQgTSB3cm90ZToNCj5BZ2FpbiBhIHJlYXNvbmFibGUgYW5kIHNpbXBsZSBhcHByb2FjaCB0byBw cm92aWRlIHRoZSBSZXN1bHRzLg0KPg0KPlRvIHB1dCBzb21lIG1vcmUgY29udGV4dCBhcm91bmQg aXQsIGlzIHRoaXMgaG93IGl0IHdvdWxkIGxvb2sgbGlrZSBpbiBhDQo+Q29uZmlnIFJlc3BvbnNl IG1lc3NhZ2U/DQo+DQo+ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiAgICAgfCAgICAgICAgVHlwZSA9IExGQiBz ZWxlY3QgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCj4gICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KPiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICBMRkIgSW5zdGFuY2UgSUQgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiAgICAgfCAgICBPcGVyYXRpb25zIChTRVQtUkVTUCkgICAgICB8ICAgICAg ICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCj4gICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgIFJlc3VsdCBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KPiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4gICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ICAgICB8ICAgIE9wZXJhdGlvbnMg KERFTC1SRVNQKSAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KPiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCj4gICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgUmVzdWx0IFRMViAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4NCj4NCj5QbHMgZG8gY2xhcmlmeSwgTm8gcGF0aC1kYXRhIHRsdiBpbiB0aGlzIGZvcm1hdD8N Cj4NCj5UaGFua3MNCj5Ib3JtdXpkDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5G cm9tOiBGb3J3YXJkaW5nIGFuZCBDb250cm9sIEVsZW1lbnQgU2VwYXJhdGlvbg0KPlttYWlsdG86 Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJu DQo+U2VudDogVGh1cnNkYXksIEp1bmUgMzAsIDIwMDUgMTI6MDQgUE0NCj5UbzogRk9SQ0VTQFBF QUNILkVBU0UuTFNPRlQuQ09NDQo+U3ViamVjdDogW0ZPUkNFU10gUmVzdWx0IFRMVg0KPg0KPlRo ZSBmb2xsb3dpbmcgaXMgd2hhdCBJIHN1Z2dlc3QgZm9yIGhhbmRsaW5nIHJlc3VsdHMgb2Ygb3Bl cmF0aW9ucy4NCj4NCj5TRVQgYW5kIEdFVCBSZXF1ZXN0cyBkbyBub3QgaGF2ZSByZXN1bHQgaW5m b3JtYXRpb24gKHRoZXkgYXJlDQpyZXF1ZXN0cykuDQo+U0VUIGFuZCBHRVQgUmVzcG9uc2VzIGhh dmUgcmVzdWx0IGluZm9ybWF0aW9uLg0KPlNFVCBhbmQgR0VUIFJlc3BvbnNlcyB1c2UgU0VULVJF U1BPTlNFIGFuZCBHRVQtUkVTUE9OU0Ugb3BlcmF0aW9uIFRMVnMuDQo+DQo+Rm9yIGEgR0VUIHJl c3BvbnNlcywgaW5kaXZpZHVhbCBnZXRzIHdoaWNoIHN1Y2NlZWQgd2lsbCBoYXZlIERBVEFSQVcN Cj5UTFZzDQo+YWRkZWQgdG8gdGhlIGxlYWYgcGF0aHMgdG8gY2FycnkgdGhlIHJlcXVlc3RlZCBk YXRhLiAgRm9yIEdFVCBlbGVtZW50cw0KPnRoYXQNCj5mYWlsLCBpbnN0ZWFkIG9mIHRoZSBEQVRB UkFXIFRMViB0aGVyZSB3aWxsIGJlIGEgUkVTVUxUIFRMVi4NCj4NCj5Gb3IgYSBTRVQgcmVzcG9u c2UsIGVhY2ggREFUQVJBVyBUTFYgaW4gdGhlIG9yaWdpbmFsIHJlcXVlc3Qgd2lsbCBiZQ0KPnJl cGxhY2Ugd2l0aCBhIFJFU1VMVCBUTFYgaW4gdGhlIHJlc3BvbnNlLg0KPklmIHRoZSByZXF1ZXN0 IHdhcyBmb3IgQWNrLWZhaWwsIHRoZW4gb25seSB0aG9zZSBpdGVtcyB3aGljaCBmYWlsZWQNCndp bGwNCj4NCj5hcHBlYXIgaW4gdGhlIHJlc3BvbnNlLiAgSWYgdGhlIHJlcXVlc3Qgd2FzIGZvciBh Y2stYWxsLCB0aGVuIGFsbA0KPmVsZW1lbnRzDQo+b2YgdGhlIHJlcXVlc3Qgd2lsbCBhcHBlYXIg aW4gdGhlIHJlc3BvbnNlIHdpdGggUkVTVUxUIFRMVnMuDQo+DQo+QSBSRVNVTFQgVExWIGNvbnRh aW5zIGEgaW50ZWdlciAocHJvYmFibHkgNCBieXRlcywgYnV0IHdlIG9ubHkgbmVlZCAxDQo+Ynl0 ZSkNCj52YWx1ZS4NCj5UaGUgZGVmaW5lZCB2YWx1ZXMgYXJlDQo+ICAgIDAgPSBzdWNjZXNzDQo+ ICAgIDEgPSBubyBzdWNoIG9iamVjdA0KPiAgICAyID0gcGVybWlzc2lvbiBkZW5pZWQNCj4gICAg MyA9IGludmFsaWQgdmFsdWUgKHRoZSBkYXRhcmF3IGNvdWxkIG5vdCB2YWxpZGx5IGJlIHN0b3Jl ZCBpbiB0aGUNCj5maWVsZCkNCj4gICAgNCA9IGludmFsaWQgYXJyYXkgY3JlYXRpb24gKHdoZW4g dGhlIHN1YnNjcmlwdCBpbiBhbiBhcnJheSBjcmVhdGUNCmlzDQo+bm90DQo+YWxsb3dlZCkNCj4g ICAyNTUgPSB1bnNwZWNpZmllZCBlcnJvciAoZm9yIHdoZW4gdGhlIEZFIGNhbiBub3QgZGVjaWRl IHdoYXQgd2VudA0KPndyb25nKQ0KPg0KPldlIG1heSBuZWVkIGEgZmV3IG1vcmUgdmFsdWVzIHRv IGNvdmVyIG90aGVyIGVycm9ycy4NCj5Ob3RlIHRoYXQgaWYgYSBTRVQgcmVxdWVzdCB3aXRoIGEg c3RydWN0dXJlIGluIGEgREFUQVJBVyBpcyBpc3N1ZWQsIGFuZA0KPnNvbWUgZmllbGQgaW4gdGhl IHN0cnVjdHVyZSBpcyBpbnZhbGlkLCB0aGUgRkUgd2lsbCBub3QgYXR0ZW1wdCB0bw0KPmluZGlj YXRlDQo+d2hpY2ggZmllbGQgd2FzIGludmFsaWQsIGJ1dCByYXRoZXIgd2lsbCBpbmRpY2F0ZSB0 aGF0IHRoZSBvcGVyYXRpb24NCj5mYWlsZWQuDQo+Tm90ZSBmdXJ0aGVyIHRoYXQgaWYgdGhlcmUg YXJlIG11bHRpcGxlIGVycm9ycyBpbiBhIHNpbmdsZSBsZWFmDQo+cGF0aC1kYXRhIC8NCj5EQVRB UkFXLCB0aGUgRkUgY2FuIHNlbGVjdCB3aGljaCBlcnJvciBpdCBjaG9vc2VzIHRvIHJldHVybi4g IFNvIGlmIGENCj5EQVRBUkFXIGZvciBhIFNFVCBvZiBhIHN0cnVjdHVyZSBhdHRlbXB0cyB0byB3 cml0ZSBvbmUgZmllbGQgd2hpY2ggaXMNCj5yZWFkDQo+b25seSwgYW5kIGF0dGVtcHRzIHRvIHNl dCBhbm90aGVyIGZpZWxkIHRvIGFuIGludmFsaWQgdmFsdWUsIHRoZSBGRSBjYW4NCj5yZXR1cm4g d2hhdGV2ZXIgZXJyb3IgaXQgbGlrZXMuDQo+DQo+WW91cnMsDQo+Sm9lbCBNLiBIYWxwZXJuDQo= 2005 Message-Id: Date: Fri, 15 Jul 2005 16:29:10 +0200 From: Robert Haas Subject: Re: [issue55] Execution text replacement Comments: To: Alistair Munro MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alistair, > The FE may have valid next-hop and prefix tables for 10000's of routes=20 > and hundred of interfaces. Given an arbitrary disconnect between the=20 > CE and FE, what should we do to reconcile any differences? So let's see first what we should do in a simple case: the association=20 breaks while there is NO transaction underway. The FE had 250k routes=20 stored. When the association is reestablished, the CE MUST either: - delete all the routes in the FE, and set the new routes. - get all routes in the FE and modify/delete/add routes as necessary Or do you propose something else ? Joel says that the CE should reload=20 the entire FE state (by doing either of the two above). Regards, -Robert --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Fri, 15 Jul 2005 14:33:33 +0200 From: Robert Haas Subject: Re: New model DRAFT Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Joel, Great work ! I tried to read the whole draft in one shot to detect=20 discrepancies and so on. Here is a first list of specific comments. Regards, -Robert [Editorial] Sec 3.1 FE Capability Model and State Model: The FE capability and the FE state are both represented by two levels.=20 The text says this only for the FE State model ? [Technical] Sec 3.3.2 Configuring the LFB Topology Note that LFB topology constraints are also expressed by the Packet=20 Types on ports (output-input matching) and required metadata (an LFB may=20 require certain metadata, hence an upstream LFB must produce it). [Technical] Sec 4.7.4 Element to Define LFB Operational Attributes =93While the capabilities will frequently indicate this non-existence, CE= s=20 may attempt to reference non-existent or non-permitted attributes=20 anyway. The FORCES protocol mechanisms should include appropriate error=20 indicators for this case=94. This is still missing in the protocol. We need special Result-TLV codes=20 for this. [Technical] Sec 4.7.5 Element to Define LFB Capability=20 Attributes In the example (copied below), nothing except the synopsis relates=20 limitBar to the bar attribute. I'd like to have sth so that the machine=20 can figure out from the LFB what is the maximum size of some the LFB=20 arrays (forwarding table, etc). So we would need sth comparable to the=20 events semantics (i.e., greater, lower, etc), and a field that maps the=20 capability to its element (if applicable). limitBar Maximum value of the "bar" attribute. uint16 [Editorial] Sec 4.7.6: incomplete sentence end of 2nd paragraph =93In a derived LFB (i.e. one=20 with a element) the baseID must not.=94 [Technical] 4.8 LFB Properties This is still missing in the protocol. We need special Result-TLV codes=20 to signal that the writing of a property element failed. [Editorial] (check in the entire document) typo OctetSting, or octetstring. [Technical] Sec 5.5. FE Attributes and Capabilities In the of the FEObject (copied below), LFBTopology is the=20 current topology of LFBs in the FE, but the synopsis says :the table of=20 known Topologies" ? If the FE has a list of allowed "fixed" working topologies, shouldn't=20 this be a field in the , i.e., an array of arrays ? Core LFB: FE Object 1.0 LFBTopology the table of known Topologies LFBLinkType [Technical] Sec 7.7. Using the FE model in the ForCES Protocol "Among the seven types of payload information the ForCES protocol=20 carries between CEs and FEs, the FE model covers all of them except item=20 1), which concerns the inter-FE topology. The FE model focuses on the=20 LFB and LFB topology within a single FE. Since the information related=20 to item 1) requires global knowledge about all of the FEs and their=20 inter-connection with each other, this exchange is part of the ForCES=20 base protocol instead of the FE model." I think that as the FEObject has an array of FEConfiguredNeighborType,=20 exchange (1) to dicsover the inter-FE topology consists simply of=20 reading this LFB attribute. So I would not say that (1) is "part of the=20 ForCES base protocol instead of the FE model." . Also check in Fig. 9. [Technical] Sec 7.2.7.2 FE Capability Declarations " FEs will have many types of limitations. Some of the limitations must=20 be expressed to the CEs as part of the capability model. The CEs must be=20 able to query these capabilities on a per-FE basis. Examples: Metadata=20 passing capabilities of the FE. Understanding these capabilities will=20 help the CE to evaluate the feasibility of LFB topologies, and hence to=20 determine the availability of certain services." I think that metadata is sth LFB-specific and does not belong to the FE=20 capabilities. The FEObject does not have any attribute about this. [Technical] 7.4 LFB Capability Declarations "Also, the LFB class definitions will probably contain very few=20 quantitative limits (e.g., size of tables), since these limits are=20 typically imposed by the implementation. Therefore, quantitative=20 limitations should always be expressed by capability arguments." Although both capabilities now defined for the FEObject are optional, I=20 expect that we will have LFB classes with capabilities that are=20 mandatory to define: for instance, the maximum routing table size should=20 be a capability that every vendor must specify. [Technical] Sec 7.6.7.6 LFB Attribute Manipulation "(Editor's note: It remains an open issue as to whether or not other=20 methods are needed in addition to "get attribute" and "set attribute"=20 (such as multi-attribute transactions). If the answer to that question=20 is yes, it is not clear whether such methods should be supported by the=20 FE model itself or the ForCES protocol.)" Multi-attribute setting or getting is in fact allowed by the protocol.=20 If the FE has a problem with it, it will return an error (for instance,=20 two attributes that are set to mutually incompatible values) [Technical] Sec 8.3 Capabilities "The capability information for this LFB includes whether the underlying=20 interface is operational". The example XML is: OperationalState whther the port over all is operational PortStatusValues I doubt that interface state should belong to the capabilities. It is an=20 attribute, no ? Joel M. Halpern wrote: > I have completed an editing pass on the model document. > I have added aliases, properties, and events. > I have added an example to try to explain how some of this works. > > Jamal has very helpfully posted the draft at: > ftp://ftp.znyx.com/users/hadi/private/forces/ > > Note, this is the word document. It has change tracking turned on, so=20 > you should easily be able to tell what I did. > Ellen will be working this document over when she gets back from=20 > vacation, and we will submit that to the I-D respository. > > The XML Schema passes XMLSpy's validity test. The two LFBs validate=20 > against that schema. > I believe the example is indented badly. Sorry. I can not get word to=20 > cooperate on it. > > One note on the Schema. I do not have the tools to usefully validate=20 > the Key / KeyRef declarations. And while my tool uses them, I think it=20 > uses them wrong because I get mysterious errors. If someone who=20 > understands Key / KeyRef could look at them, I am happy to fix them up. > > I am sure there are many other errors. > And probably places that need clarification even if they are not wrong. > > Please, Please, Please read the draft. Send comments. > > Yours, > Joel M. Halpern > > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Fri, 15 Jul 2005 10:02:48 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: "Wang,Weiming" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This looks good to me. My only quibble (minor difference) is with the description that the identifier portion of the meta-data ILV is assigned by the model. We have not worked this out, but I think that the identifiers are probably going to end up assigned by the CE. (The implication of this is that if one CE takes over for another, it may have to do some analysis to get the meanings for the meta-data identifiers. But it should be simple to find the LFBs where the meta-data is created, and determine what ID is configured to be used for it. And this needs to be described somewhere in either the model or the protocol document. I think it will go in the meta-data portion of the model draft.) Yours, Joel At 09:25 AM 7/15/2005, Wang,Weiming wrote: >Hi all, > >I tried to compose a text for the update of the redirect message part in >the attachment, based on our current discussions . Pls send coments on. > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Sent: Thursday, July 07, 2005 10:38 AM >Subject: Re: [issue32] Packet Redirect > > > > There is a whole section on meta-data in the model document. > > I would expect most meta-data fields to be 32 bits. > > The CE can choose to use a meta-data classifier and multiple meta-data > > fields in order to steer the packet to the right LFB. And the CE will > know > > what meta-data field the LFB will use for selecting among its ports. > > > > > > This relates to a larger question for the list... > > We NEED an LFB library. > > Please! > > To do this, we need folks to actually write definitions of LFBs. > > (I think we have an editor who is likely to be willing to pull things > > together. At least I hope so.) > > There are a lot of LFBs that need writing. > > If this WG doesn't start producing them, it won't happen. > > > > > > To get back to your question Weiming, given a set of LFB definitions and > > the meta-data they use, I can better specify what the CE will send / > > receive. But in an abstract sense, since it will be information flowing > > between the redirect LFB and the eventual interface LFB, the way the model > > prescribes to carry that information is as meta-data. This is the same > > meta-data that will need, for example, to come out of longest-prefix-match > > and next-hop resolution LFBs. After all, they need to be able to direct > > packets to be shipped out specific interfaces, with specific headers, etc. > > > > Yours, > > Joel > > > > At 10:27 PM 7/6/2005, Wang,Weiming wrote: > > >A very simple question then, how many bits we then can assign to the > > >meta-data like the port number ? > > > > > >thanks, > > >weiming > > > > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >To: "Weiming Wang" ; > > >Sent: Thursday, July 07, 2005 4:09 AM > > >Subject: Re: [issue32] Packet Redirect > > > > > > > > > > After some discussion, the operational data may be simpler than I > had been > > > > thinking. > > > > We can simply attach (in some reasonable TLV format) all the meta-data. > > > > So packets from the CE come with meta-data, and the CE gets all the > > > > meta-data from the FE associated with a packet. > > > > That ensures that all the necessary information is available, without > > > > making the redirect LFBs complex. > > > > > > > > Yours, > > > > Joel > > > > > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > > > >Joel, > > > > > > > > > >I tend to agree with your idea below except the index. Could you give > > > > >more details on its necessity? Thanks. > > > > >As a result, the agreeable format to me seems like: > > > > > > > > > >Redirect TLV, whith contains > > > > > LFB class ID > > > > > LFB instance ID > > > > > operation TLV (REPORT), which contains Path-Data > > > > > Packet TLV > > > > > > > > > >We further define that that Path-Data should supply enough > information > > > for > > > > >the followed packet. At least it should include information about the > > > port > > > > >number the redirect packet is input(sink LFB) or is output (source > LFB), > > > > >and the redirect packet type. How this is defined is left to model > where > > > > >redirect LFBs and the attributes are defined. > > > > > > > > > >We need to solve this a little sooner. > > > > > > > > > >thoughts? > > > > > > > > > >Thanks, > > > > >Weiming > > > > > > > > > >----- Original Message ----- > > > > >From: "Joel M. Halpern" > > > > >Subject: Redirect Message > > > > > > > > > > > > > > > > Based on discussion, and based on my earlier message that specific > > > > > protocol > > > > > > messages may have different top level TLVs, here is a description > > > of the > > > > > > contents of a redirect message. > > > > > > > > > > > > A redirect message will contain a redirect TLV. > > > > > > A redirect TLV consists of three fixed fields, and meta-data TLV, > > > and the > > > > > > packet. > > > > > > The fixed fields are > > > > > > o the LFB Class ID of the redirect source or redirect sink LFB on > > > the FE > > > > > > associated with this packet > > > > > > o the LFB Instance ID of the redirect source or redirect sink > LFB on > > > > > the FE > > > > > > associated with this packet > > > > > > o an index within that LFB to identify configured properties of > the > > > packet. > > > > > > > > > > > > The meta-data TLV contains dynamic information needed by the FE or > > > CE to > > > > > > process the packet. This will need to be spelled out in more > > > detail. It > > > > > > may need to use path encoding. > > > > > > > > > > > > Following this will be the packet. > > > > > > > > > > > > Yours, > > > > > > Joel > > > > 2005 Message-Id: Date: Thu, 14 Jul 2005 23:25:29 +0100 From: Alistair Munro Subject: Re: [issue55] Execution text replacement Comments: To: Robert Haas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Robert, Thank you for your response. Apologies for a long reply, which may not make much sense... > Although the FE can remember what its configuration is between two > associations, the CE cannot make any assumption about this. So the CE > must check the configuration state of any newly associated FE. I would like some time to think about this, but I am sure we have gone through the thought processes before and please remind me of the outcome if I'm repeating the obvious. The FE may have valid next-hop and prefix tables for 10000's of routes and hundred of interfaces. Given an arbitrary disconnect between the CE and FE, what should we do to reconcile any differences? Probably transactional recovery is not enough but it might be the best case for brief interruptions. A newly associated FE (a blade I just plugged in for example) might have no state. But it has no transactions to recover. >> >>> Let me separate the question into two parts. >>> The first part, which we discussed on the call, is what happens to >>> pending transactions that have not been fully committed when the FE >>> loses >>> association with the CE. In my opinion, no matter what the reason for >>> the lose of association, such transactions MUST be unwound. >> >> >> We could go for finer granularity but that just makes recovery a real >> pain. Let's go for this simple level of rollback. Do we also say that >> it is the CE that is the recovery master? Can the FE initiate the >> rollback/recovery? > > I agree that the FE MUST rollback by itself any unfinished transactions > whenever the association is lost. > But what about this case: if the DONE-ACK (message from FE to CE to > signal that the FE has completed the transaction) is lost due to > association breakdown, the FE won't rollback anything (it just can't know > that the DONE-ACK message did not make it to the CE). But from the CE > viewpoint, it is unclear whether the transaction was completed. I didn't mean that the FE could autonomously roll transactions back. Recovery processes have a master and the assumption of shared state is the worst-case knowledge of the master - I'm assuming this is the CE but am I wrong? If the CE is the master then all the FE can do is tell it that it has uncommitted transaction IDs (no commit request received), or committed transaction IDs (either acknowledged - it did them, or unacknowledged - it doesn't know). If the FE sent DONE-ACKs then it knows what it did - but if the CE has no recollection of receiving the DONE-ACK then, in principle, it doesn't know what happened. In that case we should go for presumed-abort, rolling back to the last confirmed transaction. But this will sometimes be inconsistent with recently received routing table/adjacency updates. To avoid doubt, I'm confident that the protocol is good. It is the actions that may need to be examined. We should possibly aim to give estimates of uncertainty? Apart from this, I agree with what you say, but this is the usual situation with transactional protocols - the certainty is only the last confirmed action that was executed. By way of an opinion on how I think it works, I believe the protocol gives rollback responsibility to the CE. The FE can go for presumed abort, i.e. it notifies the CE of incomplete transactions and undoes them if the CE knows it received confirmation of them having been done (even if the FE did them). Recoveries are usually acknowledged so this should be safe even if the association fails during the recovery - as it tends to do. As noted above, I thought the handshaking was OK so far, but I'll check again. > > As the association is reestablished, the CE will have to figure out what > happened to that last transaction. Two ways of doing this: > - fetch all necessary FE state and double-check, or > - introduce an attribute in the FE Protocol LFB that indicates the ID of > the last completed transaction (from the FE viewpoint). The CE will read > this attribute as the association is reestablished. > > What do you think ? You are starting to define a more complex recovery protocol. I think we must minimise the complexity but I have to admit I don't know how right now. >> >> This suggests an ordered world out there. Maybe the heartbeat takes >> care of most disasters, but it could fail too. The recovery model >> should provide for a failure where the loss of association is not >> guaranteed to be reported. >> > Then I don't follow you: by definition, as association goes down either > because heartbeats are not received for a period of time, or the teardown > procedure was followed. The FSM does not consider any other event as a > cause to bring the association down. Yes, this is what has been defined but the definition is possibly too optimistic. Busy CEs may not deliver heartbeats. My position is that there is *no* certainty in this kind of system, only minimising the extent and duration of inconsistency. It's not a flaw in the concept but maybe it is a guideline for users about how much they can load their CEs? If you got this far, thanks for reading this long and probably confusing message! Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com 2005 Message-Id: Date: Thu, 14 Jul 2005 16:54:47 -0400 From: "Joel M. Halpern" Subject: Re: [issue55] Execution text replacement Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Given that the CE has no way to know what may have happened to the FE since they were last talking, the CE should always reload the FE state when an association is established by talking to the FE. Yours, Joel At 09:51 AM 7/14/2005, you wrote: >I agree that the FE MUST rollback by itself any unfinished transactions >whenever the association is lost. >But what about this case: if the DONE-ACK (message from FE to CE to signal >that the FE has completed the transaction) is lost due to association >breakdown, the FE won't rollback anything (it just can't know that the >DONE-ACK message did not make it to the CE). But from the CE viewpoint, it >is unclear whether the transaction was completed. > >As the association is reestablished, the CE will have to figure out what >happened to that last transaction. Two ways of doing this: >- fetch all necessary FE state and double-check, or >- introduce an attribute in the FE Protocol LFB that indicates the ID of >the last completed transaction (from the FE viewpoint). The CE will read >this attribute as the association is reestablished. > >What do you think ? 2005 Message-Id: Date: Thu, 14 Jul 2005 15:51:50 +0200 From: Robert Haas Subject: Re: [issue55] Execution text replacement Comments: To: Alistair Munro MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alistair Munro wrote: > Hi All, > > Now that we are back on transactionality again... > >> I disagree with the last part. >> The FE clearly can remember if it has been reset or not. > > > Yes, and if not reset then it can remember what its configuration is. Although the FE can remember what its configuration is between two=20 associations, the CE cannot make any assumption about this. So the CE=20 must check the configuration state of any newly associated FE. > >> Let me separate the question into two parts. >> The first part, which we discussed on the call, is what happens to >> pending transactions that have not been fully committed when the FE=20 >> loses >> association with the CE. In my opinion, no matter what the reason for >> the lose of association, such transactions MUST be unwound. > > > We could go for finer granularity but that just makes recovery a real=20 > pain. Let's go for this simple level of rollback. Do we also say that=20 > it is the CE that is the recovery master? Can the FE initiate the=20 > rollback/recovery? I agree that the FE MUST rollback by itself any unfinished transactions=20 whenever the association is lost. But what about this case: if the DONE-ACK (message from FE to CE to=20 signal that the FE has completed the transaction) is lost due to=20 association breakdown, the FE won't rollback anything (it just can't=20 know that the DONE-ACK message did not make it to the CE). But from the=20 CE viewpoint, it is unclear whether the transaction was completed. As the association is reestablished, the CE will have to figure out what=20 happened to that last transaction. Two ways of doing this: - fetch all necessary FE state and double-check, or - introduce an attribute in the FE Protocol LFB that indicates the ID of=20 the last completed transaction (from the FE viewpoint). The CE will read=20 this attribute as the association is reestablished. What do you think ? > > I agree with the rest of Joel's comments; furthermore, Robert wrote: > >>> Associations may be taken down either due to heartbeat timeout, or an >>> explicit teardown message. >> > > This suggests an ordered world out there. Maybe the heartbeat takes=20 > care of most disasters, but it could fail too. The recovery model=20 > should provide for a failure where the loss of association is not=20 > guaranteed to be reported. > Then I don't follow you: by definition, as association goes down either=20 because heartbeats are not received for a period of time, or the=20 teardown procedure was followed. The FSM does not consider any other=20 event as a cause to bring the association down. Regards, -Robert > Regards, > > Alistair > > --=20 > Alistair Munro, > Principal Engineer, U4EA Technologies Ltd. > City Point, Temple Gate, Bristol, BS1 6PL, U.K. > E-mail: Alistair.Munro@u4eatech.com > Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) > +44-7974-922-442; > Fax: +44-117-373-6751 > Web: http://www.u4eatech.com > > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Thu, 14 Jul 2005 13:36:11 +0200 From: Robert Haas Subject: Re: [issue55] Execution text replacement Comments: cc: tracker-forces@mip4.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is some text to resolve the issue wrt "fast recovery" of pending transactions across association tear-down and reestablishment. Please comment. Associations may be taken down either due to heartbeat timeout, or an explicit teardown message. The first question is: what do we do with all the state in the FE after the association is down ? 1) if it is due to a heartbeat timeout, then the "CE failover and restart policy" attribute in the FE Protocol LFB indicates if the FE should continue operation even though the CE is gone. 2) if the association was taken down explicitely with a teardown message, then we can assume that operation of the FE must be stopped. OK ? The next question is: what do we do with all the "old" FE state when the association is reestablished ? 1) if the association was taken down explicitely, then all the "old" state in the FE is gone. The CE must restore all necessary state. OK ? 2) if the association timed out, then unless the FE Protocol LFB keeps a state that indicates how the last association went down, the FE cannot remember if association was lost due to timeout or explicit message, hence the same treatment as 1) above is expected. If we agree on the above, then a new association means starting from scratch (all state in the FE must first be restored by the CE) so that no "fast" recovery of a transaction in intermediate state can occur. OK ? So we would have to change the text in section 3.3.1.1.1.3 "Recovery": "When the associations are re-established, the CE will discover a transaction in an intermediate state." and instead say: "Whenever an association is established (whether the association is new or it is recovered from a previous association), the CE MUST NOT expect that any state from the previous association has been kept in the FE." OK ? Regards, -Robert 2005 Message-Id: Date: Thu, 14 Jul 2005 13:31:34 +0100 From: Alistair Munro Subject: Re: [issue55] Execution text replacement Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Now that we are back on transactionality again... > I disagree with the last part. > The FE clearly can remember if it has been reset or not. Yes, and if not reset then it can remember what its configuration is. > Let me separate the question into two parts. > The first part, which we discussed on the call, is what happens to > pending transactions that have not been fully committed when the FE loses > association with the CE. In my opinion, no matter what the reason for > the lose of association, such transactions MUST be unwound. We could go for finer granularity but that just makes recovery a real pain. Let's go for this simple level of rollback. Do we also say that it is the CE that is the recovery master? Can the FE initiate the rollback/recovery? I agree with the rest of Joel's comments; furthermore, Robert wrote: >> Associations may be taken down either due to heartbeat timeout, or an >> explicit teardown message. This suggests an ordered world out there. Maybe the heartbeat takes care of most disasters, but it could fail too. The recovery model should provide for a failure where the loss of association is not guaranteed to be reported. Regards, Alistair -- Alistair Munro, Principal Engineer, U4EA Technologies Ltd. City Point, Temple Gate, Bristol, BS1 6PL, U.K. E-mail: Alistair.Munro@u4eatech.com Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile) +44-7974-922-442; Fax: +44-117-373-6751 Web: http://www.u4eatech.com 2005 Message-Id: Date: Thu, 14 Jul 2005 07:52:10 -0400 From: "Joel M. Halpern" Subject: Re: [issue55] Execution text replacement Comments: To: Robert Haas Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I disagree with the last part. The FE clearly can remember if it has been reset or not. Let me separate the question into two parts. The first part, which we discussed on the call, is what happens to pending transactions that have not been fully committed when the FE loses association with the CE. In my opinion, no matter what the reason for the lose of association, such transactions MUST be unwound. The second part is what state / operation the FE is permitted to retain when it does not have an association. Robert distinguishes three cases: 1) When the FE is switching to the backup CE, 2) When the FE has lost heartbeat with the CE, but does not have a backup, and 3) When the association was explicitly terminated by the CE. Clearly, when switching from primary to secondary CE, the FE should keep its state, and keep forwarding packets according to that state, until the new CE tells it otherwise. The new CE may or may not already have knowledge of that state. Even if it does not have such knowledge, it can read the state from the FE. So, the question is what the FE "should" do when it loses association and does not have a backup CE or can not associate with it. My answer is roughly "what ever it wants". There is no reason for the FE to delete its state. After all, we permit FEs with fixed state (or fixed portions of state), so whenever it does associate the CE will need to fetch that state anyway. In terms of practical effect, once the CE is no longer advertising for the FE, after a time the other folks will stop sending it packets. Until routing has expired the information about the FE, it is better for it to keep forwarding packets according to the old table, rather than black-holing them. So for at least 90 seconds, it should keep operating. However, if a particular FE implementation has a reason to clear state and bring down interfaces, that should not be prohibited. Yours, Joel At 07:36 AM 7/14/2005, Robert Haas wrote: >Here is some text to resolve the issue wrt "fast recovery" of pending >transactions across association tear-down and reestablishment. Please comment. > >Associations may be taken down either due to heartbeat timeout, or an >explicit teardown message. > >The first question is: what do we do with all the state in the FE after >the association is down ? >1) if it is due to a heartbeat timeout, then the "CE failover and restart >policy" attribute in the FE Protocol LFB indicates if the FE should >continue operation even though the CE is gone. >2) if the association was taken down explicitely with a teardown message, >then we can assume that operation of the FE must be stopped. OK ? > >The next question is: what do we do with all the "old" FE state when the >association is reestablished ? >1) if the association was taken down explicitely, then all the "old" state >in the FE is gone. The CE must restore all necessary state. OK ? >2) if the association timed out, then unless the FE Protocol LFB keeps a >state that indicates how the last association went down, the FE cannot >remember if association was lost due to timeout or explicit message, hence >the same treatment as 1) above is expected. > >If we agree on the above, then a new association means starting from >scratch (all state in the FE must first be restored by the CE) so that no >"fast" recovery of a transaction in intermediate state can occur. > >OK ? > >So we would have to change the text in section 3.3.1.1.1.3 "Recovery": >"When the associations are re-established, the CE will discover a >transaction in an intermediate state." and instead say: "Whenever an >association is established (whether the association is new or it is >recovered from a previous association), the CE MUST NOT expect that any >state from the previous association has been kept in the FE." > >OK ? > >Regards, >-Robert 2005 Message-Id: Date: Wed, 13 Jul 2005 21:58:30 -0700 From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the clarification, Joel! That's completely fine with me. So it looks like.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path-data TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is more granular and makes sense to me (what I would have expected to see in the response). Therefore I asked for the clarification below. Regards Hormuzd -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com]=20 Sent: Wednesday, July 13, 2005 12:34 PM To: Khosravi, Hormuzd M; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] Result TLV I would expect there to be path-data at least some of the time. Assuming abbreviated responses (which are probably the norm) then for=20 success it might suffice to just have one Result TLV, with no path-data. I=20 had not thought about allowing that. If there are errors, there must at least be the path-data (possibly several=20 nested path-data TLVs) that identify the target of the operation which=20 failed, to provide context for the error code in the Result TLV. (Remember=20 that there can be multiple path-data in the request, so the CE needs to=20 know which thing failed.. If we are in the try-all-operations mode, then at least each operation=20 which failed will need its path-data. And if we instead use verbose responses, then I expect the response to have=20 all the path-data from the request, with result TLVs for each one=20 indicating success or failure. Basically, I am just putting the Result-TLV into the path-data where the data-raw would have gone. Yours, Joel At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: >Again a reasonable and simple approach to provide the Results. > >To put some more context around it, is this how it would look like in a >Config Response message? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D LFB select | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Pls do clarify, No path-data tlv in this format? > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, June 30, 2005 12:04 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Result TLV > >The following is what I suggest for handling results of operations. > >SET and GET Requests do not have result information (they are requests). >SET and GET Responses have result information. >SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. > >For a GET responses, individual gets which succeed will have DATARAW >TLVs >added to the leaf paths to carry the requested data. For GET elements >that >fail, instead of the DATARAW TLV there will be a RESULT TLV. > >For a SET response, each DATARAW TLV in the original request will be >replace with a RESULT TLV in the response. >If the request was for Ack-fail, then only those items which failed will > >appear in the response. If the request was for ack-all, then all >elements >of the request will appear in the response with RESULT TLVs. > >A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >byte) >value. >The defined values are > 0 =3D success > 1 =3D no such object > 2 =3D permission denied > 3 =3D invalid value (the dataraw could not validly be stored in the >field) > 4 =3D invalid array creation (when the subscript in an array create is >not >allowed) > 255 =3D unspecified error (for when the FE can not decide what went >wrong) > >We may need a few more values to cover other errors. >Note that if a SET request with a structure in a DATARAW is issued, and >some field in the structure is invalid, the FE will not attempt to >indicate >which field was invalid, but rather will indicate that the operation >failed. >Note further that if there are multiple errors in a single leaf >path-data / >DATARAW, the FE can select which error it chooses to return. So if a >DATARAW for a SET of a structure attempts to write one field which is >read >only, and attempts to set another field to an invalid value, the FE can >return whatever error it likes. > >Yours, >Joel M. Halpern 2005 Message-Id: Date: Wed, 13 Jul 2005 17:46:17 +0200 From: Robert Haas Subject: Re: [issue52] Association Setup Response Message: unclear use of SHOW Comments: cc: tracker-forces@mip4.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Here is how we should resolve this issue. I provided new text below. One=20 last thing is what happens to the Result field in the Association Setup=20 Response message (I'll open another tracker issue for that one and other=20 results in general). The Association Setup message (from FE to CE) may contain unsolicited=20 GET-RESPONSE operations. The reason is to let the FE declare what its=20 configuration paramaters are. The Association Setup Response message (from CE to FE) may contain SET=20 operations. The reason is to let the CE modifiy, for instance, the=20 configuration parameters that the FE declared. Only the FE Protocol LFB and the FE LFB may be targeted in the=20 Association Setup messages, as the CE must first find out what are the=20 available LFBs. Proposed new text (changes highlighted with ">"): 6.4.1 Association Setup Message This message is sent by the FE to the CE to setup a ForCES association between them. This message could also be used by CEs to join a ForCES NE, however CE-to-CE communication is not covered by this protocol. Message transfer direction: FE to CE Message Header: The Message Type in the header is set MessageType=3D 'Association Setup'. The ACK flag in the header is ignored, because the setup message will always expect to get a response from the message receiver (CE) whether the setup is successful or not. The Src ID (FE ID) may be set to O in the header which means that the FE would like the CE to assign a FE ID for the FE in the setup response message. Message body: > The LFB selection may point to the FE Object and/or FE Protocol L= FBs > and more than one attribute may be announced in this message using > GET-REPONSE to let the FE declare its configuration parameters in > an unsolicited manner. The layout is: main hdr (eg type =3D Association setup) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D FE object | | | | | +-- LFBInstance =3D 0x1 | | > | +--- T =3D Operation =3D GET-RESPONSE | | | +-- Path-data to one or more attibutes | including FE NAME +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol object | | +-- LFBInstance =3D 0x1 | > +--- T =3D Operation =3D GET-RESPONSE | +-- Path-data to one or more attibutes including suggested HB parameters 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation GET-REPONSE | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Attributes path and data ~ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Protocol Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation GET-REPONSE | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Attributes path and data ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12 Type (16 bits): LFB Select Length (16 bits): Length of the TLV including the T and L fields, in bytes. FE Object and Protocol LFBs: These contains the FE parameters e.g. HBI will be exchanged with the CE using the FE Protocol LFB. 6.4.2 Association Setup Response Message This message is sent by the CE to the FE in response to the Setup message. It indicates to the FE whether the setup is successful or not, i.e. whether an association is established. Message transfer direction: CE to FE Message Header: The Message Type in the header is set MessageType=3D 'Setup Response'. The ACK flag in the header is always ignored, because the setup response message will never expect to get any more response from the message receiver (FE). The Dst ID in the header will be set to some FE ID value assigned by the CE if the FE had requested that in the setup message (by SrcID =3D 0). Message body: > The LFB selection may point to the FE Object and/or FE Protocol LF= Bs > and more than one attribute may be announced in this message. The lay= out > is: main hdr (eg type =3D Association setup response) | | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D FE object | | | | | +-- LFBInstance =3D 0x1 | | > | +--- T =3D Operation =3D SET | | | +-- Path-data to one or more attibutes | including FE NAME >[line removed] +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol object | | +-- LFBInstance =3D 0x1 | > +--- T =3D Operation =3D SET | +-- Path-data to one or more attibutes eg HB parameters >[line removed] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation SET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Attributes path and data ~ ~ ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID =3D FE Protocol Object | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D operation SET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ ~ Attributes path and data ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 Type (16 bits): LFB Select Length (16 bits): Length of the TLV including the T and L fields, in bytes. FE Object LFB: The FE parameters e.g. HBI may be exchanged using this LFB. Result (16 bits): This indicates whether the setup msg was successful or whether the FE request was rejected by the CE. Robert Haas wrote: >New submission from Robert Haas : > >6.4.2 Association Setup Response Message > > >I don't see why the CE has to SHOW attributes of the FE object/protocol=20 >object. Are we really expecting a RESULT for the SHOW command of the FE-= CE=20 >message ? > >Message from CE to FE: > > main hdr (eg type =3D Association setup response) > | > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D FE object > | | > | | > | +-- LFBInstance =3D 0x1 > | | > | +--- T =3D Operation =3D SHOW > | | > | +-- Path-data to one or more attibutes > | including FE NAME > | May contain RESULT TLVs > +--- T =3D LFBselect > | > +-- LFBCLASSID =3D FE Protocol object > | > | > +-- LFBInstance =3D 0x1 > | > +--- T =3D Operation =3D SHOW > | > +-- Path-data to one or more attibutes > eg HB parameters > May contain RESULT TLVs > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 109 >nosy: rha >priority: Should fix >status: No discussion >title: Association Setup Response Message: unclear use of SHOW > >___________________________________________________ >Forces issue tracker > >___________________________________________________ > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=C3=A4umerstrasse 4 CH-8803 R=C3=BCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Wed, 13 Jul 2005 16:59:17 +0000 From: Robert Haas Subject: [issue57] Inconsistent operation types Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : We need to agree on the operation types (still inconsistent in the draft): for Configuration messages: set, delete, add, update, replace, del-all, cancel (are all these operatio= ns=20 applicable ?) event-subscribe, event-unsubscribe for Configuration-Response messages: the same operations but with *-response (set-reponse, del-response, etc) for Query messages: get for Query-Response messages: get-response for Event-Notification messages: report for Event-Notification-Response messages report-response for Packet-Redirect messages: no operation (currently we have "payload" TLV) Also the draft is inconsistent at many places, for instance, use of SET=20 instead of SET-RESPONSE, etc. ---------- category: Technical draft: draft-ietf-forces-protocol messages: 211 nosy: rha priority: Must fix status: No discussion title: Inconsistent operation types ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Wed, 13 Jul 2005 16:36:36 +0000 From: Robert Haas Subject: [issue56] Result TLV and result codes Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable New submission from Robert Haas : We haven't specified the following results values yet:=20 in the Association Setup Response - add an Association-Result TLV, with specific error codes describing why t= he=20 association setup failed. The defined values are: 0 =3D success 1 =3D FE ID invalid 2 =3D too many associations 3 =3D permission denied on the other hand, if we don't want to give a precise reason for the failur= e,=20 then the RESULT TLV proposed by Joel would be fine. in the Config Response message:=20 - assign a meaning for Operation Result (i.e., all attributes successfully=20 set, some errors, all errors, or what else ?) ---------- category: Technical draft: draft-ietf-forces-protocol messages: 210 nosy: rha priority: Must fix status: No discussion title: Result TLV and result codes ___________________________________________________ Forces issue tracker ___________________________________________________ 2005 Message-Id: Date: Wed, 13 Jul 2005 15:33:47 -0400 From: "Joel M. Halpern" Subject: Re: Result TLV Comments: To: "Khosravi, Hormuzd M" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I would expect there to be path-data at least some of the time. Assuming abbreviated responses (which are probably the norm) then for success it might suffice to just have one Result TLV, with no path-data. I had not thought about allowing that. If there are errors, there must at least be the path-data (possibly several nested path-data TLVs) that identify the target of the operation which failed, to provide context for the error code in the Result TLV. (Remember that there can be multiple path-data in the request, so the CE needs to know which thing failed.. If we are in the try-all-operations mode, then at least each operation which failed will need its path-data. And if we instead use verbose responses, then I expect the response to have all the path-data from the request, with result TLVs for each one indicating success or failure. Basically, I am just putting the Result-TLV into the path-data where the data-raw would have gone. Yours, Joel At 12:30 PM 7/13/2005, Khosravi, Hormuzd M wrote: >Again a reasonable and simple approach to provide the Results. > >To put some more context around it, is this how it would look like in a >Config Response message? > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = LFB select | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (SET-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operations (DEL-RESP) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result TLV | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Pls do clarify, No path-data tlv in this format? > >Thanks >Hormuzd > >-----Original Message----- >From: Forwarding and Control Element Separation >[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern >Sent: Thursday, June 30, 2005 12:04 PM >To: FORCES@PEACH.EASE.LSOFT.COM >Subject: [FORCES] Result TLV > >The following is what I suggest for handling results of operations. > >SET and GET Requests do not have result information (they are requests). >SET and GET Responses have result information. >SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. > >For a GET responses, individual gets which succeed will have DATARAW >TLVs >added to the leaf paths to carry the requested data. For GET elements >that >fail, instead of the DATARAW TLV there will be a RESULT TLV. > >For a SET response, each DATARAW TLV in the original request will be >replace with a RESULT TLV in the response. >If the request was for Ack-fail, then only those items which failed will > >appear in the response. If the request was for ack-all, then all >elements >of the request will appear in the response with RESULT TLVs. > >A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 >byte) >value. >The defined values are > 0 = success > 1 = no such object > 2 = permission denied > 3 = invalid value (the dataraw could not validly be stored in the >field) > 4 = invalid array creation (when the subscript in an array create is >not >allowed) > 255 = unspecified error (for when the FE can not decide what went >wrong) > >We may need a few more values to cover other errors. >Note that if a SET request with a structure in a DATARAW is issued, and >some field in the structure is invalid, the FE will not attempt to >indicate >which field was invalid, but rather will indicate that the operation >failed. >Note further that if there are multiple errors in a single leaf >path-data / >DATARAW, the FE can select which error it chooses to return. So if a >DATARAW for a SET of a structure attempts to write one field which is >read >only, and attempts to set another field to an invalid value, the FE can >return whatever error it likes. > >Yours, >Joel M. Halpern 2005 Message-Id: Date: Wed, 13 Jul 2005 13:08:24 -0400 From: "Joel M. Halpern" Subject: Re: [issue57] Inconsistent operation types Comments: To: Forces issue tracker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed event-subscribe and event-unsubscribe will use Set. We need Set, Get, Set-Response, Get-Response, and notification. I don't think we need add or update operations. I am not sure about delete / del-all. At 12:59 PM 7/13/2005, Robert Haas wrote: >New submission from Robert Haas : > >We need to agree on the operation types (still inconsistent in the draft): > >for Configuration messages: > set, delete, add, update, replace, del-all, cancel (are all these > operations >applicable ?) > event-subscribe, event-unsubscribe > >for Configuration-Response messages: > the same operations but with *-response (set-reponse, del-response, etc) > >for Query messages: > get > >for Query-Response messages: > get-response > >for Event-Notification messages: > report > >for Event-Notification-Response messages > report-response > >for Packet-Redirect messages: > no operation (currently we have "payload" TLV) > >Also the draft is inconsistent at many places, for instance, use of SET >instead of SET-RESPONSE, etc. > >---------- >category: Technical >draft: draft-ietf-forces-protocol >messages: 211 >nosy: rha >priority: Must fix >status: No discussion >title: Inconsistent operation types > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2005 Message-Id: Date: Wed, 13 Jul 2005 10:59:38 -0700 From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resending since I haven't seen this post yet... -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Wednesday, July 13, 2005 9:31 AM To: 'Joel M. Halpern'; FORCES@PEACH.EASE.LSOFT.COM Subject: RE: [FORCES] Result TLV Again a reasonable and simple approach to provide the Results. To put some more context around it, is this how it would look like in a Config Response message? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pls do clarify, No path-data tlv in this format? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, June 30, 2005 12:04 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Result TLV The following is what I suggest for handling results of operations. SET and GET Requests do not have result information (they are requests). SET and GET Responses have result information. SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. For a GET responses, individual gets which succeed will have DATARAW TLVs=20 added to the leaf paths to carry the requested data. For GET elements that=20 fail, instead of the DATARAW TLV there will be a RESULT TLV. For a SET response, each DATARAW TLV in the original request will be=20 replace with a RESULT TLV in the response. If the request was for Ack-fail, then only those items which failed will appear in the response. If the request was for ack-all, then all elements=20 of the request will appear in the response with RESULT TLVs. A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 byte)=20 value. The defined values are 0 =3D success 1 =3D no such object 2 =3D permission denied 3 =3D invalid value (the dataraw could not validly be stored in the field) 4 =3D invalid array creation (when the subscript in an array create = is not=20 allowed) 255 =3D unspecified error (for when the FE can not decide what went wrong) We may need a few more values to cover other errors. Note that if a SET request with a structure in a DATARAW is issued, and=20 some field in the structure is invalid, the FE will not attempt to indicate=20 which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf path-data /=20 DATARAW, the FE can select which error it chooses to return. So if a=20 DATARAW for a SET of a structure attempts to write one field which is read=20 only, and attempts to set another field to an invalid value, the FE can=20 return whatever error it likes. Yours, Joel M. Halpern 2005 Message-Id: Date: Wed, 13 Jul 2005 10:16:05 +0000 From: "David.Putzolu" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------noqwaykivwnmjufoqmpw" ----------noqwaykivwnmjufoqmpw Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Music_MP3.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/13/2005 09:10 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------noqwaykivwnmjufoqmpw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators


----------noqwaykivwnmjufoqmpw-- 2005 Message-Id: Date: Wed, 13 Jul 2005 09:30:47 -0700 From: "Khosravi, Hormuzd M" Subject: Re: Result TLV Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Again a reasonable and simple approach to provide the Results. To put some more context around it, is this how it would look like in a Config Response message? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFB select | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (SET-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operations (DEL-RESP) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pls do clarify, No path-data tlv in this format? Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, June 30, 2005 12:04 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Result TLV The following is what I suggest for handling results of operations. SET and GET Requests do not have result information (they are requests). SET and GET Responses have result information. SET and GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs. For a GET responses, individual gets which succeed will have DATARAW TLVs=20 added to the leaf paths to carry the requested data. For GET elements that=20 fail, instead of the DATARAW TLV there will be a RESULT TLV. For a SET response, each DATARAW TLV in the original request will be=20 replace with a RESULT TLV in the response. If the request was for Ack-fail, then only those items which failed will appear in the response. If the request was for ack-all, then all elements=20 of the request will appear in the response with RESULT TLVs. A RESULT TLV contains a integer (probably 4 bytes, but we only need 1 byte)=20 value. The defined values are 0 =3D success 1 =3D no such object 2 =3D permission denied 3 =3D invalid value (the dataraw could not validly be stored in the field) 4 =3D invalid array creation (when the subscript in an array create = is not=20 allowed) 255 =3D unspecified error (for when the FE can not decide what went wrong) We may need a few more values to cover other errors. Note that if a SET request with a structure in a DATARAW is issued, and=20 some field in the structure is invalid, the FE will not attempt to indicate=20 which field was invalid, but rather will indicate that the operation failed. Note further that if there are multiple errors in a single leaf path-data /=20 DATARAW, the FE can select which error it chooses to return. So if a=20 DATARAW for a SET of a structure attempts to write one field which is read=20 only, and attempts to set another field to an invalid value, the FE can=20 return whatever error it likes. Yours, Joel M. Halpern 2005 Message-Id: Date: Wed, 13 Jul 2005 09:05:21 -0700 From: "Khosravi, Hormuzd M" Subject: Re: Fwd: Re: DataRaw? Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This looks like a simple and efficient way to encapsulate the data. Thanks for the good work guys! I am fine with this format. Regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, July 08, 2005 5:12 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Fwd: Re: DataRaw? Jamal and I have been batting back and forth ideas for how the contents of=20 the dataraw TLV should be constructed, so as to cope with complex=20 circumstances lake arrays with holes and structures with optional elements. The attachment is our current best suggestion. Please take a look and let us know. Thanks, Joel 2005 Message-Id: Date: Wed, 13 Jul 2005 08:48:24 -0700 From: "Khosravi, Hormuzd M" Subject: FW: [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI...format of the Redirect TLV on which we seem to be reaching a concensus. -----Original Message----- I agree with this format for Redirect TLV as well. Should we consider this issue closed? Any other comments on this? Thanks Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.zjgsu.edu.cn]=20 Sent: Wednesday, July 13, 2005 7:43 AM To: Robert Haas; Khosravi, Hormuzd M; avri doria; Putzolu, David; Patrick Droz; donglg@mail.zjgsu.edu.cn; hadi@znyx.com; Joel M. Halpern Subject: Re: [issue32] Packet Redirect Are you supposing the format as: Redirect TLV LFB class ID LFB Insatnce ID Meta-Data TLV Redirct Data TLV I can agree with this well. The only thing is then how the meta-Data TLV should be defined here? Still using Path-Data format or using constant fields ? If constant fields, then it seems quite identical to that was showed below.=20 Sorry to all, I'v to go first. Thanks, Weiming ----- Original Message -----=20 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect > I think the Packet Data TLV you have here is the wrapper to carry the=20 > packet meta-data? > If so, the only question I have is whether it might be simpler and more=20 > general to just treat the port as part of the meta-data rather than=20 > assigning it a separate field. After all, that information will generally=20 > be used / provided by some other LFB than the redirect LFB. >=20 > Yours, > Joel >=20 > At 10:00 AM 7/13/2005, Wang,Weiming wrote: > >Sorry, the following LFB Type should be Type =3D Redirect instead of LFBselect. > > > >----- Original Message ----- > >From: Wang,Weiming > >To: Robert Haas ;=20 > >Khosravi, Hormuzd M ;=20 > >avri doria ; Joel M.=20 > >Halpern ; Putzolu, David ;=20 > >Patrick Droz ;=20 > >donglg@mail.zjgsu.edu.cn ;=20 > >hadi@znyx.com > >Sent: Wednesday, July 13, 2005 9:58 PM > >Subject: Re: [issue32] Packet Redirect > > > >Hi all, > > > >I may only have half an hour for the meeting owing to some urgent=20 > >business. I ask to take first > >some minutes of the call meeting to discuss the packet redirect message=20 > >and try to solve it quickly? > > > >After quite a lot discussion, I try to summary it as in the following > >format for packet redirect 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 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type =3D LFBselect | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LFB Class ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LFB Instance ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Port Number | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > . . > > | Packet Data TLV | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >Packet Data TLV > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type =3D Packet TYpe | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > . . > > | Packet Data | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >Thanks, > >Weiming > > >=20 2005 Message-Id: Date: Wed, 13 Jul 2005 07:39:47 +0800 From: Weiming Wang Subject: Re: DataRaw? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKb2VsIE0uIEhh bHBlcm4iIDxqb2VsQHN0ZXZlY3JvY2tlci5jb20+DQpUbzogIldlaW1pbmcgV2FuZyIgPHdtd2Fu Z0BtYWlsLnpqZ3N1LmVkdS5jbj47IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQoNCj4g V2Ugc3RpbGwgbmVlZCBwYXRocyBmb3Igc2VsZWN0aW5nIHdoaWNoIGVsZW1lbnQgaXMgd2FudGVk LiAgSWYgd2UgYWx3YXlzIA0KPiB3YW50ZWQgdG8gZ2V0IG9yIHNldCB0aGUgd2hvbGUgTEZCLCB3 ZSB3b3VsZCBub3QgbmVlZCBwYXRocy4NCj4gDQo+IE9uZSB3YXkgdG8gdGhpbmsgb2YgdGhpcyBp cyB0aGF0IHRoZSBwYXRoIHJlcHJlc2VudCBhIHNlcXVlbmNlIG9mIEkgZmllbGRzIA0KPiBmcm9t IElMVnMgd2hlcmUgdGhlIGxlbmd0aHMgd291bGQgYmUgcmVkdW5kYW50IGFuZCB0aGUgViBpcyBq dXN0IHRoZSBzaW5nbGUgDQo+IG5leHQgSUxWLg0KDQpUaGUgSUxWcyB3aXRoIGxlbmd0aCA9MCBh dCB0aGUgdGVybWluYWwgY2FuICByZXBzZW50IHRoZSBwYXRoIGZ1bmN0aW9uIHdlbGwgaW4gYSBn ZXQgb3BlcmF0aW9uLiANCkFzIGZvciBlZmZpY2llbmN5LCByZXByZXNlbnRhdGlvbiBvZiBwYXRo cyBsZXNzIHRoYW4gMyBsYXllcnMgKGUuZy4gMS4yLjMpIGlzIG5vdCBhcyBlZmZpY2llbnQgYXMg bmVzdGVkIElMViBmb3JtYXQuDQoNCkFub3RoZXIgdmVyeSBpbXBvcnRhbnQgZmVhdHVyZSBmb3Ig SUxWIGZvcm1hdCBpcywgd2UgbWF5IHVzZSB0aGUgZm9sbG93aW5nIGZvcm1hdCB0byAsIGUuZy4s IHF1ZXJ5IGEgbnVtYmVyIG9mIGZpZWxkcyBmb3IgdmFsdWVzIGF0IG9uY2UsIGxpa2U6DQoNCj4g PiAgIERhdGFyYXcgVExWDQo+ID4gICAgIElMViAoRWxlbWVudElEIHgsIGxlbmd0aD0wKQ0KPiA+ ICAgICBJTFYgKEVsZW1lbnRJRCB5LCBsZW5ndGg9MCkNCj4gPiAgICAgSUxWIChFbGVtZW50SUQg eikNCj4gPiAgICAgICBJTFYgKGluZGV4ID0gMTApDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJ RCBhLCBsZW5ndGg9MCkNCj4gPiAgICAgICAgIElMViAoRWxlbWVudElEIGIsIGxlbmd0aD0wKQ0K PiA+ICAgICAgIElMViAoaW5kZXggPSAxNSApDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJRCBh LCBsZW5ndGg9MCkNCj4gPiAgICAgICAgIElMViAoRWxlbWVudElEIGMsIGxlbmd0aD0wKQ0KDQpU aGUgZ2V0LXJlc3BvbnNlIGlzIHRoZW4gc2ltcGxpZmllZCB0byBmaWxsIG91dCBhbGwgdGhlIHZh bHVlIHBhcnQgaW4gdGhlIElMVnMuDQoNClRoYW5rcywNCldlaW1pbmcNCg0KPiANCj4gWW91cnMs DQo+IEpvZWwNCj4gDQo+IEF0IDEwOjU1IEFNIDcvMTIvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3Rl Og0KPiA+Sm9lbCwgYW5kIEphbWFsLA0KPiA+DQo+ID5JJ20gZ2xhZCB0byBzZWUgdGhhdCBhbiBJ TFYgaXMgdXNlZCB3aGljaCBkaXJlY3RseSB1c2VzIElEIGFzIHRoZSBpbmRleCANCj4gPmZvciBl bGVtZW50LCB3aGljaCBtYXRjaGVzIG15IHZlcnkgZWFybHkgdGhvdWdodCB0aGF0IHdlIHVzZSBh dHRyaWJ1dGUgSUQgDQo+ID5mb3IgaW5kZXggZGlyZWN0bHkgcmF0aGVyIHRoYW4gYSBwYXRoLg0K PiA+DQo+ID5JIGxpa2UgdGhpcyBleGFtcGxlOg0KPiA+DQo+ID4gICBEYXRhcmF3IFRMVg0KPiA+ ICAgICBJTFYgKEVsZW1lbnRJRCB4LCBsZW5ndGgsIHZhbHVlIG9mIHgpDQo+ID4gICAgIElMViAo RWxlbWVudElEIHksIGxlbmd0aCwgdmFsdWUgb2YgeSkNCj4gPiAgICAgSUxWIChFbGVtZW50SUQg eikNCj4gPiAgICAgICBJTFYgKGluZGV4ID0gMTApDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJ RCBhLCBsZW5ndGgsIHZhbHVlIG9mIGEpDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJRCBiLCBs ZW5ndGgsIHZhbHVlIG9mIGIpDQo+ID4gICAgICAgICBJTFYgKEVsZW1lbnRJRCBjLCBsZW5ndGgs IHZhbHVlIG9mIGMpDQo+ID4gICAgICAgSUxWIChpbmRleCA9IDE1ICkNCj4gPiAgICAgICAgIElM ViAoRWxlbWVudElEIGEsIGxlbmd0aCwgdmFsdWUgb2YgYSkNCj4gPiAgICAgICAgIElMViAoRWxl bWVudElEIGMsIGxlbmd0aCwgdmFsdWUgb2YgYykNCj4gPg0KPiA+QnkgdXNpbmcgc3VjaCBuZXN0 ZCBJTFYgZm9ybWF0LCBhZ2FpbiwgbXkgcXVlc3Rpb24gaXMsIGRvIHdlIG5lZWQgdGhlIFBhdGgg DQo+ID5mb3JtYXQgYW55bW9yZT8NCj4gPg0KPiA+VGhhbmsgeW91Lg0KPiA+V2VpbWluZw0KPiA+ DQo+ID4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID5Gcm9tOiAiSm9lbCBNLiBIYWxw ZXJuIiA8am9lbEBzdGV2ZWNyb2NrZXIuY29tPg0KPiA+VG86IDxGT1JDRVNAUEVBQ0guRUFTRS5M U09GVC5DT00+DQo+ID5TZW50OiBTYXR1cmRheSwgSnVseSAwOSwgMjAwNSA4OjExIEFNDQo+ID5T dWJqZWN0OiBGd2Q6IFJlOiBEYXRhUmF3Pw0KPiA+DQo+ID4NCj4gPiA+IEphbWFsIGFuZCBJIGhh dmUgYmVlbiBiYXR0aW5nIGJhY2sgYW5kIGZvcnRoIGlkZWFzIGZvciBob3cgdGhlIGNvbnRlbnRz IG9mDQo+ID4gPiB0aGUgZGF0YXJhdyBUTFYgc2hvdWxkIGJlIGNvbnN0cnVjdGVkLCBzbyBhcyB0 byBjb3BlIHdpdGggY29tcGxleA0KPiA+ID4gY2lyY3Vtc3RhbmNlcyBsYWtlIGFycmF5cyB3aXRo IGhvbGVzIGFuZCBzdHJ1Y3R1cmVzIHdpdGggb3B0aW9uYWwgZWxlbWVudHMuDQo+ID4gPiBUaGUg YXR0YWNobWVudCBpcyBvdXIgY3VycmVudCBiZXN0IHN1Z2dlc3Rpb24uDQo+ID4gPg0KPiA+ID4g UGxlYXNlIHRha2UgYSBsb29rIGFuZCBsZXQgdXMga25vdy4NCj4gPiA+IFRoYW5rcywNCj4gPiA+ IEpvZWwNCj4g 2005 Message-Id: Date: Tue, 12 Jul 2005 22:55:09 +0800 From: Weiming Wang Subject: Re: DataRaw? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCwgYW5kIEphbWFsLA0KDQpJJ20gZ2xhZCB0byBzZWUgdGhhdCBhbiBJTFYgaXMgdXNlZCB3 aGljaCBkaXJlY3RseSB1c2VzIElEIGFzIHRoZSBpbmRleCBmb3IgZWxlbWVudCwgd2hpY2ggbWF0 Y2hlcyBteSB2ZXJ5IGVhcmx5IHRob3VnaHQgdGhhdCB3ZSB1c2UgYXR0cmlidXRlIElEIGZvciBp bmRleCBkaXJlY3RseSByYXRoZXIgdGhhbiBhIHBhdGguIA0KDQpJIGxpa2UgdGhpcyBleGFtcGxl Og0KDQogIERhdGFyYXcgVExWDQogICAgSUxWIChFbGVtZW50SUQgeCwgbGVuZ3RoLCB2YWx1ZSBv ZiB4KQ0KICAgIElMViAoRWxlbWVudElEIHksIGxlbmd0aCwgdmFsdWUgb2YgeSkNCiAgICBJTFYg KEVsZW1lbnRJRCB6KQ0KICAgICAgSUxWIChpbmRleCA9IDEwKQ0KICAgICAgICBJTFYgKEVsZW1l bnRJRCBhLCBsZW5ndGgsIHZhbHVlIG9mIGEpDQogICAgICAgIElMViAoRWxlbWVudElEIGIsIGxl bmd0aCwgdmFsdWUgb2YgYikNCiAgICAgICAgSUxWIChFbGVtZW50SUQgYywgbGVuZ3RoLCB2YWx1 ZSBvZiBjKQ0KICAgICAgSUxWIChpbmRleCA9IDE1ICkNCiAgICAgICAgSUxWIChFbGVtZW50SUQg YSwgbGVuZ3RoLCB2YWx1ZSBvZiBhKQ0KICAgICAgICBJTFYgKEVsZW1lbnRJRCBjLCBsZW5ndGgs IHZhbHVlIG9mIGMpDQoNCkJ5IHVzaW5nIHN1Y2ggbmVzdGQgSUxWIGZvcm1hdCwgYWdhaW4sIG15 IHF1ZXN0aW9uIGlzLCBkbyB3ZSBuZWVkIHRoZSBQYXRoIGZvcm1hdCBhbnltb3JlPyANCg0KVGhh bmsgeW91Lg0KV2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IkpvZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NClRvOiA8Rk9SQ0VTQFBF QUNILkVBU0UuTFNPRlQuQ09NPg0KU2VudDogU2F0dXJkYXksIEp1bHkgMDksIDIwMDUgODoxMSBB TQ0KU3ViamVjdDogRndkOiBSZTogRGF0YVJhdz8NCg0KDQo+IEphbWFsIGFuZCBJIGhhdmUgYmVl biBiYXR0aW5nIGJhY2sgYW5kIGZvcnRoIGlkZWFzIGZvciBob3cgdGhlIGNvbnRlbnRzIG9mIA0K PiB0aGUgZGF0YXJhdyBUTFYgc2hvdWxkIGJlIGNvbnN0cnVjdGVkLCBzbyBhcyB0byBjb3BlIHdp dGggY29tcGxleCANCj4gY2lyY3Vtc3RhbmNlcyBsYWtlIGFycmF5cyB3aXRoIGhvbGVzIGFuZCBz dHJ1Y3R1cmVzIHdpdGggb3B0aW9uYWwgZWxlbWVudHMuDQo+IFRoZSBhdHRhY2htZW50IGlzIG91 ciBjdXJyZW50IGJlc3Qgc3VnZ2VzdGlvbi4NCj4gDQo+IFBsZWFzZSB0YWtlIGEgbG9vayBhbmQg bGV0IHVzIGtub3cuDQo+IFRoYW5rcywNCj4gSm9lbA== 2005 Message-Id: Date: Tue, 12 Jul 2005 20:22:18 -0400 From: "Joel M. Halpern" Subject: Re: DataRaw? Comments: To: Weiming Wang Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed a) In my opinion, it is helpful to have a clear sesparation between "this is the thing I am interested in" (path) and "this is the value of the thing I am interested in" (dataraw or packed-dataraw). b) We could use just the ILV in Set Request and Get Response messages. However, if there is any depth there will be a lot of redundant length fields and more complex parsing to realize that there are not additional elements at each level. c) We could use the ILV with length 0 in GET requests to indicate "this is the field I want to get", but that seems a very misleading encoding of a very natural concept. Basically, the path structure gives us a clear and compact representation of an important concept in the protocol activity. Yours, Joel At 07:39 PM 7/12/2005, Weiming Wang wrote: >Joel, > >----- Original Message ----- >From: "Joel M. Halpern" > > > We still need paths for selecting which element is wanted. If we always > > wanted to get or set the whole LFB, we would not need paths. > > > > One way to think of this is that the path represent a sequence of I fields > > from ILVs where the lengths would be redundant and the V is just the > single > > next ILV. > >The ILVs with length =0 at the terminal can repsent the path function >well in a get operation. >As for efficiency, representation of paths less than 3 layers (e.g. 1.2.3) >is not as efficient as nested ILV format. > >Another very important feature for ILV format is, we may use the following >format to , e.g., query a number of fields for values at once, like: > > > > Dataraw TLV > > > ILV (ElementID x, length=0) > > > ILV (ElementID y, length=0) > > > ILV (ElementID z) > > > ILV (index = 10) > > > ILV (ElementID a, length=0) > > > ILV (ElementID b, length=0) > > > ILV (index = 15 ) > > > ILV (ElementID a, length=0) > > > ILV (ElementID c, length=0) > >The get-response is then simplified to fill out all the value part in the >ILVs. > >Thanks, >Weiming > > > > > Yours, > > Joel > > > > At 10:55 AM 7/12/2005, Weiming Wang wrote: > > >Joel, and Jamal, > > > > > >I'm glad to see that an ILV is used which directly uses ID as the index > > >for element, which matches my very early thought that we use attribute ID > > >for index directly rather than a path. > > > > > >I like this example: > > > > > > Dataraw TLV > > > ILV (ElementID x, length, value of x) > > > ILV (ElementID y, length, value of y) > > > ILV (ElementID z) > > > ILV (index = 10) > > > ILV (ElementID a, length, value of a) > > > ILV (ElementID b, length, value of b) > > > ILV (ElementID c, length, value of c) > > > ILV (index = 15 ) > > > ILV (ElementID a, length, value of a) > > > ILV (ElementID c, length, value of c) > > > > > >By using such nestd ILV format, again, my question is, do we need the > Path > > >format anymore? > > > > > >Thank you. > > >Weiming > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >Sent: Saturday, July 09, 2005 8:11 AM > > >Subject: Fwd: Re: DataRaw? > > > > > > > > > > Jamal and I have been batting back and forth ideas for how the > contents of > > > > the dataraw TLV should be constructed, so as to cope with complex > > > > circumstances lake arrays with holes and structures with optional > elements. > > > > The attachment is our current best suggestion. > > > > > > > > Please take a look and let us know. > > > > Thanks, > > > > Joel > > 2005 Message-Id: Date: Tue, 12 Jul 2005 17:21:45 -0400 From: "Joel M. Halpern" Subject: Re: DataRaw? Comments: To: Weiming Wang Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed We still need paths for selecting which element is wanted. If we always wanted to get or set the whole LFB, we would not need paths. One way to think of this is that the path represent a sequence of I fields from ILVs where the lengths would be redundant and the V is just the single next ILV. Yours, Joel At 10:55 AM 7/12/2005, Weiming Wang wrote: >Joel, and Jamal, > >I'm glad to see that an ILV is used which directly uses ID as the index >for element, which matches my very early thought that we use attribute ID >for index directly rather than a path. > >I like this example: > > Dataraw TLV > ILV (ElementID x, length, value of x) > ILV (ElementID y, length, value of y) > ILV (ElementID z) > ILV (index = 10) > ILV (ElementID a, length, value of a) > ILV (ElementID b, length, value of b) > ILV (ElementID c, length, value of c) > ILV (index = 15 ) > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > >By using such nestd ILV format, again, my question is, do we need the Path >format anymore? > >Thank you. >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Sent: Saturday, July 09, 2005 8:11 AM >Subject: Fwd: Re: DataRaw? > > > > Jamal and I have been batting back and forth ideas for how the contents of > > the dataraw TLV should be constructed, so as to cope with complex > > circumstances lake arrays with holes and structures with optional elements. > > The attachment is our current best suggestion. > > > > Please take a look and let us know. > > Thanks, > > Joel 2005 Message-Id: Date: Tue, 12 Jul 2005 12:02:11 -0700 From: "Deleganes, Ellen M" Subject: Re: LFB library draft Comments: To: "Khosravi, Hormuzd M" , "Joel M. Halpern" Comments: cc: "Yang, Lily L" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I pulled out the LFB definitions out of the current model document and gave them to Jamal as a starting point. I still have that version if you need it. Unfortunately, Steven Blake wasn't able to get much further than this. Ellen -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Wednesday, July 06, 2005 11:06 PM To: Joel M. Halpern; FORCES@PEACH.EASE.LSOFT.COM Cc: Yang, Lily L; Deleganes, Ellen M Subject: RE: [FORCES] LFB library draft Joel, If I remember correctly the original FE Model draft that Lily was editing did have a bunch of LFB definitions, an initial LFB library of sorts. The plan was to move this content to a different draft and add more details to it. Do you have the starting draft with the content from the original FE Model draft? That would be a good starting point and then the WG/authors can start refining the content...but a starting draft would be helpful. Let me know if I am off track here, Thanks Hormuzd -----Original Message----- This relates to a larger question for the list... We NEED an LFB library. Please! To do this, we need folks to actually write definitions of LFBs. (I think we have an editor who is likely to be willing to pull things=20 together. At least I hope so.) There are a lot of LFBs that need writing. If this WG doesn't start producing them, it won't happen. Yours, Joel 2005 Message-Id: Date: Tue, 12 Jul 2005 11:13:40 +0200 From: Robert Haas Subject: Re: Fwd: Re: DataRaw? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Searching through the new model draft I have found answers to some of my=20 previous questions: I wrote: > Joel, Jamal, > The syntax looks ok to me. But I am not sure though how optional=20 > elements are the way of life in ForCES as some aspects are still=20 > unclear to me, for instance: > > Do we assume that default values are returned for optional elements=20 > unless they are explicitely set, or is there a reserved value= ? There is no value defined, apparently. > Does the default value appear in the LFB definition for each optional=20 > element ? Not clear if a default value MUST appear for each optional element though. > > What do we mean by "optional LFB element" exactly ? > Does it mean that from the LFB definition perspective, all optional=20 > elements MUST be supported by the FE and they MAY be used by the CE ? > Or can we have optional elements of an LFB that a particular FE=20 > implementation does not support ? According to the model draft, it is the latter (a particular LFB=20 instance in a FE implementation does not have to support all optional=20 elements). This makes sense, although using too many of these optional=20 elements will lead to complex CE software if the software wants to=20 benefit from whatever optional elements are provided. > > Regards, > -Robert > > Joel M. Halpern wrote: > >> Jamal and I have been batting back and forth ideas for how the=20 >> contents of the dataraw TLV should be constructed, so as to cope with=20 >> complex circumstances lake arrays with holes and structures with=20 >> optional elements. >> The attachment is our current best suggestion. >> >> Please take a look and let us know. >> Thanks, >> Joel >> >> ----------------------------------------------------------------------= -- >> >> >> A Data TLV has a 16 bit Type =3D DATARAW or PACKED-DATARAW, and a 16bi= t=20 >> Length >> followed by the data value/contents. >> In the case of the DATARAW (note: not packed) each DATA element in=20 >> the Value part will be further encapsulated in an ILV. An ILV is like=20 >> a TLV except it has a 32 bit Index (or element ID) and a 32 bit=20 >> Length field. >> The rationale behind ILVs is to make it easier to encapsulate optional= y >> appearing Data elements (which are expected to be the way of life in=20 >> Forces). >> >> Rules: >> >> 1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be=20 >> padded >> to achieve the alignement. >> >> 2) Packed-Dataraw TLV may be used at a particular path only if every=20 >> element at that path level is present. This requirement holds=20 >> whether the fields are fixed or variable length, mandatory or optional. >> >> 3) An assumed optimization is that the encoder(sender) and the=20 >> decoder(receiver) >> both understand the definition of the data elements being shipped. >> >> a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for=20 >> each element ordered by the order in which the data was defined. This=20 >> ensures >> the decoder is guaranteed to retrieve the data. >> >> b) In the case of a non-packed Dataraw we dont need to order since the >> I in the ILV uniquely identifies the element. >> >> 4) Inside a Packed-Dataraw TLV >> a) the values for atomic, fixed-length fields are given without=20 >> any TLV or >> ILV encapsulation. >> b) the values for atomic, variable-length fields are given inside=20 >> Dataraw TLVs. >> >> 5) Inside a Dataraw TLV (not packed) >> -> the values for atomic fields may be given with ILVs (32-bit=20 >> index, 32-bit length) >> >> 6) Any of the Dataraws can contain a ILV but an ILV cannot contain a=20 >> DATARAW. >> This is because it is hard to disambiguate ILV since an I is 32 >> bit and a T is 16 bit. >> >> 7) A DATARAW can also contain a DATARAW for variable sized elements.=20 >> The decoding disambiguation is assumed from rule #3 above. >> >> >> We give a few examples below but dont show the padding. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 1: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure with three fixed-length, mandatory fields. >> >> >> struct S { >> uint16 a >> uint16 b >> uint16 c >> } >> >> >> (a) Describing all fields using DATARAW >> with ILVs (index/length values) >> >> Path to an instance of S ... >> Dataraw TLV >> ILV: ElementID(a), length(a), value(a) >> ILV: ElementID(b), length(b), >> value(b) >> ILV: ElementID(c), length(c), >> value(c) >> >> (b) Describing a subset of fields >> Path-Data TLV to an instance of S ... >> Dataraw TLV >> ILV ElementID(a), length(a), value(a) >> ILV: ElementID(c), length(c), >> value(c) >> >> Note: Even though we have non-optional elements in structure S, since >> we can uniquely identify elements, we can selectively send element of >> structure S (eg in the case of an update from CE to FE). >> >> (c) Describing all fields using a Packed-Dataraw TLV >> >> Path to an instance of S ... >> Packed-Dataraw TLV >> value(a) >> value(b) >> value(c) >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 2: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure with three fixed-length fields, one mandatory, two optional. >> >> >> struct T { >> uint16 a >> uint16 b (optional) >> uint16 c (optional) >> } >> >> This example is identical to Example 1, as illustrated below. >> >> >> (a) Describing all fields using ILVs (index/length values) >> >> Path to an instance of T ... >> Dataraw TLV >> ILV: ElementID(a), length(a) >> value(a) >> ILV: ElementID(b), length(b) >> value(b) >> ILV: ElementID(c), length(c) >> value(c) >> >> (b) Describing a subset of fields using ILVs (index/length values) >> >> Path to an instance of T ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> (c) Describing all fields using a Packed-Dataraw TLV >> >> Path to an instance of T ... >> Packed-Dataraw TLV >> (value of a) >> (value of b) >> (value of c) >> >> Note: Packed-Dataraw TLV _cannot_ be used unless all fields are being=20 >> described. >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 3: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure with a mix of fixed-length and variable-length fields, some=20 >> mandatory, some optional (would be a good idea to show unions maybe). >> >> >> struct U { >> uint16 a >> string b (optional) >> uint16 c (optional) >> } >> >> >> (a) Describing all fields using ILVs >> >> Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> >> >> (b) Describing a subset of fields using ILVs >> >> Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> >> (c) Describing all fields using a Packed-Dataraw TLV >> >> Path to an instance of U ... >> Packed-Dataraw TLV (value of a) >> Packed-Dataraw TLV (value of b) >> (value of c) >> >> Note: The variable-length field requires the addition of a TLV=20 >> withing the >> packed data. >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Example 4: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Structure containing an array of another structure type. >> >> >> struct V { >> uint32 x >> uint32 y >> struct U z[] >> } >> >> >> (a): Describing all fields of V using ILVs, with two instances of=20 >> z[], also >> described with ILVs, assuming only the 10th and 15th subscript of z[]. >> >> path to instance of V ... >> Dataraw TLV >> ILV (ElementID x, length, value of x) >> ILV (ElementID y, length, value of y) >> ILV (ElementID z) >> ILV (index =3D 10) >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> ILV (index =3D 15 ) >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> Note the holes in the elements of z (10 followed by 15). Also note the >> gap in index 15 with only elements a and c appearing but not b. >> >> =20 >> > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Tue, 12 Jul 2005 10:56:43 +0200 From: Robert Haas Subject: Re: Fwd: Re: DataRaw? Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Joel, Jamal, The syntax looks ok to me. But I am not sure though how optional=20 elements are the way of life in ForCES as some aspects are still unclear=20 to me, for instance: Do we assume that default values are returned for optional elements=20 unless they are explicitely set, or is there a reserved value ? Does the default value appear in the LFB definition for each optional=20 element ? What do we mean by "optional LFB element" exactly ? Does it mean that from the LFB definition perspective, all optional=20 elements MUST be supported by the FE and they MAY be used by the CE ? Or can we have optional elements of an LFB that a particular FE=20 implementation does not support ? Regards, -Robert Joel M. Halpern wrote: > Jamal and I have been batting back and forth ideas for how the=20 > contents of the dataraw TLV should be constructed, so as to cope with=20 > complex circumstances lake arrays with holes and structures with=20 > optional elements. > The attachment is our current best suggestion. > > Please take a look and let us know. > Thanks, > Joel > >------------------------------------------------------------------------ > > >A Data TLV has a 16 bit Type =3D DATARAW or PACKED-DATARAW, and a 16bit = Length >followed by the data value/contents. >In the case of the DATARAW (note: not packed) each DATA element in the=20 >Value part will be further encapsulated in an ILV. An ILV is like a=20 >TLV except it has a 32 bit Index (or element ID) and a 32 bit Length fie= ld. >The rationale behind ILVs is to make it easier to encapsulate optionaly >appearing Data elements (which are expected to be the way of life in For= ces). > >Rules: > >1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be pad= ded >to achieve the alignement. > >2) Packed-Dataraw TLV may be used at a particular path only if=20 >every element at that path level is present. This requirement=20 >holds whether the fields are fixed or variable length, mandatory or opti= onal. > >3) An assumed optimization is that the encoder(sender) and the decoder(r= eceiver) >both understand the definition of the data elements being shipped. > >a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for eac= h=20 >element ordered by the order in which the data was defined. This ensures >the decoder is guaranteed to retrieve the data. > >b) In the case of a non-packed Dataraw we dont need to order since the >I in the ILV uniquely identifies the element. > >4) Inside a Packed-Dataraw TLV > a) the values for atomic, fixed-length fields are given without any = TLV or > ILV encapsulation. > b) the values for atomic, variable-length fields are given inside=20 > Dataraw TLVs. > >5) Inside a Dataraw TLV (not packed) > -> the values for atomic fields may be given with ILVs (32-bit index= ,=20 > 32-bit length) > >6) Any of the Dataraws can contain a ILV but an ILV cannot contain a DA= TARAW. >This is because it is hard to disambiguate ILV since an I is 32 >bit and a T is 16 bit. > >7) A DATARAW can also contain a DATARAW for variable sized elements.=20 >The decoding disambiguation is assumed from rule #3 above. > > >We give a few examples below but dont show the padding. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 1: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure with three fixed-length, mandatory fields. > > >struct S { > uint16 a > uint16 b > uint16 c >} > > >(a) Describing all fields using DATARAW >with ILVs (index/length values) > >Path to an instance of S ... > Dataraw TLV > ILV: ElementID(a), length(a),=20 > value(a) > ILV: ElementID(b), length(b), > value(b) > ILV: ElementID(c), length(c), > value(c) > >(b) Describing a subset of fields=20 > >Path-Data TLV to an instance of S ... > Dataraw TLV > ILV ElementID(a), length(a),=20 > value(a) > ILV: ElementID(c), length(c), > value(c) > >Note: Even though we have non-optional elements in structure S, since >we can uniquely identify elements, we can selectively send element of >structure S (eg in the case of an update from CE to FE). > >(c) Describing all fields using a Packed-Dataraw TLV > >Path to an instance of S ... > Packed-Dataraw TLV > value(a) > value(b) > value(c) > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 2: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure with three fixed-length fields, one mandatory, two optional. > > >struct T { > uint16 a > uint16 b (optional) > uint16 c (optional) >} > >This example is identical to Example 1, as illustrated below. > > >(a) Describing all fields using ILVs (index/length values) > >Path to an instance of T ... > Dataraw TLV > ILV: ElementID(a), length(a) > value(a) > ILV: ElementID(b), length(b) > value(b) > ILV: ElementID(c), length(c) > value(c) > >(b) Describing a subset of fields using ILVs (index/length values) > >Path to an instance of T ... > Dataraw TLV > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > >(c) Describing all fields using a Packed-Dataraw TLV > >Path to an instance of T ... > Packed-Dataraw TLV > (value of a) > (value of b) > (value of c) > >Note: Packed-Dataraw TLV _cannot_ be used unless all=20 >fields are being described. > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 3: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure with a mix of fixed-length and variable-length fields,=20 >some mandatory, some optional (would be a good idea to show unions maybe= ). > > >struct U { > uint16 a > string b (optional) > uint16 c (optional) >} > > >(a) Describing all fields using ILVs > >Path to an instance of U ... > Dataraw TLV > ILV (ElementID a, length, value of a) > ILV (ElementID b, length, value of b) > ILV (ElementID c, length, value of c) > > >(b) Describing a subset of fields using ILVs > >Path to an instance of U ... > Dataraw TLV > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > > >(c) Describing all fields using a Packed-Dataraw TLV > >Path to an instance of U ... > Packed-Dataraw TLV=20 > (value of a) > Packed-Dataraw TLV (value of b) > (value of c) > >Note: The variable-length field requires the addition of a TLV withing t= he >packed data. > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Example 4: >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Structure containing an array of another structure type. > > >struct V { > uint32 x > uint32 y > struct U z[] >} > > >(a): Describing all fields of V using ILVs, with two instances of z[], a= lso >described with ILVs, assuming only the 10th and 15th subscript of z[]. > >path to instance of V ... > Dataraw TLV > ILV (ElementID x, length, value of x) > ILV (ElementID y, length, value of y) > ILV (ElementID z) > ILV (index =3D 10) > ILV (ElementID a, length, value of a) > ILV (ElementID b, length, value of b) > ILV (ElementID c, length, value of c) > ILV (index =3D 15 ) > ILV (ElementID a, length, value of a) > ILV (ElementID c, length, value of c) > >Note the holes in the elements of z (10 followed by 15). Also note the >gap in index 15 with only elements a and c appearing but not b. > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2005 Message-Id: Date: Tue, 12 Jul 2005 07:41:31 -0400 From: "Joel M. Halpern" Subject: Re: Fwd: Re: DataRaw? Comments: To: Robert Haas Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable An optional element is a component (LFB attribute, part of a structure,=20 ...) that an FE is not required to support. A request to GET the component will return an error (= =20 or equivalent.). GETting the whole structure will return the supported=20 fields, and not the unsupported fields. A SET request which includes=20 writing that field will return an error. A not supported optional element is not the same as a read-only element=20 with a defaul value. Yours, Joel At 04:56 AM 7/12/2005, Robert Haas wrote: >Joel, Jamal, >The syntax looks ok to me. But I am not sure though how optional elements= =20 >are the way of life in ForCES as some aspects are still unclear to me, for= =20 >instance: > >Do we assume that default values are returned for optional elements unless= =20 >they are explicitely set, or is there a reserved value ? >Does the default value appear in the LFB definition for each optional=20 >element ? > >What do we mean by "optional LFB element" exactly ? >Does it mean that from the LFB definition perspective, all optional=20 >elements MUST be supported by the FE and they MAY be used by the CE ? >Or can we have optional elements of an LFB that a particular FE=20 >implementation does not support ? > >Regards, >-Robert > >Joel M. Halpern wrote: > >>Jamal and I have been batting back and forth ideas for how the contents=20 >>of the dataraw TLV should be constructed, so as to cope with complex=20 >>circumstances lake arrays with holes and structures with optional= elements. >>The attachment is our current best suggestion. >> >>Please take a look and let us know. >>Thanks, >>Joel >> >>------------------------------------------------------------------------ >> >> >>A Data TLV has a 16 bit Type =3D DATARAW or PACKED-DATARAW, and a 16bit= Length >>followed by the data value/contents. >>In the case of the DATARAW (note: not packed) each DATA element in the=20 >>Value part will be further encapsulated in an ILV. An ILV is like a TLV=20 >>except it has a 32 bit Index (or element ID) and a 32 bit Length field. >>The rationale behind ILVs is to make it easier to encapsulate optionaly >>appearing Data elements (which are expected to be the way of life in= Forces). >> >>Rules: >> >>1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be= padded >>to achieve the alignement. >> >>2) Packed-Dataraw TLV may be used at a particular path only if every=20 >>element at that path level is present. This requirement holds whether=20 >>the fields are fixed or variable length, mandatory or optional. >> >>3) An assumed optimization is that the encoder(sender) and the=20 >>decoder(receiver) >>both understand the definition of the data elements being shipped. >> >>a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for each= =20 >>element ordered by the order in which the data was defined. This ensures >>the decoder is guaranteed to retrieve the data. >> >>b) In the case of a non-packed Dataraw we dont need to order since the >>I in the ILV uniquely identifies the element. >> >>4) Inside a Packed-Dataraw TLV >> a) the values for atomic, fixed-length fields are given without any=20 >> TLV or >> ILV encapsulation. >> b) the values for atomic, variable-length fields are given=20 >> inside Dataraw TLVs. >> >>5) Inside a Dataraw TLV (not packed) >> -> the values for atomic fields may be given with ILVs (32-bit=20 >> index, 32-bit length) >> >>6) Any of the Dataraws can contain a ILV but an ILV cannot contain a=20 >>DATARAW. >>This is because it is hard to disambiguate ILV since an I is 32 >>bit and a T is 16 bit. >> >>7) A DATARAW can also contain a DATARAW for variable sized elements. The= =20 >>decoding disambiguation is assumed from rule #3 above. >> >> >>We give a few examples below but dont show the padding. >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 1: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure with three fixed-length, mandatory fields. >> >> >>struct S { >> uint16 a >> uint16 b >> uint16 c >>} >> >> >>(a) Describing all fields using DATARAW >>with ILVs (index/length values) >> >>Path to an instance of S ... >> Dataraw TLV >> ILV: ElementID(a), length(a), value(a) >> ILV: ElementID(b), length(b), >> value(b) >> ILV: ElementID(c), length(c), >> value(c) >> >>(b) Describing a subset of fields >>Path-Data TLV to an instance of S ... >> Dataraw TLV >> ILV ElementID(a), length(a), value(a) >> ILV: ElementID(c), length(c), >> value(c) >> >>Note: Even though we have non-optional elements in structure S, since >>we can uniquely identify elements, we can selectively send element of >>structure S (eg in the case of an update from CE to FE). >> >>(c) Describing all fields using a Packed-Dataraw TLV >> >>Path to an instance of S ... >> Packed-Dataraw TLV >> value(a) >> value(b) >> value(c) >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 2: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure with three fixed-length fields, one mandatory, two optional. >> >> >>struct T { >> uint16 a >> uint16 b (optional) >> uint16 c (optional) >>} >> >>This example is identical to Example 1, as illustrated below. >> >> >>(a) Describing all fields using ILVs (index/length values) >> >>Path to an instance of T ... >> Dataraw TLV >> ILV: ElementID(a), length(a) >> value(a) >> ILV: ElementID(b), length(b) >> value(b) >> ILV: ElementID(c), length(c) >> value(c) >> >>(b) Describing a subset of fields using ILVs (index/length values) >> >>Path to an instance of T ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >>(c) Describing all fields using a Packed-Dataraw TLV >> >>Path to an instance of T ... >> Packed-Dataraw TLV >> (value of a) >> (value of b) >> (value of c) >> >>Note: Packed-Dataraw TLV _cannot_ be used unless all fields are being=20 >>described. >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 3: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure with a mix of fixed-length and variable-length fields, some=20 >>mandatory, some optional (would be a good idea to show unions maybe). >> >> >>struct U { >> uint16 a >> string b (optional) >> uint16 c (optional) >>} >> >> >>(a) Describing all fields using ILVs >> >>Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> >> >>(b) Describing a subset of fields using ILVs >> >>Path to an instance of U ... >> Dataraw TLV >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >> >>(c) Describing all fields using a Packed-Dataraw TLV >> >>Path to an instance of U ... >> Packed-Dataraw TLV (value of a) >> Packed-Dataraw TLV (value of b) >> (value of c) >> >>Note: The variable-length field requires the addition of a TLV withing the >>packed data. >> >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>Example 4: >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>Structure containing an array of another structure type. >> >> >>struct V { >> uint32 x >> uint32 y >> struct U z[] >>} >> >> >>(a): Describing all fields of V using ILVs, with two instances of z[],= also >>described with ILVs, assuming only the 10th and 15th subscript of z[]. >> >>path to instance of V ... >> Dataraw TLV >> ILV (ElementID x, length, value of x) >> ILV (ElementID y, length, value of y) >> ILV (ElementID z) >> ILV (index =3D 10) >> ILV (ElementID a, length, value of a) >> ILV (ElementID b, length, value of b) >> ILV (ElementID c, length, value of c) >> ILV (index =3D 15 ) >> ILV (ElementID a, length, value of a) >> ILV (ElementID c, length, value of c) >> >>Note the holes in the elements of z (10 followed by 15). Also note the >>gap in index 15 with only elements a and c appearing but not b. >> >> > >-- >Dr. Robert R. Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha 2005 Message-Id: Date: Sat, 9 Jul 2005 23:54:51 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB library draft-reuse of NPF FAPI library Comments: To: "Joel M. Halpern" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain I am glad you used the term "starting" point as opposed to "reusing", Joel. Lets not shoot ourselves in the big toe just so the NPF APIs can look as if they are being endorsed by the IETF. Didnt we go over this discussion several times already over the last year or so? cheers, jamal On Sat, 2005-09-07 at 22:36 -0400, Joel M. Halpern wrote: > These FAPI definitions sound like good starting points for defining the LFBs. > I am not sure we will have separate configuration manager LFBs, given the > way things are working. But we can see once we have some proposed definitions. > Yours, > Joel M. Halpern > > At 08:02 PM 7/9/2005, Khosravi, Hormuzd M wrote: > >Hi Joel, > > > >One suggestion...several members of this working group, (Alistair > >Munroe, John Renwick, others) including FE Model team members (Steve, > >Zsolt, Ellen, Lily, Alan, others) have contributed over last several > >years to define a bunch of Functional APIs (FAPI) library in the NPF > >(Network Processing Forum). A lot of those are now standardized and > >available as implementation agreements (IAs) to the public. > > > >It would be wise to reuse the LFB definitions from these FAPIs, atleast > >for the ones that are available. This would also chime well with our WG > >charter to coordinate with other related standards groups. Ellen is > >currently active in the NPF and can provide you with any more info in > >this regard. > > > >The FAPIs are available at the following website... > >http://www.npforum.org/techinfo/approved-chronological.shtml > > > >The FAPIs currently available as IAs... > > > >IPv4 Prefix LFB and Functional API (February 2005) > >Generic Classifier LFB and Functional API (December 2004) > >Topology Manager Functional API (December 2004) > >Messaging LFB (September 2004) > >ATM Configuration Manager Functional API (March 2005) > >ATM Header Generator LFB and Functional API (March 2005) > >ATM Header Classifier LFB and Functional API (March 2005) > > > >Next-Hop LFB and Functional API - should be available anytime now > >(approved) > >Rate Meter LFB and Functional API - should be available in sometime > > > >Let me know if you have any questions in this regard, > > > >Thanks > >Hormuzd 2005 Message-Id: Date: Sat, 9 Jul 2005 22:36:07 -0400 From: "Joel M. Halpern" Subject: Re: LFB library draft-reuse of NPF FAPI library Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed These FAPI definitions sound like good starting points for defining the LFBs. I am not sure we will have separate configuration manager LFBs, given the way things are working. But we can see once we have some proposed definitions. Yours, Joel M. Halpern At 08:02 PM 7/9/2005, Khosravi, Hormuzd M wrote: >Hi Joel, > >One suggestion...several members of this working group, (Alistair >Munroe, John Renwick, others) including FE Model team members (Steve, >Zsolt, Ellen, Lily, Alan, others) have contributed over last several >years to define a bunch of Functional APIs (FAPI) library in the NPF >(Network Processing Forum). A lot of those are now standardized and >available as implementation agreements (IAs) to the public. > >It would be wise to reuse the LFB definitions from these FAPIs, atleast >for the ones that are available. This would also chime well with our WG >charter to coordinate with other related standards groups. Ellen is >currently active in the NPF and can provide you with any more info in >this regard. > >The FAPIs are available at the following website... >http://www.npforum.org/techinfo/approved-chronological.shtml > >The FAPIs currently available as IAs... > >IPv4 Prefix LFB and Functional API (February 2005) >Generic Classifier LFB and Functional API (December 2004) >Topology Manager Functional API (December 2004) >Messaging LFB (September 2004) >ATM Configuration Manager Functional API (March 2005) >ATM Header Generator LFB and Functional API (March 2005) >ATM Header Classifier LFB and Functional API (March 2005) > >Next-Hop LFB and Functional API - should be available anytime now >(approved) >Rate Meter LFB and Functional API - should be available in sometime > >Let me know if you have any questions in this regard, > >Thanks >Hormuzd 2005 Message-Id: Date: Sat, 9 Jul 2005 17:02:07 -0700 From: "Khosravi, Hormuzd M" Subject: Re: LFB library draft-reuse of NPF FAPI library Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joel, One suggestion...several members of this working group, (Alistair Munroe, John Renwick, others) including FE Model team members (Steve, Zsolt, Ellen, Lily, Alan, others) have contributed over last several years to define a bunch of Functional APIs (FAPI) library in the NPF (Network Processing Forum). A lot of those are now standardized and available as implementation agreements (IAs) to the public. It would be wise to reuse the LFB definitions from these FAPIs, atleast for the ones that are available. This would also chime well with our WG charter to coordinate with other related standards groups. Ellen is currently active in the NPF and can provide you with any more info in this regard. The FAPIs are available at the following website... http://www.npforum.org/techinfo/approved-chronological.shtml The FAPIs currently available as IAs... IPv4 Prefix LFB and Functional API (February 2005) Generic Classifier LFB and Functional API (December 2004) Topology Manager Functional API (December 2004) Messaging LFB (September 2004) ATM Configuration Manager Functional API (March 2005) ATM Header Generator LFB and Functional API (March 2005) ATM Header Classifier LFB and Functional API (March 2005) Next-Hop LFB and Functional API - should be available anytime now (approved) Rate Meter LFB and Functional API - should be available in sometime Let me know if you have any questions in this regard, Thanks Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Thursday, July 07, 2005 5:03 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] LFB library draft There were descriptions for several LFBs. None of them were=20 definitions. Some of them were wrong. Some were probably the wrong=20 thing. Some were right. I would recommend that rather than going back and digging those out, we=20 start a process to get a good set of definitions. We will need to make a list of ones we want. I am sure that will rapidly be larger than we can deliver. Yours, Joel At 02:05 AM 7/7/2005, Khosravi, Hormuzd M wrote: >Joel, > >If I remember correctly the original FE Model draft that Lily was >editing did have a bunch of LFB definitions, an initial LFB library of >sorts. The plan was to move this content to a different draft and add >more details to it. > >Do you have the starting draft with the content from the original FE >Model draft? That would be a good starting point and then the WG/authors >can start refining the content...but a starting draft would be helpful. > >Let me know if I am off track here, > >Thanks >Hormuzd > >-----Original Message----- >This relates to a larger question for the list... >We NEED an LFB library. >Please! >To do this, we need folks to actually write definitions of LFBs. >(I think we have an editor who is likely to be willing to pull things >together. At least I hope so.) >There are a lot of LFBs that need writing. >If this WG doesn't start producing them, it won't happen. > > >Yours, >Joel 2005 Message-Id: Date: Fri, 8 Jul 2005 20:11:55 -0400 From: "Joel M. Halpern" Subject: Fwd: Re: DataRaw? Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_358645==_" --=====================_358645==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Jamal and I have been batting back and forth ideas for how the contents of the dataraw TLV should be constructed, so as to cope with complex circumstances lake arrays with holes and structures with optional elements. The attachment is our current best suggestion. Please take a look and let us know. Thanks, Joel --=====================_358645==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="packed-dataraw1.txt" A Data TLV has a 16 bit Type = DATARAW or PACKED-DATARAW, and a 16bit Length followed by the data value/contents. In the case of the DATARAW (note: not packed) each DATA element in the Value part will be further encapsulated in an ILV. An ILV is like a TLV except it has a 32 bit Index (or element ID) and a 32 bit Length field. The rationale behind ILVs is to make it easier to encapsulate optionaly appearing Data elements (which are expected to be the way of life in Forces). Rules: 1) Both ILVs and TLVs MUST 32 bit aligned. If need be they SHOULD be padded to achieve the alignement. 2) Packed-Dataraw TLV may be used at a particular path only if every element at that path level is present. This requirement holds whether the fields are fixed or variable length, mandatory or optional. 3) An assumed optimization is that the encoder(sender) and the decoder(receiver) both understand the definition of the data elements being shipped. a) If a Packed-Dataraw TLV is used, the encoder MUST layout data for each element ordered by the order in which the data was defined. This ensures the decoder is guaranteed to retrieve the data. b) In the case of a non-packed Dataraw we dont need to order since the I in the ILV uniquely identifies the element. 4) Inside a Packed-Dataraw TLV a) the values for atomic, fixed-length fields are given without any TLV or ILV encapsulation. b) the values for atomic, variable-length fields are given inside Dataraw TLVs. 5) Inside a Dataraw TLV (not packed) -> the values for atomic fields may be given with ILVs (32-bit index, 32-bit length) 6) Any of the Dataraws can contain a ILV but an ILV cannot contain a DATARAW. This is because it is hard to disambiguate ILV since an I is 32 bit and a T is 16 bit. 7) A DATARAW can also contain a DATARAW for variable sized elements. The decoding disambiguation is assumed from rule #3 above. We give a few examples below but dont show the padding. ========== Example 1: ========== Structure with three fixed-length, mandatory fields. struct S { uint16 a uint16 b uint16 c } (a) Describing all fields using DATARAW with ILVs (index/length values) Path to an instance of S ... Dataraw TLV ILV: ElementID(a), length(a), value(a) ILV: ElementID(b), length(b), value(b) ILV: ElementID(c), length(c), value(c) (b) Describing a subset of fields Path-Data TLV to an instance of S ... Dataraw TLV ILV ElementID(a), length(a), value(a) ILV: ElementID(c), length(c), value(c) Note: Even though we have non-optional elements in structure S, since we can uniquely identify elements, we can selectively send element of structure S (eg in the case of an update from CE to FE). (c) Describing all fields using a Packed-Dataraw TLV Path to an instance of S ... Packed-Dataraw TLV value(a) value(b) value(c) ========== Example 2: ========== Structure with three fixed-length fields, one mandatory, two optional. struct T { uint16 a uint16 b (optional) uint16 c (optional) } This example is identical to Example 1, as illustrated below. (a) Describing all fields using ILVs (index/length values) Path to an instance of T ... Dataraw TLV ILV: ElementID(a), length(a) value(a) ILV: ElementID(b), length(b) value(b) ILV: ElementID(c), length(c) value(c) (b) Describing a subset of fields using ILVs (index/length values) Path to an instance of T ... Dataraw TLV ILV (ElementID a, length, value of a) ILV (ElementID c, length, value of c) (c) Describing all fields using a Packed-Dataraw TLV Path to an instance of T ... Packed-Dataraw TLV (value of a) (value of b) (value of c) Note: Packed-Dataraw TLV _cannot_ be used unless all fields are being described. ========== Example 3: ========== Structure with a mix of fixed-length and variable-length fields, some mandatory, some optional (would be a good idea to show unions maybe). struct U { uint16 a string b (optional) uint16 c (optional) } (a) Describing all fields using ILVs Path to an instance of U ... Dataraw TLV ILV (ElementID a, length, value of a) ILV (ElementID b, length, value of b) ILV (ElementID c, length, value of c) (b) Describing a subset of fields using ILVs Path to an instance of U ... Dataraw TLV ILV (ElementID a, length, value of a) ILV (ElementID c, length, value of c) (c) Describing all fields using a Packed-Dataraw TLV Path to an instance of U ... Packed-Dataraw TLV (value of a) Packed-Dataraw TLV (value of b) (value of c) Note: The variable-length field requires the addition of a TLV withing the packed data. ========== Example 4: ========== Structure containing an array of another structure type. struct V { uint32 x uint32 y struct U z[] } (a): Describing all fields of V using ILVs, with two instances of z[], also described with ILVs, assuming only the 10th and 15th subscript of z[]. path to instance of V ... Dataraw TLV ILV (ElementID x, length, value of x) ILV (ElementID y, length, value of y) ILV (ElementID z) ILV (index = 10) ILV (ElementID a, length, value of a) ILV (ElementID b, length, value of b) ILV (ElementID c, length, value of c) ILV (index = 15 ) ILV (ElementID a, length, value of a) ILV (ElementID c, length, value of c) Note the holes in the elements of z (10 followed by 15). Also note the gap in index 15 with only elements a and c appearing but not b. --=====================_358645==_-- 2005 Message-Id: Date: Thu, 7 Jul 2005 10:27:18 +0800 From: "Wang,Weiming" Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 QSB2ZXJ5IHNpbXBsZSBxdWVzdGlvbiB0aGVuLCBob3cgbWFueSBiaXRzIHdlIHRoZW4gY2FuIGFz c2lnbiB0byB0aGUgbWV0YS1kYXRhIGxpa2UgdGhlIHBvcnQgbnVtYmVyID8NCg0KdGhhbmtzLA0K d2VpbWluZw0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSm9lbCBN LiBIYWxwZXJuIiA8am9lbEBzdGV2ZWNyb2NrZXIuY29tPg0KVG86ICJXZWltaW5nIFdhbmciIDx3 bXdhbmdAbWFpbC56amdzdS5lZHUuY24+OyA8Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NPg0K U2VudDogVGh1cnNkYXksIEp1bHkgMDcsIDIwMDUgNDowOSBBTQ0KU3ViamVjdDogUmU6IFtpc3N1 ZTMyXSBQYWNrZXQgUmVkaXJlY3QNCg0KDQo+IEFmdGVyIHNvbWUgZGlzY3Vzc2lvbiwgdGhlIG9w ZXJhdGlvbmFsIGRhdGEgbWF5IGJlIHNpbXBsZXIgdGhhbiBJIGhhZCBiZWVuIA0KPiB0aGlua2lu Zy4NCj4gV2UgY2FuIHNpbXBseSBhdHRhY2ggKGluIHNvbWUgcmVhc29uYWJsZSBUTFYgZm9ybWF0 KSBhbGwgdGhlIG1ldGEtZGF0YS4NCj4gU28gcGFja2V0cyBmcm9tIHRoZSBDRSBjb21lIHdpdGgg bWV0YS1kYXRhLCBhbmQgdGhlIENFIGdldHMgYWxsIHRoZSANCj4gbWV0YS1kYXRhIGZyb20gdGhl IEZFIGFzc29jaWF0ZWQgd2l0aCBhIHBhY2tldC4NCj4gVGhhdCBlbnN1cmVzIHRoYXQgYWxsIHRo ZSBuZWNlc3NhcnkgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlLCB3aXRob3V0IA0KPiBtYWtpbmcg dGhlIHJlZGlyZWN0IExGQnMgY29tcGxleC4NCj4gDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBB dCAxMDo0NCBBTSA3LzYvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3RlOg0KPiA+Sm9lbCwNCj4gPg0K PiA+SSB0ZW5kIHRvIGFncmVlIHdpdGggeW91ciBpZGVhIGJlbG93IGV4Y2VwdCB0aGUgaW5kZXgu ICBDb3VsZCB5b3UgZ2l2ZSANCj4gPm1vcmUgZGV0YWlscyBvbiBpdHMgbmVjZXNzaXR5PyBUaGFu a3MuDQo+ID5BcyBhIHJlc3VsdCwgdGhlIGFncmVlYWJsZSBmb3JtYXQgdG8gbWUgc2VlbXMgbGlr ZToNCj4gPg0KPiA+UmVkaXJlY3QgVExWLCB3aGl0aCBjb250YWlucw0KPiA+ICAgICBMRkIgY2xh c3MgSUQNCj4gPiAgICAgTEZCIGluc3RhbmNlIElEDQo+ID4gICAgIG9wZXJhdGlvbiBUTFYgKFJF UE9SVCksIHdoaWNoIGNvbnRhaW5zIFBhdGgtRGF0YQ0KPiA+ICAgICBQYWNrZXQgVExWDQo+ID4N Cj4gPldlIGZ1cnRoZXIgZGVmaW5lIHRoYXQgdGhhdCBQYXRoLURhdGEgc2hvdWxkIHN1cHBseSBl bm91Z2ggaW5mb3JtYXRpb24gZm9yIA0KPiA+dGhlIGZvbGxvd2VkIHBhY2tldC4gQXQgbGVhc3Qg aXQgc2hvdWxkIGluY2x1ZGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHBvcnQgDQo+ID5udW1iZXIg dGhlIHJlZGlyZWN0IHBhY2tldCBpcyBpbnB1dChzaW5rIExGQikgb3IgaXMgb3V0cHV0IChzb3Vy Y2UgTEZCKSwgDQo+ID5hbmQgdGhlIHJlZGlyZWN0IHBhY2tldCB0eXBlLiBIb3cgdGhpcyBpcyBk ZWZpbmVkIGlzIGxlZnQgdG8gbW9kZWwgd2hlcmUgDQo+ID5yZWRpcmVjdCBMRkJzIGFuZCB0aGUg YXR0cmlidXRlcyBhcmUgZGVmaW5lZC4NCj4gPg0KPiA+V2UgbmVlZCB0byBzb2x2ZSB0aGlzIGEg bGl0dGxlIHNvb25lci4NCj4gPg0KPiA+dGhvdWdodHM/DQo+ID4NCj4gPlRoYW5rcywNCj4gPldl aW1pbmcNCj4gPg0KPiA+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiA+RnJvbTogIkpv ZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NCj4gPlN1YmplY3Q6IFJlZGly ZWN0IE1lc3NhZ2UNCj4gPg0KPiA+DQo+ID4gPiBCYXNlZCBvbiBkaXNjdXNzaW9uLCBhbmQgYmFz ZWQgb24gbXkgZWFybGllciBtZXNzYWdlIHRoYXQgc3BlY2lmaWMgDQo+ID4gcHJvdG9jb2wNCj4g PiA+IG1lc3NhZ2VzIG1heSBoYXZlIGRpZmZlcmVudCB0b3AgbGV2ZWwgVExWcywgaGVyZSBpcyBh IGRlc2NyaXB0aW9uIG9mIHRoZQ0KPiA+ID4gY29udGVudHMgb2YgYSByZWRpcmVjdCBtZXNzYWdl Lg0KPiA+ID4NCj4gPiA+IEEgcmVkaXJlY3QgbWVzc2FnZSB3aWxsIGNvbnRhaW4gYSByZWRpcmVj dCBUTFYuDQo+ID4gPiBBIHJlZGlyZWN0IFRMViBjb25zaXN0cyBvZiB0aHJlZSBmaXhlZCBmaWVs ZHMsIGFuZCBtZXRhLWRhdGEgVExWLCBhbmQgdGhlDQo+ID4gPiBwYWNrZXQuDQo+ID4gPiBUaGUg Zml4ZWQgZmllbGRzIGFyZQ0KPiA+ID4gbyB0aGUgTEZCIENsYXNzIElEIG9mIHRoZSByZWRpcmVj dCBzb3VyY2Ugb3IgcmVkaXJlY3Qgc2luayBMRkIgb24gdGhlIEZFDQo+ID4gPiBhc3NvY2lhdGVk IHdpdGggdGhpcyBwYWNrZXQNCj4gPiA+IG8gdGhlIExGQiBJbnN0YW5jZSBJRCBvZiB0aGUgcmVk aXJlY3Qgc291cmNlIG9yIHJlZGlyZWN0IHNpbmsgTEZCIG9uIA0KPiA+IHRoZSBGRQ0KPiA+ID4g YXNzb2NpYXRlZCB3aXRoIHRoaXMgcGFja2V0DQo+ID4gPiBvIGFuIGluZGV4IHdpdGhpbiB0aGF0 IExGQiB0byBpZGVudGlmeSBjb25maWd1cmVkIHByb3BlcnRpZXMgb2YgdGhlIHBhY2tldC4NCj4g PiA+DQo+ID4gPiBUaGUgbWV0YS1kYXRhIFRMViBjb250YWlucyBkeW5hbWljIGluZm9ybWF0aW9u IG5lZWRlZCBieSB0aGUgRkUgb3IgQ0UgdG8NCj4gPiA+IHByb2Nlc3MgdGhlIHBhY2tldC4gIFRo aXMgd2lsbCBuZWVkIHRvIGJlIHNwZWxsZWQgb3V0IGluIG1vcmUgZGV0YWlsLiAgSXQNCj4gPiA+ IG1heSBuZWVkIHRvIHVzZSBwYXRoIGVuY29kaW5nLg0KPiA+ID4NCj4gPiA+IEZvbGxvd2luZyB0 aGlzIHdpbGwgYmUgdGhlIHBhY2tldC4NCj4gPiA+DQo+ID4gPiBZb3VycywNCj4gPiA+IEpvZWwN Cj4gDQo= 2005 Message-Id: Date: Thu, 7 Jul 2005 08:03:29 -0400 From: "Joel M. Halpern" Subject: Re: LFB library draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed There were descriptions for several LFBs. None of them were definitions. Some of them were wrong. Some were probably the wrong thing. Some were right. I would recommend that rather than going back and digging those out, we start a process to get a good set of definitions. We will need to make a list of ones we want. I am sure that will rapidly be larger than we can deliver. Yours, Joel At 02:05 AM 7/7/2005, Khosravi, Hormuzd M wrote: >Joel, > >If I remember correctly the original FE Model draft that Lily was >editing did have a bunch of LFB definitions, an initial LFB library of >sorts. The plan was to move this content to a different draft and add >more details to it. > >Do you have the starting draft with the content from the original FE >Model draft? That would be a good starting point and then the WG/authors >can start refining the content...but a starting draft would be helpful. > >Let me know if I am off track here, > >Thanks >Hormuzd > >-----Original Message----- >This relates to a larger question for the list... >We NEED an LFB library. >Please! >To do this, we need folks to actually write definitions of LFBs. >(I think we have an editor who is likely to be willing to pull things >together. At least I hope so.) >There are a lot of LFBs that need writing. >If this WG doesn't start producing them, it won't happen. > > >Yours, >Joel 2005 Message-Id: Date: Wed, 6 Jul 2005 23:35:38 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue32] Packet Redirect Comments: To: "Joel M. Halpern" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain On Wed, 2005-06-07 at 22:38 -0400, Joel M. Halpern wrote: > > This relates to a larger question for the list... > We NEED an LFB library. > Please! > To do this, we need folks to actually write definitions of LFBs. > (I think we have an editor who is likely to be willing to pull things > together. At least I hope so.) > There are a lot of LFBs that need writing. > If this WG doesn't start producing them, it won't happen. I was going to ask for a slot to present a couple of the LFBs (Port and IPv4) that Steve B. and I were supposed to be working on. I figured this is the only way to get people to pay attention. cheers, jamal 2005 Message-Id: Date: Wed, 6 Jul 2005 23:07:13 -0400 From: Alan DeKok Subject: Re: [issue32] Packet Redirect <6.2.1.2.0.20050706223256.02dcd900@localhost> "Joel M. Halpern" wrote: > There is a whole section on meta-data in the model document. > I would expect most meta-data fields to be 32 bits. > The CE can choose to use a meta-data classifier and multiple meta-data > fields in order to steer the packet to the right LFB. And the CE will know > what meta-data field the LFB will use for selecting among its ports. Sounds good to me. > There are a lot of LFBs that need writing. > If this WG doesn't start producing them, it won't happen. This WG isn't alone in that respect. Alan DeKok. 2005 Message-Id: Date: Wed, 6 Jul 2005 23:05:46 -0700 From: "Khosravi, Hormuzd M" Subject: Re: LFB library draft Comments: To: "Joel M. Halpern" Comments: cc: "Yang, Lily L" , "Deleganes, Ellen M" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel, If I remember correctly the original FE Model draft that Lily was editing did have a bunch of LFB definitions, an initial LFB library of sorts. The plan was to move this content to a different draft and add more details to it. Do you have the starting draft with the content from the original FE Model draft? That would be a good starting point and then the WG/authors can start refining the content...but a starting draft would be helpful. Let me know if I am off track here, Thanks Hormuzd -----Original Message----- This relates to a larger question for the list... We NEED an LFB library. Please! To do this, we need folks to actually write definitions of LFBs. (I think we have an editor who is likely to be willing to pull things=20 together. At least I hope so.) There are a lot of LFBs that need writing. If this WG doesn't start producing them, it won't happen. Yours, Joel 2005 Message-Id: Date: Wed, 6 Jul 2005 22:44:47 +0800 From: Weiming Wang Subject: Re: [issue32] Packet Redirect MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91ciBpZGVhIGJlbG93IGV4Y2VwdCB0aGUg aW5kZXguICBDb3VsZCB5b3UgZ2l2ZSBtb3JlIGRldGFpbHMgb24gaXRzIG5lY2Vzc2l0eT8gVGhh bmtzLg0KQXMgYSByZXN1bHQsIHRoZSBhZ3JlZWFibGUgZm9ybWF0IHRvIG1lIHNlZW1zIGxpa2U6 DQoNClJlZGlyZWN0IFRMViwgd2hpdGggY29udGFpbnMNCiAgICBMRkIgY2xhc3MgSUQNCiAgICBM RkIgaW5zdGFuY2UgSUQNCiAgICBvcGVyYXRpb24gVExWIChSRVBPUlQpLCB3aGljaCBjb250YWlu cyBQYXRoLURhdGENCiAgICBQYWNrZXQgVExWDQoNCldlIGZ1cnRoZXIgZGVmaW5lIHRoYXQgdGhh dCBQYXRoLURhdGEgc2hvdWxkIHN1cHBseSBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIHRoZSBmb2xs b3dlZCBwYWNrZXQuIEF0IGxlYXN0IGl0IHNob3VsZCBpbmNsdWRlIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBwb3J0IG51bWJlciB0aGUgcmVkaXJlY3QgcGFja2V0IGlzIGlucHV0KHNpbmsgTEZCKSBv ciBpcyBvdXRwdXQgKHNvdXJjZSBMRkIpLCBhbmQgdGhlIHJlZGlyZWN0IHBhY2tldCB0eXBlLiBI b3cgdGhpcyBpcyBkZWZpbmVkIGlzIGxlZnQgdG8gbW9kZWwgd2hlcmUgcmVkaXJlY3QgTEZCcyBh bmQgdGhlIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQuDQoNCldlIG5lZWQgdG8gc29sdmUgdGhpcyBh IGxpdHRsZSBzb29uZXIuDQoNCnRob3VnaHRzPyANCg0KVGhhbmtzLA0KV2VpbWluZw0KDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkpvZWwgTS4gSGFscGVybiIgPGpvZWxA c3RldmVjcm9ja2VyLmNvbT4NClN1YmplY3Q6IFJlZGlyZWN0IE1lc3NhZ2UNCg0KDQo+IEJhc2Vk IG9uIGRpc2N1c3Npb24sIGFuZCBiYXNlZCBvbiBteSBlYXJsaWVyIG1lc3NhZ2UgdGhhdCBzcGVj aWZpYyBwcm90b2NvbCANCj4gbWVzc2FnZXMgbWF5IGhhdmUgZGlmZmVyZW50IHRvcCBsZXZlbCBU TFZzLCBoZXJlIGlzIGEgZGVzY3JpcHRpb24gb2YgdGhlIA0KPiBjb250ZW50cyBvZiBhIHJlZGly ZWN0IG1lc3NhZ2UuDQo+IA0KPiBBIHJlZGlyZWN0IG1lc3NhZ2Ugd2lsbCBjb250YWluIGEgcmVk aXJlY3QgVExWLg0KPiBBIHJlZGlyZWN0IFRMViBjb25zaXN0cyBvZiB0aHJlZSBmaXhlZCBmaWVs ZHMsIGFuZCBtZXRhLWRhdGEgVExWLCBhbmQgdGhlIA0KPiBwYWNrZXQuDQo+IFRoZSBmaXhlZCBm aWVsZHMgYXJlDQo+IG8gdGhlIExGQiBDbGFzcyBJRCBvZiB0aGUgcmVkaXJlY3Qgc291cmNlIG9y IHJlZGlyZWN0IHNpbmsgTEZCIG9uIHRoZSBGRSANCj4gYXNzb2NpYXRlZCB3aXRoIHRoaXMgcGFj a2V0DQo+IG8gdGhlIExGQiBJbnN0YW5jZSBJRCBvZiB0aGUgcmVkaXJlY3Qgc291cmNlIG9yIHJl ZGlyZWN0IHNpbmsgTEZCIG9uIHRoZSBGRSANCj4gYXNzb2NpYXRlZCB3aXRoIHRoaXMgcGFja2V0 DQo+IG8gYW4gaW5kZXggd2l0aGluIHRoYXQgTEZCIHRvIGlkZW50aWZ5IGNvbmZpZ3VyZWQgcHJv cGVydGllcyBvZiB0aGUgcGFja2V0Lg0KPiANCj4gVGhlIG1ldGEtZGF0YSBUTFYgY29udGFpbnMg ZHluYW1pYyBpbmZvcm1hdGlvbiBuZWVkZWQgYnkgdGhlIEZFIG9yIENFIHRvIA0KPiBwcm9jZXNz IHRoZSBwYWNrZXQuICBUaGlzIHdpbGwgbmVlZCB0byBiZSBzcGVsbGVkIG91dCBpbiBtb3JlIGRl dGFpbC4gIEl0IA0KPiBtYXkgbmVlZCB0byB1c2UgcGF0aCBlbmNvZGluZy4NCj4gDQo+IEZvbGxv d2luZyB0aGlzIHdpbGwgYmUgdGhlIHBhY2tldC4NCj4gDQo+IFlvdXJzLA0KPiBKb2Vs 2005 Message-Id: Date: Wed, 6 Jul 2005 22:38:27 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed There is a whole section on meta-data in the model document. I would expect most meta-data fields to be 32 bits. The CE can choose to use a meta-data classifier and multiple meta-data fields in order to steer the packet to the right LFB. And the CE will know what meta-data field the LFB will use for selecting among its ports. This relates to a larger question for the list... We NEED an LFB library. Please! To do this, we need folks to actually write definitions of LFBs. (I think we have an editor who is likely to be willing to pull things together. At least I hope so.) There are a lot of LFBs that need writing. If this WG doesn't start producing them, it won't happen. To get back to your question Weiming, given a set of LFB definitions and the meta-data they use, I can better specify what the CE will send / receive. But in an abstract sense, since it will be information flowing between the redirect LFB and the eventual interface LFB, the way the model prescribes to carry that information is as meta-data. This is the same meta-data that will need, for example, to come out of longest-prefix-match and next-hop resolution LFBs. After all, they need to be able to direct packets to be shipped out specific interfaces, with specific headers, etc. Yours, Joel At 10:27 PM 7/6/2005, Wang,Weiming wrote: >A very simple question then, how many bits we then can assign to the >meta-data like the port number ? > >thanks, >weiming > > >----- Original Message ----- >From: "Joel M. Halpern" >Sent: Thursday, July 07, 2005 4:09 AM >Subject: Re: [issue32] Packet Redirect > > > > After some discussion, the operational data may be simpler than I had been > > thinking. > > We can simply attach (in some reasonable TLV format) all the meta-data. > > So packets from the CE come with meta-data, and the CE gets all the > > meta-data from the FE associated with a packet. > > That ensures that all the necessary information is available, without > > making the redirect LFBs complex. > > > > Yours, > > Joel > > > > At 10:44 AM 7/6/2005, Weiming Wang wrote: > > >Joel, > > > > > >I tend to agree with your idea below except the index. Could you give > > >more details on its necessity? Thanks. > > >As a result, the agreeable format to me seems like: > > > > > >Redirect TLV, whith contains > > > LFB class ID > > > LFB instance ID > > > operation TLV (REPORT), which contains Path-Data > > > Packet TLV > > > > > >We further define that that Path-Data should supply enough information > for > > >the followed packet. At least it should include information about the > port > > >number the redirect packet is input(sink LFB) or is output (source LFB), > > >and the redirect packet type. How this is defined is left to model where > > >redirect LFBs and the attributes are defined. > > > > > >We need to solve this a little sooner. > > > > > >thoughts? > > > > > >Thanks, > > >Weiming > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > >Subject: Redirect Message > > > > > > > > > > Based on discussion, and based on my earlier message that specific > > > protocol > > > > messages may have different top level TLVs, here is a description > of the > > > > contents of a redirect message. > > > > > > > > A redirect message will contain a redirect TLV. > > > > A redirect TLV consists of three fixed fields, and meta-data TLV, > and the > > > > packet. > > > > The fixed fields are > > > > o the LFB Class ID of the redirect source or redirect sink LFB on > the FE > > > > associated with this packet > > > > o the LFB Instance ID of the redirect source or redirect sink LFB on > > > the FE > > > > associated with this packet > > > > o an index within that LFB to identify configured properties of the > packet. > > > > > > > > The meta-data TLV contains dynamic information needed by the FE or > CE to > > > > process the packet. This will need to be spelled out in more > detail. It > > > > may need to use path encoding. > > > > > > > > Following this will be the packet. > > > > > > > > Yours, > > > > Joel > > 2005 Message-Id: Date: Wed, 6 Jul 2005 16:09:57 -0400 From: "Joel M. Halpern" Subject: Re: [issue32] Packet Redirect Comments: To: Weiming Wang Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed After some discussion, the operational data may be simpler than I had been thinking. We can simply attach (in some reasonable TLV format) all the meta-data. So packets from the CE come with meta-data, and the CE gets all the meta-data from the FE associated with a packet. That ensures that all the necessary information is available, without making the redirect LFBs complex. Yours, Joel At 10:44 AM 7/6/2005, Weiming Wang wrote: >Joel, > >I tend to agree with your idea below except the index. Could you give >more details on its necessity? Thanks. >As a result, the agreeable format to me seems like: > >Redirect TLV, whith contains > LFB class ID > LFB instance ID > operation TLV (REPORT), which contains Path-Data > Packet TLV > >We further define that that Path-Data should supply enough information for >the followed packet. At least it should include information about the port >number the redirect packet is input(sink LFB) or is output (source LFB), >and the redirect packet type. How this is defined is left to model where >redirect LFBs and the attributes are defined. > >We need to solve this a little sooner. > >thoughts? > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" >Subject: Redirect Message > > > > Based on discussion, and based on my earlier message that specific > protocol > > messages may have different top level TLVs, here is a description of the > > contents of a redirect message. > > > > A redirect message will contain a redirect TLV. > > A redirect TLV consists of three fixed fields, and meta-data TLV, and the > > packet. > > The fixed fields are > > o the LFB Class ID of the redirect source or redirect sink LFB on the FE > > associated with this packet > > o the LFB Instance ID of the redirect source or redirect sink LFB on > the FE > > associated with this packet > > o an index within that LFB to identify configured properties of the packet. > > > > The meta-data TLV contains dynamic information needed by the FE or CE to > > process the packet. This will need to be spelled out in more detail. It > > may need to use path encoding. > > > > Following this will be the packet. > > > > Yours, > > Joel 2005 Message-Id: Date: Tue, 5 Jul 2005 23:23:51 -0700 From: "Khosravi, Hormuzd M" Subject: issues tracker updated for issues 22, 32, 47, 53, 54 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C581F3.47B44823" This is a multi-part message in MIME format. ------_=_NextPart_001_01C581F3.47B44823 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I have updated the ForCES issues tracker to reflect the discussion and resolution we had for the following issues last week... # 22, 32, 47, 53, 54 =20 The draft needs to be updated accordingly. Pls let me know if there are any comments. =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C581F3.47B44823 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have updated the ForCES issues tracker to reflect = the discussion and resolution we had for the following issues last = week…

# 22, 32, 47, 53, 54

 

The draft needs to be updated accordingly. Pls let me = know if there are any comments.

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C581F3.47B44823-- 2005 Message-Id: Date: Tue, 5 Jul 2005 19:55:49 -0400 From: "Joel M. Halpern" Subject: New model DRAFT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I have completed an editing pass on the model document. I have added aliases, properties, and events. I have added an example to try to explain how some of this works. Jamal has very helpfully posted the draft at: ftp://ftp.znyx.com/users/hadi/private/forces/ Note, this is the word document. It has change tracking turned on, so you should easily be able to tell what I did. Ellen will be working this document over when she gets back from vacation, and we will submit that to the I-D respository. The XML Schema passes XMLSpy's validity test. The two LFBs validate against that schema. I believe the example is indented badly. Sorry. I can not get word to cooperate on it. One note on the Schema. I do not have the tools to usefully validate the Key / KeyRef declarations. And while my tool uses them, I think it uses them wrong because I get mysterious errors. If someone who understands Key / KeyRef could look at them, I am happy to fix them up. I am sure there are many other errors. And probably places that need clarification even if they are not wrong. Please, Please, Please read the draft. Send comments. Yours, Joel M. Halpern